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. Classes de porta representam a realização de um Produto de Trabalho: Protocolo, que, por sua vez, representa um conjunto de sinais de entrada e saída utilizados para comunicação com cápsulas.

Na criação de portas, considere a Lista de Verificação: Protocolo para determinar se o Protocolo é apropriado. 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.

Quando as portas estiverem vinculadas aos protocolos, o comportamento externo da cápsula deve ser avaliado e validado. Utilizando técnicas manuais de ensaio ou ferramentas automatizadas de simulação, teste o comportamento da cápsula simulando os eventos que testarão seu comportamento. A validação também considerará as cápsulas que interagem com a cápsula em processo de design. Ao utilizar ferramentas automatizadas, escreva o código stub dentro da cápsula para permitir que as portas sejam testadas. Quando forem detectados erros na definição da porta ou do protocolo, ou nas responsabilidades da cápsula, faça as mudanças apropriadas nas definições da cápsula, da porta ou do protocolo.

Quando as portas e os protocolos da cápsula tiverem sido validados, defina o comportamento interno da cápsula. O comportamento da cápsula é definido com o uso de um diagrama de estados. Referência: Diretriz: Diagrama de Estados . Outras informações gerais sobre cápsulas podem ser obtidas a partir da Diretriz: Cápsula , Lista de Verificação: Cápsula.

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 Estado

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 recursos 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.

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 em mais detalhes na Tarefa: Design de Classes.

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.

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.

Utilizando a 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 retenção estruturais (útil para estruturas)
• Herança comportamental - além da herança de interface e estrutural, também reutiliza máquinas de estado de código comportamental

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 de 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. É isso o que justifica tanto esforço para tornar as estruturas de design 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ê está absolutamente certo de que a decisão/suposição será sempre válida? Em caso negativo, o que você pode fazer para removê-los ou torná-los passíveis de mudança?

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.