Полезное:
Как сделать разговор полезным и приятным
Как сделать объемную звезду своими руками
Как сделать то, что делать не хочется?
Как сделать погремушку
Как сделать так чтобы женщины сами знакомились с вами
Как сделать идею коммерческой
Как сделать хорошую растяжку ног?
Как сделать наш разум здоровым?
Как сделать, чтобы люди обманывали меньше
Вопрос 4. Как сделать так, чтобы вас уважали и ценили?
Как сделать лучше себе и другим людям
Как сделать свидание интересным?
Категории:
АрхитектураАстрономияБиологияГеографияГеологияИнформатикаИскусствоИсторияКулинарияКультураМаркетингМатематикаМедицинаМенеджментОхрана трудаПравоПроизводствоПсихологияРелигияСоциологияСпортТехникаФизикаФилософияХимияЭкологияЭкономикаЭлектроника
Пример выполнения. Создание диаграмм классов
Цель работы
Получить навыки построения диаграмм классов, создания пакетов и группировки классов в пакеты в среде визуального объектно-ориентированного моделирования систем IBM Rational Rose Enterprise.
Темы для предварительной проработки
- Классы, их атрибуты, операции и параметры, отношения зависимости, ассоциации, агрегации, композиции, обобщения и реализации.
- Работа с диаграммами классов в IBM Rational Rose (см. Справочные данные IBM Rational Rose).
Подготовка к работе
- Изучить ER-диаграмму предметной области индивидуального задания, добавив необходимые данные.
- Определить классы, их атрибуты и отношения между классами.
- Утвердить результаты предварительной подготовки у преподавателя.
Выполнение работы
- Запустить среду IBM Rational Rose Enterprise.
- Создать диаграмму классов для одного из сценариев диаграммы прецедентов, созданной в лабораторной работе №1. Для каждого класса необходимо задать атрибуты и операции. Каждый класс должен быть подробно документирован - необходимо задать текстовое описание самого класса, описания его атрибутов и операций.
- Создать пакеты для группировки созданных в предыдущем пункте классов.
- Сгруппировать ранее созданные классы в пакеты.
- Для каждого пакета создать свою диаграмму классов.
- Разработать главную диаграмму классов.
- Выполнить количественную оценку созданных диаграмм классов.
Содержание отчета
- Протокол создания диаграмм классов в среде IBM Rational Rose Enterprise.
- Созданные диаграммы классов с указанием сценария, для которого данные диаграммы построены.
- Краткое описание каждого созданного класса и отношений между классами.
- Расчет количественной оценки созданных диаграмм классов.
- Краткие выводы о навыках, приобретенных в ходе выполнения работы.
Пример выполнения. Создание диаграмм классов
Примечание: рассматривать диаграмму классов рекомендуется с концептуальной точки зрения, которая используется на начальных этапах моделирования и разработки.
Создание диаграммы классов для сценария "Добавить новый заказ" прецедента "Работа с заказом"
Диаграммы классов будем рассматривать с концептуальной точки зрения. Для упрощения задачи и чтобы не загромождать диаграммы несущественными деталями методы setX, getX для каждого атрибута Х классов задавать не будем.
Создадим в Логическом представлении браузера новую диаграмму классов и назовем ее " Add New Order ". В поле документации запишем для нее следующий текст: " Диаграмма классов для сценария "Добавить новый заказ" прецедента "Работа с заказом".
Заполнение диаграммы начнем с определения классов-сущностей. Рассматриваемый сценарий состоит из:
- самого заказа;
- клиента, который делает заказ;
- комплектующих изделий, которые входят в заказ.
Создадим классы-сущности Client (Клиент), Order (Заказ) и ComponentPart (Комплектующее изделие). Поскольку в один заказ может входить много разных комплектующих изделий, и одно комплектующее изделие может входить во много заказов, то введем еще один класс-сущность OrderItem (Состав заказа). Опишем каждый класс.
Таблица 2.1
Класс Client
| Параметр | Значение |
| Комментарий | Класс, представляющий собой клиента фирмы |
| Атрибуты | name: String - наименование клиента address: String - адрес клиента phone: String - телефон клиента Все атрибуты имеют модификатор доступа - private |
| Операции | AddClient() - добавление нового клиента RemoveClient() - удаление существующего клиента GetInfo() - получить информацию о клиенте Все операции имеют модификатор доступа - public |
Таблица 2.2
Класс Order
| Параметр | Значение |
| Комментарий | Класс, представляющий собой заказ, который делает клиент |
| Атрибуты | orderNumber: Integer - номер заказа orderDate: Date - дата оформления заказа orderComplete: Date - дата выполнения заказа Все атрибуты имеют модификатор доступа - private |
| Операции | Create() - создание нового заказа SetInfo() - занести информацию о заказе GetInfo() - получить информацию о заказе Все операции имеют модификатор доступа - public |
Таблица 2.3
Класс ComponentPart
| Параметр | Значение |
| Комментарий | Класс, представляющий собой комплектующие изделия |
| Атрибуты | name: String - наименование manufacturer: String - производитель price: Double - цена за единицу description - описание Все атрибуты имеют модификатор доступа - private |
| Операции | AddComponent() - добавление нового комплектующего изделия RemoveComponent() - удаление комплектующего изделия GetInfo() - получить информацию о комплектующем изделии Все операции имеют модификатор доступа - public |
Таблица 2.4
Класс OrderItem
| Параметр | Значение |
| Комментарий | Класс, представляющий собой пункт заказа, который делает клиент |
| Атрибуты | itemNumber: Integer - номер пункта заказа quantity: Integer - количество комплектующих изделий price: Double - цена за единицу Все атрибуты имеют модификатор доступа - private |
| Операции | Create() - создание новой строки заказа SetInfo() - занести информацию о строке заказа GetInfo() - получить информацию о строке заказа Все операции имеют модификатор доступа - public |
Результат создания классов-сущностей показан на рис. 2.1:
Рис. 2.1. Созданные классы-сущности
Добавим отношения между классами (рис. 2.2):
- класс Client и Order - отношение ассоциации, поскольку данные два класса просто связаны друг с другом и никакие другие типы связей здесь применить нельзя. Один клиент может сделать несколько заказов, каждый заказ поступает только от одного клиента, поэтому кратность связи со стороны класса Client - 1, со стороны Order - 1..n;
- класс Order и OrderItem - отношение композиции, поскольку строка заказа является частью заказа, и без него существовать не может. В один заказ может входить несколько строк заказа, строка заказа относится только к одному заказу, поэтому кратность связи со стороны Order - 1, со стороны OrderItem - 1..n;
- класс OrderItem и ComponentPart - отношение агрегации, поскольку комплектующие изделия являются частями строки заказа, но и те, и другие, являются самостоятельными классами. Одно комплектующее изделие может входить во много строк заказа, в одну строку заказа входит только одно комплектующее изделие, поэтому кратность связи со стороны ComponentPart - 1, со стороны OrderItem - 1..n.
Рис. 2.2. Классы-сущности и отношения между ними
Добавим теперь на диаграмму граничные (стереотип boundary) и управляющие (стереотип control) классы (рис. 2.3). Рассматриваемый сценарий - это только одно из действий, которые обеспечивает прецедент "Работа с заказом". Прецедент также позволяет просмотреть, отредактировать или удалить заказ. Это означает, что необходимо предусмотреть механизм, который позволяет выбирать необходимое действие. Создадим для этого граничный класс OrderOptions (Параметры работы с заказом) с комментарием " Класс, обеспечивающий механизм работы с заказами ". Также создадим граничный класс AddNewOrder (Добавление нового заказа), который будет служить для добавления новых заказов (комментарий - " Класс служит для добавления новых заказов "). Отношение между этими классами - агрегация, поскольку в данном случае класс AddNewOrder рассматривается как часть класса OrderOptions, частями которого также будут классы для просмотра, редактирования и удаления заказов. Кратность связи 1 к 1, поскольку в состав класса OrderOptions входит только один класс AddNewOrder.
Перейдем теперь к управляющим классам. Добавим управляющий класс OrderManager (Менеджер по работе с заказами) с комментарием " Управляющий класс для обработки потока событий прецедента "Работа с заказами", который будет обеспечивать обработку потока событий для рассматриваемого прецедента. Данный класс будет связан с классами AddNewOrder и Order. Отношение между классами AddNewOrder и OrderManager - однонаправленная ассоциация с кратностью связи 1 к 1, поскольку один экземпляр класса AddNewOrder взаимодействует только с одним экземпляром класса OrderManager. Отношение между классами OrderManager и Order - однонаправленная ассоциация с кратностью связи 1 к 1..n, поскольку один класс OrderManager может взаимодействовать с несколькими классами Order.
Окончательный вариант диаграммы классов показан на рис. 2.3:
Рис. 2.3. Итоговая диаграмма классов
Создание пакетов
Пакеты предназначены для группировки элементов в группы по определенным критериям. В простейшем случае классы можно группировать по их стереотипам. Создадим три пакета: Entities (классы-сущности), Boundaries (граничные классы) и Control (управляющие классы). Для этого необходимо щелкнуть правой кнопкой мыши на Logical View (Логическое представление) браузера, в появившемся контекстном меню выбрать пункт New > Package (Создать > Пакет), и ввести имя пакета. Результат создания пакетов показан на рис.2.4:
Рис. 2.4. Созданные пакеты
В поле документации (Documentation) для каждого пакета зададим комментарий:
- для пакета Boundaries комментарий: пакет содержит граничные классы;
- для пакета Control комментарий: пакет содержит управляющие классы;
- для пакета Entities комментарий: пакет содержит классы-сущности.
Date: 2015-12-12; view: 840; Нарушение авторских прав; Помощь в написании работы --> СЮДА... |