Создание логического представления проектируемой системы. Диаграммы взаимодействия

Логическое представление проектируемой системы при помощи CASE-средства Rational Rose. Диаграммы последовательности и коопераций. Рассмотрение понятий "линия жизни" и "фокус управления". Разновидности программных сообщений, доступных в Rational Rose.

Рубрика Программирование, компьютеры и кибернетика
Вид лабораторная работа
Язык русский
Дата добавления 05.06.2015
Размер файла 231,0 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

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

«Создание логического представления проектируемой системы. Диаграммы взаимодействия»

Цели работы:

1. Научиться работать с логическим представлением системы при помощи CASE-средства Rational Rose.

2. Изучить основные сведения о диаграммах взаимодействия UML.

3. Выполнить следующий этап учебного проекта.

Краткие теоретические сведения:

1. Логическое представление проектируемой системы в Rational Rose

Логическое представление (Logical View) проектируемой системы в Rational Rose концентрируется на том, как система будет реализовывать поведение, описанное в вариантах использования. Оно даёт подробную картину составных частей системы и описывает их взаимодействие. С помощью логического представления конструируется детальный проект системы.

Логическое представление содержит:

- классы; rational rose программный диаграмма

- диаграммы классов - как правило, несколько диаграмм, каждая из которых отображает некоторое подмножество всех классов системы;

- диаграммы взаимодействия, отображающие объекты, участвующие в одном пот оке события варианта использования;

- диаграммы состояний;

- пакеты, являющиеся группами взаимосвязанных классов.

Диаграммы взаимодействия UML

Для описания поведения взаимодействующих групп объектов в UML применяются диаграммы взаимодействия (Interaction Diagrams). Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного варианта использования. На диаграммах взаимодействия отображается ряд объектов и те сообщения, которыми они обмениваются между собой.

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

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

- Запрос (Interrogative) - сообщение, запрашивающее выдачу некоторой информации об объекте получателе.

- Императивное (Imperative) - сообщение, запрашивающее у объекта получателя выполнение некоторых действий.

В так называемой нотации Буча сообщением называется спецификация обмена данными между объектами, при котором передается некая информация в расчете на то, что в ответ последует определенное действие, и выделяется 5 видов простых действий:

- call (вызов) - вызов операции, применяемой к объекту, возможен, в том числе, и локальный вызов операции, когда объект посылает сообщение самому себе;

- return (возврат) - возвращение значения вызывающему объекту;

- send (послать) - посылает объекту сигнал;

- create (создать) - создаёт новый объект;

- destroy (уничтожить) - уничтожает объект.

Нотация UML предоставляет несколько видов диаграмм взаимодействия, наиболее распространёнными среди которых являются диаграммы последовательности (Sequence Diagrams) и диаграммы взаимодействий (Collaboration Diagrams).

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

На диаграмме последовательности основное внимание уделяется временньй упорядоченности сообщений. На ней изображаются объекты, непосредственно участвующие во взаимодействии, и сообщения, которыми эти объекты обмениваются (см. рис. 1).

Рис. 1 Графические элементы диаграммы последовательности

Графически каждый объект изображается в виде прямоугольника, от которого начинается его линия жизни. Линия жизни отражает существование объекта во времени. Большинство объектов существует на протяжении всего времени взаимодействия, как показано на рисунке, другие могут создаваться во время взаимодействия, и тогда их линии жизни начинаются с получения сообщения со стереотипом create. Также объекты могут уничтожаться во время взаимодействия (стереотип destroy), и конец его жизни обозначается специальным символом.

Имя объекта записывается со строчной буквы, затем через двоеточие следует имя класса, вся запись подчеркивается. Если на диаграмме последовательности отсутствует собственное имя объекта, то при этом должно быть указано имя класса - такой объект считается анонимным. Может отсутствовать и имя класса, но при этом должно быть указано собственное имя объекта - такой объект считается сиротой.

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

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

Сообщения, которыми обмениваются объекты, обозначаются в виде стрелок различного вида и упорядочиваются по времени (поэтому, их порядковые номера указывать необязательно). Основные виды стрелок:

Рис. 2

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

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

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

В Rational Rose также можно устанавливать дополнительные разновидности сообщений (связанные с синхронизацией и периодичностью). Попробуйте разобраться с этими разновидностями самостоятельно.

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

Для изображения ветвления используются две или более стрелки, выходящие из одной точки фокуса управления объекта. Перед порядковым номером сообщения ставится выражение-условие, например [х>0]. У всех альтернативных ветвей будет один и тот же порядковый номер, но условия на каждой ветви должны быть заданы так, чтобы два из них не выполнялись одновременно.

И, наконец, для моделирования итерации перед номером сообщения в последовательности ставится выражение итерации, например * [ i : = 1. . n] (или просто *, если надо обозначить итерацию без дальнейшей детализации).

Диаграммы коопераций

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

В основном, описанная нотация для диаграмм последовательностей действительна и для диаграмм коопераций, однако существуют некоторые отличия:

1. Путь - для описания связи одного объекта с другим к дальней концевой точке этой связи можно присоединить стереотип пути:

- association - соответствующий объект виден на ассоциации;

- self - объект является диспетчером операции;

- global - объект находится в глобальной области действия;

- local - объект находится в локальной области действия;

- parameter - объект является параметром.

2. Порядковый номер сообщения - для обозначения временньй последовательности перед сообщением ставиться номер (нумерация начинается с единицы), который должен постепенно возрастать для каждого нового сообщения (2, 3 и т.д.). Для обозначения вложенности используется десятичная нотация Дьюи (1 - первое сообщение; 1.1 - первое сообщение, вложенное в сообщение 1; 1.2- второе сообщение, вложенное в сообщение 1 и т.д.). Уровень вложенности не ограничен. Для каждой связи можно показать несколько сообщений (вероятно, посылаемых разными отправителями), и каждое из них должно иметь уникальный порядковый номер.

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

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

Практическая часть:

1. Архитектурный анализ системы

Следующий этап разработки проекта - анализ системы. Примем следующие соглашения по моделированию:

1. Имена вариантов использования должны быть короткими глагольными фразами.

2. Для каждого варианта использования должен быть создан пакет Use Case Realization, включающий:

- по крайней мере, одну реализацию варианта использования;

- диаграмму VOPC (View of Participating Classes).

3. Имена классов должны быть существительными, соответствующими понятиям предметной области, и начинаться с прописной буквы. Имена атрибутов и операций должны начинаться со строчной буквы, составные имена - сплошными, без подчёркиваний, каждой отдельное слово с прописной буквы.

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

Сначала создайте структуру модели, аналогично рис.2.

Рис. 3 Структура модели проектируемой системы

Как видно на рис. 2, для реализации каждого варианта использования в Logical View создан отдельный пакет (Use Case Realization), а также добавлена диаграмма вариантов использования, отображающая связи между вариантами использования и их реализациями.

Затем, для построения логической модели, необходимо определить предварительные ключевые абстракции - классы анализа, добавить их в пакет Design Model, и поместить на диаграмму Key Abstractions (см. рис.3).

Рис. 4 Диаграмма классов ключевых абстракций

В потоках событий вариантов использования классы могут быть трёх типов:

1. Граничные классы (стереотип boundary) - служат посредниками при взаимодействии внешних объектов с системой. Как правило, для каждой пары «актёр - вариант использования» определяется один такой класс. Типы граничных классов:

- пользовательский интерфейс (без деталей - кнопок, окон и т.п.);

- системный интерфейс (протоколы без деталей реализации);

- аппаратный интерфейс (протоколы без деталей реализации).

2. Классы сущности (стереотип entity) - ключевые абстракции (понятия) разрабатываемой системы. Выявляются в процессе архитектурного анализа, при составлении глоссария проекта, при описании потоков событий вариантов использования.

3. Управляющие классы (стереотип control) - обеспечивают координацию поведения объектов в системе. В вариантах использования, где производятся только простейшие манипуляции с данными, такие классы могут отсутствовать. Как правило, для каждого варианта использования определяется только один управляющий класс (менеджер транзакций, координатор ресурсов, обработчик ошибок и т.п.)

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

2. Построение диаграммы последовательности

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

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

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

Построение диаграммы коопераций

Если для заданного варианта использования диаграмма последовательности уже построена, нажмите F5 и просто удобочитаемо расположите элементы полученной диаграммы коопераций. Иначе, постройте диаграмму, используя описанную в теоретической части нотацию. Не забудьте поместить на диаграмму комментарии.

Представляемые в отчёте результаты: диаграммы взаимодействий и VOPC для каждого варианта использования с необходимыми пояснениями. Также в отчёте необходимо обосновать применение той или иной диаграммы взаимодействия.

Знать ответы на контрольные вопросы.

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

1. Что собой представляет логическое представление системы в Rational Rose?

2. Что общего и чем отличаются диаграммы последовательности и коопераций? Какие ещё виды диаграмм взаимодействия Вы знаете?

3. Что такое сообщение, и какие типы сообщений можно выделить?

4. Поясните понятия «линия жизни» и «фокус управления».

5. Какие разновидности сообщений доступны в Rational Rose? Поясните их смысл?

Размещено на Allbest.ru

...

Подобные документы

  • Характеристика CASE-засобу Rational Rose 98/2000. Дослідження призначення панелей інструментів середовища. Причини, що стримують застосування CASE-засобів. Особливості робочого інтерфейсу Rational Rose. Відмінність між нотаціями Booch, OMT та Unified.

    лабораторная работа [260,8 K], добавлен 10.11.2021

  • Разработка информационной системы для ведения каталога книг/читателей, поисковой системы и системы предварительных заказов на приобретение книг. Среда Rational Rose. Внесение изменений в объект. Основные операции классов и атрибуты типов данных.

    лабораторная работа [417,6 K], добавлен 17.05.2013

  • Среда проектирования программного обеспечения Rational Rose. Унифицированный язык моделирования UML. Требования к функциональности, к безопасности, интерфейсу, настраиваемости, информационной и программной совместимости, программная документация.

    курсовая работа [582,0 K], добавлен 20.07.2011

  • Классификация автоматизированных информационных систем (АИС). Проектирование АИС складского учета с использованием CASE-средства Rational Rose. Подходы к проектированию, анализ CASE-средств. Программная реализация профессионально ориентированной АИС.

    курсовая работа [1,4 M], добавлен 06.03.2012

  • UML как стандарт для создания модели информационной системы. Особенности работы в средстве проектирования Rational Rose 2003. Назначение операций главного меню File и Edit. Особенности разработки диаграммы развертывания в среде IBM Rational Rose 2003.

    дипломная работа [524,1 K], добавлен 27.09.2010

  • Загальна характеристика мови моделювання UML. Розробка діаграм UML з метою автоматизації продаж в магазині. Rational Rose як засіб візуального моделювання об'єктно-орієнтованих інформаційних систем. Зворотне проектування як головна перевага Rational Rose.

    контрольная работа [1,7 M], добавлен 23.10.2014

  • Использование CASE-средств для поддержки процессов создания и сопровождения информационных систем. Задачи графического редактора диаграмм, документатора и администратора проекта. Основные возможности IBM Rational Professional Bundle и IBM Rational Rose.

    реферат [28,1 K], добавлен 30.05.2012

  • Создание диаграмм вариантов использования, логического представления, классов, состояний и деятельности, компонентов, развертывания для автоматизированной информационной системы в CASE-средстве Rational Rose. Генерация кода программы на языке ANSI C++.

    курсовая работа [1,5 M], добавлен 23.10.2014

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

    презентация [458,6 K], добавлен 07.05.2014

  • Реалізація механізму роботи пекарні за допомогою засобів UML, а саме використання програмного продукту Rational Rose (об’єктно-орієнтованого засобу проектування). Проект автоматизованої моделі цього виробництва за допомогою AllFusion Process Modeler.

    курсовая работа [189,1 K], добавлен 28.04.2011

  • Введение в Rose. Создание управляемого элемента. Варианты использования и действующие лица. Выполнение лабораторной работы. Присвоение имен вариантам использования. Создание абстрактного действующего лица. Спецификация объекта. Кооперативная диаграмма.

    учебное пособие [2,7 M], добавлен 09.03.2013

  • Разработка модели информационной подсистемы для учета заказов клиентов автосервиса с применением языка UML. Создание диаграммы прецедентов, последовательности, сотрудничества и классов, используя методы Rational Rose 2000. Генерация программного кода C++.

    курсовая работа [1013,2 K], добавлен 22.06.2011

  • Разработка системы автоматизированного анализа сложных объектов образовательной системы. Построение диаграмм последовательности, кооперации, классов, состояний, компонентов, а также развертывания. Представление сгенерированных кодов клиента и сервера.

    курсовая работа [501,1 K], добавлен 23.06.2014

  • Развитие современных информационных технологий. Этапы объектно-ориентированного проектирования информационных систем Rational Rose. Моделирование железнодорожной информационной системы. Создание диаграмм последовательности, компонентов, размещения.

    курсовая работа [840,0 K], добавлен 11.07.2012

  • Создание приложения в программе Rational Rose для удобного функционирования системы обслуживания банкоматов. Методы создания баз данных в программе и разработки диаграмм: последовательности, действий и состояния. Составление инструкции для пользователя.

    курсовая работа [271,2 K], добавлен 15.02.2011

  • Системы автоматического проектирования. Сравнительный анализ средств для проектирования автоматизированных информационных систем. Экспорт SQL-кода в физическую среду и наполнение базы данных содержимым. Этапы развития и характеристика Case-средств.

    курсовая работа [1,1 M], добавлен 14.11.2017

  • Особенности и принципы моделирования программных продуктов в среде Rational Rose. Проектирование системы моментальных платежей "Терминал приема платежей". Создание модели системы на языке UML и программного продукта в виде исполняемого и исходных файлов.

    курсовая работа [1,7 M], добавлен 09.11.2011

  • Исследование объектно-ориентированного подхода к проектированию программного обеспечения будильника. Модель программного обеспечения. Взаимодействие между пользователями и системой. Диаграммы и генерация программного кода при помощи средств Rational Rose.

    курсовая работа [355,8 K], добавлен 26.09.2014

  • Анализ деятельности предприятия и моделирование основных бизнес-процессов. Моделирование бизнес-процессов при помощи CASE-средства Rational Rose. Получение прибыли путем расширения рынка товаров и услуг. Бизнес-процесс "Заказ и закупка товара".

    дипломная работа [1,2 M], добавлен 31.07.2012

  • Разработка программного комплекса по автоматизированной системе управления взаимодействия с клиентами и портфелем заказов рекламного агентства. Проектирование системы в программе Rational Rose. Моделирование структуры данных с помощью Data Modeler.

    курсовая работа [2,6 M], добавлен 13.06.2014

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.