Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++, страница 6

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

1-1, объектов в сложной системе обычно гораздо больше, чем классов.Показывая обе иерархии, мы демонстрируем избыточность рассматриваемой системы. Если бымы не знали структуру классов нашей системы, нам пришлось бы повторять одни и те же сведе3Сложные программные системы включают также и другие типы иерархии. Особое значениеимеют их модульная структура, которая описывает отношения между физическимикомпонентами системы, и иерархия процессов, которая описывает отношения междуДинамическими компонентами.ния для каждого экземпляра класса. С введением структуры классов мы размещаем в ней общиесвойства экземпляров.Наш опыт показывает, что наиболее успешны те программные системы, в которыхзаложены хорошо продуманные структуры классов и объектов и которые обладают пятьюпризнаками сложных систем, описанными выше.

Оценим важность этого наблюдения ивыразимся более категорично: очень редко можно встретить программную систему,разработанную точно по графику, уложившуюся в бюджет и удовлетворяющую требованиямзаказчика, в которой бы не были учтены соображения, изложенные выше.Структуры классов и объектов системы вместе мы называем архитектурой системы.Человеческие возможности и сложные системы. Если мы знаем, как должны бытьспроектированы сложные программные системы, то почему при создании таких систем мысталкиваемся с серьезными проблемами? Как показано в главе 2, идея о том, как бороться сосложностью программ (эту идею мы будем называть объектный подход) относительно нова.Существует, однако, еще одна, по-видимому, главная причина: физическая ограниченностьвозможностей человека при работе со сложными системами.Когда мы начинаем анализировать сложную программную систему, в ней обнаруживается много составных частей, которые взаимодействуют друг с другомразличными способами, причем ни сами части системы, ни способы их взаимодействияне обнаруживают никакого сходства.

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

При анализедискретных систем необходимо рассматривать большие, сложные и не всегдадетерминированные пространства состояний. К сожалению, один человек не можетследить за всем этим одновременно. Эксперименты психологов, например Миллера,показывают, что максимальное количество структурных единиц информации, закоторыми человеческий мозг может одновременно следить, приблизительно равносеми плюс-минус два [14]. Вероятно, это связано с объемом краткосрочной памяти учеловека. Саймон также отмечает, что дополнительным ограничивающим факторомявляется скорость обработки мозгом поступающей информации: на восприятие каждойновой единицы информации ему требуется около 5 секунд [15].Таким образом, мы оказались перед серьезной дилеммой.

Сложность программных системвозрастает, но способность нашего мозга справиться с этой сложностью ограничена. Как же намвыйти из создававшегося затруднительного положения?1.3. Внесение порядка в хаосРоль декомпозицииКак отмечает Дейкстра, «Способ управления сложными системами был известен еще вдревности — divide et impera (разделяй и властвуй)» [16]. При проектировании сложнойпрограммной системы необходимо разделять ее на все меньшие и меньшие подсистемы, каждуюиз которых можно совершенствовать независимо. В этом случае мы не превысим пропускнойспособности человеческого мозга: для понимания любого уровня системы нам необходимоодновременно держать в уме информацию лишь о немногих ее частях (отнюдь не о всех).

В самомделе, как заметил Парнас, декомпозиция вызвана сложностью программирования системы,поскольку именно эта сложность вынуждает делить пространство состояний системы [17].Алгоритмическая декомпозиция. Большинство из нас формально обучено структурномупроектированию «сверху вниз», и мы воспринимаем декомпозицию как обычное разделениеалгоритмов, где каждый модуль системы выполняет один из этапов общего процесса.

На рис. 1-2приведен в качестве примера один из продуктов структурного проектирования: структурнаясхема, которая показывает связи между различными функциональными элементами системы.Данная структурная схема иллюстрирует часть программной схемы, изменяющей содержаниеуправляющего файла. Она была автоматически получена из диаграммы потока данныхспециальной экспертной системой, которой известны правила структурного проектирования [18].Объектно-ориентированная декомпозиция.

Предположим, что у этой задачи существует альтернативный способ декомпозиции. На рис. 1-3 мы разделили систему, выбрав вкачестве критерия декомпозиции принадлежность ее элементов к различным абстракциям даннойпроблемной области. Прежде чем разделять задачу на шаги типа Get formatted update (Получитьизменения в отформатированном виде) и Add check sum (Прибавить к контрольной сумме), мыдолжны определить такие объекты как Master File (Основной файл) и Check Sum (Контрольнаясумма), которые заимствуются из словаря предметной области.Хотя обе схемы решают одну и ту же задачу, но они делают это разными способами.

Вовторой декомпозиции мир представлен совокупностью автономных действующих лиц, которыевзаимодействуют друг с другом, чтобы обеспечить поведение системы, соответствующее болеевысокому уровню. Get formatted update (Получить изменения в отформатированном виде)больше не присутствует в качестве независимого алгоритма; это действие существует теперь какоперация надGРис. 1-2. Алгоритмическая декомпозицияобъектом File of Updates (Файл изменений). Эта операция создает другой объект — Update to Card(Изменения в карте).

Таким образом, каждый объект обладает своим собственным поведением, икаждый из них моделирует некоторый объект реального мира. С этой точки зрения объектявляется вполне осязаемой вещью, которая демонстрирует вполне определенное поведение.Объекты что-то делают, и мы можем, послав им сообщение, попросить их выполнить то-то и тото. Так как наша декомпозиция основана на объектах, а не на алгоритмах, мы называем ееобъектно-ориентированной декомпозицией.Декомпозиция: алгоритмическая или объектно-ориентированная? Какая декомпозиция сложной системы правильнее — по алгоритмам или по объектам? В этом вопросе естьподвох, и правильный ответ на него: важны оба аспекта. Разделение по алгоритмамконцентрирует внимание на порядке происходящих событий, а разделение по объектам придаетособое значение агентам, которые являются либо объектами, либо субъектами действия.

Однакомы не можем сконструировать сложную систему одновременно двумя способами, тем более, чтоэти способы по сути ортогональны4. Мы должны начать разделение системы либо по алгоритмам,либо по объектам, а затем, используя полученную структуру, попытаться рассмотреть проблему сдругой точки зрения.Опыт показывает, что полезнее начинать с объектной декомпозиции.

Такое началопоможет нам лучше справиться с приданием организованности сложности программных систем.Выше этот объектный подход помог нам при описании таких непохожих систем, как компьютеры,растения, галактики и общественные институты. Как будет видно в дальнейшем (в главах 2 и 7),объектная декомпозиция имеет несколько чрезвычайно важных преимуществ передалгоритмической. Объект-4Лэнгдон предполагает, что эта ортогональность изучалась с древних времен. Он пишет: «К. X.Ваддингтон отметил, что такая дуальность взглядов прослеживается до древних греков.Пассивный взгляд предлагался Демокритом, который утверждал, что мир состоит из атомов.Эта позиция Демокрита ставила в центр всего материю. Классическим представителем другойстороны — активного взгляда — был Гераклит, который выделял понятие процесса»[34].Рис.

1-3. Объектно-ориентированная декомпозицияная декомпозиция уменьшает размер программных систем за счет повторного использованияобщих механизмов, что приводит к существенной экономии выразительных средств. Объектноориентированные системы более гибки и проще эволюционируют со временем, потому что ихсхемы базируется на устойчивых промежуточных формах. Действительно, объектнаядекомпозиция существенно снижает риск при создании сложной программной системы, так какона развивается из меньших систем, в которых мы уже уверены. Более того, объектнаядекомпозиция помогает нам разобраться в сложной программной системе, предлагая намразумные решения относительно выбора подпространства большого пространства состояний.Преимущества объектно-ориентированных систем демонстрируются в главах 8-12примерами прикладных программ, относящихся к различным областям. Следующая врезкасопоставляет объектно-ориентированное проектирование с более традиционными подходами.Роль абстракцииВыше мы ссылались на эксперименты Миллера, в которых было установлено, что обычночеловек может одновременно воспринять лишь 7±2 единицы информации.

Это число, повидимому, не зависит от содержания информации. Как замечает сам Миллер: «Размер нашейпамяти накладывает жесткие ограничения на количество информации, которое мы можемвоспринять, обработать и запомнить. Организуя поступление входной информации одновременнопо нескольким различным каналам и в виде последовательности отдельных порций, мы можемпрорвать... этот информационный затор» [35].

В современной терминологии это называютразбиением или выделением абстракций.Вулф так описывает этот процесс: «Люди развили чрезвычайно эффективную технологиюпреодоления сложности. Мы абстрагируемся от нее. Будучи не в состоянии полностью воссоздатьсложный объект, мы просто игнорируем не слишком важные детали и, таким образом, имеем делос обобщенной, идеализированной моделью объекта» [36]. Например, изучая процесс фотосинтезау растений, мы концентрируем внимание на химических реакциях в определенных клетках листаи не обращаем внимание на остальные части — черенки, жилки и т. д.