Figura 5 - Workflow para a Fase de Projeto

Transcrição

1 5. Fase de Projeto A Fase de Projeto caracteriza-se por transformar as informações modeladas durante a Fase de Análise em estruturas arquiteturais de projeto com o objetivo de viabilizar a implementação do sistema. As informações da Fase de Projeto caracterizam a modelagem dinâmica do sistema, principalmente em termos dos objetos necessários às operações através da troca de mensagens entre os mesmos. Busca-se, ainda, ter uma estrutura hierárquica de classes otimizada a partir do refinamento do Diagrama de Classes do Sistema da Fase de Análise, o que irá caracterizar os requisitos essenciais à passagem para as atividades de implementação e testes. Os objetivos da Fase de Projeto serão alcançados começando-se a modelagem dinâmica do software a partir da construção de Grafos de Interação de Objetos, em que são modeladas as operações do sistema através da troca de mensagens entre os objetos. Posteriormente, o Diagrama de Classes Conceitual do Sistema poderá ser refinado em termos de agregações, composições e estruturas de herança, viabilizando uma hierarquia de classes. A figura abaixo oferece uma visualização, através de um workflow, das atividades a serem desempenhadas durante a Fase de Projeto. Pode-se notar que as próximas três atividades da fase estarão voltadas à arquitetura do software que será implementado. Assim, abre-se espaço para retomar o projeto arquitetural das camadas do software, sendo previstas atividades de mapeamento da camada de classes para as camadas de apresentação e de persistência de dados. Por fim, são sugeridos alguns procedimentos para revisão da Fase de Projeto e preparação para iniciar as atividades de implementação e testes, o que apesar de não ser o escopo deste trabalho, merece considerações de sentido de facilitar a geração de código e sua associação às demais camadas de apresentação e armazenamento de dados.

2

3 Figura 5 - Workflow para a Fase de Projeto 75

4 5.1. Condução da Fase de Projeto A Fase de Projeto deve ser conduzida buscando-se transformar as informações da Fase de Análise em estruturas arquiteturais de projeto com o objetivo de viabilizar a implementação do sistema. Tudo o que foi analisado deve ser observado para se iniciar a Fase de Projeto, em que se deve construir as estruturas dinâmicas de trocas de mensagens entre os objetos necessárias para satisfazer os Esquemas de Operações da Fase de Análise. Assim, para a modelagem dos Grafos de Interação de Objetos deverão ser observados, principalmente, os Diagramas de Classes de Sistema e os Esquemas de Operações. Assim sendo, nos Esquemas de Operações foram investigadas e descritas as operações do sistema e, a partir de agora, deve-se transformá-las de maneira a modelar os objetos envolvidos e cada operação e como que eles se comunicam através de mensagens, as quais se transformarão em métodos dos objetos que as recebem. Os diagramas de classes passarão, então, por uma "última" revisão a fim de otimizá-los e terem acrescentados objetos de projeto quando necessário. O próximo passo será conduzir a melhoria da arquitetura do projeto e mapear as demais camadas previstas para o software 5.2. Modelagem Dinâmica A abordagem dos Grafos de Interação de Objetos (GIO) visa representar a troca de mensagens entre os objetos para satisfazer as operações modeladas na Fase de Análise. Deve ser desenvolvido pelo menos um Grafo de Interação de Objetos para cada operação prevista para o sistema. Como visto, a modelagem das trocas de mensagens entre os objetos depende diretamente da observação dos Esquemas de Operações e dos Diagramas de Classes do Sistema. A principal colaboração dos GIO será os métodos que as classes passarão a dispor após sua modelagem. Trabalhadores Envolvidos: Engenheiro de Software como Projetista de Software. Artefatos de Entrada: Esquemas de Operações. Diagramas de Classes do Sistema. Artefatos de Saída: Grafos de Interação de Objetos. Estratégias e Notações para Modelagem O primeiro passo para modelar as interações entre os objetos é partir dos Esquemas de 76

5 Operações, geralmente com as operações tendo os mesmos nomes dos eventos de entrada dos Diagramas de Seqüência. A partir daí, deve ser gerado um GIO para cada Esquema de Operação, sendo que a primeira mensagem do GIO terá sua assinatura retirada do nome da operação. Cada cláusula do Esquema de Operações deverá ser observada buscando as informações necessárias para a modelagem dos GIO, conforme descrito abaixo. Das cláusulas "Nome" e "Responsabilidades" o projetista poderá derivar a assinatura do primeiro método do GIO e as tarefas que devem ser cumpridas no GIO para que se alcance os resultados esperados pela operação; Nas "Referências Reads" e "Referências Changes" o projetista tem a relação dos objetos que poderão ser manipulados para se alcançar os resultados desejados, sabendo também quais são as permissões de acessos a estes objetos, além de também poder identificar quais são os atributos que devem ser fornecidos ao método inicial; As cláusulas "Pré-condições" e "Pós-condições" permite ao projetista criar as trocas de mensagens necessárias para fazer os testes de entrada e de saída da operação; A cláusula "Saída" viabiliza que sejam verificadas as situações finais, juntamente com a "Pós-condição", para o sistema e eventos de saída, se houver. NOTA 1: nesta fase podem ser criados objetos de projeto, que não deveriam ter sido previstos na Fase de Análise em função do foco ser voltado ao negócio. Portanto, neste momento deve-se acrescentar todos e quaisquer objetos necessários ao funcionamento da operação. Classes que implementam algoritmos ou estruturas de organização de dados são alguns destes exemplos. NOTA 2: dependendo também da arquitetura do projeto pode-se criar objetos intermediários e de comunicação entre as camadas quando necessário, o que provavelmente necessitaria de complementação destes GIO após as atividades seguintes. Assim sendo, sugere-se criar uma classe abstrata, como um repositório ou classe de acesso a dados, de forma a tornar mais independente a elaboração dos GIO. NOTA 3: vale observar, ainda, que operações pouco complexas geram GIO muito simples e com poucas trocas de mensagens. Isto ocorre, principalmente, em cadastros ou consultas simples. Em casos como estes o projetista deve ficar a vontade para decidir sobre a modelagem ou não dos GIO no sentido de simplificar o processo e evitar tarefas desnecessárias. Contudo, deve-se lembrar de gerar os métodos manualmente dentros das classes de objetos, o que deve ser feito diretamente nos diagramas de classes. Abaixo segue um modelo esquemático representando as possibilidades notacionais da UML para a construção de Diagramas de Colaboração, sendo esta a notação adotada pelo 77

6 FILM para os originais GIO do método Fusion. Contudo, o projetista poderá adotar o padrão UML para Diagramas de Seqüência neste momento de modelar as trocas de mensagens entre os objetos. Figura Esquema Notacional para Grafos de Interação de Objetos com notações UML de Diagrama de Colaboração Estudo de Caso 78

7 79

8 Figura Caso MiniBib: Grafos de Interação de Objetos Referentes as Operações dos Requisitos e Refinar Diagrama Conceitual de Classes do Sistema O Diagrama Conceitual de Classes do Sistema, inicialmente construído na Fase de Análise e delimitado ao domínio do sistema, deve agora ser refinado de forma a otimizar sua implementação com recursos da orientação a objetos. Usaremos de dois mecanismos para melhorar nossos modelos, sendo as associações de Agregação e de Herança, conforme a seguir. 80

9 Modelar Agregações A Agregação é um mecanismo que permite construir uma classe agregada a partir de outras classes componentes e de relacionamentos de classes. Uma classe agregada pode ser tratada como qualquer outra classe, podendo possuir atributos e participar de relacionamentos. A identificação das agregações depende diretamente dos Modelos de Objetos do Sistema já construídos até então, podendo também ser necessário consultar documentos de requisitos para reconhecer características de agregação. Trabalhadores Envolvidos: Engenheiro de Software. Artefatos de Entrada: Diagrama de Classes de Sistema. Artefatos de Saída: Diagrama de Classes de Sistema Refinado. Estratégias e Notações para Modelagem Uma orientação bastante útil para se identificar agregações diz respeito à análise da expressão (geralmente contendo um verbo) existente no relacionamento entre classes que estão prestes a se agregarem. Em geral a agregação modela relacionamentos "parte de" ou "contém um". Portanto, uma classe que está associada a outra através de um relacionamento do tipo "has a" é forte candidata à agregação. Assim sendo, uma forma de se identificar este tipo de associação é, além dos requisitos de objetos, identificar nos relacionamentos verbos ou expressões verbais como: "tem um", "contém um", "está em", "é parte de",... A modelagem das Agregações utiliza de uma notação gráfica específica da UML. Elimina-se o nome do verbo/expressão verbal relativa à associação e substitui-se pela equivalente gráfica. 81

10 Figura Notação para Agregação na UML Modelar Estruturas de Herança - Hierarquia de Classes A Herança é um tipo de relacionamento onde a classe que herda (subclasse/subtipo) possui todas as propriedades da classe herdada (superclasse/supertipo), podendo também possuir outras mais, o que nos levará a construir uma Estrutura Hierárquica de Classes, objetivando-se assim a reutilização de classes em outros projetos. A identificação das Estruturas de Herança também depende diretamente dos Diagramas de Classes do Sistema já construídos até então, sendo necessário consultar as mesmas estruturas já construídas e documentos de requisitos para reconhecer características de herança, às vezes também citadas como generalizações/especializações. Estratégias e Notações para Modelagem A orientação para se identificar generalizações/especializações (herança) é semalhante à usada para identificar agregações e diz respeito à análise da expressão (geralmente contendo um verbo) existente no relacionamento entre classes envolvidas. A generalização modela relacionamentos "tipo de" ou "é um". Portanto, uma classe que está associada a outra através de um relacionamento do tipo "kind of" ou "is a" é forte cadidata a se tornar subclasse de outra (superclasse). A modelagem de Herança utiliza de uma notação gráfica específica, também eliminandose o nome do verbo/expressão verbal relativa à associação que está sendo substituída. 82

11 Figura Notação para Herança (Especialização/Generalização) na UML Estudo de Caso (referente à seção 5.3) Neste ponto o Diagrama de Classes de Sistema pode ser refinado, agregando novas classes, declarando as operações das classes, revendo as cardinalidades e, caso houver necessidade, considerar agregações e heranças. Os métodos das classes, quando se utiliza uma ferramenta de apoio, são gerados a partir dos Grafos de Interação de Objetos de forma automática, conforme podemos ver no exemplo a seguir, apesar de o mesmo tratar aspectos de agregação ou herança. 83

12 Figura Caso MiniBib: Diagrama de Classes de Sistema Refinado 5.4. Complementar Modelo Arquitetural - Arquitetura dos Componentes Muitas metodologias orientadas a objetos, e especificicamente a considerada pelo Processo FILM, sugere uma implementação em três camadas, sendo Apresentação, Classes de Negócios e Armazenamento/Persistência de Dados. A camada de Negócios foi modelada através do Diagrama de Classes do Sistema, agora refinado. As camadas de Apresentação e Armazenamento de Dados devem ser elaboradas na Fase de Projeto, mas surge a necessidade de documentar os componentes da arquitetura e sua distribuição física, o que será feito em dois passos nesta atividade. A utilização da arquitetura em três camadas é motivada pelas inúmeras vantagens que proporciona, entre elas, a reutilização de objetos por outras aplicações, facilidade de manutenção, maior independência do fornecedor de banco de dados e alta produtividade de desenvolvimento através de especialização. Esta atividade também não era contemplada no método Fusion e tampouco nas últimas versões do FILM, não tendo, portanto, estudos de caso para demonstrar. Foram adaptadas 84

13 práticas de definição de processo em empresas da região de Caxias do Sul e acredita-se que possam responder positivamente dentro do Processo FILM. Trabalhadores Envolvidos: Engenheiro de Software na posição de Arquiteto de Software. Clientes. Artefatos de Entrada: Esboço Arquitetural de Projeto. Diagramas de Classes de Sistema Refinado. Artefatos de Saída: Diagrama de Classes de Sistema Refinado. Estratégias e Notações para Modelagem Inicialmente sugere-se a criação de um Diagrama de Disposição Física (Diagrama de Deployment) que apresente os nodos necessários à operacionalização do sistema. Em cada nodo deverá estar presente seus componentes, os quais serão derivados dos pacotes internos às camadas projetadas no Esboço Arquitetural de Projeto, podendo estar numa relação um-para-um com os pacotes ou numa relação um-para-muitos. Segue abaixo um modelo esquemático e notacional para associação dos pacotes em componentes e nodos. Figura Modelo Esquemático para Diagrama de Deployment da UML 85

14 O próximo passo é montar uma Descrição de Componentes do Diagrama de Disposição Física. Cada componente presente nos nodos deverá ser descrito em termos dos pacotes que o compõem, o tipo de componente (formato, designado pelo estereótipo), as tecnologias necessárias/utilizadas para seu desenvolvimento e sua origem (próprio/interno ou de terceiros). A descrição poderá ser realizada em uma tabela esquemática, por componente, como especificado abaixo. Figura Esquema de Descrição de Componentes 5.5. Mapear Camada Intermediária de Classes do Sistema Como já visto, o foco da modelagem de classes de objetos do FILM esteve na camada de negócios, necessitando agora realizar seu mapeamento. O projeto FILM não chegou a priorizar esforços no sentido de estabelecer diretrizes para o mapeamento para a camada de apresentação, limitando-se a prever o desenvolvimento de artefatos que auxiliassem esta tarefa, como será visto a frente nesta seção. O mapeamento para a camada de persistência foi estudado no projeto e proposto como trabalho de diplomação, sendo adotado nesta seção e resumido no Apêndice B Modelar Camada de Armazenamento de Dados O rápido desenvolvimento do software orientado a objetos motivou a necessidade de construir aplicações orientadas a objetos em banco de dados relacionais. Porém, o paradigma da orientação a objetos é totalmente diferente dos bancos de dados relacionais. Enquanto o paradigma da orientação a objetos é baseado em princípios da engenharia de software, o modelo relacional é baseado em tabelas e linguagens de consulta que retornam valores desejados. Além disso, a orientação a objetos constrói aplicações baseadas na criação de objetos do mundo real, que possuem dados e comportamento, enquanto que o objeto relacional somente armazena dados. Apesar da tecnologia orientada a objetos ser a mais utilizada, atualmente, para o desenvolvimento de software, o modelo relacional ainda é a abordagem preferida para armazenamento persistente (dados persistentes normalmente consistem nos bancos de 86

15 dados compartilhados, acessados e atualizados através de transações). Portanto, é necessário integrar os dois paradigmas através do mapeamento de objetos para o modelo relacional, de forma que os objetos se tornem persistentes no banco de dados relacional (Mattiuz, 2002). Esta atividade tem como propósito modelar a estrutura de armazenamento dos dados da aplicação a partir do mapeamento do diagrama de classes de projeto para um meio persistente (claro, levando em consideração apenas as classes que requeiram persistência). Dependendo da tecnologia de armazenamento, este mapeamento poderia ocorrer de forma direta, como por exemplo utilizando-se de estruturas de dados iguais às classes de objetos, como o caso de bancos de dados orientados a objetos. Contudo, o mercado ainda é dominado por bancos de dados que utilizam o modelo relacional e, portanto, esta atividade está voltada ao mapeamento das classes para um modelo como este. Trabalhadores Envolvidos: Engenheiro de Software. Administrador ou Projetista de BD. Artefatos de Entrada: Diagramas de Classes de Sistema Refinado. Artefatos de Saída: Modelo de Armazenamento de Dados. Estratégias e Notações para Modelagem Existem abordagens detalhadas para mapeamento de um modelo orientado a objetos para um modelo relacional, o que em geral é encontrado em textos e disciplinas de bancos de dados, o que é necessário ser de domínio de uma equipe de desenvolvimento de software. Entretanto, apesar de não ser este o foco desta especificação de processo, segue um resumo dos principais aspectos a serem considerados no mapeamento de um modelo de objetos para um modelo relacional. Como parte dos resultados do FILM, disponibilizamos no Apêndice B as diretrizes mais detalhadas para este mapeamento, sendo aquele texto integrante do trabalho de Mattiuz (2002). Mapeamento de Classes para Tabelas; Gerar identificadores únicos para os objetos, isto é, criando-se as respectivas chaves primárias; Mapeamento de Atributos para Colunas, lembrando-se que atributos do tipo vetor/matriz devem ser mapeados como tabelas, em geral como entidades fracas; 87

16 Mapeamento de Associações Simples: Associações um-para-um: usa-se chaves estrangeiras, transpondo a chave de uma tabela para outra; Associações um-para-muitos: ocorre a inserção de uma chave estrangeira na classe com cardinalidade muitos; Associações muitos-para-muitos: este tipo de associação deve ser evitado ainda na diagramação de classes, podendo ser resolvido através da criação de uma nova classe correspondente a associação muitos-para-muitos, o que originaria duas novas associações um-para-muitos e, então, poderia-se proceder com o respectivo mapeamento. Contudo, se necessário esta técnica pode ser utilizada diretamente no mapeamento para o modelo relacional, fazendo-se com que ao invés de uma nova classes tenha-se uma nova tabela, na qual a chave primária será a combinação das chaves primárias das tabelas participantes da associação e, assim, caracterizando-se em uma chave primária composta. Mapeamento de Estruturas de Herança. Herança Simples: considera-se a criação de uma tabela por classe, sendo que a tabela derivada da subclasse terá uma chave primária e estrangeira da tabela derivada da superclasse; Herança Múltipla: considera-se a criação de uma tabela por classe, sendo que a tabela derivada da subclasse terá uma chave primária composta, constituída pelas chaves primárias das tabelas derivadas das superclasses e chaves estrangeiras para as mesmas; Mapeamento de Estruturas de Agregação: ocorre vários tipos de agregação que requerem técnicas específicas de mapeamento. Contudo, o mais freqüente é encontrar Agregações Todo-Parte. Neste caso, sendo a classe parte considerada uma entidade fraca, há uma transposição da chave primária da tabela que representa o todo para a tabela correspondente a classe que representa a parte, que será uma chave primária e estrangeira. Ocorrendo outros tipos de agregação ou composição, deve-se buscar as respectivas técnicas de mapeamento. 88

17 Figura Diretrizes para Mapeamento do Diagrama de Classes do Sistema Refinado para o Modelo Lógico Relacional 89

18 Estudo de Caso As tabelas abaixo foram mapeadas isoladamente, podendo contudo estarem modeladas em um único modelo lógico relacional. A tabela "Exemplar" foi mapeada com duas chaves estrangeiras, o código da bibliografia e o código do proprietário, onde foram levadas em consideração as diretrizes para mapeamento de associações. Figura Caso MiniBib: Mapeamento do Diagrama de Classes do Sistema Refinado para o Modelo Lógico Relacional Modelar Camada de Apresentação - Projeto de Interface com o Usuário Para a Camada de Apresentação sugere-se o uso de técnicas de prototipação através da construção de interfaces com a interação plena do usuário final do sistema. É extremamente interessante mostrar as telas iniciais para o usuário validar todos os modelos gerados no projeto até o momento. 90

19 Trabalhadores Envolvidos: Engenheiro de Software. Designer ou Projetista de Interfaces com o Usuário. Clientes. Artefatos de Entrada: Modelo de Visão de Objetivos; Modelo de Visão de Requisitos; Esquemas de Operações. Diagramas de Classes de Sistema Refinado. Protótipos Preliminares de Interface. Artefatos de Saída: Projeto de Interfaces com o Usuário - Modelo da Camada de Apresentação. Estratégias e Notações para Modelagem Na elaboração das interfaces devem ser apresentados o projeto das telas do sistema, dando ênfase às operações básicas e a navegação dos menus, os atributos e as funcionalidades internas às operações e telas. Apesar de parecer bastante intuitiva a execução desta atividade, em muitos casos a pessoa mais apropriada para realizá-la pode ser um profissional da área de design de interfaces. Contudo, buscando dar uma orientação básica para o profissional de software, sugere-se atentar para alguns aspectos particulares para elaboração da interface com o usuário. Estudo de Caso Analisar Modelos de Visão de Objetivos e de Visão de Requisitos; Derivar opções de operações a partir dos requisitos do sistema e dos Esquemas de Operações; Analisar Diagramas de Classes buscando atributos que participem de telas de cadastramento e consultas; Havendo Protótipos Preliminares, deve-se analisá-los confrontando com a aceitação dos clientes e usuários; Desenvolver e avaliar o projeto de interfaces juntamente com clientes e usuários. A seguir apresenta-se um exemplo do estudo de caso do sistema MiniBib. O sistema é composto por uma tela principal e um menu do tipo pull-down. As funções principais do sistema estão modularizadas em cadastros e registros. Os cadastros permitem a navegação 91

20 para proprietário e bibliografia no primeiro ciclo. Já as requisições serão apresentadas no ciclo três e são aqui apresentadas com o intuito de demonstrar que é possível prever as opções para todas as operações, deixando-se o projeto de telas específicas para o momento propício em outras iterações. 92

21 93

22 Figura Caso MiniBib: Mapeamento para a Camada de Apresentação 5.6. Inspeção dos Artefatos da Fase de Projeto Nesta seção apresenta-se orientações para a verificação dos modelos de projeto em relação à especificação da fase de análise e às funcionalidades do sistema, conforme Coleman (1996). 1. Consistência com a especificação do sistema: verificar que somente as classes representadas nos grafos de interação de objetos sejam consideradas como parte do modelo de classes para posterior implementação. 2. Verificação do efeito funcional: Verificar se o efeito funcional de cada grafo de interação de objetos satisfaz à especificação da sua operação definida no esquema de operações. Verificar se cada atributo possui o seu tipo de dados e visibilidade. Verificar se todas as classes do Diagrama de Classe possuem associações com outras classes. Verificar se todas as associações possuem cardinalidade definidas. Revisar o Modelo Relacional gerado. 3. Corretude: verificações relativas a sintaxe e semântica dos modelos gerados de acordo com os padrões estabelecidos pela UML e por este Guia. Verifique se: A notação utilizada para os Grafos de Interação de Objetos segue a notação padrão da UML para Diagramas de Colaboração. 94

23 A construção do Modelo Conceitual de Classes segue a notação padrão da UML para Diagramas de Classes. Consistência com a especificação do sistema: verificar que somente as classes representadas nos grafos de interação de objetos sejam consideradas como parte do modelo de objetos do sistema para posterior implementação. Novas classes poderão ser introduzidas durante a fase de projeto sem que sejam mostradas no modelo de objetos do sistema desenvolvido durante a análise Organizar Projeto para Transição às Atividades de Implementação e Testes 95