Diagrama de Classes

UML-1550:!

::I <i.

::I

:i

::I

:I

:3

:3

:3

:3

:I

:3

:I

:3

:iI

:3

:iI

:iI

:ii :iI.

:!i

c f--' o -:( o-c (J ::::> c w f-W Z u,

~ a: o Q.

o '" c « >a: w w '" a: o ' -:(

'" o '" f-Ui a: E

O '" O '" c O f

4 - Diagrama de Classes

• • •

Você aprenderá:

Conceitos

Relacionamentos

Mapeamento de Classes para Banco de Dados Relacional.

159

INSTITUTO INFNET ·159

:3

:!

:I ..: a .... ...J

O -:( o« o :::l o:3 "".... "" z u,

~

O Q.::I li:

a:> O o

> l!J a:> w::I «a:

a: o -:( a:>

:I a:> o !:: l!J a: Õ a:> o a:>

~ o o o ....

:3

:3

:3

~

:li

:8

:11

==

==:11

UML-1550

Conceitos

• Os diagramas de classes servem para mostrar e estrutura física do sistema, identificando as classes, relacionamentos, cardinalidade (multiplicidade) etc.

• Lembre-se que na DA 1 vimos os conceitos de classe, objeto, propriedades e métodos.

• É possível também estender o diagrama de classes para mostrar "instâncias" em um dado cenário de funcionamento (Diagrama de Objetos).

161

Re1embrando: classe é um conjunto de objetos e objeto é uma instância de uma classe. Exemplos de classes: fornecedor, cheque, fatura, cardápio, livro, produto, etc.

Os diagramas de classe são usados para mostrar a estrutura interna do sistema, ou seja, como o sistema deve ser dividido em termos de classes. Ele não mostra como as classes são executadas, quais métodos são chamados e em que sequência, etc.

Em situações bem específicas (por exemplo, sistemas de tempo real) pode ser necessário mostrar os objetos ao invés de classes. Neste caso, basta utilizar o próprio diagrama de classes com a nomenclatura de objetos.

As classes podem ser identificadas a partir do texto dos casos de uso. Entidades descritas nos casos de uso são bons candidatos a classes. Assim se em uma descrição de caso de uso encontra-se a frase "Sistema insere item no carrinho de compras", as entidades "Item" e "Carrinho de Compras" são classes em potencial.

Apesar de ser um dos diagramas da UML mais importantes (e as vezes o único a ser desenhado) o diagrama de classes não mostra todos os pontos de vista de um sistema. Deve ser usado em conjunto com, no mínimo, diagramas de casos de uso e diagramas de sequência.

INSTITUTO INFNET • 161

3

r

<i. c ~ o.« o« o => c w ti; Z u,

~ a: o o.. cn o c « >a: w cn w a:

'0 .« cn cn o !::: w a: C cn o cn o c g

UML-155D

Conceitos • Objetos representam entidades discretas, que

encapsulam estado e comportamento e são definidos por classes.

• O estado é representado pelos atributos do objeto, o comportamento pelas operações.

• Na UML, a classe é representada por um retângulo dividido em três compartimentos representando o nome da classe, os atributos e as operações:

Nome da Classe

-atI:'ibutos

+operações ( )

162

Nas metodologias de modelagem orientadas a objetos, os objetos representam entidades discretas, com fronteira bem definida e identidade própria, que encapsulam estado e comportamento.

O estado é representado pelos atributos do objeto, e o comportamento pelas respectivas operações. Os objetos interagem entre si trocando mensagens, que são invocações das operações.

Na UML, a classe é representada por um retângulo dividido em três compartimentos, que contêm respectivamente: o nome da classe, os atributos e as operações.

Para maior clareza nos diagramas, pode-se suprimir cada um dos compartimentos de atributos e operações, ou deixar de mostrar determinados atributos ou operações.

São opcionais também: a indicação da visibilidade por caracteres ou ícones; a assinatura (lista de argumentos e tipo de retomo) das operações; e o tipo e valor padrão dos atributos.

!-

i!!-

i!-i!•

i•

i-I•

i•

I

i-I

I

I• INSTITUTO INFNET • 162

~

:::I D... --":::I oi.

o o« o

5<[

:::: !.:.:::I :.: z ..... ~ x:::I ., ~

g <[ >

.,~ ~ ~ :>: o

'" >:::I <:

'"o sr x :5

o '" ~ '"'o c

o....

~

:::I

~

:3

:3

ai

===::w :J

:li

UML-1550

Exemplos: Banco Money cont.accxcent;e

- núme co : int -c í cu Iar r 5tcing -eenhar Str ing -saldo; double

«c:reate»+ContaCorrente (nÚIlIe:t"o: int, titular: Strinq, «c:reate»+ContaCOI:rente (núree r c : int) -conauLt.ar'Sa.ldc (): doun Ie -ve Lí.decaenhe taenha : Str:1ng): boo Leen

-ceque.Ja (cc e ctljecq: boo Ieen +qetTJúm~ro(): int +get5aldo tl: double +get5enba (): Str ing +qetTitular {I: Str:Lng +setNÚI:Ile:ro (uúmer o ; :Lct)

+setSaldo (saldo: doublej -cse t senbelaenhar Strlng'l +setTitular (titu.lar:-: String)

senha: Stt"ing, saldo: double)

TelaHenu

+SALDO: 5tring = "Consultar Saldo" +SAIR: String - "Sa1r:" -opção: 5tring '" .'" ~e9: Scring[1;] - { SALDO, SAIR}

+executar (cc: ContaCarrenteJ +getOpçào (): 5tring

I Principal. I

163

o exemplo acima mostra três classes do Banco Money: ContaCorrente (Model), TelaMenu (View) e Principa (Controller). Maiores informações sobre o padrão Model-View-Controller podem ser encontradas no Apêndice A.

Na fase de análise as classes de negócio são identificadas. Classe de negócio é aquela que trata das funcionalidades principais do sistema. A classe ContaCorrente é uma classe de negócio pois ela define os dados e as operações referentes a uma conta corrente:

Em um sistema de agenda eletrônica o objetivo principal é manter os contatos (incluir, buscar, listar, etc). As classes de negócio identificadas são as seguintes:

Contato

-nome -fone -email

+validarNomeO

Agenda

-contatos: Lista de Contato

+inserirContato(contato: Contato) +buscarContato(nome): Contato +listarContatosO: List +buscarContatos(palavra chave: 5tring): List +montarResposta(resultado: List)

INSTITUTO INFNET - 163

~

<i. c ~ o '<l o<l U ::> c w

tu z u,

~ a: o e, CIl o C <l >a: w CIl wa: 'o '<l CIl CIl

g wa: i5 CIl o CIl o c ~

UML-1550

Pacotes • Os pacotes lógicos são agrupamentos de elementos.

• Um sistema pode ser dividido em pacotes para melhorar o entendimento e para aumentar a produtividade.

• Exemplo:

164

Os pacotes lógicos são agrupamentos de elementos de um modelo. No modelo de análise, eles podem ser utilizados para formar grupos de classes com um tema comum para auxiliar a divisão do trabalho na equipe de desenvolvimento.

Existem muitas maneiras de se dividir um sistema em pacotes: subsistemas, tipos de funcionalidades, metodologia de desenvolvimento, etc.

Em termos de implementação, pacotes são pastas que contém os fontes e binários das classes e outros recursos.

A figura acima mostra uma possível divisão dentro de um projeto que utiliza o padrão MVC de desenvolvimento. O pacote view contém as classes de apresentação, o pacote controller as classes de controle e o pacote model as classes de negócio. Este pacote é subdivido em outros dois: o pacote model.dao contém as classes de integração e acesso a banco de dados (Data Access Objects) e o pacote model.to contém as classes de transporte de dados (Transfer Objects).

f-~-~--I!-~-

t!!-

INSTITUTO INFNET -164

::I

:I

::I

~

::I

:3

:I

::I

:I

::I

:I

:I

=t

=t

:3

:3

~

:2

~

~

EiI

~ -' ::l < o< 5 ~ ~ z u, ;?;

5 Q.. ::> :2 :;;r >

.,'" z:

'":L

o -e '" '"o !üü :L Õ

'"o '"o o ~

L1ML -1550

Exemplos de Pacotes

--"""I --"""I ca.lendário rela.t;ório3

165

Os pacotes acima mostram outros tipos de divisões possíveis:

Pacotes para classes com funcionalidades afins: util, rede, arquivo.

Pacotes para classes de negócio que fazem parte de processos comuns: calendário, estoque, relatórios.

Linguagens modernas possuem algum tipo de divisão semelhante a pacotes. Java possui o conceito de "package" enquanto a plataforma .NET possui o conceito de "namespace". Ambos auxiliam a equipe de desenvolvimento a estruturar melhor suas classes e componentes.

Pacotes são muito úteis no reaproveitamento de esforços pois mantém uma identificação única que pode ser usada em todos os sistemas.


-~ ~---~~~~

 c w ti; Z LL ~ a: o Q.

cn o c ~ a: w cn w a: 'o .« cn cn o l:: w a: Õ cn o cn o c ~

UML-I550

Visibilidade .

• Os tipos de acesso possíveis aos membros de uma classe (atributos, métodos) são: - Público (+): a propriedade ou método da

classe pode ser acessado por todas as demais entidades do sistema;

- Protegido (#) : o acesso aos membros da classe só é permitido a classes da mesma hierarquia;

- Privado (-) : o acesso aos membros da classe só é permitido aos métodos da própria classe.

166

Uma classe pode definir o tipo de acesso que seus membros (propriedades e métodos) permitirão às demais partes do sistema.

Em uma escala progressiva de "privacidade" dos membros, os tipos de acesso possíveis são público, protegido e privado.

Os tipos de acesso a operações ou atributos de cada classe incluem:

Público:

Qualquer outra classe pode usar;

Símbolo "+";

Protegido: li Só subclasses dessa classe podem usar;

Símbolo "#"; li Privado:

Nenhuma outra classe pode usar diretamente •Símbolo "-";

I As implementações de visibilidade das linguagens modernas oferecem outros tipos de

visibilidade como pacote (Java) e internal (.NET). I-I

INSTITUTO INFNET -166 Ji-

UML -1550

Visibilidade

-<-<cr-eat:e)-)-+Cont.aCorrente.(núrnero: rnc , -c-ccr-eeueoc-i-cont.ecocr ence (número: int) -i-coneuLt.ar.seLdo O: double +val~darse.nh8.(~enha: String): baolean +equals [c c e cc jectn : boolean +qetNÚ1:I:Iero (): int

+getSaldo t l: douc Le +getSe::nha (j; Str ínlJ" +getTitulaJ:" (): StrinlJ" +setNúme::ro (nÚlIle.ro: int) +setSaldo [aatdo : doub Le] -eeuaenhe (se.nna: St.ring) r ccc'racu.rar (titUlar: Scr1ng)

t.1cular: String, aenhe e 5trinlJ, eeLdo t double.]

167

A figura mostra a classe ContaCorrente com as suas propriedades e métodos. Do lado esquerdo destas propriedades e métodos existem os sinais que indicam a visibilidade do elemento.

Todos os atributos estão definidos como private e todos os métodos como públicos. Esta é uma boa prática pois protege atributos de acessos externos. Entretanto esta regra não é rígida, já que é bastante comum encontrar métodos privativos (métodos que executam tarefas específicas para a classe) e atributos constantes públicos (constantes não mudam -de valor portanto se forem definidas como públicas não possuem problemas de alteração fora da classe).

Para alterar atributos privativos são criados métodos "set". Estes métodos simplesmente atualizam o atributo com o valor passado como parâmetro. Para recuperar atributos privativos (para serem mostrados em uma tela por exemplo) são criados métodos "get" que retomam o atributo desejado. As ferramentas de desenvolvimento normalmente geram estes métodos de maneira automárica.

A grande vantagem desta abordagem é a criação de pontos únicos de acesso aos dados. Qualquer classe que precise alterar ou recuperar o atributo de outra deve utilizar os métodos. Assim sempre que for necessária fazer uma alteração no código de alteração ou recuperação, ela será feita em apenas um local.


=t

:r. ::I

:i

:I

:J

:I

::I

::I

~

~

~

~

:iI

=~

=:w :fi

~

ãtI

<i. <1 ..... J

o o« o<o: o ::l <1 OJ

..... OJ Z u,

~

'"o e, :Il o <1 « >'"w.., I!J

'" o o« :Il.., o ..... iii

Õ'" .., o.., o <1 o .....

-crúrneco . int -ct Lt.u Lar : String -senha: Scring -salda: do ub Le

~ ~ o

'<1: o. <I: U ::J C w I w Z u,

~ cc o c. C/l o c ~ cc w C/l w cc 'O '<I: C/l C/l

~ ii:i cc Õ C/lo C/lo c o I

UML-I550

Como Identificar Classes?

• As classes de um sistema podem ser identificadas a partir de um diagrama de casos de uso e suas

!I;descrições.

• Liste todas as entidades (tipos complexos) que forem encontradas nas descrições.

• Verifique se entre estas entidades não existe alguma relação, como por exemplo:

Elas são sinônimos?

Uma contém a outra?

- Ambas tem muitos métodos e atributos em comum?

168

Uma das maiores dificuldades para quem está começando a trabalhar com orientação a objetos é como identificar as classes. A experiência ajuda bastanta mas para quem não a tem existem algumas técnicas que ajudam encontrar as classes de um sistema.

Uma das maneiras mais simples é identificar as entidades ou tipos complexos encontrados nas descrições dos casos de uso. Em seguida, verifique se cada tipo pode ser uma classe de negócio respondendo a algumas perguntas:

• A entidade tem algum sinônimo ou entidade similar na lista?

• Uma entidade contém outra da lista. Se contém, é necessário deixá-las separadas?

• A entidade contém muitos atributos ou métodos em comum com outra?

• A entidade é realmente complexo e precisa ser tratada de maneira separada?

• A entidade é manipulada pelo sistema?

Como exemplo, considere a descrição do caso de uso "Efetuar Depósito" do capítulo anterior. A lista das entidades seria:

Pessoa, Depósito, Agência, Conta, Gaveta, Comprovante.

Pessoa não é classe pois o sistema não vai manter informações sobre ela.

Depósito não é classe, é um metodo (depositar) da classe Conta.

Agência não é classe pois não faz parte do escopo do sistema a manipulação de agências separadas. 11

Gaveta não é classe pois é apenas um dispositivo controlado pelo nosso sistema. I!Comprovante pode ser uma classe desde que seja necessário guardar informações sobre cada operação que aconteceu.

Conclusão: A identificação de classes depende do contexto e dos requisitos funcionais. Além disso, existem várias soluções possíveis para um mesmo problema. I


-=====================-==c--::==----=---~~~---- ~~ .

~

~ oi.

:;Cl

:=J o <[ o<l: <.J

:=J :::l Cl UJ

~ Z u, ;?;

o'" e,~ o '" Cl <l:

a: UJ

w::J >

'" a: o <[

o '"::i '".... Ui a: o O '" O '"~ Cl O ....

~

~

~

~

~

::I

~

:=!

~

:=t

~

:=!

~

UML-1550

Relacionamentos

• Os possíveis relacionamentos entre classes são os seguintes: - Associação

- Navegabilidade - Dependência

- Agregação

- Composição

- Generalização

) --------------------;>

ô

•

t>

171

Relacionamentos entre classes indicam de que forma as classes devem ser ligadas para cumprir os objetivos. Existem relacionamentos que levam em conta apenas a estrutura das classes (generalização) e outros que são determinados a partir da quantidade de objetos da ligação (associação, agregação, etc.).

Os tipos de relacionamentos da figura acima tem os seguintes significados:

Associação: indica que duas classes tem um relacionamento forte e duradouro. Normalmente uma possui um atributo de referência para a outra.

Navegabilidade (Associação Direta): apenas uma das classes "conhece" a outra.

Dependência: a execução de uma das classes depende da existência da outra.

Agregação: uma classe representando um todo contém classes que representam partes.

Composição: idem a anterior mas as partes não existem sem o todo.

Generalização (Herança): uma classe (subclasse) herda atributras e métodos de outra classe (superclasse) .


-- --- ----~------ - ---------------~

I

..: c !:i o '<c ~ U :J C w lu z u,

~ lI: o D..

o '" c <C >lI: w w '" ee o '<c '" o '" !:: w lI: Õ

o '" tn o c o I

UML-I550

Associação • A associação é o relacionamento entre classes,

representada por um traço simples. • As associações podem expressar relações

bidirecionais entre classes. • Faz parte das responsabilidades de um objeto de

uma das classes determinar os objetos correspondentes da outra classe.

• Normalmente uma associação é implementada com atributos. Assim, se um pedido está relacionado a um cliente, este relacionamento pode ser implementado colocando-se um atributo do tipo cliente dentro da classe pedido.

172

As associações indicam a possibilidade de comunicação direta entre os respectivos objetos. Isso significa que faz parte das responsabilidades de um objeto de urna das classes determinar os objetos correspondentes da outra classe. É comum existir em cada classe operações para cumprir essa responsabilidade.

Normalmente urna associação é implementada com atributos. Assim, se um pedido está relacionado a um cliente, este relacionamento pode ser implementado colocando-se um atributo do tipo cliente dentro da classe pedido e urna lista de pedidos em cada cliente. Desta forma é possível identificar pelo pedido qual é o cliente que o efetuou e pelo cliente, quais são os pedidos realizados.

INSTITUTO INFNET - 172 '~-

UML-1550

Exemplos

Empresa Produto

Aluno Curso

173

A figura mostra que existe algum tipo de colaboração entre a classe Empresa e a classe Produto. Podemos entender isso quando perguntamos a uma determinada empresa que produtos ela fornece. Da mesma forma podemos perguntar a um determinado produto que empresas podem fornecê-lo.

Também pode ser visto que existe algum tipo de relacionamento entre aluno e curso: um aluno se matricula em vários cursos e um curso pode ter vários alunos.

Mesmo sabendo que existem atributos para representar estes relacionamentos, eles não devem ser escritos nas classes de negócio. O objetivo das classes nesta fase é iniciar a elaboração de uma solução, portanto o entendimento do relacionamento entre as classes é mais importante do que a exata maneira como serão implementadas.

Quando for necessário criar classes de projeto estes atributos poderão aparecer para tomar mais claro qual o nome e tipo do atributo. Por exemplo, um relacionamento de um para muitos pode ser implementado como um vetor, lista encadeada, tabela hash, etc.

::I

::iI

~

~

~

~

::I

::J

::I

::I

::I

~

~

~

:J

~

:I

:I

:3

::J

<i. Q

~

o >« o-

5«o

"-' ;

~ ~ OI: o e, a> o c « >c:: !l.l! a>

~ o >«., a> o ; a c:: s., o., o c o f-


~

r

tI: W Ul w tI: o

'<CUl Ul g W tI: 5 Ul o Ul o c ~

UML-I550

Multiplicidade e Papéis • A especificação das associações inclui o seu

nome, descrição e possíveis restrições. • Em certos casos, é útil batizar também os papéis,

assim como especificar vários detalhes destes. • Os nomes das associações devem ser simples e

significativos. • Uma convenção habitual é batizar o

relacionamento de modo que ele seja lido corretamente de cima para baixo ou da esquerda para a direita.

174

A especificação das associações inclui o seu nome, descrição e possíveis restrições.

Em certos casos, é útil batizar também os papéis, assim como especificar vários detalhes destes.

Os nomes das associações devem ser simples e significativos. Recomenda-se usar um substantivo que descreva bem a semântica do relacionamento. Pode-se também usar um verbo, ~desde que esteja claro qual classe é sujeito e qual classe é objeto desse verbo.

Uma convenção habitual é batizar o relacionamento de modo que ele seja lido corretamente de cima para baixo ou da esquerda para a direita.

De acordo com a UML, um pequeno triângulo pode ser usado para indicar a direção de leitura, caso necessário.

w-

! INSTITUTO INFNET -174 -•

UML-1550

Multiplicidade

• A multiplicidade de um participante em um relacionamento indica quantos objetos de uma classe se relacionam com cada objeto da outra classe.

0..1 1

O..'" 1.,'". n

O..n l..n

Zero ou um Somente um Zero ou muitos Um ou muitos Muitos (maior do que 1) Muitos (maior do que 1) Zero ou muitos Um ou muitos ~

175

A multiplicidade de um participante de um relacionamento indica quantos objetos de uma classe se relacionam com cada objeto da outra classe. Relacionamentos obrigatórios têm multiplicidade mínima 1.

A multiplicidade máxima indica o número máximo de instâncias da classe alvo que podem existir simultaneamente.

Os tipos de relacionamento que podem ter a indicação de multiplicidade são: associação, navegabilidade, agregação e composição. Nos demais, não faz sentido indicar multiplicidade pois não existe a conotação de quantidade de objetos da ligação.

::J

:=I

::I

~

:I

::I

::I

~

::I

:I

~

~

~

:3

~

~

:3

:;t.

~

::I

oi. 2: -' c -e o-c o :> :::l LI

Ll Z L

~

6 a,

o '" c « > >lJ '" '" '" -o: '"o'" '" 2 :;:;

õ'"., o '" '" oo ....

INSTITUTO INFNET • 175

~

--l

 o w I w Z

z LL

o: o o. CIl o o ~ o: w ffi

,o: o

'Cl:CIl CIl o !::: wo: Õ CIl o CIl o o o I

UML-I550

Exemplo de Multiplicidade

0..* Empresa Mercadoria

0..*

0..1

1..*

Pessoa

176

No exemplo foi modelado o fato de que urna "Pessoa" poder estar ligada a nenhuma ou urna "Empresa", ou seja, podemos cadastrar um desempregado. Enquanto urna "Empresa" poder estar relacionada com, no mínimo urna instância de "Pessoa",

Urna "Empresa" pode estar relacionada com zero ou mais instâncias de "Mercadoria" (por exemplo, fornecer) e urna mercadoria pode ser fornecida por nenhuma (mercadoria obsoleta) ou muitas empresas.

Um álbum possui de nenhuma a muitas figurinhas:

ÁThwn-------------"'-1 FigurinhaO., .

Durante um campeonato, um time pode possuir muitos jogadores e um jogador pode ser de vários times (devido a transferências por exemplo):

Jogador

'" Time---1-1.-''''----------1

li]-

INSTITUTO INFNET - 176 I!-

:s :::I

:3 oi o t ....I

o < o<C

::> o ur:=I o

ti; z e,

:r. :!: tI: o e, Cf)

o o <C :> tI: w Cf) ~ w tI: o

:=I Cf) "'" Cf)

o t: w o: Õ Cf)

o Cf)~ o o o...

~

~

:I

~

~

=:iI

~

:3

::JI

~

::li

:a

UML-1550

Papéis

• Os papéis são denominações que exprimem em que qualidade um objeto de uma das classes do se relaciona com um objeto da outra classe.

Ifornecedor fornece ~ ProdutO. I M dorí IE lo.' ,I erca orlarnpresaI O. 'I '-----------'

empregador 0..1

emprega

empregado Pessoa I

177

Os papéis são denominações que exprimem em que qualidade um objeto de urna das classes do relacionamento se relaciona com um objeto da outra classe.

Os papéis dos participantes devem ser batizados explicitamente quando participarem de um relacionamento em urna qualidade que não é implícita no respectivo nome da classe.

Cuidado para não poluir o diagrama !

Na figura acima, um objeto da classe "Empresa" participa no papel de "fornecedor" do relacionamento "Fornece", com zero ou mais objetos da classe "Mercadoria", e um objeto dessa classe se relaciona com zero ou mais objetos da classe "Empresa" na qualidade de "produto".

Urna "Empresa" pode participar de outros relacionamentos em outras qualidades; por exemplo, no papel de "empregador", em um relacionamento "Emprega" com um objeto da classe "Pessoa".


---

<i. c !::i a .« C> « (.J ::J C W I W Z u,

:?: a: a o.. (fj a c « >a: w (fj w !Ia.« (fj

(fj a I u;a: Õ (fj a (fj a c a I-

t= UML-1550

,-r!:Auto-Relacionamento

I:• Ocorre quando há necessidade de relacionar dois objetos de uma mesma classe. r-Pessoa Dependente E

nome 1 possui 0 ..* nome dt nascimento f-=-------'=='-='--------'=--j dt nascimento

~ -. ,€I~li Possui dependentes

! E~~ ~..* ~-

180 r-o exemplo acima indica que uma pessoa pode possuir dependentes. Entretanto, não há

necessidade de se criar uma classe específica, pois dependentes também são pessoas. Desta forma a indicação de relacionamento entre pessoa e dependente é feita com um auto-relacionamento. A descrição deve mostrar claramente qual a relação semântica existente dentro da classe.

Em uma empresa, um empregado pode ter a identificação de guem é o seu chefe:

+chefiadopor

Uma ianela de um si botões.caixas di_:lg-I~.,ma jane a e um SIstema U./!,.HlvlUH<U 5l<UlvU ./!u"",UI VarIOS componentes: otoes, carxas e texto, menus e.o. janelas! Portanto existem relacionamentos comuns e um auto-relacionamento:

__1 icompOSJtapor

~--- Jan.e1a i ~ 0 ..*


,----------

3

:ti

-~ <' :;;>

~ rr~ i: z ..... ~

:11 ~

« > =- :c

~

:LJ :: a:"" <'

2'":::I :c

:i:i :I: s

:3 ., o'"o '" 2

:;I

~

~ ~ ~ F

~

UML-155D

Classe Associativa

• Ocorre quando há necessidade de colocar informação em uma associação.

+dataAdmissao +salariolnic:ial +c:e.rgo

Emprego

Empresa 1--------'-----\ Pessoa I

181

,_ Os dados de emprego só existem se houver uma pessoa e uma empresa. Se não houver esta associação não existirá nenhum objeto da classe emprego.

Este tipo de relacionamento só deve ser criado quando a classe associativa possuir atributos ou métodos específicos.

A classe associativa ajuda no entendimento do problema e na estruturação da solução, mas deixa margem para dúvidas no momento da implementação. Para dirimir estas dúvidas, uma classe associativa é convertida para uma classe comum no momento da definição das classes de projeto. No caso do exemplo acima, os relacionamentos entre as classes de projeto seriam:

Emprego

+dataAd1't'Jissao : Pessoa II Empresa: 1 +salariolnicial

1..* 0..* 1 +ca~go


--

 c w I W Z 1L ;; o:: o D.. Ul o c ~ o:: w Ul W 0::.

o.« Ul Ul

~ m o:: Õ in o Ul o c ~

UML-l55O

Dependência . • Relacionamento de dependência é uma relação

fraca, indicando que uma classe usa outra mas não possui nenhum atributo permanente dela.

• É representada por um traço pontilhado e direcionado.

• Como identificar dependências? - Quando uma classe tem uma operação que usa uma

instância de outra classe como parâmetro; - Uma classe chama uma operação que é de escopo de

outra classe. - Uma operação retoma um objeto de outra classe

182

A associação vista anteriormente é um relacionamento forte pois implica na existência de um atributo de ligação entre as classes.

Existem situações nas quais esta ligação é temporária e portanto a associação não é a melhor forma de explicitar o relacionamento.

Por exemplo, se uma classe apenas chama métodos de outra, recebe um objeto de outra classe como parâmetro ou se cria objetos de outra dentro de um método (escopo local) então o relacionamento é uma dependência.

A dependência indica que uma classe depende de outra ou que ela "usa" outra classe. Ou seja, a existência de uma classe depende da existência da outra.

lI!:

INSTITUTO INFNET - 1S2 "tE

::I

~

:::I

:::I

::I

:I

::I

::I

::I

~

~

~

:J

:J

:a ::I

;a

~

~

~

:li

 '" :r J.::l

'" :r ~

o o« '" a '" .... ii] Oi: s., o., a o a !

UML-1550

Exemplos de Dependência

• A classe Círculo possui métodos que usam a constante PI de Math:

Círcu10 Kath

-raio - - ---- - - - - --,;> +PI = 3.141592

+calcularA.rea () +calcularPerimetro()

• TelaMenu possui O método "executar" que recebe uma conta como parâmetro:

TeLaKenu ____ u _________ uu ______ ~ ContaCorrente

+executar(cc: ContaCorrente) +getOpção(): String I

183

I

No primeiro exemplo acima, a classe Círculo possui dois métodos (calcularArea e calcularPerimetro) que utilizam localmente a classe Math para recuperar o valor da constante PI. O uso da classe Math é temporário (escopo local), apenas dentro dos referidos métodos, portanto o relacionamento é de dependência.

No segundo exemplo, a classe TelaMenu deve mostrar o nome do titular em cima do menu. Portanto, precisa da informação da conta corrente atual. Este objetivo é alcançado passando-se a conta atual como parâmetro para o método executar, responsável pela exibição do menu. Este método recupera o nome do titular, exibe-o e retoma. Mais uma vez o relacionamento foi temporário e deve ser representado como uma dependência.

Abaixo um outro exemplo, no qual uma tela que mostra todas as vendas de um determinado mês precisa mostrar para cada venda a data que ela foi efetuada. A data deve ser formatada com o método formatar da classe FormatadorDeData. Este método é chamado dentro do método exibirVendas, portanto o relacionamento é de dependência.

TelaDeVendas FonmatadorDeData I------------L _

:;.:

+ex ib irVendas ( ) +:formatar ()


~ !:i o "<t C> o« o :::> c w

tü z u, ~ o: o D. CJl o C o« >o: w ffi o: o.0« CJl CJl o liio: c CJl o ~ c ~

UML-I550

Navegabilidade • Todas as classes de um relacionamento de associação

"conhecem" as outras, ou seja, possuem atributos das outras classes.

• Para indicar uma direção para a associação é usada a navegabilidade ou associação direta.

• No exemplo abaixo, agência "conhece" ContaCorrente, mas o contrário não é verdade:

Agencia ContaCorrente::-1

1,,° I

184

Todas as classes de um relacionamento de associação "conhecem" as outras, ou seja, possuem atributos das outras classes. Assim, em urna associação comum, por exemplo, entre contrato e cliente, a classe Contrato possui um atributo para cliente enquanto a classe Cliente possui um atributo para a classe Contrato.

Muitas vezes esta característica não é necessária ou não é desejável. Para indicar que apenas urna das classes "conhece" a outra, usa-se a navegabilidade.

No exemplo acima, a seta indica que a classe Agência tem a responsabilidade de localiza .::. ContaCorrente, ou seja, Agência tem algum identificador de cliente para que seja possível .::. localização das contas correntes que ela possui. A classe ContaCorrente não tem corno saber a qua. agência pertence.

Mais um exemplo: urna agenda possui urna lista de contatos mas cada contato não precis; "conhecer" sua agenda pois sempre que for necessário acessar um contato, será feito um ped.; =

para a agenda.

AgendaI Contato 1-==<::--1-,,-*---- _

It INSTITUTO INFNE""" - -~

~

:=I

-:< 'J=- ~

~

~ =2 ;:; :;; Z .L.

~

~ ~

~ ;;: :> OI:: LC.,~ U

.. OI:: C

g::I ::

~ 5

:I :::

'" :J

~ õ

:I

::I

~.

:J

=t ::I

=t

:I

:I

~

=:I

UML-1550

Herança

• O relacionamento de herança existe entre classes de natureza mais geral (chamadas de superclasses ou classes bases) e suas especializações (chamadas de subclasses ou classes derivadas).

• As superclasses contêm atributos ou operações comuns a um grupo de subclasses.

185

A herança existe na 00 para facilitar a programação e a manutenção dos programas, pois a codificação dos métodos e definição dos atributos (tipo/tamanho) estará em um único lugar (na superclasse) e será aproveitado por todas as subclasses.

O relacionamento de herança existe entre classes de natureza mais geral (chamadas de superclasses, classes base, classes pai) e suas especializações (chamadas. de subclasses, classes derivadas, classes filha). As superclasses contêm atributos ou operações comuns a um grupo de subclasses.

As subclasses herdam todos os atributos e métodos das superclasses. Este fato facilita o desenvolvimento de software, principalmente a manutenção e a extensibilidade, pois mudanças são feitas em locais bem específicos com um mínimo de impacto para o restante do sistema.

INSTITUTO INFNET· 185

~

~ o I...J

o,« o« o ::::> o w IW Z u,

~ li: o c. in o o ~ li: w [fi li: O·,« Cf) Cf)

f2 Ui li: Õ Cf) O Cf) O o O I

UML-1550

Exemplos de Herança

ContaCorrente

Pessoa-número -titular -nome -saldo -endereç;o-senha

-fone +sacar () -email +depositar () +consultarSaldo()

I A1unoProfessor

-curso-títulaçâoMáxima ContaEspecial -turma

-limite

+sacar ()

-disciplinasHabilitadas

186

No primeiro exemplo existem dois tipos de conta corrente: contas comuns e contas especiais. A única diferença entre elas está no atributo limite, que indica o valor que a conta pode ficar negativa. Portanto, uma solução bem simples e poderosa é criar a conta especial como subclasse de conta corrente. Assim, a conta especial herda todos os atributos e métodos de sua superclasse e especifica os seus próprios. No caso, o método sacar foi reescrito pois a operação de ambas difere com relação ao limite.

No segundo exemplo, uma escola precisa controlar seus professores e alunos. Estas duas entidades possuem muitas coisas em comum que são capturadas por uma superclasse denominada Pessoa.

Uma empresa que vende cds e dvds pode modelar seu sistema da forma abaixo, 'Itconsiderando que cds e dvds possuem atributos em comum (título, preço, estoque, etc):

Produto

~ I I CD DVD


~

:I

:i ..: => :... o <[ o<l

:> c w:I u

f-W Z u, ~

o e,:t c:

Cll o C <l >c: w Cll ~ ur c: o <[

'" '"o~ to ur c: Õ

o ~ '"o

'" c o f

:3

:J

~

:s ~

~

::J

::I

~

:t

:3

::I

=

UML-1550

Classes Abstratas _ • As classes abstratas não permitem instanciar

objetos pois definem "conceitos". • São usadas somente para descrever atributos,

operações e associações comuns que serão herdados pelas subclasses.

• Uma classe abstrata pode conter operações abstratas. São operações cuja implementação não é especificado na superclasse, somente sua assinatura.

• As classes que herdarem essa operação deverão implementá-la, sendo a implementação diferente para cada classe, ou mantê-la abstrata.

Existem situações em que superclasses são criadas apenas para definir características comuns a um conjunto de subclasses. Estas superclasses não deverão ser instanciadas pois não foram projetadas para este fim.

Este tipo de classe é denominada de classe abstrata e é identificada no diagrama de classes com o nome em itálico.

Uma classe abstrata pode conter métodos com implementação e métodos "vazios". São métodos cuja implementação não é especificado na superclasse, somente sua assinatura e também são denominados de abstratos.

Normalmente as classes que herdarem o método irão implementá-lo. Caso não o façam, também devem ser declaradas como abstratas, pois não podem ser instanciadas.


---------~~._~----=~=~~~........_-_-....~ ........._~===..-~.

-c

« D

':i o .<t ou => D w

tu z u,

~ o: o D. cn o D <t 6: w cn w o: o .<t cn cn o !::: w o: Õ cn o cn o D o I

UML-1550

~-Exemplo de Classe Abstrata

Funcionaria

-mat.r í.cui e

-nome -cargo -dataAdn1issao

Mensalista -dataDemissaa I

-salaria L--- +demitir ()

+demitir (data) +calcularSalario() +cd1 cu1dIS d1 "xi o ()

r-r-f;;

I r-'I

Vendedor Horista r-ccomí.aaeo -valo:LHora --totalVendss <t.ot.e ijror-ea

+calcularSalario() +calcularSalario()

1BB

o exemplo acima mostra uma situação típica para a criação de uma classe abstrata. Em um sistema de Folha de Pagamento, a classe Funcionario nunca deve ser instanciada. Portanto ela é declarada como abstrata (nome da classe em itálico). Eventualmente classes abstratas podem possuir métodos abstratos, ou seja, métodos que não possuem implementação. Estes métodos também são escritos em itálico e normalmente são implementados nas subclasses.

No exemplo, todas as subclasses (Mensalista, Vendedor e Horista) implementam o método calcularSalario e portanto podem ser instanciadas e usadas no sistema.

Na mesma loja de cds e dvds vista anteriormente, a classe produto não tem objetos instanciados já que todas as operações são feitas com cds e dvds. Portanto, produto pode ser modelado como uma classe abstrata: Ir-,

Produto

~ I I CD DVD


:s

==- ..-

~

::>

~ i:~ i: z .... ~

!õ ~ i:.

=- .. ..!!r

::> .tl lO a r

'" ~ ~

li

E ~

~ ~

==~

~

:s

=:ti

=: =-, ;ti

:ti

UML-1550

Agregação

• Um relacionamento de agregação é uma associação que reflete a construção física ou a posse lógica.

• Os relacionamentos de agregação são casos particulares dos relacionamentos de associação e indicam um todo que contém partes.

189

Um relacionamento de agregação é uma associação que reflete a construção física ou a posse lógica, ou seja, um objeto é constituído de outros ou possui outros objetos.

Os relacionamentos de agregação são casos particulares dos relacionamentos de associação, e só é necessário distingui-los quando for conveniente enfatizar o caráter "todo-parte" do relacionamento.

Geralmente um relacionamento de agregação é caracterizado pela presença da expressão "parte de" na descrição do relacionamento, e pela assimetria da navegação.

Em um relaciomento de agregação, a parte pode existir sem o todo ou então fazer parte de outro todo.

INSTITUTO INFNET - 189 =

<i. o ~ o '<C o<C (J :::l o W I W Z u. ~ tI: o C-Ul o o :; tI: W Ul W tI: O· I<C Ul Ul o l m tI: Õ Ul o Ul o o o I

UML-1550

Exemplos de Agregação

Prato

190

As figuras acima mostram dois relacionamentos de agregação.

O primeiro exemplo faz parte de um sistema de controle e geração de contratos. Um contrato é composto de textos genéricos, templates que valem para diversos tipos de contrato, Um texto genérico pode fazer parte de vários contratos, portanto o relacionamento é de agregação.

O segundo exemplo é de um restaurante que vende refeições industriais. Existe um sistema que gera cardápios automaticamente, sendo que os cardápios são compostos de pratos. Um prato pode fazer parte de vários dias (peixe de novel) o que configura um relacionamento de agregação.

'~


C:J

:3

:i

:I

~

~

~

~

~

:I

:I

~

:I

::i

:i

:I

~

:3

~

:iI

:!I

 ao tLI

ffl '" o "'" '" g'" iü

'"ã

'"o o '" a o .....

UML-1550

Composição '" • E um tipo mais forte de relacionamento tode prte onde o todo é composto pelas partes.

• Nesse caso, os objetos da "parte" não têm existência independente do "todo". '" • E uma especialização da Agregação.

191

Existe outro tipo de relacionamento semelhante ao de agregação: a composição. A diferença entre os dois está no fato de que na composição, a parte não existe sem o todo e não pode fazer parte de outro todo. Além disso, caso o "todo" seja eliminado, todas as suas "partes" também serão excluídas.


 c w f W Z LL

~ o:: o D. CIJ o c « >o:: w CIJ W 0::' o.« CIJ CIJ o f Ui o:: 15 CIJ o CIJ o c o f

UML-I550 :~

E: I!I:

'I:

TextoEspecí:fico

Exemplos de Composição

NotaFiscal

ItemDaNotaFiscal

192

Dois exemplos de composição:

O primeiro exemplo também faz parte do sistema de controle de contratos. Cada contrato tem textos específicos, dependentes de cada negociação. Um texto específico não faz parte de outro contrato.

Os itens de uma nota fiscal fazem parte apenas de uma nota, não podendo existir em outras notas fiscais.

Como existe a obrigatoriedade de ser parte de apenas um todo, ambos os exemplos são representações de uma composição.


=s ::I

 c l!J:I «o

f-W Z lL

a: o "'"o

::I ~

c « >a:

~ '" ww a:

'" f:I «

'"

o

o Ui a: Õ

O

O::I '" '" c O f

:I

:3

:I

:I

::I

:I

:I

:I

:!

:I

::i

:=I

=i

UML-1550

Mapeamento Objeto - BD Relacional

• Como projetar o banco de dados a partir de um modelo de classes?

• Como ficam as classes persistentes?

• Como ficam as classes transientes?

• Como ficam os atributos?

• Como ficam os relacionamentos ?

197

o objetivo deste bloco de construção é mostrar onde se encaixa a implementação da modelagem e corno é feita esta transição do modelo para o banco de dados relacional.

Atualmente existem diversos frameworks que auxiliam este trabalho, aumentando de forma significativa a produtividade.

As perguntas que devem ser respondidas no momento em que o diagrama de classes tiver que ser convertido para o banco de dados são as seguintes:

Corno os relacionamentos serão modelados no banco de dados? Associação, navegabilidade, agregação, composição e generalização influenciam o projeto dos dados de que forma?

As classes que devem ser persistidas serão convertidas em quantas tabelas? Urna tabela por classe?

As respostas dependem do contexto do sistema mas algumas diretrizes gerais podem ser seguidas.


<i. o !:; o .« C> « o ::> o w IW Z u, ~ a: o c.

'"o o « >a: w w '" a: o.« '" o'"l-m a: 15

'"o o'"o o I

UML-1550

Mapeamento Objeto - BD Relacional r-• Classes Simples -7Tabelas com chave

primária + atributos da classe

• Agregações e Composições: - N:M - tabela intermediária

- N:l campo de relacionamento na tabela com multiplicidade N

- 1:1 - campo em uma das tabelas

~-r

~

~

! i: 198

Classes isoladas que devam ser persistidas são convertidas para uma tabela que possui uma chave primária e os atributos da classe. Eventualmente a chave primária pode estar entre os atributos já definidos. Se não estiver, pode ser criado um üID (identificador de objeto) numérico para representar a chave primária.

Agregações e composições seguem as mesmas regras das formas normais. No caso de relacionamentos N:M cria-se uma tabela intermediária cuja chave primária seja a junção das chaves primárias das tabelas originais. Para relacionamentos 1:N, o campo de relacionamento (chave estrangeira) será colocado na tabela com multiplicidade N. Para relacionamentos 1:1, o campo de relacionamento pode ficar em qualquer tabela.

~-

---

.I!,


--------

~

~

..: => .....~ :J < <;> <{ ';.l ::t

~ ª:;: z... ~

=s ~ '"Q

~ ...:I <

E'" o

:I -e = :: o

i: :i o

~ '" o '" ::l o

:I

=:I

:I

:I

~

;:a

~

~

~

~

:11

•

UML-1550

Mapeamento de Atributos

• Atributo simples - coluna na tabela

• Atributo composto - uma coluna para cada parte do atributo

• Atributo com múltiplos valores - tabela intermediária na qual a chave primária é a chave da tabela de origem + atributo

199

A conversão de atributos para colunas é feito de forma direta:

Atributos simples são mapeados em colunas simples. Atributos compostos são mapeados com uma coluna para cada campo do atributo. Atributos com múltiplos valors são convertidos em tabelas que possuem como chave primária o valor do atributo e a chave primária da tabela original.


 <C U ::> o w f w Z u,

ao a: o D.. Ul o o ~ a: w Ul w a: o '<CUl Ul o !:: w a: Õ Ul o Ul o o ~

iii -....

ii -;:•..

ii..

Hierarquias de classes possuem várias soluções na conversão para banco de dados relacional. Cada caso deve ser analisado para que se possa identificar qual solução é mais eficiente.

As possíveis soluções são:

Uma tabela por classe da hierarquia

..fUma tabela para toda a hierarquia

Uma tabela para cada classe concreta.

E.. r-iii..... r-

UML-1550

Generalizações .

• Soluções para a conversão de hierarquias de classes em tabelas de bancos de dados relacionais: - Uma tabela por classe

- Uma tabela para toda a hierarquia

- Uma tabela por classe concreta

200

.' ...-INSTITUTO INFNET - 200 ..

~

:3

~

~

~

~

~

~

~

~

~

~

~

:iI

=~

=~

=:iI

==

~ --<oco:

s ~

"" Z""Lo

~

~ 2l:

~ <:> E J.:.:J 2l:

E""<2l: 2l:

:: E

.. ~

..cE '5

UML-1550

Uma Tabela Por Classe

• Passos: - Criar uma tabela para cada classe cujos campos são uma

chave primária + atributos específicos da classe - Na tabela da superclasse criar uma coluna tipo

• Vantagens: - Adequado a orientação a objetos - Suporte ao polimorfismo - Extensibilidade

• Desvantagens: - Muitas tabelas - Desempenho - Consultas exigem views

201

Passos para a criação de uma tabela por classe: Criar uma tabela para cada classe. As colunas da tabela serão a chave primária mais os atributos específicos da classe. Atributos herdados não são considerados Na tabela que representa a superclasse criar uma coluna tipo para identificar os possíveis tipos de objetos que serão armazenados.

Vantagens: Adequado a orientação a objetos: uma classe por tabela. Suporte ao polimorfismo: um objeto é inserido em várias tabelas, uma para cada tipo que ele pode assumir. Extensibilidade: novas classes e tabelas são inseridas sem a necessidade de alteração da estrutura anterior.

Desvantagens: Muitas tabelas Desempenho: para construir um objeto é necessário acessar várias tabelas. Consultas exigem views: consultas são difíceis de executar pois são muitas tabelas representando um objeto. E necessário criar views no banco de dados para simular as tabelas necessárias.


:::J

:i c ~::i oi

O Clt <><

Õ .l:J:;i Si!

.l:i Z... ~ :;:::I ~

<ª:I E=

"

>

>:: o Clt

= 2:J =

~ :::;

o =:=I =;:: s

=t

=:I

~

:I

~

:I

~

~

==:iI

:3

UML-1550

Uma Tabela por Classe Concreta

• Passos - Criar uma tabela por classe onde os campos são os

atributos específicos + atributos herdados + chave primária

• Vantagens: - Consultas são mais fáceis

• Desvantagens: - Extensibilidade dificultada - Mudanças de papéis exigem cópias de dados - Dificuldade no suporte a múltiplos papéis

203

Passos para a criação de uma tabela por classe concreta: Criar uma tabela para cada classe. As colunas da tabela serão a chave primária mais os atributos específicos da classe e mais os atributos herdados.

Vantagens: Consultar mais fáceis pois apenas uma tabela é consultada.

Desvantagens: Extensibilidade dificultada, pois a inclusão de um novo atributo causa a necessidade de alteração em várias tabelas. Muitas tabelas Mudança de papéis exige que dados sejam copiados/movidos entre tabelas. É difícil o suporte a múltiplos papéis para o mesmo objeto.


a <t

'" '" a .... 8 :!C C

'" a :l a <:> g

UML-I550

Pontos Importantes• Um diagrama de classes poderá gerar mais ou

menos tabelas do que classes, não tem regra, lembre-se que temos que normalizar os relacionamentos n para n e temos também, classes transientes que não serão implementadas em banco.

• Os métodos podem ser implementados como triggers ou stored procedures no banco ou implementados através da linguagem de programação utilizada, em uma camada de negócios. Pode ser criada uma camada de acesso ao banco (biblioteca).

204

Em uma ferramenta CASE, apesar de não estar visível graficamente, uma classe pode possuir definição de chave primária.

De uma forma geral cada classe será uma tabela, pelo menos as persistentes serão.

Na modelagem de classes não nos preocupamos com normalização, no mapeamento para banco de dados relacional isto será importante.

As restrições do modelo podem ser capturadas em forma de triggers.


í!~•....._n:

== ~ ~

E:::

Documents

Diagrama de Classes