МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ
федеральное государственное автономное образовательное учреждение высшего образования
«САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ АЭРОКОСМИЧЕСКОГО ПРИБОРОСТРОЕНИЯ»
На правах рукописи
Шахомиров А.В.
Объектно-ориентированный анализ и проектирование на примере диаграмм языка UML
(часть 3)
Методические указания к выполнению лабораторных работ
Санкт-Петербург 2019-2021
Введение
В современной практике проектирования сложных систем и, в частности программного обеспечения, в настоящее время стали широко применяться визуальные модели, которые представляют собой средства для описания, проектирования и документирования архитектуры системы. Таким образом, модели строятся для того, чтобы понять и осмыслить структуру и поведение будущей системы, облегчить управление процессом ее создания и уменьшить возможный риск, а также документировать принимаемые проектные решения.
Одним из факторов, от которых зависит успех проекта, является наличие строгого стандартного языка моделирования. Таким языком является унифицированный язык моделирования UML (Unified Modeling Language). Построение моделей и диаграмм UML выполняется с помощью различных программных систем автоматизации проектирования, так называемых CASE –средств (Computer Aided Software Engineering). В качестве такого средства все часто используется IBM Rational Rose.
2
Диаграммы классов
Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними. На диаграмме классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами. Диаграммы классов используются непосредственно для получения программного кода системы. Диаграмма классов для прецедента «Снять деньги со счета» показана на рисунке 3.1.
<<Form>>
Устройство_для_чтения_карточек
номер_карточки : Integer
Ввести_карточку() 
выдать_карточку()
+uu 0..1
<<Form>>
Экран_банкомата
PIN : Integer
сколько_денег : Currency прецедент : String
Сообщение()
Ввести_сообщение(ввод : Integer)
+ee
0..1
+mm +mm
<<control>>
Менеджер_банкомата
открыть_счет() +mm
сверка_PIN() : Boolean выдать() : Long снять() : Long
+mm
|
0..* |
0..* |
|
|
|
|
|
|
|
|
<<entity>> |
|
|
Счет |
|
|
|
+sc |
номер_счета_ : Integer |
|
|
PIN : Integer |
|
|
баланс : Long |
|
|
номер_карточки : Integer |
|
|
|
|
|
Открыть() : Integer |
|
|
Найти(счет : Long) : Integer |
|
|
Проверить_найденное() : Integer |
|
|
Вычеркнуть_найденное(счет : Long) : Integer |
|
|
|
|
|
1 |
|
+ka |
0..1 |
|
|
|
|
<<Form>>
Кассовый_аппарат 
кассовый_баланс : Long
Снабжать_кассу() 
Давать_расписку()
Рисунок 3.1. Диаграмма классов для прецедента Снять деньги со счета
3
Примечание: диаграмму классов можно создавать для каждого прецедента отдельно. Но должна быть и обобщенная диаграмма классов всего проекта, где будет учтено, что некоторые классы на различных диаграммах могут быть синонимами, могут выполнять одинаковый функционал, могут выполнять обобщенный функционал отдельных классов с других диаграмм. Поэтому построение единой диаграммы классов для всего проекта в целом, является необходимым.
Как видно из рисунка, для рассматриваемого прецедента задействованы пять классов:
-Устройство для чтения карточек (uu)
-Счет (sc)
-Экран банкомата (ee)
-Кассовый аппарат (ka)
-Менеджер банкомата (mm)
Каждый класс на диаграмме изображается в виде прямоугольника, разделенного на три части. В первой содержится имя класса, во второй – его атрибуты, в третьей – операции класса, отражающие его поведение (действия, выполняемые классом). Например, для класса по имени Счет определены атрибуты: Номер счета, PIN и Баланс,
а также операции: Открыть, Найти, Проверить наличие найденного и Вычесть найденное.
Связывающие классы линии отражают взаимодействие между классами. Для каждого класса указываются стереотипы.
Стереотипы – это механизм, позволяющий разделять классы на категории. В языке UML основными стереотипами являются:
-Boundary (граница);
-Entity (сущность);
-Control (управление).
Граничные классы (Boundary classes) – это классы, которые расположены на границе системы и окружающей среды. Они включают все формы, отчеты, интерфейсы с аппаратурой (такой, как принтеры, сканеры) и интерфейсы с другими системами.
Для того чтобы найти граничные классы, надо исследовать диаграммы прецедентов. Каждому взаимодействию между актером и прецедентом должен соответствовать, по крайней мере, один граничный класс. Так, например, на рисунке. 3.1 4
взаимодействию между клиентом и каждым из связанных с ним прецедентов поставлен в соответствие граничные классы Экран банкомата и Устройство для чтения карточек, а взаимодействию между прецедентами Снять деньги со счета, Просмотреть баланс и
клиентом – граничный класс Кассовый аппарат.
Классы – сущности (Entity classes) отражают основные сущности предметной области. Обычно для каждого класса-сущности создается таблица в базе данных. На рисунке 3.1 таким классом является Счет.
Управляющие классы (Control classes) отвечают за координацию действий других классов. Обычно у каждого прецедента имеется один управляющий класс, контролирующий последовательность событий этого прецедента. Его часто называют классом-менеджером.
В системе могут быть и другие управляющие классы, общие для нескольких прецедентов. Например, класс Менеджер безопасности, отвечающий за контроль событий, связанных с безопасностью, или класс Менеджер транзакций, занимающийся координацией сообщений, относящихся к транзакциям с базой данных. В рассматриваемом примере таким классом является Менеджер банкомата.
Атрибуты содержатся внутри класса. Для атрибута нужно определить область видимости:
-Public (общий, открытый) предполагает, что атрибут будет виден всеми остальными классами, которые могут изменить его значение.
-Private (закрытый) предполагает, что атрибут не виден никаким другим классам, а поэтому другие классы не могут этот атрибут редактировать.
-Protected (защищенный) доступен только самому классу и его потомкам.
-Package or Implementation (пакетный) является общим, но только в пределах
его пакета.
В общем случае рекомендуется атрибуты делать закрытыми или защищенными. Это позволяет лучше контролировать сам атрибут и код, а также избежать ситуации, когда значение атрибута изменяется всеми классами системы. Задаваемые параметры видимости повлияют на генерируемый код.
Операции реализуют связанное с классом поведение. Операция включает три части: имя, параметры (аргументы, получаемые операцией на входе) и тип возвращаемого значения.
В языке UML операции имеют следующую нотацию:
5
Имя_операции (аргумент1: тип_данных_аргумента1, аргумент2: тип_данны_аргумента2,… : тип_возвращаемого_значения;
Используются четыре различных типа операций:
-Операции реализации (implementor operations) реализуют некоторые бизнесфункции. Такие операции можно найти в диаграммах взаимодействия. Каждое сообщение диаграммы скорее всего можно соотнести с операцией реализации.
-Операции управления (manager operations) управляют созданием и уничтожением объектов. В эту категорию попадают конструкторы и деструкторы классов.
-Операции доступа (access operations) существуют для того, чтобы просматривать или изменять значения атрибутов других классов. При реализации кода этим операциям соответствуют функции Get, Let или Get, Set (получение и изменение значений). Использование операций доступа дает возможность безопасно инкапсулировать атрибуты внутри класса, защитив их от других классов, но все же позволяет осуществить к ним контролируемый доступ. Использование операций получения и изменения значений (Get, Let и Get Set) для каждого атрибута класса является стандартом.
-Вспомогательные операции (helper operations) необходимы классу для выполнения его ответственностей, но о которых другие классы не должны ничего знать. Это закрытые и защищенные операции класса.
В процессе генерации кода для каждой операции будет создана процедура типа Function, если задан тип возвращаемого значения, и типа Sub/Procedure – если не задан. Для каждого аргумента будет создана переменная соответствующего типа.
Связь представляет собой семантическую взаимосвязь между классами. Возможны четыре типа связей:
-Ассоциации
-Зависимости
-Агрегации
-Обобщения.
6
Ассоциации (association) – это семантические связи между классами. Они изображаются линиями на диаграмме. Ассоциации могут быть двунаправленными и однонаправленными. На языке UML двунаправленные ассоциации рисуют в виде простой линии без стрелок или со стрелками с обеих сторон (см. рисунок 3.2). На однонаправленной ассоциации изображают только одну стрелку, показывающую ее направление.
Направление ассоциации можно определить, изучая диаграммы последовательности и кооперативные диаграммы. Если все сообщения на них отправляются только одним классом, а не наоборот, между этими классами имеет место однонаправленная связь. Если хотя бы одно сообщение отправляется в обратную сторону, ассоциация должна быть двунаправленной.
Ассоциации могут быть рефлексивными, когда предполагается, что один экземпляр класса взаимодействует с другими экземплярами этого же класса.
<<Class Module>> NewClass
<<Class Module>> NewClass2
Рисунок 3.2. Двунаправленная ассоциация
Зависимости (dependency) всегда однонаправлены и показывают, что один класс зависит от определений, сделанных в другом. Зависимости изображают на диаграмме в виде стрелки, проведенной пунктирной линией (см. рисунок 3.3). При генерации кода для этих классов к ним не будут добавляться новые атрибуты. Однако будут созданы специфические для языка операторы, необходимые для поддержки связи. Например, на языке С++ в код войдут необходимые операторы #include.
<<Class Module>> |
|
<<Class Module>> |
NewClass |
|
NewClass2 |
|
|
|
|
|
|
Рисунок 3.3. Зависимости
Агрегации (aggregations) представляют собой более тесную форму ассоциации. Агрегация – это связь между целым и его частью. Например, целое – автомобиль – и части
– двигатель, колеса и пр. На диаграмме агрегация изображается в виде линии с ромбиком у класса, являющимся целым (см. рисунок 3.4).
7
<<Class Module>> |
|
<<Class Module>> |
Whole |
|
Part |
|
||
|
|
|
|
|
|
Рисунок 3.4. Агрегация
В дополнение к простой агрегации UML использует более сильную разновидность агрегации – композицию. Согласно композиции объект-часть может принадлежать только единственному целому, и, кроме того, зачастую жизненный цикл частей совпадает с циклом целого: они живут и умирают вместе с ним. Любое удаление целого распространяется на его части.
Такое каскадное удаление нередко рассматривается как часть определения агрегации, однако оно всегда подразумевается в том случае, когда множественность роли составляет 1..1 (один-к-одному). Например, если необходимо удалить клиента, то это удаление должно распространится и на заказы.
Обобщения (generalization) показывают связи наследования между двумя классами. Она позволяет одному классу наследовать все атрибуты, операции и связи другого. На языке UML связи наследования называют обобщениями и изображают в виде стрелок от класса-потомка к классу-предку (см. рисунок 3.5).
<<Class Module>> NewClass1
<<Class Module>> NewClass1_1
<<Class Module>> NewClass1_2
Рисунок 3.5. Обобщение
Для связи могут быть указаны параметры связи:
-Имена связей (или ролевые имена) – обычно глагол, например, поставляет.
Имя связи указывать необязательно. Обычно это делается, если причина связи не очевидна. Имя пишется около линии связи.
8
-Множественность (multiplicity) показывает, сколько экземпляров одного класса взаимодействуют с помощью этой связи с одним экземпляром другого класса в данный момент времени. Например, пусть имеется два класса Дисциплина и Студент. Предположим, что каждый студент может посещать занятия по дисциплинам (от 0 до 4-х), а на занятии по одной дисциплине может присутствовать от 10 до 20 студентов. Тогда для связи между классами нужно указать множественность связи, как показано на рисунке 3.6.
<<Class Module>> |
|
|
<<Class Module>> |
|
Course |
|
|
Student |
|
0..4 |
10..20 |
|||
|
|
|||
|
|
Рисунок 3.6. Множественность
В языке UML приняты следующие нотации для обозначения множественности:
0 |
Ноль |
1 |
Один |
Zero or More |
(0…*) |
One or More |
(1…*) |
Zero or One |
(0…1) |
n |
( * ) |
Unspecified multiplicity |
множественность не определена |
9
Создание диаграммы классов в Rational Rose
Для создания диаграммы классов, изображенной на рисунке 3.1, нужно выполнить следующую цепочку действий:
1.На папке Logical View в браузере объектов открыть к.з. меню и исполнить команду New/Class Diagram и дать диаграмме имя по имени прецедента
Снять деньги со счета.
2.Создать 5 классов: Устройство для чтения карточек, Экран банкомата, Счет, Кассовый аппарат и Менеджер банкомата.
3.Для создания класса нужно исполнить из к.з. меню на папке Logical View в браузере команду New/Class и дать классу имя.
4.Перенести мышью созданные классы из браузера на диаграмму. Указать стереотип для каждого класса. Для указания стереотипа класса нужно открыть окно спецификаций класса (2с по классу на диаграмме или командой Open Specification из к.з. меню на классе). Для класса Счет указать стереотип Entity
(сущность), для классов Экран банкомата, Устройство для чтения карточек
и Кассовый аппарат – стереотип Boundary (граничный класс), для класса Менеджер банкомата – стереотип Control (управляющий).
5.Используя элемент Undirectional Association на панели элементов диаграммы, связать классы друг с другом, как показано на рисунке 3.1. Убрать стрелки на линии связи, указав тем самым, что связи двухсторонние. Для этого нужно из к.з. меню на линии связи выполнить команду Navigable. Указать множественность для каждой связи в соответствии с рисунком 3.1. Например, для указания множественности связи между классами Устройство для чтения карточек и Счет надо из к.з. меню на линии связи около класса Устройство для чтения карточек выбрать команду Multiplicity/Zero or One, а около класса Счет - Multiplicity/Zero or More. Аналогично для остальных классов.
6.Указать атрибуты для каждого класса. Для класса Устройство для чтения карточек – атрибут – номер карточки, указав его тип Integer область видимости - Private. Для этого можно открыть окно спецификаций класса (2с по классу), выбрать вкладку Atributes и в поле атрибута выбрать из к.з. меню команду Insert. Можно иначе – из к.з. меню на классе исполнить команду New Attribute. Для указания типа и области видимости атрибута надо открыть окно спецификации атрибута (2с по имени атрибута в окне спецификации класса).
10