close

Вход

Забыли?

вход по аккаунту

?

Diyazitdinova Halimov Unifizirov yazik modelirovaniya UML metodichka 2010

код для вставкиСкачать
Федеральное агентство связи
Федеральное государственное образовательное бюджетное учреждение
высшего профессионального образования
ПОВОЛЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ТЕЛЕКОММУНИКАЦИЙ И ИНФОРМАТИКИ
ЭЛЕКТРОННАЯ
БИБЛИОТЕЧНАЯ СИСТЕМА
Самара
Государственное образовательное учреждение
высшего профессионального образования
Поволжский государственный университет
телекоммуникаций и информатики
Кафедра экономических и информационных систем
УНИФИЦИРОВАННЫЙ ЯЗЫК
МОДЕЛИРОВАНИЯ UML
(с использованием case-средства
Visual Paradigm for UML)
Методические указания
к лабораторным работам по дисциплине
"Проектирование информационных систем"
Составители: Диязитдинова А.Р.,
Халимов Р.Р.
Самара, 2010 г.
УДК 681.3
Рецензент
Кандидат технических наук, доцент Иващенко А.В.
Диязитдинова А.Р., Халимов Р.Р. Унифицированный язык моделирования UML (с использованием case-средства Visual Paradigm for UML): Методические указания к лабораторным работам по дисциплине «Проектирование информационных систем». – Самара: ПГУТИ, 2010. – 48 с., ил.
Visual Paradigm for UML 7.1 (VP-UML) представляет собой case-средство
визуального UML моделирования. VP-UML 7.1 предлагает объектноориентированный подход к анализу и проектированию систем различной сложности и позволяет создавать UML-диаграммы в полностью визуализированной
среде разработки посредством простых drag&drop операций. Основная цель методических указаний – способствовать получению студентами практических
навыков в области проектирования информационных систем с использованием
объектно-ориентированного подхода (с применением методологии UML).
Методические указания к лабораторным работам подготовлены на кафедре "Экономические и информационные системы", предназначены для студентов
всех форм обучения специальности 080801 (Прикладная информатика в экономике) и являются руководством к выполнению их студентами. В дальнейшем
могут быть использованы в ходе дипломного проектирования, также они могут
быть полезны преподавателям смежных дисциплин и разработчикам программного обеспечения.
© ГОУВПО ПГУТИ
© Диязитдинова А.Р., Халимов Р.Р., 2010
Содержание
ЦЕЛИ И ЗАДАЧИ ..................................................................................................... 5
ЛАБОРАТОРНЫЙ ПРАКТИКУМ........................................................................ 5
ЛАБОРАТОРНАЯ РАБОТА 1 .......................................................................................... 5
Общие сведения. Описание потоков событий и разработка вариантов
использования........................................................................................................ 5
Разработка диаграммы вариантов использования в Visual Paradigm for
UML ........................................................................................................................ 9
ЛАБОРАТОРНАЯ РАБОТА 2 ........................................................................................ 15
Разработка диаграммы классов ....................................................................... 15
Разработка диаграммы классов в Visual Paradigm for UML ........................ 16
ЛАБОРАТОРНАЯ РАБОТА 3 ........................................................................................ 28
Разработка диаграммы состояний ................................................................. 28
Разработка диаграммы состояний в Visual Paradigm for UML ................... 29
ЛАБОРАТОРНАЯ РАБОТА 4 ........................................................................................ 33
Разработка диаграммы деятельностей ......................................................... 33
Разработка диаграммы деятельностей в Visual Paradigm for UML ........... 34
ЛАБОРАТОРНАЯ РАБОТА 5 ........................................................................................ 36
Диаграммы взаимодействия ............................................................................. 36
Диаграмма последовательности ...................................................................... 36
Разработка диаграммы последовательности в Visual Paradigm for UML . 37
Диаграмма коммуникации ................................................................................. 39
Разработка диаграммы коммуникации в Visual Paradigm for UML ............. 40
ЛАБОРАТОРНАЯ РАБОТА 6 ........................................................................................ 44
Разработка диаграммы компонентов ............................................................. 44
Разработка диаграммы компонентов в Visual Paradigm for UML .............. 45
ЛАБОРАТОРНАЯ РАБОТА 7 ........................................................................................ 48
Разработка диаграммы размещения ............................................................... 48
Разработка диаграммы размещения в Visual Paradigm for UML ................. 49
ВАРИАНТЫ ЗАДАНИЙ ........................................................................................ 51
ПРИЛОЖЕНИЕ....................................................................................................... 52
СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ ............................................... 54
ЦЕЛИ И ЗАДАЧИ
Цель методических указаний – применение на практике знаний, полученных в процессе изучения курса "Проектирование информационных систем", в
области проектирования информационных систем с использованием объектноориентированного подхода (с применением методологии Unified Modeling
Language (UML)).
ЛАБОРАТОРНЫЙ ПРАКТИКУМ
Лабораторная работа 1
Тема: Знакомство с case-средством Visual Paradigm for UML. Разработка
диаграммы вариантов использования.
Цель лабораторной работы: в ходе выполнения лабораторной работы
студент должен ознакомиться с возможностями case-средства Visual Paradigm
for UML 7.1, освоить основные принципы создания диаграмм вариантов использования.
Задачи:
1. Изучить среду case-средства Visual Paradigm for UML 7.1.
2. Получить навыки создания диаграммы вариантов использования.
Общие сведения. Описание потоков событий и разработка вариантов
использования
На Рис. 1 показан пример диаграммы вариантов использования для предметной области «Поликлиника». На данной диаграмме человеческие фигурки
обозначают действующих лиц (актеры/актанты), овалы – варианты использования (функции, реализуемые системой), а линии и стрелки – различные связи
между актерами и вариантами использования.
Однако, для того чтобы фактически разработать систему, потребуются более конкретные детали. Эта детали описываются в документе, называемом «поток событий» (flow of events). Целью потока событий является документирование процесса обработки данных, реализуемого в рамках варианта использования. Этот документ подробно описывает, что будут делать пользователи системы и что – собственно система. Хотя поток событий и описывается подробно,
он не должен зависеть от реализации. Цель - описать то, что (а не как) будет делать система.
Обычно поток событий включает [2]:
краткое описание;
предусловия (pre-conditions);
основной поток событий;
альтернативный поток событий;
постусловия (post-conditions).
Рис. 1. Диаграмма вариантов использования «Поликлиники»
Краткое описание
Каждый вариант использования должен иметь краткое описание того, что
он будет делать. Например, вариант использования «Осуществить прием пациента» может содержать следующее описание:
Вариант использования «Осуществить прием пациента» позволяет врачу
поставить диагноз осматриваемому пациенту, определить и назначить лечение, выписать в случае необходимости рецепт и/или листок по потере трудоспособности; медсестре занести информацию приема в личную карточку пациента; пациенту посетить в назначенное время врача.
Предусловия
Предусловия варианта использования - это такие условия, которые должны
быть выполнены, прежде чем вариант использования начнет выполняться сам.
Например, таким условием может быть выполнение другого варианта использования или наличие у пользователя прав доступа, требуемых для запуска данного. Не у всех вариантов использования бывают предусловия. С помощью предусловий можно документировать порядок выполнения диаграмм использования. Так, предусловием одного варианта использования может быть то, что в
это время должен выполняться другой.
Предусловием варианта использования «Осуществить прием пациента»
является выполнение вариантов использования «Оформить карточку пациента», «Зарегистрировать страховой полис» и «Оформить талон на прием к
врачу».
Основной и альтернативный потоки событий
Конкретные детали вариантов использования описываются в основном и
альтернативных потоках событий. Поток событий поэтапно описывает, что
должно происходить во время выполнения заложенной в варианты использования функциональности. Поток событий уделяет внимание тому, что будет делать система, а не как она будет делать это, причем описывает все это с точки
зрения пользователя. Основной и альтернативный потоки событий включают
следующее описание [2]:
каким образом запускается вариант использования;
различные пути выполнения варианта использования;
нормальный, или основной, поток событий варианта использования;
отклонения от основного потока событий (так называемые альтернативные потоки);
потоки ошибок;
каким образом завершается вариант использования.
Например, поток событий варианта использования «Осуществить прием
пациента» может выглядеть следующим образом:
Основной поток
1. Вариант использования начинается, когда пациент приходит на прием к
врачу.
2. Пациент должен передать врачу талон на прием. Если талон отсутствует, то выполняется альтернативный поток событий А1.
3. Врач уточняет у пациента, является ли прием первым. Если прием повторный, то врач просматривает результаты проведенных анализов.
4. Врач выслушивает жалобы пациента.
5. Врач/медсестра вносит сведения в личную карточку пациента.
6. Полученных сведений достаточно для постановки диагноза. Если информации недостаточно, то альтернативный поток событий А2.
7. Врач ставит диагноз пациенту.
8. Врач определяет вид лечения для пациента.
9. Врач назначает лекарство пациенту. Если на лекарство требуется рецепт,
то выполняется альтернативный поток событий А3.
10.Врач уточняет необходимость открытия листка потери трудоспособности. Если такая необходимость существует, то выполняется альтернативный поток событий А4.
11.Вариант использования завершается.
Альтернативный поток А1. Пациент не оформил талон на прием к врачу
1. Врач информирует пациента о том, что обязательным условием посещения
врача является наличие талона амбулаторного пациента, оформляемого в
регистратуре.
2. Врач возвращает пациенту медицинскую карточку.
3. Вариант использования завершается.
Альтернативный поток А2. Информации для постановки диагноза недостаточно
1. Врач выписывает направления на анализы.
2. Медицинская карточка пациента остается у лечащего врача.
3. Вариант использования завершается.
Альтернативный поток А3. Требуется рецепт на лекарство
1. На специальном бланке за подписью и печатью врача, с указанием даты,
выписывается рецепт на требуемое лекарство.
2. Вариант использования завершается.
Альтернативный поток A4. Врач открывает листок по потере трудоспособности
1. На бланке строгой отчетности врач указывает дату открытия документа.
2. На основании поставленного диагноза определяется срок потери трудоспособности.
3. Листок потери трудоспособности регистрируется в регистратуре.
4. Вариант использования завершается.
Постусловия
Постусловиями называются такие условия, которые, если они существуют
в потоке событий, всегда должны быть выполнены после завершения варианта
использования. Например, в конце варианта использования можно пометить
флажком какой-нибудь переключатель. Информация такого типа вводит в состав постусловий. Как и для предусловий, с помощью постусловий можно вводить информацию о порядке выполнения вариантов использования системы.
Если, например, после одного из вариантов использования должен всегда выполняться другой, это можно описать как постусловие. Такие условия имеются
не у каждого варианта использования.
Постусловием варианта использования «Осуществить прием пациента»
является выполнение варианта использования «Пройти назначенное лечение».
Разработка диаграммы вариантов использования в Visual Paradigm
for UML
Visual Paradigm for UML 7.1 (VP-UML) представляет собой case-средство
визуального
UML-моделирования.
VP
7.1
предлагает
объектноориентированный подход к анализу и проектированию систем различной сложности и позволяет создавать множество типов диаграмм в полностью визуализированной среде разработки посредством простых drag&drop операций.
При запуске VP-UML предложит открыть существующий проект или выбрать тип вновь создаваемой диаграммы (Рис. 2).
Рассмотрим подробнее некоторые особенности создания диаграмм в Visual
Paradigm for UML.
Диаграммы в VP-UML можно создавать как в оконном, так и в полноэкранном режиме. Переключение в полноэкранный режим производится выбором
в меню «View» команды «Full Screen» или нажатием клавиши «F11». Повторное
выполнение команды возвращает оконный режим проектирования.
Открыть проект
Создать
диаграмму
Рис. 2. Стартовое окно Visual Paradigm for UML 7.1 Community Edition
VP-UML позволяет создавать элементы диаграмм и связи графическим
способом с помощью мыши. Для этого в программе существуют определенные
графические знаки – «жесты», рисуя которые, пользователь может получить
необходимую фигуру в области построения простым движением мыши, не прибегая к использованию панели элементов и прочих меню. Чтобы получить таким образом элемент, нужно зажать правую кнопку мыши и нарисовать один из
графических знаков, приведенных в Табл. 2 (см. Приложение).
Для создания новой диаграммы вариантов использования нужно выбрать
соответствующую строку в списке вновь создаваемых диаграмм (в нашем случае – «New Use Case Diagram»).
После создания новой диаграммы определится еѐ имя (см. Рис. 3)
Рис. 3. Назначение нового имени
Создание объектов
Для создания элемента следует выбрать его в панели объектов диаграммы
щелчком мыши, затем, вторым щелчком на области построения элемент может
быть добавлен в диаграмму (см. Рис. 4).
Рис. 4. Создание актера
После создания очередного элемента, ему присваивается имя по умолчанию, которое может быть изменено сразу или впоследствии, по двойному
щелчку на элементе. Имя (и другие свойства) также можно задать в панели
свойств объектов (Property) в левой части окна программы.
Рис. 5. Окно свойств
Создание связей
Для создания новой связи выберите тип связи в панели объектов, затем
щелкните на объекте-источнике, далее – на связываемом с ним объекте.
При построении связей следует учитывать, что в VP-UML имеется функция автоматической проверки синтаксиса UML, которая не позволяет создавать
неверные связи между объектами (см. Рис. 6).
Рис. 6. Процесс проверки
Каждый существующий объект диаграммы имеет ресурсоориентированный интерфейс, позволяющий создавать новый, связанный с ним, объект или
связь (см. Рис. 7).
Рис. 7. Создание нового варианта использования
Для каждой связи можно установить собственный стиль. Для этого необходимо в контекстном меню связи выбрать Styles and Formatting  Connector
Style и в появившемся списке выбрать один из шести предложенных типов.
В этом же меню задается стиль отображения подписи связи (Только по горизонтали, По горизонтали и вертикали, Параллельно линии связи и т.д.).
Рис. 8. Определение стиля (первый вариант)
Второй способ задания стиля отображения связи – через панель свойств
объектов диаграммы. Сначала в области диаграммы выбирается связь, затем, в
панели свойств, определяется ее стиль:
Рис. 9. Определение стиля (второй вариант)
Экспорт диаграммы
Готовую диаграмму можно полностью или частично копировать в формате
изображения JDG или EMF в буфер обмена для экспорта в другое приложение.
Для этого следует выделить нужные объекты или всю диаграмму (Ctrl+A) и в
контекстном меню выбрать команду Copy  Copy to Clipboard as Image. Данная
команда дублируется комбинацией клавиш Ctrl+Alt+C. После выполненных действий изображение диаграммы готово к вставке в другом приложении.
Иногда, если диаграмма слишком большая, возникает необходимость ориентироваться в ней. Для этого в VP-UML предназначена панель просмотра области диаграммы (Diagram Overview), расположенная в виде вкладки, соседней
по отношению к вкладке свойств объектов диаграммы. Панель просмотра показывает всю область построения диаграммы, выделяя ту ее часть, которую видит
в данный момент пользователь.
Рис. 10. Область построения диаграммы
Сохранение проекта
В рамках одного проекта можно создавать множество диаграмм различных
типов. Доступ к диаграммам проекта осуществляется c помощью Навигатора
(Diagram Navigator), представляющего собой иерархический список в левой части окна программы.
Для сохранения вашего проекта выберите пункт меню File  Save Project,
открывающий диалог сохранения проекта.
1.
2.
3.
4.
Содержание работы
Ознакомиться с теоретическими вопросами построения диаграммы вариантов использования.
Построить с помощью программного средства Visual Paradigm for UML
7.1 диаграмму вариантов использования для предметной области «Поликлиника».
Осуществить построение диаграммы вариантов использования согласно
индивидуальному заданию.
Подготовить отчет по созданным диаграммам.
Требования к отчету
Отчет по лабораторной работе оформляется в печатном виде. Защита лабораторной работы включает в себя проверку знания студентом теоретического
материала, а также практической части лабораторной работы.
Отчет должен включать:
название работы, ее задачи и описание последовательности выполнения;
документ «Поток событий»;
диаграмму вариантов использования для предметной области согласно
выданному индивидуальному заданию.
Все примеры должны быть сохранены на сетевом диске или на диске студента.
Лабораторная работа 2
Тема: Разработка диаграммы классов
Цель работы: Изучить теоретические основы создания диаграммы классов. Освоить принципы построения диаграммы классов в Visual Paradigm for
UML 7.1.
Задачи:
1. Научиться создавать классы.
2. Изучить основные стереотипы классов.
3. Научиться устанавливать отношения между классами.
Разработка диаграммы классов
Диаграмма классов определяет типы классов системы и различного рода
статические связи, которые существуют между ними. На диаграммах классов
изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами.
Класс описывает группу объектов системы, имеющих одинаковые свойства (атрибуты), схожее поведение (операции), типы отношений с другими объектами и семантику [4].
Стереотипы – это механизм, позволяющий разделять классы на категории.
В языке UML основными стереотипами являются:
Boundary (граничный класс) – это классы, объекты которых расположены на границе системы и окружающей среды. Они включают все
формы, отчеты, интерфейсы с аппаратурой (такой, как принтеры или
сканеры) и другими системами.
Entity (классы-сущности) моделируют основные понятия (абстракции)
предметной области, содержащие долгоживущую, нередко сохраняемую информацию. Обычно для каждого класса-сущности создают таблицу в базе данных.
Control (управляющие классы) отвечают за координацию, порядок последовательности, взаимодействия других классов. Обычно у каждого
варианта использования имеется один управляющий класс, контролирующий последовательность событий этого варианта использования.
Диаграмма классов предметной области «Поликлиника» показана на Рис.
11.
Класс «Пациенты» предназначен для хранения в нем информации о пациентах, прикрепленных к поликлинике. В нижней части класса содержатся операции, выполняемые над его объектами (атрибутами), в данном случае - над
сведениями о пациентах. Класс «Врачи» содержит информацию о врачах поликлиники. В классе «Лечение» содержатся сведения о лечении каждого конкретного пациента. Классы «Вид лечения» и «Тип врача» имеют стереотип
«Enumeration» (перечисление). Класс «Отделения» служит для хранения в нем
справочной информации об отделениях поликлиники. Класс «Участок» предназначен для хранения в нем справочной информации об участках города, обслуживаемых поликлиникой. Классы «Больничные листы», «Талоны» и «Рецепты» связаны связью агрегации с классом «Прием пациентов». Класс «Тумба» является граничным классом. Класс «Платные услуги» является дочерним
класса «Услуги».
Рис. 11. Диаграмма классов предметной области «Поликлиника»
Разработка диаграммы классов в Visual Paradigm for UML
1. Для создания диаграммы классов средствами VP-UML в новом проекте
необходимо в списке диаграмм (UML Diagrams), находящемся в правой части
стартовой страницы проекта выбрать строку New Class Diagram. Для добавления
новой диаграммы в существующий (открытый) проект достаточно в меню File
 New Diagram  UML Diagrams выбрать тип создаваемой диаграммы или нажать соответствующую диаграмме кнопку панели инструментов Diagram (см.
Рис. 12).
2. Задаем имя созданной диаграмме классов: «Поликлиника».
Новая диаграмма
классов
Создание в новом
проекте
Рис. 12. Окно создания новой диаграммы классов
3. Построение диаграммы начнем с создания класса «Приѐм пациентов».
Для этого, в панели объектов, необходимо щелчком мыши выбрать элемент
«Class», затем вторым щелчком на области построения диаграммы добавить
элемент в диаграмму и определить ему имя «Приѐм пациентов».
Созданный класс имеет стандартный, прямоугольный вид:
Рис. 13. Класс «Прием пациентов»
Класс «Приѐм пациентов» содержит атрибуты и операции согласно Рис.
11. Для добавления атрибута выберите пункт контекстного меню класса Add 
Attribute или, выделив класс, нажмите Alt+Shift+A.
Примечание. Атрибуты класса могут иметь определенный тип (типы атрибутов класса аналогичны основным типам переменных в программировании), который задается свойством Type атрибута в инспекторе свойств
(см. Рис. 14).
Рис. 14. Задание типов атрибутов
Добавить операцию в класс можно выбрав в контекстном меню класса команду Add  Operation, или комбинацией Shift+Alt+O (элемент должен быть
предварительно выделен).
После добавления необходимых атрибутов и операций класс «Приѐм пациентов» приобрел следующий вид:
Рис. 15. Класс «Прием пациентов» с указанием атрибутов и операций
4. Следующий шаг – создание класса «Пациент». Воспользуемся для этого
встроенным меню класса «Приѐм пациентов», которое доступно после выделения элемента мышью. В меню кликните по иконке, соответствующей команде
создания нового элемента ( Generic Resource):
Рис. 16. Команды создания нового связанного элемента
Для создания нового класса, связанного с существующим посредством ассоциации, выберите команду Association  Class меню создания элемента (см.
Рис. 17).
Рис. 17. Окно создания ассоциации
Результатом выполнения команд является новый класс диаграммы, связанный с классом «Приѐм пациентов» посредством ассоциации.
Рис. 18. Создание класса «Пациент», связанного с классом «Прием пациентов»
Задайте новому классу имя «Пациент».
Примечание. Для каждого элемента диаграммы можно выбрать способ привязки маркера связи. Способ привязки определяется в окне «Выбор стиля маркера связи» (Select
Connection Point Style), доступ к которому осуществляется командой Styles and Formatting  Connection Point… контекстного меню элемента или группы элементов диаграммы. В окне можно выбрать один из стилей – привязка по контуру элемента (Round the
shape) или привязка к центру (Follow center):
Рис. 19. Окно выбора способа привязки маркера связи
Примечание. Привязку связи элемента (группы элементов) можно настроить и в инспекторе свойств левой части окна программы (Рис. 20) или
вручную, перетаскивая и «прикрепляя» связь к элементу нажатием специальной кнопки (Рис. 21).
Рис. 20. Определение типа привязки в инспекторе свойств
Рис. 21. Настройка «вручную»
Примечание. Повторное нажатие кнопки возвращает свойства привязки
связи заданные по умолчанию или установленные пользователем.
Теперь настроим кратность (multiplisity) ассоциации элементов «Приѐм пациентов» и «Пациент». Кратность настраивается определением ее параметров
в окне «Свойства ассоциации» (Association Specification), открыть которое можно командой контекстного меню ассоциации «Open Specification…», или выделив нужную ассоциацию и нажав клавишу «Enter». В верхней части окна можно
задать кратность ассоциации для источника (свойство Multiplicity). В данном
случае кратность равна 1 (всегда только один объект).
Рис. 22. Задание кратности для источника
В нижней части окна свойств ассоциации задается кратность для приемника (значение 1 для элемента «Пациент»).
Рис. 23. Задание кратности для источника
Примечание. Кратность можно задать в инспекторе свойств элемента
(для класса «Прием пациента» - Role A  Multiplicity, для класса «Пациент» - Role B  Multiplicity):
Рис. 24. Задание кратности в инспекторе свойств элемента
Примечание. Кратность можно также определить из контекстного меню
ассоциации. Для этого щелкните правой кнопкой мыши в центре линии
ассоциации, затем выберите в меню один из элементов ассоциации – Role
A (Прием пациентов) или Role B (Пациент) и задайте выбранному элементу значение свойства Multiplicity:
Рис. 25. Задание кратности с помощью контекстного меню
5. Аналогично пп. 4 и 5, согласно Рис. 11, создайте классы: «Участок»,
«Адреса» «Врач», «Отделение», «Кабинет», «График дежурств», «Лечение»,
«Рецепты», «Больничные листы», «Талоны» и «Платные услуги». Определите
созданным классам соответствующие атрибуты и операции (см. п.3).
6. Добавьте в диаграмму класс «Тип врача». В нашем случае, данный элемент имеет стереотип Enumeration (перечисление). В терминологии UML в основе понятия «стереотип» заложено расширение словаря UML, позволяющее
разработчику создавать новые типы строительных блоков, порождая их от существующих.
Чтобы определить классу стереотип перечисления, выполните команду
Stereotypes  Stereotypes… контекстного меню элемента и примените к классу
(кнопка
) находящийся в списке слева стереотип «enumeration».
Рис. 26. Задание стереотипа
Закройте окно свойств класса нажатием кнопки «ОК».
Таким образом, класс приобрел стереотип перечисления, о чем свидетельствует метка << enumeration >> в его заголовке:
Рис. 27. Назначение стереотипа << enumeration >> классу «Тип врача»
7. Процесс создания класса «Вид лечения» аналогичен созданию класса
«Тип врача» (см. п.6).
8. Последний создаваемый класс в рамках данного задания – «Терминал».
Этот объект является граничным классом (boundary), то есть служит для моделирования взаимодействия между системой и ее актантами (пользователями).
Для определения классу стереотипа Boundary выполните команду Stereotypes  boundary контекстного меню класса (см. Рис. 28).
Рис. 28. Присвоение стереотипа «Boundary»
В результате, класс «Терминал» приобретает следующий вид:
Рис. 29. Класс «Терминал»
9. Для связывания родительского («Услуги») и дочернего («Платные услу-
ги») класса выберите в панели элементов тип связи «Обобщение»
(Generalization), затем щелкните мышью на классе «Услуги» и, не отпуская клавиши, проведите связь к потомку. Задайте имя связи «наследует» (см. Рис. 30).
Рис. 30. Создание родительского и дочернего классов
10. Лечение не может быть назначено пациенту без предварительного осмотра его на приѐме, поэтому между классами «Приѐм пациентов» и «Лечение»
необходимо определить композицию. Для этого выделите класс «Приѐм пациентов» и выполните команду Composition  Class встроенного меню элемента.
Рис. 31. Задание композиции
Выполнение команды откроет окно, где нужно ввести имя класса, к которому строиться связь. Если класс, который необходимо включить в композицию, уже создан в области построения, программа, после ввода первых символов имени, предложит выбрать его из списка (см. Рис. 32).
Рис. 32. Предлагаемый список классов для подстановки
Для построенной композиции определите имя – «создает».
11. Талоны, рецепты и больничные листы являются неотъемлемой частью
приѐма, но могут существовать и после его завершения. Поэтому класс «Приѐм
пациентов» связан с классами «Талоны», «Рецепты» и «Больничные листы»
отношением агрегации.
12. Наконец, определите согласно Рис. 11, оставшиеся отношения между
классами диаграммы, указав в случае необходимости их кратность.
13. Конечный вид построенной вами диаграммы классов должен соответствовать модели анализа, представленной на Рис. 11.
Сохраните диаграмму/проект.
Содержание работы
1. Ознакомиться с теоретическими вопросами построения диаграммы
классов.
2. Построить с помощью программного средства Visual Paradigm for UML
диаграмму классов для предметной области «Поликлиника».
3. Осуществить построение диаграммы классов согласно индивидуальному заданию.
4. Продемонстрировать преподавателю созданные диаграммы.
Требования к отчету
Отчет по лабораторной работе оформляется в печатном виде. Защита работы включает в себя проверку знания студентом теоретического материала, а
также практической части лабораторной работы.
Отчет должен включать:
диаграмму классов для предметной области согласно выданному индивидуальному заданию;
описание каждого класса (его назначение, описание атрибутов, операций).
описание связей между классами.
Все примеры должны быть сохранены на сетевом диске или на диске студента.
Лабораторная работа 3
Тема: Разработка диаграммы состояний.
Цель работы: Изучить теоретические основы создания диаграммы состояний. Освоить принципы построения диаграммы состояний в Visual
Paradigm for UML 7.1.
Задачи:
1. Изучить основные типы состояний.
2. Научиться создавать состояния.
3. Научиться создавать переходы.
Разработка диаграммы состояний
На Рис. 33 показана диаграмма состояний для класса «Врач». На Рис. 34
приводится пример диаграммы состояний для пациента, на которой можно наблюдать процесс перехода пациента из одного состояния в другое.
На диаграмме имеются два специальных состояния - начальное (start) и конечное (stop). На диаграмме состояний может быть одно и только одно начальное состояние. В тоже время может быть столько конечных состояний, сколько
вам нужно, или их может не быть вообще. Когда объект находится в каком-то
конкретном состоянии; могут выполняться различные процессы. Процессы,
происходящие в момент, когда объект находится в определенном состоянии,
называются действиями (actions). Заключенное в квадратных скобках условие
(сторожевое условие, guard condition) определяет, когда может произойти переход из одного состояния в другое.
Рис. 33. Диаграмма состояний для класса «Врач»
Рис. 34. Диаграмма состояний для класса «Пациент»
Разработка диаграммы состояний в Visual Paradigm for UML
1. Для создания диаграммы состояний в проекте VP-UML, выберите пункт
State Machine Diagram стартового окна проекта, или выполните команду File 
New Diagram  UML Diagrams  State Machine Diagram главного меню существующего проекта. Выполнение команды откроет соответствующую панель элементов и пустую область построения, разместив на ней начальное состояние
.
2. Построим диаграмму состояний для класса «Пациент».
Согласно Рис. 34, класс имеет состояния: Незарегистрированный, Зарегистрированный, Записан на прием, На приеме, Лечится, Вылечен. Вынесем на
область построения элемент «Состояние» (State) и присвоим его имени значение «Незарегистрированный». Далее, свяжем созданный элемент с начальным
состоянием (см. Рис. 35) посредством перехода (кнопка
панели инструментов).
Аналогично добавьте в диаграмму состояние «Зарегистрированный», при
этом пациент может переходить в данное состояние как из начального, так и из
состояния «Незарегистрированный». При переходе из состояния «Незарегистрированный» обязательным условием перехода является сторожевое событие
«Оформить карточку», что нужно учесть при задании имени перехода.
Рис. 35. Событие «Незарегистрированный»
Далее, создайте состояние «Записан на приѐм». На Рис. 34 видно, что в
данном состоянии происходят определенные действия. Добавить действия в
элемент состояния можно посредством определения значений полей Entry, Do и
Exit Activity вкладки General окна свойств элемента (см. Рис. 36).
Рис. 36. Состояние «Записан на приѐм»
При нажатии кнопки Edit поля действия открывается окно его свойств, в
котором определяются имя действия, а также пред- и постусловия, при их наличии.
Рис. 37. Основные свойства действия состояния «Записан на приѐм»
Более удобный способ доступа к настройкам действий обеспечивает инспектор свойств элементов, расположенный в левой части окна программы.
Состояния «На приѐме», «Лечится» и «Вылечен», с соответствующими событиями и условиями строятся аналогично описанным в п. 2.
В итоге, диаграмма состояний класса «Пациент» имеет вид, представленный на Рис. 34.
Диаграмма состояний для моделирования поведения врача представлена на
Рис. 33 и строится аналогично предыдущей диаграмме. Отличительной особенностью данной диаграммы является наличие составных состояний, для создания которых достаточно в панели инструментов выбрать

. Вложенные состояния добавляются в диаграмму аналогично рассмотренным ранее.
Примечание. Графический способ построения позволяет создавать не
только объекты диаграммы, но и связи между ее элементами. Для построения связи между существующими элементами в рамках любого вида диаграммы достаточно зажав правую клавишу мыши провести линию от исходного элемента к конечному:
Примечание. Дополнительно, функция позволяет создавать новые, связанные объекты. Такой элемент создается проведением графического маркера от существующего элемента в пустую область диаграммы, с последующим выбором в отобразившемся меню типа связи и вида связываемого
объекта
Примечание. В масштабе элементов функция реализует добавление атрибутов (направление линии - справа-налево) и операций (слева-направо)
Содержание работы
1. Ознакомиться с теоретическими вопросами построения диаграмм состояний.
2. Построить с помощью программного средства Visual Paradigm for UML
диаграмму состояний для предметной области «Поликлиника».
3. Осуществить построение диаграммы состояний согласно индивидуальному заданию.
Требования к отчету
Отчет по лабораторной работе оформляется в печатном виде. Защита работы включает в себя проверку знания студентом теоретического материала, а
также практической части лабораторной работы.
Отчет должен включать:
– диаграмму состояний для предметной области согласно выданному индивидуальному заданию;
– описание разработанной диаграммы.
Все примеры должны быть сохранены на сетевом диске или на диске студента.
Лабораторная работа 4
Тема: Разработка диаграммы деятельностей.
Цель работы: в ходе выполнения лабораторной работы студент должен
освоить основные принципы создания диаграммы деятельностей.
Задачи:
1. Изучить основные компоненты диаграммы деятельностей.
2. Научиться создавать диаграмму деятельностей.
Разработка диаграммы деятельностей
Диаграммы деятельностей особенно полезны в описании поведения, включающего большое количество параллельных процессов. Самым большим достоинством диаграмм деятельностей является поддержка параллелизма. Самый
большой их недостаток заключается в том, что связи между действиями и объектами просматриваются недостаточно четко.
Рис. 38. Диаграмма деятельностей сотрудника регистратуры
На Рис. 38 представлена диаграмма деятельностей для сотрудника регистратуры. Деятельность сотрудника начинается, когда пациент впервые приходит
в поликлинику для прохождения медицинского обслуживания. Пациент обращается в регистратуру. Сотрудник регистратуры уточняет, зарегистрирован ли
пациент в поликлинике. Если нет, то необходимо оформить пациенту новый
бланк и внести в него паспортные сведения и данные страхового полиса. Затем
сотрудник регистратуры по адресу прописки гражданина определяет номер
участка пациента, тем самым, прикрепляя его за определенными врачами. Деятельность регистратора по оформлению пациента на прием к врачу начинается,
когда пациент обращается в регистратуру с просьбой о приеме у определенного
специалиста. Регистратор определяет время работы нужного врача. Затем формирует пациенту талон амбулаторного больного. На этом деятельность завершается.
Разработка диаграммы деятельностей в Visual Paradigm for UML
Нажатием соответствующей кнопки на панели Diagram создайте область
построения для диаграммы деятельностей и присвойте ей имя «Деятельность
сотрудника регистратуры». С помощью таблицы (см. Табл. 1) и согласно Рис.
38 постройте диаграмму деятельностей сотрудника регистратуры.
Табл. 1. Элементы диаграммы деятельностей в Visual Paradigm for UML
Название
элемента
Графический
символ
Кнопка панели
элементов
Начальное состояние
Действие
Решение
Объединение по условию
Разветвление
Слияние
Переход
Условие выполнения
Конечное состояние
{определяется в имени перехода}
Содержание работы
1. Ознакомиться с теоретическими вопросами построения диаграмм деятельностей.
2. Построить с помощью программного средства Visual Paradigm for UML
диаграмму деятельностей для предметной области «Поликлиника».
3. Осуществить построение диаграммы деятельностей согласно индивидуальному заданию.
Требования к отчету
Отчет по лабораторной работе оформляется в печатном виде. Защита работы включает в себя проверку знания студентом теоретического материала, а
также практической части лабораторной работы.
Отчет должен включать:
– диаграмму деятельностей для предметной области согласно выданному
индивидуальному заданию;
– описание разработанной диаграммы;
– ответы на контрольные вопросы.
Все примеры должны быть сохранены на сетевом диске или на диске студента.
Лабораторная работа 5
Тема: Разработка диаграмм взаимодействия.
Цель работы: Освоить технологию создания диаграмм взаимодействия.
Задачи:
1. Изучить основные компоненты диаграммы последовательности.
2. Научиться создавать диаграмму последовательности.
3. Научиться создавать диаграмму коммуникации.
Диаграммы взаимодействия
Диаграммы взаимодействия описывают поведение взаимодействующих
групп объектов. Как правило, диаграмма взаимодействия охватывает поведение
объектов в рамках только одного варианта использования. На такой диаграмме
отображается ряд объектов и те сообщения, которыми они обмениваются между собой.
Для моделирования различных аспектов взаимодействия объектов в языке
UML используются соответствующие диаграммы:
1) взаимодействия объектов можно рассматривать во времени, тогда
для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности (sequence diagram);
2) можно рассматривать структурные особенности взаимодействия
объектов. Для представления структурных особенностей передачи и
приема сообщений между объектами используется диаграмма коммуникации (communication diagram). В нотации UML 1.x она носит
название «диаграмма кооперации» (collaboration diagram).
Диаграмма последовательности
Диаграммы последовательности отражают поток событий, происходящих в
рамках варианта использования. Нормальный сценарий оформления талона на
прием показан на Рис. 39. Под сценарием понимается конкретный экземпляр
потока событий.
Рис. 39. Фрагмент диаграммы последовательности
Разработка диаграммы последовательности в Visual Paradigm for
UML
Для создания диаграммы последовательности выберите пункт New Sequence Diagram стартового окна проекта, либо, в главном меню программы,
пункт File  New Diagram  UML Diagrams  Sequence Diagram. Добавить новую диаграмму последовательности в проект также можно нажатием соответствующей кнопки ( New Sequence Diagram) панели инструментов Diagram.
После создания области построения определите ей имя «Приѐм пациента».
Построение диаграммы начнем с последовательного размещения на ней
объектов, с одновременным определением сообщений, которыми взаимосвязанные элементы системы обмениваются между собой в процессе своего функционирования.
1. Первым объектом последовательности является «Пациент».
«Пациент» - актант, инициирующий действия объектов системы. Для создания актера, выберите в панели элементов соответствующий объект –
, после чего щелкните мышью в области построения (по умолчанию,
вместе с объектом создается принадлежащая ему линия жизни).
«Пациент» инициирует функционирование системы, отправляя «сообщение» актеру «Сотрудник регистратуры». Для отображения сообщений в диаграмме последовательности используют линии-стрелки.
2. По аналогии с п.1 добавьте в диаграмму действующее лицо «Сотрудник
регистратуры», расположив его правее созданного ранее.
3. Следующий объект проектируемой последовательности варианта использования – «Карточки пациентов». Добавить подобный элемент в диаграмму можно посредством выбора его в панели объектов (
– прямоугольник со штрихпунктирной линией – стандартное отображение объекта в диаграмме последовательности), и последующим щелчком на области построения:
Рис. 40. Объект «Карточки пациентов»
4. Элемент последовательности «Приѐм» добавляется в диаграмму аналогично
предыдущему:
Рис. 41. Объект «Прием»
5. Наконец, создайте объект «Врач», представляющий собой, как и объект «Пациент», актанта системы.
6. Пользуясь объектным меню и согласно Рис. 39, создайте сообщения между
актантами «Пациент» и «Сотрудник регистратуры»:
Рис. 42. Создание связи от актера «Пациент»
Программа предложит список, из которого можно выбрать линию жизни
объекта, принимающего сообщение (или создать новый объект – пункт New LifeLine списка):
Рис. 43. Выбор объекта для передачи сообщения
Примечание. Сообщения также могут быть созданы посредством выбора
соответствующего объекта (
) панели инструментов
диаграммы:
Рис. 44. Типы сообщений
После создания, сообщения можно перемещать по линиям жизни указателем мыши, устанавливая тем самым требуемое время выполнения операций.
Остальные сообщения последовательности создаются по аналогии.
Общий вид диаграммы последовательности для предметной области «Приѐм пациента» представлен Рис. 39.
Диаграмма коммуникации
Структура взаимодействия объектов проектируемой системы представлена
на Рис. 45.
Рис. 45. Структура взаимодействия объектов системы
Разработка диаграммы коммуникации в Visual Paradigm for UML
1. Для создания диаграммы коммуникаций в открытом проекте достаточно
выбрать в панели Diagram кнопку с соответствующей пиктограммой:
Рис. 46. Создание диаграммы коммуникаций
Для вновь созданной диаграммы введите имя «Приѐм пациентов».
Элементами диаграммы, в рамках данного задания, являются следующие
объекты:
– актант, участвующий во взаимодействии;
– экземпляр конкретного классификатора взаимодействия.
2. Создайте объекты actor («Пациент», «Сотрудник регистратуры» и
«Врач») и LifeLine («Приѐм» и «Карточки пациентов»). Расположите их в области построения в соответствии с Рис. 45.
Примечание. Добавление различных объектов в диаграмму коммуникации
ничем не отличается от аналогичных рассмотренных выше процедур для
объектов других диаграмм.
3. Определите связи (
) между всеми объектами коммуникации:
Рис. 47. Задание связей на диаграмме коопераций
4. Классификатор «Карточки пациентов» имеет дугу, означающую самоделегирование.
Примечание.
Самоделегирование
распространено
в
объектноориентированных системах. Объекты предлагают ряд открытых сервисов
(открытых операций), которые могут быть вызваны клиентскими объектами. Но, как правило, они также имеют и закрытые «вспомогательные»
операции, разработанные специально для вызова самим объектом. [1] В
данном примере линия жизни «Карточки пациентов» посылает себе сообщение «Найти карточку», чтобы найти карту пациента, если таковая
существует. Закрытые операции объекта могут быть вызваны только самим объектом средствами самоделегирования.
Для создания дуги выберите
в панели элементов диаграммы, затем щелкните на объекте, для которого еѐ следует определить («Карточки пациентов») и, удерживая клавишу мыши, завершите связь на том же объекте:
Рис. 48. Создание дуги
5. Для создания сообщения, выберите объект
панели
элементов, после чего щелкните на связи, через которую осуществляется передача сообщения (например, между объектами «Пациент» и «Сотрудник регистратуры»).
После того, как связь создана, программа предложит ввести еѐ имя. Все
сообщения на диаграмме коммуникации автоматически нумеруются в порядке
их отправления/получения. После создания сообщения, связь выглядит следующим образом:
Рис. 49. Создание сообщения
Примечание. Графический символ сообщений (стрелку) и их заголовки
можно свободно перемещать по области построения мышью, обеспечивая
тем самым диаграмме необходимый внешний вид.
6. Сообщение-ответ создается выбором объекта
панели инструментов и последующим щелчком мыши на связи между объектами
взаимодействия:
Рис. 50. Создание сообщений
7. Создайте сообщения для остальных участников коммуникации (см.
Рис. 45).
8. Сохраните проект.
Содержание работы
1. Ознакомиться с теоретическими вопросами построения диаграмм взаимодействия.
2. Построить с помощью программного средства Visual Paradigm for UML
диаграмму последовательности для предметной области «Поликлиника».
3. Построить с помощью программного средства Visual Paradigm for UML
диаграмму коммуникации для предметной области «Поликлиника».
4. Осуществить построение диаграмм взаимодействия согласно индивидуальному заданию.
Требования к отчету
Отчет по лабораторной работе оформляется в печатном виде. Защита лабораторной работы включает в себя проверку знания студентом теоретического
материала, а также практической части.
Отчет должен включать:
диаграмму последовательности для предметной области согласно выданному индивидуальному заданию;
диаграмму коммуникации предметной области согласно индивидуальному заданию;
описание разработанных диаграмм.
Все примеры должны быть сохранены на сетевом диске или на диске студента.
Лабораторная работа 6
Тема: Разработка диаграммы компонентов.
Цель работы: научиться создавать диаграмму компонентов.
Задачи:
1. Изучить основные элементы диаграммы компонентов.
2. Научиться строить диаграмму компонентов.
Разработка диаграммы компонентов
Диаграммы компонентов показывают, как выглядит статическая структурная модель программной системы. На них изображены компоненты программного обеспечения (библиотеки, модули, пакеты, исполняемые файлы и т.п.) и
связи (зависимости) между ними.
Каждый класс модели (или подсистема) преобразуется в компонент исходного программного кода. После создания они сразу добавляются к диаграмме
компонентов. Между отдельными компонентами изображают зависимости, соответствующие зависимостям на этапе компиляции или выполнения программы. У системы может быть несколько диаграмм компонентов в зависимости от
числа подсистем или исполняемых файлов.
На Рис. 51 изображен пример диаграммы компонентов для поликлиники. В
данном случае, в зависимости от роли пользователя осуществляется вызов одной из подсистем: АРМ сотрудника регистратуры или АРМ врача. Сотрудник
регистратуры работает с подсистемой, обрабатывающей информацию из двух
баз данных: БД врачей и БД услуг. Кроме того, на диаграмме показано, что
терминал для выписывания талонов на прием является интерфейсом.
Рис. 51. Диаграмма компонентов
Разработка диаграммы компонентов в Visual Paradigm for UML
Нажатием кнопки New Component Diagram ( ) добавьте в проект новую
диаграмму компонентов, задав ей имя «Поликлиника».
1. Создайте стандартный компонент, выбрав в панели элементов объект
. Определите созданному элементу имя «БД врачей». Для построения
диаграммы (Рис. 51), необходимо установить данному компоненту стереотип
<<database>>. Сделать это можно выбором команды Stereotypes  database
контекстного меню объекта. В результате, компонент «БД врачей» приобретает
следующий вид:
Рис. 52. Компонент «БД врачей»
2. Аналогичным образом добавьте в диаграмму компонент «БД услуг»,
также определив элементу стереотип <<database>>:
Рис. 53. Компонент «БД услуг»
3. Далее, создайте компоненты «АРМ сотрудника регистратуры» и «АРМ
врача». На программном уровне данные компоненты представляют собой подсистемы, которые пользователь, в зависимости от своего служебного статуса,
через главный интерфейс вызывает на исполнение. Задайте компонентам стереотип <<subsystem>>. Созданные элементы должны иметь следующий вид:
Рис. 54. Подсистемы «АРМ сотрудника» и «АРМ врача»
4. Еще один элемент диаграммы – спецификация задачи (исполняемый
файл) «Основное меню» - создается аналогично предыдущим, но имеет стереотип Executable (Исполнимый).
Рис. 55. Компонент «Основное меню»
5. Создайте элемент «Оформление талонов на приѐм». Так как талоны на
приѐм реализуются в форме документа, компонент должен иметь стереотип
<<document>>:
Рис. 56. Компонент «Оформление талонов на прием»
6. Последний компонент – интерфейс «IТерминал». Для создания интер-
фейса выберите в панели элементов объект
; вторым щелчком добавьте его в область построения. Имя интерфейсу определяется с заглавной латинской буквы «I».
Интерфейс должен быть связан с реализующим его компонентом посредством обобщения (
), и ассоциацией (
) с
компонентом, который использует его в процессе выполнения. В нашем случае
интерфейс «IТерминал» реализуется компонентом «Основное меню», а используется элементом системы «Оформление талонов на приѐм»:
Рис. 57. Связи между компонентами и интерфейсом
Наконец, в соответствии с Рис. 51, определите зависимости между остальными компонентами – кнопка
панели элементов.
Содержание работы
1. Ознакомиться с теоретическими вопросами построения диаграммы
компонентов.
2. Построить с помощью программного средства Visual Paradigm for UML
диаграмму компонентов для предметной области «Поликлиника».
3. Осуществить построение диаграммы компонентов согласно индивидуальному заданию.
Требования к отчету
Отчет по лабораторной работе оформляется в печатном виде. Защита лабораторной работы включает в себя проверку знания студентом теоретического
материала, а также практической части лабораторной работы.
Отчет должен включать:
диаграмму компонентов для предметной области согласно выданному
индивидуальному заданию;
описание разработанной диаграммы.
Все примеры должны быть сохранены на сетевом диске или на диске студента.
Лабораторная работа 7
Тема: Разработка диаграммы размещения.
Цель работы: научиться создавать диаграмму размещения.
Задачи:
1. Изучить основные элементы диаграммы размещения.
2. Научиться строить диаграмму размещения.
Разработка диаграммы размещения
Диаграмма размещения отражает физические взаимосвязи между программными и аппаратными компонентами системы. Она показывает размещение объектов и компонентов в распределенной системе. Каждый узел на диаграмме размещения представляет собой некоторый тип вычислительного устройства - в большинстве случаев часть аппаратуры. Эта аппаратура может быть
простым устройством или датчиком, а может быть и мэйнфреймом.
Диаграмма размещения показывает физическое расположение сети и взаимное местонахождение в ней различных компонентов. Диаграмма размещения
для информационной системы поликлиники показана на Рис. 58. В нашем примере система поликлиники состоит из АРМ сотрудника регистратуры, АРМ
врачей и терминала для выписки талонов на посещение, то есть из отдельных
физических устройств, или узлов (node).
Диаграмма размещения используется менеджером проекта, пользователями, архитектором системы и эксплуатационным персоналом, чтобы понять физическое размещение системы и расположение ее отдельных подсистем.
Рис. 58. Диаграмма размещения для системы «Поликлиника»
Разработка диаграммы размещения в Visual Paradigm for UML
Для создания диаграммы размещения выберите пункт File  New Diagram UML Diagrams  Deployment Diagram главного меню проекта.
Добавьте в диаграмму узел, соответствующий региональному серверу системы. Для этого, выберите в панели элементов объект Node (
), затем
щелкните мышью на области построения. Определите узлу имя «Сервер поликлиники».
Далее, аналогичным образом и согласно Рис. 58, добавьте в область построения узлы: «АРМ сотрудника регистратуры» и «АРМ врача».
В рассматриваемой диаграмме размещения также существует компонент
«Электронный терминал». Данный компонент является функционирующим в
рамках системы устройством или девайсом. Для добавления в диаграмму узла
устройства, выберите в панели элементов (выпадающий список элемента Node)
объект Device Node (
), после чего, нажатием мыши добавьте
объект в область построения.
Для детального описания свойств или особенностей узлов диаграммы размещения используют примечания (объект Note панели элементов). Примечания
не являются частью системы, т.е. не соответствуют какому-либо физическому
объекту, а служат лишь для описания еѐ компонент на диаграмме. Добавьте необходимые примечания для узлов рассматриваемой диаграммы, как показано
на Рис. 58.
Определите, согласно Рис. 58, необходимые ассоциации между компонентами системы (объектами диаграммы). Ассоциацию компонент системы с элементами-примечаниями можно установить, выбрав тип связи Generic Connector
– кнопка
панели элементов программы.
Содержание работы
1. Ознакомиться с теоретическими вопросами построения диаграммы размещения.
2. Построить с помощью программного средства Visual Paradigm for UML
диаграмму размещения для предметной области «Поликлиника».
3. Осуществить построение диаграммы размещения согласно индивидуальному заданию.
Требования к отчету
Отчет по лабораторной работе оформляется в печатном виде. Защита работы включает в себя проверку знания студентом теоретического материала, а
также практической части лабораторной работы.
Отчет должен включать:
диаграмму размещения для предметной области согласно выданному
индивидуальному заданию;
описание разработанной диаграммы.
Все примеры должны быть сохранены на сетевом диске или на диске студента.
ВАРИАНТЫ ЗАДАНИЙ
Вариант задания указывается преподавателем.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
Автострахование.
Агентство по сдаче автомобилей в аренду.
Аренда коньков, роликов, велосипедов, лыж.
Аэропорт – пассажирское расписание и перевозки.
Банковская система вкладов (физических и юридических лиц) .
Банковская система кредитования (физических и юридических лиц).
Биллинг сотовой компании.
Ветеринарная лечебница.
Клуб обучения танцам.
Магазин косметики.
Машиностроительное предприятие: система по разработке и модификации изделий (ведение архива, стандартов и пр.).
Нефтеперерабатывающая компания.
Парикмахерская.
Поставка вин.
Приемная комиссия ВУЗа.
Производство мебели (прием индивидуальных и типовых заказов и
изготовление).
Рекламное агентство.
Риэлторская компания: аренда; продажа первичного и вторичного
жилья.
Санаторий.
Система управления проектом для IT-компании.
Складская логистика.
Спа-салон (услуги, обслуживающий персонал и пр.).
Страховая компания.
Такси.
Транспортная логистика.
Туристическое агентство (путешествия за рубеж).
Туристическое агентство (путешествия по России).
Учет оборудования на крупном промышленном предприятии.
Филармония.
Электронный проездной.
ПРИЛОЖЕНИЕ
Табл. 2. «Жесты», используемые при создании элементов диаграмм
Основные
команды
Свойства диаграммы
Найти расположение диаграммы
Закрыть
диаграмму
Миниатюрное представ
ление диаграмм
Диаграмма
вариантов
использования
Вариант использования
Контейнер
Актер
Диаграмма
классов
Класс
Контейнер классов
Диаграмма
деятельностей
Действие
Деятельность
Начальный/конечный
элемент
Решение
Диаграмма
состояний
Состояние
Составное состояние
Начальный/конечный элемент
Компонент
Специализация класса
Элемент - контейнер
Диаграмма
компонентов
Диаграмма
развертывания
Узел сети
Компонент
Синхронизировать с диаграммой классов
Сущность
Взаимодействие
Решение
Начальный/конечный элемент
Синхронизировать с диаграммой взаимодействия
Линия жизни объекта
Актант
Специализация узла
Диаграмма
«Сущностьсвязь»
Диаграмма
представления взаимодействия
Диаграмма
последовательностей
Список используемых источников
1. Арлоу Д., Нейштадт И. UML 2 и Унифицированный процесс. Практический
объектно-ориентированный анализ и проектирование, 2-е издание. – Пер. с
англ. – СПб: Символ-Плюс, 2007. – 624 с., ил.
2. Вендров А.М. Практикум по проектированию программного обеспечения
экономических информационных систем: Учеб. Пособие. - М.: Финансы и статистика, 2004. - 192 с.: ил.
3. Леоненктов А.В. Обектно-ориентированный анализ и проектирование с использованием UML Rational Rose: Учебное пособие / А.В. Леоненков. – И.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2006. – 320 с.: ил. – (Серия «Основы информационных технологий).
4. Дж. Рамбо, М. Блоха. UML 2.0. Объектно-ориентированное моделирование и
разработка. 2-е изд. – СПб.: Питер, 2007. – 544 с.: ил.
5. Фаулер М., Скотт К. UML. Основы. – Пер. с англ. – СПб.: Символ-Плюс,
2002. – 192 с.: ил.
Документ
Категория
Без категории
Просмотров
0
Размер файла
1 824 Кб
Теги
modelirovanie, uml, yazik, 2010, metodichka, halimov, diyazitdinova, unifizirov
1/--страниц
Пожаловаться на содержимое документа