Conforme apresentado no trabalho de Pimentel (2007) é possível estabelecer uma relação entre as fases do Processo Unificado (PU) e os domínios do Projeto Axiomático (PA). Esse trabalho propôs que os processos de mapeamento entre os quatro domínios definidos por Suh (2001) fossem relacionados às quatro fases do PU, como visto no Capítulo 3.
Neste trabalho, apresenta-se uma releitura desta visão, que se tornou possível devido à inclusão do domínio do problema no conjunto de domínios do PA. Assim, a abordagem proposta estabelece uma relação do processo de mapeamento entre os domínios com os fluxos do PU ligados mais diretamente ao desenvolvimento de software (modelagem de negócio, especificação de requisitos, modelagem e implementação). Por sua vez, é a intensidade com que ocorre o mapeamento entre determinado par de domínios a cada fase que relaciona as fases PU à abordagem proposta. O relacionamento estabelecido entre a abordagem proposta e o Processo Unificado é ilustrado pela Figura 30.
Assim, como se pode observar na Figura 30, o processo de mapeamento entre problemas e necessidades corresponde à disciplina de Modelagem de negócio do Processo Unificado. O mapeamento entre necessidades e requisitos corresponde à disciplina de Requisitos, enquanto o mapeamento de requisitos para elementos da UML no domínio físico corresponde à disciplina de Análise e Design.
Figura 30 - Projeto Axiomático e fases do Projeto Unificado Fonte: Autoria própria
Desta forma, trabalha-se no relacionamento entre cada domínio com mais ou menos intensidade conforme a fase do processo de desenvolvimento. Por exemplo, na fase de concepção o foco está, principalmente, no mapeamento entre os domínios do problema, do cliente e funcional, pois nesta fase são estudados os modelos de negócios, as necessidades do cliente e os requisitos do sistema. Por outro lado, na fase de elaboração o foco está no relacionamento entre domínio funcional e físico à medida que estão sendo construídos os modelos do sistema.
Nas seções anteriores falou-se do mapeamento de elementos de um domínio para outro, seguido pela decomposição dos elementos destes domínios. Essa descrição do processo pode fazer parecer que ele envolve somente dois domínios. No entanto, é necessário esclarecer que o processo de mapeamento não deve ser independente, mas sim, um processo completo, que pode envolver três ou mais domínios a cada iteração como ilustra a Figura 30. Mais adiante neste Capítulo é discutido o estabelecimento de etapas de decomposição dos elementos dos domínios e o foco de cada uma delas, levando em conta a relação estabelecida com o PU nesta Seção.
Figura 31 - Fluxo de Requisitos do PU e Abordagem Proposta Fonte: Autoria própria
Uma vez que o trabalho apresentado nessa dissertação está focado, principalmente, na especificação de requisitos, buscou-se estabelecer também a relação da abordagem proposta com o fluxo de requisitos do PU. Esta relação é ilustrada na Figura 31. Desta forma, a atividade ―Analisar Problema‖ do PU pode ser representada na abordagem proposta como a atividade de ―identificação de problemas e seu mapeamento para as necessidades‖. A atividade ―Compreender as necessidades dos envolvidos‖ toma, nesta abordagem, a forma da ―identificação das necessidades e seu mapeamento para os requisitos‖. Finalmente, a atividade ―Definir Sistema‖ é representada pelo ―mapeamento dos requisitos para casos de uso do software‖. Por sua vez, as atividades de Gerenciar escopo e Refinar a Definição do Sistema não fazem parte do escopo da abordagem proposta, como ilustra a Figura 31.
Esta seção estabeleceu a relação existente entre os domínios do Projeto Axiomático e as fases do Processo Unificado. Desta forma, de acordo com a fase do projeto, pode-se ter mais foco no mapeamento entre um grupo ou outro de domínios. Além disso, discutiu-se a relação existente entre o fluxo de requisitos e a abordagem proposta. A próxima seção discute a questão da manutenção da correspondência entre elementos destes domínios do ponto de vista do nível de detalhamento que se pode alcançar em cada um deles.
4.3.1 Mapeamento e Níveis de Detalhamento
Conforme discutido anteriormente, a atividade de representar o mapeamento dos relacionamentos existentes entre elementos dos domínios funcional e físico em uma matriz é uma das características fundamentais da TPA. Ainda, o número de elementos deve ser sempre igual nos dois domínios possibilitando a formação de uma matriz quadrada em qualquer nível de decomposição funcional, segundo o Teorema 4 (Anexo A).
No entanto, este trabalho tem por objetivo estender o processo de mapeamento e decomposição para os domínios do problema e do cliente. Portanto, embora seja desejável manter sempre o mesmo número de elementos em todos os domínios, nesta abordagem torna-se comum um domínio possuir mais itens que o anterior, pois quanto mais se caminha em direção ao domínio físico maior o nível de
detalhamento que pode ser obtido. Ou seja, quanto mais o processo se aproxima da implementação, maior tende a ser o detalhamento do projeto. Sendo que, em última análise, no nível máximo de abstração de um projeto de software encontram-se os problemas do cliente enquanto no nível máximo de detalhamento estão as linhas do código fonte.
Assim sendo, recomenda-se manter o mapeamento entre dois domínios até que não seja mais possível ou interessante realizar detalhamentos. A partir do momento em que não for mais possível detalhar, deixa-se de realizar o mapeamento entre os domínios envolvidos. Daí em diante, passa-se a fazer mapeamento somente entre os outros domínios em que ainda é possível continuar realizando decomposição.
Figura 32 - Níveis de Detalhamento Fonte: Autoria própria
Ao final do projeto, um domínio terá mais níveis de detalhamento que o outro, porém, até o nível de decomposição alcançado, existirá sempre o mesmo número de elementos entre os pares de os domínios, conforme ilustra a Figura 32. Por outro lado, é possível que alguns domínios não possuam elementos nos níveis mais altos de abstração, conforme ilustrado na figura pelo Domínio Físico, que, como se pode ver, não possui nenhum elemento correspondente ao requisito ―R1‖. Isso se deve ao fato de que alguns domínios, como o físico, são mais voltados aos aspectos práticos e, portanto, têm limitações em relação à abstração.
Esta seção discutiu a questão da manutenção da correspondência entre elementos dos domínios do ponto de vista do nível de detalhamento que se pode
alcançar em cada um deles. Ainda levando em conta a questão do detalhamento e mapeamento dos elementos de cada domínio, a próxima seção discute as questões relativas à rastreabilidade que pode ser obtida com a aplicação da abordagem proposta.