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 import java.util.vector; public class livro { private String titulo; private String sub-titulo; private Vector myautor; public String gettitulo() { return null; public String getsubtitulo() { return null; Código em java para a classe autor public class autor { private String nome; public void setnome( nome:string) { public String getnome() { return null; 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 t e A
Pacotes podem conter outros pacotes: Notação: <<es teriotipo>> P a c o t e 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 Outros exemplos genéricos do uso de pacotes para organizar o modelo de um sistema: Pacote A classaa ClassAB
Pacote A classaa ClassAB s ubpacotea1 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. V E N D A S 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_ sistema <<servico>> a c e s s o B D 2.2 Pacotes nomeados segundo o contexto da aplicação clientes clientes_bd (from clientes) Cliente_controle (from clientes) produtos Cliente_entidade (from clientes) fornecedores vendas <<limítrofe>> Interface_Usuario 2.3 Pacotes nomeados segundo a hierarquia de herança pessoas produtos pessoa (from pessoas) produto (from produtos) Pessoa_juridica (from pessoas) pessoa_fisica (from pessoas) perecivel (from produtos) nao_perecivel (from produtos)