Baixe o app para aproveitar ainda mais
Prévia do material em texto
Guia para Modelagem de Classes de Projeto Metodologia CELEPAR Agosto 2009 Sumário de Informações do Documento Documento: guiaModelagemDiagramaClasses.odt Número de páginas: 29 Versão Data Mudanças Autor 1.0 Criação. Este documento contém algumas orientações extraídas do guia ORIENTAÇÕES PARA DOCUMENTAR A FASE DE PROJETO(documento elaborado por autores do GIC e da GTI) da versão 1.0 da metodologia CELEPAR. Danielle Mayer 1.0 21/08/09 Revisão Danielle Mayer, Marcos Chiarello, Cleverson Budel, Willian Medeiros 1.0 17/11/2009 Alterando exemplos com a correção após a primeira turma de treinamento. Danielle Mayer Sumário 1 Introdução.........................................................................................................................................4 2 Principais Conceitos .........................................................................................................................4 2.1 GRASP: Padrões de Princípios Gerais para a Atribuição de Responsabilidades.....................4 2.1.1 Especialista na Informação (Information Expert) ............................................................4 2.1.2 Criador (Creator)..............................................................................................................6 2.1.3 Acoplamento Fraco (Baixo Acoplamento – Low Coupling)...........................................7 2.1.4 Coesão Alta .....................................................................................................................9 2.1.5 Controlador (Controler)..................................................................................................10 2.2 Arquitetura de software..........................................................................................................11 2.2.1 Padrão MVC...................................................................................................................11 2.2.2 Padrão Fachada...............................................................................................................12 3 Arquitetura lógica Adotada............................................................................................................14 3.1 Camada de Controle................................................................................................................14 3.1.1 Classe Controle...............................................................................................................14 3.2 Camada de Visualização.........................................................................................................16 3.2.1 Classes Tela.........................................................................................................................16 3.3 Camada de Modelo.................................................................................................................17 3.3.1 Classe Serviço.................................................................................................................17 3.3.2 Classe Domínio...............................................................................................................20 3.3.3 Classe de Persistência.....................................................................................................21 3.3.4 Classe DTO (Data Transfer Objects)..............................................................................24 4 Tratamento de Domínios ...............................................................................................................25 5 Tipos de dados Recomendados: ..................................................................................................27 6 Checklist de elaboração..................................................................................................................28 4 1 INTRODUÇÃO Durante a fase de projeto há uma ênfase na definição dos objetos de software (projeto de objetos), como eles colaboram para a satisfação dos requisitos e como se dará a persistência dos mesmos. Neste contexto encontramse os diagramas de interação e as classes de projeto, estas vislumbradas sob a ótica de uma arquitetura lógica. Este documento tratará dos conceitos inerentes aos padrões arquiteturais e de projeto que norteiam a modelagem do diagrama de classes de projeto. 2 PRINCIPAIS CONCEITOS Fundamentalmente, o projeto de objetos exige o conhecimento de princípios de atribuição de responsabilidades, padrões de projetos e arquiteturais. Um padrão de projeto nomeia, abstrai e identifica os aspectoschave de uma estrutura de projeto comum para tornála útil para a criação de um projeto orientado a objetos reutilizável. O padrão de projeto identifica as classes e instâncias participantes, seus papéis, colaborações e a distribuição de responsabilidades. Cada padrão de projeto focaliza um problema ou tópico particular de projeto orientado a objetos, descreve quando e se ele pode ser aplicado em função de outras restrições de projetos e as conseqüências, custos e benefícios de sua utilização. Nos próximos tópicos será apresentado os principais padrões GRASP, os conceitos de arquitetura de software, o padrão arquitetural MVC e o padrão FACHADA. 2.1 GRASP: Padrões de Princípios Gerais para a Atribuição de Responsabilidades Os padrões GRASP descrevem princípios fundamentais de projeto baseado em objetos e atribuições de responsabilidade aos mesmos. 2.1.1 Especialista na Informação (Information Expert) É o padrão mais usado na atribuição de responsabilidade. Determina quem é o especialista METODOLOGIA DE DESENVOLVIMENTO CELEPAR 5 em determinada informação, ou seja, a classe que tem a informação necessária para satisfazer tal responsabilidade ou que sabe como obter tal informação. Problema: Qual é o princípio básico de atribuição de responsabilidades a objetos? Solução: Atribuir a responsabilidade ao objeto que tem a informação necessária para satisfazêla. Este padrão é um princípio básico, usado continuamente no projeto orientado a objetos na atribuição de responsabilidades. Ele expressa a “intuição” comum de que os objetos fazem coisas relacionadas com a informação que têm. Exemplo: Em um sistema de vendas, onde existem as classes Venda e ItemVenda, a classe responsável por manter o total de uma venda seria a classe Venda, pois Venda é que detém o conhecimento sobre todos os seus itens de venda. A classe ItemVenda não deve ter a responsabilidade de guardar o total de uma venda porque só conhece o valor do seu item. Benefícios: ● O encapsulamento de informações é mantido, uma vez que os objetos usam sua própria informação para executar tarefas, favorecendo o acoplamento fraco, que conduz a sistemas mais robustos e fáceis de manter. ● O comportamento está distribuído entre as classes que têm as informações necessárias; assim são estimuladas definições de classes “leves”, de maior coesão, METODOLOGIA DE DESENVOLVIMENTO CELEPAR Figura 1: Exemplo do uso do padrão Especialista 6 mais fáceis de compreender e manter. Contraindicação: Existem situações em que uma solução sugerida pelo padrão Especialista é indesejável, devido ao problema de acoplamento e coesão. Um exemplo disso é tratar a persistência dos dados na classe do próprio domínio, analisando somente o padrão Especialista essa seria uma solução correta, mas analisando o fator coesão verificase que a classe de domínio não estará mais focada na parte pura da aplicação, ela terá que tratar os serviços técnicos ligados a banco de dados o que diminuiria sua coesão. Além disso, deve se levar em consideraçãoo princípio básico de arquitetura: projetar para obter uma separação dos principais interesses do sistemas, como por exemplo, manter a lógica da aplicação em um lugar (objetos de software de domínio) e a lógica relacionada com banco de dados em outro lugar ( como um subsistema separado para serviços de persistência). 2.1.2 Criador (Creator) A criação de objetos é uma das atividades mais comuns em um sistema orientado a objetos. Desta forma, é útil ter um princípio geral para a atribuição de responsabilidades de criação. Com essas responsabilidades bem atribuídas, o projeto apresentará acoplamento fraco, mais clareza, encapsulamento e reutilização. Este padrão define qual classe deve ser responsável por criar instâncias de outras classes. A classe criadora deve ser aquela que possui a outra como parte dela ou que esteja fortemente associada a ela. Problema: Quem deve ser responsável pela criação de uma nova instância de uma classe? Solução: Atribua à classe B a responsabilidade de criar uma instância da classe A se uma das seguintes condições for verdadeira: ● B agrega objetos de A; METODOLOGIA DE DESENVOLVIMENTO CELEPAR 7 ● B contém objetos de A; ● B registra instâncias de objetos de A; ● B usa, de maneira muito próxima, objetos de A; ● B tem os dados de iniciação que serão passados para A quando ele for criado (portanto, B é uma Classe Especialista com respeito à criação de A); ● B é um criador de objetos de A. Se mais de uma opção for aplicável, prefira uma classe B que agrega ou comtém a classe A. Contraindicação: Muitas vezes, a criação é uma tarefa complexa, que exige o uso de instâncias recicladas por motivos de desempenho, eventualmente criando uma instância de uma família de classes similares com base no valor de alguma propriedade externa, e assim por diante. Nesses casos, é aconselhável delegar a criação para uma classe auxiliar chamada Fábrica (do padrão de projeto GOF [GoF Factory]) ao invés do sugerido pelo padrão Criador. Benefícios: Favorece o acoplamento fraco, implicando em menor dependência para a manutenção e maiores oportunidades de reutilização. O acoplamento não é aumentado pois a classe criada provavelmente já é visível para a classe criadora, por causa das associações existentes que motivaram sua escolha como criador. 2.1.3 Acoplamento Fraco (Baixo Acoplamento – Low Coupling) Acoplamento é a medida de quão fortemente um elemento está conectado a, tem conhecimento de ou depende de outros elementos. METODOLOGIA DE DESENVOLVIMENTO CELEPAR 8 Uma classe com acoplamento fraco significa que ela não depende de muitas outras. Já uma classe com o acoplamento alto (ou forte) é mais difícil de reutilizar, pois seu uso depende da reutilização de outras classes da qual ela depende e também é mais sensível a mudanças nas classes associadas a ela. Problema: Como favorecer a dependência baixa, o pequeno impacto à mudança e aumentar a reutilização? Solução: Atribuir uma responsabilidade de maneira que o acoplamento permaneça fraco. O Acoplamento Fraco favorece o projeto de classes que são mais independentes, o que reduz o impacto de mudanças. Ele não pode ser considerado isoladamente de outros padrões, como o Especialista e o Coesão Alta, mas, em vez disso, precisa ser incluído como um entre vários princípios de projetos que influenciam uma escolha na atribuição de uma responsabilidade. Não há medida absoluta que determine quando o acoplamento é muito forte. O desenvolvedor deve avaliar o grau atual de acoplamento e julgar se o seu aumento trará problemas. Em geral, as classes que são genéricas por natureza, e com alta probabilidade de reutilização, deveriam ter acoplamento especialmente fraco. ContraIndicação: Não devese exagerar ao projetar visando o mais baixo acoplamento, essa prática exige bom senso. Aconselhase que o projetista avalie suas decisões de reduzir o acoplamento e a encapsular coisas concentrandose nos pontos passíveis de evolução e alta instabilidade. Benefícios: Atribuir uma responsabilidade de maneira que o acoplamento permaneça fraco traz como benefício: ● O elemento não será afetado por mudanças em outros; METODOLOGIA DE DESENVOLVIMENTO CELEPAR 9 ● É simples de entender isoladamente; ● É conveniente para reutilização. 2.1.4 Coesão Alta Coesão é a medida de quão fortemente relacionadas e focalizadas são as responsabilidades de uma classe. Uma classe com baixa coesão acaba se responsabilizando por mais coisas do que ela realmente deveria ser responsável. Classes assim acabam oferecendo dificuldade para o seu entendimento e manutenção, sendo assim, mais difíceis de reutilizar por não terem o foco definido. Problema: Como manter a complexidade sob controle? Solução: Atribuir uma responsabilidade de forma que a coesão permaneça alta. Como regra prática, uma classe com coesão alta tem um número relativamente pequeno de métodos, com funcionalidades altamente relacionadas, e não executa muito trabalho. Se a tarefa for grande, ela irá colaborar com outros objetos para dividir o esforço. O nível de coesão não pode ser considerado isoladamente de outras responsabilidades e de outros princípios, como o Especialista e o Acoplamento Fraco. Má coesão geralmente traz mau acoplamento, e viceversa. São interdependentes. ContraIndicação: Existem alguns poucos casos nos quais se justifica uma coesão mais baixa. Um deles é o agrupamento de responsabilidades ou de código em uma classe ou componente para simplificar a manutenção por uma pessoa, claro que, tal agrupamento também pode piorar a manutenção. Outro caso é quando existem objetos servidores distribuídos. Por causa de sobrecarga e das implicações de desempenho associadas com objetos e comunicações remotos, algumas vezes, é melhor criar uma quantidade menor de objetos servidores maiores, menos coesos, que forneçam uma interface para muitas operações. Benefícios: Atribuir uma responsabilidade de maneira que a coesão permaneça alta traz como benefício: METODOLOGIA DE DESENVOLVIMENTO CELEPAR 10 ● Mais clareza e facilidade de compreensão no projeto; ● Simplificação da manutenção e do acréscimo de melhorias; ● Favorecimento do acoplamento fraco. 2.1.5 Controlador (Controler) Padrão que define a classe responsável por tratar um acontecimento externo ao sistema e que desencadeia alguma ação do mesmo. É o padrão responsável por tratar eventos do sistema. Problema: Quem deve ser responsável por tratar um evento de sistema? Um evento de entrada de um sistema é um evento gerado por um ator externo. Ele está associado com operações do sistema. Um Controlador é um objeto da interface (mas não da interface com o usuário), responsável por receber ou tratar um evento do sistema. Um Controlador define o método para a operação do sistema. Solução: Atribuir a responsabilidade de receber ou tratar uma mensagem de um evento do sistema a uma classe que represente uma das seguintes escolhas: ● Represente todo o sistema, o dispositivo ou subsistemas (controlador fachada); ● Represente um cenário de um caso de uso dentro do qual ocorra o evento do sistema. Devese usar, normalmente, uma classe controladora para todos os eventos do sistema no mesmo cenário de caso de uso (poderia ser para o mesmo caso de uso) Benefícios: ● Aumento das possibilidades de reutilização e de interfaces plugáveis: Delegar a responsabilidade de uma operação de sistemaa um controlador apóia a reutilização da lógica em aplicações futuras e, uma vez que a lógica não está presa à camada de interface, esta pode ser substituída por uma METODOLOGIA DE DESENVOLVIMENTO CELEPAR 11 interface diferente. ● Conhecer o estado do caso de uso: Identificar o estado da atividade e das operações dentro do caso de uso em processamento, caso se queira garantir que as operações do sistema ocorram em uma seqüência válida. 2.2 Arquitetura de software Para a atribuição de responsabilidades e o estabelecimento de interações entre objetos, habilidade central para o desenvolvimento orientado a objetos, além dos padrões GRASP, citados anteriormente, devemos nos preocupar com a interface com o usuário ou ao acesso aos recursos, como um banco de dados, aspectos importantes mapeados na arquitetura adotada. Os sistemas são tipicamente compostos de muitos pacotes lógicos, como pacote de interface com o usuário, pacote de acesso a banco de dados, etc. Cada pacote agrupa um conjunto de responsabilidades coesas guiados pela arquitetura lógica definida. “Uma arquitetura é o conjunto de decisões significativas sobre a organização de um sistema de software, a seleção dos elementos estruturais e as interfaces das quais o sistema é composto, junto com seu comportamento especificado nas colaborações entre estes elementos, a composição desses elementos estruturais e comportamentais em subsistemas progressivamente maiores e o estilo arquitetural que guia sua organização – esses elementos e suas interfaces, suas colaborações e sua composição.” (The Unified Modeling Language User Guide – Booch, Rumbaugh e Jacobson ). Resumidamente a arquitetura lógica, descreve o sistema em termos de sua organização conceitual em camadas, pacotes, principais frameworks, classes, interfaces e subsistemas. Há várias melhores práticas para o projeto de arquitetura lógica, entre eles podemos destacar o padrão MVC e o padrão Fachada. 2.2.1 Padrão MVC É um padrão de arquitetura que consiste em dividir a aplicação em três partes: a lógica de negócios (Model), a interface do usuário (View) e o fluxo da aplicação (Control). METODOLOGIA DE DESENVOLVIMENTO CELEPAR 12 ● Modelo (Model): Representa a camada que contém os processos de negócio da aplicação, encapsulando dados e comportamento independente da apresentação (camada de visualização). ● Visualização (View): É a camada de apresentação ao usuário. Esta camada não deve ter responsabilidades sobre qualquer lógica ligada ao domínio, devendo ser responsável somente por tarefas relacionadas com a interface do usuário como entrada de dados e apresentação de resultados. ● Controle (Controller): Representa a camada responsável pela forma como a aplicação reage aos estímulos do usuário, determina o fluxo de apresentação servindo de camada intermediária entre as camadas de visualização e modelo. 2.2.2 Padrão Fachada Padrão cujo objetivo é fornecer uma interface unificada para um conjunto de interfaces em um subsistema1. Fachada define uma interface de nível mais alto que torna o subsistema mais fácil de ser usado. Estruturar um sistema em subsistemas ajuda a reduzir a complexidade. Um objetivo comum de todos os projetos é minimizar a comunicação e as dependências entre subsistemas. Uma maneira de atingir este objetivo é introduzir um objeto fachada, o qual fornece uma interface única e simplificada para os recursos e facilidades mais gerais de um subsistema. A fachada normalmente não deve expor muitas operações de baixo nível. É desejável que a fachada exponha um pequeno número de operações de alto nível – serviços não refinados. Quando 1 Subsistema: Grupo independente de classes que colaboram para cumprir um conjunto de responsabilidades. METODOLOGIA DE DESENVOLVIMENTO CELEPAR Figura 2: Diagrama exemplificando a relação entre Model, View e Controller. 13 uma fachada expõe muitas operações de baixo nível, tende a se tornar nãocoesa. O padrão GRASP Controlador, utiliza o conceito do padrão Fachada. Escolher um objeto que represente todo o sistema ou organização para ser um controlador é um tipo de Fachada. ● Estrutura: Participantes: ● Fachada: Conhece quais as classes do subsistema responsáveis pelo atendimento de uma solicitação; Delega solicitações de clientes a objetos apropriados do subsistema. ● Classes de Subsistema: Implementam a funcionalidade do subsistema; Encarregamse do trabalho atribuído a elas pelo objeto Fachada; Não têm conhecimento da fachada; isto é, elas não mantêm referências para a mesma. Colaborações: ● Os clientes se comunicam com um subsistema através do envio de solicitações para a Fachada, a qual as repassa para os objetos apropriados do subsistema. Embora os objetos do subsistema executem o trabalho real, a fachada pode ter que efetuar trabalho próprio dela para traduzir a sua interface para as interfaces de subsistemas; ● Os clientes que usam a fachada não tem que acessar os objetos do subsistema METODOLOGIA DE DESENVOLVIMENTO CELEPAR Figura 3: Exemplo do padrão Façade 14 diretamente. 3 ARQUITETURA LÓGICA ADOTADA Esta arquitetura está baseada nos padrões MVC (Model, View, Controller) e Fachada. Seu principal objetivo fornecer subsídios para uma modelagem indepentente de plataforma(tecnologia). 3.1 Camada de Controle Representa a forma como a aplicação reage aos estímulos do usuário, determina o fluxo de apresentação servindo de camada intermediária entre as camadas de visualização e modelo. 3.1.1 Classe Controle As classes de controle são aquelas que recebem as solicitações da camada de visão e as transferem para a camada de modelo. METODOLOGIA DE DESENVOLVIMENTO CELEPAR Figura 4: Aquitetura Lógica Adotada 15 Padronização sugerida: 1. Classe Controle: Geralmente é associada a cada caso de uso, contendo os métodos de controle necessários ao funcionamento do mesmo. Atribuir a esta o estereótipo<< Controle>> do perfil(RUPAnalysis) 2. Métodos: ■ É aconselhável que cada classe controle possua um método de carregamento(Carregar<nome da tela>) ex:CarregarPlanejamento. Este método tem por objetivo o carregamento da tela inicial do respectivo cenário2 de caso de uso; ■ Métodos da classe controle devem disparar a chamada de métodos da classe serviço da camada modelo; ■ Os métodos serão identificados durante a elaboração do diagrama de seqüência desta fase. ■ Propriedade Documentação: Se necessário, utilizar esta propriedade para informar maiores detalhes do método, como por exemplo, os campos (informações) de tela que serão populados por este método – conforme figura 6 Observação: Evitar a citação de nomes de outros métodos na propriedade documentação, a chamada de métodos deve estar sempre explícita no diagrama de seqüência. Desta forma, alterações na sua assinatura são efetivadas automaticamente em todos os diagramas do projeto. 3. Exemplo: 2Um cenário, ou instância de um caso de uso, é a descrição de uma das maneiras pelas quais um caso de uso um pode ser realizado. Normalmente há diversos cenários para um mesmo caso de uso METODOLOGIA DE DESENVOLVIMENTO CELEPAR 16 3.2 Camada de Visualização Representa basicamente a interface com o usuário. É utilizada parareceber a entrada dos dados e apresentar o resultado. 3.2.1 Classes Tela As classes de tela são aquelas que recebem o evento do ator externo e repassam para a camada de controle. Padronização Sugerida: Presente no documento Guia para Modelagem de Interações. METODOLOGIA DE DESENVOLVIMENTO CELEPAR Figura 6: Propriedade Documentação do método da classe Controle Figura 5: Classe de Controle 17 Exemplo: 3.3 Camada de Modelo Representa a camada que contém os processos de negócio da aplicação, encapsulando dados e comportamento independente da apresentação (camada de visualização). Esta camada conterá classes de serviço, classes de domínio, classes de persistência e classes DTO. 3.3.1 Classe Serviço Classe cujo objetivo é fornecer uma interface para os recursos e facilidades mais gerais de um subsistema. Classe Serviço X Classes de Domínio: A classe serviço, como ponto único de acesso para METODOLOGIA DE DESENVOLVIMENTO CELEPAR Figura 7: Classes de Tela 18 um subsistema3, deve redirecionar a requisição de um serviço para a(s) classe(s) de domínio(s) o que o implementa. Dessa forma, as classes que usam os serviços (como a classe de controle ou outras aplicações) não precisam se preocupar em conhecer as demais classes da camada de modelo que compõem a aplicação. Este tipo de classe normalmente não deve expor muitas operações de baixo nível. É desejável que a exponha um pequeno número de operações de alto nível. Classe Serviço X Classe de Persistência: A classe de Serviço deve se preocupar também com o ciclo de vida do objeto (carregar, manipular) disparando as chamadas aos serviços técnicos de persistência. Padronização Sugerida: 1. Criação da classe: Criar uma classe de serviço para cada subsistema e adicionar o estereótipo <<Servico>>. ● Padrão de Nomenclatura: XxxxFacade onde: Xxxx – é o nome da classe de fachada. Facade – palavra fixa para indicar a utilização do padrão Fachada. 2. Métodos (Capacidades): ■ Os métodos serão identificados durante a elaboração do diagrama de seqüência desta fase; ■ Métodos da classe serviço devem disparar a chamada de métodos das classes de domínio e persistência; ■ Propriedade Documentação: Se necessário, utilizar esta propriedade para informar maiores detalhes do método. ○ Mensagens: Mensagens lançadas por estes métodos devem estar descritas na referida propriedade Documentação. Observação: Evitar a citação de nomes de outros métodos na propriedade 3 Subsistema: Grupo independente de classes que colaboram para cumprir um conjunto de responsabilidades. METODOLOGIA DE DESENVOLVIMENTO CELEPAR 19 documentação, a chamada de métodos deve estar sempre explícita no diagrama de seqüência. Desta forma, alterações na sua assinatura são refletidas automaticamente em todos os diagramas do projeto. 3. Vínculo com classes de domínio <<Entidade>>: Crie, se necessário, um relacionamento de dependência entre a classe <<Servico>> e as classes de domínio aos quais esta classe representa. 4. Vínculo com classes de persistência <<Persistência>>: Crie, se necessário, um relacionamento de dependência entre a classe <<Servico>> e as classes de persistências os quais esta classe se comunica. 5. Vínculo com classes de controle <<Controle>>: Crie, se necessário, um relacionamento de dependência entre a classe controle e as classes de serviços acessadas por ela. Exemplo: METODOLOGIA DE DESENVOLVIMENTO CELEPAR Figura 8: Exemplo de Diagrama de Classes de Serviço e seus relacionamentos 20 3.3.2 Classe Domínio O modelo de Domínio, na fase de análise, identificou os conceitos relacionados aos requisitos do sistema e analisou o problema sob a perspectiva conceitual. Agora na fase de projeto o modelo de domínio deve representar as classes de projeto preocupandose com o domínio da solução, desta forma, as classes de domínio devem ser complementadas com as operações necessárias à execução do sistema em questão. Padronização Sugerida: 1. Devese atribuir a cada classe de domínio o estereótipo<<Entidade>> do perfil(RUPAnalysis) 2. Métodos: ■ Os métodos serão identificados durante a elaboração do diagrama de seqüência desta fase; ■ Métodos desta classe tratam as regras de negócio do domínio, ou seja, não devem representar regras de negócio da aplicação, como controlar o ciclo de vida de objetos (carregar, manipular – camada de persistência). Para criação destes métodos observe os conceitos dos padrões GRASP; ■ Propriedade Documentação: Utilizar esta propriedade para informar maiores detalhes do método. ○ Mensagens: Mensagens lançadas por estes métodos devem estar descritas na referida propriedade Documentação. Observação: Evitar a citação de nomes de outros métodos na propriedade documentação, a chamada de métodos deve estar sempre explícita no diagrama de seqüência. Desta forma, alterações na sua assinatura são efetivadas automaticamente em todos os diagramas do projeto. METODOLOGIA DE DESENVOLVIMENTO CELEPAR 21 3. Exemplo: 3.3.3 Classe de Persistência Classe cujo objetivo é tratar os serviços técnicos de persistência de dados. Estas classes estão amparadas pelo padrão de projeto DAO (Data Access Object). DAO (Data Access Object) é um padrão para persistência de dados que permite separar regras de de acesso das regras de negócio. Numa aplicação que utilize a arquitetura MVC, todas as funcionalidades de bancos de dados, tais como obter as conexões, mapear objetos para tipos de dados SQL ou executar comandos SQL, devem ser feitas por classes de DAO. Padronização Sugerida: 1. Criação da classe: Criar uma classe de persistência para cada classe de domínio que seja persistente e adicionar o estereótipo <<Persistência>>. ● Padrão de Nomenclatura: XxxxDAO onde: Xxxx – é o nome da classe de persistência. DAO – palavra fixa para indicar a utilização do padrão DAO para persistência 2. Métodos: ■ Os métodos serão identificados durante a elaboração do diagrama de seqüência desta fase. ■ Propriedade Documentação: Utilizar esta propriedade para especificar o método. METODOLOGIA DE DESENVOLVIMENTO CELEPAR Figura 9: Exemplo de Classes de Dominio na fase de Projeto 22 ○ Mensagens: Mensagens lançadas por estes métodos devem estar descritas na referida propriedade Documentação. ○ Paginação: Para os métodos que realizem pesquisas, informar se as mesmas devem ser paginadas. Observação: Métodos padrões como salvar, alterar, excluir, listar, obter e verificarExistencia não precisam ser especificados na propriedae documentação. 3. Vínculo com classes de domínio: Crie um relacionamento de dependência entre a classe <<Persistência>> e as classes de domínio aos quais esta classe representa. 4. Palavras Reservadas: Visto que alguns métodos tem funcionalidades semelhantes, a nomenclatura destes foi padronizada para evitar sobreposições de definições de métodos e para agilizar a fase de projeto. Os seguintes métodos serão considerados métodos do tipo padrão e não será necessário especificálos, na fase de projeto, bastando apenas referenciálos: • salvar, alterar, excluir, listar, obter e verificarExistencia Por conseqüência os nomes destes métodos deverão ser considerados como PALAVRASRESERVADAS e não poderão ser utilizados para identificar métodos com características especificas de uma determinada aplicação. Também como complemento a este padrão quaisquer métodos que não estejam enquadrados no mesmo serão considerados como particulares da aplicação, deverão ser especificados e descritos da mesma forma que os demais. PALAVRA Função METODOLOGIA DE DESENVOLVIMENTO CELEPAR 23 salvar salvar ( objeto ) = inclui o objeto como registro. alterar alterar ( objeto ) = altera registro de acordo com o objeto excluir excluir ( objeto ) = exclui o registro correspondente ao objeto. listar listar ( ) = retorna todos os registros. listar(objeto) = retorna todos os registros conforme o(s) filtro(s) informados no objeto. Listar (qtdPag, numPag) = retorna uma lista de registros paginados conforme os parâmetros. listar(objeto, numPag, qdtPag) = retorna uma lista de registros conforme o(s) filtro(s) informados no objeto e paginados conforme os parâmetros numPag/qtdPag. listar(String[]) = retorna todos os registros ordernados de acordo com o parâmetro. listar(objeto, String[])= retorna uma lista de registros conforme o(s) filtro(s) informados no objeto e ordernados de acordo com o parâmetro. listar(objeto, String[], numPag, qdtPag) = retorna uma lista de registros conforme o(s) filtro(s) informados no objeto, ordernados e paginados de acordo com os demais parâmetros. observação: o parâmetro String[] referese a um Array de pares de string contendo os campos para ordenacao. Ex: [“nome”, “asc”, “idade”, “desc”] verificarExistencia verificarExistencia(objeto) : boolean = retorna verdadeiro/falso conforme o(s) filtro(s) informados no objeto. obter obter ( id ) = obtém / retorna um objeto conforme o id do registro. METODOLOGIA DE DESENVOLVIMENTO CELEPAR 24 5. Exemplo: Figura 10: Exemplo de classe de persitência 3.3.4 Classe DTO (Data Transfer Objects) Classe caracterizada por armazenar informações que são transferidas entre as camadas. Classes deste tipo são estruturas do armazenamento de dados contendo informações em formato específico que geralmente são utilizadas para generalizar a busca e o retorno de dados. Padronização Sugerida: 1. Padrão de Nomenclatura: XxxxDTO onde: Xxxx – é o nome da classe. DTO – palavra fixa para indicar a utilização do padrão DTO. Observação: Essas classes são utilizadas apenas em situações muito específicas onde, por exemplo, seja necessário mesclar informações de várias entidades para a emissão de um relatório. Use o bom senso. METODOLOGIA DE DESENVOLVIMENTO CELEPAR 25 4 TRATAMENTO DE DOMÍNIOS Domínio é uma abstração para possibilidades discretas com significado para o usuário. Por exemplo, um atributo indicador cujos valores possíveis sejam ATIVO ou INATIVO, um atributo sexo cujos valores possíveis sejam MASCULINO ou FEMININO, caracterizamse como domínios pois possuem um número fixo de possibilidades para preenchimento. Na fase de projeto, devese decidir, se os domínios a serem utilizados serão tabelados ou não. Se existe a possibilidade de um valor de domínio ser utilizado muitas vezes em consultas e relatórios, ou que estes valores possam crescer durante a vida do sistema, talvez seja útil que este domínio seja tabelado, pois o mesmo poderá ser utilizado diretamente em queries SQL. Sendo tabelado deverá ser representado no diagrama de classes de projeto como uma classe de domínio <<Entidade> . Para os domínios não tabelados, domínios constantes, sua utilização darseá diretamente na codificação, sendo assim, sugerese que todas as constantes devem ser modeladas como enumerações. Enumeração: é uma classe com uma lista de constantes (literais de enumeração), por exemplo: public enum TipoVeiculo { CARRO, MOTO, CAMINHAO, ONIBUS, CARRETA, BICICLETA } Normalmente, os códigos de uma enumeração começam em zero, conforme a linguagem de programação utilizadas, e são incrementados a cada nova constante adicionada. Se isso não for o desejado, é possível informar os códigos específicos para cada constante. Os nomes das constantes também são “imprimíveis” e podem ser utilizados para montar caixas de seleção (combobox), METODOLOGIA DE DESENVOLVIMENTO CELEPAR 26 etiquetas (labels) e relatórios. A representação no diagrama de classe darseá por uma classe com o esteriótipo enumeração previsto pela UML2. O fato de se modelar uma classe de enumeração, favorece no sentido de que esta pode ser compartilhada por mais de uma classe. Exemplo 1: Neste exemplo a classe Veiculo tem um atributo do tipoVeiculo da classe enumeração TipoVeiculo. A enumeração neste caso está considerando que as literais começam em 0 e são incrementadas a cada literal. Exemplo 2: Neste exemplo foram definidos valores específicos para cada constante, e neste caso, devese declarar um atributo referente ao valor da instância representada pela constante e declarar seu valor entre parênteses ao lado de cada constante. METODOLOGIA DE DESENVOLVIMENTO CELEPAR Figura 11: Exemplo de Classe de Enumeração Figura 12: Exemplo de Classe Enumeração 27 5 TIPOS DE DADOS RECOMENDADOS: Para fins de padronização e independência de plataforma tecnológica sugerese os seguintes tipos de dados utilizados na modelagem: ● Character; ● Boolean; ● Date; ● DateTime; ● Decimal; ● File; ● Image; ● Integer; ● Money; ● String; ● Void. Estes tipos de dados poderão ser utilizados tanto na declaração de atributos quanto nos parâmetros de métodos. Observação: 1 Para representação de coleção de objetos como atributos utilize a multiplicidade presente no relacionamento entre as classes. METODOLOGIA DE DESENVOLVIMENTO CELEPAR Figura 13: Exemplo de multiplicidade no relacionamento 28 2 - Para representação de listas em assinatura de método utilize a multiplicidade do parâmetro ou do retorno. 6 CHECKLIST DE ELABORAÇÃO CHECKLIST O nome da cada classe deve iniciar com a primeira letra maiúscula. Os nomes de objetos utilizados nas operações, devem iniciar com letra minúscula. Exemplo: cliente, listaFornecedo. METODOLOGIA DE DESENVOLVIMENTO CELEPAR Figura 15: Exemplo de representação de listas em assinatura de método Figura 14: Exemplo de multiplicidade no relacionamento – visão do relacionamento como atributo 29 CHECKLIST Utilizar o tipo void para as operações que não possuírem retorno. Cada classe representa um pequeno, consistente e exclusivo conjunto de responsabilidades. Verificar se existem classes que atendem aos requisitos comportamentais estabelecidos pelas realizações de casos de uso. Verificar se não existem duas classes com a mesma finalidade. O nome de cada operação ou atributo é descritivo e compreensível e deve ser um verbo no infinitivo. Os parâmetros de cada operação devem estar corretos em termos de número, nome e tipo. Cada operação deve ser usada pelo menos por uma realização de caso de uso? Verificar as multiplicidades dos relacionamentos. METODOLOGIA DE DESENVOLVIMENTO CELEPAR 1 Introdução 2 Principais Conceitos 2.1 GRASP: Padrões de Princípios Gerais para a Atribuição de Responsabilidades 2.1.1 Especialista na Informação (Information Expert) 2.1.2 Criador (Creator) 2.1.3 Acoplamento Fraco (Baixo Acoplamento – Low Coupling) 2.1.4 Coesão Alta 2.1.5 Controlador (Controler)2.2 Arquitetura de software 2.2.1 Padrão MVC 2.2.2 Padrão Fachada 3 Arquitetura lógica Adotada 3.1 Camada de Controle 3.1.1 Classe Controle 3.2 Camada de Visualização 3.2.1 Classes Tela 3.3 Camada de Modelo 3.3.1 Classe Serviço 3.3.2 Classe Domínio 3.3.3 Classe de Persistência 3.3.4 Classe DTO (Data Transfer Objects) 4 Tratamento de Domínios 5 Tipos de dados Recomendados: 6 Checklist de elaboração
Compartilhar