Специфицирование интерфейсов

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

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

Рис. 9.4. Объекты интерфейсов подсистем

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

Алгебраический подход первоначально был разработан для описания интерфейсов аб­страктных типов данных, где типы данных определяются скорее спецификациями опера­ций над данными, чем способом представления самих данных. Это очень похоже на опре­деление классов объектов. Алгебраический подход к формальным спецификациям определяет абстрактный тип данных в терминах операций над данными.

Спецификация поведения систем

Простые алгебраические методы, описанные в предыдущем разделе, подходят для описания интерфейсов, когда операции, ассоциированные с объектом, не зависят от со­стояния объекта. Тогда результаты любой операции не зависят от результатов предыду­щих операций. Если это условие не выполняется, алгебраические методы могут стать гро­моздкими. Более того, я думаю, что алгебраические описания поведения систем часто искусственны и трудны для понимания.

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

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

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

1. Структурирование системы. Программная система структурируется в виде совокуп­ности относительно независимых подсистем. Также определяются взаимодействия между подсистемами.

2. Моделирование управления. Разрабатывается базовая модель управления взаимоотно­шениями между частями системы.

3. Модульная декомпозиция. Каждая определенная на первом этапе подсистема разбива­ется на отдельные модули. Здесь определяются типы модулей и типы их взаимосвя­зей.

Как правило, эти этапы перемежаются и накладываются друг на друга. Этапы повторя­ются для все более детальной проработки архитектуры до тех пор, пока архитектурный проект не будет удовлетворять системным требованиям.

Четких различий между подсистемами и модулями нет, но, думаю, будут полезными следующие определения.

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

2. Модуль— это обычно компонент системы, который предоставляет один или несколько сервисов для других модулей. Модуль может использовать сервисы, поддерживаемые другими модулями. Как правило, модуль никогда не рассматривается как независимая система. Модули обычно состоят из ряда других, более простых компонентов.