Cap 05 Diagrama de Classes v3

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
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
Princpios de Anlise e Projeto de Sistemas com UML - 2 edio
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
Introduo
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.
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?
Modelo de Classes de Anlise

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 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 Pagamento quantia 1 Pago-por 1 data hora Anlise
Projeto (Especificao) Venda Pagamento 1 Pago-por 1 -data:Date -hora:Time
-quantia: Currency
+getValor(): Currency
+getTotal():Currency
8
5.2 Diagrama de classes
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.
10
Exemplo (classe ContaBancria)
11
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.
12
Notao para Associaes

Na UML associaes so representadas por uma linha que liga as classes cujos objetos se relacionam. Exemplos:
13
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 Apenas Um Zero ou Muitos Um ou Muitos Zero ou Um Intervalo Especfico Simbologia na UML 1..1 (ou 1) 0..* (ou *) 1..* 0..1 li..ls
14
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.
15
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 Um para um Em um extremo 0..1 1 No outro extremo 0..1 1
Um para muitos
0..1 1
* 1..* 0..*
Muitos para muitos
* * 1..* 1..* Princpios de Anlise e Projeto de Sistemas com UML - 2 edio 0..* 0..*
16
Exemplo (conectividade)
17
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.
18
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.
19
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
20
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.
21
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).
22
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
23
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.
24
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.
25
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?
26
Exemplos
27
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 nocompartilhada.
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.
28
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
29
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
30
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.
31
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.
32
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.
33
Propriedades da Herana
34
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.
35
Notao para classes abstratas

Na UML, uma classe abstrata representada com o seu nome em itlico. No exemplo a seguir, ContaBancria uma classe abstrata.
36
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?
37
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/)

38
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
39
Restries sobre gen/espec

Veculo
FiguraGeomtrica
{incompleta} Caminho Trator

Elipse
{incompleta, disjunta} Quadrado Crculo
Indivduo
Atleta
{completa, disjunta} Homem Mulher
{incompleta, sobreposta} Nadador Corredor
40
5.3 Diagrama de objetos
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.
Exemplo
Formato
nomeClasse nomeObjeto: NomeClasse
Pedido umPedido: Pedido

42
Exemplo (Diagrama de objetos)

produto20 : Produto nome = "Caderno M" descrio = "Caderno em espiral tamanho mdio" preoUnitrio = 4,50 desconto = 15 produto12 : Produto nome = "Caneta ESF" descrio = "Caneta esferogrfica 5mm" preoUnitrio = 1,20 desconto = 2 produto07 : Produto nome = "Esquadro" descrio = "Esquadro de acrlico 20 cm" preoUnitrio = 2,35 desconto = 10
item1 : ItemPedido quantidade = 6 Pedido1 : Pedido ItemPedido Produto Pedido data = 13/09/2002 hora = 10:00am
item2 : ItemPedido quantidade = 20
item3 : ItemPedido quantidade = 1
43
Exemplo (Diagrama de objetos)
Joo : Empregado Antnio : Empregado Jos : Empregado Maria : Empregado
Rafaela : Empregado
Aline Empregado : Empregado
Lucas : Empregado
44
5.4 Tcnicas para identificao de classes
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.
46
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
47
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.
48
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).
49
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.
50
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.
51
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.
52
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...

53
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

54
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.
55
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.
56
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.
57
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.
58
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.
59
Estrutura de uma VCP

Uma VCP representa a estrutura das classes que participam da realizao de um caso de uso em particular.
entidade
fronteira
controle
entidade
entidade
60
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.
61
VCP (exemplo) Realizar Inscrio
62
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.
63
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.
64
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.
65
Responsabilidades e Colaboraes
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.
Objetos possuem realizadas por
Responsabilidades
O que o objeto conhece + O que o objeto faz
Colaboradores
O padro de cooperao (comunicao) entre objetos
precisam de
Princpios de Anlise e Projeto de Sistemas com UML - 2 edio Pense em um SSOO como uma sociedade onde os cidados (colaboradores) so objetos. 66
5.5 Construo do modelo de classes
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.
68
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.
69
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.
70
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)
Inadequado
Adequado
Trabalho cargaHorria trabalhador Projeto * * Pessoa trabalhador * * Projeto
Pessoa cargaHorria
71
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>>
72
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.
73
5.6 Modelo de classes no processo de desenvolvimento
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.
75

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.
76

Interdependncia entre o modelo de casos de uso e o modelo de classes.
77
8.5 Herana
78
Relacionamento de Herana
Na modelagem de classes de projeto, h diversos aspectos relacionados ao de relacionamento de herana.
Tipos de herana Classes abstratas Operaes abstratas Operaes polimrficas Interfaces Acoplamentos concreto e abstrato Reuso atravs de delegao e atravs de generalizao Classificao dinmica
Princpios de Anlise e Projeto de Sistemas com UML - 2 edio Princpios de Anlise e Projeto de Sistemas com UML - 2 edio
79
79
Tipos de herana
Com relao quantidade de superclasses que certa classe pode ter.
herana mltipla herana simples
Com relao forma de reutilizao envolvida.

Na herana de implementao, uma classe reusa alguma implementao de um ancestral. Na herana de interface, uma classe reusa a interface (conjunto das assinaturas de operaes) de um ancestral e se compromete a implementar essa interface.
80
80
Classes abstratas
Usualmente, a existncia de uma classe se justifica pelo fato de haver a possibilidade de gerar instncias a partir da mesma.
Essas classes so chamadas de classes concretas.
No entanto, podem existir classes que no geram instncias diretamente.

Essas classes so chamadas de classes abstratas.
Classes abstratas so usadas para organizar hierarquias gen/spec.

Propriedades comuns a diversas classes podem ser organizadas e definidas em uma classe abstrata a partir da qual as primeiras herdam.
Tambm propiciam a implementao do princpio do polimorfismo.

81
81
Classes abstratas (cont)

Na UML, uma classe abstrata pode ser representada de duas maneiras alternativas:
Com o seu nome em itlico. Qualificando-a com a propriedade {abstract}
Exemplo:
82
82
Operaes abstratas
Uma classe abstrata possui ao menos uma operao abstrata, que corresponde especificao de um servio que a classe deve fornecer (sem mtodo).
Uma classe qualquer pode possuir tanto operaes abstratas, quanto operaes concretas (ou seja, operaes que possuem implementao). Entretanto, uma classe que possui pelo menos uma operao abstrata , por definio abstrata, abstrata.
Uma operao abstrata definida com visibilidade pblica em uma classe tambm herdada por suas subclasses. Quando uma subclasse herda uma operao abstrata e no fornece uma implementao para a mesma, esta classe tambm abstrata.
83
83
Operaes abstratas (cont)

Na UML, a assinatura de uma operao abstrata definida em itlico.
84
84
Operaes polimrficas
Uma subclasse herda todas as propriedades de sua superclasse que tenham visibilidade pblica ou protegida. Entretanto, pode ser que o comportamento de alguma operao herdada seja diferente para a subclasse. Nesse caso, a subclasse deve redefinir o comportamento da operao.
A assinatura da operao reutilizada. Mas, a implementao da operao (ou seja, seu mtodo) diferente.
Operaes polimrficas so aquelas que possuem mais de uma implementao.
85
85
Operaes polimrficas (cont)

Operaes polimrficas possuem sua assinatura definida em diversos nveis de uma hierarquia gen/spec.
A assinatura repetida na(s) subclasse(s) para enfatizar a redefinio de implementao. O objetivo de manter a assinatura garantir que as subclasses tenham uma interface em comum.
Operaes polimrficas facilitam a implementao.

Se duas ou mais subclasses implementam uma operao polimrfica, a mensagem para ativar essa operao a mesma para todas essas classes. No envio da mensagem, o remetente no precisa saber qual a verdadeira classe de cada objeto, pois eles aceitam a mesma mensagem. A diferena que os mtodos da operao so diferentes em cada subclasse.
86
86

A operao obterPagamento polimrfica.
87
87

Operaes polimrficas tambm podem existir em classes abstratas.
88
88

Operaes polimrficas implementam o princpio do polimorfismo, no qual dois ou mais objetos respondem a mesma mensagem de formas diferentes.
ContaCorrente cc; ContaPoupanca cp; ... List<ContaBancaria> contasBancarias; ... contasBancarias.add(cc); contasBancarias.add(cp); ... for(ContaBancaria conta : contasBancarias) { conta.aplicarJuros(); } ...
89
89
Interfaces
Uma interface entre dois objetos compreende um conjunto de assinaturas de operaes correspondentes aos servios dos quais a classe do objeto cliente faz uso. Uma interface pode ser interpretada como um contrato de comportamento entre um objeto cliente e eventuais objetos fornecedores de um determinado servio.
Contanto que um objeto fornecedor fornea implementao para a interface que o objeto cliente espera, este ltimo no precisa conhecer a verdadeira classe do primeiro.
90
90
Interfaces (cont.)
Interfaces so utilizadas com os seguintes objetivos:
1. Capturar semelhanas entre classes no relacionadas sem forar relacionamentos entre elas. 2. Declarar operaes que uma ou mais classes devem implementar. 3. Revelar as operaes de um objeto, sem revelar a sua classe. 4. Facilitar o desacoplamento entre elementos de um sistema.
Nas LPOO modernas (Java, C#, etc.), interfaces so definidas de forma semelhante a classes.
Uma diferena que todas as declaraes em uma interface tm visibilidade pblica. Adicionalmente, uma interface no possui atributos, somente declaraes de assinaturas de operaes e (raramente) constantes.
91
91
Interfaces (cont)
Notaes para representar interfaces na UML:
A primeira notao a mesma para classes. So exibidas as operaes que a interface especifica. Deve ser usado o esteretipo <<interface>>. A segunda notao usa um segmento de reta com um pequeno crculo em um dos extremos e ligado ao classificador.
Classes clientes so conectadas interface atravs de um relacionamento de notao similar do relacionamento de dependncia.
92
92
Interface (cont)
public interface ElementoDiagrama { double PI = 3.1425926; //static and final constant. void desenhar(); void redimensionar(); } public class Circulo implements ElementoDiagrama { public void desenhar() { /* draw a circle*/ } public void redimensionar() { /* draw a circle*/ } } public class Retangulo implements ElementoDiagrama { public void desenhar() { /* draw a rectangle*/ } public void redimensionar() { /* draw a rectangle*/ } }
93
93

Cap 05 Diagrama de Classes v3

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Cap 05 Diagrama de Classes v3

Загружено:

Авторское право:

Доступные форматы

Princpios de Anlise e Projeto de Sistemas com UML

Captulo 5 Modelagem de Classes de Anlise

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Esse modelo evolui durante o desenvolvimento do SSOO.

H trs nveis sucessivos de detalhamento:

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Objetivo da Modelagem de Classes

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Modelo de Classes de Anlise

Elementos de notao do diagrama de classes normalmente usados na construo do modelo de anlise:

Modelo de Anlise: Foco no Problema

Projeto (Especificao) Venda Pagamento 1 Pago-por 1 -data:Date -hora:Time

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

5.2 Diagrama de classes

Notao na UML: caixa com no mximo trs compartimentos exibidos.

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Exemplo (classe ContaBancria)

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Notao para Associaes

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Muitos para muitos

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Acessrios para Associaes

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Notao para Classes Associativas

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Exemplo (associao ternria)

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Esse o chamado relacionamento de herana.

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Notao definida pela UML

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Note a diferena semntica entre a herana e a associao.

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

No entanto, podem existir classes que no geram instncias diretas.

Classes abstratas so utilizadas para organizar e simplificar uma hierarquia de generalizao.

Notao para classes abstratas

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Refinamento do Modelo com Herana

Refinamento do Modelo com Herana

Barbara Liskov (http://www.pmg.csail.mit.edu/~liskov/)

Restries sobre gen/espec

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

Restries sobre gen/espec

{incompleta} Caminho Trator

{incompleta, disjunta} Quadrado Crculo

{completa, disjunta} Homem Mulher

{incompleta, sobreposta} Nadador Corredor

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

5.3 Diagrama de objetos

nomeClasse nomeObjeto: NomeClasse

Pedido umPedido: Pedido

Princpios de Anlise e Projeto de Sistemas com UML - 2 edio