Revisão AV2
59 pág.

Revisão AV2


DisciplinaModelagem de Sistemas5.052 materiais86.350 seguidores
Pré-visualização3 páginas
\u201ctodo\u201d e têm o seu tempo de vida coincidente 
com o dele
\u2013 Quando o \u201ctodo\u201d morre todas as suas \u201cpartes\u201d
também morrem
TecladoNotebook
FrameWindow
1 1
1 0..*
1..* 0..*
errado
Diagrama de Classes - Relacionamentos
GENERALIZAÇÃO / ESPECIALIZAÇÃO
Generalização representa os vários tipos de um objeto 
em uma única classe.
Diagrama de Classes - Relacionamentos
Dependência:
\u2022 Representa que a alteração de um objeto (o objeto 
indepedendente) pode afetar outro objeto (o objeto 
dependente)
Ex:
\u2013 Obs:
\u2022 A classe cliente depende de algum serviço da classe 
fornecedor
\u2022 A mudança de estado do fornecedor afeta o objeto cliente 
\u2022 A classe cliente não declara nos seus atributos um objeto do 
tipo fornecedor
\u2022 Fornecedor é recebido por parâmetro de método
cliente fornecedor
Diagrama de Classes - Relacionamentos
Simbologia
AUTO ASSOCIAÇÃO
Define quando um objeto de uma classe está relacionado 
com outro objeto da mesma classe para atender a algum 
comportamento. A multiplicidade é estabelecida 
normalmente.
Diagrama de Classes - Relacionamentos
DESCRIÇÃO DE CASO DE USO
\ufffd É uma descrição narrativa de uma sequência de eventos que 
ocorre quando um ator (agente externo) usa um sistema para 
realizar uma tarefa[Jacobson 92]
Em outras palavras:
É a representação textual dos casos de uso
\ufffd Utilizada para complementar o modelo de casos de uso
\ufffd Define o que o sistema faz quando o caso de uso é realizado
\ufffd Ajuda a validar se a compreensão dos requisitos foi plena
\ufffd Registra a funcionalidade lógica e é o documento 
comprobatório do levantamento dos requisitos
DESCRIÇÃO DE CASO DE USO
Formato de Documentação de Casos de Uso
(Modelo mais usado)
\u2022 Nome do Caso de Uso
\u2022 Breve descrição
\u2022 Ator (principal)
\u2022 Pré-Condições
\u2022 Pós-Condições
\u2022 Fluxo de eventos:
\u2013 Fluxo de evento principal
\u2013 Fluxos secundários: alternativos e de exceção
DESCRIÇÃO DE CASO DE USO
A descrição poderá ser desenvolvida de duas formas: 
Descrição não Expandida e Descrição Expandida.
DESCRIÇÃO DE CASO DE USO
Descrição não Expandida prevê a apresentação sucinta dos 
procedimentos, como um pequeno relato apresentando os 
objetivos a serem atingidos. Deve ser utilizada quando o Caso 
de Uso for de conhecimento completo de todos, não possuir 
exceções ou, utilizar mecanismos de outro caso de uso.
DESCRIÇÃO DE CASO DE USO
Descrição Expandida prevê a apresentação detalhada dos 
procedimentos, apresentando os objetivos a serem atingidos 
passo-a-passo e com referência a responsabilidade se ator ou 
sistema.
Devemos considerar a descrição em duas partes: Fluxo Normal 
e Fluxo Alternativo.
DIAGRAMAS DE INTERAÇÃO
\ufffd Como as operações do sistema são
executadas internamente?
\ufffd A que classes estas operações internas
pertencem?
\ufffd Quais objetos participam da realização 
de um caso de uso ou de uma
operação do software?
Os modelos de análise não respondem a algumas perguntas:
O modelo de classes (modelo conceitual) não mostra:
\ufffd De que forma os objetos colaboram para que um determinado 
caso de uso seja realizado?
\ufffd Em que ordem as mensagens são enviadas durante esta 
realização?
\ufffd Que informações precisam ser enviadas em uma mensagem 
de um objeto a outro?
\ufffd Será que há responsabilidades ou mesmo classes que ainda 
não foram identificadas?
Pedido
- dataPagamento : Date[0..1]
# éPréPago : boolean[1] = true
+ itensDeLinha : itenDeLinha [*] {ordenada}
- numeroPedidos : int
+ pagar (valor : double)
- calcularTotal() : double
Diagramas de interação representam como o sistema age
internamente para que um ator atinja seu objetivo na 
realização de um caso de uso. A modelagem de um SOO 
normalmente contém diversos diagramas de interação. O 
conjunto de todos os diagramas de interação de um sistema 
constitui o seu modelo de interações. (Bezerra, E. seg.edição)
\ufffd Para responder às questões anteriores, omodelo de interações
deve ser criado.
\ufffd Esse modelo representa como os objetos interagem via 
mensagens para a execução de cenários dos casos de uso do 
sistema.
DIAGRAMAS DE INTERAÇÃO
Objetivos do modelo de interação
1 - Obter informações adicionais para completar e aprimorar 
outros modelos (principalmente o modelo de classes)
\ufffd Quais as operações de uma classe?
\ufffd Quais os objetos participantes da realização de um caso 
de uso (ou cenário deste)?
\ufffd Para cada operação, qual a sua assinatura?
\ufffd Uma classe precisa de mais atributos?
2 - Fornecer aos programadores uma visão detalhada dos 
objetos e mensagens envolvidos na realização dos casos de 
uso.
DIAGRAMAS DE INTERAÇÃO
DIAGRAMAS DE INTERAÇÃO
Conceitos
\ufffd O Diagrama de Interação apresenta a relação entre os objetos 
e a troca de mensagens que são necessárias para efetivar a 
realização do comportamento.
\ufffd O Diagrama de Interação representa um único caso de uso e 
deve ser usado quando se deseja visualizar os 
comportamentos utilizados pelos vários objetos dentro do 
caso de uso.
\ufffd Diagramas de interação são apresentados sob duas formas na 
UML através do Diagrama de Sequência e Diagrama de 
Comunicação (Colaboração).
Mensagem
\ufffd O conceito básico da interação entre objetos é a mensagem.
\ufffd Um sistema OO é uma rede de objetos que trocam mensagens.
\u2013 Funcionalidades são realizadas pelos objetos, que só podem 
interagir através de mensagens.
\u2013 Um objeto envia uma mensagem para outro objeto quando 
o primeiro deseja que o segundo realize alguma tarefa.
\ufffd Na construção de diagramas de interação, mensagens de um 
objeto a outro implicam em operações que classes devem ter. 
Uma mensagem representa a requisição de um objeto remetente
a um objeto receptor para que este último execute alguma 
operação definida para sua classe. Essa mensagem deve conter 
informação suficiente para que a operação do objeto receptor 
possa ser executada.
Tipos de diagramas de Interação
1 - Diagrama de Sequência
\ufffd Foco nas mensagens enviadas no decorrer do 
tempo.
\ufffd Se a ênfase do que se quer modelar é o decorrer do 
tempo
\ufffd A visualização fica dificultada conforme o número de 
objetos cresce (disposição em uma dimensão).
Tipos de diagramas de Interação
1 - Diagrama de Comunicação
\ufffd Foco nas mensagens enviadas entre objetos que 
estão relacionados
\ufffd Se a ênfase é o contexto do sistema
\ufffd Exibe mensagens enfatizando relacionamentos.
\ufffd Melhor utilização do espaço (disposição em duas 
dimensões)
DIAGRAMA DE SEQUÊNCIA - SIMBOLOGIA
GERENTE
:nome objeto
:nome objeto
Ator
Objeto
Linha da vida
DIAGRAMAS DE INTERAÇÃO
:nome objeto :nome objeto
Lista de 
objetos
DIAGRAMA DE SEQUÊNCIA - SIMBOLOGIA
Estacionamento Estácio - DSS
Representa a ligação entre o 
mundo externo e o sistema
:objeto1 :objeto2
:objeto1 :objeto2
mensagem() 
retorno() 
mensagem() 
Ligação
Mensagem
DIAGRAMA DE COMUNICAÇÃO \u2013 SIMBOLOGIA
DIAGRAMAS DE INTERAÇÃO
Representa a ligação entre os objetos
Diagrama de Comunicação
Representa troca de mensagens sem sequência.
:formulário
escolherHospede()
escolherProcedencia()
InformarDiasPermanencia()
clicaCONFIRMA()
:Hóspedes
4: *ler()
listaHospedes
1: apresentaInformações()
2: apresentaDataChegada()
3: calculaDataSaída ()
5: *ler()
listaProcedência
:Procedência
6: [disponíveis]*ler()
listaQuartos
:Quartos
7: Incluir()
:Hospedagem
8: <include>
alocarQuarto
9: <include>
abrirCCorrente
DIAGRAMA DE MÁQUINAS DE ESTADO
\ufffd Representa o comportamento de um objeto individual
\ufffd Complementa a descrição de um Caso de Uso e se apoia
no Diagrama de Classes.
\ufffd Mostra todos os estados possíveis que objetos de uma 
certa classe podem assumir e também quais são os eventos 
do sistemas que provocam tais mudanças.