Инструменты проектирования

В области разработки программного обеспечения было создано большое количество систем представления для облегчения системного анализа и процесса проектирования. Мы уже обсуждали блок-схемы, диаграммы классов и диаграммы взаимодействия. Существует еще схема информационных потоков (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-карточка, в сущности, является обычной учетной карточкой, на которую заносится описание объекта. При использовании этой методики разработчик создает карточку для каждого объекта будущей системы и использует их для имитации действий системы, например на рабочем столе или в ходе эксперимента, когда каждый член проектной группы выполняет действия определенного объекта, описанного в соответствующей карточке. Такая имитация системы помогает выявить некоторые недостатки системы еще до ее реализации.

Тестирование

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

С другой стороны, разработчики программного обеспечения создали методы тестирования, которые с достаточно большой вероятностью позволяют обнаружить ошибки в программе. Одна из методик основывается на наблюдении, что ошибки в программном обеспечении имеют свойство скапливаться в одном месте. То есть опыт показывает, что некоторые модули большой системы содержат больше ошибок, чем другие модули. Поэтому, определив эти модули и проверив их более тщательно, чем остальные, можно выявить больше ошибок, чем если проверять все модули достаточно тщательно, но одинаковым образом. Это пример применения принципа Парето (Pareto principle), названного в честь итальянского социолога и экономиста Вильфредо Парето (Vilfredo Pareto, 1848-1923), который заметил, что небольшая часть населения Италии контролирует большую часть богатства страны. В общем, принцип Парето говорит о том, что часто можно достичь больших результатов, если прикладывать усилия в ограниченном пространстве.

Другой метод тестирования называется тестированием базового пути (basis path testing). В этом случае создается набор контрольных данных, которые бы подтверждали, что каждая команда программы выполняется по меньшей мере один раз. Для определения контрольных данных была разработана методика, в которой используется теория графов. Хотя при таком способе тестирования и невозможно гарантировать, что были проверены все пути программной системы, однако можно утверждать, что в процессе проверки каждый оператор выполнялся, по крайней мере, один раз.

В методах тестирования, основанных на принципе Парето и проверке базового пути, подразумевается, что нам известно внутреннее строение тестируемой системы. Поэтому эти способы тестирования можно отнести к категории тестирования методом «прозрачного ящика» (glass-box testing), когда человеку, проводящему испытание системы, известно ее строение. В отличие от этого, при тестировании методом «черного ящика» (black-box testing) внутреннее строение системы остается неизвестным. Такое тестирование выполняется с точки зрения пользователя. Основное внимание при этом уделяется не тому, как именно система выполняет задачу, а тому, выполняется ли задача правильно, точно и вовремя.

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

Другой способ тестирования методом «черного ящика» — применение избыточности. Согласно этому подходу разные проектные группы или даже разные компании создают независимо друг от друга две программные системы, выполняющие одинаковые действия. Затем эти две системы проверяются с использованием одних данных и результаты проверки сравниваются. Ошибки определяются по расхождениям результатов тестирования. Этот метод часто используется при проверке космических систем.

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

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

Документация

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

Документация для пакета программ создается обычно по двум причинам. Прежде всего она объясняет свойства программного обеспечения и описывает, как его следует использовать. Такая документация называется пользовательской (user documentation). Поскольку она предназначена для чтения пользователем, она является нетехнической.

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

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

Другая цель создания документации — это описание внутреннего строения системы для обслуживания системы в будущем. Такая документация называется системной (system documentation), она по своей сути является более формальной, чем пользовательская документация. Главной составляющей системной документации являются исходные версии всех программ системы. Важно, чтобы эти программы были представлены в удобочитаемом формате, поэтому разработчики программного обеспечения поддерживают использование языков программирования высокого уровня, комментариев и модульного проектирования, которое позволяет представлять модули как отдельные единицы. Многие компании, создающие программное обеспечение, разработали правила, которых должны придерживаться их сотрудники при написании программ. Они включают в себя правила расположения текста программы на странице, правила наименования констант, переменных, объектов классов и правила написания документации. Эти правила помогают сделать программное обеспечение, создаваемое компанией, единообразным, что значительно облегчает процесс его обслуживания.

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

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

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