Inicio - SETI
A modelagem de um sistema envolve a identificação de itens considerados importantes de acordo com uma determinada visão. Esses itens formam o vocabulário do sistema a ser modelado. Uma classe é uma abstração de itens que fazem parte do vocabulário do sistema. A classe não é um objeto individual, mas representa um “conjunto” inteiro de objetos que compartilham os mesmos atributos, operações, relacionamentos e semântica.
Classes
Na prática, os nomes das classes são substantivos ou expressões substantivadas breves, definidos a partir do vocabulário do sistema cuja modelagem esta sendo feita. Tipicamente, aparece como maiúsculo o primeiro caractere de cada palavra existente no nome da classe, ex.: Cliente, Pedido, ItemDoPedido, ContaPagar, ContaReceber, etc. Uma classe que não pode possuir instância direta (um objeto não pode ser instanciado diretamente da classe) é dita classe abstrata (oposto de classe concreta) e na UML a notação para identificar uma classe abstrata é colocar o nome da classe em itálico.Atributos
Os nomes dos atributos são substantivos ou expressões substantivadas breves, que representam alguma característica da classe correspondente. Tipicamente, aparece como maiúsculo o primeiro caractere de cada palavra existente no nome do atributo, exceto a primeira letra do nome, ex.: nome, enderecoComercial, tipoCargo, valorSalario, etc.Operações
Os nomes das operações são verbos ou locuções verbais breves, que representam algum comportamento da classe correspondente. Tipicamente, aparece como maiúsculo o primeiro caractere de cada palavra existente no nome da operação, exceto a primeira letra do nome, ex.: compare, calcularSalario, getNome, setEnderecoComercial, isSalvo, etc. Um operação que não possui implementação (por questões técnicas o método não será implementado) é dita operação abstrata, neste caso, uma classe derivada (descendente) precisa fornecer (por sobreposição) um método para a implementação da operação. A notação da UML para identificar operações abstratas é colocar o nome da operação em itálico.Relacionamentos
Um relacionamento é uma conexão entre itens. Em uma modelagem orientada a objetos, os três relacionamentos mais importantes são as dependências, as generalizações e as associações.Dependência
Uma dependência é um relacionamento de utilização, determinando as modificações na especificação de um item. A dependência é representada graficamente como linhas tracejadas apontando o item do qual o outro depende. |
Generalização
Uma generalização é um relacionamento entre itens gerais (superclasses ou classes-mãe) e tipos mais específicos desses itens (subclasses ou classes-filha). Muitas vezes, as generalizações são chamadas relacionamentos “é um tipo de”. Uma generalização é representada graficamente como uma linha sólida apontando a classe-mãe. |
A generalização existente entre uma classe e uma interface é chamada de realização. Uma realização é representada graficamente como uma linha tracejada apontando a interface (classe-mãe). Normalmente, a realização indica que uma operação abstrata da interface deve ser sobreposta pela classe derivada, especificando, desta maneira, a realização do contrato estipulado entre a interface (contratada) e a classe (contratante) relacionada (associação) à interface.
No exemplo indicado pela Figura 3, o serviço “contratado” pela classe ClasseA à interface InterfaceA é especificado pela operação operacaoA(), entretanto, efetivamente quem realiza o serviço é a ClasseB pela sobreposição da operação operacaoA()(considerando os mecanismos de herança e polimorfismo). Sendo assim, a interface é a classe que intermedia a contratação de um serviço que é especificado por uma operação (cláusula do contrato), em outras palavras, a interface é a 'classe' que serve de 'interface' entre duas classe (a que contrata o serviço e a que efetivamente realiza o serviço).
 |
Associação
Uma associação é um relacionamento estrutural que especifica objetos de um item conectados a objetos de outro item. Uma associação é representada graficamente como uma linha sólida conectando a mesma classe ou classes diferentes. |
Uma associação pode possuir: nome, papéis e multiplicidade.
- Nome: Utilizado para descrever a natureza do relacionamento.
- Papel: Quando uma classe participa de uma associação, ela tem um papel específico a executar nesse relacionamento; o papel é apenas a face que a classe próxima a uma das extremidades apresenta à classe encontrada na outra extremidade da associação.
- Multiplicidade: Representa a quantidade de objetos que podem ser conectados pela instância de uma associação. E é escrita como uma expressão equivalente a um intervalo de valores ou a um valor explícito. A multiplicidade do diagrama de classes na UML pode ser definida conforme tabela abaixo:
| Multiplicidade | Tipo | Observação |
|---|---|---|
| 0 | Exatamente zero | Definido pela UML, porém, não usual. Um relacionamento com multiplicidade exatamente zero indica uma inexistência do relacionamento. |
| 0..1 | Zero ou um | Um objeto pode estar relacionado com zero ou no máximo um outro objeto. |
| 0..* | Zero ou muitos | Um objeto pode estar relacionado com zero ou no máximo muitos outros objetos. |
| 1 | Exatamente um | Um objeto pode estar relacionado com exatamente um outro objeto. Neste caso, poderá ser omitido (definindo-o como valor de multiplicidade defaut). |
| 1..* | Um ou muitos | Um objeto pode estar relacionado com um ou no máximo muitos outros objetos. |
| * | Muitos | Um objeto pode estar relacionado com zero ou no máximo muitos outros objetos. Equivalente ao relacionamento 0..*. |
| n..m | De n até m inclusive | Um objeto pode estar relacionado com n ou no máximo m (inclusive) outros objetos. Por exemplo: 3..5, 1..2, 1..10. |
 |
Agregação
Uma agregação é um relacionamento estrutural entre uma classe que representa um item maior (o “todo”) e a classe que representa o item menor (a “parte”). Representa um tipo de relacionamento “tem um” ou “todo/parte”. A agregação é um tipo de especial de associação, representada graficamente como uma linha sólida com um “diamante” aberto na extremidade do todo. |
Composição
É uma forma de agregação onde o tempo de vida da parte é coincidente com o tempo de vida do todo. A composição é um tipo de especial de associação, representada graficamente como uma linha sólida com um “diamante” fechado na extremidade do todo. |
Associação x Agregação x Composição
A agregação é um tipo especial de relacionamento de associação, ou seja, é uma associação, entretanto, possui uma semântica (significado) diferente no contexto de modelagem do diagrama de classes, em tempo de implementação, pouca diferença existe entre um relacionamento de associação e agregação. A semântica associada ao relacionamento de agregação é a indicação do “todo/parte”, ou seja, quando da abstração do 'objeto de dado' (no contexto do problema) for indicada a necessidade de dividir o 'objeto de dado' em mais de uma classe, considerando questões de modularidade, coesão e acoplamento. |
No exemplo indicado pela Figura 8, quando da avaliação da modelagem indicada pela referida figura, pode-se claramente entender que ItemPedido é parte de Pedido (todo), entretanto, esta definição depende do contexto do problema e de definições de abstração, ou seja, em um outro contexto de problema ou em uma outra abstração do mesmo problema, pode não ser indicada a existência de um relacionamento de agregação entre Pedido e ItemPedido.
Portanto, a utilização de um relacionamento de agregação é subjetiva e não deve ser utilizada indiscriminadamente. Deve ser utilizado em momentos onde o significado (semântica), efetivamente, seja de especificar e documentar a indicação do “todo/parte”.
Com relação ao relacionamento de composição toda definição de agregação também é válida, pois, uma composição é, também, uma agregação (e consequentemente uma associação), entretanto, a composição possui uma semântica mais restritiva que o relacionamento de agregação, diretamente relacionada ao tempo de vida dos objetos instanciados.
 |
Considerando o exemplo apresentado pela Figura 9, para um determinado contexto de problema e para uma determinada interpretação do Analista de Sistemas (dependendo de questões subjetivas de abstração), quando existe uma indicação de “todo/parte”, onde, NotaFiscal é o todo e NumeroNota é a parte pode-se interpretar claramente a existência de um relacionamento de agregação, entretanto, quando além do significado de agregação existe o significado de tempo de vida coincidente, deve-se considerar a existência de um relacionamento de composição.
Para o citado exemplo, quando para instanciar um objeto da classe NotaFiscal seja necessário instanciar, também, um objeto da classe NumeroNota (em um momento semelhante) e quando os dois objetos não podem existir isoladamente, ou seja, para destruir um objeto da classe NumeroNota (parte) deve, também, ser destruído obrigatoriamente o objeto do classe NotaFiscal (todo) correspondente, existe a indicação de um relacionamento de composição.
Assim como na agregação, a utilização de um relacionamento de composição é subjetiva e não deve ser utilizada indiscriminadamente. Deve ser utilizado em momentos onde o significado (semântica) efetivamente seja de especificar e documentar a indicação do “todo/parte” e, ainda,. que “tempo de vida da parte é coincidente com o tempo de vida do todo”