UML - Diagrama de Classes

Introduçã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

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

• 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

• 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

• • 

Polimorfismo

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.

• • 

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

• 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

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

• Quando o “todo” morre todas as suas “partes” também morrem.

Dependência

• 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

• Tipo especial de associação que tenta demonstrar que 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

• 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
  • 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

• Exemplo 1 Hotel:
  • 
  • Arquivo:Hotel.pdf
• Exemplo 2 Matrícula:
  • 
  • Arquivo:Matricula.pdf

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