Проверка правильности внешних спецификаций

Завершение внешнего проектирования является ответственным мо­ментом для всего проекта. Процесс внешнего проектирования и предшест­вующие процессы концентрировались вокруг взаимодействия системы и пользователя; остальные процессы проектирования касаются внутренней структуры программного обеспечения. По этой причине проверка их пра­вильности приобретает исключительное значение.

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

Имеется шесть методов проверки правильности, применимых к внешним спецификациям. Эти методы не исключают друг друга, и реко­мендуется применять их все.

1. Контроль по правилу «n плюс-минус один».

2. Контроль со стороны пользователя.

3. Таблицы решений. Если в спецификациях имеются таблицы реше­ний, можно применить автоматизированные методы поиска ошибок.

4. Ручная имитация. Эффективный прием проверки – подготовить тесты и затем воспользоваться детальными внешними спецификациями для имитации поведения системы.

5. Имитация за терминалом. Вместо того чтобы просто читать список тестов, как в предыдущем случае, человек садится за терминал. Для ими­тации системы еще один участник проверки, вооружившись специфика­циями, садится за другой терминал. Особая небольшая программа связы­вает терминалы, передавая сообщения от «пользователя» к «имитатору» и обратно.

6. Функциональные диаграммы. Спецификации представляются в другой форме – в форме бинарной логической диаграммы. Главное их на­значение – служить основой для строгого построения тестов, однако, по­скольку при построении диаграмм проводится детальный анализ специфи­каций, функциональные диаграммы полезно построить уже на этом этапе.

3.2.5. Проектирование архитектуры программы

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

Традиционный метод борьбы со сложностью – принцип «разделяй и властвуй», часто называемый «модуляризацией». На практике, однако, этот подход часто не приводит к ожидаемому уменьшению сложности. В [7] указано три причины подобной неудачи:

1. Модули выполняют слишком много связанных, но различных функций – это делает их логику запутанной.

2. При проектировании остались невыявленными общие функции, вследствие чего они рассредоточены (и по-разному реализованы) в разных модулях.

3. Модули взаимодействуют посредством совместно используемых или общих данных самым неожиданным образом.

Методология проектирования, называемая композиционным проек­тированием [11], – это принцип проектирования, рассматриваемый здесь на примере проектирования структуры программы. Композиционное про­ектирование состоит, по существу, из двух компонент: системы явных проектных оценок, позволяющих решить все три перечисленные выше проблемы и еще целый ряд дополнительных проблем, и ряда мыслитель­ных процессов, обеспечивающих разбиение программы на множество мо­дулей, их сопряжений и отношений. В результате композиционного проек­тирования достигается минимальная сложность структуры программы. Та­кую программу легче понимать, сопровождать и адаптировать.