Смысл проектирования
В любой инженерной дисциплине под проектированием обычно понимается некий унифицированный подход, с помощью которого мы ищем пути решения определенной проблемы, обеспечивая выполнение поставленной задачи. В контексте инженерного проектирования Мостов определил цель проектирования как создание системы, которая
"удовлетворяет заданным (возможно, неформальным) функциональным спецификациям;
согласована с ограничениями, накладываемыми оборудованием;
удовлетворяет явным и неявным требованиям по эксплуатационным качествам и ресурсопотреблению;
удовлетворяет явным и неявным критериям дизайна продукта;
удовлетворяет требованиям к самому процессу разработки, таким, например, как продолжительность и стоимость, а также привлечение дополнительных инструментальных средств" [40].
По предположению Страуструпа: "Цель проектирования - выявление ясной и относительно простой внутренней структуры, иногда называемой архитектурой... Проект есть окончательный продукт процесса проектирования" [41]. Проектирование подразумевает учет противоречивых требований. Его продуктами являются модели, позволяющие нам понять структуру будущей системы, сбалансировать требования и наметить схему реализации.
Важность построения модели. Моделирование широко распространено во всех инженерных дисциплинах, в значительной степени из-за того, что оно реализует принципы декомпозиции, абстракции и иерархии [42]. Каждая модель описывает определенную часть рассматриваемой системы, а мы в свою очередь строим новые модели на базе старых, в которых более или менее уверены. Модели позволяют нам контролировать наши неудачи. Мы оцениваем поведение каждой модели в обычных и необычных ситуациях, а затем проводим соответствующие доработки, если нас что-то не удовлетворяет.
Как мы уже сказали выше, чтобы понять во всех тонкостях поведение сложной системы, приходится использовать не одну модель. Например, проектируя компьютер на одной плате, инженер-электронщик должен рассматривать систему как на уровне отдельных элементов схемы (микросхем), так и на уровне схемы.
Схема помогает инженеру разобраться в совместном поведении микросхем. Схема представляет собой план физической реализации системы микросхем, в котором учтены размер платы, потребляемая мощность и типы имеющихся интегральных микросхем. С этой точки зрения инженер может независимо оценивать такие параметры системы, как температурное распределение и технологичность изготовления. Проектировщик платы может также рассматривать динамические и статические особенности системы. Аналогично, инженер-электронщик использует диаграммы, иллюстрирующие статические связи между различными микросхемами, и временные диаграммы, отражающие поведение элементов во времени. Затем инженер может применить осциллограф или цифровой анализатор для проверки правильности и статической, и динамической моделей.
Элементы программного проектирования. Ясно, что не существует такого универсального метода, "серебряной пули" [43], который бы провел инженера-программиста по пути от требований к сложной программной системе до их выполнения. Проектирование сложной программной системы отнюдь не сводится к слепому следованию некоему набору рецептов. Скорее это постепенный и итеративный процесс. И тем не менее использование методологии проектирования вносит в процесс разработки определенную организованность. Инженеры-программисты разработали десятки различных методов, которые мы можем классифицировать по трем категориям. Несмотря на различия, эти методы имеют что-то общее. Их, в частности, объединяет следующее:
условные обозначения - язык для описания каждой модели;
процесс - правила проектирования модели;
инструменты - средства, которые ускоряют процесс создания моделей, и в которых уже воплощены законы функционирования моделей. Инструменты помогают выявлять ошибки в процессе разработки.
Хороший метод проектирования базируется на прочной теоретической основе и при этом дает программисту известную степень свободы самовыражения.
Объектно-ориентированные модели. Существует ли наилучший метод проектирования? На этот вопрос нет однозначного ответа.
По сути дела это завуалированный предыдущий вопрос: "Существует ли лучший способ декомпозиции сложной системы?" Если и существует, то пока он никому не известен. Этот вопрос можно поставить следующим образом: "Как наилучшим способом разделить сложную систему на подсистемы?" Еще раз напомним, что полезнее всего создавать такие модели, которые фокусируют внимание на объектах, найденных в самой предметной области, и образуют то, что мы назвали объектно-ориентированной декомпозицией.
Объектно-ориентированный анализ и проектирование - это метод, логически приводящий нас к объектно-ориентированной декомпозиции. Применяя объектно-ориентированное проектирование, мы создаем гибкие программы, написанные экономными средствами. При разумном разделении пространства состояний мы добиваемся большей уверенности в правильности нашей программы. В итоге, мы уменьшаем риск при разработке сложных программных систем.
Так как построение моделей крайне важно при проектировании сложных систем, объектно-ориентированное проектирование предлагает богатый выбор моделей, которые представлены на рис. 1-4. Объектно-ориентированные модели проектирования отражают иерархию и классов, и объектов системы. Эти модели покрывают весь спектр важнейших конструкторских решений, которые необходимо рассматривать при разработке сложной системы, и таким образом вдохновляют нас на создание проектов, обладающих всеми пятью атрибутами хорошо организованных сложных систем.
В главе 5 подробно рассмотрен каждый из четырех типов моделей. В главе 6 описан процесс объектно-ориентированного проектирования, представляющий собой цепь последовательных шагов по созданию и развитию моделей. В главе 7 рассмотрена практика управления процессом объектно-ориентированного проектирования.
В этой главе мы привели доводы в пользу применения объектно-ориентированного анализа и проектирования для преодоления сложности, связанной с разработкой программных систем. Кроме того, мы определили ряд фундаментальных преимуществ, достигаемых в результате применения такого подхода.
Прежде чем мы представим систему обозначений и процесс проектирования, мы должны изучить принципы, на которых этот процесс проектирования основан: абстрагирование, инкапсуляцию, модульность, иерархию, типизацию, параллелизм и устойчивость.
Рис. 1-4. Объектно-ориентированные модели.
Выводы
Программам присуща сложность, которая нередко превосходит возможности человеческого разума.
Задача разработчиков программных систем - создать у пользователя разрабатываемой системы иллюзию простоты.
Сложные структуры часто принимают форму иерархий; полезны обе иерархии: и классов, и объектов.
Сложные системы обычно создаются на основе устойчивых промежуточных форм.
Познавательные способности человека ограничены; мы можем раздвинуть их рамки, используя декомпозицию, выделение абстракций и создание иерархий.
Сложные системы можно исследовать, концентрируя основное внимание либо на объектах, либо на процессах; имеются веские основания использовать объектно-ориентированную декомпозицию, при которой мир рассматривается как упорядоченная совокупность объектов, которые в процессе взаимодействия друг с другом определяют поведение системы.
Объектно-ориентированный анализ и проектирование - метод, использующий объектную декомпозицию; объектно-ориентированный подход имеет свою систему условных обозначений и предлагает богатый набор логических и физических моделей, с помощью которых мы можем получить представление о различных аспектах рассматриваемой системы.
Дополнительная литература
Проблемы, связанные с развитием сложных программных систем, были отчетливо описаны в классических работах Брукса (Brooks) [Н 1975] и [Н 1987]. В работах Гласса (Glass) [Н 1982], Defense Science Board [Н 1987], и Joint Service Task Force [Н 1982] можно найти более свежую информацию о современной практике программирования. Эмпирические исследования природы и причин программистских неудач можно найти в работах ван Генучтена (van Genuchten) [Н 1991], Гвиндона (Guindon) и др. [Н 1987], Джонса (Jones) [H1992].
Работы Саймона (Simon) [A 1962,1982] - богатый источник сведений об архитектуре сложных систем. Куртуа (Courtois) [A 1985] применил эти идеи к области программного обеспечения. Плодотворная работа Александера (Alexander) [I 1979] предлагает свежий подход к архитектуре. Питер (Peter) [I 1986] и Петроски (Petroski) [11985] изучали сложность в контексте соответственно социальных и физических систем. Аллен и Стар (Alien and Starr) [A 1982] изучали иерархические системы в ряде предметных областей. Флуд и Кэрсон (Flood and Carson) [A 1988] предприняли формальное исследование сложности сквозь призму теории систем. Волдрап (Waldrop) [A 1992] описал возникающую науку о сложности и ее использование при изучении больших адаптивных систем, возникающего поведения и самоорганизации. Отчет Миллера (Miller) [A 1956] дает эмпирические свидетельства фундаментальных ограничивающих факторов человеческого сознания.
По проектированию программного обеспечения есть ряд замечательных ссылок. Росс, Гудинаф и Ирвайн (Ross, Goodenough, and Irvine) [Н 1980], а также Зелковитс (Zeikowitz) [Н 1978] - это две классические работы, суммирующие существенные элементы проектирования. Более широкий круг работ по этому предмету включает: Дженсен и Тонис (Jensen and Tonies) [Н 1979], Саммервиль (Sommerville) [Н 1985], Вик и Рамамурти (Vick and Ramamourthy) [Н 1984], Вегнер (Wegner) [Н 1980], Пресман (Pressman) [Н 1992], Оман и Льюис (Oman and Lewis) [A 1990], Берзинс и Луки (Berzins and Luqi) [Н 1991] и Hг и Йeн(NgandYen) [Н 1990]. Другие статьи, касающиеся проектирования программного обеспечения , можно найти в Йордон (Yourdon) [Н 1979] и Фриман и Вассерман( Freeman and Wasserman)[H 1993]. Две работы, Грэхема (Graham) [F 1991] и Берарда (Berard) [Н 1993], предлагают широкое истолкование объектно-ориентированного проектирования.
Глейк (Gleik) [I 1987] предложил легко читаемое введение в хаосоведение.
