Aula 5 Modelos de classes de projeto

Prévia do material em texto

Disciplina: TCC em Sistema da Informação
Aula 5: Modelos de classes de projeto
Apresentação
Nesta aula, vamos explorar as propriedades e conceitos do diagrama de classes de projeto, levando em consideração a
modelagem dos diagramas de estados e sequência, que podem ter levado à incorporação de novos métodos para as classes
envolvidas nos diversos cenários de uso do sistema.
Serão levados em consideração conceitos de coesão e acoplamento, bem como padrões de projeto e outros elementos de
reuso.
É o momento também de de�nir a arquitetura do sistema, através do diagrama de pacotes, mostrando o seu
particionamento e a interconexão entre as partes.
Objetivos
Explicar os conceitos, propriedades e técnicas para evoluir o diagrama conceitual de classes para diagrama de classes
de projeto;
Examinar conceitos de coesão e acoplamento, bem como padrões de projeto e outros elementos de reuso;
Aplicar a construção do diagrama de classes de projeto em seu TCC a partir do diagrama conceitual de classes.
Atividades inerentes ao projeto (ou design) de software
Conforme de�nido em Princípios de análise e projeto de sistemas com UML, de Eduardo Bezerra, as principais atividades
realizadas durante o projeto de software, especi�camente quando evoluímos, na fase de projeto, o diagrama conceitual de classes
para diagrama de classes de projeto.
Tais atividades são:
Clique nos botões para ver as informações.
• Re�namento do modelo conceitual de classes, acrescentando atributos e métodos que melhor de�nam as
responsabilidades de cada classe.
• Pode haver classe de análise que precise ser representada por mais de 1 classe de projeto e vice-versa (embora mais
difícil).
• São revistos e de�nidos tipos para os atributos.
• São de�nidas as navegabilidades das associações entre classes.
• Re�namento dos relacionamentos de associações, que podem vir a ser composição/agregação,
generalização/especialização, classes de associação e dependências.
• Devem ser considerados aspectos como coesão e acoplamento, garantindo maior independência entre as classes. Devem
ser considerados ainda a correta aplicação do conceito de encapsulamento.
• Destaque deve ser dado a fatoração de classes, através do conceito de herança (relacionamento de generalização e
especialização entre classes) e polimor�smo.
Re�namento dos aspectos estáticos e estruturais 
• A arquitetura lógica, diz respeito a divisão do software em camadas, incluindo aqui o modelo MVC e o modelo em camadas
de apresentação, domínio, persistência e etc. O diagrama de pacotes é o modelo disponibilizado pela UML para
representação da arquitetura lógica.
• Aspectos relevantes a serem considerados são: subsistemas, interfaces, camadas de software, como controle e
dependência entre subsistemas.
Projeto de arquitetura 
• Diz respeito a forma como os objetos são armazenados de forma persistente, em geral em banco de dados, que podem ser
relacionais, objeto relacionais ou de objetos.
• A persistência pode demandar novas classes, que sejam responsáveis por esse armazenamento no banco de dados
especi�cado (a partir desse momento as decisões de uso de linguagem de programação e SGBD começam a ocorrer.
• Tal técnica permite que se altere apenas a classe de persistência (DAO), em caso de troca de SGBD, por exemplo.
Persistência de objetos 
• As interfaces vêm sendo representadas nos diagramas de interação, como elemento através do qual se dá a interação do
usuário com o sistema. No diagrama de classes de projeto, podem tornar-se classe.
Interface 
• O uso de padrões de software tem sido bastante usado em projetos de software, na tentativa de desenhar sistemas mais
consistentes, com maior reuso.
Padrões de software 
Interações
É muito importante que avaliemos os diagramas de interação, já desenvolvidos, para de�nir melhor as classes de projeto.
Os diagramas de interação são extremamente valiosos, pois vamos entender e raciocinar em detalhes sobre quais mensagens
enviar, para quem e em que ordem.
Podemos re�etir também sobre as seguintes questões:
Quais objetos realmente precisam existir? Quais as responsabilidades de cada um?
Como os objetos interagem?
É o momento de veri�car se é possível estabelecer algum padrão de projeto dentro do
princípio de aplicação de boas práticas.
Atenção
Em geral, já aprendemos que: 
 
• Toda mensagem que chega a um objeto no diagrama de sequência ou comunicação vai representar uma operação da classe, ou
seja, um método na classe que recebe a mensagem.
Observe que ao objeto cliente chega uma mensagem de nome
procurar cliente (Id Cliente), ou seja, essa será a assinatura de
um método da classe, conforme especi�cado abaixo na classe
Cliente.
Ao criar os modelos de interação (sequência ou comunicação), geramos informações que complementam o modelo de classes
iniciado na fase de análise.
Dica
Avalie se o seu diagrama de classes está absolutamente compatível com os diagramas de sequência dos quais faz parte, ou seja,
se todas as mensagens que chegam na classe (avaliando o diagrama de sequência), de fato são métodos que estão nas
respectivas classes. O que estiver incompleto deve ser complementado.
Modelagem de classes de projeto
O diagrama de classes de um sistema é um só, que vai sendo re�nado ao longo dos momentos de análise e projeto do
desenvolvimento desse sistema.
Iniciamos avaliando o negócio e extraindo as classes a ele relacionadas.
O diagrama conceitual de classes apresenta os principais atributos e (caso desejado) os métodos derivados dos casos de uso.
Com a construção do diagrama de interação (sequência ou comunicação), começamos os re�namentos, que encerram ao �nal
do momento de projeto ou design do sistema. Assim, novas classes, relacionadas à forma de implementação, vão sendo criadas.
Novos métodos das classes existentes vão sendo adicionados, para adequar melhor a solução com as tecnologias propostas ou
alternativas.
Novas classes de negócio também podem ser inseridas nesse momento do processo de
desenvolvimento, mas isso com certeza vai representar ou novos requisitos que estão
sendo adicionados, ou falha técnica no momento anterior, onde os requisitos foram
identi�cados e de�nidos como presentes no escopo do sistema.
Outra tese famosa é a de Martin Dibelius, professor da Universidade de Heidelberg no início do século XX. Ele a�rmava que Lucas,
o autor, utilizou um diário de viagens escrito por um companheiro de Paulo, tendo ele também participado de viagens de Paulo.
O argumento principal dessa hipótese é o fato de, em alguns trechos de Atos, ser
utilizado o pronome pessoal da primeira pessoa do plural, “nós”, enquanto que em
outros trechos não é usado.
Vielhauer (2015) concorda que um itinerário de viagens foi utilizado como fonte, mas a�rma que o autor de Atos não pode ter sido
uma testemunha ocular e alguém próximo de Paulo, argumentando que são cometidos por ele equívocos históricos.
Ele cita a a�rmação de que houve uma segunda viagem missionária a Jerusalém, antes do Concílio, o que entra em contradição
com o que Paulo diz em Gálatas 1,17-2,1 e com o Decreto dos Apóstolos (At 15,23-29), que contradiz Gálatas 2,6-9.
A seguir, eis algumas situações que nos fazem acrescentar classes ao modelo conceitual, dando origem ao modelo de classes de
projeto:
1
Classes de fronteira: interface entre a aplicação e as entidades externas (usuários, sistemas, equipamentos). Os atores
comunicam-se apenas com essas classes. Dessa forma, mudanças na interface não interferem nas classes de entidade,
persistência e controle. Não devem conter lógica do negócio (melhor coesão).
2
Classes de controle: as mais conhecidas são as que controlam a realização de um caso de uso (em geral, uma classe de
controle). Casos de uso simples, como cadastramentos, não necessitam de classes de controle. Classes de controle
geram uma camada entre as classes de fronteira e a classe de entidade.
3 Classes que sirvam de base para implementação do mecanismo de herança, as chamadasclasses abstratas.
4 Controle de segurança (autorização e autenticação de acesso): usuário, per�s de acesso e login/logout.
5 Registro de ações realizadas no sistema (guardar os logs de acesso).
6 Classes de transações
7 Acesso e armazenamento
Veja abaixo a relação entre as classes de fronteira, entidade e controle.
• A classe de controle passa o “comando” para a classe de
fronteira (Boundary);
• O usuário interage com a classe de fronteira e devolve o
comando para a classe de controle;
• A classe de controle repassa para a classe de agência os
dados do saldo a consultar, pois é esta última classe que
conhece as suas contas.
 Fonte: ARAÚJO, 2009.
Cada situação exempli�cada implica na necessidade de novas responsabilidades do sistema, que demandam novas classes a ser
projetadas.
A reutilização também está presente no projeto do software, através de padrões de projeto, bibliotecas de classes (coleção de
classes com objetivo determinado), frameworks (coleção de classes em colaboração, como o hibernate e JUnit) e componentes.
Além de novas classes, vamos também re�nar as classes de�nidas no modelo conceitual de classes, no que se refere:
À visibilidade de atributos e métodos;
Aos detalhes das assinaturas dos métodos, como os argumentos adequados, e o tipo de dado que retorna;
À análise da possibilidade de uso da herança;
À identi�cação de novos métodos pela análise das interações dos diagramas de sequência e/ou comunicação;
À substituição de relacionamentos de associações por outros mais semanticamente adequados; por exemplo:
Agregação;
Composição;
Classe de relacionamento;
Dependência.
Passando da Análise ao Projeto: Classes
A seguir, veremos uma classe típica de um modelo conceitual, onde são apresentados os principais atributos e métodos obtidos
diretamente do diagrama de casos de uso, ou de outra técnica, onde poucos detalhes são apresentados.
1
O nome da classe
que representa algo relevante para o negócio.
2
Os nomes dos principais atributos
a partir dos dados recuperados da especi�cação textual dos casos de uso, sem especi�car detalhes como visibilidade e tipos
dos dados (inteiro, real, string etc.).
3
Os nomes dos métodos derivados de casos de uso
mas sem detalhes como parâmetros.
Saiba mais
Veja a representação da classe fornecedor <galeria/aula5/docs/PDF_Aula_Classe fornecedor.pdf> em um diagrama de classes de
projet.o, derivado do modelo conceitual de classes em que são acrescentados detalhes de projeto.
No diagrama conceitual de classes não há preocupação na identi�cação exata dos relacionamentos. De forma geral, são
indicados como associações.
Na elaboração do diagrama conceitual de classes, temos que nos preocupar com a melhor forma de implementar.
Considere o seguinte trecho de um diagrama conceitual de classes:
Veremos mais exemplos de derivação de diagrama de classes de projeto com base no diagrama conceitual de classes e algumas
decisões de implementação.
Adiante, um dos possíveis trechos de diagrama de classes de projeto:
Além do detalhamento dos atributos (aqui não exempli�camos métodos, propositalmente), adicionamos ao modelo de projeto:
1 A inclusão da classe Itens do Pedido, pois é necessário conhecer os produtos que pertencem a um pedido.
2
Assim sendo, o Pedido passa a ser composto de ItensPedido, pelo relacionamento de composição (a vida de Itens Pedido
depende de Pedido, ou seja, é criado e destruído por objetos da classe Pedido). E a classe itens Pedido refere-se à classe
produto. Foram adicionadas as multiplicidades dos novos relacionamentos identi�cados.
3 Como as vendas podem ter descontos unitários de produto, adicionou-se o atributo Desconto Unit na classe Itens Pedido.
4
Outra decisão de projeto foi a inclusão dos atributos Valor Pedido e Impostos Pedido, que vão armazenar o total do
pedido e o total de impostos a ser recolhidos por pedido. Tal decisão deu-se pela necessidade de uma lei vigente de
informar tais dados ao �sco.
https://stecine.azureedge.net/webaula/estacio/gon375/galeria/aula5/docs/PDF_Aula_Classe%20fornecedor.pdf
5
Na classe ProdutosE foi incluído um atributo Perc Imposto, que visa a informar o percentual de imposto daquele produto,
na venda. Esse atributo é a base para que se possa armazenar o atributo Impostos Pedido que soma o valor de todos os
impostos de todos os itens constantes no pedido.
Vamos demonstrar agora a utilidade dos modelos de interação para a construção do modelo conceitual de classes. Para tal,
vamos construir um diagrama de sequência, tomando por base:
O trecho de diagrama de casos de uso, representado pela �gura;
A especi�cação textual do caso de uso: Registrar Pedido, conforme abaixo;
O trecho do diagrama de classes de projeto, representado pela �gura.
Especi�cação do Caso de Uso: Registrar Pedido 
Objetivo: registrar os pedidos solicitados pelos clientes 
Ator(s): Atendente
Clique nos botões para ver as informações.
1. Atendente informa Id Cliente
2. Sistema Localiza Cliente
3. Para cada Item a ser inserido no pedido
3.1. Atendente informa Id Produto
3.2. Sistema localiza Produto
3.3. Atendente informa quantidade de produto
3.4. Sistema valida quantidade de produto
3.5. Sistema registra item do pedido
4. Atendente con�rma dados do pedido
5. Sistema registra pedido
Cenário Principal 
2.a. Cliente não cadastrado
1. Sistema informa “Cliente não cadastrado”
2. << Extends Incluir Cliente >>
2.a. Produto não cadastrado
1. Sistema informa: “Produto não cadastrado”
2. Sistema retorna ao passo 3.1 do cenário principal
4.a. Sem estoque su�ciente
1. Sistema informa: “Não há estoque su�ciente do produto para a quantidade informada”
2. Sistema retorna ao passo 3.3. do cenário principal
Cenários Alternativos 
Com base nos diagramas e especi�cações acima, o diagrama de sequência do cenário principal do caso de uso Registrar Pedido
pode �car (tem outras soluções) conforme abaixo.
O diagrama de sequência conta a
estória do caso de uso Registrar Pedido,
mostrando as classes que interagem e
quais mensagens são trocadas entre
eles.
Dessa solução, que é uma das possíveis, observe:
1
O método Inicializar Pedido, da classe PedidoE vai iniciar o pedido, gerando o número do pedido, através do método Gera
NumPedido, também da Classe PedidoE, criando ainda o objeto Itens Pedido, que vai armazenar os itens do pedido
inicializado, através do método Criar ItemPed, que tem como parâmetro o Num. Pedido que acabou de ser gerado.
2
Observe o lopp, quadrado que circunda desde o Item Pedido informado pelo Atendente até o retorno do método Incluir
Item Pedido (Num Pedido, Id Produto, Qtde Produto). Ele indica que todas as entradas de dados e métodos com seus
respectivos retornos são repetidos, conforme indicado na especi�cação textual do cenário principal do caso de uso em
questão (Registrar Pedido).
3
Observe que, a cada Produto e respectiva quantidade informados pelo atendente, e após veri�cações de produto
existente e quantidade em estoque, o item do pedido é registrado pelo método Incluir Item Pedido (Num Pedido, Id
Produto, Qtde Produto) da classe Itens Pedido.
4 Ao �nal, após o �m do loop, o pedido é con�rmado pelo Atendente, e então é �nalizado (registro efetivamente inserido).
Outra situação que deve ser analisada é a representação de herança no diagrama conceitual de classes, conforme abaixo
explicitado:
 Fonte: Extraído do livro proprietário da disciplina Modelagem de Sistemas [Seses].
Ao pensar no modelo conceitual de classes, temos três possibilidades:
Clique nos botões para ver as informações.
Quando as três classes têm relacionamentos individuais e há uma quantidade equivalente e equilibrada de atributos nas
quatro classes.
Opção 1: Manter as mesmas classes 
Quando a classe pai tem a maioria de relacionamentos e atributos. Nesse caso, essa classe absorve todos os atributos,
métodos e relacionamentos das classes �lhas.
Opção 2: Manter apenas a classe pai (Funcionário) 
Ou seja, a classe pai não tem relacionamentosou atributos especí�cos. Mas pode ser mantida no modelo, como uma classe
abstrata , ou seja, não tem atribuição especí�ca no contexto, mas incorpora o que há de comum entre as �lhas. Também
pode ser eliminada, dependendo da solução desejada.
Opção 3: Manter apenas as classes �lhas (diretoria, gerência e operação) 
1
Comentário
No exemplo ilustrado no trecho de diagrama de classes , vemos a classe empregado atuando como classe abstrata. Essa deve ter
ao menos um método abstrato.
 
Nesse exemplo, a classe empregada tem o método abstrato Vencimento() implementado pelo método de mesma assinatura, mas
com os respectivos códigos implementados, conforme o tipo de empregado (assalariado, comissionado e horista).
Conceitos de acoplamento e coesão
Quando falamos em arquitetura de um sistema, estamos falando de sua organização em partes, das relações de dependências
entre as partes e da forma como dividimos os elementos do sistema entre essas partes.
Quando falamos de partes, estamos nos referindo a subsistemas, módulos, pacotes, classes, componentes, métodos de uma
classe ou qualquer outra forma de organizar os elementos de um sistema.
Há dois conceitos relevantes que estão diretamente relacionados ao conceito de arquitetura de software: acoplamento e coesão.
Acoplamento
Diz respeito a dependência entre as partes, a forma
como estão relacionadas ou acopladas.
Coesão
Diz respeito ao grau de dependências entre os
elementos internos das partes do sistema.
https://stecine.azureedge.net/webaula/estacio/gon375/aula5.html
Continue lendo...

Continue lendo...
As classes precisam ser construídas levando em consideração a análise de coesão
entre as suas funcionalidades e ainda a avaliação do acoplamento entre as classes.
Considere, ainda nessa análise sobre as classes, o conceito de responsabilidade, que veremos mais detalhadamente a seguir.
Responsabilidade das classes
Uma das formas mais clássicas de pensar sobre projeto de objetos em um software diz respeito à responsabilidades, papéis e
colaborações.
A UML de�ne responsabilidade como “um contrato ou obrigação de um classi�cador”.
Responsabilidade tem relação com o que o objeto precisa fazer para exercer seu papel no contexto. Basicamente:
Fazer
algo em prol da colaboração, seja criando um objeto,
calculando, controlando demais objetos e etc.
Conhecer
os dados e os objetos relacionados.
As responsabilidades dos objetos são identi�cadas durante a fase ou disciplina de projeto de software.
A ideia de colaboração está intimamente relacionada com o conceito de responsabilidade. Responsabilidades são implementadas
por métodos, que atuam por si só ou colaboram com métodos de objetos relacionados. Os diagramas de interação são
extremamente úteis para atribuir responsabilidades às classes.
 Diagrama de classe.
A classe PedidoE é responsável por criar Itens Pedido (responsabilidade de fazer), e por conhecer o seu total (responsabilidade de
conhecer).
https://stecine.azureedge.net/webaula/estacio/gon375/aula5.html
https://stecine.azureedge.net/webaula/estacio/gon375/aula5.html
Sobre essa responsabilidade, para conhecer o seu total, a classe faz uso do método Obter
TotalPed (). Mas não faz isso sozinho. Precisa de colaboração da classe Itens Pedido,
através do método Obter Sub Total Ped (), pois quem conhece o total de cada linha de item
do pedido é a própria classe Itens Pedido.
Conceito de Interface
Outro conceito que deve ser incorporado a sua visão de agregar mais detalhes ao diagrama de classes de projeto é o de interface.
Uma classe pode ter em uma instância um objeto real, ao
passo que a interface precisa de uma classe para implementá-
la.
Observe a imagem onde, na parte superior do retângulo, que
representa a classe, é apresentado o estereótipo «interface».
 Representação de uma interface.
Dica
A partir da versão 2.0 da UML, uma interface é considerada uma especialização de uma classe e é desenhada como uma classe.
Uma interface é útil quando não se pode implementar herança múltipla (na linguagem de programação que se pretende usar),
mas permite inúmeras interfaces.
As classes que implementarem o conceito de interface passam a incorporar todos os
métodos da interface ou se transformam em uma classe abstrata.
Aplicando em seu TCC, o diagrama de classes de projeto e
diagrama de pacotes
Aplicando os conteúdos aqui ministrados, elabore o diagrama de classes de projeto, considerando o seu diagrama conceitual de
classes, construído na disciplina de Projeto de TCC em Sistemas de Informação.
• Caso seja necessário alterar diagramas de interação em função de novas formas de implementar uma determinada solução, não
há qualquer problema. Apenas avise ao seu orientador-tutor e, ao mandar o projeto como um todo, agregue essas eventuais
mudanças.
• Conforme identi�car métodos de classes que tenham algoritmos complexos e/ou que tenham atividades realizadas em paralelo,
faça anotações, pois o próximo passo é justamente a elaboração do diagrama de atividades para esses métodos.
• Cabe lembrar que a cada momento de evolução no projeto você deve registrar as bibliogra�as consultadas, independentemente
do tipo de mídia.
Atividade
1. No que se refere às atividades inerentes ao projeto de objetos: 
 
I. O diagrama conceitual de classes já traz as classes completas em termos da de�nição dos atributos. 
II. Re�namento das classes, com inserção de classes de software (de projeto). 
III. Inserção de métodos nas classes, com atribuições de responsabilidades. 
 
Com base em sua análise, assinale a única alternativa correta:
a) Estão corretas apenas II e III.
b) Está correta apenas I.
c) Estão corretas I, II e III.
d) Estão corretas apenas I e II.
e) Estão corretas apenas I e III.
2. Analise as duas assertivas a seguir e a relação entre elas: 
 
I. No modelo de classes de projeto podemos incluir novos atributos nas classes 
 
PORQUE 
 
II. No modelo conceitual de classes não representamos atributos. 
 
Com base em análise , assina a resposta correta quanto a assertividade de cada uma e sobre a relação entre elas.
a) As duas assertivas estão corretas e a segunda justifica a primeira.
b) As duas assertivas estão corretas e a segunda não justifica a primeira.
c) As duas assertivas estão erradas.
d) A assertiva I está correta e a assertiva II está errada.
e) A assertiva I está errada e a assertiva II está correta.
Notas
Classe abstrata 1
São “modelos” para classes que forem suas herdeiras. Não pode ser instanciada (ter objeto a ela associado). Para ter um objeto
de uma classe abstrata é necessário criar uma classe mais especializada, herdando dela e então instanciar essa nova classe.
Seus métodos devem ser sobrescritos, em suas classes �lhas.
Tais classes abstratas trazem consigo o conceito de métodos abstratos, implementados em suas subclasses para de�nir um
comportamento especí�co. O método abstrato de�ne tão somente a assinatura do método e não possui código, que estará em
cada classe especializada que desejar implementar aquele método (assinatura) de forma diferenciada, especí�ca.
Acoplamento
Partindo do próprio conceito de sistema, temos que sistema é um conjunto de partes independentes, cada qual realizando seu
trabalho, que juntas colaboram para um objetivo maior, em comum. Ou seja, as partes devem ser independentes ou pouco
dependentes. 
 
O acoplamento, assim, mede o grau de interdependência entre essas partes. Dessa forma, os sistemas devem ser organizados
para ter baixo acoplamento ou baixa dependência. 
 
O alto acoplamento entre as partes pode gerar di�culdade de: 
• Alteração no sistema, uma vez que existe dependência entre as partes (a alteração em uma parte pode demandar re�exos nas
que dela dependem); 
• Reutilização, uma vez que depende da presença de outras partes.
Coesão
Podemos dizer que a coesão mede, por exemplo, o grau de a�nidade entre as funcionalidades de cada parte do sistema. As
funcionalidades de uma parte devem levar ao desenvolvimento de apenas uma tarefae, nesse caso, devemos perseguir a alta
coesão, ou seja, que a a�nidade entre as funcionalidades seja alta. 
 
Uma parte com baixa coesão faz muitas coisas não relacionadas, e apresenta di�culdades de: 
• Entendimento das partes e consequentemente do sistema. 
• Reutilização, na medida em que a parte não realiza uma tarefa única. 
• Manutenção
Referências
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 3.ed. Rio de Janeiro: Elsevier, 2015. Cap. 3.
BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML - Guia do Usuário. 2.ed. Rio de Janeiro: Elsevier, 2005. cap. 1 e 2.
FOWLER, Martin. UML Essencial - Um Breve Guia Para a Linguagem-Padrão. 3.ed. Porto Alegre: Artmed, 2005. cap. 1.
LARMAN, Craig. Utilizando UML e Padrões? Uma Introdução à Análise e ao Projeto Orientados a Objetos e ao Processo
Uni�cado. 3.ed. Porto Alegre: Artmed, 2007. cap. 2.
Próxima aula
Detalhar lógica de métodos complexos e/ou com atividades em paralelo, usando o diagrama de atividades da UML;
Desenvolver o Diagrama de Atividades em seu TCC.
Explore mais
Leia os seguintes textos:
Engenharia de Software 2 - Análise Orientada a Objetos. Saiba como chegar a um modelo OO focado em responsabilidades a
partir de casos de uso <https://www.devmedia.com.br/artigo-engenharia-de-software-2-analise-orientada-a-objetos/9150> .
Acesso em: 02 jan. 2019.
O diagrama de classes
<https://www.ibm.com/developerworks/br/rational/library/content/RationalEdge/sep04/bell/index.html> . Uma introdução aos
diagramas de estrutura em UML 2. Acesso em: 02 jan. 2019.
Polimor�smo, classes abstratas e interfaces: fundamentos da POO em Java <https://www.devmedia.com.br/polimor�smo-
classes-abstratas-e-interfaces-fundamentos-da-poo-em-java/26387> . Acesso em: 02 jan. 2019.
Visite também a página da Uni�ed Modeling Language (UML) <//www.uml.org/> . Acesso em: 02 jan. 2019.
https://www.devmedia.com.br/artigo-engenharia-de-software-2-analise-orientada-a-objetos/9150
https://www.ibm.com/developerworks/br/rational/library/content/RationalEdge/sep04/bell/index.html
https://www.devmedia.com.br/polimorfismo-classes-abstratas-e-interfaces-fundamentos-da-poo-em-java/26387
https://www.uml.org/