Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование
Подождите немного. Документ загружается.
566 Глава 25. Введение в OCL
менные подобны локальным переменным в обычных языках програм
мирования. И назначение их практически такое же – хранение вычис
ленного значения, используемого в выражении более одного раза.
let определяет локальную переменную OCLвыражения.
Выражение let состоит из двух частей – let и in.
let <имяПеременной>:<типПеременной> = <выражениеLet> in
<использующееВыражение>
В первой части значение выражения let (<выражениеLet>) присваивается
переменной (<имяПеременной>). Вторая часть определяет OCLвыраже
ние, являющееся областью действия переменной и местом, где она мо
жет использоваться (<использующееВыражение>).
В нашем примере банковского счета на самом деле нет необходимости
в выражении let. Однако для иллюстрации рассмотрим пример, в кото
ром определена переменная originalBalance (исходный баланс), локаль
ная для ограничения withdrawalSucceeded.
context BankAccount::withdraw( amount : Real )
post withdrawalSucceeded:
let originalBalance : Real = self.balance@pre in
окончательный баланс – это исходный баланс минус снятая сумма
self.balance = originalBalance amount
25.10.7. derive:
OCL может использоваться для определения значений производных
атрибутов.
Значения производных атрибутов определяются с помощью derive.
Наш пример с банковским счетом можно реорганизовать и выразить
переменную баланса и переменную превышения кредита с помощью
производных атрибутов (рис. 25.14).
Правила вывода этих производных атрибутов можно описать следую
щим образом:
context CheckingAccount::availableBalance : Real
derive:
можно снимать сумму, не превышающую ограничения по превышению кредита
balance + overDraftLimit
context CheckingAccount::availableOverdraft : Real
derive:
if balance >= 0 then
возможность превышения кредита доступна полностью
overdraftLimit
25.11. OCL на диаграммах других типов 567
else
возможность превышения кредита использована частично
overdraftLimit + balance
endif
Это упрощает определение операций CheckingAccount::getAvailableBal
ance() и CheckingAccount::getAvailableOverdraft():
context CheckingAccount::getAvailableBalance() : Real
body:
availableBalance
context CheckingAccount::getAvailableOverdraft() : Real
body:
availableOverdraft
25.11. OCL на диаграммах других типов
До сих пор мы рассматривали применение OCL только на диаграммах
классов. Однако OCL может также использоваться на диаграммах дру
гих типов:
• на диаграммах взаимодействий (глава 12);
• на диаграммах деятельности (главы 14 и 15);
• на диаграммах состояний (конечные автоматы) (главы 21 и 22).
В следующих разделах рассмотрим применение OCL на диаграммах
этих типов.
BankAccount
balance : Real
accountNumber : String
deposit( amount : Real ):Real
withdraw( amount : Real )
getBalance() : Real
getOwner() : Person
getOperators() : Person[]
CheckingAccount
overdraftLimit : Real
/availableBalance : Real
/availableOverdraft : Real
withdraw( amount : Real )
getAvailableBalance() : Real
getAvailableOverdraft() : Real
DepositAccount
withdraw( amount : Real )
Person
name : String
id : String
address : String
getName() : String
getId() : String
getAddress() : String
owner
operator
1..**
*1
ownedAccounts
operatedAccounts
производные
атрибуты
Рис. 25.14. Производные атрибуты
568 Глава 25. Введение в OCL
25.11.1. OCL на диаграммах взаимодействий
На диаграммах взаимодействий OCL используется для представления
ограничений. Необходимо помнить, что с помощью OCL нельзя опи
сать поведение, поскольку данный язык не имеет побочных эффектов.
На диаграммах взаимодействий OCL может использоваться везде, где
необходимо сделать следующее:
• определить сторожевое условие;
• определить селектор линии жизни (раздел 12.6);
• определить параметры сообщения.
Рассмотрим пример использования OCL на диаграммах последова
тельностей. На рис. 25.15 изображена диаграмма классов простой сис
темы электронной почты.
Класс EmailAddress (электронный адрес) представляет адрес электрон
ной почты. Например, адрес электронной почты jim@umlandtheuni+
fiedprocess.com был бы представлен как объект класса EmailAddress, как
показано на рис. 25.16. В данном случае операция EmailAddress:get
blacklist
0..*
whiteList
0..*
EmailAddress
getName() : String
getDomain() : String
getAddress() : String
…
address : String
replyTo cc bcc fromAddress toAddresses0..1 0..* 0..* 1 1..*
Legitimate
Unclassified
<<enumeration>>
MessageType
messageType
11
MailSystem
MailSystem
classifyMessage( m : Message )
…
reviewBox inBox0..*0..*
11
subject : String
content : String
setType( type : MessageType )
…
1
1
111 11
Рис. 25.15. Диаграмма классов системы электронной почты
25.11. OCL на диаграммах других типов 569
Name() возвращает "Jim", EmailAddress::getDomain() возвращает "umlandthe
unifiedprocess.com" и EmailAddress::getAddress() возвращает "jim@umlandthe
unifiedprocess.com". Объекты EmailAddress эквивалентны, если их атрибу
ты address (адрес) имеют одинаковое значение.
Система для обработки пришедшей почты пользуется политикой бе
лый/черный список:
• Все почтовые сообщения, адрес отправителя (fromAddress) которых
входит в черный список (blackList), удаляются.
• Все почтовые сообщения, fromAddress которых входит в белый спи
сок (whiteList), помещаются в ящик входящей почты (inBox).
• Все остальные почтовые сообщения помещаются в ящик для про
смотра (reviewBox).
• Состояние пришедшего сообщения (Message) меняется соответствен
но его типу: спам (удаляется), Legitimate (допустимый) или Unclassi
fied (неклассифицированный).
На рис. 25.17 показана диаграмма последовательностей для операции
MailSystem::classifyMessage( m : Message ). Диаграмма деятельностей для
этой операции представлена в следующем разделе на рис. 25.18, и вы
должны заметить, как эти диаграммы соответствуют друг другу. Диа
грамма последовательностей определяет, какие классы и операции
реализуют поведение, описанное диаграммой деятельностей.
MailSystem (система электронной почты) – контекст выражения. OCL
использовался для определения условий в комбинированном фрагмен
те alt.
С помощью OCL также было задано состояние объектов на диаграмме
(хотя это обычное применение OCL, поскольку OCL и UML имеют оди
наковый синтаксис для описания состояний).
25.11.2. OCL на диаграммах деятельности
Диаграммы деятельности можно создавать для описания поведения
любого элемента UMLмоделирования. На диаграммах деятельностей
OCL используется для определения:
• узлов вызова действия;
• сторожевых условий переходов;
• объектных узлов;
• состояния объекта.
jimsAddress:EmailAddress
address = "jim@umlandtheunifiedprocess.com"
Рис. 25.16. Адрес электронной почты jim@umlandtheunifiedprocess.com
представлен как объект класса
EmailAddress
570 Глава 25. Введение в OCL
Например, на рис. 25.18 показана очень простая диаграмма деятель
ности для описания поведения ClassifyMailMessage (классифицировать
почтовое сообщение) системы электронной почты, рассматриваемого
в предыдущем разделе.
Как видите, OCL используется для описания объектов, их состояний
и условий.
OCL применяется для точного моделирования, а диаграммы деятель
ности по своей природе не могут быть точными. Кроме того, они часто
предназначаются для заказчиков, которые не являются специалиста
ми в технической области. Поэтому целесообразность применения OCL
на диаграммах этого типа довольно сомнительна. Например, ограни
чения на рис. 25.18 могли бы быть записаны просто на естественном
языке (английском или русском). Рассматривая возможность исполь
зования OCL на диаграммах деятельности, всегда необходимо учиты
вать назначение диаграммы и ее целевую аудиторию.
25.11.3. OCL на диаграммах состояний
OCL используется в диаграммах состояний для определения:
• сторожевых условий;
:MailSystem
classifyMessage( m : Message )
m:Message :reviewBox
alt
:inBox
setType( Legitimate )
add( m )
[else]
setType( Unclassified )
add( m )
sd ClassifyMessage
«delete»
Unclassified
[ blackList !>exists( a | a.getAddress() = m.fromAddress.getAddress() ) ]
[ whiteList!>exists( a | a.getAddress() = m.fromAddressgetAddress() ) ]
Legitimate
Рис. 25.17. Диаграмма последовательностей для операции
MailSystem::classifyMessage( m : Message )
25.11. OCL на диаграммах других типов 571
• условий, налагаемых на состояния;
• целей действий;
• операций;
• значений параметров.
Экземпляр контекста – это экземпляр классификатора, которому при
надлежит конечный автомат. В качестве примера рассмотрим конеч
ный автомат CheckingAccountActive (активный текущий счет) класса Che
ckingAccount (рис. 25.19).
Из рисунка видно, что на диаграмме синтаксис OCL используется в сто
рожевых условиях. Чтобы конечный автомат был рабочим, необходи
мо учесть ограничения, которые записаны отдельно, чтобы не загро
мождать диаграмму.
context CheckingAccount::balance
int:
0
context CheckingAccount
inv:
oclInState( InCredit ) implies ( balance >= 0 )
ClassifyMailMessage
GetMailMessage
message
[Unclassified]
DeleteMessage
[ whiteList !>exists( a | a.getAddress() = m.fromAddress.getAddress() ) ]
ClassifyMessageAsLegitimate
message
[Legitimate]
message
[Unclassified]
FileMessageInInBoxFileMessageForReview
else
else
[ blackList !>exists( a | a.getAddress() = m.fromAddress.getAddress() ) ]
Рис. 25.18. Диаграмма деятельностей
572 Глава 25. Введение в OCL
inv:
oclInState( Overdrawn ) implies ( balance <0 )
def:
availableBalance = ( balance + overdraftLimit )
def:
enoughMoney = ( ( availableBalance – amount ) >= 0 )
def:
inCredit = ( balance >= 0 )
Обратите внимание, как с помощью oclInState( InCredit ) организована
ссылка на состояние InCredit. В качестве альтернативы можно было бы
прикрепить инвариант (balance >= 0) прямо к состоянию InCredit в виде
примечания.
Operating
InCredit
Overdrawn
AcceptingWithdrawal
RejectingWithdrawal
deposit( amount )
H
[enoughMoney]
withdraw( amount )
[notenoughMoney]
withdraw( amount )
Active
close
closed
CheckingAccountActive
[not inCredit] [inCredit]
open
Рис. 25.19. Конечный автомат CheckingAccountActive
25.12. Дополнительные вопросы 573
25.12. Дополнительные вопросы
В данном разделе рассматриваются некоторые не часто используемые
аспекты OCL:
• навигация к и из классовассоциаций;
• навигация по квалифицированным ассоциациям;
• унаследованные ассоциации;
• OCLMessage.
25.12.1. Навигация к и от классовассоциаций
Имя классаассоциации используется для навигации к классуассоциа
ции.
Классыассоциации обсуждаются в разделе 9.4.5. Осуществить нави
гацию к классуассоциации можно с помощью его имени. Для примера
рассмотрим рис. 25.20.
Операцию запроса getJobs() можно представить следующим образом:
context Person::getJobs() : Set(Job)
body:
self.Job
Выражение self.Job возвращает Set всех объектов Job, ассоциированных
с данным объектом Person. Этот Set можно использовать в OCLвыраже
ниях. Пусть согласно бизнесправилу Person не может занимать две
одинаковые должности (Job). На OCL это можно описать так:
context Person
inv:
человек не может занимать две одинаковые должности
self.Job>isUnique( j : Job | j.name )
getEmployee() : Person
getEmployer() : Company
Company
1..* 0..*
employer employee
Person
Job
name : String
dateOfBirth : Date
getAge() : Integer
getJobs()
getTotalSalary() : Real
name : String
description : String
salary : Real
Рис. 25.20. Навигация к классу+ассоциации по имени
574 Глава 25. Введение в OCL
Предположим, компания (Company) работает по схеме постепенного со
кращения круга служебных обязанностей с приближением пенсион
ного возраста, и существует бизнесправило, запрещающее человеку
(Person) старше 60 занимать более одной должности (Job). На OCL это
можно представить следующим образом:
context Person
inv:
человек старше 60 может занимать только одну должность
(self.getAge() >60) implies (self.Job>count() = 1)
Чтобы получить общую заработную плату Person, необходимо сложить
его зарплату на каждой должности (Job):
context Person::getTotalSalary() : Real
body:
возвращаем суммарную заработную плату на всех должностях
self.Job.salary>sum()
Навигацию от классаассоциации можно осуществлять как обычно –
с помощью имен ролей на отношениях. Например, вот OCL для опера
ций getEmployee() и getEmployer() класса Job:
context Job::getEmployee() : Person
body:
self.employee
context Job::getEmployer() : Company
body:
self.employer
25.12.2. Навигация по квалифицированным ассоциациям
Для навигации по квалифицированной ассоциации после имени роли
в квадратных скобках указываются квалификаторы.
Квалифицированные ассоциации обсуждались в разделе 9.4.6. Для
навигации по квалифицированной ассоциации после имени роли
в квадратных скобках размещается квалификатор (или разделенный
запятыми список квалификаторов).
На рис. 25.21 приведена простая модель клуба с различными уровня
ми членства. Предположим, существует бизнесправило, согласно ко
торому членский ID 00001 всегда зарезервирован за председателем
клуба. На языке OCL это можно выразить следующим образом:
context Club
inv:
id председателя всегда 00001
self.members['00001'].level = 'Chairman'
25.12. Дополнительные вопросы 575
Здесь видно, как используется квалифицированная ассоциация с оп
ределенным значением квалификатора для выбора одного объекта из
множества (Set) self.members.
25.12.3. Унаследованные ассоциации
Рассмотрим модель на рис. 25.22. Она адаптирована из книги [Arlow 1]
и представляет модель единиц измерений и систем единиц.
Есть два разных типа единиц измерения (Unit): метрические (MetricUnits)
и британские (ImperialUnits). MetricUnits принадлежат метрической систе
ме (MetricSystem), а ImperialUnits – британской системе (ImperialSystem). Од
нако UMLмодель на рис. 25.22 не отражает этого различия. По сути, в
ней определено, что любой Unit может принадлежать любой системе
единиц (SystemOfUnits). Можно сделать модель более точной, если соз
дать подкласс отношения между SystemOfUnits и Unit, как показано на
рис. 25.23.
Это решает проблему, но несколько загромождает диаграмму, и при
увеличении числа подклассов Unit и SystemOfUnits ситуация быстро усу
губляется.
clubName : String
clubAddress : String
Сlub
club
memberld : String
1
1 members
Member
id : String
name : String
address : String
level : String
Рис. 25.21. Модель клуба с различными уровнями членства
SystemOfUnits Unit
MetricUnit ImperialUnit
Meter Centimeter Foot Inch
system units
1 1..*
ImperialSystem MetricSystem
Рис. 25.22. Модель единиц измерений и систем единиц