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

Рамка подсистемы на модели взаимодействии подсистем (MBП) представляет собой модель взаимодействия объектов для частной подсистемы. Если модель состояний и одной подсистеме порождает событие, которое принимается моделью состояний и другой, то рисуют стрелку из подсистемы, и которой событие порождается, к подсистеме, принимающей его. Обозначают стрелку идентификатором события(й) и, если на диаграмме достаточно места, значением события, как показано на рис. 8.4.3.

Рис.8.4.3. Модель взаимодействия подсистем для домена Работа Железной Дороги.

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

Рамка подсистемы на модели доступа к подсистемам (МДП) представляет собой модель доступа к объектам для одной из подсистем в домене. Если модель состояния в одной подсистеме (А) использует процесс аксессор, определенный для объекта в другой (В), рисуют стрелку из подсистемы А к подсистеме В. Обозначают стрелку идентификаторами аксессора, как показано на рис.8.Л.4.

Рис.8.4.4. Модель доступа к подсистемам для домена Работа Железной Дороги.

8.5 Проектная матрица Что представляет проектная матрица

Проектная матрица [1] - простое представление планирующего и организационного фрейма, обеспечиваемого подсистемами и ООА. В проектной матрице (рис.8.5.1) каждая строка матрицы - это этап в методе ООА и каждый столбец -подсистема. Ячейки, которые образуются пересечением строк и столбцов, представляют собой отдельные модули работы, которую необходимо выполнить. В результате Вы можете связать некоторые информационные сведения с каждой данной рамкой:

• сотрудники, определенные для выполнения работы, представленной ячейкой;

• рабочие продукты, которые должны быть созданы как результат выполнения работы;

• предполагаемые трудозатраты, требуемые для выполнения работы;

• текущее состояние работы: завершена, выполняется, будет проделана;

• ожидаемые даты начала и конца работы;

• трудозатраты, которые действительно потребовались для выполнения работы.

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

Деятельность при анализе

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

Строка информационной модели. Работа, связанная с рамкой в строке информационной модели, подразделяется на несколько отчетливых видов деятельности:

• исследование;

• разработка модели;

• интеграция;

• просмотр.

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

Рис.8.5.1. Проектная матрица для Автоматизированной Системы Управления Железной Дорогой.

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

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

При формировании графика проекта используйте ячейки проектам матрицы как модули планируемой работы

Заполните ее атрибутами и связями, предложенными техническими замечаниями.

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

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

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

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

Строка моделей состояний. Деятельность, связанная с рамкой в строке моделей состояний, - это разработка модели, верификация взаимных действий, интеграция и просмотр.

Разработка модели. Начните работу с моделью состояний эскизной зарисовкой грубой модели взаимодействия объектов для установления иерархического представления объектов, как описано в 5-й главе. Затем формируйте одну за другой модели состояний (ДПС и ТПС) н накапливайте в процессе работы список событий. Может быть, будет необходимо провести некоторые дополнительные исследования, чтобы определить тонкости поведения различных объектов. В таком случае запишите полученные сведения в технические замечания.

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

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

Интеграция. Как только модели состояний н модель взаимодействия объектов завершены, сформируйте (или модифицируйте) модель взаимодействия подсистем для этого домена.

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

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

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

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