Моделирование логической структуры системы.pps

8. Моделирование логической
структуры системы
8.1. Диаграмма классов
• Диаграмма классов служит для
моделирования классов и отношений
между ними.
Элементы диаграммы классов
– Class – класс.
– Association – отношение ассоциации
между классами.
– Dependency – отношение зависимости
между классами.
Графическое обозначение
элементов
class Class diagram
Отношение
ассоциации
Класс с именем
Class1
Class1
Отношение
зависимости
Class3
Class2
Графическое обозначение
класса
• В общем случае графическое
обозначение класса содержит
три прямоугольных области,
в которых отображаются:
– имя класса (обязательно);
– атрибуты класса (может
отсутствовать);
– операции класса (может
отсутствовать).
Имя класса
Атрибуты
Методы
Синтаксис описания атрибута
•
visibility name : type-expression [ multiplicity ordering ] = initial-value { property-string }
•
где
–
visibility – область видимости атрибута; может принимать одно из следующих
значений:
•
•
•
•
–
–
–
–
name – имя атрибута;
type – тип атрибута;
initial-value – начальное значение атрибута;
multiplicity – количество значений, которые может содержать атрибут, задается в виде:
•
–
lower_bound..upper_bound
ordering –используется когда атрибут хранит более одного значения и обозначает
упорядоченность этих значений, может принимать одно из значений:
•
•
–
+ : public visibility – видим вне класса;
- : private visibility – не видим вне класса;
# : protected visibility – видим вне класса только друзьями класса;
~ : package visibility – видим внутри пакета;
unordered – неупорядочено (по умолчанию);
ordered – упорядочено;
property-string – свойства значений или другими словами ограничения на значения
атрибута.
Синтаксис описания операции
•
•
visibility name ( parameter-list ) : return-type-expression { property-string }
где
–
visibility – область видимости операции; может принимать одно из следующих
значений:
•
•
•
•
–
–
name – имя операции;
parameter-list – список формальных параметров операции, каждый параметр задается
в виде:
•
•
+ : public visibility – видима вне класса;
- : private visibility – не видима вне класса;
# : protected visibility – видима вне класса только друзьями класса;
~ : package visibility – видима внутри пакета;
kind name : type-expression = default-value
где
–
–
–
kind – обозначает вид параметра может быть опущен или принимать одно из следующих значений:
» in – входной, значение по умолчанию;
» out – выходной;
» inout – входной и выходной (модифицируемый);
return-type-expression – тип возвращаемого методом значения или списка значений,
если опущен, то операция не возвращает значения;
property-string – свойства операции или другими словами ограничения на операцию.
8.2. Стереотипы классов
• Стереотипы классов используются для
того, чтобы разбить классы на
категории.
• В UML предопределены некоторые
стереотипы классов. Эти стереотипы
классов имеют в UML специальные
графические обозначения.
Интерфейс
• Interface – интерфейс,
это абстрактный класс,
все методы которого
являются чисто
виртуальными
функциями.
• Графическое обозначение
интерфейса:
class Class...
Interface
Граничный класс
• Boundary class –
граничный класс,
это класс, который
находится на
границе системы с
её окружением.
• Графическое
обозначение
граничного класса:
class Class diagram
BoundaryClass
Использование граничного
класса
• Предполагается, что в системе должен быть,
по крайней мере, один граничный класс
между актером и вариантом использования, с
которым связан этот актер.
• Граничный класс позволяет актеру
взаимодействовать с системой.
• Как правило, такой граничный класс носит
имя актера, которому он позволяет
взаимодействовать с системой.
Класс сущность
• Entity class – класс
сущность, это
класс, содержащий
информацию,
которая требует
хранения в
постоянной памяти.
• Графическое
обозначение класса
сущности:
class Class diagram
EntityClass
Контроллер
• Control class –
контроллер,
управляющий класс,
это класс, который
управляет работой
других классов.
• Графическое
обозначение
контроллера
class Class diagram
ControlClass
Использование контроллера
• Обычно для каждого варианта
использования существует один
управляющий класс.
Другие стереотипы
• Стереотип <<type>> показывает, что
класс не имеет реализации.
• Стереотип <<implementationClass>>
показывает, что класс является
реализацией некоторого типа.
8.3. Стереотипы отношения
ассоциации
• Для отношения ассоциации в UML
предопределены следующие
стереотипы:
– обобщение (generalization);
– агрегация (aggregation);
– композиция (composition);
Отношение обобщения
• Отношение
обобщения
моделирует
отношение “is-a”
между классами.
• Графически
обозначение
обобщения:
class Generalization
Base
Deriv ed
Отношение агрегации
• Отношение агрегации определяет отношение
«целое-часть», т. е. показывает, что объекты
одного класса принадлежат (являются частями)
объектам другого класса.
• Такое отношение также называется «слабой
агрегацией».
• Графическое обозначение агрегации:
class Aggregation
Целое
Whole
Часть
Part
Отношение композиции
• Отношение композиции – это отношение
агрегации, при котором время существования
объектов одного класса зависит от времени
существования другого класса.
• Такое отношение также называется «сильной
агрегацией».
• Графическое обозначение композиции:
class Composition
Whole
Part
Отношение принадлежности
пространству имен
• Если один класс определен внутри
другого класса, т.е. является
вложенным, то для обозначения этого
используется отношение ассоциации,
которое называется
«принадлежность пространству
имен» и имеет стереотип «namespaceownedElement».
• Графическое обозначение отношения
принадлежности пространству имен:
class Namespace-ow ned Element
Объявленный клас с
DeclaringClass
Вложенный клас с
NestedClass
8.4. Стереотипы отношения
зависимости
– <<access>> – показывает, что один пакет имеет доступ к
открытым элементам другого пакета;
– <<bind>> – показывает связь параметров шаблона с
действительными типами для создания не
параметризованного класса;
– <<derive>> - показывает вычислительную зависимость
одного элемента от другого;
– <<import>> - показывает, что один пакет имеет доступ к
открытым элементам другого пакета и может помещать
имена этих элементов в свое пространство имен;
– <<refine>> - показывает, что один элемент является
улучшением другого элемента;
– <<trace>> - показывает, что один элемент отслеживает
другой элемент в различных смыслах этого слова;
– <<use>> - показывает, что один элемент использует другой
элемент в различных смыслах этого слова.
Использование стереотипа
<<use>>
• На уровне классов стереотип <<use>>
отношения зависимости обычно
показывает следующие виды
зависимости:
– операции одного класса используют другой
класс как тип своих параметров или тип
возвращаемого значения;
– при реализации операций одного класса
используются объекты другого класса.
Использование стереотипа
<<realize>>
• Для связи класса-типа, или
интерфейса, или пакета с его
реализацией используется отношение
зависимости, которое имеет стереотип
<<realize>>.
• Графическое
обозначение
зависимости со
стереотипом
<<realize>>:
class Realize Type
«type»
Class
«implementationClass»
Realization
• Графическое
обозначение
зависимости
типа
<<realize>>,
когда она
отмечает
реализацию
интерфейса:
class Realize Interface
Interface
Realization
8.5. Концептуальная модель
системы
• Концепция – это множество типов,
удовлетворяющих определенным
требованиям.
• Тип, принадлежащий концепции,
называется моделью концепции.
• Отсюда следует, что концепцию можно
определить через произвольный тип,
принадлежащий этой концепции.
Концептуальный класс
• Концептуальный класс (conceptual
class, analysis class) – это класс,
который является абстрактным
представлением (моделью) концепции.
• Концептуальные классы описывается
только свойствами объектов, входящих
в этот класс.
Концептуальная модель системы
• Концептуальная модель системы (domain
model, conceptual model, domain object model,
analysis object model) описывает концепции из
прикладной области системы и отношения
между ними.
• Все концепции, которые включаются в
концептуальную модель, должны быть
определенные в глоссарии системы.
• Концепции описываются концептуальными
классами, для описания отношений между
концепциями используются отношение
ассоциации без стереотипов.
Использование отношения
ассоциации
• Отношение ассоциации в
концептуальной модели может иметь
следующие спецификации:
– имя;
– направление;
– роли;
– количество экземпляров роли (multiplicity).
Определение концептуальных
классов
• Для определения концептуальных
классов используются два
дополняющих друг друга подхода:
– анализ текстового описания прикладной
области (документы, сценарии, глоссарий
и другие материалы) и определение
ключевых понятий для кандидатов в
концептуальные классы;
– использование списка концептуальных
классов, разбитых по категориям.
Категории концептуальных
классов
–
–
–
–
–
–
–
–
–
–
–
–
роли актеров, например, доктор;
события, например, получение сообщения;
транзакции;
физические объекты;
контейнеры;
элементы контейнеров;
другие системы;
организации, например, отдел;
спецификации;
местоположения;
процессы;
политики;
• и т. д.
Ассоциации между
концептуальными классами
• Для определения ассоциаций между
концептуальными классами используются те же
подходы, что и для определения концептуальных
классов.
• Ассоциации между концептуальными классами могут
быть разбиты по следующим категориям:
–
–
–
–
–
отношение включения друг в друга;
отношение взаимного расположения в пространстве;
отношение взаимного нахождения во времени;
отношение взаимодействия;
отношение использования;
• и т. д.
Пример концептуальной модели
class Концептуальная модель
GoodsList
Выбор товара
+
numberOfGoods: int
Подсчет стоимости заказа
Client
Order
Оформление заказа
+
price: double
Определение суммы оплаты
Payment
Оплата заказа
+
amount: double
GoodsItem
Содержит
+
+
description: string
price: double
8.6. Логическая модель системы
• Логическая модель системы описывает логическую
структуру системы при помощи классов и отношений
между ними.
• Для построения логической модели системы
используются диаграммы классов (class diagram).
• Логическая модель системы строится в два этапа:
– сначала строится концептуальная модель (domain model)
системы;
– затем на базе концептуальной модели строится полная
логическая модель, которая представляет собой детально
проработанную диаграмму классов.
• Разработка логической модели системы
после построения концептуальной
модели включает следующие этапы:
– определение функциональности
концептуальных классов и связей между
ними;
– детализация концептуальных классов;
– спецификация исполнения вариантов
использования посредством
функциональных классов;
– доработка (refine) концептуальных классов
в модели классов системы (design classes).
Пример логической модели
системы
class Заказ товаров
GoodsItem
GoodsList
Выбор товара
«create»
UnregisteredClient
+
+
+
+
+
-
numberOfGoods: int
+
+
+
+
+
+
GoodsList()
~GoodsList()
includeGoods(GoodsItem) : bool
excludeGoods(GoodsItem) : bool
getPrice() : double
getNextItem(GoodsItem*) : bool
UnregisteredClient()
~UnregisteredClient()
chooseGoods(int) : void
formOrder(GoodsList) : Order
payOrder(Order) : void
-
description: string
price: double
+
+
+
+
+
+
GoodsItem(string, double)
~GoodsItem()
setPrice(double) : void
getPrice() : double
setDescription(String) : void
getDescription() : String
Подс чет с тоимос ти заказа
«use»
Order
«interface»
Client
+
+
+
Оформление заказа
chooseGoods(GoodsStore) : GoodsList
formOrder(GoodsList) : Order
payOrder(Order) : Payment
«create»
-
clientProfile: String
ptrGoodsList: GoodsList*
price: double
+
+
+
+
Order(String, GoodsList, double)
~Order()
addPrice(double) : void
getOrder(String*, double*) : void
Определение с уммы оплаты
RegisteredClient
-
profile: String
+
+
+
+
+
+
RegisteredClient(string)
~RegisteredClient()
chooseGoods(int) : void
formOrder(GoodsList) : Order
payOrder(Order) : void
sendMessage(string) : void
«use»
Payment
Оплата товара
«create»
-
amount: double
paymentTransferData: String
+
+
+
Payment(double)
~Payment()
setTransfer(String) : void
GoodsStore
-
goodsItemTable: GoodsItem [1..n]
+
+
+
chooseGoods(int) : GoodsItem
includeGoods(GoodsItem) : bool
excludeGoods(int) : bool