FIAPEng Desing SWAula 13 UMLRelacao Classes 1

ENGENHARIA DE SOFTWARE
Prof. Renato Jardim Parducci – profrenato.parducci@fiap.com.br

DISCIPLINA:
ENGENHARIA E DESIGN DE SOFTWARE
AULA:
13 – UML – DETALHAMENTO DE CLASSES E SUAS RELAÇÕES
PROFESSOR:
RENATO JARDIM PARDUCCI
PROFRENATO.PARDUCCI@FIAP.COM.BR

ANÁLISE E PROJETO DE SISTEMAS OO

A UML tem uma notação própria para representar Classes e as
associações entre elas, a qual será conhecida em todos os seus detalhes
nessa aula.

RELAÇÕES DE CLASSES NO
MODELO DE DOMÍNIO


Os Objetos de Classes têm relações entre si,.. Eles se comunicam e
se associam.
Na modelagem de Domínio, o Diagrama de Classes de um sistema

de informação criará associações (vínculos) entre as Classes, os
quais permitem que as regras de negócio e dados da empresa e
suas transações sejam completados.
CLIENTE DO CONTA
BANCO POSSUI BANCÁRIA

Quais são as possíveis relações entre Classes e como representá-las

na UML?
Vamos conhecer agora!


Relações ASSOCIATIVAS
Relação na mesma Classe (Unária ou Reflexiva)
Classe
A
Relação entre duas Classes (Binária)
Classe Classe
A B
Navegabilidade da Relação entre duas Classes

Classe Classe
A B
A seta opcional, determina qual é a Classe determinante da relação

Relações ASSOCIATIVAS
Relações fortes: sempre existe Objeto instanciado

em ao menos um dos lados da relação
Relações fracas que podem não acontecer: o

Objeto de uma Classe precisa da(s) outra(s) para
existir

As relações associativas devem receber indicação de Cardinalidade.
1: Existe 1 e apenas 1 objeto da classe associado neste lado da relação

0..*: Existem 0 a N objetos relacionados na classe desse lado da relação
0..1: Existe 0 ou 1 objeto da classe associado neste lado da relação
1..*: Existe 1 a N objetos da classe associados deste lado da relação
*: Existem N objetos da classe associados deste lado da relação
Classe “A” Classe “B”

1 0..*
A Cardinalidade determina uma Restrição na relação de Classes.


Opcionalmente, pode ser indicada a quantidade exata de Objetos
em cada ponta da relação.
Neste exemplo, um Vendedor pode ter até 40

Clientes incluídos na sua carteira de
atendimentos. Se ele estiver em treinamento,
pode não ter clientes vinculados.
VENDEDOR CLIENTE
1 0..40

Se desejarmos indicar a navegação nas relações, escolhemos uma

classe para a partida da relação e denominamos (rotulamos) a
relação com algo que remeta ao que está acontecendo.
VENDEDOR atende CLIENTE

1 0..40


Exemplo com detalhes de Atributos e Métodos SEM Atributos de
relacionamento
VENDEDOR 1 atende 0..40 CLIENTE

idVendor:integer idCli:integer
nomeVendor: string nomeCli: string
criarVendedor() criarCliente()
consultarVendedor() consultarCliente()


Exemplo com detalhes de Atributos e Métodos COM Atributos de
relacionamento
VENDEDOR 1 0..40 CLIENTE

idVendor:integer É atendido por idCli:integer
nomeVendor: string nomeCli: string
criarVendedor() vendedor: Vendedor
consultarVendedor() criarCliente()
consultarCliente()

Não devem existir Classes com associação múltipla em ambas, na

mesma relação (número maior que 1 dos dois lados).
Para resolver isso, criamos uma Classe nova que nasce da reação:
uma Classe Associativa. No exemplo a seguir, um animal de
estimação pode ter vários donos e um dono pode ter vários
animais.
Pessoa Pet
Propriedade

Veja que a notação da Classe Associativa é diferente.
A linha pontilhada está conectada à Classe que só existe se uma

Pessoa estabelecer uma relação com um Pet!
Essa Classe foi criada no nosso exemplo porque uma Pessoa pode
ter vários Pets e um Pet pode pertencer a várias Pessoas.
Pessoa Pet
Propriedade


Para cada Objeto da Classe Propriedade só existe um Objeto da
Classe Pessoa for vinculada a um Objeto da Classe Pet, ou vice-
versa.
Exemplo: os objetos João e Bilu estão relacionados na

Propriedade P010.
Pessoa Pet
Propriedade

Exemplo com detalhes de Atributos e Métodos COM Atributos de
relacionamento
Pessoa Pet
idPessoa:integer idPet:integer
nomePessoa: string nomeCinema: string
Pessoa():Pessoa Cinema():Cinema
setId(id:int):void setId(id:int):void
setNome(nome:String):void setNome(nome:String):v
getId():int Propriedade getId():int
getNome():String getNome():String
idPropriedade:int
dataAquisicao: Date
Pessoa: Pessoa
Pet:Pet
Propriedade():Propriedade
setId(id:int):void
setData(data:Date):void
getId():int
getData():Date

ATIVIDADE PRÁTICA
Considere o desenvolvimento de um sistema de gestão de propriedade de

veículos onde devem ser controlados os proprietários, os automóveis, as
montadoras fabricantes dos automóveis e os documentos de propriedade.
Faça o modelo de Domínio das Classes de objetos – retrate as Classes de

Entidade com Atributos, Métodos, Estereótipo e Relacionamentos!

Existem outras associações onde a existência de um Objeto em

uma Classe depende de existir um Objeto em outra Classe.
Esse tipo de relação estabelece que pelo menos um dos dois

lados tem cardinalidade 1 (UM), sendo o mandante da relação,
inexistindo assim as chamadas relações fracas, que são aquelas
que podem até não acontecer (quando os dois lados da reação
têm ZERO objetos).
Resumo: as relações de Agregação e Composição são fortes!

Essas associações com dependência existencial são:
• Agregação: quando uma Classe A associa outra Classe B para

complementar opcionalmente as suas necessidades em atender
regras de negócio, sendo que pode ou não existir um Objeto em
B mas, se existir objeto em B, tem que existir um Objeto em A.
• Composição: quando uma Classe A associa outra Classe B para

complementar obrigatoriamente suas necessidades em atender
regras de negócio, sendo que pode sempre deve existir ao
menos um Objeto em B e, se existir objeto em B, tem que existir
um Objeto em A.

Exemplo de Agregação:
Agrega
O avião à jato não depende

de ter cadeiras para existir.
Ele pode ser um avião de
carga!
Exemplo de Composição:
É composto de
O avião à jato depende de

ter turbinas para existir.

Modelagem da Agregação com UML:
Classe 1- Pessoa Classe 2- Dependente financeiro

Agrega
O Símbolo de Agregação deve ficar junto da Classe que Agrega a outra (é um

losango sem preenchimento)
Os objetos instanciados na Classe 2 só existem se existir um objeto na Classe 1.

No exemplo, uma pessoa pode ou não ter um dependente financeiro atribuído.
Observe portanto que no caso da Agregação, não é preciso indicar a Cardinalidade

do lado da Classe mandante/agregadora da relação pois subentende-se que é 1.
Objeto da Classe mandante (agregadora) está associado com 0, 1 ou “n” objetos da

Classe demandada/agregada)
Modelagem da Composição com UML:
Classe Carro É composta de Classe Pneu
Classe
Amortecedor
Classe Mola
O Símbolo de Composição (losango preenchido) deve ficar junto da Classe

que é composta pela a outra.
Na composição, as Classes que compõem a Classe que as associa têm
cardinalidade mínima 0 e a Classe composta tem 1.

Modelagem da Agregação x Composição com UML:
Classe Carro É composta de Classe Pneu

pneu: Pneu[] 1..*
1
Classe Aluno 0..* Classe Endereco

ender: Endereco [] Agrega
1
A diferença básica está na implementação:

-Na agregação e composição os agregados e componentes passam a fazer
parte do objeto do qual são componentes ou agregados!

Exemplo combinado de Agregação e Composisção:
Classe CEP É composta de Logradouro
Agrega Localização
Geográfica
(Geoprocessada)
Classe Social


Exemplo de identificação da relação através de um Atributos na Classe
mais fraca de uma relação.
JATO
nroSerie – Inteiro TURBINA
dataFabricacao – Inteiro
nroSerie – Inteiro
turbina:Turbina[]
dataFabricacao – Inteiro
cadeira: Cadeira[] 0..*
1 localInstalacao – Char[5]
decolhar()
pousar()
criar() instalar()
criar()
1 CADEIRA
nro – Inteiro
0..* localInstalacao – Char[5]

Devemos indicar algo nos Atributos e Métodos das Classes de

Domínio quando modelamos relações?
Devemos incluir alguma coisa que indique a relação?


Devemos indicar algo nos Atributos e Métodos das Classes de Domínio
quando modelamos relações?
Devemos incluir alguma coisa que indique a relação?
As Classes de Domínio se mantém inalteradas.

O desenho das associações é suficiente para que um desenvolvedor
entenda que numa Classe que associa com outra. Alguns projetistas
incluem um atributo na Classe mais fraca da relação, com o nome e tipo
da Classe associada (permitido na UML).
Esses Atributos de associação são obrigatórios nos Modelos de Classes

de Especificação e Implementação, conforme a linguagem de
programação escolhida.

O último tipo de relação que precisa ser apresentado é o de

Especialização e Generalização.
Essas relações criam associações onde uma ou mais Classes nascem

(são derivadas) de outra Classe, criando uma relação pai-filho onde
o filho herda características do pai e as complementa com seu
comportamento e estrutura particular de filho.


Dizemos que estamos especializando quando partimos de uma
Classe e derivamos filhos para ela e dizemos que Generalizamos
quando ajuntamos características de várias Classes em uma Classe
pai.
Generalização Classe Pessoa Especialização
Classe Homem Classe Mulher
Símbolo utilizado para apontar a Classe PAI (triângulo pequeno preenchido)


No exemplo abaixo, a Classe Pessoa conterá todos os Atributos e
Métodos que as Classes Homem e Mulher têm em comum,
ficando para Homem e Mulher só os Métodos e Atributos
exclusivos de cada um.
Generalização Classe Pessoa Especialização
Classe Homem Classe Mulher


ATRIBUTOS: MÉTODOS:
Exemplo ilustrativo • asa • cruzeiro
Classe Aeronave
(fora do padrão • motor • ligar
• cabine • desligar
UML): • ... • decolar
• ...
Classe Avião Classe Foguete
ATRIBUTOS: MÉTODOS: ATRIBUTOS: MÉTODOS:

• asa • cruzeiro • asa • cruzeiro
Herda
Herda
• motor • ligar • motor • ligar

• Cabine • desligar • Cabine • desligar
• ... • decolar • ... • decolar
• ... • ...
ATRIBUTOS: ATRIBUTOS: MÉTODOS:
Adiciona
Adiciona
• assentos • célula • liberar célula

• ... • ... • ...
Efeitos da herança na instanciação de Objetos (exemplo fora do
padrão UML).
Classe Pessoa Classe Homem
Objeto ID CL2
identificação nome (herda de Pessoa)
nome sobrenome (herda de Pessoa) Objetos Nome Carlos
sobrenome sexo masculino instanciados Sobrenome doVal
fala fala (herda de Pessoa) -Escuta Carlos

escuta anda (herda de Pessoa)
anda come (herda de Pessoa)
come escuta (herda de Pessoa)
Classe Mulher
Objeto ID CL1
nome (herda de Pessoa)
sobrenome (herda de Pessoa) -Nome Laura
Objetos instanciados -Sobrenome Luc
sexo feminino
fala (herda de Pessoa) -Fala com Laura

anda (herda de Pessoa)
come (herda de Pessoa)
escuta Prof. Renato Jardim Parducci – profrenato.parducci@fiap.com.br
Nessas relações, os Atributos e Métodos recebem atenção especial

e ganham uma notação adicional!

Nas Especializações e Generalizações podem ocorrer duas

situações:
1ª) A Classe filha instancia a Classe Mãe e a Classe Mãe nunca é

instanciada com Objetos ( a Classe Mãe é ABSTRATA)
2º) A Classe filha instancia a Classe Mãe e a Classe Mãe também é

instanciada com Objetos (a Classe Mãe não é ABSTRATA)


Pessoa
#nome
Na UML a +construirPessoa()
+destruirPessoa()
associação +consultarNome()
representada
com linha
contínua
Pessoa Física PessoaJuridica

-rg -cnpj
-cpf
+incluirRegistroLegal()
+incluirDocumentos() +emitirNotaFiscal()


Usuário
Se Usuario não for Abstrada, #id: int
#nome: char
os Objetos podem ser
instanciados nas Classes +fazerLogin():Boolean;;
filhas e podem, todos eles,
executar Login e acessar ID e
NOME diretamente (sem ter
que chamar métodos da
Classe Mãe) e a Classe Mãe
também poderá instanciar
Objetos!
Gestor Operador
-nívelHierarquico: char; -turno: int
+apontarPresenca();
+aprovarPromocao(): void;


Usuário
#id: int
#nome: char
+fazerLogin():Boolean;;
Se a Mãe não é Abstrara,
essas Classes podem ser
instanciadas com Objetos:
podemos ter USUÁRIOS
genéricos e ESPECÌFICOS
(Gestor ou Operador)
Gestor Operador
-nívelHierarquico: char; -turno: int
+apontarPresenca();
+aprovarPromocao(): void;


Aeronave
#asa
Classes abstratas não #motor
#cabine
instanciam objetos –
+construir()
são apenas
+destruir()
estruturas de +cruzeiro()
referência (Meta +ligar()
Objetos serão instanciados
dados/Meta +desligar()
+decolar() nas Classes Avião ou
modelos)
+aterrissar() Foguete somente, caso a
Classe mãe seja Abstrata
Avião Foguete
-assentospassageiros -cápsulacomando
+liberar_cápsula()

Como falamos, a Generalização e Especialização traz para o projeto de software

o poderoso recurso da Herança, permitindo o reuso de Métodos e Atributos de
Classes já declarados por outras Classes.
Para que a modelagem fique completa, a UML pede que diante de cada Método
e Atributo seja colocado um dos símbolos que indicam a VISIBILIDADE:
– (privado) diante no nome do método ou atributo: o método/atributo só pode

ser acessado pela sua Classe de definição.
# (restrito/protegido) diante no nome do método/atributo: o método/atributo
pode ser acessado diretamente pelos métodos da Classe da sua definição ou
Herdeiras.
+ (público) diante no nome do método/atributo: o método/atributo pode ser
acessado por qualquer outra parte (Classe) do sistema.
• Como os Métodos são usados para comunicação entre Objetos de diversas

Classes, a visibilidade default é +
• Como Atributos são características do objeto que devem ser encapsuladas

em sua maioria, a visibilidade default é –
• Somente em situações de atributos que devem ser herdados por Classes

filhas é que usamos #

Exemplo de prática.
Aluno
#nome
#iD-Matricula
#telefone
#endereço
+matricular()
+pagarmensalidade()
+viràsaulas()
+fazerprovas()
+obternotas()
Aluno Mau Pagador Aluno Bom Pagador

-valortotalpendênciafinanceira -descontopróximarenovaçãomatrícula
-númeroocorrênciasinadimplência
+incrementapendências() +usadesconto()
+quitadébitos() +incrementadesconto()

Exemplo de Herança, aplicando Visibilidade em Métodos e Atributos das Classes.

Atributos Atributos
passados por
herança aos
exclusivos
da classe
filhos
Exemplo de Herança, aplicando Visibilidade em Métodos e Atributos das Classes.
Métodos
de acesso
público

Engenharia de Software – Prof. Ms. ENGENHARIA
Renato J.Parducci DE SOFTWARE
Atributos
ANÁLISE E PROJETO DE SISTEMAS OO exclusivos
da classe
A existência da
Exemplo
herança já faz de Herança, aplicando Visibilidade em Métodos e Atributos das Classes.
com que a
Classe Aluno
receba os
atributos
marcados com #
e os manipule

ATIVIDADE PRÁTICA
Considerando a situação real de compra de ingressos em cinema, a qual você

conhece bem...
Modele as Classes de objetos de Entidade do domínio da operação de reserva de

poltrona para uma sessão de um filme em uma sala de cinema.
Não precisa detalhar atributos e métodos neste momento.

Modele apenas as Classes e suas relações.

ATIVIDADE PRÁTICA
Junte seu grupo de trabalho para o desenvolvimento do nosso estudo de

Caso de aula.
Defina as Classes de Entidade que você criou anteriormente para o projeto do sistema de
Gestão de Estacionamento.
Para fazer esse trabalho, considere a que você produziu até agora (Casos de Uso e
Classes de Entidade).

Para concluir a especificação de Classes, é boa prática descrever maiores

detalhes sobre os Métodos, aportando a lógica de aplicação de cada um.
Para fazer isso, casa Método de cada Classe é detalhado com um Algoritmo que
explica o seu funcionamento interno.

Exemplo de Algoritmo aplicado a um Método:
Método Cliente.Consultar (RG_do_cliente:Integer): String
Início
Abrir Cliente
Ler Cliente com Cliente.RG = RG_do_cliente
Se não encontrado
Status = ‘não encontrado’
Senão
Status = ‘encontrado’
Nome_do_Cliente = Cliente.Nome Cliente
Fim-se
Fim

ATIVIDADE PRÁTICA
Faça um algoritmo para o método “alocarVaga():Vaga”, considerando

que esse método busca a primeira vaga disponível no estacionamento
(status de livre) e altera a sua situação (muda para status ocupado),
retornando ao método que o chamou, os dados da vaga selecionada.

CANAL DO PROFESSOR
Assista ao vídeo sobre Diagramação de

Classes com ASTAH!
https://youtu.be/YtpadTBQhMs
Vídeos de
complementares
de aulas


Para modelar Classes com o ASTAH, acesse Class Diagram na barra de
ferramentas e use os botões de trabalho sinalizados abaixo (maiores informações
na apostila de Ferramentas de Modelagem).
Para definir
Relações
Para definir Clicando nas Classes, Atributos e

Para definir Herança Métodos, você tem acesso ao painel
Classes entre de detalhamento
Classes
Exemplo de descrição de algoritmo de Método no ASTAH.
Observe o Método em foco
Observe o ALGORITMO
do Método

ATIVIDADE PRÁTICA
Junte o seu grupo de trabalho de sala!
Modele as Classes de Entidade para gerenciar uma Faculdade com vários

Campus e com diversos Cursos.
Disciplinas podem ser ofertadas em mais de um Curso, formando Roteiros,
e os Cursos podem ocorrer nas modalidades EaD ou Presencial.
Alunos podem se matricular nos Cursos e esses alunos terão controle de
bons ou mau pagadores.
Funcionários também serão cadastrados no sistema podendo ser
Administrativos ou Docentes, tendo os Docentes, controle de titulação
(mestre, doutores, pósdoc).
Proponha os atributos e cuide da visibilidade!

PROJETO INTEGRADO DE CURSO
Faça os Diagramas de Classe completos do seu projeto AM!

ATIVIDADE EXTRA
Evolua o projeto do seu Jogo da Forca.
Ele vale 1 ponto a mais na última PS do ano se:
-A lista de requisitos estiver correta e completa;
-A modelagem em UML estiver correta e completa;
-O código fonte estiver escrito, respeitando os modelos de engenharia;
-O programa esteja funcionando.
Guarde o seu material:

Na próxima aula, você vai descobrir como definir seu banco

de dados e construir código de aplicação partindo da
documentação de Classes.


Referência
Referência bibliográficas
bibliográficas
BIBLIOGRAFIA
BIBLIOGRAFIABÁSICA:
BÁSICA:
•• BEZERRA,
BEZERRA,EDUARDO.
EDUARDO.Princípios
Princípiosde
deanálise
análiseeeprojeto
projetode
desistemas
sistemascom
comUML.
UML.Alta
Alta
Books,
Books,Rio
Riode
deJaneiro,
Janeiro,2006.
2006.
•• MEDEIROS,
MEDEIROS,E. E.S.S.Desenvolvendo
DesenvolvendoSoftware
SoftwarecomcomUML
UML2.0:
2.0:definitive.
definitive.Editora
EditoraPearson,
Pearson,
São
SãoPaulo,
Paulo,2004.
2004.
•• FILHO,
FILHO,MILTON
MILTONM. M.A.
A.UML
UMLeeC++:
C++:Guia
GuiaPrático
PráticodedeDesenvolvimento
DesenvolvimentoOrientado
Orientadoaa
Objetos.
Objetos.Editora
EditoraMakron
MakronBooks,
Books,São
SãoPaulo,
Paulo,2001.
2001.

FIAPEng Desing SWAula 13 UMLRelacao Classes 1

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

FIAPEng Desing SWAula 13 UMLRelacao Classes 1

Enviado por

Direitos autorais:

Formatos disponíveis

ENGENHARIA DE SOFTWARE

Prof. Renato Jardim Parducci – profrenato.parducci@fiap.com.br

Prof. Renato Jardim Parducci – profrenato.parducci@fiap.com.br

ANÁLISE E PROJETO DE SISTEMAS OO

Prof. Renato Jardim Parducci – profrenato.parducci@fiap.com.br

Prof. Renato Jardim Parducci – profrenato.parducci@fiap.com.br

ANÁLISE E PROJETO DE SISTEMAS OO

Na modelagem de Domínio, o Diagrama de Classes de um sistema

Prof. Renato Jardim Parducci – profrenato.parducci@fiap.com.br

ANÁLISE E PROJETO DE SISTEMAS OO

Quais são as possíveis relações entre Classes e como representá-las

Vamos conhecer agora!

Prof. Renato Jardim Parducci – profrenato.parducci@fiap.com.br

ANÁLISE E PROJETO DE SISTEMAS OO

Navegabilidade da Relação entre duas Classes

ANÁLISE E PROJETO DE SISTEMAS OO

Relações fortes: sempre existe Objeto instanciado

Relações fracas que podem não acontecer: o

Prof. Renato Jardim Parducci – profrenato.parducci@fiap.com.br

ANÁLISE E PROJETO DE SISTEMAS OO

As relações associativas devem receber indicação de Cardinalidade.

1: Existe 1 e apenas 1 objeto da classe associado neste lado da relação

Classe “A” Classe “B”

A Cardinalidade determina uma Restrição na relação de Classes.

Prof. Renato Jardim Parducci – profrenato.parducci@fiap.com.br

ANÁLISE E PROJETO DE SISTEMAS OO

Neste exemplo, um Vendedor pode ter até 40

Prof. Renato Jardim Parducci – profrenato.parducci@fiap.com.br

ANÁLISE E PROJETO DE SISTEMAS OO

Se desejarmos indicar a navegação nas relações, escolhemos uma

VENDEDOR atende CLIENTE

Prof. Renato Jardim Parducci – profrenato.parducci@fiap.com.br

ANÁLISE E PROJETO DE SISTEMAS OO

VENDEDOR 1 atende 0..40 CLIENTE

Prof. Renato Jardim Parducci – profrenato.parducci@fiap.com.br

ANÁLISE E PROJETO DE SISTEMAS OO

VENDEDOR 1 0..40 CLIENTE

Prof. Renato Jardim Parducci – profrenato.parducci@fiap.com.br

ANÁLISE E PROJETO DE SISTEMAS OO

Não devem existir Classes com associação múltipla em ambas, na

Prof. Renato Jardim Parducci – profrenato.parducci@fiap.com.br

ANÁLISE E PROJETO DE SISTEMAS OO

Veja que a notação da Classe Associativa é diferente.

A linha pontilhada está conectada à Classe que só existe se uma

Prof. Renato Jardim Parducci – profrenato.parducci@fiap.com.br

ANÁLISE E PROJETO DE SISTEMAS OO

Exemplo: os objetos João e Bilu estão relacionados na

Prof. Renato Jardim Parducci – profrenato.parducci@fiap.com.br

Prof. Renato Jardim Parducci – profrenato.parducci@fiap.com.br

Considere o desenvolvimento de um sistema de gestão de propriedade de

Faça o modelo de Domínio das Classes de objetos – retrate as Classes de

Prof. Renato Jardim Parducci – profrenato.parducci@fiap.com.br

ANÁLISE E PROJETO DE SISTEMAS OO

Existem outras associações onde a existência de um Objeto em

Esse tipo de relação estabelece que pelo menos um dos dois

Resumo: as relações de Agregação e Composição são fortes!

Prof. Renato Jardim Parducci – profrenato.parducci@fiap.com.br

ANÁLISE E PROJETO DE SISTEMAS OO

Essas associações com dependência existencial são:

• Agregação: quando uma Classe A associa outra Classe B para

• Composição: quando uma Classe A associa outra Classe B para

Prof. Renato Jardim Parducci – profrenato.parducci@fiap.com.br

ANÁLISE E PROJETO DE SISTEMAS OO