UML - Diagrama de Classes - SourceInnovation

Prévia do material em texto

18/09/13 UML - Diagrama de Classes - SourceInnovation
www.sourceinnovation.com.br/index.php/UML_-_Diagrama_de_Classes 1/8
UML - Diagrama de Classes
De SourceInnovation
Índice
1 Introdução
2 Conceito de Classes
3 Herança
4 Polimorfismo
5 Relacionamentos entre classes
5.1 Associações
5.2 Dependência
5.3 Agregação
5.4 Composição
6 Diagrama de Classes
6.1 Exemplos
7 Referências
Introdução
João
A UML(Unified Modeling Language ou Linguagem de Modelagem Unificada) é uma linguagem visual utilizada para modelar sistemas
computacionais por meio do paradigma da Orientação a Objetos. Essa linguagem tornou-se, nos ultimos anos a linguagem-padrão de
modelagem de software adotada internacionalmente pela industria da Engenharia de software.
Ressalto aqui que a UML não é uma linguagem de programação, e sim uma linguagem de modelagem.
A diferença da linguagem de modelagem para a linguagem de programação está no fato de que a linguagem de modelagem é um meio de
guiar engenheiros e técnicos sobre os requisitos, o comportamento, estrutura lógica e até necessidades fisicas de um determinado software.
A UML surgiu da união de três métodos de modelagem, o método de Booch, o método OMT de Jacobson e o método OOSE. Que foram
os métodos mais populares entre os profissionais da área até meados da década de 90.
Conceito de Classes
Michelly
Em POO , os problemas de programação são pensados em termos de objetos, nada de funções, rotinas, nada disto, o assunto são os
objetos, propriedades e métodos.
Um exemplo de sistema de vendas de carros , é pensar que tudo que tenha nesta loja seja tratados como objetos.
Cliente é um objeto , Carro é um objeto , Vendedor é um objeto .
Definição de um objeto : " Um objeto é um termo que usamos para representar uma entidade do mundo real . Tendo como características e
comportamentos nesse mundo.
Exemplo de um objeto:
Uma Ferrari é um objeto. Ele tem como características a cor, peso, quantidade de portas, modelo, ano, etc. Também tem ações como frear,
buzinar, acelerar, abrir os vidros, trocar de marchas, etc. Portanto programar Orientado a Objetos é você fazer essa abstração do mundo real e
transforma-la em código.
Em termos de POO para poder tratar os objetos precisamos criar as classes.
18/09/13 UML - Diagrama de Classes - SourceInnovation
www.sourceinnovation.com.br/index.php/UML_-_Diagrama_de_Classes 2/8
Definição de Classe : É uma descrição de um conjunto de objetos que compartilham os mesmos atributos, operações, relacionamentos e
semântica.
Uma classe é representada por um retângulo que pode possuir até três divisões:
 - Nome da classe;
 - Atributos da classe;
 - Métodos da classe.
Visibilidade de atributos e operações :
Para poder representar a visibilidade dos atributos e operações em uma classe utiliza-se as seguintes marcas e significados:
- (+) público - visível em qualquer classe
- (#) protegido - qualquer descendente pode usar
- (-) privado - visível somente dentro da classe
Herança
Michelly
Herança é um mecanismo que permite que características comuns a diversas classes com comportamentos comuns ou parecidos, sejam
abstraídas e centralizadas em uma classe base, ou superclasse. Este permite poupar tempo quando se trata de criar classes que são
similares a outras.
Usando a analogia de pai e filho , o filho herda características do pai , e assim em POO o PAI será a SUPERCLASSE e o FILHO será
SUBCLASSE.
Exemplo :
Uma Ferrari é um carro. Logo ele foi herdado da classe carro, pois contém as características comuns de um carro. Assim a classe Carro será a
SUPERCLASSE. E a classe Ferrari será a SUBCLASSE.
A partir dessa superclasse outras classes podem ser especificadas. Portanto uma subclasse que é uma classe herdada da superclasse recebe sem
codificação extra as características da superclasse. Ainda podemos adicionar elementos particulares a está subclasse.
Em Java :
public class Ferrari extends Carro
18/09/13 UML - Diagrama de Classes - SourceInnovation
www.sourceinnovation.com.br/index.php/UML_-_Diagrama_de_Classes 3/8
Polimorfismo
Michelly
Analisando a palavra Polimorfismo, ela significa "muitas formas". Essas formas, em nosso contexto de programação, são as subclasses/objetos
criados a partir de uma classe maior, mais geral, ou abstrata. Polimorfismo é a capacidade de controlar todas as formas de uma maneira mais
simples e geral, sem ter que se preocupar com cada objeto especificamente.
Com o polimorfismo vamos ter um controle maior sobre as subclasses sem ter que nos preocupar especificamente com cada uma delas, pois cada
uma terá autonomia para agir de uma maneira diferente.
Formas de polimorfismo:
Sobrescrita de métodos
Esta utilidade nos permite escrever numa subclasse um ou mais métodos presentes numa das superclasses podendo alterar o comportamento da
superclasse.
Exemplo : Aumento no preço dos carros .
Em uma loja de carros , todo ano os carros tem um aumento.
A Ferrari teve um aumento de 5%. O Jaguar teve um aumento de 4%.
Note que todos sejam "Carro", mas cada objeto terá que calcular seu aumento de forma diferente, pois terão diferentes valores de aumento. E
para que isso seja feito em OO, será necessário criar um método aumento() em cada subclasse.
Isso é um exemplo de polimorfismo de sobrescrita de métodos : embora todos os objetos sejam "Carro", eles terão uma forma diferente de agir,
pois em cada subclasse implementamos os métodos de maneira diferente.
18/09/13 UML - Diagrama de Classes - SourceInnovation
www.sourceinnovation.com.br/index.php/UML_-_Diagrama_de_Classes 4/8
Lembrando que a sobrescrita de métodos só é valida quando o método reescrito na subclasse tem exatamente a mesma identificação (nome, tipos,
etc.) do método da superclasse.
Sobrecarga de método ou construtor
O Polimorfismo ainda permite que numa mesma classe tenhamos métodos com o mesmo nome, desde que o número ou tipos de parâmetros
passados sejam diferentes.
A sobrecarga de métodos é uma ferramenta poderosa, pois nos permite criar vários métodos com o mesmo nome, isso facilita o entendimento de
problemas mais complexos, pois não é necessária a criação de nomes de funcionalidades sem sentido aparente.
Relacionamentos entre classes
18/09/13 UML - Diagrama de Classes - SourceInnovation
www.sourceinnovation.com.br/index.php/UML_-_Diagrama_de_Classes 5/8
Othávio
• Os relacionamentos possuem:
Nome: descrição dada ao relacionamento (faz, tem, possui,...).
Sentido de leitura.
Navegabilidade: indicada por uma seta no fim do relacionamento.
Multiplicidade:
Tipo: associação (agregação, composição), generalização e dependência.
Papéis: desempenhados por classes em um relacionamento.
Associações
Othávio
Relacionamentos: Associação 
• Agregação
É um tipo especial de associação.
Utilizada para indicar “todo-parte”.
Ex.:
um objeto “parte” pode fazer parte de vários objetos “todo”.
• Composição
É uma variante semanticamente mais “forte” da agregação.
Os objetos “parte” só podem pertencer a um único objeto “todo” e têm o seu tempo de vida coincidente com o dele.
Ex.:
18/09/13 UML - Diagrama de Classes - SourceInnovation
www.sourceinnovation.com.br/index.php/UML_-_Diagrama_de_Classes 6/8
Quando o “todo” morre todas as suas “partes” também morrem.
Dependência
Othávio
• Relacionamento: Dependência
Representa que a alteração de um objeto (o objeto indepedendente) pode afetar outro objeto (o objeto dependente).
Ex:
 
-Obs.:
A classe cliente depende de algum serviço da classe fornecedor.
A mudança de estado do fornecedor afeta o objeto cliente.
A classe cliente não declara nos seus atributos um objeto do tipo fornecedor.
Fornecedor é recebido por parâmetro de método.
Agregação
Maykell
Tipo especial de associação que tenta demonstrarque as informações de um objeto-todo precisam ser complementadas pelas informações
contidas em um (ou mais) objetos-parte.
A existência do objeto-parte faz sentido mesmo não existindo o objeto-todo.
Um objeto “parte” pode fazer parte de vários objetos “todo”.
A associação de agregação pode, em muitos casos, ser substituída por uma associação binária simples, dependendo da visão de quem faz a
modelagem.
As palavras chaves usadas para identificar uma agregação são: "consiste em", "contém", "é parte de".
Exemplo
Arquivo:Agregação.pdf
Composição
Maykell
Uma forma mais forte de agregação.
Há uma coincidência da vida das partes.
Uma vez criada a parte ela irá viver e morrer com ele.
O “Todo” é responsável pelo gerenciamento da criação e destruição das partes.
Exemplo
18/09/13 UML - Diagrama de Classes - SourceInnovation
www.sourceinnovation.com.br/index.php/UML_-_Diagrama_de_Classes 7/8
Arquivo:Composição.pdf
Diagrama de Classes
Porque modelar um software?
Uma casa precisa ser projetada? Um pedreiro experiente consegue construir uma casa sem precisar 
de um projeto. Agora pensemos se essa casa um dia precisar de um reparo no encanamento ou na fiação 
em um determinado ponto, devemos quebrar toda a parede para reparar um pequeno ponto? essa parede 
não é uma parede de sustentação principal da casa?
Exemplos
João 
Exemplo 1 Hotel:
Arquivo:Hotel.pdf
Exemplo 2 Matrícula:
18/09/13 UML - Diagrama de Classes - SourceInnovation
www.sourceinnovation.com.br/index.php/UML_-_Diagrama_de_Classes 8/8
Arquivo:Matricula.pdf
Maykell
Exemplo 3 Locadora:
Arquivo:Locadora.pdf
Referências
GUEDES, Gilleanes. UML Uma Abordagem Prática. Editora Novatec. São Paulo, 2007. -
(http://www.ebah.com.br/content/ABAAAfQA8AI/uml-abordagem-pratica, acessado em 20/07/2013)
(http://iscte.pt/~ipxa/FBD/fich/DiagClasses.pdf, acessado em 19/07/2013)
(http://docente.ifrn.edu.br/givanaldorocha/disciplinas/engenharia-de-software-licenciatura-em-informatica/diagrama-de-class, acessado em
20/07/2013)
Disponível em "http://www.sourceinnovation.com.br/index.php?title=UML_-_Diagrama_de_Classes&oldid=16578"
Esta página foi modificada pela última vez à(s) 23h17min de 23 de julho de 2013.
Esta página foi acessada 266 vezes.