Диаграммы классов относятся к логическому представлению системы Logical View. На диаграмме Main представления Logical View обычно размещают главную диаграмму пакетов, а диаграммы классов помещают на другие листы этого представления. Для создания новой диаграммы классов выполним следующие шаги: щелкнуть правой кнопкой мыши по папке представления Logical View в навигаторе модели, в контекстном меню выбрать пункт Add Diagram, в списке выбрать диаграмму классов Class Diagram (рис. 38).
Рис. 38 - Добавление диаграммы классов
Будет создана новая диаграмма классов со стандартным именем ClassDiagram1, которое можно изменить в редакторе свойств диаграммы (рис. 39).
Рис. 39 - Редактор свойств диаграммы классов: изменение имени диаграммы
Пример. Рассмотрим сценарий Оформление заказа, который является внутренним потоком для прецедента Заказ товара. Опишем его классы.
Данный сценарий позволяет покупателю оформить заказ из корзины и оплатить его с использованием банковской карты.
Давайте представим, как выполняется этот сценарий, еще раз. Покупатель, находясь в своей покупательской корзине, приняв решение о том, что он готов сделать заказ в магазине «Style», выбирает опцию «Оформить заказ». Как реагирует система на действия покупателя? Запускается сценарий Оформление заказа. Пользователь должен на специальной форме внести свои личные данные, подтвердить заказ или нет, и в зависимости от этого произвести оплату, затем получить подтверждение заказа. В системе появляется новый объект – заказ покупателя.
Выбор граничных классов.
По всей видимости, нам нужен будет хотя бы один граничный класс, который осуществляет связь между действующим лицом Покупатель и дополнительным прецедентом Оформить заказ. Назовем его ОформлениеЗаказа (PlaceOrder). Этот класс знает, какие товары и в каком количестве были в корзине покупателя, их нужно перенести в заказ. Также этот класс может знать, пуста корзина покупателя или нет, и, если пуста, то вывести об этом соответствующее сообщение. Для того, чтобы сделать заказ, покупатель должен ввести свои личные данные, электронный адрес, телефон и данные кредитной карты. Для этих целей мы введем еще один класс ВводЛичныхДанных (EnterPersonalInformation). После того, как выбраны товары и введена личная информация покупателя, остается только проверить детали заказа и согласиться с ними или нет – для этого действия введем класс ПроверкаДеталейЗаказа (ConfirmOrder). Наконец, когда покупатель завершит оформление заказа, то на экране он видит номер заказа и подтверждение заказа отправляется покупателю на электронный адрес, для выполнения этих обязанностей создадим еще один граничный класс ПодтверждениеЗаказа (OrderConfirmation)
Выбор управляющих классов.
Создадим один управляющий класс, который будет распределять обязанности других классов и вызывать их операции при выполнении данного сценария. Назовем этот управляющий класс МенеджерОформленияЗаказа (PlaceOrderManager).
Выбор классов-сущностей.
В сценарии Оформление заказа речь идет о покупателе, заказе и товарах. Создадим классы-сущности Покупатель (Customer), Заказ (Order), Товар (Item).
Возможно, что в ходе дальнейшего проектирования какие-то новые классы будут добавлены для этого сценария, а какие-то, напротив, из этой диаграммы удалены.
Построим диаграмму классов сценария Оформление заказа в StarUML.
Создайте в пакете Logical View диаграмму классов описанным выше способом. Переименуйте ClassDiagram1 в Place Order (Оформление Заказа).
Создадим новый класс Покупатель (Customer). Щелкните правой кнопкой мыши по Logical View в навигаторе модели, в контекстном меню выберите пункт Add (Добавить), затем выберите пунскт Class (Класс). Новый класс будет создан и отобразится в навигаторе модели. На вкладке Properties (Свойства) измените имя класса на Покупатель (Customer). Заметим, что при таком способе создания класса, StarUML создает новое пространство имен. Если вы хотите создать класс, который носит такое же имя, как, например, действующее лицо на диаграмме прецедентов, то для того, чтобы StarUML «разрешил» использовать это имя еще раз, нужно создать класс способом, описанным выше. Теперь перетащите этот класс из навигатора модели на лист диаграммы Place Order (рис. 40).
Рис. 40 - Создание класса Покупатель
Для того чтобы создать класс ОформлениеЗаказа (PlaceOrder), используем другой метод. Слева на панели инструментов (Toolbox) щелкните изображение класса (Class), затем щелкните на листе диаграммы Place Order в том месте, куда необходимо поместить класс, при этом стандартное имя класса станет активным, давая возможность его изменить. Измените имя класса на ОформлениеЗаказа (PlaceOrder) (рис. 41).
Рис. 41 - Создание класса ОформлениеЗаказа
Создадим все остальные классы, наша диаграмма классов представлена на рисунке 42.
Рис. 42 - Диаграмма классов сценария Оформление заказа
Замечание. Мы выполняем диаграммы классов и взаимодействия на английском языке, так как эти диаграммы участвуют в генерации программного кода системы. Конечно, если мы бы мы выполнили их на русском языке, ничего страшного не случилось бы, но сгенерированный код содержал бы имена на кириллице, и для дальнейшего использования программного кода нам пришлось бы их все заменить. Для удобства читателя мы приводим соответствующие переводы фраз и названий.
Назначение стереотипов
Чтобы присвоить классу один из стереотипов UML, нужно выделить класс щелчком правой кнопки мыши, открыть редактор свойств Properties на инспекторе модели и выбрать раздел стереотип Stereotype (рис. 43).
Рис. 43 - Назначение стереотипа классу
Если мы нажмем на значок ..., то в появившемся диалоге нам будет представлен список доступных стереотипов с кратким описанием и графическим обозначением. Для того чтобы присвоить классу стереотип, нужно выбрать его в списке, выделить и нажать кнопку OK (рис. 44).
Рис. 44 - Выбор стереотипа
После присвоения классу стереотипа его внешний вид изменится. Рядом с именем класса появится имя стереотипа, заключенное в угловые скобки (рис. 45).
Рис. 45 - Отображение стереотипа класса
Пример. Присвоим классам сценария Оформление заказа соответствующие стереотипы. Диаграмма классов изменится (см. рис. 46).
Рис. 46 - Диаграмма классов сценария Оформление заказа со стереотипами
Мы можем отобразить стереотипы классов с помощью пиктограмм. Для этого нужно выделить класс, щелкнуть по выделенной области правой кнопкой мыши, в контекстном меню выберите пункт Format, затем выберите пункт Stereotype Display, далее в списке выберите Iconic (рис.47).
Рис. 47 - Задание отображения стереотипов классов в виде пиктограмм
Классы будут отображаться как пиктограммы (рис. 48).
Рис. 48 - Отображение классов с помощью пиктограмм стереотипов
Пример. Диаграмму классов сценария Оформление заказа отобразим с помощью пиктограмм (см. рис. 49).
Рис. 49 - Диаграмма классов сценария Оформление заказа в пиктограммах
Пакеты в UML
Если в нашей модели немного классов, то нам легко ими управлять, однако многие системы содержат большое количество классов, поэтому необходим механизм, позволяющий классы группировать и облегчающий их повторное использование. Таким механизмом в UML являются пакеты.
Пакет (package) — общецелевой механизм для организации различных элементов модели в группы.
Подпакет (subpackage) — пакет, который является составной частью другого пакета.
Пакет в логическом представлении модели – это объединение классов или других пакетов. С помощью объединения классов в пакеты мы можем получить представление о системе на более высоком уровне. Напротив, рассматривая пакет, мы получаем более детальное представление модели.
Объединять классы в пакеты можно как угодно, однако, существует несколько наиболее распространенных подходов.
- можно группировать классы по стереотипам: классы-сущности, граничные и управляющие классы.
- группировка классов по их функциональности: например, пакет классов, отвечающих за безопасность системы или пакет классов Работа с сотрудниками и т.п.
- наконец, применяют комбинацию двух указанных методов.
В дальнейшем можно вкладывать пакеты друг в друга.
Чаще всего пакет на диаграмме изображается в виде папки с закладкой с именем пакета (рис. 50).
Рис. 50 - Пакет
Главную диаграмму пакетов системы обычно помещают диаграмме Main представления Logical View. Для того чтобы создать пакет на диаграмме, нужно открыть рабочее поле диаграммы, щелкнуть по элементу пакет Package на панели элементов слева, затем щелкнуть по рабочему полю диаграммы в том месте, где вы хотите поместить пакет. В окне редактора свойств можно задать новое имя пакета.
Чтобы разместить классы по пакетам, используют метод перетаскивания: на навигаторе модели нужно перетащить, удерживая левую кнопку мыши, классы в соответствующие пакеты на навигаторе модели.
Пример. Созданные ранее классы сценария Оформление заказа сгруппируем по пакетам, диаграмму пакетов поместим на листе Main представления Logical View. Создадим пакеты Граничные классы, Классы-сущности, Управляющие классы (рис. 51).
Рис. 51 - Диаграмма пакетов
Перетащим на навигаторе модели класс Customer (Покупатель) в пакет Классы-сущности (рис. 52).
Рис. 52 - Перемещение классов в пакеты
Аналогично классы Item (Товар) и Order (Заказ) разместим в пакете Классы-сущности, классы ОформлениеЗаказа (PlaceOrder), ВводЛичныхДанных (EnterPersonalInformation), ПроверкаДеталейЗаказа (ConfirmOrder) и ПодтверждениеЗаказа (OrderConfirmation) разместим в пакете Граничные классы, а класс МенеджерОформленияЗаказа (PlaceOrderManager) – в пакете Управляющие классы.
Обратите внимание, что при этом внешний вид диаграмм классов Place Order и диаграммы пакетов Main не изменится.
Задание
Для выбранного варианта в StarUML, используя подход RationalApproach, разработать:
- основную диаграмму вариантов использования для проектируемой системы;
- для выбранных двух основных прецедентов:
- поясняющие диаграммы вариантов использования;
- потоки событий;
- для выбранных двух дополнительных прецедентов:
- диаграммы деятельности;
- диаграммы классов со стереотипами;
- разместить по пакетам созданные классы для каждой диаграммы классов.
Варианты
1. Программный модуль «Информационная система библиотеки». Приложение позволяет искать книги в своем каталоге, учитывать выдачу книг на руки и возврата книг, а также добавлять книги в фонд и списывать их.
2. Программный модуль «Кафедра». Содержит сведения о сотрудниках кафедры (ФИО, должность, ученая степень, дисциплины, нагрузка, общественная работа, совместительство и др.). Модуль предназначен для использования сотрудниками отдела кадров и деканата.
3. Программный модуль «Лаборатория». Содержит сведения о сотрудниках лаборатории (ФИО, пол, возраст, семейное положение, наличие детей, должность, ученая степень). Модуль предназначен для использования сотрудниками профкома и отдела кадров.
4. Программный модуль «Химчистка». При записи на обслуживание заполняется заявка, в которой указываются ФИО владельца, описание изделия, вид услуги, дата приема заказа и стоимость услуги. После выполнения работ распечатывается квитанция.
5. Программный модуль «Поликлиника». Приложение должно позволяет ставить и снимать больных с учета, записывать больных на прием к врачам, учитывать факт приема, а также вести историю болезни (медицинскую карту) больного.
6. Программный модуль «Картотека автомагазина». В базе содержатся сведения об автомобилях (марка, объем двигателя, дата выпуска и др.). При поступлении заявки на покупку производится поиск подходящего варианта. Если такого нет, клиент заносится в клиентскую базу и оповещается, когда вариант появляется.
7. Программный модуль «Картотека абонентов АТС». Картотека содержит сведения о телефонах и их владельцах. Фиксирует задолженности по оплате (абонентской и повременной).
8. Программный модуль «Автокасса». Содержит сведения о наличии свободных мест на автобусные маршруты. В базе должны храниться сведения о номере рейса, маршруте, водителе, типе автобуса, дате и времени отправления, а также стоимости билетов. При поступлении заявки на билеты программа производит поиск подходящего рейса.
9. Программный модуль «Книжный магазин». Содержит сведения о книгах (автор, название, издательство, год издания, цена). Покупатель оформляет заявку на нужные ему книги, если таковых нет, он заносится в базу и оповещается, когда нужные книги поступают в магазин.
10. Программный модуль «Автостоянка». Содержитс информация о марке автомобиля, его владельце, дате и времени въезда, стоимости стоянки, скидках, задолженности по оплате и др.
11. Программный модуль «Учет успеваемости студентов». Предназначен для оперативного учета успеваемости студентов в сессию деканом, заместителями декана и сотрудниками деканата. Сведения об успеваемости студентов должны храниться в течение всего срока их обучения и использоваться при составлении справок о прослушанных курсах и приложений к диплому.
12. Программный модуль «Личные дела студентов». Предназначен для получения сведений о студентах сотрудниками деканата, профкома и отдела кадров. Сведения должны храниться в течение всего срока обучения студентов и использоваться при составлении справок и отчетов.
13. Программный модуль "Информационная система склада".
Предназначен для учета поступления и списание товаров со склада, а также для определения места хранения товаров на складе.
14. Программный модуль «Информационная система технической экспертизы». Позволяет соискателям грантов подавать заявки, независимым экспертам оценивать заявки, а держателям фонда принимать решение о выдаче гранта по результатам экспертизы заявок.
15. Программный модуль «Органайзер». Предназначен для записи, хранения и поиска адресов и телефонов физических лиц и организаций, а также расписания, встреч и др.
Рекомендуемые источники
- Шмуллер Д. Освой самостоятельно UML 2 за 24 часа. Практическое руководство / Шмуллер Д.; пер. с англ. - М.: Вильямс, 2005. - 416 с.: ил. - ISBN 0-672-32640-X;
- Арлоу Д. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2е издание / Арлоу Д., Нейштадт И.; пер. с англ. - Спб: Символ-Плюс, 2007. - 624с.: ил. - ISBN 978-5-93286-094-6;
- Национальный открытый университет «Интуит» / Нотация и семантика языка UML. URL: http://www.intuit.ru/studies/courses/32/32/info
- Национальный открытый университет «Интуит» / Введение в UML. URL: http://www.intuit.ru/studies/courses/1007/229/info
Дата: 2018-12-28, просмотров: 3941.
