Nome: Lucas Alves Martins Rodney Garcia Prof: Flvia Balbino
Universidade Castelo Branco
Slide 2
Identificar agregaes As hierarquias de agregao, tambm
conhecidas como hierarquias de parte-todo entre duas ou mais
classes distintas possibilitam representar uma abstrao a partir das
partes em que a compem. Alm disso, o fato de cada parte poder
possuir seus prprios componentes, possibilita uma refatorao
recursiva.
Slide 3
Identificar agregaes De uma maneira geral, dadas duas classes
(A e B), podemos dizer que B agrega A quando: (i) A uma parte fsica
ou lgica de B; (ii) A est contida em B; (iii) A um item de uma
transao ou relatrio B; (iv) A um membro de B; (v) A uma sub-unidade
organizacional de B; e (vi) A possudo por B.
Slide 4
Identificar agregaes Exemplo:
Slide 5
Identificar Herana A identificao de relacionamentos de herana
mais simples do que a de associaes. Para encontrar relacionamentos
de herana entre as classes de anlise identificadas, basta estud-las
e procurar por relaes do tipo -um-tipo-de entre elas.
Slide 6
Identificar Herana Um exemplo claro no sistema de biblioteca o
relacionamento entre a classe Usurio e as classes Atendente, Aluno
e Professor. Alm disso, as classes Peridico, Livro, Tese e Manual
podem ser consideradas como sub-tipos de Publicao. A relao das
classes identificadas para o sistema pode ser identificada a partir
do domnio do problema ou do dicionrio de dados.
Slide 7
Identificar Herana
Slide 8
Aps a identificao dos relacionamentos de herana, pode ser
necessrio refatorar as associaes entre as classes. Essa refatorao
tem o objetivo principal de mover as associaes comuns a todas as
classes derivadas (filhas) para a classe base (superclasse). Alm
disso, a existncia de hierarquias de generalizao e especializao bem
estruturada possibilitaro outros benefcios ao modelo.
Slide 9
Identificar Herana A figura a seguir apresenta o diagrama de
classes de anlise depois da adio de associaes, agregaes e
relacionamentos de herana. Devido ao excesso de agregaes entre a
classe Sistema e as demais classes modeladas, essa informao
conceitual de composio das partes do sistema pode ser expressada
atravs do conceito de mdulo, que pode ser representado por pacotes
UML.
Slide 10
Identificar Herana
Slide 11
Identificar Atributos das Classes de Anlise No ltimo estgio da
modelagem esttica, so identificados os atributos das classes de
anlise. Porm, nem todos os atributos precisam ser encontrados
durante a anlise; esperado que uma parte deles pertena soluo e por
isso devem ser identificadas durante a fase do projeto.
Slide 12
Identificar Atributos das Classes de Anlise Os atributos que so
identificados durante a fase de anlise, ou so inerentes ao domnio
da aplicao, ou so aqueles que representam informaes relevantes para
a realizao dos casos de uso, isto , aqueles que representam
informaes explicitadas na especificao dos casos de uso. Sendo
assim, esses atributos quase sempre esto associados a classes de
entidade.
Slide 13
Identificar Atributos das Classes de Anlise Essas classes
normalmente s precisam ter estado se for necessrio guardar
informaes relativas interao com um certo usurio, por exemplo
informaes de sees, utilizadas no caso de vrios usurios acessarem o
sistema ao mesmo tempo. Mas normalmente esse tipo de informao s
levado em considerao e identificado a partir da fase de
projeto.
Slide 14
Identificar Atributos das Classes de Anlise A identificao dos
atributos feita de maneira anloga identificao das classes, isto ,
os atributos normalmente so identificados atravs da anlise do
domnio e do estudo das especificaes dos casos de uso do sistema, do
enunciado do problema e do dicionrio de dados.
Slide 15
Identificar Atributos das Classes de Anlise De uma maneira em
geral, eles podem ser identificados a partir das classes candidatas
descobertas atravs da anlise textual desses artefatos, mais
especificamente, a partir das classes descartadas no refinamento do
diagrama de classes de anlise.
Slide 16
Identificar Atributos das Classes de Anlise Esses atributos
normalmente representam conceitos simples que podem ser expressados
usando-se tipos primitivos, como inteiros e caracteres. Quando no o
caso, comum criar novas classes que representam registros de dados,
onde cada atributo representa um campo de registro.
Slide 17
Identificar Atributos das Classes de Anlise Para enfatizar a
sua importncia, alguns autores do a essas classes o esteretipo
>. Exemplos de classes que normalmente definem tipos de dados so
Endereo, Cor, Telefone, Ponto cartesiano, etc.
Slide 18
Identificar Atributos das Classes de Anlise De um modo em
geral, se um atributo de uma classe muito complexo, provavelmente
ele deveria ser definido como uma classe parte. Depois, se for
necessrio, as classes de atributos podem ser facilmente
transformadas em atributos na fase de projeto do sistema.
Slide 19
Atributos das Classes de Anlise no Estudo de Caso Olhando
rapidamente a lista de classes eliminadas a seguir, percebemos que
vrias delas no se tornaram classes de anlise por representarem, na
verdade, atributos de outras classes. Alm dessas informaes, possvel
extrair algumas outras examinando a especificao do dicionrio de
dados e os atributos inerentes ao domnio da aplicao.
Slide 20
Atributos das Classes de Anlise no Estudo de Caso *Categorias e
Entidades identificadas para o sistema da biblioteca. Classes
eliminadas: Exemplar,Bibliotecria, Sistema de cadastro de publicaes
e usurios, Devoluo com atraso, Bloqueio e Desbloqueio.
Slide 21
Atributos das Classes de Anlise no Estudo de Caso A tabela a
seguir associa os atributos identificados s classes
correspondentes:
Slide 22
Atributos das Classes de Anlise no Estudo de Caso *Atributos
identificados para o sistema de bibliotecas.
Slide 23
Atributos das Classes de Anlise no Estudo de Caso Algumas
informaes foram modificadas para se tornarem mais simples e de
acordo com as orientaes descritas na imagem anterior. Por exemplo,
o perodo de um emprstimo foi definido atravs de dois atributos: a
data em que o emprstimo foi realizado (data emprstimo) e a data
esperada para a devoluo data de devoluo.
Slide 24
Atributos das Classes de Anlise no Estudo de Caso Tambm podem
ser adicionados ao modelo de anlise atributos bvios, relativos ao
domnio e que no apareceram na descrio dos casos de uso analisados.
Deve-se ter cuidado, porm, com a definio do que ou no inerente ao
domnio. Por exemplo, no nosso estudo de caso, perfeitamente
coerente adicionar o atributo Ttulo classe Publicao, j que qualquer
publicao tem um ttulo.
Slide 25
Atributos das Classes de Anlise no Estudo de Caso Por outro
lado, apesar de tentador, no adequado adicionar um atributo Autor a
essa classe, j que, entre as publicaes com as quais o sistema deve
lidar, esto peridicos, publicaes para as quais o conceito de autor
normalmente no faz sentido.
Slide 26
Atributos das Classes de Anlise no Estudo de Caso A figura a
seguir apresenta o diagrama de classes de anlise depois de
adicionados os atributos identificados anteriormente:
Slide 27
Atributos das Classes de Anlise no Estudo de Caso
Slide 28
Identificar Classes de Anlise O processo RUP sugere que classes
de anlise sejam dividas em trs grupos, a fim de classificar os
elementos de acordo com o seu papel no modelo. O principal objetivo
dessa classificao e simplificar a transio da anlise para o projeto.
Os trs grupos definidos so: Classes de entidade Classes de controle
Classes de fronteira
Slide 29
Classe de Entidade Representao dos conceitos do domnio do
problema Informaes e regras de negcio que direcionam a manipulao
dessas informaes Tambm chamadas de classes de negcio A maioria j
descoberta na fase de anlise Aspecto importante a analisar: quais
geram objetos que devam ser persistentes Definir o mecanismo de
persistncia Prtica interessante: Para ajudar na identificao nica de
objetos de uma classe, sugere-se a criao de um atributo
identificador de implementao (identificador ou id) do tipo Inteiro
id) do tipo inteiro Muito teis em caso de mapeamento para
mecanismos de armazenamento persistente
Slide 30
Classes de Fronteira Interao com os elementos externos
Apresentao de informaes Captao de informao Classes de fronteira NO
devem ter responsabilidades relativas as regras de negcio da
Aplicao Exemplo: uma classe para representar um formulrio de
inscrio em uma escola Tipos de fronteira: Classes de interface com
o usurio Classes de interface com equipamentos Classes de interface
com outros sistemas As formas de interao do sistema com o ambiente
influenciam no projeto arquitetural do mesmo
Slide 31
Classes de Fronteira Clientes WEB clssicos Representao na forma
de classes de pginas WEB estticas e dinmicas Clientes mveis Classes
de fronteira em protocolos especficos Clientes stand-alone Janelas,
menus, formulrios, botes, etc. Servios WEB (WEBservices) Servios da
aplicao disponveis pela Internet
Slide 32
Classes de Fronteira
Slide 33
Classes de Controle Responsveis por coordenar a interao entre
os demais objetos Normalmente podem haver vrias classes de controle
em uma aplicao Uma para cada aspecto da soluo Responsabilidades:
Preenchimento de controles da interface grfica Autenticao de
usurios Controle de acesso s funcionalidades do sistema Tipo comum
de classe de controle o controlador de caso de uso Coordenar a
realizao de um caso de uso Servir de canal de comunicao entre os
objetos de Fronteira e os objetos de entidade
Slide 34
Classes de Controle Mapeando aes dos atores em mensagens para
objetos de entidade Comunicar-se com outros controladores, quando
for necessrio Estar apto a manipular excees Em uma aplicao WEB
comum o uso de um front controller (FC) Receber as requisies de um
cliente Identificar o controlador adequado para processar a
Redirecionar para o controlador adequado Caractersticas a serem
evitadas Acoplamento excessivo Repetio de cdigo
Slide 35
Relacionamento entre Classes Os objetos tem relaes entre eles:
um professor ministra uma disciplina para alunos numa sala, um
cliente faz uma reserva de alguns lugares para uma data, etc. Essas
relaes so representadas tambm no diagrama de classe. Geralmente as
classes no esto ss e se relacionam entre si. O relacionamento e a
comunicao entre as classes definem responsabilidades E um dos
principais diagramas da UML define o esqueleto do sistema Ha tres
tipos de relacionamientos entre classes: associao, agregao e
generalizao
Slide 36
Associao E o tipo de relacionamento mais comum e mais
importante em um sistema orientado a objetos E um relacionamento ou
ligacao entre duas classes permitindo que objetos destas possam se
comunicar Objetivo essencial da associacao: possibilitar a
comunicacao entre objetos de duas classes A comunicacao pode ser
uni ou bidirecional Segmento de reta ligando as duas classes
Associacao unidirecional: inclui-se uma seta na extremidade de
destino Pode-se incluir um nome na associacao Indica a natureza ou
finalidade da comunicacao
Slide 37
Associao
Slide 38
Papeis das classes Pode-se incluir uma indicacao dos papeis das
classes nas associacoes Nao e comum indicar o nome da associacao e
os papeis das classes para uma mesma associacao opta-se por uma ou
outra
Slide 39
Associao
Slide 40
Cardinalidade Especifica o numero de objetos de cada classe
envolvidos com a associacao Quando nao ha especificacao, entende-se
que a cardinalidade e 1
Slide 41
Associao
Slide 42
A leitura da cardinalidade exige cuidados: Deve-se fazer a
leitura de forma distinta para os dois sentidos da associao Para
cada um dos sentidos: Deve-se esquecer a cardinalidade no extremo
de inicio Deve-se considerar que existe a associao de um objeto da
classe de inicio com vrios objetos da classe de destino
Slide 43
Agregaco Relacionamento de pertinncia entre classes Permite a
incluso de objetos de uma classe no interior de objetos de outra
classe Relao 'parte-de', 'tem-um', 'todo-parte' Objeto que agrega
conhece o agregado mas este no conhece aquele comunicao
unidirecional Notao UML: segmento de reta ligando a classe dos
objetos que agregam a classe dos objetos agregados
Slide 44
Agregaco Na extremidade da classe dos objetos que agregam
inclui-se um losango:
Slide 45
Agregaco
Slide 46
Cardinalidade Numero de objetos envolvidos na relacao Um objeto
pode incluir varios outros mas nao pode estar contido em mais de um
objeto i.e. cardinalidade no lado da classe dos objetos que agregam
sera sempre 1
Slide 47
Associao A leitura da cardinalidade exige cuidados: Deve-se
fazer a leitura de forma distinta para os dois sentidos da
associacao Para cada um dos sentidos: Deve-se esquecer a
cardinalidade no extremo de inicio Deve-se considerar que existe a
associacao de um objeto da classe de inicio com varios objetos da
classe de destino
Slide 48
Associao Relacionamento de pertinncia entre classes Permite a
incluso de objetos de uma classe no interior de objetos de outra
classe Relao 'parte-de', 'tem-um', 'todo-parte' Objeto que agrega
conhece o agregado mas este no conhece aquele comunicao
unidirecional Notao UML: segmento de reta ligando a classe dos
objetos que agregam a classe dos objetos agregados
Slide 49
Associao Na extremidade da classe dos objetos que agregam
inclui-se um losango:
Slide 50
Associao Exemplo: um objeto da classe CCarro contem 4 objetos
da classe CRoda e 5 objetos da classe Cporta:
Slide 51
Associao
Slide 52
No existe uma tcnica precisa para de se definir as agregaes em
um sistema Sugestes: definio das agregaes a partir de decomposies
quando uma classe tem muitas responsabilidades, tende-se a
dividi-la. Tal diviso pode fazer com que a classe perca sua
identidade neste contexto, as agregaes so muitos uteis porque
dividem uma classe grande em outras menores, sem que a grande perca
a identidade definio das agregaes a partir de composies raciocinio
e o inverso ao da decomposicao procura-se identificar conjuntos de
objetos que juntos compoem objetos maiores
Slide 53
Associao definio de agregaes a partir de partes comuns quando
se percebe dentro de duas ou mais classes um conjunto de atributos
e/ou mtodos semelhantes se estes juntos possuem uma identidade,
ento poderia ser criada uma nova classe:
Slide 54
Agregao Definicao de agregacoes a partir de partes comuns
Slide 55
Generalizao/Especializao de classes Relacionamento estrutural
entre duas classes classe base (superclasse) classe base
(subclasse) Herana (relacionamento 'e um' a derivada herda as
propriedades da base
Slide 56
Generalizao/Especializao de classes
Slide 57
Padres de Modelagem Desenvolvedores experientes de sistemas
orientados a objetos construram ao longo dos anos um repertrio de
solues para problemas comuns encontrados durante o desenvolvimento.
Para serem consideradas como padres, essas solues, devem ser
validadas atravs do uso em diversas circunstncias distintas,
especificadas de uma maneira estruturada que descreve tanto a soluo
quanto o problema que ela se prope a resolver.
Slide 58
Padres de Modelagem Inicialmente, os padres surgiram no
contexto do projeto arquitetnico, na construo ao civil [1]. Segundo
Christopher Alexander, cada padro descreve um problema que ocorre
recorrentemente em nosso ambiente e uma soluo para ele, de tal
maneira que se pode usar essa soluo vrias vezes e de diversas
maneiras [1]. No desenvolvimento de software, padres podem ser
encontrados em diversas circunstncias diferentes. Padres de projeto
foram os primeiros a aparecer [19] e no demorou muito para que uma
mirade de outros, como padres arquiteturais [10], anlise [18] e de
implementao [29] surgissem. Atualmente, padres de variados tipos so
empregados em projetos de desenvolvimento
Slide 59
Padres de Modelagem para tornar os sistemas construdos mais
fceis de entender e manter, alm de facilitar a reutilizao de suas
partes Em geral, um padro tem quatro elementos fundamentais: 1.
Nome do padro: um identificador que podem ser utilizados para
descrever um problema, sua soluo e suas consequncias em uma ou duas
palavras. 2. Problema: uma descrio de quando aplicar o padro. Ele
explica o problema que o padro Um exemplo de padro de anlise que
discutimos neste captulo foi o padro
Slide 60
Padres de Modelagem Controlador [29], apresentado como parte do
padro de anlise MVC (Seo 3.10.1). Este padro consiste em atribuir a
uma classe a responsabilidade de tratar os eventos do sistema,
sendo responsvel por implementar a lgica do negcio. Esse padro de
anlise descrito resumidamente a seguir: Nome: Controlador Problema
: definir qual classe implementa as regras do negcio e e responsvel
por lidar com os eventos do sistema. Soluo : atribuir essa
responsabilidade a uma classe cujo propsito justamente lidar com
esses eventos e implementar as regras de negcios. Essa classe
representa a inteligncia do sistema. Consequncias: (i) aumenta o
potencial para reutilizao, j que separa o controle de outras
caractersticas do sistema, como a interface com o usurio e a
representao dos dados; e (ii) melhorar a manutenibilidade do
sistema, uma vez que a rpida localizao do controle facilita evoluo
das regras de negcio