6.5 Инструменты проектирования
В области разработки программного обеспечения было создано большое количество систем представления для облегчения системного анализа и процесса проектирования. Мы уже обсуждали блок-схемы, диаграммы классов и диаграммы взаимодействия. Существует еще схема информационных потоков (dataflow diagram), которая отображает пути прохождения данных в системе. На схеме информационных потоков изображается источник, место назначения и пункты обработки данных в системе. Все символы на такой диаграмме имеют точное значение: стрелками обозначаются пути прохождения данных, жирными линиями — источники и приемники данных, окружностями — пункты обработки данных, жирными вертикальными линиями — устройства для хранения данных. В каждом случае рядом с обозначением помещается название представляемого им элемента. Схема информационных потоков фрагмента системы заказа товаров через Интернет показана на рис. 6.10.
Подход к процессу разработки программного обеспечения с точки зрения потоков данных появился в рамках императивной парадигмы программирования. Идея заключалась в том, что, отслеживая потоки данных, мы можем понять, где единицы данных объединяются, разделяются или изменяются каким-либо другим образом. Поскольку в таких местах системы необходимо выполнение каких-либо действий над данными, в них должны находиться процедурные модули.
Хотя анализ информационных потоков разрабатывался для императивной парадигмы программирования, он также находит применение в объектно-ориентированном программировании. В частности, определение элементов данных системы помогает определить ее объекты, а определение операций над данными — действия, которые эти объекты должны выполнять.
Другой инструмент, применяемый при анализе и проектировании систем программного обеспечения, — схема отношений между информации!тыми объектами (entity-relationship diagram), которая отображает элементы информации системы и отношения между ними. Рассмотрим в качестве примера часть диаграммы отношений между информационными объектами системы, хранящей информацию о преподавателях, студентах и лекционных курсах университета.
Прежде всего, определим информационные объекты нашей системы. Объект Преподаватель представляет отдельного преподавателя университета. Объект Студент представляет отдельного студента университета. И объект Предмет представляет отдельный лекционный курс. С каждым экземпляром объекта Преподаватель связаны имя, адрес, идентификационный номер сотрудника университета, зарплата и т. д. С каждым экземпляром объекта Студент связаны имя, адрес, идентификационный номер студента, средний балл и т. д. С каждым экземпляром объекта Предмет связаны идентификационный номер предмета (например, история 101), семестр и год, аудитория, время и т. д.
Определив объекты системы, можно приступить к рассмотрению отношений между ними. Прежде всего, заметим, что каждый преподаватель читает лекции, а каждый студент посещает лекции. Следовательно, между объектами Преподаватель и Предмет существует отношение Преподает, а между объектами Студент и Предмет существует отношение Посещает. (Обратите внимание на то, что названия объектов представлены существительными, а названия отношений между объектами представлены глаголами.)
Для наглядного изображения этих объектов и отношений между ними используется схема отношений между объектами (рис. 6.11), на которой объекты представлены в виде прямоугольников, а отношения — в виде ромбов. Диаграмма показывает, что преподаватели связаны с предметами отношением Преподает, а студенты с предметами — отношением Посещает.
Однако двум отношениям из нашего примера соответствуют разные структуры. Отношение между объектами Преподаватель и Предмет является отношением типа «один ко многим», поскольку каждый преподаватель может читать несколько лекционных курсов, но каждый лекционный курс может читаться только одним преподавателем. А отношение между объектами Студент и Предмет является отношением типа «многие ко многим», так как каждый студент может посещать несколько лекций и каждую лекцию посещают несколько студентов. Существует три основных типа отношений между объектами: «один к одному», «один ко многим» (или «многие к одному», в зависимости от точки зрения) и «многие ко многим» (рис. 6.12). Мы уже сталкивались с отношением «один к одному» (см. рис. 6.6), где каждый покупатель связан только с одним бланком заказа и каждый заказ связан только с одним покупателем. В качестве примера отношений «один ко многим» и «многие ко многим» можно привести отношение между авторами и книгами. С одной стороны, отношение между автором и романом является отношением типа «один ко многим», так как писатель может написать несколько романов, а роман имеет только одного автора. С другой стороны, отношение между авторами учебника и учебником является отношением типа «многие ко многим», так как учебник обычно имеет несколько авторов.
На диаграмме отношений между объектами тип отношений обычно обозначается количеством стрелок, соединяющих объекты. Например, одна стрелка по направлению к объекту означает, что только один объект данного типа связан данным отношением, а двойная стрелка означает, что два и больше объекта данного типа связаны отношением. Таким образом, стрелка, входящая в объект Преподаватель (см. рис. 6.11) показывает, что курс может читать только один преподаватель, а двойная стрелка, направленная к объекту Предмет в отношении Преподает, показывает, что каждый преподаватель может читать лекции по нескольким предметам.
Среди разных инструментов, применяемых разработчиками программного обеспечения, схемы отношений между объектами имеют самую большую вероятность пережить переход к объектно-ориентированным методам разработки, поскольку традиционная диаграмма отношений между объектами является предшественником диаграммы классов языка UML (см. рис. 6.4), используемого при разработке программ в объектно-ориентированной среде.
Еще один инструмент разработки программного обеспечения — словарь данных (data dictionary), представляет собой базу данных, содержащую информацию обо всех элементах данных системы. Словарь данных включает в себя идентификатор каждого элемента; содержимое каждого элемента (будет ли элемент всегда числовым или буквенным, какие значения можно будет присвоить этому элементу); где этот элемент будет храниться (будет ли он храниться в файле или базе данных, если да, то в какой); где в системе этот элемент используется (какому модулю требуется этот элемент информации).
Словарь данных создается по нескольким причинам. Прежде всего он улучшает взаимодействие между потенциальным пользователем системы и системным аналитиком, ответственным за преобразование потребностей пользователя в технические требования к системе и техническое описание системы. Было бы неприятно уже после реализации системы обнаружить, что номера изделий вовсе не являются числами, а размер инвентарной ведомости превышает максимальный размер, допустимый системой. Создание словаря данных помогает избежать подобных недоразумений.
Также словарь данных необходим для обеспечения единообразия программной системы. С помощью словаря выявляется наличие противоречий и избыточных данных в системе. Например, элемент PartNumber в инвентарной ведомости может означать то же, что элемент Part Id при учете продаж. Кроме того, отдел кадров может использовать элемент Name по отношению к служащим, а при учете продаж этот элемент может применяться по отношению к изделию.
Наконец, следует упомянуть CRC-карточки (class-responsibility-collaboration — класс-ответственность-сотрудничество), которые применяются при разработке объектно-ориентированных систем программного обеспечения. CRC-карточка, в сущности, является обычной учетной карточкой, на которую заносится описание объекта. При использовании этой методики разработчик создает карточку для каждого объекта будущей системы и использует их для имитации действий системы, например на рабочем столе или в ходе эксперимента, когда каждый член проектной группы выполняет действия определенного объекта, описанного в соответствующей карточке. Такая имитация системы помогает выявить некоторые недостатки системы еще до ее реализации.