А.3.2.1.1.4. Ассоциация экранов



Функции представляются с помощью экранов, отображающих данные или задающих поля для их ввода. С такими бизнес-функциями, как, например, «создание заказа клиента», может быть связано несколько экранов. И наоборот, некоторые экраны могут активизироваться несколькими функциями. Следовательно, экраны связаны с классом ФУНКЦИЯ ассоциацией *:* (см. рис. 105).

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

Экраны приложений или функций отражают требования к входным данным или выходы бизнес-функций.

Экраны описываются соответствующими моделями. Привязывая модели к функциям, можно настраивать конфигурацию функций в соответствии с представленными на экране объектами данных. Например, функции ввода данных, связанные с типом сущности КЛИЕНТ, позволяют вводить данные о клиентах, а функции, связанные с типом сущности ПАЦИЕНТ, — данные о пациентах. Средства редактирования функций можно расширить путем изменения содержания экрана (например, атрибутов добавления или удаления).

На рис. 106а показана модель экрана, содержащая атрибуты типов сущностей КЛИЕНТ и АДРЕС. Соответствующие отношения для обработки мастер-данных формы о клиенте представлены на рис. 106в. В этом примере ФОРМА КЛИЕНТА представляет собой весьма сложный объект данных. В правой части рис. 106а указывается источник происхождения данных, каковым служит модель данных. Эти отношения дополняют метамодель на рис. 105.

Экраны проектируются по иерархическому принципу и состоят из страниц, разделов и столбцов (см. рис. 106б). Дополнив модель экрана деталями компоновки, можно автоматически генерировать экран, представленный на рис. 106г (IDS. ARIS-Framework. 1997).

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

 

Рис . 105. Отображение потока данных с помощью ассоциации ОПЕРАЦИЯ

 

 

Рис . 106 а . Структура и атрибуты сложного типа объекта «форма клиента»

 

Рис . 106б. Пример компоновки модели экрана

 

Рис . 106 в . Модель данных для шаблона клиента

Рис . 106 г . Экран с таблицей

 

А.3.2.1.2. Управление посредством событий и сообщений

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

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

Обмен сообщениями описывает динамическое поведение объектов и в объектно-ориентированных методах.

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

А.3.2.1.2.1. Правило СУД

В информатике для регулирования управляющих потоков применяется правило СУД (событие-условие-действие) ( Dittrich , Gatziu . Aktive Datenbanksysteme . 1996, с. 10), хотя правила СУД описывают также и бизнес-правила ( Herbst , Knolmayer . Geschd ftsregeln . 1995).

События характеризуют направленные действия, заключая в себе факты (что), происходящие в определенный момент времени (когда). В рамках временных событий «что» и «когда» совпадают (например, 6 часов вечера). Условия задают обстоятельства наступления соответствующего события. Действия определяют реакцию на возникновение той или иной ситуации.

В моделях бизнес-процессов ARIS события создаются обрабатывающими функциями или субъектами действия, находящимися за рамками модели. В процессе моделирования отбираются релевантные события, поэтому в модель включаются только те события, которые влияют на бизнес-процесс. Таким образом, условия входят в описание события, сводя правило СУД к правилу СД (событие-действие).

Вместо уравнения «событие = общая сумма заказа известна» с последующей проверкой условия «общая сумма заказа > 5000 долл.» (сценарий (а) на рис. 107) мы для начала введем два возможных релевантных события (сценарий (б) на рис. 107).

 

Рис . 107. Способы моделирования событий

 

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

Связи между событиями могут быть сложными и разнообразными. Например, для активизации некоторой функции может потребоваться несколько событий, при этом иногда играет роль даже последовательность их наступления. Такие сложные события можно описывать «алгебраически», используя операторы дизъюнкции (логического сложения), последовательности, конъюнкции (логического умножения) и отрицания ( Dittrich , Gatziu . Aktive Datenbanksysteme. 1996, с . 26).


Дата добавления: 2019-02-26; просмотров: 149; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!