ENGENHARIA DE SOFTWARE I

ROTEIRO VERIFICAÇÃO 3

1. MODELAGEM
a. Entender os diversos tipos de associação
i. Uma associação informa que algumas classes possuem uma ligação
entre elas, significando, por exemplo, que elas “conhecem uma a
outra”, “estão conectadas com”, etc.
ii. Cardinalidade é o que acontece para expressar multiplicidade entre os
relacionamentos, existe um intervalo que indica quantos objetos estão
relacionados na ligação.
1. Zero para um (0..1)
2. Zero para vários (0..* ou *)
3. Um para vários (1..*)
4. Cinco para onze (5..11)
5. Se não for descrita nenhuma multiplicidade, então é
considerado o padrão de um para um (1..1 ou 1)

iii. Tipos de Associação:

1. Normal: Ocorre quando há apenas uma conexão entre classes
(Cliente possui uma conta, conta pertence a um cliente)
2. Recurssiva: É possível conectar uma classe a ela mesma através
de uma associação.

3. Qualificada: são mais utilizadas com associações de um para

vários (1..*) ou vários para vários. O qualificador pode ser visto
como um tipo de chave para separar todos os objetos.

4. Exclusiva: é uma restrição entre duas ou mais associações, ela

especifica que objetos de uma classe sofrem restrições de
acordo com o sistema modelado.

5. Ordenada: o padrão das associações é serem desordenadas,

então para que se haja uma associação ordenada, coloca-se
“{ordenada}”.
6. De Classe: é uma classe que é associada a outra associação,
serve para se adicionar informações extas a uma associação
existente.
 7. N-ária ou múltiplas associações: esta associação é representada
por um grande losango (diamante) e ainda suporta uma
associação de classe ligada a ela. Pode ser ternária (três classes),
quaternária (quatro classes) e assim por diante.

b. Conceitos de agregação e composição

i. Agregação é um caso particular de associação. A agregação indica que
uma das classes do relacionamento é uma parte, ou está contida em
outra classe.
1. Agregação compartilhada (regular): uma agregação é dita
regular quando uma das classes é uma parte, ou está contida na
outra.

2. Agregação de composição: é uma agregação onde uma classe

que está contida na outra “vive” e constitui a outra.
2. DIAGRAMA DE CASOS DE USO
a. Diferença entre requisitos funcionais e não funcionais
i. Requisitos funcionais
1. Especificam ações que um sistema deve ser capaz de executar,
sem levar em consideração restrições físicas. Exemplo:
a. Toda mensagem deve ter um remetente.
ii. Requisitos não funcionais
1. Descreve em geral condições relacionadas ao ambiente do
sistema.
2. Diz respeito a questões como: usabilidade, desempenho,
confiabilidade, restrições, etc.
3. Estão relacionados aos atributos de qualidade do sistema.
Exemplo:
a. O sistema deve ter uma interface amigável.
b. O tempo de resposta não pode ser superior a 20
segundos.
b. Objetivo de casos de uso
i. Devem ser considerados os problemas dos usuários.
ii. São o que realmente os stakeholders precisam para resolver os seus
problemas, independentemente de um sistema. Exemplo:
1. Uma comunicação melhor entre os empregados.
c. Cenários
i. É uma sequência de passos que descreve uma interação entre um
usuário e um sistema.
ii. Exemplo de um cenário cujo objetivo é COMPRAR PRODUTOS:
 1. O cliente navega no catálogo de itens e adiciona os itens
desejados à sua cesta de compras. Quando o cliente deseja
pagar, descreve o endereço de entrega, fornece as informações
do cartão de crédito e confirma a venda. O sistema verifica a
autorização do cartão de crédito e confirma a venda
imediatamente com um e-mail subsequente.
d. Ator
i. Papel que os usuários desempenham quando interagem com o sistema
através de um caso de uso.
1. Usuário, Cliente, Gerente, Médico
ii. Ator Primário
1. Ator que inicializa um diálogo com o caso de uso.
iii. Ator Secundário
1. Ator que interage com o caso de uso, mas não inicializou o
diálogo.

e. Relacionamentos inclusão e extenção

i. Relacionamento de Inclusão
1. É usado quando há um conjunto de passos que se repete em
dois ou mais casos de uso. Reutilização.
2. Uma regra simples: usar o relacionamento de inclusão quando
o caso de uso incluído é obrigatório.
3. Para modularizar um caso de uso complexo. Facilitar o
entendimento. Situação menos usual.
 ii. Relacionamento de Extensão
1. É usado quando há casos particulares (opcionais ou
excepcionais) do caso de uso principal.
2. Uma regra simples: usar o relacionamento de extensão quando
o caso de uso que estende é opcional.

3. ESPECIFICAÇÕES DE CASO DE USO E REGRAS DE NEGÓCIO

a. Entender os elementos do fluxo principal de especificações de casos de uso
e seu objetivo
i. A Especificação de Caso de Uso (ECU) é um documento textual que
descreve os cenários de um caso de uso, isto é, os vários cenários
possíveis, entre um ator e o sistema, de um mesmo objetivo.
ii. Descreve os passos que um caso de uso deve realizar.
iii. Não deve fazer referência ao como.
iv. A Especificação de Regras de Negócio (ERN) também é um
documento textual, mas descreve os requisitos funcionais que
independem do diálogo. Descrevem as regras que podem ser usadas em
vários casos de uso: validações, cálculos, etc.
v. Uma especificação de caso de uso pode fazer referência a nenhuma ou
a várias especificações de regras de negócio.
 vi. As regras de negócio podem descritas em texto livre, pseudo-código,
em tabelas, etc.
vii. É uma descrição breve da intenção (do objetivo) do caso de uso
viii. Objetivo do caso de uso Sacar Dinheiro:
1. Este caso de uso descreve o procedimento de saque de dinheiro
em um caixa eletrônico
ix. Objetivo do caso de uso Alterar Senha do Cliente:
1. Este caso de uso descreve os passos necessários para alterar a
senha de um cliente.
x. Objetivo do caso de uso Manter Cliente:
1. Este caso de uso descreve os cenários de inclusão, consulta,
alteração e exclusão de um cliente
xi.
b. Conceito e uso de fluxos de exceção e alternativos
i. Os cenários são descritos através de:
ii. fluxo principal ou fluxo básico: “caminho feliz”, tudo ocorre com
sucesso, e
iii. extensões:
iv. fluxos alternativos: formas alternativas de fazer algum passo e
v. fluxos de exceção: tratamento de erros
vi. sub-fluxos: são usados como sub-rotinas, englobam vários passos que
se repetem várias vezes durante o caso de uso:
vii. Para se executar um sub-fluxo, use o comando: Execute SN, onde
N indica o número do sub-fluxo
viii. Após o término de um sub-fluxo, a execução deve continuar no
passo seguinte ao passo que o executou.
 c. Utilização de regras de negócio
i.
4. DIAGRAMA DE ATIVIDADES
a. Conhecer os principais elementos do diagrama de atividades (vide slide
24)
i.
5. DIAGRAMA DE CLASSES
a. Conceito de visibilidade de propriedades e métodos
i.
b. Tipos de operação
i.
c. Navegabilidade (inclusive saber instanciar)
i.
d. Classe de associação (inclusive saber instanciar)
i.
6. DIAGRAMA DE SEQUÊNCIA
a. Divisão em três camadas
i.
b. Elementos do diagrama de sequência
i.