Концепция архитектуры aris 1 Типы моделей 1 Уровни представления моделей 5 Анализ процессов 1 Описание проблем бизнеса 1




НазваниеКонцепция архитектуры aris 1 Типы моделей 1 Уровни представления моделей 5 Анализ процессов 1 Описание проблем бизнеса 1
страница6/17
Дата публикации26.07.2013
Размер1.56 Mb.
ТипРеферат
www.lit-yaz.ru > Информатика > Реферат
1   2   3   4   5   6   7   8   9   ...   17
^

4.Моделирование в архитектуре ARIS. Типы моделей и уровни описаний

4.1. Функциональная модель

4.1.1. Формулировка требований


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

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

Определение

Функция – это предметно-ориентированное задание или действие, выполняемое над объектом, в результате которых достигается одна или несколько целей, стоящих перед компанией.

Функции отображаются в виде прямоугольников с закругленными углами (см. рис. 4.1.1-1).



Рис. 4.1.1-1. Пример функции «проверить достоверность запроса клиента»

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

4.1.1.1. Функциональное дерево


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

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

Определение

Базовая функция – это функция, которая уже не может быть разделена на составные элементы с целью анализа бизнес-процесса.

Для представления иерархической структуры функций служит диаграмма дерева функции, или иерархическая диаграмма (см. рис. 4.1.1-2).



Рис. 4.1.1-2. Дерево функций (частичная модель)

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

Объектно-ориентированный подход при детализации функции иллюстрирует рис. 4.1.1-3.



Рис. 4.1.1-3. Объектно-ориентированное функциональное дерево

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

Если функциональное дерево используется в рамках моделирования бизнес-процесса, предпочтительнее применять метод, позволяющий построить процессо-ориентированное функциональное дерево. На рис. 4.1.1-4 представлена процессо-ориентированная детализация функции (последовательность функций, составляющих процесс).



Рис. 4.1.1-4. Процессо-ориентированное функциональное дерево

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

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



Рис. 4.1.1-5. Операционно-ориентированное функциональное дерево

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

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

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

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

4.1.1.2. Y - диаграмма


Y-диаграмма представляет функции (задания) компании на самом верхнем уровне агрегации. Здесь мы имеем дело с основными макро-функциями: прототипированием изделия, управлением материалами, обслуживанием. Структурное представление в виде модели Y-CIM классифицирует отдельные функции. Левая ветвь Y содержит основные управленческо-административные функции, связанные с планированием и управлением производством, а правая - технико-ориентированные функции планирования производства и реализации продукции. Функции планирования расположены в верхних частях Y, в то время как функции управления и реализации находятся в нижней части.

Модель Y-CIM представляет основу для классификации всех функций компании, участвующих в производстве.

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

Y-диаграмма представлена на рис. 4.1.1-6.



Рис. 4.1.1-6. Y-диаграмма
^

4.1.1.3. Диаграмма SAP-приложений


Диаграмма SAP-приложений позволяет представлять модели-прототипы SAP R/3, ориентированные на модули системы управления предприятием SAP R/3. В модели-прототипе R/3 матрица выбора процессов связана с каждым объектом диаграммы данного типа. Она отображает основные процессы, доступные в отдельных модулях R/3, и сценарии процессов, которые могут быть затем проиллюстрированы.

Диаграмма SAP-приложений в системе SAP R/3 представлена на рис. 4.1.1-7.



Рис. 4.1.1-7. Диаграмма SAP-приложений
^

4.1.1.4. Диаграмма целей


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

С помощью диаграммы целей можно описать цели компании и построить их иерархию.

Определение

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

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

Определение

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

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

Диаграммы целей показана на рис. 4.1.1-8.



Рис. 4.1.1-8. Диаграмма целей
^

4.1.2. Спецификация проекта. Диаграмма типа прикладной системы


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

На уровне спецификации проекта в рамках функциональной модели необходимо ответить на следующие ключевые вопросы:

  • Какова может быть поддержка функций, определенных с помощью типов ПС, типов модулей или проектов этих функций?

  • Можем ли мы что-либо сказать о модульной структуре ПС или типах модулей?

  • Какие списки и экраны потребуются для выполнения функции?

  • Какие списки могут быть созданы с помощью прикладной системы данного типа или модуля данного типа и какие экраны поддерживают прикладную систему и модули данных типов?

  • Какая технологическая база имеется в распоряжении для реализации прикладной системы данного типа (операционная система, интерфейс пользователя или система управления базами данных)?

  • Как соотносится с целями компании прикладная система определенного типа?

Тип ПС может рассматриваться как тип основного объекта в рамках функциональной модели на этапе спецификации проекта.

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

Определение

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

Пример. Инструментарий ARIS, версия 4.1, представляет тип ПС. Вы можете приобрести несколько лицензий этого типа ПС и таким образом стать собственником нескольких конкретных прикладных систем.

На рис. 4.2.1.-1 приведен тип прикладной системы.



Рис. 4.1.2-1. Типа прикладной системы

Тип прикладной системы – это некоторая обобщенная ПС, состоящая, как правило, из отдельных модулей. Диаграмма типа прикладной системы – это представление ее модульной структуры. Типы модулей образуют отдельные части типа ПС, как показано на рис. 4.1.2-2.



Рис. 4.1.2-2. Модульная структура типа ПС

Инструментарий ARIS Toolset, версия 4.1, состоит из модулей следующих типов: модуль компоновки, версия 4.1, модуль навигации, версия 4.1, и модуль моделирования, версия 4.1. Так же, как типы прикладной системы, типы модулей объединяют отдельные модули, базирующиеся на одной и той же технологии. Типы модулей содержатся в типах прикладной системы и представляют отдельные выполняемые компоненты.

Определение

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

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

Определение

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

Рис. 4.1.2-3 иллюстрирует тип функции.



Рис. 4.1.2-3. Графическое представление типа функций

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



Рис. 4.1.2-4. Соотнесение функций типам ПС

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

Таким образом, тип ПС может соответствовать пользовательскому интерфейсу Windows 98 и Windows NT. Это означает, что данная версия типа ПС способна работать с пользовательскими интерфейсами обоих типов. Только в том случае, когда пользовательский интерфейс соответсвует конкретной прикладной системе на уровне описания реализации в рамках функциональной модели, становится необходимой уникальная взаимосвязь. Эта взаимосвязь описывает конфигурацию отдельной лицензии на типы ПС, которые были приобретены компанией.

Пример возможной привязки в рамках диаграммы типа ПС представлен на рис. 4.1.2-5.



Рис. 4.1.2-5. Конфигурация типа ПС

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

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



Рис. 4.1.2-6. Привязка экранов и списков

В в гл. 9 английской версии руководства «Методы ARIS» содержится список всех типов объектов диаграммы типа ПС и возможные отношения.
^

4.1.3. Описание реализации. Диаграмма прикладной системы


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

Определение

Прикладная система (модуль) – это единственный экземпляр типа ПС (типа модуля), который может быть уникально идентифицирован.

Графическое представление прикладных систем и модулей приведено
на рис. 4.1.3-1.



Рис. 4.1.3-1. Графическое представление прикладной системы и модуля

Если компания имеет несколько лицензий на один тип ПС (тип модуля), то на диаграмме прикладной системы несколько прикладных систем (модулей) могут соответствовать одному типу ПС (типу модуля). Это показано на рис. 4.1.3-2.



Рис. 4.1.3-2. Привязка прикладных систем к типам ПС

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



Рис. 4.1.3-3. Различная модульная структура двух прикладных систем одного типа

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

Диаграммы ПС наглядно показывают какие типы программных элементов необходимы для реализации данного типа ПС и типа модуля.

Определение

Программный элемент – это отдельный программный файл, расположенный на носителе данных (например, файл EXE или COM), и приобретаемый вместе с лицензией. Типы программных элементов – это совокупность типов программных элементов, базирующихся на одной и той же технологии.

Рис. 4.1.3-4 иллюстрирует привязку типов программных элементов к типам ПС и отдельных программных элементов к типам программных элементов.



Рис. 4.1.3-4. Привязка типов ПС, типов программных элементов и программных элементов

Для типа ПС ARIS Toolset, версия 4.1, типами программных элементов являются aris.exe, aris.xlm, arisen.dll и merge.exe. Если в компании куплены многопользовательские лицензии или созданы резервные копии, то для каждого типа программного элемента могут быть доступны несколько программных элементов.

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

В гл. 9 английской версии руководства «Методы ARIS» содержится список всех типов объектов и типов отношений для диаграмм прикладных систем.
1   2   3   4   5   6   7   8   9   ...   17

Похожие:

Концепция архитектуры aris 1 Типы моделей 1 Уровни представления моделей 5 Анализ процессов 1 Описание проблем бизнеса 1 iconЭффективная реализация расширяемой метамодели case-средства на основе uml 0
Это означает, что, используя такое средство, пользователь может создавать в нём не только заранее определенный класс моделей, а имеет...

Концепция архитектуры aris 1 Типы моделей 1 Уровни представления моделей 5 Анализ процессов 1 Описание проблем бизнеса 1 iconПамяти Леонарда Андреевича Растригина Гринченко С. Н. ( sng @ kynosoft ru )
Случайный поиск, адаптация и эволюция: от моделей биосистем к языку представления о мире. Часть 1

Концепция архитектуры aris 1 Типы моделей 1 Уровни представления моделей 5 Анализ процессов 1 Описание проблем бизнеса 1 iconЭкономико-математическое моделирование Вопросы по курсу Часть Основные понятия моделирования
Роль математических моделей в управлении. Методика формализации задач в системах организационного управления. Описание альтернатив,...

Концепция архитектуры aris 1 Типы моделей 1 Уровни представления моделей 5 Анализ процессов 1 Описание проблем бизнеса 1 iconВведение 2 1 теоретические основы оценки банковских кредитных рисков 4
Анализ иструментов data mining для построения скоринговых моделей оценки кредитоспособности заемщика 26

Концепция архитектуры aris 1 Типы моделей 1 Уровни представления моделей 5 Анализ процессов 1 Описание проблем бизнеса 1 iconАнализ предметной области Постановка задач
Цель данного курсового проекта – разработка программной информационной системы «Интерактивная среда разработки idef-моделей» с использованием...

Концепция архитектуры aris 1 Типы моделей 1 Уровни представления моделей 5 Анализ процессов 1 Описание проблем бизнеса 1 iconЛитература 122
Описание и модели архитектуры системы, общее описание принципов функционирования 29

Концепция архитектуры aris 1 Типы моделей 1 Уровни представления моделей 5 Анализ процессов 1 Описание проблем бизнеса 1 iconЕ. Д. Соложенцев Институт проблем машиноведения ран, Санкт-Петербург
Аннотация. Обоснована актуальность и изложена суть проблемы, изложены основные положения и 3 технологий, сформулированы цели и задачи...

Концепция архитектуры aris 1 Типы моделей 1 Уровни представления моделей 5 Анализ процессов 1 Описание проблем бизнеса 1 iconТема фестиваля
Ирина коробьина, директор музея архитектуры им. Щусева, кандидат архитектуры, действительный член Международной академии архитектуры,...

Концепция архитектуры aris 1 Типы моделей 1 Уровни представления моделей 5 Анализ процессов 1 Описание проблем бизнеса 1 iconРазработка моделей, алгоритмов и программных средств для повышения...
Разработка моделей, алгоритмов и программных средств для повышения качества прогнозов биржевых показателей

Концепция архитектуры aris 1 Типы моделей 1 Уровни представления моделей 5 Анализ процессов 1 Описание проблем бизнеса 1 icon«Автоматизация звука [ р ] в изолированном произношении, в слогах,...
Тема занятия «Автоматизация звука [ р ] в изолированном произношении, в слогах, словах, с использованием карточек- моделей артикуляции...



Образовательный материал



При копировании материала укажите ссылку © 2013
контакты
www.lit-yaz.ru
главная страница