А. З. Моделирование отношений между разными типами представлений (модель управления) 88

Вид материала

А.З. Моделирование отношений между разными типами представлений (модель управления)
А. 3.1. Отношения между функциями и организацией
А.З.1.1. Моделирование определения требований
А.3.1.1.2. Диаграмма взаимодействия
А.3.1.2. Конфигурирование
А.3.1.3. Спецификация проекта

Подобный материал:

1 2 3 4 5 6 7 8 9 10 ... 16

А.З. Моделирование отношений между разными типами представлений (модель управления)

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

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

А. 3.1. Отношения между функциями и организацией

На рис. 85 показаны отношения между функциональной и организационной моделями.

Рис. 85. Отношения между функциями и структурой организации

На рис. 86 приведено базовое отношение между бизнес-функцией и организационной единицей. Однако эта связь может иметь разные семантические ответвления. Кроме того, возможны различные исходные модели и разграничения, связанные с распределением функций.

Рис. 86. Общее отношение между организационной единицей и функциями

А.З.1.1. Моделирование определения требований

А.З.1.1.1. Диаграммы связи функция-организация

При описании функций и организации возможны различные уровни детализации.

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

Рис. 87. Модель на уровне функций

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

Организационные

единицы

Функции

Управление

Маркетинг

Управление и организация

Управление филиала

Людские ресурсы

Учет и контроль стоимости

Продажа

Продажа и дистрибуция

НИОКР

Производство

Закупки / снабжение

Склад материалов

Анализ рынка

Планирование производственной программы

Обработка предложений

Обработка заказов

Разработка продуктов

Производственное планирование

Закупка материалов

Управление складом

Производственное управление и контроль

Обеспечение качества

Отправка

Учет и контроль стоимости

Финансовое и инвестиционное планирование

Планирование и совершенствование людских ресурсов

Инвентаризация и подведение баланса на конец года

о = несет ответственность у = активно участвует с = оказывает содействие

Рис. 88. Матричное описание распределения функций

Если в выполнении функции участвует несколько организационных единиц, можно уточнить тип участия каждой из них, дополнительно указав, какие организационные единицы несут ответственность за данную функцию, какие активно участвуют в ее реализации, а какие лишь оказывают содействие. Другие примеры из реальной практики содержатся в работе: Martin. Information Engineering II. 1990, с. 58.

Функциональную модель и матрицу распределения функций можно представить отношением АССОЦИАЦИЯ ФУНКЦИИ, как показано в метамодели на рис. 89. Эта ассоциация относится к основным функциям.

Рис. 89. Диаграмма классов для распределения функций

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

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

Можно не только детализировать связи основных функций с предварительными уровнями, но и привязывать пользовательские транзакции к исполнительским должностям в рамках организации или к конкретным пользователям (см. рис. 90). В этом контексте мы употребляем термин «пользовательская транзакция», введенный при обсуждении функциональных моделей. Этот термин, в свою очередь, связан с понятием «должность», введенным на уровне организационного моделирования. Это обеспечивает доступ к конкретным пользовательским транзакциям различным исполнителям, занимающим соответствующие должности. Можно также (хотя это и необязательно) присваивать должностям полномочия на исполнение нескольких пользовательских транзакций; минимальное значение мощности при этом равно 0.

Рис. 90. Привязка транзакций к конкретным пользователям

А.3.1.1.2. Диаграмма взаимодействия

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

Диаграммы взаимодействия описывают, каким образом организационные единицы в качестве «субъектов действия» взаимодействуют с функциями. Понятие «диаграмма взаимодействия» несколько расплывчато и включает описание лишь части бизнес-процесса, выполняемой за одну операцию, т.е. без каких-либо существенных разрывов во времени или пространстве. Диаграммы взаимодействия позволяют «взять в свои руки» такие сложные вопросы, как бизнес-процессы. Пример диаграммы взаимодействия приведен на рис. 91 (дополнительные примеры можно найти в работе: Oestereich. Objektorientierte Softwareentwicklung. 1997, с. 215).

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

Рис. 91. Диаграмма взаимодействия (UML Notation Guide. 1997, рис. 33)

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

Рис. 92. Метамодель диаграммы взаимодействия

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

Распределение функций между организационными единицами играет ключевую роль в конфигурировании систем.

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

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

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

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

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

Рис. 93а. Пример управления материалами для функций, разделенных в рамках организации

Рис. 93б. Диаграмма ЕРС для примера, приведенного на рис. 93а

Рис. 93в. Пример управления материалами для функций, объединенных в рамках организации

Рис. 93г. Диаграмма ЕРС для примера, приведенного на рис. 93в

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

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

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

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

На рис. 94 показано два способа конструирования ПОЛНОМОЧИЙ. Различные типы полномочий называются ПРОГРАММНЫМИ ОБЪЕКТАМИ и представляют собой общие версии МОДУЛЕЙ, ЭКРАНОВ и СПИСКОВ. Если функции полномочий связываются с каждым пользователем через матрицу полномочий, ПОЛНОМОЧИЯ образуют ассоциацию между классами ТИП ПОЛНОМОЧИЙ, ОРГАНИЗАЦИОННАЯ ЕДИНИЦА (ПОЛЬЗОВАТЕЛЬ) и ПРОГРАММНЫЙ ОБЪЕКТ. Таким образом, пользователи с идентичными профилями полномочий описываются индивидуально, что делает администрирование громоздким и избыточным.

Рис. 94. Конфигурирование полномочий

Другой способ, показанный на рисунке, позволяет избежать избыточности. Сначала некоторые профили полномочий привязываются к ПАРОЛЮ через ПОЛНОМОЧИЯ ПАРОЛЯ, который, в свою очередь, связывается с пользовательскими группами или отдельными пользователями при помощи ассоциативного класса АССОЦИАЦИЯ ПОЛЬЗОВАТЕЛЬ-ПАРОЛЬ. Такое косвенное описание существенно снижает избыточность информации.

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

На стадии спецификации проекта ПРОГРАММНЫЕ ОБЪЕКТЫ (модули, бизнес-объекты, пользовательские транзакции) привязываются к конкретным УЗЛАМ компьютерной сети. Они могут влиять на физические системы хранения или физический доступ, используя стандартные методы (удаленные вызовы процедур, CORBA, DCOM и т.д.) или оригинальные методы доступа, такие как, например, удаленный вызов функций (RFC) или ALE в приложениях SAP. На рис. 95 некоторые из этих вариантов представлены классом ТИП АССОЦИАЦИИ.

Рис. 95. Описание хранения и доступа

Blog