4.4 Teoria de Projeto axiomático para o Projeto de Software
4.4.1 Projeto Axiomático de Sistemas de Software Orientados a Objeto
A conjunção entre os métodos Orientados a Objeto e o Projeto Axiomático permitiu a geração de uma abordagem genérica para o projeto de software chamada ADo-oSS (Axiomatic Design of Object- Oriented Software Systems). Esta metodologia está estruturada sob o modelo em V (Fig. 4.4) e combina o poder do Projeto Axiomático com as populares técnicas de programação orientada a objeto, e surgiu como uma maneira de superar as deficiências das técnicas existentes para suporte ao projeto de software, como extensos ciclos de depuração e testes. Essa metodologia tem como resultado final a arquitetura do sistema,
representada pelo fluxograma.
Figura 4.4: Processo de Projeto Axiomático para Sistema de Software Orientado a Objeto (Modelo V)
O fluxograma gerado pode ser aplicado a diferentes fins, por exemplo (SUH; DO, 2000a):
a) Melhoria do projeto proposto através da identificação de projetos acoplados. b) Diagnóstico de falha iminente de um sistema complexo.
c) Redução do custo do serviço de manutenção de máquinas e sistemas. d) Ordens de mudança de engenharia.
e) Atribuição de tarefas e gerenciamento de tarefas de projeto. f) Gestão de tarefas de projeto distribuídas e colaborativas. g) Reutilização e extensionalidade do software.
Utilizando o conceito de ADo-oSS, primeiro passo é projetar o software seguindo a abordagem de cima para baixo (top-down) do projeto axiomático, construir a hierarquia do software e, em seguida, gerar a matriz de projeto completa (isto é, a matriz de projeto que mostra toda a hierarquia do projeto) para definir os módulos. O passo final é construir o modelo orientado a objetos com uma abordagem de baixo para cima, seguindo o diagrama de fluxo do AD para o sistema projetado.
Para compreender ADo-oSS, é necessário relembrar as definições dos termos usados na técnica de Ori- entação a Objeto, e conhecer suas palavras equivalentes em projeto axiomático. O elemento fundamental na orientação a objeto é o Objeto (Object), que equivale a FRs. O projeto orientado a objetos decompõe um sistema em objetos. Os objetos "encapsulam"tanto os dados (equivalente a DPs) como o métodos (equi- valente à relação entre FRi e DPi, ou seja, módulo) em uma única entidade. O objeto retém determinadas
informações sobre como realizar certas operações, usando a entrada fornecida pelos dados e métodos in- corporados no Objeto. Em projeto axiomático um Objeto pode ser representado pela formula: FRi = Aij DPj (SUH; DO, 2000a).
A Orientação a objetos possui quatro definições para descrever suas operações: identidade, classifica- ção, polimorfismo e relacionamento. Identidade significa que dados - equivalentes a DPs - são incorporados em objetos específicos. Os objetos são equivalentes a um FR - com uma relação especificada [FRi = Aij DPj] - de projeto axiomático, onde DPs são dados ou entradas, e Aij é um método ou um relacionamento. Classificação significa que os objetos com a mesma estrutura de dados (atributos) e comportamento (ope- rações ou métodos) são agrupados em uma classe. O objeto é representado como uma instância de classe específica em linguagens de programação.
Às vezes um Objeto exibe um comportamento, que é um caso especial de FR. A relação entre Objetos e Comportamentos é comparada à decomposição de FRs na hierarquia de FR do projeto axiomático. Objeto é o "FR pai"em relação ao Comportamento o qual é o "FR filho"(SUH; DO, 2000a).
Segundo Suh (SUH, 2001), a distinção entre Superclasse, Classe, Objeto e Comportamento é necessária na Orientação a Objeto para tratar de FRs em camadas sucessivas de um projeto de sistema. Uma classe, como uma abstração de objetos, está no mesmo nível que um Objeto na hierarquia de FRs. No entanto, o Objeto é um nível superior ao Comportamento na hierarquia de FRs. O uso dessas palavras-chave, embora necessário em TOO, acrescenta complexidade desnecessária quando os resultados do projeto axiomático devem ser combinados com TOO. Portanto, é modificado o uso dessas palavras-chave em TOO.
Dessa forma, os Objetos são associados a índices para representar todos os níveis de FRs, ou seja, Classe, Objeto e Comportamento. Classe ou Objeto pode ser chamado Objeto i, que é equivalente a FRi. O Comportamento será denotado como Objeto ij que corresponde a FRij, um FR de segundo nível. Por outro lado, um FRijk de terceiro nível será denotado como Objeto ijk. Logo, Objetos i, ij e ijk são equivalentes a FRi, FRij e FRijk, respectivamente, que são FRs de três níveis sucessivos da hierarquia de FR.
Estabelecida a equivalência entre a terminologia de Projeto Axiomático com a Metodologia de Orien- tação a Objeto, as etapas do Projeto Axiomático de Sistema de Software Orientado a Objeto (ADo-oSS) podem ser divididas em:
a) Definição dos FRs do sistema de software - nessa primeira etapa na concepção de um sistema de soft- ware são determinados os atributos do cliente, no domínio do cliente, que o sistema de software deve satisfazer. Então, os requisitos funcionais (FRs) do software no domínio funcional e restrições (Cs) são estabelecidos para satisfazer as necessidades do cliente.
b) Mapeamento entre Domínios e a Independência funções de software - Neste passo mapeiam-se os FRs do domínio funcional no domínio físico, identificando os parâmetros de projeto (DPs). Os DPs são o "como"do projeto que satisfazem FRs específicos. Os DPs devem ser escolhidas de modo a serem consistentes com as restrições.
c) Decomposição de FRs, DPs, and PVs - Essa decomposição ocorre entre domínios por um método de "zigue-zague"e deve ocorrer até que o projeto possa ser implementado sem mais decomposição. As hierarquias de FRs, DPs, PVs e as matrizes correspondentes representam a arquitetura do sistema.
d) Definição de Módulos - Matriz de Projeto Completa - No caso do software, a matriz de projeto fornece duas bases importantes na criação de software. Uma base é que cada elemento na matriz de projeto pode ser um método (ou operação) em termos do método orientado a objetos. A outra base é que cada linha na matriz de projeto representa um módulo para satisfazer um FR específico quando um dado DP é fornecido. Os termos fora da diagonal na matriz de projeto são importantes, uma vez que as fontes de acoplamento são esses termos fora da diagonal. É importante construir a matriz de projeto completa com base no nível de folha FR-DP-Aij para verificar a consistência das decisões tomadas durante a decomposição.
e) Identificação de Objetos, Atributos e Operações - A folha é o objeto de nível mais baixo em um dado ramo de decomposição, mas todos os objetos de nível de folha podem não estar no mesmo nível se pertencerem a ramos de decomposição diferentes. Uma vez que os Objetos são definidos, os Atributos (ou dados) - DPs - e Operações (ou métodos) - produtos do módulo vezes DPs - para o Objeto devem ser definidos para construir o modelo de objeto. Essa atividade deve usar a tabela da matriz de projeto completa.
A tradução da matriz de projeto, com FRs e DPs, em uma estrutura Orientada a Objeto é ilustrada pela Figura 4.5.
Figura 4.5: A correspondência entre a matriz de projeto completa e o diagrama de Classes (a) Matriz de projeto completa, (b) Diagrama de Classe, adaptado de (SUH; DO, 2000b)
f) A maioria dos esforços está focada nesta etapa do método orientado a objeto, uma vez que a relação é a principal característica. A metodologia de projeto axiomática apresentada utiliza os elementos fora da diagonal na matriz de projeto, bem como os elementos da diagonal em todos os níveis. Um elemento de matriz de projeto representa um relacionamento de ligação ou associação entre diferentes ramos de FR que têm um comportamento totalmente diferente.
Como foi citado anteriormente, todo processo de projeto axiomática inicia após o conhecimento das necessidades dos clientes do projeto e a para isso o uso de ferramentas e metodologias complementares para auxiliar na apreensão dessas informações de entrada se faz necessário. Nesse sentido, o projeto axiomático foi aplicado com o suporte da linguagem IDEF0 e da pesquisa bibliográfica específica para definição da necessidades dos potenciais usuários do framework proposto, que serão detalhadas no próximo capítulo.