Методы с учетом субъекта, предиката и объекта

Возникновение

Во всех существенных формальных методах информатики для моделирования не образуются предложения с точки зрения естественного языка. Так как это всегда необходимо для полного понимания, то нужные аспекты дополняются неформальными. Так, например, прямоугольники, обозначающие действия в блок-схемах, имеют соответствующие подписи. Вместо «заполнить» для подписи символа действия используется фраза «заполнить заявку на командировку». В английской литературе эго обозначается как «фраза глагол-существительное» [11, с. 45].

Диаграммы приложений и действий в UML

UML охватывает 13 типов диаграмм. Они разделяются на 6 типов структурных диаграмм и 7 типов поведенческих диаграмм. С помощью поведенческих диаграмм описываются динамические аспекты программы. Структурные диаграммы имеют свои аспекты представления, при которых систематический переход невозможен. Все 7 типов диаграмм содержат аспекты субъекта, но в неясной форме. В UML все рассматриваемые предметы — объекты. В дальнейшем будут подробнее рассмотрены 2 типа диаграмм, в которых аспект субъекта выступает на сегодняшний день наиболее четко. Это диаграмма приложений (Use Case Diagram) и диаграмма действий {Activity Diagram).

Диаграммы приложений позволяют описать использование системы с точки зрения пользователя, демонстрируя, какой пользователь (Актер = субъект) выполняет какие действия (предикат) в системе. Приложение описывает видимое снаружи поведение рассматриваемого элемента (система, класс и т. д.) и обобщает один из внутренних наборов действий, которые протекают в определенной последовательности. Приложение не показывает, какие классы и какие отдельные операции участвуют в действиях. Описание приложения только тогда полно, если определены дальнейшие последовательности. Для этого может использоваться соответствующий метод поведенческого моделирования UML или описание с помощью естественного языка.

Актеры рассматриваются в UML как специальные классы с определенными свойствами и поэтому не обязательно считаются активными. Таким образом устанавливается, какие действия протекают между Актером и системой, а не то, кто является исходным пунктом действия. Однако предлагается рассматривать Актеров в качестве этого исходного пункта действий.

Рисунок 14.18 показывает диаграмму приложений для процесса подачи заявки на командировку. Последовательность действий для «заполнения запроса» может быть следующей: «внести начало командировки», «внести конец командировки», «направить начальнику для проверки». Аналогично могут быть описаны и другие приложения.

Рис. 14.18. Диаграмма приложений для запроса на командировку

Диаграммы приложений часто уточняются с помощью диаграмм действий, в которых комбинируются элементы диаграмм потоков данных, сетей Петри, блок-схем и т. д. Кроме того, взаимодействие нескольких диаграмм действий через моделирование сигналов и событий для обмена возможно лишь мельком. Это означает, что связь отдельных приложений в нашем примере на уровне Use-Case-диаграммы невозможна вообще, а в диаграммах действий лишь ограниченно. Пример: альтернативное ожидание утверждения или отказа.

Следующий пример показывает диаграмму действий для запроса на командировку (рис. 14.19). Отдельные действия при этом группируются с помощью так называемых плавающих линий {Swim Lanes) в зависимости от того, кто выполняет деятельность. В нашем примере существует плавающая линия для сотрудника, начальника и отдела, ответственного за организацию командировок. Эти плавающие линии могут быть рассмотрены как субъекты, которые выполняют определенные действия. Последовательность действий определяется через контрольный поток, аналогично тому, как это делается и в блок-схемах. Существует возможность разделить через операции Разделения (Fork) и Объединения (Join) отдельный контрольный поток на несколько параллельных контрольных потоков (Fork) или снова соединить их (Join).

Рис. 14.19. Диаграмма действий для запроса на командировку

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

Координирование отдельных действий должно осуществляться через смену контрольными потоками отдельных плавающих линий. Это кажется нереальным, что контрольный поток после заполнения заявки на командировку через сотрудника автоматически отправится к «начальнику». Обычно участники процесса для передачи контрольного потока обмениваются сообщениями.

Подобная передача контрольного потока от одного участника процесса к другому в диаграмме действий не видна и узнается только с помощью когнитивной задачи. Операции Разделения и Объединения в соседних плавающих линиях трудно узнаваемы и искусственны. На практике они часто опускаются, это даже официально разрешено в BPMN^X, что сразу же приводит к семантическим сложностям при операциях Разделения и прежде всего при Объединении.

Несмотря на показанную краткость, UML предлагает, но крайней мере ограниченную возможность создания полного предложения с точки зрения стандартной семантики предложения. В UML Актеры не являются составной частью модели, поэтому их поведение в деталях, а также возможная коммуникация между собой не могут быть рассмотрены. Это можно также увидеть и в том, что Актеры больше не используются в обычных типах диаграмм UML, за исключением диаграммы Временных Последовательностей (Time-Sequence).

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

Субъектно-ориентированный подход с PASS

Основная, представленная в гл. 5 данной книги субъектно-ориентированная методика базируется на Спецификации Параллельных Действий (CHJX/PASS) [4]. СПД охватывает элементы исчисления систем связи Мильнера и взаимодействующих последовательных процессов Хоара (см. параграфы 14.3.4.2 и 14.3.4.3), интегрирует аспекты объектной ориентации и дополняет их графическим обозначением [10, с. 54]. При этом методология S-BPM с субъектами, предикатами и объектами обладает возможностью учитывать все части стандартной семантики, где субъекту отводится роль «первого среди равных».

Резюме

В таблице на рис. 14.20 суммированы все описанные в разделах выше методические подходы к моделированию. Более или менее заполненные круги выражают оценку различных методов с точки зрения стандартной семантики предложения естественного языка. Из представления становится ясно, что во многих методах отсутствуют семантические части. Для образования полных предложений они прагматически дополняются через комментарии естественного языка и через расширения базисных символов.

Субъектно-ориентированное моделирование распространяется на действующие субъекты (носители действия) и распределяет их или их коммуникационные отношения по действиям и бизнес-объектам. Кроме того, это моделирование интуитивное: сокращает затраты на учебу по моделированию до определенных пределов, связанных с приобретением навыка выражать предложения естественным языком.^[1]

Рис. 14.20. Таблица возможностей различных методов и подходов в моделировании бизнес-процессов.

• [1] URL: subprocess.omg.org/spec/BPMN/2.0