Atividade:  Design de Cápsula

As cápsulas são usadas para definir threads simultâneos de execução no sistema. As cápsulas podem ser aninhadas a uma profundidade arbitrária e ter associações a classes (passivas) de design. Essa atividade é realizada uma vez para cada cápsula, incluindo as novas cápsulas dentro do escopo dessa atividade.

Criar Portas e Vincular a Protocolos

Leve em consideração as responsabilidades da cápsula, criando um conjunto inicial de classes de portas. Essas classes de portas representam as 'interfaces' para a cápsula. As classes de portas representam a realização de Artefato: Protocolo, que por sua vez representa um conjunto de sinais de entrada e saída usados na comunicação com as cápsulas.

Ao criar portas, avalie Pontos de Verificação: Protocolo para determinar se o Protocolo é adequado. A porta deve refletir um conjunto único de responsabilidades relacionadas; a existência de protocolo com escopo semelhante permite a sua reutilização em várias cápsulas. Quando o protocolo adequado estiver selecionado, vincule a porta a ele.

Validar Interações de Cápsulas

Quando as portas estiverem vinculadas aos protocolos, o comportamento externo da cápsula deve ser avaliado e validado. Usando técnicas manuais de ensaio ou ferramentas automatizadas de simulação, o comportamento da cápsula deve ser testado por eventos de simulação que testarão o comportamento da cápsula. A validação também considerará as cápsulas que interagem com a cápsula em processo de design. Ao usar ferramentas automatizadas, o código stub precisará ser escrito dentro da cápsula para permitir que as portas sejam testadas. Os erros na definição da porta ou do protocolo, ou nas responsabilidades da cápsula, devem ser detectados, e as mudanças apropriadas nas definições da cápsula, porta ou protocolo devem ser feitas.

Definir Máquina de Estado da Cápsula

Quando as portas e os protocolos da cápsula tiverem sido validados, o comportamento interno da cápsula deve ser definido. O comportamento da cápsula é definido usando-se um diagrama de estados, consulte Diretrizes: Diagrama de Estados. Outras informações gerais sobre cápsulas podem ser obtidas em Diretrizes: Cápsula e Pontos de Verificação: Cápsulas.

Definir Estados

Primeiro, identifique os estados nos quais a cápsula pode existir. Os estados devem ser exclusivos (uma cápsula não pode estar em dois estados simultaneamente) e descritivos. Consulte as diretrizes e os pontos de verificação adequados para obter mais informações.

Definir Transições de Estados

Quando os estados forem definidos, leve em consideração as transições entre os estados. O código de transição deve ser redigido como pseudocódigo de aplicativo de alto nível; ele deve consistir basicamente em chamadas de serviços do sistema operacional de tempo real, por exemplo, serviços de frame, serviços de tempo, operações de porta , operações de cápsula e operações de classe passiva.

Ao adicionar código detalhado a uma transição de Cápsula:

• Se o código puder ser útil em outras transições, leve em consideração delegá-lo a uma operação de Cápsula.
• Avalie se o código implementa capacidades que estão de acordo com a responsabilidade da Cápsula.

Ao definir uma operação de Cápsula:

• Leve em consideração se a função seria reutilizável a qualquer momento por qualquer transição da Cápsula, e se qualquer parte do trabalho que está sendo feito poderia ser útil em outra parte do sistema. Em caso afirmativo, considere delegá-la a uma função de classe passiva.
• Se o código for estritamente específico a aplicativos que não possa ser armazenado em uma determinada classe de Dados, convém criar uma classe de Dados adicional como uma abstração para aquele código.
• Caso o código trate da manipulação da estrutura de dados (por exemplo, listas de manutenção), ou realize cálculos complexos (mais de uma linha), ele deverá ser colocado em uma classe de dados.

Definir Requisitos de Classes Passivas

Examine as classes passivas citadas pela cápsula, com base nas máquinas de estados das cápsulas. Se houver novos requisitos nessas classes, mude as solicitações que precisam ser geradas para efetivar as mudanças necessárias. Se novas classes tiverem sido identificadas, os requisitos dessas classes (mais especificamente, as operações necessárias nelas) devem ser reunidas e as classes devem ser criadas. Essas classes serão descritas com mais detalhe em Atividade: Design da Classe.

Introduzir Heranças de Cápsulas

A herança de cápsulas é usada para implementar especialização de generalização, para utilizar polimorfismo e para reutilizar implementação. A palavra-chave aqui é 'implementação' - ela é uma técnica usada basicamente para reutilizar a estrutura interna de cápsulas, mas não, o comportamento externo de cápsulas. A finalidade primária de Artefato: Protocolos é reutilizar definições de comportamento, para que a herança de cápsulas não precise ser usada com essa finalidade.

Freqüentemente, a herança é aplicada de forma incorreta para conseguir algo que seria conseguido de maneira mais fácil usando técnicas de design mais simples.

Utilização de herança para especialização de generalização

Existem três tipos de herança. Listadas da menos complexa (mais desejável) à mais complexa (menos desejável), são elas:

• Herança de interface - herda apenas portas e protocolos, esse é o tipo de herança mais desejável
• Herança estrutural - herda a interface e as hierarquias de conteúdo estrutural (útil para frameworks)
• Herança de comportamento - além das anteriores também reutiliza o código de comportamento e as máquinas de estado

A herança estrutural e de comportamento apresentam alguns problemas:

• O grau muito alto de acoplamento conseguido pela herança faz com que as mudanças para as subclasses sejam colocadas em cascata quando são feitas mudanças nas superclasses.
• A necessidade de substituir e excluir o comportamento e a estrutura de superclasse nas subclasses indica o uso inadequado da herança (normalmente para reutilização tática de código). A refatoração de classes e cápsulas e a utilização adequada de delegação são uma estratégia mais apropriada.
• Herança significa mover decisões de design para cima na hierarquia de classes, causando design indesejável e dependências na compilação. 

Outros problemas:

• As decisões podem não ser adequadas em todas as situações de uso.
• A introdução de herança realmente dificulta a reutilização, pois os elementos de design são acoplados de modo mais rígido.
• O design se torna mais frágil porque qualquer novo requisito que invalide a decisão causará grandes problemas.
• Será necessário tornar o design extremamente flexível para compensar, o que é sempre difícil. É por isso que é tão difícil projetar frameworks reutilizáveis!

Todos os designs que contêm estrutura/comportamento têm decisões e pressupostos internos (explícitos ou implícitos). A pergunta crítica a fazer é: você tem absoluta certeza de que as decisões ou os pressupostos serão sempre válidos? Em caso negativo, o que você pode fazer para removê-los ou torná-los passíveis de mudança?

Validar o Comportamento da Cápsula

Como passo final, o comportamento da cápsula deve ser avaliado e validado. Usando técnicas manuais de ensaio ou ferramentas automatizadas de simulação, o comportamento da cápsula deve ser testado por eventos de simulação que testarão o comportamento da cápsula. Além disso, a estrutura interna da cápsula deve ser avaliada, assegurando que tanto o comportamento externo quanto a implementação interna desse comportamento sejam validados. Ao usar ferramentas automatizadas, talvez seja necessário escrever o código stub para simular a implementação de classes passivas de dados e cápsulas externas com as quais a cápsula interage. Os defeitos detectados devem ser documentados e as mudanças adequadas nas definições de cápsulas devem ser feitas.

Copyright  (c) 1987 - 2001 Rational Software Corporation

Rational Unified Process