Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
прис_ЛР_4.doc
Скачиваний:
0
Добавлен:
01.05.2025
Размер:
180.74 Кб
Скачать

Лабораторная работа № 4

Тема: изучение методики построения диаграмм последовательности (sequence diagram) и диаграмм сотрудничества (collaboration diagram) по задаче.

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

Порядок выполнения лабораторной работы

Лабораторная работа №4 выполняется на основе материалов лабораторной работы №2, №3, в которых выбран вариант моделирования процессов по выбранному прецеденту (бизнес прецеденты или системные прецеденты) и построены диаграммы классов объектов. По каждому классу выделены свойства и методы. В лабораторной работе №4 необходимо построить модели последовательности обработки

  1. Проанализировать диаграмму классов и при необходимости дополнить диаграмму классов технологическими классами, обеспечивающими реализацию алгоритма рассматриваемого прецедента.

  2. Сформировать номенклатуру сообщений, которыми обмениваются классы между собой (информационная модель класса).

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

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

  5. Построить диаграмму последовательности по выбранному прецеденту.

  6. Построить диаграмму сотрудничества (кооперации) по выбранному прецеденту.

  7. Провести анализ параллельности обработки сообщений в классах

Содержание отчёта по лабораторной работе

  1. Краткая характеристика рассматриваемого прецедента.

  2. Назначение и цели построения диаграмм последовательности и кооперации.

  3. Спецификация классов, свойств и методов по выбранному прецеденту

  4. Спецификация сообщений при взаимодействии классов.

  5. Диаграмма последовательности.

  6. Логическое обоснование последовательности работы классов..

  7. Диаграмма сотрудничества..

  8. График Ганта работы классов, построенный по диаграмме сотрудничества.

  9. Выводы по построенным моделям.

Методические указания

Язык UML предназначен для моделирования технологических процессов в предметной области. Он должен предоставлять возможность отражать конструкцию и технологию на объекте автоматизации. Фактически UML является инструментом для моделирования предметной области и может использоваться для отражения текущего состояния моделируемого технологического процесса и построения перспективной реализации технологического процесса. Его могут использовать и специалисты в других областях деятельности для отражения специфики процессов, протекающих в их области деятельности.

В языке UML можно построить следующие виды диаграмм:

  1. диаграмма сценариев (Use Case diagram);

  2. диаграмма классов (Class diagram);

  3. диаграмма активности (Activity diagram);

  4. диаграмма состояний (State diagram);

  5. Диаграммы взаимодействия (Interaction diagram);

    1. Диаграмма последовательности (Sequence diagram);

    2. Диаграмма сотрудничества (Collaboration diagram);

  6. диаграмма компонент (Component diagram);

  7. диаграмма развёртывания (Deployment diagram).

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

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

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

диаграммы последовательностей используются на этапе анализа требований,

диаграммы кооперации — системного проектирования.

Этот выбор соответствует общепринятой практике разработки ИС.

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

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

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

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

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

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

Диаграмма последовательностей для "отображения текущей конфигурации" показана на рис. 4.1. Внешний субъект— клиент— (Customer) принимает решение об отображении конфигурации компьютера. Сообщение openNew (открыть новое [окно]) отправляется объекту ConfWin класса ConfigurationWindow ([диалоговое] окно конфигурации). В результате создается ("материализуется как экземпляр") новый объект ConfWin. (Класс ConfigurationWindow— пограничный класс (разд. 2.2.4.1).)

Рис. 4.1. Диаграмма последовательностей для вида деятельности Display Current Configuration ( Internet магазин)

Объекту ConfWin необходимо "отобразить себя" вместе с данными, относящимися к конфигурации. С этой целью он отправляет сообщение объекту aComp: Computer. В действительности, aComp — это объект класса StandardComputer или ConfiguredComputer. Класс Computer — абстрактный класс.

Объект aComp использует выходной аргумент для того, чтобы "собрать себя" из элементов конфигурации — объектов ConfigurationItem. Затем он "оптом" отсылает элементы конфигурации объекту aConfWin в качестве аргумента i_recset сообщения displayComputer. Теперь объект aConfWin может отобразить себя. На экране компьютера выводится изображение выбранной конфигурации компьютера.

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

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