12. Модели по используемые на этапе определения спецификаций

Формальные модели, используемые на этапе определения спецификаций можно разделить на две группы: модели, зависящие от подхода к разработке (структурного или объектно-ориентированного), и модели, не зависящие от него. Так диаграммы переходов состояний, которые демонстрируют особенности поведения разрабатываемого программного обеспечения при получении тех или иных сигналов извне (см. § 4.2), и математические модели предметной области (см. § 4.6) используют при любом подходе к разработке.

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

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

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

12. Модули и их свойства

Модуль - автономно компилируемая программная единицу. Термин «модуль» используется в двух смыслах. Первоначально, когда размер программ был невелик, и все подпрограммы компилировались отдельно, под модулем понималась подпрограмма, т.е. последовательность связанных фрагментов программы, обращение к которой выполняется по имени. Когда размер программ вырос, и появилась возможность создавать библиотеки ресурсов, термин «модуль» стал использоваться и в смысле автономно компилируемый набор программных ресурсов. Данные модуль может получать и/или возвращать через общие области памяти или параметры.

Первоначально к модулям (подпрограммам) предъявлялись требования: отдельная компиляция; одна точка входа; одна точка выхода; соответствие принципу вертикального управления; возможность вызова других модулей; небольшой размер (50-60 операторов); независимость от истории вызовов; выполнение одной функции.

Когда под модулем стали понимать отдельно компилируемую библиотеку ресурсов, требование независимости модулей стало основным. Чем выше степень независимости модулей, тем:

1. легче разобраться в отдельном модуле и всей программе и, соответственно, тестировать, отлаживать и модифицировать ее;

2. меньше вероятность появления новых ошибок при исправлении старых или внесении изменений в программу, т. е. вероятность появления «волнового» эффекта;

3. проще организовать разработку ПО группой программистов и легче его сопровождать.

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