Продумайте обязанности капсулы, создав начальный набор классов портов. Эти классы портов представляют собой 'интерфейсы' капсулы. Классы портов представляют реализацию Рабочий продукт: Протокол, который, в свою очередь, представляет набор сигналов входных и выходных, используемых для связи с капсулой.

Пи создании портов рассмотрите Справочная таблица: Протокол , чтобы определить, подходит ли Протокол. Порт должен отражать исключительный набор связанных обязанностей. Если протокол имеет подобную область действия, то порт можно использовать во многих капсулах. После выбора подходящего протокола, свяжите его с портом.

После того как порты связаны с протоколами, нужно оценить и проверить внешнее поведение. Используя или ручные техники сквозного контроля, или средства автоматической имитации, протестируйте поведение капсулы, имитируя для этого соответствующие события. Проверка также касается тех капсул, которые взаимодействуют с разрабатываемой. С помощью автоматизированных средств напишите код заглушки в капсуле, чтобы протестировать порты. Если в протоколе, порте или обязанностях капсулы обнаружатся ошибки, внесите соответствующие изменения.

После проверки портов и протоколов капсулы определите ее внутреннее поведение. Поведение капсулы определяется с помощью диаграммы состояний. Справочник: Рекомендация: Диаграмма состояний. Другую общую информацию о капсуле можно получить в Рекомендация: Капсула , Справочная таблица: Капсула.

Определить состояния

Сначала определите возможные состояния капсулы. Состояния должны быть уникальными (капсула не может находиться в двух состояниях одновременно) и описательными. Более подробная информация содержится в соответствующих рекомендациях и контрольных точках.

Определить переходы между состояниями

После определения состояний опишите переходы между ними. Код перехода должен выглядеть как псевдо-код приложения высокого уровня, он должен состоять в основном из вызовов служб операционной системы в реальном времени, например, служб фреймов, служб времени, операций портов, операций капсулы и операций пассивного класса.

При добавлении подробного кода к переходу Капсулы:

• Если код может быть полезен в других переходах, выделите его в операцию Капсулы.
• Проверьте, согласовываются ли функции, реализованные кодом, с обязанностями Капсулы.

При определении операции Капсулы:

• Проверьте, будет ли полезна эта функция в любое время при любом переходе в Капсулу, и будет ли выполняемая работа полезна еще где-нибудь в системе. Если да, то выделите ее в функцию пассивного класса.
• Если код является слишком специфичным для этого приложения чтобы храниться в определенном Классе данных, создайте дополнительный Класс данных как абстракцию для этого кода.
• Если код управляет структурой данных (например, списками поддержки) или выполняет сложные (более 1 линии) вычисления, его стоит вынести в класс данных.

На основании конечных автоматов капсулы проверьте пассивные классы, на которые ссылается капсула. Если существуют новые требования к этим классам, необходимо создать запросы на требуемые изменения. Если были определены новые классы, то необходимо собрать вместе требования к этим классам (особенно требуемые операции над ними) и создать классы. Эти классы будут в дальнейшем описаны в Задача: Проект класса.

Наследование капсулы используется для реализации специализации-обобщения, чтобы воспользоваться полиморфизмом для повторной реализации. Ключевым словом является здесь 'реализация' - это техника повторного использования внутренней структуры капсул, а не внешнего поведения.

Наследование часто неверно применяют для достижения чего-то, что может быть легко достигнуто более простым способом.

Использование наследования для специализации-обобщения

Существуют три вида наследования. Ниже они перечислены, начиная с наименьшей сложности (наиболее желательные), и заканчивая наибольшей сложностью (менее желательные):

• Наследование интерфейса - наследуются только порты и протоколы, это наиболее желательный вид наследования
• Структурное наследование - наследуются интерфейс и внутренние структурные иерархии (полезно для структур)
• Наследование поведения - в дополнение к наследованию интерфейсов и структур, наследуются код поведения и конечные автоматы

При наследовании структуры и поведения могут возникнуть некоторые проблемы:

• Очень высокая степень соединения при наследовании приводит к каскадным изменениям подклассов при изменении суперкласса.
• Необходимость переопределения или удаления структуры или поведения подкласса означает неуместное использование наследования (обычно для тактического повторного использования кода). Рефакторинг классов и капсул, а также рациональное использование делегирования являются более подходящими стратегиями.
• Наследование означает перемещение решений проекта вверх по иерархии классов, что приводит к нежелательному проекту и зависимостям компиляции.  

Среди других проблем:

• Решения могут не подходить для всех ситуаций использования.
• Введение наследования фактически усложняет повторное использование, так как элементы проекта более тесно связаны.
• Проект становится более уязвимым, потому что всякие новые требования, которые отменяют старые решения, приводят к большим проблемам.
• Проект должен быть очень гибок для изменений, что часто очень трудно обеспечить. Вот что делает проектирование многоразовых структур таким сложным!

Все проекты, содержащие структуру/поведение, содержат встроенные решения и предположения (или явные, или неявные). Ключевым вопросом является следующий: абсолютно ли вы уверены, что решение/предположение будет всегда верным? Если нет, что вы можете сделать, чтобы удалить его или обеспечить возможность изменения?

Наконец, нужно оценить и проверить поведение капсулы. Используя или ручные техники сквозного контроля, или средства автоматической имитации, протестируйте поведение капсулы, имитируя для этого соответствующие события. Кроме того, в дополнение к проверке внешнего поведения, проверьте внутреннюю структуру капсулы. Может понадобиться с помощью автоматизированных средств написать код заглушки, чтобы имитировать реализацию пассивных классов данных и внешних капсул, с которыми данная капсула взаимодействует. Обнаруженные дефекты следует внести в документацию и произвести соответствующие изменения в капсуле.