Aspectos Gerais

A abordagem de Pimentel (2007), baseada em TPA E POO, tem por objetivo trazer vantagens ao processo de desenvolvimento de software. Entre estas vantagens está o estabelecimento de critérios para a tomada de decisões de projeto como escolher o conjunto mais apropriado de requisitos funcionais e escolher a melhor solução de projeto entre as possíveis maneiras de se modelar a solução.

A TPA é comprovadamente eficaz na melhoria de resultados na elaboração de projetos em diversas áreas e pode ser utilizada, inclusive, no desenvolvimento de software. Por sua vez, o PU é um dos processos mais difundidos de desenvolvimento de software. PU é utilizado, na maioria das vezes, em conjunto com a UML, a linguagem de modelagem orientada a objetos mais utilizada atualmente. Por esta razão, ao se pensar em uma abordagem de projeto axiomático de software orientado ao objetos, parece um caminho natural integrar estas técnicas. Para isso é necessário estabelecer relações entre as fases do PU e os mapeamentos entre domínios da TPA e, também, estabelecer correspondências entre os conceitos básicos de TPA e UML. Por esta razão, são apresentadas a seguir as definições propostas por (PIMENTEL, 2007) no contexto da UML:

Caso de Uso: um caso de uso é a especificação de um conjunto de ações que

representa uma utilização completa do sistema por um ou mais atores.

Subcaso de Uso: um subcaso de uso é a especificação de um conjunto de ações

que representa uma utilização não completa do sistema ou subsistema. Um subcaso de uso representa uma parte de uma utilização completa do sistema, ou seja, parte de um caso de uso.

Subcaso de uso independente: um subcaso de uso independente de

características técnicas é a especificação de um conjunto de ações que um sistema executa que representa uma utilização não completa do sistema que é especificada sem levar em consideração características técnicas empregadas na solução.

Subcaso de uso dependente: um subcaso de uso dependente de características

técnicas é a especificação de um conjunto de ações que um sistema executa que representa uma utilização não completa do sistema que é especificada considerando fortemente características técnicas empregadas na solução.

Serviço Técnico: um serviço técnico é um serviço esperado por um objeto, classe

ou componente do sistema de outro objeto, classe ou componente do sistema.

Colaboração: uma colaboração é o conceito da UML responsável por representar a

realização de um caso de uso (BOOCH, RUMBAUGH, & JACOBSON, 2006).

Uma vez definidos os conceitos da UML utilizados na abordagem, é possível estabelecer sua relação com os conceitos de requisitos funcionais (RFs) e parâmetros de projeto (PPs) definidos por Suh (SUH, 2001).

De acordo com Suh, os RFs representam as características funcionais esperadas de um produto (SUH, 2001). Por sua vez, Booch, Rumbaugh e Jacobson (2006) definem um caso de uso como a representação completa de um requisito funcional do sistema. Assim sendo, casos de uso podem representar o conceito de requisito funcional do Projeto Axiomático como ocorre na abordagem de Pimentel (2007).

Ainda, segundo Booch, Jacobson e Rumbaugh (2006), as colaborações são utilizadas para especificar a realização de casos de uso e operações. A relação de realização entre casos de uso e colaborações é ilustrada na Figura 22. Por outro

lado, na TPA os PPs são especificados para satisfazer os RFs do projeto. Portando, isto significa que, em um contexto em que Casos de Uso representam requisitos funcionais, as colaborações podem ser utilizadas para representar os PPs.

Figura 22 - Realização de Casos de Uso Fonte: Autoria própria

Esta representação é válida em níveis de abstração mais altos do projeto mas, conforme os requisitos funcionais são decompostos, é necessário utilizar outros elementos. Desta maneira, casos de uso são decompostos em subcasos e as colaborações em subcolaborações. As subcolaborações representam interações menores que compõem a colaboração original. A Figura 23 apresenta um exemplo de decomposição de Casos de Uso e Colaborações. Neste exemplo o caso de uso ―Testar Placa‖ está composto em dois subcasos, ―Testar Sensor de Papel‖ e ―Testar Memória‖, que são realizados por subcolaborações identificadas com os mesmos nomes respectivamente.

Figura 23 - Decomposição de Casos de Uso e Colaborações Fonte: Autoria própria

Esta divisão ou detalhamento dos casos de uso e colaborações em elementos menores é necessária para que seja possível adaptar a abordagem proposta ao processo em zig-zag (SUH, 2001). De acordo com este processo, os RFs devem ser refinados ou decompostos e, a cada iteração, devem ser identificados os PPs correspondentes. Com vistas a realizar este processo de decomposição e mapeamento entre os domínios funcional e físico, foram definidos níveis de hierarquia funcional para os casos de uso, chegando-se à conclusão de que quatro níveis com uma ou mais decomposições cada um são suficientes para o detalhamento de um projeto de software (PIMENTEL, 2007). A Tabela 3 demonstra as correspondências de RFs e PPs com conceitos da UML em cada nível de decomposição.

Tabela 3 - Níveis de Abstração

Nível de Abstração Requisitos Funcionais (RF) Parâmetros de Projeto (PP)

1 Casos de Uso Colaborações e seus papéis

2 Subcasos de uso independentes de características técnicas.

Subcolaborações e seus papéis 3 Subcasos de uso dependentes de

características técnicas.

Subcolaborações e seus papéis

4 Serviços técnicos Objetos e classes

Fonte: (PIMENTEL, 2007)

Uma vez identificadas as correspondências dos conceitos de requisito funcional e parâmetro de projeto com os elementos da UML, foi estabelecida um relação de correspondência entre os processos de mapeamento entre domínios da TPA e as fases do PU.