UML Aspectos de projetos em Diagramas de classes

UML
Aspectos de projetos em Diagramas de classes
Após ser definido o contexto da aplicação a ser gerada. Devemos pensar em detalhar o
Diagrama de Classes com informações visando uma implementação Orientada a Objetos por
meio de linguagem de programação.
1. Operações e Métodos
Uma Operação em um diagrama de classes descreve um comportamento do objeto
modelado. Um método é a implementação de uma operação para uma classe.
Toda classe deve possuir os métodos new, get e set. A operação new que permite o
instanciamento de objetos. A operação get permite obter o valor de um determinado atributo e por
fim o método set permite setar (definir) o valor para um atributo da classe.
2. Classes abstratas
Uma classe abstrata é uma classe na qual não se instancia objetos. Em oposição a
esta classe temos as classes concretas, classes pelas quais os objetos são instanciados.
Se a classe pessoa for definida como abstrata ela não permitirá instanciamento de
objetos, isto só será possível pelas suas especialização, fornecedor e cliente, que herdam os
atributos e operações da usa superclasse.
Uma classe abstrata pode possuir métodos concretos e métodos abstratos.
Um
método abstrato é o método contido em uma classe abstrata que não possui implementação. Nele
estão definidos apenas sua assinatura. A implementação de um método abstrato é feita na
subclasse, classe filha, por intermédio de de sobrescrita de método (overriding )
3. Interface
Uma interface é um tipo de classe abstrata em que todos métodos são abstratos. Os
métodos são definidos na classe no entanto eles não possuem corpo (código de implementação).
Assim como a classe abstrata a interface não pode ser instanciada
4. Navegabilidade
Qualquer associação entre classes é bidirecional. No entanto, a implementação de um
relacionamento bidimensional é custosa em termos de implementação. Isto faz com que para
cada associação tenhamos que determinar sua navegabilidade.
Se uma classe não necessita saber a que outras classes está associada, então não é
necessário criar condições para tal navegação. Por intermédio dos diagramas de sequência e
colaboração, que serão vistos mais tarde, é possível identificar o sentido da navegabilidade .
Exemplo:
Neste caso temos que a navegabilidade é de livro para autor significando que em tempo de
execução a classe livro dever reter um atributo que guarde os autores a ela relacionados .
Neste caso temos que a navegabilidade é de autor para livro significando que em tempo de
execução a classe autor dever reter um atributo que guarde os livros a ela relacionados .
Neste caso temos que a navegabilidade é bidirecional significando que uma deve guardar
informações da outra quanto ao relacionamento existente entre elas.
Para garantir a navegabilidade é necessitário a definição de atributo(s) que guardem informações
das instancias de classe associadas. Se considerarmos o primeiro caso onde a navegabilidade é
de livro para autor teremos:
Código em java para a classe livro
Código em java para a classe autor
import java.util.Vector;
public class autor {
public class livro {
private String titulo;
private String sub-titulo;
private Vector myautor;
private String nome;
public String getTitulo() {
return null;
}
public String getNome() {
return null;
}
public String getSubtitulo() {
return null;
}
public void setNome( nome:string) {
}
}
public void setTitulo( titulo:string) {
}
public void setSubtitulo( subtitulo:string) {
}
}
5. Dependência
Uma Dependência indica um relacionamento semântico entre os dois elementos de
modelagem (ou conjunto de elementos de modelagem). A dependência relaciona os elementos de
modelagem por si só, não demandando um conjunto de instâncias para seu significado, e
normalmente indicam situações em que uma mudança em um dos elementos pode demandar
uma mudança no elemento que dele depende.
A linguagem UML estabelece ainda um conjunto de estereótipos padrões para
dependências: access, bind, derive, import, refine, trace e use.
A dependência é um relacionamento temporário entre objetos cujo propósito é evitar o uso
de relacionamentos permanentes, como as associações de agregação e de composição. Objetos
só se comunicam se forem capazes de ver uns aos outros. Quando o relacionamento é de
associação, esta visibilidade é conseguida com um atributo de referência.
A dependência, relacionamento temporário, pode implementada por uma de três soluções:
variável local de métodos, parâmetros de métodos, ou variáveis globais. A seguir as soluções são
detalhadas e ilustradas em um diagrama de classe e exemplificadas na listagem a seguir.
1.A operação op1() de ClasseA contém um variável local do tipo ClasseB.
2.A instância da ClasseB é passada para a instância da ClasseA no método op2(ClasseB b).
3.Uma classe é visível à ClasseA porque é global. Por exemplo, em Java, as classe
java.lang.Math e java.lang.Vector estão visíveis e globais para a ClasseA. Se os nomes das
classes estiverem completamente qualificados, então o importe não é necessário.
Código em java para classe A:
public class ClasseA {
public void op1() {
ClasseB b = new ClasseB();
}
public void op2(ClasseB b) {
...
}
}
exemplo:
No diagrama de UML
No código em Java
public class livro, {
private String titulo;
private String sub-titulo;
private autor Autor_1;
public Vector myautor;
public String getTitulo() {
return null;
}
...
public void incluirAutor() {
Autor_1 = new autor();
}
}
6 Esteriótipo
Uma classe é um conjunto de objetos que partilham uma estrutura e um comportamento
comum. Uma classe é uma abstração de um item do mundo real. Quando estes itens existem, são
instâncias da classe respectiva e são denominados objetos; As classes podem ser agrupadas e
nomeadas por grupos semelhantes por intermédio de esteriótipos.
Principais esteriótipos para classe:
Classe Fronteira (Boundary) - classe usada para modelar a interação entre o ambiente do
sistema e seus trabalhos internos. Essa interação envolve transformar e converter eventos, bem
como observar mudanças na apresentação do sistema (como a interface). Permitem a
comunicação entre o mundo externo e o sistema.
Notação da UML para classe fronteira:
Classe de controle (control) - classe usada para modelar um comportamento de controle
específico de um ou alguns casos de uso. Como objetos de controle (instâncias de classes de
controle) geralmente controlam outros objetos, o comportamento de objetos de controle é do tipo
coordenador. As classes de controle encapsulam um comportamento específico de caso de uso.
Notação da UML para classe Controle:
Classe de entidade (entity) - Classes de objetos que refletem objetos, entidades, do mundo real
que pertence ao domínio do problema que está sendo modelado. As classe entidade são usadas
para modelar as informações e o comportamento associado que devem ser armazenados. Esses
objetos geralmente são persistentes, precisando de atributos e relacionamentos durante muito
tempo, algumas vezes durante todo o ciclo de vida do sistema. Um objeto de entidade também
pode ajudar a executar tarefas internas do sistema.
Notação da UML para classe Controle:
Classe Parametrização (Parameterized)- Neste tipo de classes são declarados, formalmente,
parâmetros genéricos.
Classe utilitária (utility) - Classes não instanciáveis, contendo um ou mais métodos de classe;
Metaclasse (Metaclass) - Classes cujas instâncias são classes. Providenciam operações para
inicialização de variáveis de classe, servindo como repositórios de suporte às variáveis de classe,
necessários para todos os objetos da classe definida.
7. Classes Conceituais e classes de implementação
As classes em um diagrama de classes podem ser de dois tipos básicos: Classes
Conceituais ou Classes de Implementação.
Classes de conceituais
As classes Conceituais devem representar as regras do negócio podendo-se omitir
métodos, e representar somente especificações comportamentais para sua operação e ainda a
representação de atributos e associações entre classes. Sem a preocupação de representar a
visibilidade e assinatura, tanto para as classes como para os atributos.
Classes de Implementação
As classes de implementação definem uma estrutura de dados física (para atributos e
associações) e métodos de um objeto como implementados em linguagens de programação.
Tradicionais.
A notação para interfaces, no UML, é a de uma classe sem compartimento de atributos,
com o estereótipo «interface» ou simplesmente um círculo (visão estereotipada da interface). Uma
dependência abstrata entre uma classe e uma interface pode ser representada por uma linha do
tipo
generalização tracejada ou por uma linha cheia ligada a um círculo representando a interface,
conforme na figura 14.
8. Pacotes
Um pacote na UML tem por objetivo particionar os diagramas de um determinado modelo. Pode
ser aplicado a qualquer diagrama da UML.
Os diagramas da UML podem ser empacotados com a finalidade de:
 Criar diagramas de tamanhos tratáveis
 Gerar uma organização que propicie a reusabilidade dos códigos que serão gerados
 Criar um contexto que facilite a compreensão do modelo
Notação:
<<Es teriotipo>>
P a c o te A
Pacotes podem conter outros pacotes:
Notação:
<<es teriotipo>>
P a c o te A
s ub_pacote A1
Sub_pacote A2
Pacotes podem ser reaproveitados de outros pacotes e ou outras classes de outros pacotes:
Notação:
<<esteriotipo>>
Pacote A
sub_pacote A1
Sub_pacote A2
(from Pacote A)
(from Pacote A)
Outros exemplos genéricos do uso de pacotes para organizar o modelo de um sistema:
Pacote A
classAA
(from Pacote A)
Class AB
(from Pacote A)
Pacote A
class AA
(from Pacote A)
s ubPacoteA1
Clas s AB
(from Pacote A)
SubPacoteA2
1. DEPENDÊNCIA EM EMPACOTAMENTO
Neste caso deve-se representar qual pacote necessitas de classes contidas em outros
pacotes para desempenhar algum de das responsabilidades das classes nele contidas.
VEND AS
PRODUTOS
2. NOMEAÇÃO DE PACOTES
Não existe uma regra oriunda dos conceito da UML para nomear os pacotes a serem
empregados no modelo. Porem, dependendo da situação os pacotes produzidos tem sido
nomeados segundo:
 Pacotes nomeados segundo seu estereótipo
 Pacotes nomeados segundo o contexto da aplicação
 Pacotes nomeados segundo o grau de associações existentes entre as classes
2.1 Pacotes nomeados segundo o seu estereótipo
<<lim ítrofe>>
interface com
us uario
<<entidade>>
dom ínio da
aplicacao
<<controle>>
gerenciador_do_
sis tem a
<<servico>>
acesso BD
2.2 Pacotes nomeados segundo o contexto da aplicação
clientes
produtos
clientes _BD
Cliente_controle
(from clientes )
(from clientes )
Cliente_entidade
(from clientes )
vendas
fornecedores
<<limítrofe>>
Interface_Us uario
2.3 Pacotes nomeados segundo a hierarquia de herança
pessoas
produtos
pess oa
(from pessoas)
Pes soa_juridica
(from pessoas )
pess oa_fis ica
(from pessoas)
produto
(from produtos )
perecivel
(from produtos )
nao_perecivel
(from produtos )