1601PAPSUML-Cap05

Princpios de Anlise
e Projeto de Sistemas
com UML
2 edio
Eduardo Bezerra
Editora Campus/Elsevier
Captulo 5
Modelagem de Classes de Anlise
O engenheiro de software amador est sempre procura da
mgica, de algum mtodo sensacional ou ferramenta cuja
aplicao promete tornar trivial o desenvolvimento de software.
uma caracterstica do engenheiro de software profissional
saber que tal panacia no existe -Grady Booch
Princpios de Anlise e Projeto de Sistemas com UML - 2 edio
3
Tpicos
Introduo
Diagrama de classes
Diagrama de objetos
Tcnicas para identificao de classes
Construo do modelo de classes
Modelo de classes no processo de desenvolvimento
4
Introduo
As funcionalidades de um SSOO so realizadas internamente atravs de
colaboraes entre objetos.
Externamente, os atores visualizam resultados de clculos, relatrios
produzidos, confirmaes de requisies realizadas, etc.
Internamente, os objetos colaboram uns com os outros para produzir os
resultados.
Essa colaborao pode ser vista sob o aspecto dinmico e sob o aspecto
estrutural esttico.
O modelo de objetos representa o aspecto estrutural e esttico dos objetos
que compem um SSOO.
Dois diagramas da UML so usados na construo do modelo de objetos:
diagrama de classes
diagrama de objetos
5
Na prtica o diagrama de classes bem mais utilizado que o
diagrama de objetos.
Tanto que o modelo de objetos tambm conhecido como modelo de
classes.
Esse modelo evolui durante o desenvolvimento do SSOO.
medida que o SSOO desenvolvido, o modelo de objetos
incrementado com novos detalhes.
H trs nveis sucessivos de detalhamento:
Anlise Especificao (Projeto) Implementao.
Introduo
6
Objetivo da Modelagem de Classes
O objetivo da modelagem de classes de anlise
prover respostas para as seguintes perguntas:
Por definio um sistema OO composto de objetos...em
um nvel alto de abstrao, que objetos constituem o
sistema em questo?
Quais so as classes candidatas?
Como as classes do sistema esto relacionadas entre si?
Quais so as responsabilidades de cada classe?
7
Representa termos do domnio do negcio.
idias, coisas, e conceitos no mundo real.
Objetivo: descrever o problema representado pelo sistema a ser
desenvolvido, sem considerar caractersticas da soluo a ser utilizada.
um dicionrio visual de conceitos e informaes relevantes ao sistema
sendo desenvolvido.
Duas etapas:
modelo conceitual (modelo de domnio).
modelo da aplicao.
Elementos de notao do diagrama de classes normalmente usados na
construo do modelo de anlise:
classes e atributos; associaes, composies e agregaes (com seus adornos);
classes de associao; generalizaes (herana).
Modelo de Classes de Anlise
8
Modelo de Anlise: Foco no Problema
O modelo de anlise no representa detalhes da soluo do
problema.
Embora este sirva de ponto de partida para uma posterior definio das
classes de software (especificao).
Venda
data
hora
Venda
-data:Date
-hora:Time
+getTotal():Currency
Pagamento
quantia
1 1 Pago-por
Pagamento
-quantia: Currency
+getValor(): Currency
1 1 Pago-por
Projeto (Especificao)
Anlise
5.2 Diagrama de classes
10
Classes
Uma classe descreve esses objetos atravs de atributos e
operaes.
Atributos correspondem s informaes que um objeto armazena.
Operaes correspondem s aes que um objeto sabe realizar.
Notao na UML: caixa com no mximo trs
compartimentos exibidos.
Detalhamento utilizado depende do estgio de desenvolvimento e do
nvel de abstrao desejado.
11
Exemplo (classe ContaBancria)
12
Associaes
Para representar o fato de que objetos podem se relacionar uns
com os outros, utilizamos associaes.
Uma associao representa relacionamentos (ligaes) que so
formados entre objetos durante a execuo do sistema.
Note que, embora as associaes sejam representadas entre
classes do diagrama, tais associaes representam ligaes
possveis entre os objetos das classes envolvidas.
13
Notao para Associaes
Na UML associaes so representadas por uma linha que liga
as classes cujos objetos se relacionam.
Exemplos:
14
Multiplicidades
Representam a informao dos limites inferior e superior da
quantidade de objetos aos quais outro objeto pode se associar.
Cada associao em um diagrama de classes possui duas
multiplicidades, uma em cada extremo da linha de associao.
Nome Simbologia na UML
Apenas Um 1..1 (ou 1)
Zero ou Muitos 0..* (ou *)
Um ou Muitos 1..*
Zero ou Um 0..1
Intervalo Especfico l
i
..l
s
15
Exemplos (multiplicidade)
Exemplo
Pode haver um cliente que esteja associado a vrios pedidos.
Pode haver um cliente que no esteja associado a pedido algum.
Um pedido est associado a um, e somente um, cliente.
Exemplo
Uma corrida est associada a, no mnimo, dois velocistas
Uma corrida est associada a, no mximo, seis velocistas.
Um velocista pode estar associado a vrias corridas.
16
Conectividade
A conectividade corresponde ao tipo de associao entre duas
classes: muitos para muitos, um para muitos e um para
um.
A conectividade da associao entre duas classes depende dos
smbolos de multiplicidade que so utilizados na associao.
Conectividade Em um extremo No outro extremo
Um para um 0..1
1
0..1
1
Um para muitos 0..1
1
*
1..*
0..*
Muitos para muitos *
1..*
0..*
*
1..*
0..*
17
Exemplo (conectividade)
18
Participao
Uma caracterstica de uma associao que indica a necessidade
(ou no) da existncia desta associao entre objetos.
A participao pode ser obrigatria ou opcional.
Se o valor mnimo da multiplicidade de uma associao igual a 1
(um), significa que a participao obrigatria
Caso contrrio, a participao opcional.
19
Acessrios para Associaes
Para melhor esclarecer o significado de uma associao no
diagrama de classes, a UML define trs recursos de notao:
Nome da associao: fornece algum significado semntico a mesma.
Direo de leitura: indica como a associao deve ser lida
Papel: para representar um papel especfico em uma associao.
20
Classe associativa
uma classe que est ligada a uma associao, em vez de estar
ligada a outras classes.
normalmente necessria quando duas ou mais classes esto
associadas, e necessrio manter informaes sobre esta
associao.
Uma classe associativa pode estar ligada a associaes de
qualquer tipo de conectividade.
Sinnimo: classe de associao
21
Notao para Classes Associativas
Notao semelhante utilizada para classes ordinrias. A
diferena que esta classe ligada a uma associao por uma
linha tracejada.
Exemplo: para cada par de objetos [pessoa, empresa], h duas
informaes associadas: salrio e data de contratao.
22
Associaes n-rias
Define-se o grau de uma associao como a quantidade de
classes envolvidas na mesma.
Na notao da UML, as linhas de uma associao n-ria se
interceptam em um losango.
Na grande maioria dos casos prticos de modelagem, as
associaes normalmente so binrias.
Quando o grau de uma associao igual a trs, dizemos que a
mesma ternria.
Uma associao ternria so uma caso mais comum (menos raro) de
associao n-ria (n = 3).
23
Exemplo (associao ternria)
Na notao da UML, as linhas de uma associao n-ria se
interceptam em um losango nomeado.
Notao similar ao do Modelo de Entidades e Relacionamentos
24
Associaes reflexivas
Tipo especial de associao que representa ligaes entre
objetos que pertencem a uma mesma classe.
No indica que um objeto se associa a ele prprio.
Quando se usa associaes reflexivas, a definio de papis
importante para evitar ambigidades na leitura da associao.
Cada objeto tem um papel distinto na associao.
25
Agregaes e Composies
A semntica de uma associao corresponde ao seu
significado, ou seja, natureza conceitual da relao que existe
entre os objetos que participam daquela associao.
De todos os significados diferentes que uma associao pode
ter, h uma categoria especial de significados, que representa
relaes todo-parte.
Uma relao todo-parte entre dois objetos indica que um dos
objetos est contido no outro. Podemos tambm dizer que um
objeto contm o outro.
A UML define dois tipos de relacionamentos todo-parte, a
agregao e a composio.
26
Algumas particularidades das agregaes/composies:
so assimtricas, no sentido de que, se um objeto A parte de um
objeto B, o objeto B no pode ser parte do objeto A.
propagam comportamento, no sentido de que um comportamento que
se aplica a um todo automaticamente se aplica s suas partes.
as partes so normalmente criadas e destrudas pelo todo. Na classe do
objeto todo, so definidas operaes para adicionar e remover as partes.
Se uma das perguntas a seguir for respondida com um sim,
provavelmente h uma agregao onde X todo e Y parte.
X tem um ou mais Y?
Y parte de X?
27
Exemplos
28
As diferenas entre a agregao e composio no so bem
definidas. A seguir, as diferenas mais marcantes entre elas.
Destruio de objetos
Na agregao, a destruio de um objeto todo no implica
necessariamente na destruio do objeto parte.
Pertinncia
Na composio, os objetos parte pertencem a um nico todo.
Por essa razo, a composio tambm denominada agregao no-
compartilhada.
Em uma agregao, pode ser que um mesmo objeto participe como
componente de vrios outros objetos.
Por essa razo, a agregao tambm denominada agregao
compartilhada.
29
Restries sobre associaes
Restries OCL podem ser adicionadas sobre uma associao
para adicionar a ela mais semntica.
Duas das restries sobre associaes predefinidas pela UML so
subset e xor.
O modelador tambm pode definir suas prprias restries em OCL.
30
Restries sobre associaes (cont)
31
Restries sobre associaes (cont)
32
Generalizaes e Especializaes
O modelador tambm pode representar relacionamentos entre
classes.
Esses denotam relaes de generalidade ou especificidade entre as
classes envolvidas.
Exemplo: o conceito mamfero mais genrico que o conceito ser
humano.
Exemplo: o conceito carro mais especfico que o conceito veculo.
Esse o chamado relacionamento de herana.
relacionamento de generalizao/especializao
relacionamento de gen/espec
33
Generalizaes e Especializaes
Terminologia
subclasse X superclasse.
supertipo X subtipo.
classe base X classe herdeira.
classe de especializao X classe de generalizao.
ancestral e descendente (herana em vrios nveis)
Notao definida pela UML
34
Semntica da Herana
Subclasses herdam as caractersticas de sua superclasse
como se as caractersticas da superclasse estivessem definidas
tambm nas suas subclasses
Alm disso, essa herana transitiva e anti-simtrica
Note a diferena semntica entre a herana e a associao.
A primeira trata de um relacionamento entre classes, enquanto que a
segunda representa relacionamentos entre instncias de classes.
Na associao, objetos especficos de uma classe se associam entre si
ou com objetos especficos de outras classes.
Exemplo:
Herana: Gerentes so tipos especiais de funcionrios.
Associao: Gerentes chefiam departamentos.
35
Herana de Associaes
No somente atributos e operaes, mas tambm associaes
so herdadas pelas subclasses.
No exemplo abaixo, cada subclasse est associada a Pedido,
por herana.
36
Propriedades da Herana
Transitividade: uma classe em uma hierarquia herda
propriedades e relacionamentos de todos os seus ancestrais.
Ou seja, a herana pode ser aplicada em vrios nveis, dando origem a
hierarquia de generalizao.
uma classe que herda propriedades de uma outra classe pode ela prpria
servir como superclasse.
Assimetria: dadas duas classes A e B, se A for uma
generalizao de B, ento B no pode ser uma generalizao
de A.
Ou seja, no pode haver ciclos em uma hierarquia de generalizao.
37
Propriedades da Herana
38
Classes Abstratas
Usualmente, a existncia de uma classe se justifica pelo fato de
haver a possibilidade de gerar instncias da mesma
Essas so as classes concretas.
No entanto, podem existir classes que no geram instncias
diretas.
Essas so as classes abstratas.
Classes abstratas so utilizadas para organizar e simplificar
uma hierarquia de generalizao.
Propriedades comuns a diversas classes podem ser organizadas e
definidas em uma classe abstrata a partir da qual as primeiras herdam.
Subclasses de uma classe abstrata tambm podem ser
abstratas, mas a hierarquia deve terminar em uma ou mais
classes concretas.
39
Notao para classes abstratas
Na UML, uma classe abstrata representada com o seu nome
em itlico.
No exemplo a seguir, ContaBancria uma classe abstrata.
40
Refinamento do Modelo com Herana
Critrios a avaliar na criao de subclasses:
A subclasse tem atributos adicionais.
A subclasse tem associaes.
A subclasse manipulada (ou reage) de forma diferente da
superclasse.
Se algum subconceito (subconjunto de objetos)
atenda a tem algum(ns) das critrios acima, a criao
de uma subclasses deve ser considerada.
Sempre se assegure de que se trata de um
relacionamento do tipo -um: X um tipo de Y?
41
Refinamento do Modelo com Herana
A regra -um mais formalmente conhecida como regra da
substituio ou princpio de Liskov.
Regra da Substituio: sejam duas classes A e
B, onde A uma generalizao de B. No
pode haver diferenas entre utilizar instncias
de B ou de A, do ponto de vista dos clientes
de A.
Barbara Liskov (http://www.pmg.csail.mit.edu/~liskov/)
42
Restries sobre gen/espec
Restries OCL sobre relacionamentos de herana podem ser
representadas no diagrama de classes, tambm com o objetivo
de esclarecer seu significado.
Restries predefinidas pela UML:
Sobreposta X Disjunta
Completa X Incompleta
43
Restries sobre gen/espec
5.3 Diagrama de objetos
45
Diagrama de objetos
Alm do diagrama de classes, A UML define um segundo
tipo de diagrama estrutural, o diagrama de objetos.
Pode ser visto com uma instncia de diagramas de classes
Representa uma fotografia do sistema em um certo
momento.
exibe as ligaes formadas entre objetos conforme estes interagem e
os valores dos seus atributos.
Formato Exemplo
nomeClasse Pedido
nomeObjeto: NomeClasse umPedido: Pedido
46
Exemplo (Diagrama de objetos)
47
Exemplo (Diagrama de objetos)
5.4 Tcnicas para identificao de classes
49
Apesar de todas as vantagens que a OO pode
trazer ao desenvolvimento de software, um
problema fundamental ainda persiste: identificar
corretamente e completamente objetos (classes),
atributos e operaes.
50
Tcnicas de Identificao
Vrias tcnicas (de uso no exclusivo) so usadas
para identificar classes:
1. Categorias de Conceitos
2. Anlise Textual de Abbott (Abbot Textual Analysis)
3. Anlise de Casos de Uso
Categorizao BCE
4. Padres de Anlise (Analisys Patterns)
5. Identificao Dirigida a Responsabilidades
51
Categorias de Conceitos
Estratgia: usar uma lista de conceitos comuns.
Conceitos concretos. Por exemplo, edifcios, carros, salas de aula, etc.
Papis desempenhados por seres humanos. Por exemplo, professores,
alunos, empregados, clientes, etc.
Eventos, ou seja, ocorrncias em uma data e em uma hora particulares.
Por exemplo, reunies, pedidos, aterrisagens, aulas, etc.
Lugares: reas reservadas para pessoas ou coisas. Por exemplo:
escritrios, filiais, locais de pouso, salas de aula, etc.
Organizaes: colees de pessoas ou de recursos. Por exemplo:
departamentos, projetos, campanhas, turmas, etc.
Conceitos abstratos: princpios ou idias no tangveis. Por exemplo:
reservas, vendas, inscries, etc.
52
Anlise Textual de Abbott
Estratgia: identificar termos da narrativa de casos
de uso e documento de requisitos que podem sugerir
classes, atributos, operaes.
Neste tcnica, so utilizadas diversas fontes de informao
sobre o sistema: documento e requisitos, modelos do negcio,
glossrios, conhecimento sobre o domnio, etc.
Para cada um desses documentos, os nomes (substantivos e
adjetivos) que aparecem no mesmo so destacados. (So
tambm consideradas locues equivalentes a substantivos.)
Aps isso, os sinnimos so removidos (permanecem os
nomes mais significativos para o domnio do negcio em
questo).
53
Anlise Textual de Abbott (cont.)
Cada termo remanescente se encaixa em uma das situaes a
seguir:
O termo se torna uma classe (ou seja, so classes candidatas);
O termo se torna um atributo;
O termo no tem relevncia alguma com ao SSOO.
Abbott tambm preconiza o uso de sua tcnica na identificao
de operaes e de associaes.
Para isso, ele sugere que destaquemos os verbos no texto.
Verbos de ao (e.g., calcular, confirmar, cancelar, comprar, fechar,
estimar, depositar, sacar, etc.) so operaes em potencial.
Verbos com sentido de ter so potenciais agregaes ou composies.
Verbos com sentido de ser so generalizaes em potencial.
Demais verbos so associaes em potencial.
54
Anlise Textual de Abbott (cont.)
A ATA de aplicao bastante simples.
No entanto, uma desvantagem que seu resultado (as classes
candidatas identificadas) depende de os documentos utilizados
como fonte serem completos.
Dependendo do estilo que foi utilizado para escrever esse documento,
essa tcnica pode levar identificao de diversas classes candidatas
que no geraro classes.
A anlise do texto de um documento pode no deixar explcita uma
classe importante para o sistema.
Em linguagem natural, as variaes lingsticas e as formas de
expressar uma mesma idia so bastante numerosas.
55
Anlise de Casos de Uso
Essa tcnica tambm chamada de identificao dirigida por
casos de uso, e um caso particular da ATA.
Tcnica preconizada pelo Processo Unificado.
Nesta tcnica, o MCU utilizado como ponto de partida.
Premissa: um caso de uso corresponde a um comportamento especfico
do SSOO. Esse comportamento somente pode ser produzido por
objetos que compem o sistema.
Em outras palavras, a realizao de um caso de uso responsabilidade
de um conjunto de objetos que devem colaborar para produzir o
resultado daquele caso de uso.
Com base nisso, o modelador aplica a tcnica de anlise dos casos de
uso para identificar as classes necessrias produo do
comportamento que est documentado na descrio do caso de uso.
56
Anlise de Casos de Uso
Procedimento de aplicao:
O modelador estuda a descrio textual de cada caso de uso para
identificar classes candidatas.
Para cada caso de uso, se texto (fluxos principal, alternativos e de
exceo, ps-condies e pr-condies, etc.) analisado.
Na anlise de certo caso de uso, o modelador tenta identificar classes
que possam fornecer o comportamento do mesmo.
Na medida em que os casos de uso so analisados um a um, as classes
do SSOO so identificadas.
Quando todos os casos de uso tiverem sido analisados, todas as classes
(ou pelo menos a grande maioria delas) tero sido identificadas.
Na aplicao deste procedimento, podemos utilizar as
categorizao BCE...
57
Categorizao BCE
Na categorizao BCE, os objetos de um SSOO so agrupados
de acordo com o tipo de responsabilidade a eles atribuda.
objetos de entidade: usualmente objetos do domnio do problema
objetos de fronteira: atores interagem com esses objetos
objetos de controle: servem como intermedirios entre objetos de
fronteira e de entidade, definindo o comportamento de um caso de uso
especfico.
Categorizao proposta por Ivar Jacobson em1992.
Possui correspondncia (mas no equivalncia!) com o framework
model-view-controller (MVC)
Ligao entre anlise (o que; problema) e projeto (como; soluo)
Esteretipos na UML: boundary, entity, control
58
Objetos de Entidade
Repositrio para informaes e as regras de negcio
manipuladas pelo sistema.
Representam conceitos do domnio do negcio.
Caractersticas
Normalmente armazenam informaes persistentes.
Vrias instncias da mesma entidade existindo no sistema.
Participam de vrios casos de uso e tm ciclo de vida longo.
Exemplo:
Um objeto Pedido participa dos casos de uso Realizar
Pedido e Atualizar Estoque. Este objeto pode existir por
diversos anos ou mesmo tanto quanto o prprio sistema.
59
Objetos de Fronteira
Realizam a comunicao do sistema com os atores.
traduzem os eventos gerados por um ator em eventos relevantes ao
sistema eventos de sistema.
tambm so responsveis por apresentar os resultados de uma interao
dos objetos em algo inteligvel pelo ator.
Existem para que o sistema se comunique com o mundo
exterior.
Por conseqncia, so altamente dependentes do ambiente.
H dois tipos principais de objetos de fronteira:
Os que se comunicam com o usurio (atores humanos): relatrios,
pginas HTML, interfaces grfica desktop, etc.
Os que se comunicam com atores no-humanos (outros sistemas ou
dispositivos): protocolos de comunicao.
60
Objetos de Controle
So a ponte de comunicao entre objetos de fronteira e
objetos de entidade.
Responsveis por controlar a lgica de execuo
correspondente a um caso de uso.
Decidem o que o sistema deve fazer quando um evento de
sistema ocorre.
Eles realizam o controle do processamento
Agem como gerentes (coordenadores, controladores) dos outros
objetos para a realizao de um caso de uso.
Traduzem eventos de sistema em operaes que devem ser
realizadas pelos demais objetos.
61
Importncia da Categorizao BCE
A categorizao BCE parte do princpio de que cada objeto em um SSOO
especialista em realizar um de trs tipos de tarefa, a saber:
se comunicar com atores (fronteira),
manter as informaes (entidade) ou
coordenar a realizao de um caso de uso (controle).
A categorizao BCE uma receita de bolo para identificar objetos
participantes da realizao de um caso de uso.
A importncia dessa categorizao est relacionada
capacidade de adaptao a eventuais mudanas.
Se cada objeto tem atribuies especficas dentro do sistema, mudanas
podem ser menos complexas e mais localizadas.
Uma modificao em uma parte do sistema tem menos possibilidades
de resultar em mudanas em outras partes.
62
Vises de Classes Participantes
Uma Viso de Classes Participantes (VCP) um diagrama das
classes cujos objetos participam da realizao de determinado
caso de uso.
uma recomendao do UP (Unified Process). UP: definir uma VCP
por caso de uso
Termo original: View Of Participating Classes (VOPC).
Em uma VCP, so representados objetos de fronteira, de
entidade e de controle para um caso de uso particular.
Uma VCP definida atravs da utilizao da categorizao BCE
previamente descrita...vide prximo slide.
63
Estrutura de uma VCP
entidade
entidade
entidade controle fronteira
Uma VCP representa a estrutura das classes que participam da
realizao de um caso de uso em particular.
64
Construo de uma VCP
Para cada caso de uso:
Adicione uma fronteira para cada elemento de interface grfica
principal, tais com uma tela (formulrio) ou relatrio.
Adicione uma fronteira para cada ator no-humano (por exemplo, outro
sistema).
Adicione um ou mais controladores para gerenciar o processo de
realizao do caso de uso.
Adicione uma entidade para cada conceito do negcio.
Esses objetos so originrios do modelo conceitual.
Os esteretipos grficos definidos pela UML podem ser
utilizados.
65
VCP (exemplo) Realizar Inscrio
66
Regras Estruturais em uma VCP
Durante a fase de anlise, use as regras a seguir para
definir a VCP para um caso de uso.
Atores somente podem interagir com objetos de fronteira.
Objetos de fronteira somente podem interagir com
controladores e atores.
Objetos de entidade somente podem interagir (receber
requisies) com controladores.
Controladores somente podem interagir com objetos de
fronteira e objetos de entidade, e com (eventuais) outros
controladores.
67
Padres de Anlise
Aps produzir diversos modelos para um mesmo domnio,
natural que um modelador comece a identificar caractersticas
comuns entre esses modelos.
Em particular, um mesmo conjunto de classes ou
colaboraes entre objetos costuma recorrer, com algumas
pequenas diferenas, em todos os sistemas desenvolvidos
para o domnio em questo.
Quantos modelos de classes j foram construdos que possuem os
conceitos Cliente, Produto, Fornecedor, Departamento, etc?
Quantos outros j foram construdos que possuam os conceitos
Ordem de Compra, Ordem de Venda, Oramento, Contrato, etc?
68
Padres de Anlise
A identificao de caractersticas comuns acontece em
conseqncia do ganho de experincia do modelador em
determinado domnio de problema.
Ao reconhecer processos e estruturas comuns em um domnio,
o modelador pode descrever (catalogar) a essncia dos
mesmos, dando origem a padres de software.
Quando o problema correspondente ao descrito em um padro
de software acontecer novamente, um modelador pode utilizar
a soluo descrita no catlogo.
A aplicao desse processo permite que o desenvolvimento de
determinado aspecto de um SSOO seja feito de forma mais
rpida e menos suscetvel a erros.
69
Padres de Anlise
Each pattern describes a problem which occurs over and over
again in our environment, and then describes the core of the
solution to that problem, in such a way that you can use this
solution a million times over, without ever doing it the same
way twice
http://www.patternlanguage.com/leveltwo/ca.htm
Cada padro descreve um problema que ocorre freqentemente
no nosso ambiente, e ento descreve o ncleo de uma soluo
para tal problema. Esse ncleo pode ser utilizado um milho de
vezes, sem que haja duas formas de utilizao iguais.
Christopher Alexander
Um padro de software pode ento ser definido
como uma descrio essencial de um problema
recorrente no desenvolvimento de software.
70
Padres de Anlise
Padres de software podem ser utilizados em diversas
atividades e existem em diversos nveis de abstrao.
Padres de Anlise (Analysis Patterns)
Padres de Projeto (Design Patterns)
Padres Arquiteturais (Architectural Patterns)
Idiomas (Idioms)
Anti-padres (Anti-patterns)
71
Padres de Anlise
Um padro de software pode ento ser definido como uma
descrio essencial de um problema recorrente no
desenvolvimento de software.
Padres de software vm sendo estudados por anos e so
atualmente utilizados em diversas fases do desenvolvimento.
Padres de software utilizados na fase de anlise de um SSOO
so chamados padres de anlise.
Um padro de anlise normalmente composto, dentre outras
partes, de um fragmento de diagrama de classes que pode ser
customizado para uma situao de modelagem em particular.
72
Exemplo 1 Padro Party
73
Exemplo 2 Padro Metamodel
74
Identificao Dirigida a Responsabilidades
Nesta tcnica, a nfase est na identificao de classes a partir
de seus comportamentos relevantes para o sistema.
O esforo do modelador recai sobre a identificao das
responsabilidades que cada classe deve ter dentro do sistema.
Mtodo foi proposto por Rebecca Wirfs-Brock et al (RDD).
O mtodo dirigido a responsabilidades enfatiza o encapsulamento da
estrutura e do comportamento dos objetos.
Essa tcnica enfatiza o princpio do encapsulamento:
A nfase est na identificao das responsabilidades de uma classe que
so teis externamente mesma.
Os detalhes internos classe (como ela faz para cumprir com suas
responsabilidades) devem ser abstrados.
75
As responsabilidades de um SSOO devem ser alocadas
aos objetos (classes) componentes do mesmo.
76
Responsabilidades de uma Classe
Em um SSOO, objetos encapsulam comportamento.
O comportamento de um objeto definido de tal forma que ele possa
cumprir com suas responsabilidades.
Uma responsabilidade uma obrigao que um objeto tem
para com o sistema no qual ele est inserido.
Atravs delas, um objeto colabora (ajuda) com outros para que os
objetivos do sistema sejam alcanados.
Na prtica, uma responsabilidade alguma coisa que um
objeto conhece ou sabe fazer (sozinho ou pedindo ajuda).
Se um objeto tem uma responsabilidade com a qual no pode
cumprir sozinho, ele deve requisitar colaboraes de outros
objetos.
77
Responsabilidades e Colaboradores
Exemplo: considere clientes e seus pedidos:
Um objeto Cliente conhece seu nome, seu endereo, seu telefone, etc.
Um objeto Pedido conhece sua data de realizao, conhece o seu cliente,
conhece os seus itens componentes e sabe fazer o clculo do seu total.
Exemplo: quando a impresso de uma fatura requisitada em um sistema
de vendas, vrios objetos precisam colaborar:
um objeto Pedido pode ter a responsabilidade de fornecer o seu valor total
um objeto Cliente fornece seu nome
cada ItemPedido informa a quantidade correspondente e o valor de seu subtotal
os objetos Produto tambm colaboraram fornecendo seu nome e preo unitrio.
78
Responsabilidades e Colaboraes
Pense em um SSOO como uma sociedade onde os cidados (colaboradores) so objetos.
Um objeto cumpre com suas responsabilidades atravs das
informaes que ele possui ou das informaes que ele
pode derivar a partir de colaboraes com outros objetos.
79
Modelagem CRC
A identificao dirigida a responsabilidades normalmente
utiliza uma tcnica de modelagem que facilita a participao
de especialistas do domnio e analistas.
Essa tcnica denominada modelagem CRC (CRC modeling).
CRC: Class, Responsibility, Collaboration
A modelagem CRC foi proposta em 1989 por Kent Beck e
Ward Cunningham.
A princpio, essa tcnica de modelagem foi proposta como uma forma
de ensinar o paradigma OO a iniciantes.
Contudo, sua simplicidade de notao a tornou particularmente
interessante para ser utilizada na identificao de classes.
80
Sesso CRC
Para aplicar essa tcnica, esses profissionais se renem em
uma sala, onde tem incio uma sesso CRC.
Uma sesso CRC uma reunio que envolve cerca de meia
dzia de pessoas.
Entre os participantes esto especialistas de domnio,
projetistas, analistas e o moderador da sesso.
A cada pessoa entregue um carto de papel que mede
aproximadamente 10cm x 15cm.
Uma vez distribudos os cartes pelos participantes, um
conjunto de cenrios de determinado caso de uso
selecionado.
81
Sesso CRC
Ento, para cada cenrio desse conjunto, uma sesso CRC
iniciada.
(Se o caso de uso no for to complexo, ele pode ser analisado em uma
nica sesso.)
Um carto CRC dividido em vrias partes.
Na parte superior do carto, aparece o nome de uma classe.
A parte inferior do carto dividida em duas colunas.
Na coluna da esquerda, o indivduo ao qual foi entre o carto deve listar
as responsabilidades da classe.
Na coluna direita, o indivduo deve listar os nomes de outras classes
que colaboram com a classe em questo para que ela cumpra com suas
responsabilidades.
82
Modelagem CRC
Normalmente j existem algumas classes candidatas para
determinado cenrio.
Identificadas atravs de outras tcnicas.
A sesso CRC comea com algum dos participantes simulando
o ator primrio que dispara a realizao do caso de uso.
Na medida em que esse participante simula a interao do ator
com o sistema, os demais participantes encenam a colaborao
entre objetos que ocorre internamente ao sistema.
Atravs dessa encenao dos participantes da sesso CRC, as
classes, responsabilidades e colaboraes so identificadas.
83
Estrutura de um Carto CRC
Nome da classe
Responsabilidades Colaboradores
1
a
responsabilidade
2
a
responsabilidade
...
n-sima responsabilidade
1
o
colaborador
2
o
colaborador
...
m-simo colaborador
84
Exemplos de cartes CRC
Aluno
1. Conhecer seu nmero de registro
2. Conhecer seu nome
3. Conhecer as disciplinas que j cursou
Participao
Disciplina
1. Conhecer seus pr-requisitos
2. Conhecer seu cdigo
3. Conhecer seu nome
4. Conhecer sua quantidade de crditos
Disciplina
85
Criao de Novos Cartes
Durante uma sesso CRC, para cada responsabilidade
atribuda a uma classe, o seu proprietrio deve questionar se tal
classe capaz de cumprir com a responsabilidade sozinha.
Se ela precisar de ajuda, essa ajuda dada por um colaborador.
Os participantes da sesso, ento, decidem que outra classe
pode fornecer tal ajuda.
Se essa classe existir, ela recebe uma nova responsabilidade necessria
para que ela fornea ajuda.
Caso contrrio, um novo carto (ou seja, uma nova classe) criado para
cumprir com tal responsabilidade de ajuda.
5.5 Construo do modelo de classes
87
Construo do modelo de classes
Aps a identificao de classes, o modelador deve verificar a
consistncia entre as classes para eliminar incoerncias e
redundncias.
Como dica, o modelador deve estar apto a declarar as razes de
existncia de cada classe identificada.
Depois disso, os analistas devem comear a definir o
mapeamento das responsabilidades e colaboradores de cada
classe para os elementos do diagrama de classes.
Esse mapeamento resulta em um diagrama de classes que apresenta
uma estrutura esttica relativa a todas as classes identificadas como
participantes da realizao de um ou mais casos de uso.
88
Definio de propriedades
Uma responsabilidade de conhecer mapeada para um ou
mais atributos.
Operaes de uma classe so um modo mais detalhado de
explicitar as responsabilidades de fazer.
Uma operao pode ser vista como uma contribuio da classe para
uma tarefa mais complexa representada por um caso de uso.
Uma definio mais completa das operaes de uma classe s pode
ser feita aps a construo dos diagramas de interao.
89
Definio de associaes
O fato de uma classe possuir colaboradores indica que devem
existir relacionamentos entre estes ltimos e a classe.
Isto porque um objeto precisa conhecer o outro para poder lhe fazer
requisies.
Portanto, para criar associaes, verifique os colaboradores de uma classe.
O raciocnio para definir associaes reflexivas, ternrias e
agregaes o mesmo.
90
Definio de classes associativas
Surgem a partir de responsabilidades de conhecer que o
modelador no conseguiu atribuir a alguma classe.
(mais raramente, de responsabilidades de fazer)
91
Organizao da documentao
As responsabilidades e colaboradores mapeados para
elementos do modelo de classes devem ser
organizados em um diagrama de classes e
documentados, resultando no modelo de classes de
domnio.
Podem ser associados esteretipos predefinidos s
classes identificadas:
<<fronteira>>
<<entidade>>
<<controle>>
92
Organizao da documentao
A construo de um nico diagrama de classes para todo o
sistema pode resultar em um diagrama bastante complexo.
Um alternativa criar uma viso de classes participantes
(VCP) para cada caso de uso.
Em uma VCP, so exibidos os objetos que participam de um
caso de uso.
As VCPs podem ser reunidas para formar um nico diagrama
de classes para o sistema como um todo.
5.6 Modelo de classes no processo
de desenvolvimento
94
Modelo de classes no processo de
desenvolvimento
Em um desenvolvimento dirigido a casos de uso, aps a
descrio dos casos de uso, possvel iniciar a identificao
de classes.
As classes identificadas so refinadas para retirar
inconsistncias e redundncias.
As classes so documentadas e o diagrama de classes inicial
construdo, resultando no modelo de classes de domnio.
95
desenvolvimento
Inconsistncias nos modelos devem ser verificadas e
corrigidas.
As construes do modelo de casos de uso e do modelo de
classes so retroativas uma sobre a outra.
Durante a aplicao de alguma tcnica de identificao, novos casos
de uso podem ser identificados
Pode-se identificar a necessidade de modificao de casos de uso
preexistentes.
Depois que a primeira verso do modelo de classes de anlise
est completa, o modelador deve retornar ao modelo de casos
de uso e verificar a consistncia entre os dois modelos.
96
desenvolvimento
Interdependncia entre o modelo de casos de uso e o
modelo de classes.

1601PAPSUML-Cap05

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

1601PAPSUML-Cap05

Enviado por

Direitos autorais:

Formatos disponíveis

Princpios de Anlise

Você também pode gostar