задание_практика. Задание 1 построение диаграммы классов и диаграммы объектов в нотации uml краткие теоретические сведения
 Скачать 0.5 Mb.
|
|
ЗАДАНИЕ № 1 ПОСТРОЕНИЕ ДИАГРАММЫ КЛАССОВ И ДИАГРАММЫ ОБЪЕКТОВ В НОТАЦИИ UML Краткие теоретические сведения Диаграммы классов являются отправной точкой процесса разработки. Они помогают при анализе, позволяя аналитику общаться с клиентом в «привычных» ему терминах и стимулируя процесс выявления важных деталей в проблеме, которую требуется решить. Класс – это категория или группа вещей, которая имеет сходные атрибуты и общие свойства. Например, класс “Стена” описывает объекты с общими свойствами: высотой, длиной, толщиной, и т.д. При этом конкретные стены будут рассматриваться как отдельные экземпляры класса «стена». У каждого класса есть имя, (простое или составное, к которому спереди добавлено имя пакета, в который входит класс). Имя класса в пакете должно быть уникальным. Класс реализует один или несколько интерфейсов. Атрибут – это именованное свойство класса, включающее описание множества значений, которые могут принимать экземпляры этого класса. Класс может иметь любое число атрибутов или не иметь их вовсе. В языках высокого уровня, таких, как С++, Java, атрибуты соответствуют переменным, объявленным в классе. Атрибуты описывают перечень значений, в рамках которых указываются свойства объектов этого класса. Операция – это то, что может выполнять класс, либо то, что вы можете выполнять над данным классом. Рис.1. Атрибуты класса В UML имена классов чаще всего включают несколько слов. Каждое слово в имени класса начинается с прописной буквы, пробелы между словами отсутствуют. Имена атрибутов и операций строятся по тем же правилам, но первая буква является строчной (например, загрузитьПрограмму) Класс представляется прямоугольником, разделенным на три области: верхняя часть содержит имя класса средняя часть - атрибуты, нижняя часть – операции Рис.2. Список атрибутов класса Построение на примере PowerDesigner Рассмотрим основные возможности PowerDesigner при создании диаграммы классов: Создание класса – с помощью инструмента Class на панели инструментов Pallete. В свойствах (Class Properties) указывается: Вкладка General: Название класса и название в программном коде в полях Name и Code, Вкладка Attributes - вносятся атрибуты класса. Каждый атрибут имеет свои свойства, их можно указать в свойствах атрибута (для этого нажать на введенный атрибут два раза левой кнопкой мыши – откроется форма Attribute Properties). В свойствах атрибута заполняются поля Name и Code, выбираетсятип для каждого значения атрибута (строка Data Type). Для того чтобы указать значение атрибута по умолчанию, необходимо перейти на вкладку Detail ив поле Initial value вписать заданное значение. Вкладка Operations – вносятся операции, которые может выполнять данный класс. Каждая операция имеет свои свойства, их можно указать в свойствах операции (для этого нажать на введенный атрибут два раза левой кнопкой мыши – откроется форма Operation Properties). В свойствах операции заполняются поля Name и Code, выбираетсятип возвращаемого значения (строка Return Type). Также возможно указать параметры операции и их типы (вкладка Parameters) Если список атрибутов и/или операций слишком велик, можно уточнить информацию с помощью ключевого слова (стереотипа), поле Stereotype. Также дополнительную информацию можно внести в поле комментария Comment или присоединить комментарий к классу с помощью инструмента Note. Ассоциации: если классы взаимодействуют друг с другом, то такое взаимодействие называется ассоциацией и изображается в PowerDesigner при помощи инструмента Association. В свойствах (Association Properties) указывается: Вкладка General: название ассоциации и название в программном коде (поля Name и Code) Если один класс ассоциируется с другим, каждый из них играет свою роль в этой ассоциации. Роли указываются в полях Role A (для класса А) и Role В (для класса В) Рис.3. Взаимодействие классов Ассоциации могут работать в разных направлениях, а также могут быть более сложными - с одним классом может ассоциироваться несколько других. Подобно классам, ассоциация может иметь атрибуты и операции. Для отображения класса ассоциации в PowerDesigner используется тот же инструмент Association, но соединяются не два класса а ассоциация и класс. А класс ассоциации сам может быть связан с другими классами (см. рисунок). Кратность – количество объектов одного класса, которые могут быть связаны с определенным количеством объектов другого класса, см. рисунок (В PowerDesigner – открыть в свойствах ассоциации вкладку Detail и установитьуказать кратность в поле Multiplicity). Кратность может быть: 1:1, 1:m, m:1, m:m. Рис.4. Взаимодействие нескольких классов Класс может ассоциироваться сам с собой (рефлекторная ассоциация), см. пример на рисунке: Рис.5. Рефлекторная ассоциация Наследование: класс может наследовать атрибуты и операции другого класса. Наследующий класс является дочерним по отношению к родительскому, от которого он наследуется. Связь родительского и дочернего классов соответствует отношению является видом. В PowerDesigner для изображения наследования используется инструмент Generalization. Абстрактные классы предназначены только для использования в качестве базовых для наследования и не порождают своих объектов. Зависимость: взаимосвязь при использовании одного класса другим называется зависимостью. Наиболее общий случай зависимости – это использование одного класса в сигнатуре операции другого класса. Для изображения зависимости применяется инструмент Dependency. На примере ниже изображено два класса: Система и Форма. У класса Система есть операция отобразитьФорму (). Отображаемая системой форма зависит от того, какой экземпляр класса Форма выбрал пользователь. Рис.6. Зависимость классов Агрегация – взаимосвязь, при которой класс состоит из некоторого количества классов-компонентов, называется агрегацией. Компоненты и класс, который они составляют, находятся в ассоциации часть-целое. Агрегацию можно представить в виде дерева, корнем которого является «целое», а листьями – его компоненты. В PowerDesigner применяется инструмент Aggregation. Чтобы проиллюстрировать агрегацию на примере, смоделируем диаграмму меню в ресторане. В свойствах каждого класса и ассоциации необходимо указать все те поля, описание которых приведено выше. Рис.7. Агрегация классов Композит – это строгий тип агрегации, характеризующийся тем, что каждый элемент может принадлежать только одному целому. Например, компоненты стола – столешница и ножки – составляют композит. Для отображения в PowerDesigner используется инструмент Composition. Интерфейсы и реализация: Интерфейс - это набор операций, которые задают некоторые аспекты поведения класса и представляют его для других классов.. В PowerDesigner первый вариант - добавить с помощью инструмента Interface (свойства заполняются аналогично свойствам класса), второй вариант – добавить автоматически – нажать правой кнопкой мыши на созданный класс и в списке выбрать Create Interface (в этом случае операции, прописанные в созданном классе, добавятся автоматически). Взаимосвязь между классом и его интерфейсом называется отношением реализации (инструментRealization) Пример: при использовании автомата по продаже карт экспресс оплаты, мы взаимодействуем с ним через интерфейс. Отношение панели управления и автомата по продаже карт оплаты – это реализация, а отношение человека и интерфейса ПанельУправления – это зависимость (инструмент Dependency): Рис.8. Взаимодействие нескольких классов Видимость: данный термин применяется по отношению к атрибутам и операциям. Выделяют три области видимости: Открытая – могут использовать другие классы; Защищенная – могут использовать только наследники данного класса; Закрытая – используются только самими классами. В PowerDesigner видимость указывается в свойствах во вкладке General, в поле Visibility. Практические задания Разработать программное обеспечение для ресторана с удобным интерфейсом. Для этого необходимо: несколько окон пользовательского интерфейса. Системе нужны пользовательские интерфейсы карманного компьютера для ввода заказа, изменения заказа, контроля состояния заказа, состояния клиента и отправки сообщений помощнику и уборщику. Шеф-повар должен иметь возможность отслеживать заказ. Каждый пользователь данной системы должен иметь возможность ответить на вопросы клиента и отследить его состояние. Необходима база данных для записи всех заказов. Каждая запись должна содержать номер столика, пункты заказа, время внесения заказа, имя официанта, статус заказа (действителен или нет) и т.п. Должна быть подсистема обработки заказов, позволяющая передать заказ по назначению и зарегистрировать его в БД. Таким образом, в систему необходимо включить: Интерфейс пользователя, GUI Официанта, GUI Шеф-повара, Обработчик заказов, БД заказов. Смоделируйте диаграмму классов и добавьте операции каждому классу. ЗАДАНИЕ № 2 ПОСТРОЕНИЕ ДИАГРАММЫ ПРЕЦЕДЕНТОВ В НОТАЦИИ UML Краткие теоретические сведения Перед приобретением какого-либо продукта или системы, мы формируем список требований, которые желаем видеть в нашей покупке (например: возможности будущей системы, функции, которые она будет выполнять и т.д.), т.е. анализируем прецеденты (use-case analysis). Такой процесс играет особенно важную роль на этапе анализа системных требований. Способ использования системы пользователями определяет проектное решение, которое будет положено в ее основу. Прецедент - это конструкция, позволяющая описать систему с точки зрения потенциальных пользователей. Прецедент представляет собой набор сценариев использования системы. Каждый сценарий описывает последовательность действий. Каждая последовательность действий инициируется пользователем, другой системой, аппаратным средством или в какой-либо момент времени. Сущности, инициирующие сценарии, называются исполнителями (actor). Результат прецедента должен быть полезен исполнителю, инициировавшему этот прецедент, либо какому-то другому исполнителю. Прецедент заставляет потенциальных пользователей думать о системе со своих позиций. Пользователям не всегда легко выразить свои требования к системе. Основная идея - привлечь пользователей к разработке системы на ранних стадиях анализа и проектирования. Это повышает вероятность создания полезной системы, позволяет сконцентрироваться на мнении людей, а не на компьютерных понятиях, с которыми не могут работать реальные пользователи. Лучший способ определения прецедентов - это опрос. При этом, важно выявить предусловия для инициализации прецедента и постусловия, реализуемые в результате выполнения прецедента. Для аналитиков прецедент помогает определить способ использования системы. Для разработчиков - это полезный инструмент, предоставляющий надежную методику формирования требований к системе с точки зрения пользователя (заказчика). Представление модели прецедентов: Один исполнитель инициирует прецедент, а другой (возможно, инициатор, но необязательно) - получает новое качество от его реализации. Графически модель прецедентов представляется просто: эллипс соответствует прецеденту, а упрощенная фигурка представляет исполнителя. Инициирующий исполнитель находится слева от прецедента, принимающий исполнитель - справа. Взаимодействие исполнителя и прецедента обозначается с помощью сплошной соединительной линии. При выполнении анализа прецедентов определяются границы системы и ее связь с окружающим миром. Исполнители обычно находятся вне системы, а прецеденты - внутри. Для обозначения границ системы используется прямоугольник, внутри которого указывается имя системы. Исполнители, прецеденты и соединительные линии образуют модель прецедентов. Рис.9. Модель прецедентов Построение в PowerDesigner Рассмотрим построение прецедентов на примере модели автомата по продаже карт экспресс - оплаты: Создайте диаграмму Use-Case. Далее создайте 3 прецедента, используя инструмент Use-Case.Чтобы "сбросить" выбранный инструмент, выберите другой инструмент или нажмите на правую кнопку мыши. Чтобы изменить имя прецедента и другие свойства, нажмите два раза левой кнопкой мыши на объект. В открывшемся окне, в поле Name введите Покупка карты, а в поле Code введите название объекта, которое затем будет использоваться в программном коде (BuyCard). Остальные use-case переименуйте в соответствии с таблицей 1. Таблица 1-Виды Use-case Case_1 Покупка карты BuyCard Case_2 Заправка автомата Refuelling Case_3 Сбор денег GetMoney Создайте 6 исполнителей, нажав на кнопку actor. Переименуйте объекты в соответствии с таблицей 2. Таблица 2-Виды Use-case Actor_1 Покупатель Customer Actor_2 Покупатель Customer Actor_3 Специалист по заправке Refueller Actor_4 Специалист по заправке Refueller Actor_5 Инкассатор Collector Actor_6 Инкассатор Collector Создадим взаимосвязи между объектами. Взаимосвязи могут идти в двух направлениях: От исполнителя к прецеденту (Связь Primary actor) От прецедента к исполнителю (Связь Secondary actor) Создайте взаимосвязи от инициирующих исполнителей к прецедентам и от прецедентов к принимающим исполнителям с помощью инструмента Assosiation . Для этого подведите указатель к исполнителю, нажмите левую кнопку мыши и не отпуская подведите к прецеденту. Соедините объекты как показано на диаграмме: Рис.10. Модель прецедентов Чтобы повторно использовать шаги одного прецедента в другом, применяется включение. В нашем примере тоже можно использовать включение. Рассмотрим use-case Заправка автомата и Сбор денег. Они оба начинаются с разблокирования и открытия автомата и заканчиваются закрытием и блокировкой. Прецедент Проникновение внутрь включает первые два шага, а Выход наружу - два остальных. Прецеденты Заправка автомата и Сбор денег включают в себя прецеденты Проникновение внутрь и Выход наружу. Графически включение обозначается в виде соединительной пунктирной линии со стрелкой, указывающей на тот класс, от которого зависит другой (в PowerDesigner используется инструмент Dependency). В свойствах данного объекта необходимо в поле Stereotype указать слово <<включает>>. Модель прецедентов с включением должна выглядеть следующим образом: Рис.11. Модель прецедентов Можно расширить исходный (базовый) прецедент за счет добавления новых шагов. Данный тип взаимоотношений называется расширением. Расширение может происходить только на заданных точках последовательности шагов базового прецедента. Такие места называются точками расширения. Стереотип – позволяет создавать новые элементы UML на базе существующих. Имя стереотипа представляется в двух парах угловых скобок. Само имя стереотипа называется ключевым словом. Концепция стереотипа полезна при использовании автоматизированных средств моделирования. Такие средства позволяют создать «словарь» элементов, используемых в модели, - классов, прецедентов, компонентов и т.д. Словарь позволяет работать только с существующими элементами UML. А также со стереотипами, созданными на базе этих элементов. Словарь помогает управлять моделью и обеспечивает повторное использование элементов. В UML предусмотрен расширенный набор готовых стереотипов. Подобно включению, расширение отображается линией зависимости (пунктир со стрелкой) со стереотипом <<расширяет>> (инструмент Dependency). Расширим прецедент "Заправка автомата": в отличие от равномерного пополнения запасов всех сортов сиропа, этот прецедент позволяет пополнять автомат с учетом спроса. Диаграмма выглядит следующим образом: Рис.12. Модель прецедентов Практические задания Создайте 2 модели прецедентов, которые описывали бы работу библиотеки, причем в первой из них поиск книг осуществляется без помощи компьютера, а второй – с помощью компьютера. В модель с использованием ПК добавьте БД книг, в которой библиотекарь сможет искать нужную книгу, смотреть, где она лежит. Помимо БД книг, добавьте БД студентов, где будет храниться информация о каждом студенте и о книгах, которые он взял и должен отдать. Новая книга, добавляется к списку уже имеющихся у студента книг не вручную, а с помощью считывания штрих кода с книги. ЗАДАНИЕ № 3 ПОСТРОЕНИЕ ДИАГРАММЫ СОСТОЯНИЙ В НОТАЦИИ UML Краткие теоретические сведения Рассмотрим новую категорию элементов, которая позволяет описать поведение системы и показать, как части модели UML изменяются во времени. К одной из таких категорий относятся элементы диаграммы состояний. Изменение в системе можно охарактеризовать так: объекты изменяют свое состояние в ответ на происходящие события и с течением времени. Например, при щелчке на кнопке пульта дистанционного управления, телевизор изменяет свое состояние и показывает передачи другого канала и т.д. Поэтому Диаграмма состояний UML, охватывая приведенный выше тип изменения, представляет состояния объекта и переходы между ними, а также показывает начальное и конечное состояние объекта. Данная диаграмма значительно отличается от диаграммы классов, диаграммы объектов или диаграммы прецедентов. Диаграмма состояний показывает состояния одного объекта. Представление диаграммы состояний. Состояние изображается прямоугольником со скругленными углами, переход – сплошной линией со стрелкой. Закрашенный круг соответствует начальной точке последовательности состояний, а обведенный круг («глазок») представляет конечную точку. Рис.13. Модель состояний Причем, прямоугольник разделен на две части. Верхняя содержит имя состояния (которое нужно присвоить независимо от того, будут ли присутствовать другие элементы обозначения), а нижняя предназначена для размещения видов деятельности. Также необходимо уточнить, что переход зачастую происходит в ответ на переключающее событие и может вызывать выполнение некоторых действий. Например, можно указать событие, которое привело к переходу (переключающее событие) и выполняемые вычисления (действия), которые приводят к изменению состояния. Иногда событие вызывает переход баз всякого действия, иногда же переход происходит из-за того, что в текущем состоянии выполнены все действия (не из-за события). Такой тип перехода называется безусловным переходом. Необходимость создания диаграммы состояний На диаграмме состояний отображаются все переходы между состояниями одного объекта системы. Если информация слишком детализирована, то диаграмма вскоре слишком усложнится (и это необходимо). Диаграммы состояния используются аналитиками, проектировщиками и разработчиками для исследования поведения объектов в системе. Диаграмма классов и диаграмма объектов отображают только статическое состояние системы. На них представлены иерархии и ассоциации, и из них можно узнать о возможном перечне действий системы, но ничего нельзя узнать о деталях динамического поведения. Однако разработчики должны понимать поведение объектов, поскольку их задачей является реализация этого поведения в программном обеспечении. Просто разработать объект недостаточно: специалисты должны добиваться того, чтобы объект выполнял свои функции. Диаграммы состояний дают полную информацию о желаемом поведении. Ясное представление о поведении объекта повышает вероятность того, что группа разработчиков создаст систему, удовлетворяющую выдвинутым требованиям. Построение в PowerDesigner Рассмотрим построение диаграммы состояний в PowerDesigner на примере графического пользовательского интерфейса (GUI) компьютера. Предположим, что упрощенный интерфейс может находиться в одном из трех состояний: Инициализация Работа Завершение работы Причем, при включении компьютера происходит загрузка. Поэтому включение компьютера является переключающим событием, которое приводит к переходу интерфейса в состояние Инициализация, а загрузка – действие, происходящее во время перехода. Результатом выполнения действия в состоянии Инициализации является выработка переключающего события, которое вызывает переход в состояние Работа. При щелчке на кнопке завершения работы, осуществляется переход в состояние Завершение работы, и в конечном итоге компьютер выключается. Итак, создадим новую диаграмму: нажать правой кнопкой мыши в пустом месте рабочей области. Выбрать Диаграмма (Diagram) -> Новая Диаграмма (New Diagram) -> Диаграмма состояний (StateChart Diagram). Введите название диаграммы (в поле Name): «Диаграмма состояний GUI», а в Code укажите название диаграммы так, чтобы было понятно разработчикам, когда они будут реализовывать проект на определенном языке программирования, например, так: «StateChart_Digram_GUI». Чтобы название в поле Code не было таким же, как и в Name, отожмите кнопку «равно» справа от поля Code. Создайте 3 объекта с помощью инструмента State, который расположен на панели инструментов «Pallete». А также одно начальное (Start) и одно конечное состояние (End). Теперь, в свойствах переименуйте объекты состояний в соответствии с таблицей 3. Таблица 3 –Виды состояний Объекты состояний Название в поле Name Название в поле Code State_1 Инициализация Initialization State_2 Работа Work State_3 Завершение работы EndOfWork Далее, необходимо добавить состояния и переходы, для этого: откройте свойства объекта Инициализация и во вкладке Действия (Actions) с помощью кнопки Add a row , добавьте новое действие. В столбце Trigger Event выберите состояние выполнение (do), в столбце Name введите название действия Loading. Нажмите кнопку Применить для сохранения внесенных изменений. Соедините последовательно все объекты с помощью инструмента Transition и дайте названия переходам, как показано на рисунке. Для этого зайдите в свойства объекта Transition и во вкладке Trigger в поле Trigger Event создайте новое действие (кнопка Create ). В результате должна получится диаграмма, представленная ниже: Рис.14. Модель состояний Переход может происходить в случае специальных условий – так называемых условий перехода. Рассмотрим и дополним пример, приведенный выше: если на компьютере не выполняется никаких действий (в течение 15 минут), активизируется экранная заставка, т.е. пользовательский интерфейс переходит из состояния Работа в состояние отображение заставки. 15-минутный интервал в данном случае является условием перехода. Дополним нарисованную выше диаграмму: создадим еще одно состояние с названием «Отображение заставки» и два перехода. Переход от состояния «Отображение заставки» к «Работа» назовем «Нажатие клавиши или перемещение указателя». Для перехода от состояния Работа к состоянию Отображение заставки зададим условие, для этого откроем окно со свойствами перехода, перейдем на вкладку «Условие» (Condition) и в поле Alias введем условие: время истекло. Условие отображается на диаграмме в квадратных скобках. После сохранения должно получиться следующее: Рис.15. Модель состояний Практические задания Создайте диаграмму состояний, описывающую работу пользовательского интерфейса для резервирования мест в ресторане. Чтобы пойти в ресторан, клиент резервирует себе стол на определенную дату и время, используя специальный интерфейс. Клиент входит в систему, с помощью карты постоянного клиента, если данные неверны, то выход. Если все нормально, клиент выбирает дату и время, указывает стол, где хотел бы сидеть, система сохраняет введенные данные, печатает чек клиенту с информацией о забронированном месте, закрывает сеанс (выход пользователя из системы) и отправляет информацию управляющему, который дает всем необходимые указания. |