Конспект по курсу. Объектно ориентированный анализ и проектирование (1133667), страница 9

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

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

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 }

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

Дополнительные возможности 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. Вспоминая пример, приведенный в начале лекции, мы можем описать следующие ограничения:

c
ontext ГрузовойСамолет 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).

Литература к лекции 4

1. J.Warmer, A. Kleppe. Object Constraint Language, The: Getting Your Models Ready for MDA, Second Edition

2. OCL portal http://www-st.inf.tu-dresden.de/ocl/

3. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд.: Пер. с англ. – СПб.: Питер, 2007. – Глава 3.

4. Дж. Арлоу, Ай. Нейштадт. UML 2 и унифицированный процесс, 2-е изд. – СПб.: Символ-Плюс, 2007. – Глава 25.

Лекция 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) описывает последовательность действий в рамках экономической деятельности предприятия, приносящую ощутимый результат конкретному деловому действующему лицу.

П
ример модели бизнес-процессов (регистрация пассажиров на рейс в аэропорту):

Каждый бизнес-процесс сопровождается спецификацией, в которой содержится:

• наименование;

• краткое описание бизнес-процесса;

• цели и результаты;

• описание сценариев (основного и альтернативных);

• специальные требования (время и стоимость);

• расширения (исключительные ситуации);

• связи;

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

Пример:

• Наименование – Пройти регистрацию.

• Краткое описание – Процесс регистрации пассажира на рейс.

• Цели – Получить посадочный талон и сдать багаж.

• Основной сценарий:

1. Пассажир встает в очередь к стойке регистратора.

2. Пассажир предъявляет билет регистратору.

3. Регистратор подтверждает правильность билета.

4. Регистратор оформляет багаж.

5. Регистратор резервирует место для пассажира.

6. Регистратор печатает посадочный талон.

7. Регистратор выдает пассажиру посадочный талон и квитанцию на багаж.

8. Пассажир уходит от стойки регистратора.

• Альтернативные сценарии:

1а. Билет неправильно оформлен – регистратор отсылает пассажира к агенту по перевозкам.

2а. Багаж превышает установленный вес – регистратор оформляет доплату.

• Специальные требования – Время регистрации не должно превышать 1 минуты.

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

Модель бизнес-анализа (модель бизнес-объектов) создается другим исполнителем в рамках RUP – бизнес-разработчиком, но руководит ее созданием бизнес-аналитик.

Бизнес-разработчик выполняет следующие деятельности:

• работает над бизнес-системой (отделом или подразделением организации);

• уточняет спецификацию бизнес-процессов (business use case);

• моделирует реализацию бизнес-процессов в виде модели бизнес-анализа (business analysis).

Р
ис. Деятельности, выполняемые бизнес-разработчиком и рабочие документы, создаваемые им.

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

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