Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ТППС / ТППС_лаб_2012-рус.docx
Скачиваний:
90
Добавлен:
05.06.2015
Размер:
1.11 Mб
Скачать

Моделирование взаимодействий

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

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

Диаграммы взаимодействий разделяются на два вида - диаграммы последовательно­стей и диаграммы кооперации. Они могут использоваться как взаимозаменяемые, и, ко­нечно, многие CASE-средства поддерживают автоматическое преобразование одной модели в другую. Разница между моделями заключается в акцентах. Модели последова­тельностей концентрируются на временных последовательностях событий, а в моделях кооперации основное внимание уделяется отношениям между объектами.

Взаимодействия

Взаимодействие (interaction) представляет собой набор сообщений, свойственных поведению некоторой системы, которыми обмениваются объекты ъ соответствии с установленными между ними связями (последние могут быть постоянными или времен­ными (Диаграмма последовательностей представляется двумерным графом. Объекты располагаются по горизонтали. Последовательности сообщений располагаются сверху вниз по вертикали. Каждая вертикальная линия называется ли­нией жизни (lifeline) объекта.

Стрелки представляют каждое сообщение, направляемое от вызывающего объекта (отправителя) к операции (методу) вызываемого объекта (получателя). Для каждого сообщения, как минимум, указывается его имя. Кроме того, для сообщения могут быть указаны фактические аргументы сообщения и другая управляющая информа­ция. Фактические аргументы соответствуют формальным аргументам метода объекта-получателя.

Фактические аргументы могут быть входными аргументами (передаются от отправителя к получателю) или выходными аргументами (передаются от получателя назад к отправите­лю). Входные аргументы могут быть обозначены ключевым словом in (если ключевое слово отсутствует, то предполагается, что аргумент - входной). Выходные аргументы обо­значаются ключевым словом out. Допускаются также аргументы типа inout ("входные-выходные"), однако, для объектно-ориентированного подхода они не характерны. Сооб­щение getCourseName, отправленное объекту, обозначенному пере­менной crs_ref, имеет один выходной аргумент и ни одного входного:

crs_ref.getCourseName(out crs_name)

Показывать на диаграмме возврат управления от объекта-получателя объекту-отправителю не обязательно. Стрелка, указывающая на объект-получатель, предпола­гает автоматический возврат управления отправителю. Получатель знает уникальный идентификатор объекта (OID) отправителя.

Сообщение может быть отправлено коллекции (collection) объектов (коллекция мо­жет быть набором, списком, массивом объектов и т.д.). Довольно частой является си­туация, когда вызывающий объект связан с несколькими объектами-получателями (поскольку кратность ассоциации указана как "один ко многим" или "многие ко мно­гим"). Итеративный маркер- звездочка перед обозначением сообщения - указывает на процесс итерации сообщения по всей коллекции.

Задание:

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

Предоставить отчет, содержащий результаты проведенного планирования и результаты моделирования системы.

Контрольные вопросы:

1.   Реинжиниринг бизнес - процессов (BPR) проводит ясное различие между бизнес - процессом и бизнес - функцией. В чем заключается это различие? Приведите пример бизнес - процесса, который разорван по горизонтали по всей организации.

2.   Почему понимание метода ISA (архитектура информационной системы) важно для системной разработки?

3.   Объясните разницу между этапами определения требований и разработки спецификации.

4.   Объясните взаимосвязь двух этапов проектирования (архитектурное проектирование и детализированное проектирование) с первыми двумя этапами жизненного цикла - этапом определения требований и этапом разработки спецификации.

5.   Каковы основные причины сдвига от структурного подхода к проектированию объектно - ориентированном?

Соседние файлы в папке ТППС