Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 7)

В телах OCL-выражений используются типы и имена (классов, атрибутов, операций) из модели. Далее в примерах мы будем рассматривать модель авиаперевозок:

О
братите внимание на производные атрибуты в классе Flight (arrivalTime, nrPassengers) и статический атрибут minAge класса Passenger.

Для указания атрибута или операции используется выражение с точкой:

<выражение>.<имя>

context Flight inv: self.maxNrPassengers <= 1000 – в любом рейсе максимальное количество пассажиров не превышает 1000 (использован атрибут объекта – экземпляра класса Flight).

context Flight:maxNrPassengers:Integer init: 1000 – в любом рейсе максимальное количество пассажиров по умолчанию = 1000.

context Passenger inv: self.age >= Passenger::minAge – у любого пассажира возраст больше минимального (использован атрибут age экземпляра класса Passenger и атрибут того же класса minAge).

Примеры с производными атрибутами:

context Flight def: arrivalTime:Time = departTime.plus(duration)

или context Flight:arrivalTime derive: departTime.plus(duration)

По смыслу ограничения совпадают, но в первом определяется производный атрибут, которого не было в модели, во втором определяется правило вывода для атрибута в составе модели. В примерах использован класс Time.

Пример определения операции:

context Interval::equals(i:Interval):Boolean body:

(self.nrOfDays*60+self.nrOfHours)*60+self.nrOfMins =

(i.nrOfDays*60+i.nrOfHours)*60+i.nrOfMins

Заметим, что данное ограничение не описывает, вообще говоря, как именно проверяются интервалы на совпадение, допускается любой способ, который дает результат, совпадающий со значением из ограничения.

Поскольку ограничения часто накладываются не только на объекты классов, но и на связанные с ними объекты других классов, каждая ассоциация рассматривается как путь навигации. Контекст выражения является стартовой точкой. Имя роли определяет, по какой ассоциации осуществляется навигация (если их несколько), если ассоциация одна, то используется имя класса на другом конце ассоциации. Пример:

context Flight

inv: self.origin <> self.destination

inv: self.origin.name = ‘Amsterdam’ – у любого рейса аэропорт назначения и аэропорт вылета не совпадают, а также аэропорт вылета называется ‘Amsterdam’.

Если есть класс ассоциаций, то используется его имя. Если ассоциация квалифицированная, то после имени роли в квадратных скобках указывают значения квалификаторов.

context Person inv:

if employer.name = ‘OAO MMM’ then

Job.type = #trainer

else Job.type = #programmer

endif

Смысл ограничения: у любой персоны, занятой в ‘OAO MMM’, тип работы trainer, у остальных тип работы programmer. То же самое по смыслу ограничение можно записать, используя в качестве контекста класс ассоциаций:

context Job inv:

if employer.name = ‘OAO MMM’ then

self.type = #trainer

else self.type = #programmer

endif

При навигации по связям, если на другом конце указана мощность связи *, от одного объекта мы приходим к нескольким связанным с ним (например, один аэропорт является аэропортом вылета для нескольких рейсов), поэтому в OCL введено понятие коллекции. Вообще говоря, коллекции могут состоять либо из объектов, либо из элементов простых типов, либо из элементов типов, определенных в модели, либо из коллекций. Виды коллекций:

• Set (множество– неупорядоченный набор без повторов) – для экземпляра класса Airport прибывающие рейсы составляют множество объектов Flight.

• Bag (неупорядоченный набор с повторами) – для экземпляра класса Airport длительности всех прибывающих рейсов составляют bag вещественных значений.

• OrderedSet (упорядоченный набор без повторов) – для экземпляра класса Flight все его пассажиры составляют orderedSet объектов Passenger.

• Sequence (упорядоченный набор с повторами) – для экземпляра класса Flight возрасты всех его пассажиров составляют sequence целых значений.

В OCL имеется большое количество предопределенных операций над коллекциями (isEmpty, size, includes, union …). Синтаксис: <коллекция> -> <операция>

Операция collect возвращает коллекцию значений, полученных при вычислениях выражения для всех элементов коллекции. Запись: <коллекция>->collect(<выражение>) – здесь и далее круглые скобки и | – символы OCL, а не языка БНФ. Сокращенная запись: <коллекция>.<выражение>

Пример: context Airport inv: self.arrivingFlights -> collect(airLine) -> nonEmpty – для любого аэропорта множество авиакомпаний, выполняющих прибывающие рейсы, не пусто.

Операция select возвращает совокупность тех элементов коллекции, для которых <выражение> истинно. Запись: <коллекция>->select(<выражение>)

Пример: context Airport inv: self.departingFlights->select(duration<4)->notEmpty – для любого аэропорта есть хоть один отправляющийся рейс длительностью менее 4 часов.

Операция forAll возвращает true если <выражение> истинно для всех элементов коллекции. Запись: <коллекция>->forAll(<выражение>)

Пример: context Airport inv: self.departingFlights->forAll(maxNrPassengers < 1000) – для любого аэропорта справедливо, что у любого отправляющегося рейса максимальное количество пассажиров < 1000.

Операция exists возвращает true если хотя бы для одного элемента коллекции <выражение> истинно. Запись: <коллекция>->exists(<выражение>)

Другие операции над коллекциями:

• isEmpty: истина, если коллекция пуста;

• notEmpty: истина, если коллекция непуста;

• size: количество элементов коллекции;

• sum: сумма элементов коллекции чисел;

• count(<элемент>): количество вхождений элемента;

• includes(<элемент>): истина, если <элемент> входит в коллекцию;

• excludes(<элемент>): истина, если <элемент> отсутствует в коллекции;

• includesAll(<коллекция>): истина, если все элементы параметра <коллекция> входят в коллекцию.

Коллекции можно сравнивать на = и <>. Преобразование коллекций к другому виду осуществляется при помощи операций asSet(), asBag(), asOrderedSet(), asSequence(). Преобразование типов осуществляется с помощью операции oclAsType(type). Коллекцию коллекций можно сделать «плоской» с помощью операции flatten(). Примеры ее работы:

Set { Set { 1, 2 }, Set { 2, 3 }, Set { 4, 5, 6 } }  flatten  Set { 1, 2, 3, 4, 5, 6 }

Bag { Set { 1, 2 }, Set { 1, 2 }, Set { 4, 5, 6 } }  flatten  Bag { 1, 1, 2, 2, 4, 5, 6 }

Дополнительные возможности OCL:

• result и @pre в постусловиях;

• локальные переменные;

• итераторы;

• наследование;

• указание состояний объектов.

С помощью result в постусловии можно указать, что операция возвращает в качестве результата:

context Airline::servedAirports() : Set(Airport)

pre : --none

post: result = flights.destination->asSet

@pre в постусловии дает возможность использовать значения атрибутов, какими они были в начале выполнения операции

context Passenger::Book(f:Flight)

pre : Flight.nrPassengers < Flight.maxNrPassengers

post: Flight.nrPassengers = Flight.nrPassengers@pre + 1

Конструкция let определяет локальную переменную. Запись:

let <name> : <type> = <expression1> in <expression2>

Пример: context Airport inv: let supportedAirlines : Set(Airline) = self.arrivingFlights ->collect(airLine) in (supportedAirlines ->notEmpty) and (supportedAirlines ->size < 500) – здесь для упрощения логического выражения определена локальная переменная supportedAirlines, представляющая собой коллекцию авиалиний, обслуживающих, прибывающие в аэропорт рейсы. Указано, что для любого аэропорта таких авиалиний должно быть больше нуля, но меньше 500.

Конструкция iterate позволяет описывать нестандартные операции над коллекциями. Запись: <коллекция>->

iterate(<переменная1> : <тип>; <переменная2> : <тип> [= <нач. значение>] | <тело>)

где <переменная1> – параметр итератора, <переменная2> – результат итератора, <тело> – OCL-выражение с <переменная1> и <переменная2>.

Например, ограничение:

context Airline inv: self.flights->select(maxNrPassengers > 150)->notEmpty

идентично:

context Airline inv: self.flights->iterate (f : Flight; answer : Set(Flight) = Set{ } |

if f.maxNrPassengers > 150 then answer->including(f) else answer endif )->notEmpty

Поясним второе OCL-выражение. Для авиалинии будет собрана коллекция всех ее рейсов и на этой коллекции будет запущен итератор. В начале работы результат итератора инициализируется пустым множеством. Затем для каждого рейса f из коллекции, одного за другим, будет вычислено условное выражение, которое добавит в результат лишь те рейсы, maxNrPassengers которых больше 150.

В наследовании ограничений работает принцип подстановки Лисковой (Liskov’s Substitution Principle): «Где может находиться экземпляр суперкласса, туда всегда может быть подставлен экземпляр его любого подкласса.» Это означает, что:

• Инвариант суперкласса наследуется любым подклассом.

• Подклассы могут усиливать инвариант.

• Предусловие может быть ослаблено в подклассе.

• Постусловие может быть усилено в подклассе.

Если в ограничении требуется проверить, является ли экземпляр суперкласса также экземпляром конкретного подкласса, то используют стандартную операцию ocllsTypeOf. Вспоминая пример, приведенный в начале лекции, мы можем описать следующие ограничения:

context ГрузовойСамолет inv:

Рейс->forAll(r | r.oclIsTypeOf(ГрузовойРейс))

context ПассажирскийСамолет inv:

Рейс->forAll(r | r.oclIsTypeOf(ПассажирскийРейс))

Операция oclInState возвращает истину, если объект находится в определенном состоянии. Пример:

context Bottle inv:

self.oclInState(closed) implies filled = #full

Мы рассмотрели OCL применительно к моделям (диаграммам) классов. Он также может использоваться на других диаграммах. На диаграммах взаимодействия OCL применяют для записи сторожевых условий (от выполнения которых зависит, будет ли послано сообщение). На диаграммах деятельности OCL применяют для описания деятельностей, узлов принятия решения, сторожевых условий на потоках. На диаграммах состояний OCL используется для описания состояний и сторожевых условий на переходах между состояниями.

Подведем итоги.

• OCL позволяет уточнять модель, формулировать запросы к модели, сохранять при этом свободу реализации.

• Пре- и постусловия OCL позволяют точнее описывать интерфейсы и компоненты.

• Рекомендуется при использовании OCL писать простые ограничения, совместно использовать OCL и естественный язык, применять CASE-средства, поддерживающие OCL (например, из состава Eclipse Model Develepment Tools или Dresden OCL Toolkit).

Лекция 5. Моделирование бизнес-процессов

Моделирование бизнес-процессов является важной составной частью крупномасштабных проектов по созданию ПО. Отсутствие таких моделей является одной из главных причин неудач многих проектов.

Бизнес-процесс (производственный процесс) определяется как логически завершенный набор взаимосвязанных и взаимодействующих видов деятельности, поддерживающий деятельность организации и реализующий ее политику, направленную на достижение поставленных целей. Бизнес-процесс использует определенные ресурсы (финансовые, материальные, человеческие, информационные). Выделяют следующие классы процессов:

• основные процессы (производство товаров и услуг, приносят доход, составляют основную деятельность компании);

• обеспечивающие процессы (обеспечение основных процессов финансами, кадрами, комплектующими, тех. обслуживанием, администрирование и юридическое обеспечение);

• процессы управления (планирование и контроль бизнес-процессов других видов).

Бизнес-модель – это формализованное описание бизнес-процессов предприятия, фиксирующее существующее положение дел (модель AS-IS «как есть») или устанавливающее новые усовершенствованные способы осуществления деятельности (модель AS-TO-BE «как будет»). Цели бизнес-моделирования:

1. обеспечить понимание структуры организации и происходящих в ней процессов;

2. обеспечить понимание текущих проблем организации и возможностей их решения;

3. убедиться, что заказчики, пользователи и разработчики одинаково понимают цели и задачи организации;

4. создать базу для формирования требований к будущему ПО организации.
   

Бизнес-модель должна давать ответы на вопросы:

1. Какие процедуры (функции, работы) необходимо выполнить для получения заданного конечного результата?

2. В какой последовательности выполняются эти процедуры?

3. Какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес-процесса?

4. Кто выполняет процедуры процесса?

5. Какие входящие документы/информацию использует каждая процедура процесса?

6. Какие исходящие документы/информацию генерирует процедура процесса?

7. Какие ресурсы необходимы для выполнения каждой процедуры процесса?

8. Какая документация/условия регламентирует выполнение процедуры?

Рассмотрим методику моделирования деловых процессов, являющуюся составной частью технологии Rational Unified Process.

Аналитик бизнес-процессов возглавляет и координирует бизнес-моделирование. Он отвечает за:

• видение бизнеса – документ, где определены цели бизнес-моделирования;

• оценку организации – документ, описывающий текущее состояние дел в организации;

• бизнес-правила – условия, соблюдение которых необходимо;

• глоссарий деятельности – словарь основных терминов организации;

• дополнительную спецификацию – документ со сведениями, не вошедшими в другие документы;

• модель бизнес-процессов (Business Use Case Model), моделирующую взгляд на предприятие извне, как на «черный ящик»;

• модель бизнес-анализа (Business Analysis Model), моделирующую взгляд на предприятие изнутри, как на «белый ящик».

Модель бизнес-целей представляет собой древовидную структуру, описывающую зависимости вида цель-подцель (см. рисунок). Связи в дереве таковы, что достижение подцелей приводит или приближает к достижению родительской бизнес-цели. Дерево целей изображается на диаграмме классов.

Модель бизнес-процессов (Business Use Case Model) – модель, описывающая бизнес-процессы организации в терминах ролей и их потребностей. Она представляет собой расширение модели вариантов использования UML за счет введения набора стереотипов Business Actor (деловое действующее лицо – стереотип действующего лица) и Business Use Case (бизнес-процесс – стереотип варианта использования). Из этой модели видно в каком контексте работает предприятие, но не видно как именно протекает его работа (это описывает модель бизнес-анализа).

Деловое действующее лицо (business actor) – некоторая роль, выполняемая по отношению к бизнес-процессам организации. Кандидатами на эту роль являются: акционеры, заказчики, поставщики, партнеры, потенциальные клиенты, местные органы власти, коллеги из подразделений, не охваченных моделью, внешние бизнес-системы (предприятия или подразделения). Деловыми действующими лицами, как правило, не являются должностные лица, работающие на предприятии. Обнаружить действующих лиц бизнес-процессов можно, найдя ответы на вопросы:

• Кто извлекает пользу из существования организации?

• Кто помогает организации осуществлять свою деятельность?

• Кому организация передает информацию и от кого получает?

Бизнес процесс (Business use-case) описывает последовательность действий в рамках экономической деятельности предприятия, приносящую ощутимый результат конкретному деловому действующему лицу.

Характеристики

Список файлов лекций