wiki

UML - Diagrama de Classes

Revisão de 20h23min de 23 de julho de 2013 por Othávio Mendes Vala (discussão | contribs) (→Relacionamentos entre classes)

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

  • 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.
  • Definição de um objeto : "Um objeto é um termo que usamos para representar uma entidade do mundo real . Objetos similares são agrupados em classes. No paradigma da orientação a objetos, tudo pode ser potencialmente representado como um objeto. "
  • 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. De uma forma simples, herança é o mecanismo que faz com que uma nova classe herde da classe mãe (ou superclasse) atributos e métodos.
  • 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á chamada de SUPERCLASSE. E a classe Ferrari será chamado de 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.

Quando numa subclasse reescrevemos um método já existente numa superclasse, chamamos de sobrescrita de método ou reescrita de método. 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

--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: 0..1, 0..*, 1, 1..*, 2, 3..7.
  • Tipo: associação (agregação, composição), generalização e dependência.
  • Papéis: desempenhados por classes em um relacionamento.


Associações

--Othávio

  • O que é?
  • Exemplo


Dependência

--Othávio

  • O que é?
  • Exemplo


Agregação

--Maykel

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


Composição

--Maykel

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

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 e Maykel


Referências

Disponível em “http://3.143.69.156/wiki/index.php?title=UML_-_Diagrama_de_Classes&oldid=16533”