На этом шаге рассмотрим декомпозицию сложной системы.
Выявление общих абстракций и механизмов значительно облегчает понимание сложных систем. Сложные системы содержат много разных иерархий. Например, компьютер можно разделить на несколько систем: монитор, системный блок и т.д. Такое разделение дает структурную иерархию, основанную на отношении "является частью" (part of).
С другой стороны, устройство компьютера можно анализировать иначе. Например, монитор - это определенная разновидность устройств отображения информации, а монитор "LG" - это конкретный тип мониторов. Иначе говоря, понятие "устройство отображения информации" обобщает свойства, характерные для всех устройств отображения, а понятие "монитор" представляет собой уточнение вида устройства отображения, обладающего определенными свойствами, которые позволяют отличить его от других, например, от телевизора.
Вторая иерархия основана на отношении "является" (is-a). Любую систему следует рассматривать с обеих точек зрения, изучая ее и как иерархию "целое/часть", и как иерархию "общее/частное". Назовем эти иерархии соответственно структурой классов (class structure) и структурой объектов (object structure).
В сложных системах программного обеспечения существуют и другие типы иерархий. Среди них особенно важными являются модульная структура, описывающая отношения между физическими компонентами системы, и иерархия процессов, описывающая отношения между динамическими компонентами.
В данном случае, говоря о структуре классов и структуре объектов, мы не имеем в виду классы и объекты, создаваемые программистами. Мы имеем в виду более абстрактные классы и объекты, образующие сложную систему, например, монитор, корпус, клавиатура, материнская плата и т.д.
Выбор элементарных компонентов зависит от наблюдателя. На рис. 1 продемонстрированы две ортогональных иерархии одной системы: структура классов и структура объектов.
Рис.1. Основные иерархии сложных систем
Каждая иерархия является многоуровневой, причем на каждом уровне классы и объекты состоят из более простых компонентов. Выбор элементарных классов и объектов зависит от рассматриваемой задачи. Анализ любого уровня иерархии позволяет выявить новый уровень сложности, обусловленный тесным взаимодействием между его объектами.
Сопоставляя структуры классов и структуры объектов с пятью атрибутами сложных систем, легко понять, что практически все сложные системы имеют одинаковую (каноническую) форму, показанную на рис. 2. В собирательном значении структура классов и структура объектов образуют архитектуру (architecture) системы.
Рис.2. Каноническая форма сложной системы
Структура классов и структура объектов не являются полностью независимыми друг от друга: каждый элемент структуры объектов представляет специфический экземпляр определенного класса. Как показано на рис. 2, количество объектов в сложной системе обычно намного превышает количество классов.
Анализ обеих иерархий позволяет выявить избыточность рассматриваемой системы. В противном случае пришлось бы дублировать информацию о свойствах каждого компонента системы. Структура классов решает эту проблему, позволяя описать все общие свойства в единственном месте.
Одна и та же структура классов допускает разные способы конкретизации и организации объектов. Ни одну архитектуру нельзя назвать единственно правильной. Это обстоятельство порождает основную проблему, связанную с архитектурой системы, — поиск баланса между множеством разных способов организации компонентов, пятью атрибутами сложных систем и потребностями пользователей.
При проектировании сложной системы программного обеспечения необходимо разделять ее на все меньшие и меньшие части, каждую из которых можно уточнять независимо друг от друга.
Формально принципы структурного проектирования выполняются методом "сверху вниз", с этой точки зрения декомпозиция есть обычное алгоритмическое разделение, в котором каждый модуль системы выполняет один из этапов общего процесса. На рис. 9 в качестве примера приведена структурная схема, показывающая связи между различными функциональными элементами. Эта структурная схема иллюстрирует часть программы, обновляющей содержание основного файла.
Рис.3. Алгоритмическая декомпозиция
Предположим, что существует альтернативный способ декомпозиции этой задачи. На рис. 4 продемонстрирована декомпозиция системы, в качестве критерия выбраны основные абстракции проблемных областей. Вместо разделения системы на этапы, например, Прочитать отформатированное обновление к Добавить контрольную сумму, мы должны определить такие объекты, как Главный файл и Контрольная сумма, которые извлекаются непосредственно из словаря предметной области.
Рис.4. Объектно-ориентированная декомпозиция
Несмотря на то что обе схемы решают одну и ту же задачу, они делают это разными способами. Во второй декомпозиции мир представляет собой совокупность автономных агентов, взаимодействующих друг с другом, обеспечивая более сложное поведение системы. Действие Прочитать отформатированное обновление больше не является независимым алгоритмом; это действие представляет собой операцию, связанную с объектом Файл обновлений. В результате выполнения этой операции возникает другой объект — Обновление карты. Таким образом, каждый объект в схеме реализует свое собственное поведение, и каждый из них моделирует некоторый объект реального мира. С этой точки зрения объект является материальной сущностью, обладающей определенным поведением. Получая сообщения, объекты выполняют определенные операции. Так как описанная декомпозиция основана на объектах, а не на алгоритмах, она называется объектно-ориентированной (object-oriented decomposition).
Разделение по алгоритмам основано на порядке происходящих событий, а разделение по объектам акцентирует внимание на агентах, которые либо вызывают действие, либо выполняют его.
Невозможно сконструировать сложную систему одновременно двумя способами, тем более, что они полностью ортогональны. Декомпозицию следует начинать с объектов, поскольку она облегчает упорядочение сложных систем. Объекты как абстракции реальных сущностей представляют собой особенно компактные и связные блоки информации.
Преимущества объектно-ориентированной декомпозиции:
- уменьшает размер систем за счет повторного использования общих механизмов, обеспечивая значительную экономию выразительных средств;
- основано на устойчивых промежуточных формах, что позволяет системам быть более гибкими и легче эволюционировать со временем;
- значительно снижает риск, возникающий при создании сложной программной системы, так как она создается из меньших по размеру систем
- помогает справиться со сложностью, характерной для систем программного обеспечения, помогая правильно разделить большое пространство состояний.
Объектная структура играет важную роль, поскольку она иллюстрирует схемы взаимодействия разных объектов друг с другом, которые называются механизмами (mechanisms). Структура классов не менее важна, так как она выделяет общую структуру и поведение внутри системы.
Несмотря на то, что каждый объект определенного типа рассматривается как отдельная сущность, можно предположить, что его поведение не отличается от поведения других подобных объектов. Объединяя объекты в группы взаимосвязанных абстракций, мы четко разделяем общие и уникальные свойства разных объектов, что в дальнейшем помогает нам справиться со свойственной им сложностью.
Идентифицировать иерархии в сложной программной системе часто нелегко, поскольку для этого необходимо выяснить шаблоны поведения многих объектов, функционирование каждого из которых может быть чрезвычайно сложным.
На следующем шаге рассмотрим особенности проектирования сложных систем.
