Моделирование бизнес-процессов (стр. 22 )

Данный подход вновь акцентирует внимание на различии между парадигмами проектирования с ориентацией на процессы и проектирования с ориентацией на объекты. На рис. 117 приведен фрагмент оСДП, наглядно иллюстрирующий проблемы, о которых мы говорили в связи с процессом создания объекта.

Рис. 117. Объектно-ориентированная диаграмма СДП для ввода заказа

А.3.2.2. Конфигурирование

В зависимости от контекста, относящегося к функциям и данным модель может быть наполнена самым разным содержанием.

Используя здесь моделируемые события как «вехи», можно определить ответственные моменты для обновления данных, касающихся стоимости или времени выполнения конкретных бизнес-процессов. Наступление этих событий инициирует проведение оценки и сообщение ее результатов руководству.

Управление рабочими потоками (workflow) основывается на потоке управления, описываемом диаграммой СДП. Поток управления копируется из соответствующей модели для обработки в рамках экземпляров процессов.

Применительно к управлению потоком работ управляющие структуры можно моделировать более детально, включая, например, задержки перед началом работы, ситуации отказа от порученных задач или учет предельных мощностей при их распределении. (Jablonski. Workflow-Management-Systeme. 1995, с. 35).

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

Бизнес-функции определяют, какие приложения должна запускать система workflow, включая присвоенные им программные имена. На рис. 118 показано, как использовать СДП в модели workflow.

Рис. 118. Использование СДП в рамках модели workflow

Как и при управлении потоками работ, потоки управления стандартными приложениями можно представлять в виде СДП. Однако в отличие от workflow, эта процедура не допускает произвольного конфигурирования, а требует соблюдения параметров, предписываемых стандартным приложением. Это означает, что можно выбирать функции (путем редактирования) или задавать определенные последовательности вызовов функций.

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

На рис. 119 приведен пример конфигурирования SAP R/3 при помощи модификации СДП (верхний экран). Незаштрихованная область диаграммы процесса в этом реальном сценарии деактивизирована, поэтому ее программные функции не задействованы. На нижнем экране показано руководство по настройке, открывающее прямой доступ к соответствующим транзакциям настройки, проектной информации и документам. Это отображается на экране символами «галочка», «карандаш» и «документ».

Рис. 119. Конфигурирование R/3 с помощью СДП (источник: SAP AG)

Функции можно также модифицировать путем изменения моделей экранов. Например, если в моделях экранов, показанных на рис. 106а и 1066, удалить данные об адресах, то функции создания и обновления применительно к этим данным становятся недоступны. Поскольку вводить адреса при этом тоже нельзя, модифицируется и связь между объектом данных и функцией.

А.3.2.3. Спецификация проекта

А.3.2.3.1. Связывание модулей с базами данных

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

А.3.2.3.1.1. Привязка схемы

Прикладным модулям не нужно общаться со всей концептуальной схемой

базы данных: достаточно лишь некоторых фрагментов.

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

Внешние схемы баз данных, связывающие пользователей с концептуальной схемой, описывают логические представления баз данных с точки зрения конкретного приложения или отдельных пользователей. На основе реляционной схемы можно вывести новые отношения, опустив атрибуты или некоторые кортежи базисных отношений, скомбинировав базисные отношения в соответствии с определенными критериями или, наоборот, разложив их на ряд более детальных отношений. Один из важнейших методов состоит в описании так называемых представлений. В общем виде это выглядит следующим образом (Mayr, Dittrich, Lockemann. Datenbankentwurf. 1987, с. 537):

• ОПИСАТЬ ПРЕДСТАВЛЕНИЕ [имя представления],

• ВЫБРАТЬ [выражение].

Метаструктура таких представлений показана на рис. 120. Вся концептуальная схема, состоящая из отношений, атрибутов и условий целостности, представлена сложным объектом КОНЦЕПТУАЛЬНАЯ СХЕМА. Ассоциации связывают ВНЕШНИЕ СХЕМЫ с КОНЦЕПТУАЛЬНЫМИ СХЕМАМИ. К одному МОДУЛЮ можно привязать несколько внешних схем и, наоборот, внешние схемы можно привязать к нескольким модулям.

Рис. 120. Связывание модулей со схемой базы данных

А.3.2.3.1.2. Выведение структур управления

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

Структуры управления можно связывать со структурами данных. Ассоциации 1:1 между классами соответствуют последовательности; ассоциации 1:* соответствуют итерации, а операции конкретизации (разбивающие информационные объекты на подчлены) соответствуют выбору.

К информационному объекту КЛИЕНТ однозначным образом привязывается счет (ассоциация 1:1). Один клиент может порождать множество бизнес-событий, однако любое бизнес-событие всегда связано только с одним клиентом. БИЗНЕС-СОБЫТИЯ можно конкретизировать, подразделив их на ЗАКАЗ и ОТМЕНУ, (см. рис. 121).

Рис. 121. Отношения между структурами управления и структурами данных

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

Рис.122. Структура управления

Различные бизнес-события с мощностью * (со стороны клиента), обрабатываемые для данного клиента, представлены как итерация.

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

Метаописания опускаются. Такое проектирование программы, ориентированное на структуру данных, аналогично построению обмена сообщениями на основе ассоциаций диаграммы классов в контексте объектно-ориентированных методов.

А.3.2.3.1.3. Транзакции баз данных

Обновление баз данных основано на концепции транзакций, свойства которых описываются термином ACID (A - атомарность, С - согласованность, I - изолированность, D - долговечность). Транзакции включают серию операций базы данных, которая — с точки зрения приложения — не должна прерываться. Это означает, что с точки зрения приложений согласование базы данных производится лишь в том случае, если транзакция доведена до конца. В случае же ошибки выполняется «откат», т. е. данные возвращаются в состояние, предшествовавшее транзакции. Это свойство транзакций называется атомарностью. База данных обновляется лишь при условии успешного завершения транзакции.

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

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

Транзакции характеризуются понятиями «начало транзакции» и «конец транзакции». В рамках этих двух этапов может заключаться любое число команд записи в файл или чтения. Транзакции также используются в качестве единиц для измерения числа этапов восстановления данных.

С точки зрения проектирования программ, транзакции могут интерпретироваться как модули, поэтому на рис. 123 мы вводим ТРАНЗАКЦИИ как конкретизацию понятия МОДУЛЬ. На стадии спецификации проекта мы говорили, что модули можно связывать друг с другом в сети. Та же ситуация и здесь.

Рис. 123. Концепция транзакций

Несколько операций базы данных группируются в одну транзакцию, в результате чего ОПЕРАЦИЯ БАЗЫ ДАННЫХ (БД) превращается в ассоциацию между ТИПОМ ОПЕРАЦИИ БД (как в процессе чтения или записи в файл), соответствующей ТРАНЗАКЦИЕЙ и упоминавшимся ранее ИНФОРМАЦИОННЫМ ОБЪЕКТОМ.

А.3.2.3.2. Управление посредством триггеров

Базы данных являются не только средством для пассивного хранения корпоративных данных. К ним также подсоединяются компоненты, реагирующие на определенные события и действия, связанные с приложениями. Эти компоненты инициируют обновление базы данных (активные системы баз данных) и называются триггерами. Понятие «триггер» мы ввели в разделе А.2.3.3.3, когда рассматривали условия целостности при спецификации проекта на уровне модели данных.