:!

UML-1550

::I

<i.
c
::I f­
--'
o
-:(
o­
4 - Diagrama de Classes
-c
(J
::::>
c
:i w

f-

u,
~
a:
Você aprenderá:
::I
oQ.
oc'" • Conceitos
«
>
a:
: I
'"
w
w
• Relacionamentos
a:
o '
-:(
• Mapeamento de Classes para Banco de
:3 '"o'"
f-
Ui
a: Dados Relacional.
E
'"O
:3 '"cO
O
f­

:3
159

:3
:I
:3
:I
:3
:iI
:3
:iI
:iI
:ii

:iI.
INSTITUTO INFNET ·159
:!i
:3
UML-1550

:!
..:a
....
:I ...J
O
-:(
o­
Conceitos
«
o
:::l
o
:3 ""....
""z
• Os diagramas de classes servem para mostrar e
u,
~ estrutura física do sistema, identificando as
li:

::I O
Q.
a:>
O
classes, relacionamentos, cardinalidade
o
«
>
(multiplicidade) etc.
a:
::I l!J
a:>
w
a:
o
• Lembre-se que na DA 1 vimos os conceitos de
-:(
a:>
a:>
classe, objeto, propriedades e métodos.
:I o
!::
l!J
a: • É possível também estender o diagrama de classes
Õ
a:>
o para mostrar "instâncias" em um dado cenário de
~
a:>
o
o
o
.... funcionamento (Diagrama de Objetos).

:3
161

:3
Re1embrando: classe é um conjunto de objetos e objeto é uma instância de uma classe.
:3 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.
:li 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
:8 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
:11 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.

=­
=­
:11
INSTITUTO INFNET • 161
r

UML-155D

<i.
c
-
!

~
o
.«
o­
Conceitos
«
o
=>
c
w
ti;
• Objetos representam entidades discretas, que
Z
u,
~
encapsulam estado e comportamento e são
a:
o
o..
cn
o
c
«
>
definidos por classes.
• O estado é representado pelos atributos do objeto,
-
i!!

a:
w
cn
w
o comportamento pelas operações.
a:
'0
.« • Na UML, a classe é representada por um retângulo
-
cn
cn
o
!:::
dividido em três compartimentos representando o i!
w
a:
C nome da classe, os atributos e as operações:
cn
o
cn Nome da Classe i!
oc •
g -atI:'ibutos

+operações ( ) i
•
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.
-
i

I
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.
i
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

INSTITUTO INFNET • 162

I
•
~
UML-1550

:::I

oi.
...
D

:::I --"
o
o«
o­
Exemplos: Banco Money

<[

5::::
:::I
cont.accxcent;e
!.:.
- núme co : int
:.: -c cu Iar r 5tcing
í

z
..... -eenhar Str ing
~ -saldo; double
x
:::I .,~
g
«c:reate»+ContaCorrente (nÚIlIe:t"o: int, titular: Strinq, senha: Stt"ing, saldo: double)
«c:reate»+ContaCOI:rente (núree r c : int)
-conau Lt.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
o +setNÚI:Ile:ro (uúmer o ; :Lct)
<:
'o" +setSaldo (saldo: doublej

:::I '">­
sr
x
-cse t senbelaenhar Strlng'l
+setTitular (titu.lar:-: String)

:5
'"o TelaHenu

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

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

163

:::I
~ 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.
:3 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
:3 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,
ai buscar, listar, etc). As classes de negócio identificadas são as seguintes:

=­
=­
Contato Agenda

-nome -contatos: Lista de Contato

-fone

=­::w
+inserirContato(contato: Contato)
-email +buscarContato(nome): Contato
+validarNomeO +listarContatosO: List
+buscarContatos(palavra chave: 5tring): List
+montarResposta(resultado: List)

:J
:li
INSTITUTO INFNET - 163
~

 UML-1550

-
f

-
<i.
~
c
~
o
'<l
o­
Pacotes
<l
U
::>
c
w
tu
z
• Os pacotes lógicos são agrupamentos de elementos.
-
~
• Um sistema pode ser dividido em pacotes para melhorar o
-­
u,
~
a:
oe, entendimento e para aumentar a produtividade. I!
CIl
oC
<l
>
a:
w
CIl
w
a:
• Exemplo:
-

'o
'<l
CIl

CIl

g
w
a:
i5
CIl
o
CIl
oc
~

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.
-
t!!

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

INSTITUTO INFNET -164

::I
L1ML -1550

:I

~
::I
-'
::l
<
Exemplos de Pacotes

o­
<
5
~ ~
~
z
u,
;?;

5
::I Q..
::>
:2
:;;r
>
z:
:3 .,'"
'"
:L
o
-e
'"
:I '"
o
!­
üü
:L
--"""I
ca.lendário
--"""I
rela.t;ório3
Õ
'"
o
::I '"
o
o
~

:I
165

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

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

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

:I
relatórios.
Linguagens modernas possuem algum tipo de divisão semelhante a pacotes. Java possui o
=t
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.
=t
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.

:3

:3

:2

~
INSTITUTO INFNET -165
EiI
-~ ~---~~~~
 UML-I550

<i
o

o
!:J
.« Visibilidade .
~
o
::>
c
w
ti;
Z
• Os tipos de acesso possíveis aos membros
LL
~
a:
oQ.
de uma classe (atributos, métodos) são:
cn
o
c
- Público (+): a propriedade ou método da
~
a:
w
cn
classe pode ser acessado por todas as demais
w
a:
'o entidades do sistema;
.«
cn
o
cn
l::
- Protegido (#) : o acesso aos membros da classe
w
a:
Õ só é permitido a classes da mesma hierarquia;
cn
o
cn
o
c
- 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

-
INSTITUTO INFNET -166
Ji
=t UML -1550

:r.

<i.
<1

::I .....
J
o
o«
o­
Visibilidade

<o:
o
::l

:i <1
OJ
.....
OJ

u,
~

'"
:I o
e,
:Il
o
<1
-crúrneco . int
-ct Lt.u Lar : String
« -senha: Scring
>
..,'"w -salda: do ub Le

:J I!J

o'"
-<-<cr-eat:e)-)-+Cont.aCorrente.(núrnero: rnc , t.1cular: String, aenhe e 5trinlJ, ee Ldo t double.]
-c-ccr-eeueoc-i-cont.ecocr ence (número: int)
-i-coneu Lt.ar.se Ldo O: double
o«
..,o
:Il +val~darse.nh8.(~enha: String): baolean

+equals [c c e cc jectn : boolean

:I .....
iii
+qetNÚ1:I:Iero (): int

+getSaldo t l: douc Le

..,'"o
+getSe::nha ( j ; Str ínlJ"

Õ +getTitulaJ:" (): StrinlJ"

+setNúme::ro (nÚlIle.ro: int)

..,o
::I <1
o
.....
+setSaldo [aa tdo : doub Le]

-eeuaenhe (se.nna: St.ring)

r ccc'racu.rar (titUlar: Scr1ng)

::I
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).
:iI 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.

=­:w
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.

:fi
~
INSTITUTO INFNET -167
ãtI
 UML-I550

~
~
o
'<1:
Como Identificar Classes?
o.
<I:
U
::J
C
w
I­
w
Z
• As classes de um sistema podem ser identificadas a
u,
~ partir de um diagrama de casos de uso e suas
cc
oc.
descrições.
!I;
C/l
o
c
~ • Liste todas as entidades (tipos complexos) que forem
cc
w
C/l
w
cc
'O
encontradas nas descrições.
'<I:
C/l

C/l
• Verifique se entre estas entidades não existe alguma
~
ii:i
cc
Õ
relação, como por exemplo:

C/l
o
C/l
Elas são sinônimos?

oc
o
I­
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.
Comprovante pode ser uma classe desde que seja necessário guardar informações sobre cada operação que I!
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

INSTITUTO INFNET - 168

-=====================-==c--::==----=---~~~---- ~~ .
~
UML-1550

oi.

Relacionamentos
Cl

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

:=J Cl
UJ

~
Z
• Os possíveis relacionamentos entre classes são
u,
;?;

o'e," os seguintes:
~
'"o
Cl - Associação
<l:
>
a:
::J UJ

'"
w
a:
- Navegabilidade )
o
<[ - Dependência --------------------;>
'"
'"
::i o....
Ui
a:
- Agregação ô

o
'"
O - Composição •
~ '"
O
Cl
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.
::I 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) .

:=t
~

:=!
INSTITUTO INFNET - 171
~
-- - - - ----~------ - ---------------~
 UML-I550
I

..:c
!:i
o
'<c
Associação
~
U
:J
C
w • A associação é o relacionamento entre classes,
lu
zu, representada por um traço simples.
~
lI:
oD.. • As associações podem expressar relações
'"o
c
bidirecionais entre classes.
<C
>
lI:
w • Faz parte das responsabilidades de um objeto de
'"eew uma das classes determinar os objetos
o
'<c correspondentes da outra classe.
'"'"o
!::
w
lI:
• Normalmente uma associação é implementada
Õ com atributos. Assim, se um pedido está
'"otn relacionado a um cliente, este relacionamento
o
c
o
I­
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

-
'~
::I
UML-1550

::iI
<i.
Q

~ ~
o
>« Exemplos

o-
«
o
5"-'
~ ;­

~
~ Empresa Produto

~
OI:
o
e,
a>
o
c
«
>
c::

~ !l.l!
a>
~
o
.,
>«

::I
a>
o
;­
ac::
s., Aluno Curso
.,
o
::J
o
c
o
f-

::I

173

::I

::I
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.
:J
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

:I

:3

::J

INSTITUTO INFNET - 173

~

UML-I550

<i
c
~
o
'<C
Multiplicidade e Papéis
~
U
::l
C
w
tiz
• A especificação das associações inclui o seu
u,
a;;
nome, descrição e possíveis restrições.
tI:
o
o..
Ul
• Em certos casos, é útil batizar também os papéis,
o
c
<C
assim como especificar vários detalhes destes.
>
tI:
W
Ul
w • Os nomes das associações devem ser simples e
tI:
o
'<C
Ul

significativos.
Ul

g • Uma convenção habitual é batizar o

W
tI:
5
Ul
relacionamento de modo que ele seja lido
o
Ul
oc 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

-•
::J
UML-1550

:=I

oi.
2:
::I
-'
c
-e
o­
Multiplicidade
-c
o
:>

~
:::l
LI

Ll
Z
• A multiplicidade de um participante em um
L
~
relacionamento indica quantos objetos de
:I
6
a,

'"oc uma classe se relacionam com cada objeto

«
>
da outra classe.
::I
'"
>lJ

'"'"
'"o
-o: 0..1 Zero ou um
'"'"
::I
2
1
O..'"
Somente um
Zero ou muitos
:;:;

.,õ'"
.

1.,'" Um ou muitos
Muitos (maior do que 1)
o n Muitos (maior do que 1)

~ '"o
'"o
O..n
l..n
Zero ou muitos
Um ou muitos ~
....

::I

175

:I

~ 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
:3
não existe a conotação de quantidade de objetos da ligação.

:3

:;t.
~

::I

INSTITUTO INFNET • 175

~

 UML-I550

<i
o

Exemplo de Multiplicidade

I­
--l
o
'Cl:
o­
Cl:
U
::>
o
w
I­
w
Z
LL
z 0..*
o:
o
Empresa Mercadoria
o. 0..*
CIl
o
o 0..1
~
o:
w
ffi
,o:
o
'Cl:
CIl

CIl

o
!:::
w
1..*
o:
Õ
CIl
o Pessoa
CIl
o
o
o
I­

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:

-------------"'-1
ÁThwn

O., .
Figurinha

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

---1-1.-'' '
Time Jogador
-
li]

----------1
'"

INSTITUTO INFNET - 176

-
I!
:s
UML-1550

:::I

oi
o
:3 t­
....I
o
<o­
Papéis
<C
o
::>
:=I o
ur
ti; • Os papéis são denominações que exprimem em que
z
e,

qualidade um objeto de uma das classes do se

:r.
:!:
tI:
oe,
Cf)
oo
relaciona com um objeto da outra classe.
<C
:>

~
tI:
w
Cf) Ernpresa
I fornecedor
lo.' fornece ~ ProdutO.,II M ercadorí
orla I
w
tI:
o
I O. 'I
'-----------'

"'"
Cf) empregador 0..1

:=I Cf)
o
t:
w
o: emprega
Õ
Cf)
o
~ Cf)
o
o
...
o
empregado
Pessoa I
~
177

:I 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
:iI exemplo, no papel de "empregador", em um relacionamento "Emprega" com um objeto da classe
"Pessoa".
~

:3

::JI

::li
:a INSTITUTO INFNET -177
 UML-1550
t=

,-r
<i.
c
!::i
a
.« Auto-Relacionamento !:
C>
«
(.J

I:
::J
C
W
I­
W
• Ocorre quando há necessidade de relacionar
Z
u,

dois objetos de uma mesma classe.

-r
:?:
a:
ao..
(fj
a
c
«
>
a:
w
(fj
w
!I­
Pessoa
nome 1 possui *
0 ..
Dependente
nome

E
a
.« dt nascimento f-=-------'=='-='--------'=--j dt nascimento

(fj
(fj
a
I­
~
-.
u;
a:
Õ
(fj
a
,€I~li Possui dependentes
E
~~
(fj
!
a
c
a
I-

~..*
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 i_:lg-I~.,

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

__
1 icompOSJta
por

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

INSTITUTO INFNET -180

- - - ,----------­
:ti UML-155D

3
~

~ -
<' Classe Associativa
:;;>

~
~ rr
i: • Ocorre quando há necessidade de colocar
z
.....
~
informação em uma associação.
:11 ~
~
«

=-:::I
>
:c
:LJ
::
Emprego
""a:
<'
:c
+dataAdmissao
+salariolnic:ial
'"
2 +c:e.rgo
:i:i
:I:
s.,
o
:3 'o"
'"
2
Empresa 1--------'-----\ Pessoa I
:;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

I
I Empresa: 1
1.. *
+salariolnicial
+ca~go
0.. * 1
: Pessoa

INSTITUTO INFNET -181

 UML-l55O

<i
c

Dependência .
I­
...J
o
.«
o­
«
o
::>
c
w
I­

• Relacionamento de dependência é uma relação lI!:

Z
1L
;; fraca, indicando que uma classe usa outra mas não
o::
oD.. possui nenhum atributo permanente dela.
Ul
o
c
~
• É representada por um traço pontilhado e

o::
w
Ul
W
direcionado.

0::.
o
.«
Ul

• Como identificar dependências?

Ul

~ - Quando uma classe tem uma operação que usa uma

m
o::
Õ
instância de outra classe como parâmetro;
in
o
Ul
- Uma classe chama uma operação que é de escopo de
o
c 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.

INSTITUTO INFNET - 1S2

--
"tE
::I
UML-1550

~
<i
c
:::I
'"""
...l

.4.
Exemplos de Dependência
o­
-c
u
:l

:::I
:::l
.L1
1J • A classe Círculo possui métodos que usam a
zL
~ constante PI de Math:
::I
~
'"
a Círcu10
c
Kath
'"
:> -raio

: I
'":r
J.::l
~
:r
+calcularA.rea ()
+calcularPerimetro()
- - ­ ----­ -­ - - -­ --,;>
+PI = 3.141592

o
o«
'"a
::I
'"
....
ii]
Oi: • TelaMenu possui O método "executar" que recebe
s.,
o., uma conta como parâmetro:
::I
o
a
a TeLaKenu
!­
+executar(cc: ContaCorrente)
____ u _________ u u ______ ~ ContaCorrente

::I
+getOpção(): String I I

183

~
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
:J
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
:J
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
:a
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.
::I
;a TelaDeVendas
I------------L _
:;.:­
FonmatadorDeData

+ex ib irVendas ( ) +:formatar ()

~

~
INSTITUTO INFNET - 183
:li
 UML-I550

~
!:i
o
"<t
C>
o«
Navegabilidade
o
:::>
c
w
• Todas as classes de um relacionamento de associação
tü
z "conhecem" as outras, ou seja, possuem atributos das
u,
~
o:
oD.

outras classes.
CJl

o
C
• Para indicar uma direção para a associação é usada a
o«
>
o:
w
navegabilidade ou associação direta.
ffio:
o
.0«
• No exemplo abaixo, agência "conhece" ContaCorrente,
CJl
CJl
o
mas o contrário não é verdade:
liio:
c
CJl Agencia ContaCorrente
o ::-1
~
c
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.

Agenda
I Contato 1-==<::--1-,,-*---- _

It
INSTITUTO INFNE""" - - ~
~ UML-1550

:=I

=-
~
~
-
:<'J
~
=2
;:;
Herança
:;;
Z
• O relacionamento de herança existe entre
.L.
~
classes de natureza mais geral (chamadas de
~ ~
superclasses ou classes bases) e suas
~
;;:
:>
especializações (chamadas de subclasses ou
~
OI::
.,
LC

..g
U
OI::
C
::
classes derivadas).
::I ~
• As superclasses contêm atributos ou
5
:::
:J
operações comuns a um grupo de
:I '"
~
õ subclasses.
:I

185

::I

~. 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.
:J 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
=t derivadas, classes filha). As superclasses contêm atributos ou operações comuns a um grupo de
subclasses.
::I 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.
=t
:I
:I
~

=­
:I
INSTITUTO INFNET· 185
~

 UML-1550

~
o

Exemplos de Herança
I­
...J
o
,«
o­
«o
::::>
o
w ContaCorrente
I­
W

u, -número Pessoa
~
li:
-titular -nome
oc. -saldo -endereç;o
in -senha
oo -fone

~ +sacar ()
-email

li:
w +depositar ()

[fi

I
li:
+consultarSaldo()

O·
,«
Cf)

Cf)

f2
Ui Professor A1uno
li:
Õ
Cf) -títulaçâoMáxima -curso
O
Cf)
ContaEspecial -disciplinasHabilitadas -turma
O
o -limite
O
I­

+sacar ()

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,
considerando que cds e dvds possuem atributos em comum (título, preço, estoque, etc): 'It
Produto

~
I I
CD DVD

INSTITUTO INFNET - 186

~ UML-1550

:I
..:=>
:i :...
o
<[
o­
Classes Abstratas _
<l
u

:I
:>
c
w
f-
• As classes abstratas não permitem instanciar
W
Z
u, objetos pois definem "conceitos".
~

:t c:
oe, • São usadas somente para descrever atributos,
Cll
oC operações e associações comuns que serão
<l
> herdados pelas subclasses.
~
c:
w
Cll
ur
c: • Uma classe abstrata pode conter operações
o
<[
abstratas. São operações cuja implementação não é
~ '"oto'" especificado na superclasse, somente sua
ur
c:
Õ assinatura.
o'"
~ '"oc • As classes que herdarem essa operação deverão
of­ implementá-la, sendo a implementação diferente
para cada classe, ou mantê-la abstrata.
:3

:J

~ 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

:s 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,
::J
também devem ser declaradas como abstratas, pois não podem ser instanciadas.

::I

:t
:3

::I

=­
INSTITUTO INFNET - 187

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

 UML-1550

«
-
~

D
':i
o
.<t
Exemplo de Classe Abstrata
o­
-c
u
=>
D Funcionaria
w
tu
z
-mat.r í.cu i e
u, -nome
~
o:
o
D.
cn Mensalista
-cargo
-dataAdn1issao
-dataDemissaa
I
r-
o L---
D +demitir ()

-r
<t -salaria
6:w
cn
w
+calcularSalario()
+demitir (data)
+cd1 cu1dIS d1 "xi o () r
o:
f;;

I
o

-
.<t
cn
cn
o
!:::
w
o:

-
Õ 'I
cn
o
cn
o
Vendedor

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

I­
+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

INSTITUTO INFNET -188

:s
UML-1550

=­
=-
~

.
-
::>
Agregação
~
~ i:
i: • Um relacionamento de agregação é uma
z....
~
associação que reflete a construção física ou
~
!õ
i:.
a posse lógica.
..::
!!

=-
>
r
.tl
lO • Os relacionamentos de agregação são casos
.'"
a
r
particulares dos relacionamentos de
~ ~
li associação e indicam um todo que contém
E
~ 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.
:s 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.

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

=­:­
=-,
;ti
:ti

=­
INSTITUTO INFNET - 189
 UML-1550

<i.
o
~
o
'<C
o­
Exemplos de Agregação
<C
(J
:::l
o
W
I­
W

u.
~
tI:
o
C-

Ul

o
o
:;
tI:

Ul
W
tI:
O·
I<C
Ul

Ul

Prato
o
l­
m
tI:
Õ
Ul
o
Ul
o
o
o
I­

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.

'~

INSTITUTO INFNET - 190

C:J
UML-1550

:3

<i
a
:i .....
...J
o
<t
c­
Composição
<t
o
::o
:I
c
ur
....
w
Z
• E'" um tipo mais forte de relacionamento
u.
~
tode prte onde o todo é composto pelas
~ 'o"
J:1.

partes.
'"
o
a
<t
>
ao

~ tLI
ffl
• Nesse caso, os objetos da "parte" não têm
o'" existência independente do "todo".
"''""
~ '"
g
iü • E'" uma especialização da Agregação.
'"
ã
'"
o
~ '"oa
o
.....

~
191

:I

:I
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.

:I

::i
:i
:I
~

:3

:iI
INSTITUTO INFNET - 191
:!I
 :~
UML-I550

<i
c
~
o
.«
o­
Exemplos de Composição
«
o
:::>
c
w
f­
W
Z
LL NotaFiscal
~
o::
oD.
CIJ
oc
«
>
o::
w
CIJ
W
0::'
o
.« ItemDaNotaFiscal
CIJ

CIJ

TextoEspecí:fico
of­
Ui
o::
15
CIJ
o
CIJ
oc
of­

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.

E:

!I:
I

'I:

INSTITUTO INFNET -192

=s
UML-1550

::I

<i
c
:I f­
....I
o
«
o­
Mapeamento Objeto - BD Relacional
«
o
=>
:I c
l!J
f-
W
Z
• Como projetar o banco de dados a partir de um
lL
~ modelo de classes?
a:
::I o
"­
'"
o
• Como ficam as classes persistentes?
c
«
>
a: • Como ficam as classes transientes?
~ w
'"
w
a:
o
«
• Como ficam os atributos?
'"
:I '"
o
f­
Ui
a:
• Como ficam os relacionamentos ?
Õ
'"
O

::I '"
O
c
O
f­

:I
197

:3
:I 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
:I significativa a produtividade.
As perguntas que devem ser respondidas no momento em que o diagrama de classes tiver
::I 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,
:I 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
:I classe?
As respostas dependem do contexto do sistema mas algumas diretrizes gerais podem ser
:I seguidas.

:!

:I
::i
:=I
INSTITUTO INFNET -197
=i
 UML-1550

-
<i.
o
!:; Mapeamento Objeto - BD Relacional r
o
.«
C>
«
o
::>
o
w
I­

Z
u,
• Classes Simples -7Tabelas com chave
~
primária + atributos da classe
a:
o
c.
'"
o
• Agregações e Composições:
-
~

-
o
«
>
a:
w
- N:M - tabela intermediária r
'"
w
a:
o

-
.«
'" - N:l ­ campo de relacionamento na tabela com
o'" ~
l-
m
a:
multiplicidade N
15
'"
o
'"
o
o
o
I­
- 1:1 - campo em uma das tabelas
-
~

! 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!
, ­

INSTITUTO INFNET - 198

 --------

~ UML-1550

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

~ ª...
:;: • Atributo simples - coluna na tabela
z
~

=s ~
'"Q
• Atributo composto - uma coluna para cada
< parte do atributo
~
...
:I '"
E • Atributo com múltiplos valores - tabela
o
-e
= intermediária na qual a chave primária é a
:I ::
o
i: chave da tabela de origem + atributo
:i
'"o
~ '"o
::l
o

:I
199

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

:I
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
:I
tabelas que possuem como chave primária o valor do atributo e a chave primária da tabela
original.
:I

;:a
~

:11

•
INSTITUTO INFNET - 199
 iii
UML-1550 -
..
..

<i
o
~
o
'<C
Generalizações .
C>
<C
U
::> ii
o
w
f­
w
Z
u,
• Soluções para a conversão de hierarquias de -
ao
a: classes em tabelas de bancos de dados ;:
o
D..
Ul
o
o relacionais: ­
~
a:
w
Ul
w
- Uma tabela por classe
­
•.
a:
o
'<C
Ul

- Uma tabela para toda a hierarquia

Ul

o
!::
w
a:
- Uma tabela por classe concreta

Õ
Ul
o
Ul
o
o
..

ii

200

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
Uma tabela para toda a hierarquia ..f
Uma tabela para cada classe concreta.

..E
-r
...iii..

r-
.-...­
'

INSTITUTO INFNET - 200 ..

~
:3
UML-1550

~
~
~ -- Uma Tabela Por Classe
<o­
co:
~

~ s
"" • Passos:
"Z"
Lo
~
- Criar uma tabela para cada classe cujos campos são uma
chave primária + atributos específicos da classe
~ ~
2l:
~ - Na tabela da superclasse criar uma coluna tipo
<
:>
• Vantagens:

~
E
J.:.:J
2l:
""
E - Adequado a orientação a objetos

<
2l: - Suporte ao polimorfismo

~
2l:
:: - Extensibilidade

...
~
c
• Desvantagens:

~ E
'5
- 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:
:iI 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.

=­
:iI
=­
=­ INSTITUTO INFNET - 201
:::J
UML-1550

:i
oi
c
::i ~

O
Clt
Uma Tabela por Classe Concreta
<>
<
Si!
:;i Õ
.l:J

.l:i • Passos
...Z
~
:;: - Criar uma tabela por classe onde os campos são os
::I ~
atributos específicos + atributos herdados + chave
ª
<
> primária
:I E
=
">:: • Vantagens:
o
Clt
= - Consultas são mais fáceis
=
:J 2
~
:::; • Desvantagens:
=
o
:=I =
;::
- Extensibilidade dificultada
s
- Mudanças de papéis exigem cópias de dados
=t - Dificuldade no suporte a múltiplos papéis
203

=­:I 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:
:I 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.

:I
~

=­
=­:iI
INSTITUTO INFNET - 203
:3

 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.
a
<t • Os métodos podem ser implementados como
'"'"a triggers ou stored procedures no banco ou
....
8
:!C
C
implementados através da linguagem de
'"
a programação utilizada, em uma camada de
:l
a
<:> negócios. Pode ser criada uma camada de acesso
g
ao banco (biblioteca).

204

Em uma ferramenta CASE, apesar de não estar visível graficamente, uma classe pode •.....

_n:

í!~

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.

==

~
~

E:::
INSTITUTO INFNET - 204