МЕТОДЫ ПРОЕКТИРОВАНИЯ.docx

МЕТОДЫ ПРОЕКТИРОВАНИЯ

Разработка методов проектирования систем программного обеспечения является основным предметом поиска в области технологии разработки программного обеспечения. В этом разделе мы рассмотрим несколько разработанных ранее методов и познакомимся с направлениями текущих исследований.

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

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

В противоположность этому методу проектирования, при восходящем методе проектирование системы начинается с определения отдельных задач внутри системы. Затем изучается, как решение этих задач может использоваться в качестве абстрактных инструментов для решения более общих задач. Многие годы этот подход считался хуже нисходящего метода проектирования. Однако в настоящее время методология восходящего проектирования получила мощную поддержку. Одна из причин этого заключается в том, что нисходящая методология ищет решение, в котором основной модуль использует подмодули, каждый из которых основывается на подмодулях, и т.д. Однако для многих систем наилучший вариант решения лишен подобной иерархической природы. Действительно, при построении приложения по принципам архитектуры "кли- ент/сервер" или использовании методов параллельной обработки проектное решение, в котором два или несколько модулей взаимодействуют как равноправные партнеры, может оказаться более удачным, чем проект, состоящий из управляющего модуля, обращающегося к модулям подпрограмм для решения стоящих перед ним задач.

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

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

ют потоки данных; сплошные линии – источники и приемники данных; кружки указывают, где с данными производятся не- которые действия; а жирные прямые линии отмечают места сохранения данных. В каждом случае символ помечается име- нем представляемого объекта. Схема потоков данных для нашей простой ролевой игры представлена на рис. 6.8.

Рис. 6.8. Диаграмма потоков данных в простой ролевой игре

Метод разработки систем программного обеспечения, основанный на анализе потоков данных, возник в среде императивного программирования. Изначально задача состояла в том, что, отслеживая пути данных в предлагаемой системе, можно обнаружить, где элементы данных сливаются, разделяются или изменяются каким-либо другим образом. В таких местах системы обязательно потребуются те или иные вычислительные действия, которые (взятые по отдельности или сгруппированные) позволят образовать процедурные модули системы. Следовательно, изучение потоков данных поможет определить модульную структуру системы.

Хотя разработка метода анализа потоков данных происходила в рамках императивной парадигмы программирования, он нашел широкое применение и в объектно-ориентированной среде. В частности, определение элементов данных в системе помогает выявить необходимые объекты, а определение происходящих с данными изменений – уточнить действия, которые эти объекты должны выполнять.

Еще одним инструментом анализа и проектирования систем программного обеспечения является диаграмма "сущность

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

Прежде всего определим те сущности, которые должны содержаться в системе. Сущность Professor (Профессор) пред- ставляет отдельного преподавателя университета; сущность Student (Студент) – отдельного студента и сущность Class (Заня- тие) – раздел определенного курса. С каждым экземпляром сущности Professor связывается фамилия, адрес, идентификационный номер, оклад и т.д., с каждым экземпляром сущности Student – фамилия, адрес, идентификационный номер, средний балл и т.д., с каждым экземпляром сущности Class – название курса (История 101), семестр и год, аудитория, время проведения и т.д.

Определив присутствующие в создаваемой системе сущности, следует рассмотреть связи, существующие между ними. Прежде всего, заметим, что каждый преподаватель ведет занятия, а каждый студент посещает их. Следовательно, связь меж- ду сущностями Professor и Class можно определить как Teaches (Проводит), а между сущностями Student и Class – как At- tends (Посещает). (Обратите внимание, что сущности обозначаются существительными, а связи между ними – глаголами.)

Рис. 6.9. Пример диаграммы "сущность – связь"

Однако для двух существующих в данном примере связей характерна различная структура. Связь между сущностями Professor и Class имеет тип "один ко многим", поскольку каждый преподаватель проводит несколько различных занятий, однако каждое занятие проводится только одним преподавателем. В противоположность этому, связь между сущностями Student и Class имеет тип "многие ко многим", так как каждый студент посещает несколько занятий и каждое занятие посе- щают несколько студентов. Эта дополнительная информация представлена на рис. 6.9 с помощью стрелок, соединяющих сущности и связи. В частности, одинарная стрелка, направленная в сторону сущности, указывает, что только одна сущность данного вида входит в каждую связь этого типа, тогда как двойная стрелка означает, что в этой связи могут участвовать не- сколько экземпляров данной сущности. Например, одинарная стрелка, направленная на рис. 6.9 в сторону сущности Pro- fessor, означает, что каждое занятие проводит только один преподаватель, в то время как двойная, направленная в сторону

сущности Class от связи Teaches, показывает, что каждый преподаватель может проводить более чем одно занятие.

Можно предположить, что среди различных средств, используемых разработчиками программного обеспечения в про- шлом, диаграммы "сущность – связь" имели больше шансов выжить при переходе к объектно-ориентированным методам. Действительно, определение сущностей является, по сути, определением объектов системы, а классификация связей между ними – первый шаг на пути к определению необходимых связей и взаимодействий этих объектов. Поэтому в традиционной диаграмме "сущность – связь" легко распознать предшественницу диаграммы классов языка UML (рис. 6.4), которая исполь- зуется в объектно-ориентированной среде проектирования.

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

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

Другая цель создания словаря данных – установить в системе необходимое единообразие. Обычно именно за счет соз- дания словаря можно избежать избыточности и противоречивости данных. Например, элемент данных, который в записи складского учета был назван PartNumber, в записях о продажах может получить имя PartId. Кроме того, отдел кадров может использовать элемент Name (Имя) по отношению к сотруднику, в то время как в записи складского учета элемент Name (На- звание) может входить в описание детали.

Наконец, следует упомянуть и CRC (Class-Responsibility-Collaboration – карты взаимодействия классов), которые могут оказаться полезными при проектировании объектно-ориентированных систем. Карта CRC является, в сущности, традицион- ной индексной картой, содержащей описание объекта. Метод использования карт CRC состоит в том, что проектировщик создает карту CRC для каждого объекта предлагаемой системы, а затем использует эти карты для моделирования действий в системе – например, на поверхности рабочего стола или с помощью "театрализованного" эксперимента, в котором каждый член команды проектировщиков играет роль объекта, выполняя все действия именно так, как это предписывается соответст- вующей картой. Такое моделирование используется для обнаружения недостатков в проекте.

Шаблоны проектирования. В своих поисках, предпринимаемых с целью найти способы создания программного обес- печения из готовых компонентов, разработчики программного обеспечения обратились и к области архитектуры. Особый интерес здесь представляет книга Кристофера Александера (Christopher Alexander) и др. "A Pattern Language", в которой опи- сывается набор шаблонов для сообщества архитекторов-проектировщиков. Каждый шаблон состоит из постановки задачи, за которой следует предлагаемое решение. Приведенные задачи в основном универсальны, а предлагаемое решение является обобщенным в том смысле, что оно относится к общей природе задачи, а не к конкретному случаю.

Например, один из шаблонов, названный "Quiet Backs" ("тихие уголки"), предназначен для создания в деловом центре тихих местечек для отдыха. Предлагаемое решение заключается в том, чтобы спроектировать в деловых районах "тихие уголки". В некоторых случаях следует проектировать район вокруг главной улицы, к которой все здания повернуты фасада- ми, обеспечивая, таким образом, тихую сторону на улицах, проходящих позади этих зданий. В других случаях "тихие угол- ки" могут быть получены с помощью парков, рек или соборов.

Важным для нашего обсуждения является то, что в данной работе Александера сделана попытка определить общие за- дачи и предложить типовые шаблоны их решения. Сегодня многие разработчики программного обеспечения пытаются при- менить аналогичный подход к проектированию больших систем программного обеспечения. В частности, исследователи используют шаблоны проектирования в качестве средств создания обобщенных строительных блоков, из которых можно конструировать системы программного обеспечения.

Среда программирования языка Java. Java был бы просто еще одним объектно-ориентированным языком про- граммирования, если бы не имел набора структур, разработанных специально для упрощения процесса программирова- ния на этом языке. Набор этих структур получил общее название "Прикладной программный интерфейс", или API (Ap- plication Program Interface), и является частью набора инструментальных средств языка Java (JDK – Java Development Kit), разработанного компанией Sun Microsystems. Структуры API языка Java включают шаблоны для решения таких задач, как разработка графических интерфейсов пользователя (GUI), работа с аудио- и видеоданными, передача данных через Internet или разработка анимированных Web-страниц. Таким образом, среда программирования языка Java – это прогресс в направлении конструирования программного обеспечения из готовых компонентов.

Примером такого шаблона является Publisher – Subscriber (Издатель – Подписчик), состоящий из модуля (издателя), ко- торый должен посылать копии своих "публикаций" другим модулям (подписчикам), как показано на рис. 6.10. Как частный случай рассмотрим группу данных, которые изображаются на экране компьютера одновременно в нескольких форматах, например в виде круговой диаграммы и гистограммы. В этом случае любое изменение данных должно быть отражено сразу в обоих форматах. Следовательно, модули программного обеспечения, отвечающие за построение диаграмм, должны опо- вещаться об изменении данных. В данном случае модуль программного обеспечения, управляющий данными, выполняет роль издателя, посылающего сообщения о произошедших изменениях сразу всем его подписчикам, т.е. модулям, отвечаю- щим за построение диаграмм.

Рис. 6.10. Шаблон Publisher – Subscriber

Рис. 6.11. Шаблон Container – Component

Еще одним примером шаблона проектирования программного обеспечения является Container – Component (Контейнер

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

После того как структура шаблонов, подобных Publisher – Subscriber или Container – Component, будет определена, раз- работчики программного обеспечения выполняют разработку каркасных программных элементов, называемых структура- ми, в которых реализуются основные особенности решений, предлагаемых шаблонами. Тогда как реализация специфических функций, присущих конкретным приложениям, откладывается на более поздний срок за счет организации соответствующих слотов, подлежащих заполнению конкретными значениями. Как дополнение к структурам, разработчики программного обеспечения обычно предлагают документацию, описывающую, как следует заполнять эти структуры в целях получения завершенной реализации положенного в ее основу шаблона в рамках конкретной разработки. Такую документацию называют рецептом, поэтому подборки структур вместе с их рецептами шутливо именуют кулинарными книгами.

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

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

Вопросы для самопроверки

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

2.    Нарисуйте диаграмму "сущность – связь", представляющую авиационные компании; полеты, выполняемые каждой компанией; и пассажиров различных рейсов.

3.    Приведите примеры некоторых программных структур, обсу-ждаемых в предыдущих главах, которые можно рас- сматривать в качестве шаблонов проектирования.

4.    Какую роль, как надеются исследователи, будут играть структуры в процессе создания программного обеспечения в будущем?