8.6 Записная книжка подсистемы

Чтобы удовлетворить потребноcти как аналитиков, так и рецензентов подсистемы, мы рекомендуем создать отдельную записную книжку подсистемы для каждой подсистемы или маленького домена. Записная книжка подсистемы содержит рабочие продукты ООА, расположенные в направлении вниз по столбцам проектной матрицы. Рисунок 8.6.1 показывает содержание типичной записной книжки подсистемы.

Записная книжка подсистемы <xyz>

Содержание

Часть 1 Контекст подсистемы

1.1 Контекст для просмотра подсистемы <xyz>

1.2 Схема доменов

1.3 Описание мостов и их роли

1.4 Проектная матрица

1.5 Описание подсистемы <xyz>

1.6 Модель связей подсистем

1.7 Модель взаимодействия подсистем

1.8 Модель доступа к подсистемам

Часть 2 Информационная модель

2.1 Информационная модель <xyz>

2.2 Описания объектов и атрибутов <xyz>

2.3 Описания связей <xyz>

Часть 3 Модели состояний

3.1 Модель взаимодействия объектов <xyz>

3.2 Модели состояний <xyz>

3.3 Список событий <xyz>

Часть 4 Модели процессов

4.1 Модель доступа к объектам <xyz>

4.2 Таблица процессов состояний <xyz>

4.3 Диаграммы потоков данных действий <xyz>

4.4 Описания процессов <xyz>

Приложения

АА. Список мелких недоделок

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

Рис. 8.6.1. Содержание записной книжки подсистемы.

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

Считая, что записная книжка подсистемы используется для существенных формальных просмотров, касающихся заказчика 1, мы зарезервировали первую позицию в записной книжке для сообщений рецензентам. Содержание и уровень формализованности этого документа в большой степени зависят, от условий при которых разрабатывается система. В прошлых проектах мы использовали этот документ для ознакомления рецензента с OОA, для предупреждения заказчика о проблемах, с которыми мы столкнулись при сборе информации в его организации, и для записи основных положений, на которых основывается проект (Например: «Мы считали, что такие-то датчики будут установлены и будут действовать до развертывания системы").

2, 3 и 4-я части записной книжки содержат стандартные рабочие продукты ООА. Если Вы пожелаете включить схемы каналов управления, вставьте их как пункт 3.4. Чрезвычайно детализированные результаты выполнений имитаций, вероятно, лучше расположить как приложения.

Последний раздел записной книжки подсистемы резервируется для детализированного материала, обеспечивающего поддержку для формализованных моделей ООА. Включите сюда все частные существенные технические замечания*, бланки данных и т.п. И наконец, обратите внимание на первый пункт в списке приложений: Список мелких недоделок. Мы используем этот документ для записи остающихся неразрешенными вопросов, незначительных исправлений, которые следует сделать (Например: "Платформа.Пассажирская Станция - вспомогательный атрибут и должен быть обозначен как R8 на графической модели".). Список мелких недоделок обычно модифицируется раз в неделю или раз в две недели. Поскольку это рабочий документ В1гутреннего пользования, Вы можете, если захотите, переместить его в начало записной книжки.

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