Download - 6.Modelos de Domínio e Projeto - Parte 2
![Page 1: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/1.jpg)
1
Profª. Juliana Pinheiro CamposE-mail: [email protected] – Programação II
Créditos: Prof. Gustavo Willam Pereira e
Prof. Clayton Vieira Fraga Filho
Princípios de modelagem de Domínio e Projeto(design) de Software - Parte 2
![Page 2: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/2.jpg)
2
Dia g ra m a de C a s o s de Us o
Importante salientar que antes de iniciar a análise de cada caso de uso
em específico, é importante ter a visão geral do sistema que está sendo
proposto, por meio das definições de todos os casos de uso. Para isso,
utiliza-se o diagrama de casos de uso, composto de:
Atores;
Casos de uso;
Relacionamentos:•Inclusão (include)•Extensão (extend)•Generalização (generalization)
![Page 3: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/3.jpg)
3
Dia g ra m a de C a s o s de Us o
O ator em um diagrama de Casos de Uso (DCU) é um PAPEL DESEMPENHADO POR ALGUMA COISA EXTERNA ao sistema (não necessariamente uma pessoa). Outros sistemas (externos) também podem ser atores. Atores são representados pelos bonequinhos.
uc Casosd...
Ator
A representação do Caso de Uso no Diagrama é simples: a elipse representa uma forma que o sistema se comporta do ponto de vista do Ator. O nome do Caso de Uso é uma forma de elucidar esse comportamento do sistema, assim sendo, o nome do caso de uso define o OBJETIVO do Ator, isto é, o que ele quer fazer no sistema.
uc CasosdeUso
Cadastrar clientes
![Page 4: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/4.jpg)
4
Dia g ra m a de C a s o s de Us o
Uma linha conecta atores aos Casos de Uso informando que o sistema permitirá ao Ator usar o Caso de Uso diretamente. Ex: o ator vendedor é quem inicia o caso de uso Cadastrar clientes.
uc CasosdeUso
Vendedor
Cadastrar clientes
Cadastrar produtos
Efetuar vendas
Registrar recebimentos
Gerente
u c : e x e m p lo s is te m a d e v e n d a s
![Page 5: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/5.jpg)
R e la c io na m e nto de Inc lus ã o (<<inc lude >>)
Indica que um caso de uso (base) contém o comportamento definido em outro caso de uso.
É utilizado quando existem comportamentos comuns a vários casos de uso. Esses comportamentos são descritos em um único caso de uso que é incluído em todos os outros que possuem o mesmo comportamento.
Dia g ra m a de C a s o s de Us o :
5
A B
<<include>>
![Page 6: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/6.jpg)
R e la c io na m e nto de Inc lus ã o (<<inc lude >>)
O caso de uso incluído é o b rig a to ria m e nte ins e rido no c a s o de us o b a s e sempre que este é executado.
Um ponto de inclusão (in c lu s io n p o in t) indica o local no caso de uso base ao qual o caso de uso incluído está associado.
B é e s s e nc ia l pa ra o c o m po rta m e nto de A.
Dia g ra m a de C a s o s de Us o :
6
A B
<<include>>
![Page 7: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/7.jpg)
R e la c io na m e nto de Inc lus ã o (<<inc lude >>)
Exemplo:O s ta k e h o ld e r do sistema de pedidos solicitou que exista uma forma de imprimir a segunda via da Venda realizada.
Considerando que o caso de uso “Efetuar Vendas” (já existente) tenha em seu fluxo principal a opção de imprimir a venda que está sendo feita, pode-se extrair o trecho e criar um caso de uso “Imprimir cópia da venda”
Dia g ra m a de C a s o s de Us o
7
Vendedor
Efetuar Vendas
Imprimir cópia da venda
<<include>>
![Page 8: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/8.jpg)
R e la c io na m e nto de E xte ns ã o (<<e x te nd>>)
Início da técnica de Caso de Uso: analistas tinham um problema para acrescentar comportamentos em Casos de Uso que já estavam definidos. Eles imaginavam que seria muito bom se o Caso de Uso definido abrisse uma porta para que os novos comportamentos da evolução do software fossem incorporados. Essa foi a motivação do relacionamento «extend».
Dia g ra m a de C a s o s de Us o
8
![Page 9: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/9.jpg)
R e la c io na m e nto de E xte ns ã o (<<e xte nd>>)
Especifica que o comportamento de um caso de uso incorpora implicitamente o comportamento de outro caso de uso em um ou mais locais específicos chamados de pontos de extensão (e x te n s io n p o in ts ).
Esses pontos são definidos no caso de uso base e a extensão será adicionada a ele sob uma condição.
É utilizado para adicionar condicionalmente comportamentos para um caso de uso existente. Esse relacionamento modela um comportamento opcional do sistema, ou seja, a e xe c uç ã o do c a s o de us o e s te ndido nã o é o b rig a tó ria a o e xe c uta r o c a s o de us o b a s e .
Dia g ra m a de C a s o s de Us o
9
![Page 10: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/10.jpg)
R e la c io na m e nto de E xte ns ã o (<<e xte nd>>)
O relacionamento extend do caso de uso B para o caso de uso A indica que o caso de uso B po de s e r acrescentado para descrever o comportamento de A (não é essencial).
Dia g ra m a de C a s o s de Us o
10
A B
<<extend>>
![Page 11: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/11.jpg)
R e la c io na m e nto de E xte ns ã o (<<e xte nd>>)
Dia g ra m a de C a s o s de Us o
11
Vendedor
Gerente
Efetuar Vendas
Consultar Vendas
Registrar Recebimentos
Cadastrar Clientes
Cadastrar Produtos <<extend>>
<<extend>>
<<extend>>
![Page 12: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/12.jpg)
Com inclusão e extensões
Dia g ra m a de C a s o s de U s o
12
Vendedor
Gerente
Efetuar Vendas
Consultar Vendas
Registrar Recebimentos
Cadastrar Clientes
Cadastrar Produtos <<extend>>
<<extend>>
<<extend>>Imprimir cópia da venda
<<include>>
![Page 13: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/13.jpg)
R e la c io na m e nto de g e ne ra liza ç ã o (<<g e ne ra liza tio n>>)
Entre atores: Os casos de uso de B são também casos de uso de a.
Entre casos de uso: Representa um caso de uso generalizado (pai) que descreve as características compartilhadas por todos os casos de uso especializados (filhos).
Dia g ra m a de C a s o s de Us o
13
Ator A
Ator B
Caso de uso B
Caso de uso A
![Page 14: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/14.jpg)
E x e m plo :
Explique o diagrama de casos de uso abaixo:
Dia g ra m a de C a s o s de Us o
14
Cliente
Fazer Pedido
Fazer Pedido Web Fazer Pedido Telefônico
Cancelar Pedido Procurar Pedido<<include>>
Aplicar Desconto Cliente Especial<<extend>>
![Page 15: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/15.jpg)
15
Aná lis e de C a s o s de Us o (c o ntinua ç ã o )
A identificação de todos os casos de uso devem atender o que os clientes desejam do sistema;
De posse da descrição expandida (narrativa) de cada um deles: Verificar o texto dos casos de uso expandidos. Selecionar termos que representam informação transmitida do
ator para o sistema. Agrupar sinônimos.
![Page 16: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/16.jpg)
C a da s tra r um c lie nteF lux o princ ipa l
1. O cliente chega ao balcão para fazer seu cadastro2. O atendente solicita seu nome e um comprovante de renda (com valor total da renda atualizado)3. O atendente faz a classificação do cliente e atribui um percentual de desconto4. O atendente informa ao cliente que seu registro foi feito com sucesso.
F lux o s de e x c e ç ã oF E 1 - C lie nte nã o le m b ra s ua re nda1. O cliente não tem um comprovante de renda2. O atendente solicita que seja providenciado3. O cliente se dispõe a providenciar4. O registro é suspenso.
F lux o s a lte rna tivo sNão há
C a s o de U s o E s s e nc ia l
C a da s tra r um c lie nteF lux o princ ipa l
1. O cliente chega ao balcão para fazer seu cadastro2. O atendente solicita seu nome e um comprovante de renda (com valor total da renda atualizado)3. O atendente faz a classificação do cliente e atribui um percentual de desconto4. O atendente informa ao cliente que seu registro foi feito com sucesso.
F lux o s de e x c e ç ã oF E 1 - C lie nte nã o le m b ra s ua re nda1. O cliente não tem um comprovante de renda2. O atendente solicita que seja providenciado3. O cliente se dispõe a providenciar4. O registro é suspenso.
F lux o s a lte rna tivo sNão há
Aná lis e de C a s o s de Us o (c o ntinua ç ã o )
![Page 17: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/17.jpg)
Termos identificados na 1º avaliação do analista: Cliente Nome Comprovante de Renda Classificação do cliente Percentual de Desconto
Em um outro momento o analista pode necessitar esclarecer junto ao stakeholder:
Por que é necessário ter um comprovante de renda? O que é classificação do cliente e como é feita a
classificação? Como o percentual de desconto é atribuído?
Ou pode ser que essas informações tenham sido obtidas em uma conversa prévia, que tenha sido inclusive gravada em áudio.
Aná lis e de C a s o s de Us o (c o ntinua ç ã o )
![Page 18: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/18.jpg)
O cliente pode explicar ao analista que (quase nunca de forma tão direta como segue):A empresa mantém um cadastro de clientes, com seu código, nome, renda e tipo (Prata e Ouro). Os clientes podem se cadastrar na empresa e participar de 2 categorias (tipos) distintas.
Clientes tipo Ouro são aqueles com renda superior a 1000 reais. Estes têm 10% de desconto no valor das suas faturas.
Clientes prata são aqueles com renda entre 300 e 1000 reais e tem desconto de 5%.
Os demais clientes cadastrados com renda inferior a 300 reais não tem classificação (tipo) e não possuem desconto;
Como seria a classe cliente???
Aná lis e de C a s o s de Us o (c o ntinua ç ã o )
![Page 19: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/19.jpg)
O analista pode identificar a classe de domínio Cliente, como segue:
class Venda
Cliente
- codCl iente-/ desconto- nom e- renda- tipo
ou
class Venda
Cliente
- codCl iente-/ desconto- nom e- renda
ClienteOuro ClientePrata
ou
class Venda
Cliente
- codCl iente-/ desconto- nom e- renda
Tipo
- desconto- l im i teInferiorRenda- l im i teSuperiorRenda- tipo
1
+tipo 1
Aná lis e de C a s o s de Us o (c o ntinua ç ã o )
![Page 20: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/20.jpg)
Identificar as classes Identificar responsabilidades de cada
classe Identificar relacionamentos Identificar atributos Identificar persistência
20
Aná lis e de C a s o s de Us o (c o ntinua ç ã o )
![Page 21: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/21.jpg)
No primeiro passo de análise, identificaremos três tipos de classes:◦ Fronteira ◦ Entidade◦ Controle
Tais classes são identificadas separadamente para cada caso de uso.
21
Aná lis e de C a s o s de Us o (c o ntinua ç ã o )
![Page 22: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/22.jpg)
C a s o de U s o E s s e nc ia l
Aná lis e de C a s o s de Us o (c o ntinua ç ã o )
C a da s tra r um c lie nteF lux o princ ipa l
1. O cliente chega ao balcão para fazer seu cadastro2. O atendente informa o procedimento e solicita o nome do cliente e um comprovante de renda (com valor total da renda atualizado) [FE1]3. [EV] O atendente registrar o nome e a renda do cliente4. [RS] O sistema exibe a classificação do cliente e o percentual de desconto autorizado.5. O atendente informa ao cliente que seu registro foi feito com sucesso.
F lux o s de e x c e ç ã oF E 1 - C lie nte nã o le m b ra s ua re nda1. O cliente não tem um comprovante de renda2. O atendente solicita que seja providenciado3. O cliente se dispõe a providenciar4. O registro é suspenso.
F lux o s a lte rna tivo sNão há
![Page 23: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/23.jpg)
Que classes preciso criar?◦ uma classe de fronteira para lidar com a interação dos atores
com o sistema.◦ uma classe de entidade para representar as informações
relevantes do cliente.◦ uma classe de controle para gerenciar o fluxo de execução do
caso de uso.
23
Aná lis e de C a s o s de Us o (c o ntinua ç ã o )
![Page 24: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/24.jpg)
Há diferentes opções de visualização dos estereótipos, por exemplo modo texto:
Aná lis e de C a s o s de Us o (c o ntinua ç ã o )
24
TelaCadastroCliente ClienteControladorCliente
TelaCadastroCliente<<boundary>>
Cliente<<entity>>
ControladorCliente<<control>>
![Page 25: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/25.jpg)
Só teremos um cliente? Onde ficarão armazenados os demais? Que classe será responsável por realizar as tarefas de
persistência?
Aná lis e de C a s o s de Us o (c o ntinua ç ã o )
25
TelaCadastroCliente<<boundary>>
Cliente<<entity>>
ControladorCliente<<control>>
![Page 26: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/26.jpg)
Para cada classe de entidade que precise ser persistente, é criada uma nova classe com o estereótipo <<entity collection>> ou <<persistence>>.
Aná lis e de C a s o s de Us o (c o ntinua ç ã o )
26
TelaCadastroCliente<<boundary>>
Cliente<<entity>>
ControladorCliente<<control>>
CadastroClientes<<entity collection>>
Compatível com o vetor de clientes, ou lista de clientes na programação estruturada.
![Page 27: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/27.jpg)
Após a identificação das classes, é necessário descobrir quais são as responsabilidades de cada classe, o que cada uma precisa fazer.
Os diagramas de interação (seqüência e colaboração) são muito úteis nesta tarefa.
Inicialmente deve-se identificar as informações trocadas entre os elementos identificados na categorização BCE.
27
![Page 28: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/28.jpg)
28
: Atendente
: TelaCadastroCliente : ControladorCliente : Cliente
: CadastroClientes
1 : nome, renda()2 : nome, renda()
3 : calcula o % de desconto()
4 : classifica o cliente()
5 : Cria a entidade()
6 : Cadastra a entidade na lista()
![Page 29: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/29.jpg)
29
: Atendente
: TelaCadastroCliente : ControladorCliente : Cliente
: CadastroClientes
1 : nome, renda()2 : nome, renda()
3 : calcula o % de desconto()
4 : classifica o cliente()
5 : Cria a entidade()
6 : Cadastra a entidade na lista()
Região de execução
Linha de vida: o sistema ou o ator
está inativo, mas está instanciado
Instância da classe, ou ator. Pode ter o nome ou o tipo, ou ambos.
Quando a linha está cheia, o sistema está ativo (operando ou aguardando o
resultado de alguma operação)
Estímulo ou mensagem
enviada de um objeto para o
outro, ou executada pelo mesmo objeto
![Page 30: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/30.jpg)
30
: Atendente
: TelaCadastroCliente : ControladorCliente : Cliente
: CadastroClientes
1 : nome, renda()2 : nome, renda()
3 : calcula o % de desconto()
4 : classifica o cliente()
5 : Cria a entidade()
6 : Cadastra a entidade na lista()
Por que existe esse envio de informações? O que TelaCadastroCliente
precisa fazer?O mesmo vale para as
demais
![Page 31: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/31.jpg)
Após identificarmos as responsabilidades (métodos) pelos diagramas de interação, devemos acrescentar os métodos nas classes previamente identificadas (1º passo);
Exemplo das classes com métodos:
31
TelaCadastroCliente<<boundary>>
+cadastrar(nome, renda)
Cliente<<entity>>
+nome+renda+desconto
ControladorCliente<<control>>
+cadastrar(nome, renda)+calculaDesconto()+classificaCliente()
CadastroClientes<<entity collection>>
+clientes
+cadastrar(nome, renda, desconto, tipo)
![Page 32: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/32.jpg)
Também é necessário identificar quais os atributos das classes
Um bom conhecimento do domínio do problema é bastante importante para esta tarefa, principalmente na identificação de atributos das classes de entidade
Nesta etapa ainda não precisamos indicar quais os tipos dos atributos
32
![Page 33: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/33.jpg)
33
![Page 34: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/34.jpg)
E fe tua r L o g in (re s um o do c a s o de us o )◦ Fluxo principal:
1. Usuário informa login e senha
34
Aná lis e de C a s o s de Us o (c o ntinua ç ã o )
![Page 35: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/35.jpg)
Que classes preciso criar?◦ uma classe de fronteira para lidar com a interação dos atores
com o sistema◦ uma classe de entidade para representar as informações
relevantes do aluno◦ uma classe de controle para gerenciar o fluxo de execução do
caso de uso
35
Aná lis e de C a s o s de Us o (c o ntinua ç ã o )
![Page 36: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/36.jpg)
ControladorLogin UsuarioTelaLogin
ControladorLogin<<control>>
Usuario<<entity>>
TelaLogin<<boundary>>
Há diferentes opções de visualização dos estereótipos, por exemplo modo texto:
Aná lis e de C a s o s de Us o (c o ntinua ç ã o )
36
![Page 37: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/37.jpg)
ControladorLogin<<control>>
Usuario<<entity>>
TelaLogin<<boundary>>
Só teremos um usuário? Onde ficarão armazenados os demais usuários?
Que classe será responsável por realizar as tarefas de persistência?
Aná lis e de C a s o s de Us o (c o ntinua ç ã o )
37
![Page 38: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/38.jpg)
Para cada classe de entidade que precise ser persistente, é criada uma nova classe com o estereótipo <<entity collection>> ou <<persistence>>
Aná lis e de C a s o s de Us o (c o ntinua ç ã o )
TelaLogin<<boundary>>
CadastroUsuarios<<entity collection>>
ControladorLogin<<control>>
Usuario<<entity>>
38
![Page 39: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/39.jpg)
Após a identificação das classes, é necessário descobrir quais são as responsabilidades de cada classe, o que cada uma precisa fazer.
Os diagramas de interação (seqüência e colaboração) são muito úteis nesta tarefa.
Inicialmente deve-se identificar as informações trocadas entre os elementos identificados durante e categorizados pela método BCE.
39
![Page 40: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/40.jpg)
Após a identificação das classes, é necessário descobrir quais são as responsabilidades de cada classe, o que cada uma precisa fazer.
Os diagramas de interação (sequência e colaboração) são muito úteis nesta tarefa
40
: usuár io : TelaLogin : Con trolado rLogin : Cadas troA lunos
efetuarLogin(login, senha)
efetua rLogin( log in, se nha)
checar(login, senh a)
regis trarSessao()
![Page 41: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/41.jpg)
Após identificarmos as responsabilidades (métodos) pelos diagramas de interação, devemos acrescentar os métodos nas classes previamente identificadas (1º passo);
Exemplo das classes com métodos:
41
TelaLogin
efetuarLogin(login, senha)
<<boundary>>
CadastroUsuarios
checar(login, senha)
<<entity collection>>
ControladorLogin
efetuarLogin(login, senha)registrarSessao()
<<control>>
Usuario<<entity>>
![Page 42: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/42.jpg)
Também é necessário identificar quais os atributos das classes
Um bom conhecimento do domínio do problema é bastante importante para esta tarefa, principalmente na identificação de atributos das classes de entidade
Nesta etapa ainda não precisamos indicar quais os tipos dos atributos
42
![Page 43: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/43.jpg)
43
![Page 44: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/44.jpg)
Usuariologinsenha
<<entity>>
TelaLogin
efetuarLogin(login, senha)
<<boundary>> ControladorLogin
efetuarLogin(login, senha)registrarSessao()
<<control>>
1*
CadastroUsuarios
checar(login, senha)
<<entity collection>> 1
1
* 1
1
1
44
Conceito do domínio do problema
Classe criada para controlar interaçãoClasse criada para receber a interação
Classe criada para armazenar (servir dedepósito, repositório) de usuários
![Page 45: 6.Modelos de Domínio e Projeto - Parte 2](https://reader034.vdocuments.com.br/reader034/viewer/2022052600/557201df4979599169a283ce/html5/thumbnails/45.jpg)
Em UML, um pacote é definido como: "Um mecanismo de propósito geral para organizar elementos semanticamente relacionados em grupos." Todos os modelos de elementos que são ligados ou referenciados por um pacote são chamados de "Conteúdo do pacote".
Um pacote possui vários modelos de elementos, e isto significa que estes não podem ser incluídos em outros pacotes.
P a c o te s
P a us a pa ra o rg a niza r o s e le m e nto s :
45
InterfaceGrafica Domínio
ControladoraPersistencia
Vejamos um exemplo no StarUML