Princpios de modelagem de Domnio e Projeto(design) de Software - Parte 2

Prof. Juliana Pinheiro Campos E-mail: jupcampos@gmail.com

ENG10082 Programao II Crditos: Prof. Gustavo Willam Pereira e Prof. Clayton Vieira Fraga Filho

Dia g ra m a de C a s o s de U s o
Importante salientar que antes de iniciar a anlise de cada caso de uso em especfico, importante ter a viso geral do sistema que est sendo proposto, por meio das definies de todos os casos de uso. Para isso, utiliza-se o diagrama de casos de uso, composto de: Atores; Casos de uso; Relacionamentos: Incluso (include) Extenso (extend) Generalizao (generalization)
2

Dia g ra m a de C a s o s de U s o
O ator em um diagrama de Casos de Uso (DCU) um PAPEL DESEMPENHADO POR ALGUMA COISA EXTERNA ao sistema (no necessariamente uma pessoa). Outros sistemas (externos) tambm podem ser atores. Atores so representados pelos bonequinhos. A representao 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 Casosd...

Ator

uc CasosdeUso

Cadastrar clientes

Dia g ra m a de C a s o s de U s 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

u c : e x e m p lo s is te m a d e ve ndas
Cadastrar clientes

Cadastrar produtos Vendedor

Efetuar v endas

Gerente

Registrar recebimentos

Dia g ra m a de C a s o s de U s o :
R e la c io n a m e n to de In c lu s o (<<in c lu de >>) Indica que um caso de uso (base) contm o comportamento definido em outro caso de uso. utilizado quando existem comportamentos comuns a vrios casos de uso. Esses comportamentos so descritos em um nico caso de uso que includo em todos os outros que possuem o mesmo comportamento.

<<include>> A B

Dia g ra m a de C a s o s de U s o :
R e la c io n a m e n to de In c lu s o (<<in c lu de >>)

<<include>> A B

O caso de uso includo o b rig a to ria m e n te in s e rido n o c a s o de u s o b a s e sempre que este executado. Um ponto de incluso (in c lu s io n p o in t) indica o local no caso de uso base ao qual o caso de uso includo est associado. B e s s e n c ia l pa ra o c o m po rta m e n to de A .
6

Dia g ra m a de C a s o s de U s o
R e la c io n a m e n to de In c lu s o (<<in c lu de >>) 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 opo de imprimir a venda que est sendo feita, podese extrair o trecho e criar um caso de uso Imprimir cpia da venda

Efetuar Vendas Vendedor <<include>>

Imprimir cpia da venda

Dia g ra m a de C a s o s de U s o
R e la c io n a m e n to de E x te n s o (<<e x te n d>>) Incio da tcnica 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 evoluo do software fossem incorporados. Essa foi a motivao do relacionamento extend.

Dia g ra m a de C a s o s de U s o
R e la c io n a m e n to de E x te n s o (<<e x te n d>>) Especifica que o comportamento de um caso de uso incorpora implicitamente o comportamento de outro caso de uso em um ou mais locais especficos chamados de pontos de extenso (e x te n s io n p o in ts ). Esses pontos so definidos no caso de uso base e a extenso ser adicionada a ele sob uma condio. utilizado para adicionar condicionalmente comportamentos para um caso de uso existente. Esse relacionamento modela um comportamento opcional do sistema, ou seja, a e x e c u o do c a s o de u s o e s te n dido n o o b rig a t ria a o e x e c u ta r o c a s o de u s o b a s e .

Dia g ra m a de C a s o s de U s o
R e la c io n a m e n to de E x te n s o (<<e x te n d>>) 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 (no essencial).

A <<extend>>

10

Dia g ra m a de C a s o s de U s o
R e la c io n a m e n to de E x te n s o (<<e x te n d>>)
Cadastrar Clientes

<<extend>> Cadastrar Produtos <<extend>>

Vendedor Efetuar Vendas

Consultar Vendas <<extend>>

Registrar Recebimentos Gerente

11

Dia g ra m a de C a s o s de U s o
Com incluso e extenses
Cadastrar Clientes

<<extend>> Cadastrar Produtos

<<extend>>

Vendedor Efetuar Vendas <<include>> Consultar Vendas <<extend>> Imprimir cpia da venda Registrar Recebimentos Gerente

12

Dia g ra m a de C a s o s de U s o
R e la c io n a m e n to de g e n e ra liza o (<<g e n e ra liz a tio n >>) Entre atores: Os casos de uso de B so tambm casos de uso de a.

Ator B

Ator A

Entre casos de uso: Representa um caso de uso generalizado (pai) que descreve as caractersticas compartilhadas por todos os casos de uso especializados (filhos).
Caso de uso A

Caso de uso B

13

Dia g ra m a de C a s o s de U s o
E x e m plo : Explique o diagrama de casos de uso abaixo:

Fazer Pedido

<<extend>> Aplicar Desconto Cliente Especial

Cliente

Fazer Pedido Web

Fazer Pedido Telefnico

Cancelar Pedido

<<include>> Procurar Pedido

14

A n lis e de C a s o s de U s o (c o n tin u a o )
A identificao de todos os casos de uso devem atender o que os clientes desejam do sistema; De posse da descrio expandida (narrativa) de cada um deles: Verificar o texto dos casos de uso expandidos. Selecionar termos que representam informao transmitida do ator para o sistema. Agrupar sinnimos.

15

A n lis e de C a s o s de U s o (c o n tin u a o )
C a s o de U s o E s s e n c ia l
C a da s tra r u m c lie n te F lu x o prin c ipa l 1. O cliente chega ao balco para fazer seu cadastro 2. O atendente solicita seu nome e um comprovante de renda (com valor total da renda atualizado) 3. O atendente faz a classificao do cliente e atribui um percentual de desconto 4. O atendente informa ao cliente que seu registro foi feito com sucesso. F lu x o s de e x c e o F E 1 - C lie n te n o le m b ra s u a re n da 1. O cliente no tem um comprovante de renda 2. O atendente solicita que seja providenciado 3. O cliente se dispe a providenciar 4. O registro suspenso. F lu x o s a lte rn a tiv o s No h

A n lis e de C a s o s de U s o (c o n tin u a o )
Termos identificados na 1 avaliao do analista: Cliente Nome Comprovante de Renda Classificao do cliente Percentual de Desconto Em um outro momento o analista pode necessitar esclarecer junto ao stakeholder: Por que necessrio ter um comprovante de renda? O que classificao do cliente e como feita a classificao? Como o percentual de desconto atribudo? Ou pode ser que essas informaes tenham sido obtidas em uma conversa prvia, que tenha sido inclusive gravada em udio.

A n lis e de C a s o s de U s o (c o n tin u a o )
O cliente pode explicar ao analista que (quase nunca de forma to direta como segue): A empresa mantm um cadastro de clientes, com seu cdigo, nome, renda e tipo (Prata e Ouro). Os clientes podem se cadastrar na empresa e participar de 2 categorias (tipos) distintas. Clientes tipo Ouro so aqueles com renda superior a 1000 reais. Estes tm 10% de desconto no valor das suas faturas. Clientes prata so aqueles com renda entre 300 e 1000 reais e tem desconto de 5%. Os demais clientes cadastrados com renda inferior a 300 reais no tem classificao (tipo) e no possuem desconto; Como seria a classe cliente???

A n lis e de C a s o s de U s o (c o n tin u a o )
O analista pode identificar a classe de domnio Cliente, como segue:
class Venda
class Venda

class Venda
-/ -

Cliente codCli ente desconto nom e renda

Cliente -/ cod Cl ie n te de sco nto no m e re nd a 1

Cliente -/ cod Cl i en te d escon to n om e ren da tipo

ou
ClienteOuro ClientePrata

ou

+ti p o

Tipo descon to li m i teIn feri orRe nd a li m i teSu pe ri orRen d a ti po

A n lis e de C a s o s de U s o (c o n tin u a o )

Identificar as classes Identificar responsabilidades de cada classe Identificar relacionamentos Identificar atributos Identificar persistncia

20

A n lis e de C a s o s de U s o (c o n tin u a o )
No primeiro passo de anlise, identificaremos trs tipos de classes:
Fronteira Entidade Controle

Tais classes so identificadas separadamente para cada caso de uso.

21

A n lis e de C a s o s de U s o (c o n tin u a o )
C a s o de U s o E s s e n c ia l
C a da s tra r u m c lie n te F lu x o prin c ipa l 1. O cliente chega ao balco para fazer seu cadastro 2. 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 cliente 4. [RS] O sistema exibe a classificao do cliente e o percentual de desconto autorizado. 5. O atendente informa ao cliente que seu registro foi feito com sucesso. F lu x o s de e x c e o F E 1 - C lie n te n o le m b ra s u a re n da 1. O cliente no tem um comprovante de renda 2. O atendente solicita que seja providenciado 3. O cliente se dispe a providenciar 4. O registro suspenso. F lu x o s a lte rn a tiv o s No h

A n lis e de C a s o s de U s o (c o n tin u a o )

Que classes preciso criar?

uma classe de fronteira para lidar com a interao dos atores com o sistema. uma classe de entidade para representar as informaes relevantes do cliente. uma classe de controle para gerenciar o fluxo de execuo do caso de uso.

23

A n lis e de C a s o s de U s o (c o n tin u a o )

TelaCadastroCliente

ControladorCliente

Cliente

H diferentes opes de visualizao dos esteretipos, por exemplo modo texto:

<<boundary>> TelaCadastroCliente

<<control>> ControladorCliente

<<entity>> Cliente

24

A n lis e de C a s o s de U s o (c o n tin u a o )

<<boundary>> TelaCadastroCliente

<<control>> ControladorCliente

<<entity>> Cliente

S teremos um cliente? Onde ficaro armazenados os demais? Que classe ser responsvel por realizar as tarefas de persistncia?

25

A n lis e de C a s o s de U s o (c o n tin u a o )
Para cada classe de entidade que precise ser persistente, criada uma nova classe com o esteretipo <<entity collection>> ou <<persistence>>.
<<boundary>> TelaCadastroCliente <<control>> ControladorCliente <<entity>> Cliente

<<entity collection>> CadastroClientes

Compatvel com o vetor de clientes, ou lista de clientes na programao estruturada.

26

Aps a identificao das classes, necessrio descobrir quais so as responsabilidades de cada classe, o que cada uma precisa fazer. Os diagramas de interao (seqncia e colaborao) so muito teis nesta tarefa. Inicialmente deve-se identificar as informaes trocadas entre os elementos identificados na categorizao BCE.

27

: CadastroClientes : TelaCadastroCliente : Atendente 1 : nome, renda() 2 : nome, renda() 3 : calcula o % de desconto() : ControladorCliente : Cliente

4 : classifica o cliente()

5 : Cria a entidade()

6 : Cadastra a entidade na lista()

28

Instncia da classe, ou ator. Pode ter o nome ou o tipo, ou ambos.

: CadastroClientes : TelaCadastroCliente : Atendente 1 : nome, renda() 2 : nome, renda() 3 : calcula o % de desconto() : ControladorCliente : Cliente

Regio de execuo

4 : classifica o cliente()

Estmulo ou mensagem enviada de um objeto para o outro, ou executada pelo mesmo objeto

5 : Cria a entidade()

6 : Cadastra a entidade na lista()

Linha de vida: o sistema ou o ator est inativo, mas est instanciado

Quando a linha est cheia, o sistema est ativo (operando ou aguardando o resultado de alguma operao)

29

: CadastroClientes : TelaCadastroCliente : Atendente 1 : nome, renda() 2 : nome, renda() 3 : calcula o % de desconto() : ControladorCliente : Cliente

4 : classifica o cliente()

Por que existe esse envio de informaes? O que TelaCadastroCliente precisa fazer? O mesmo vale para as demais

5 : Cria a entidade()

6 : Cadastra a entidade na lista()

30

Aps identificarmos as responsabilidades (mtodos) pelos diagramas de interao, devemos acrescentar os mtodos nas classes previamente identificadas (1 passo); Exemplo das classes com mtodos:
<<boundary>> TelaCadastroCliente +cadastrar(nome, renda) <<control>> ControladorCliente +cadastrar(nome, renda) +calculaDesconto() +classificaCliente()

<<entity collection>> CadastroClientes +clientes +cadastrar(nome, renda, desconto, tipo)

<<entity>> Cliente +nome +renda +desconto

31

Tambm necessrio identificar quais os atributos das classes Um bom conhecimento do domnio do problema bastante importante para esta tarefa, principalmente na identificao de atributos das classes de entidade Nesta etapa ainda no precisamos indicar quais os tipos dos atributos

32

33

A n lis e de C a s o s de U s o (c o n tin u a o )

E fe tu a r L o g in (re s u m o do c a s o de u s o )
Fluxo principal:
1. Usurio informa login e senha

34

A n lis e de C a s o s de U s o (c o n tin u a o )
Que classes preciso criar?

uma classe de fronteira para lidar com a interao dos atores com o sistema uma classe de entidade para representar as informaes relevantes do aluno uma classe de controle para gerenciar o fluxo de execuo do caso de uso

35

A n lis e de C a s o s de U s o (c o n tin u a o )

TelaLogin

ControladorLogin

Us uario

H diferentes opes de visualizao dos esteretipos, por exemplo modo texto:

< < boundary > > TelaLogin < < c ontrol> > ControladorLogin < < entity > > Us uario

36

A n lis e de C a s o s de U s o (c o n tin u a o )
< < boundary > > TelaLogin < < c ontrol> > ControladorLogin < < entity > > Us uario

S teremos um usurio? Onde ficaro armazenados os demais usurios? Que classe ser responsvel por realizar as tarefas de persistncia?

37

A n lis e de C a s o s de U s o (c o n tin u a o )
Para cada classe de entidade que precise ser persistente, criada uma nova classe com o esteretipo <<entity collection>> ou <<persistence>>

<<boundary>> TelaLogin

<<control>> ControladorLogin

<<entity collection>> CadastroUsuarios

<<entity>> Usuario

38

Aps a identificao das classes, necessrio descobrir quais so as responsabilidades de cada classe, o que cada uma precisa fazer. Os diagramas de interao (seqncia e colaborao) so muito teis nesta tarefa. Inicialmente deve-se identificar as informaes trocadas entre os elementos identificados durante e categorizados pela mtodo BCE.

39

Aps a identificao das classes, necessrio descobrir quais so as responsabilidades de cada classe, o que cada uma precisa fazer. Os diagramas de interao (sequncia e colaborao) so muito teis nesta tarefa
: usur io : TelaLogin : Con tr olado rLogin : Cadas troA lunos

efetuarLogin(login, s enha) efetua rLogin( log in, s e nha) c hec ar(login, s enh a)

regis trarS es s ao()

40

Aps identificarmos as responsabilidades (mtodos) pelos diagramas de interao, devemos acrescentar os mtodos nas classes previamente identificadas (1 passo); Exemplo das classes com mtodos:
<<boundary>> TelaLogin efetuarLogin(login, senha) <<control>> ControladorLogin efetuarLogin(login, senha) registrarSessao()

<<entity collection>> CadastroUsuarios checar(login, senha)

<<entity>> Usuario

41

Tambm necessrio identificar quais os atributos das classes Um bom conhecimento do domnio do problema bastante importante para esta tarefa, principalmente na identificao de atributos das classes de entidade Nesta etapa ainda no precisamos indicar quais os tipos dos atributos

42

43

Classe criada para receber a interao

<<boundary>> TelaLogin efetuarLogin(login, senha) * 1 1

Classe criada para controlar interao

<<control>> ControladorLogin efetuarLogin(login, senha) registrarSessao()

<<entity collection>> CadastroUsuarios checar(login, senha)

<<entity>> Usuario login senha

Classe criada para armazenar (servir de depsito, repositrio) de usurios Conceito do domnio do problema

44

P a u s a pa ra o rg a n iza r o s e le m e n t o s :
P a c ote s
Em UML, um pacote definido como: "Um mecanismo de propsito geral para organizar elementos semanticamente relacionados em grupos." Todos os modelos de elementos que so ligados ou referenciados por um pacote so chamados de "Contedo do pacote". Um pacote possui vrios modelos de elementos, e isto significa que estes no podem ser includos em outros pacotes.
InterfaceGrafica Domnio

Vejamos um exemplo no StarUML

Controladora

Persistencia

45