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




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

4.2. Модель данных

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


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

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

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

В последующих разделах дается введение в метод моделирования, базирующийся на модели сущность-отношение (ERM). В первую очередь рассматриваются объекты и взаимосвязи исходной модели Чена. Далее к исходной модели добавляются некоторые операции.
^

4.2.1.1. Базовая модель ERM


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

Определение

Сущность – это реальный или абстрактный объект, представляющий интерес для задач в конкретной области деятельности.

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

  • клиент 1235,

  • изделие 4711,

  • заказ 11.

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

Определение

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

Сущности одного и того же типа могут быть описаны одними и теми же атрибутами. Таким образом, клиент ^ Иванов и клиент Петров вместе образуют сущность типа клиент, а изделие 4711 вместе с изделием 4712 образуют сущность изделие. Типы сущностей отображаются в модели ERM в виде прямоугольников (см. рис. 4.2.1-1). В последующем изложении типы сущностей обозначены прописными буквами.



Рис. 4.2.1-1. Типов сущностей

Определение

Атрибуты – это свойства, описывающие типы сущностей.

Экземпляры атрибутов – это фактические значения атрибутов, присвоенные отдельным сущностям. Например, клиент ^ 1235 может быть описан посредством экземпляров атрибутов Петров, Иван, Москва и т.д. Соответствующими атрибутами здесь являются фамилия, имя и город.

Атрибуты обычно изображаются эллипсами или окружностями. Далее на рисунках атрибуты представлены эллипсами. На рис. 4.2.1-2 приведены атрибуты для типа сущности клиент.



Рис. 4.2.1-2. Атрибутов типа сущности «клиент»

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

Запомните, что сущности могут обладать атрибутами вне зависимости от того, имеете ли вы дело с типом сущности или атрибутом. С другой стороны, атрибуты не могут обладать атрибутами. Таким образом, если в модели ERM создается атрибут, и предполагается, что он будет в дальнейшем описан другими атрибутами, то атрибут становится типом сущности. Другой важный критерий при определении сущности – будет ли рассматриваемый объект взаимосвязан с другими типами сущностей или нет. Если такая связь предполагается, то этот объект также является типом сущности.

Определение

Отношение – это логическая связь между сущностями.

Следовательно, существование отношений прямо зависит от существования сущностей.

Определение

Отношения одного и того же типа, сгруппированные в наборы, определяют тип отношений.

Тип отношения между поставщик и деталь может быть снабжает. Здесь и в последующем тексте типы отношений обозначаются прописными буквами. В модели ERM типы отношений изображаются ромбами, которые соединены с типами сущностей (см. рис. 4.2.1-3).



Рис. 4.2.1-3. Тип отношений

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

Теперь следует дифференцировать типы отношений. В этом контексте критериями отличия являются: число типов сущностей, которые соединены типом отношений, и степень сложности отношений.

Типы отношений различаются по числу типов сущностей, связанных с ними. Будем различать унарные, бинарные и n-арные отношения.

Определение

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

Отношения, образованные указанным образом, представлены на рис. 4.2.1-4.

Различаются четыре типа отношений:

  • отношение 1:1,

  • отношение 1:n,

  • отношение n:1,

  • отношение n:m.

При отношении 1:1 только одна сущность из второго набора соответсвует каждой сущности из первого набора. При отношении 1:n только одна сущность из второго набора связана с каждой сущностью из первого набора, но n сущностей из первого набора связаны с каждой сущностью из второго набора. Отношение n:1 отображает ту же ситуацию, но в обратном порядке. При отношении n:m несколько сущностей из второго набора связаны с одной сущностью из первого набора и наоборот.



Рис. 4.2.1-4. Мощность отношений между двумя типами сущностей

Мощность типов отношений (тип атрибута степень сложности) представлена соединениями на диаграмме сущность-отношение (см. рис. 4.2.1-5).



Рис. 4.2.1-5. Представление мощности типов отношений в модели ERM

Мощность определяет максимальное число принадлежащих некоторому типу отношений, в которых может участвовать одна сущность, принадлежащая к некоторому типу сущностей. Это означает, что для отношения n:1 на рис. 4.2.1-5 компания, имеющая тип сущности КОМПАНИЯ, может многократно находиться в различных отношениях ВЛАДЕЕТ, если эта компания имеет дело с различными фабриками. Однако каждая отдельная фабрика имеет только одно отношение типа ВЛАДЕЕТ: она может принадлежать только одной компании.

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

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



Рис. 4.2.1-6. Модель ERM для списка материалов

Посредством атрибутов описываются не только типы сущностей. Они же используются при описании типов отношений (см. рис. 4.2.1-7).

Определение

Диапазон значений атрибутов называется областью.

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

Определение

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

В примере, приведенном на рис. 4.2.1-7, отдельные сущности типа КЛИЕНТ однозначно идентифицированы ключевым атрибутом номер клиента.



Рис. 4.2.1-7. Определение атрибутов в модели ERM

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

Описательные атрибуты соответствующих объектов данных определяются значениями, взятыми из областей, которые имеют мощность отношения 1:n с сущностью или типом отношения.
^

4.2.1.2. Расширенная модель «Сущность-отношение» (eERM)


В течение последних нескольких лет оригинальная модель Чена была значительно расширена. В данном руководстве будут рассматриваться такие расширенные модели, которые существенны для модели данных в архитектуре ARIS.
^
4.2.1.2.1. Расширение модели с помощью операторов проектирования

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

Опираясь на ряд различных подходов к расширению модели «сущность-отношение», можно выделить четыре основных оператора проектирования:

  • классификацию,

  • обобщение,

  • агрегацию,

  • группировку.

Классификация

Определение

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

Таким образом, классификация ведет к ранее описанной идентификации типов сущностей (см. рис. 4.2.1-8).



Рис. 4.2.1-8. Классификация клиентов

Обобщение/Специализация

Определение

При обобщении аналогичные типы объектов группируются под одним, более старшим типом объекта.

Как показано на рис. 4.2.1-9, тип сущности ^ Клиент и тип сущности Поставщик объединены под общей концепцией Участник бизнес-процесса. Свойства (описанные атрибутами), которые являются общими для обоих исходных объектов, присваиваются обобщенному объекту. Таким образом, остается описать только такие атрибуты, которые отличны от атрибутов исходных типов объектов. Образование нового типа сущности Участник бизнес-процесса представляется графически в виде треугольника, который также является отношением и означает есть.

Определение

Под специализацией понимается разделение некоторого общего множества (например, объектов) на подмножества.

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

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



Рис. 4.2.1-9. Обобщение/Специализация

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

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

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

Когда все специализированные типы объектов, возможные для одного критерия специализации, входят в состав одного обобщенного типа объекта, мы говорим о полной специализации. Возьмем, например, тип сущности Человек: он может быть разделен на типы сущностей Мужчина и Женщина (см. рис. 4.2.1-10). Специализация полностью определена, если мы в качестве критерия специализации выбираем пол.



Рис. 4.2.1-10. Полная специализация

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

  • раздельная/полная,

  • раздельная/неполная,

  • не раздельная/полная,

  • не раздельная/неполная.

Агрегация

Определение

Агрегация описывает формирование нового типа объекта с помощью комбинации существующих типов объектов. В этом контексте новый тип объекта может нести новые свойства.

В eER-модели агрегация представляется как формирование типов отношений (см. рис. 4.2.1-11). Агрегация типов сущностей Заказ на производство и Маршрутизация создает новый объект Маршрутизация заказа.



Рис. 4.2.1-11. Пример агрегации

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



Рис. 4.2.1-12. Агрегация с реинтерпретацией типа отношений

Первая агрегация используется для формирования типа отношения Маршрутизация заказа из типов сущностей Заказ на производство и Маршрутизация. Ключевые атрибуты номер заказа на производство и номер маршрута образуют сложный ключевой атрибут для отношения к Маршрутизации заказа. Теперь многочисленные операции могут быть связаны с Маршрутизацией заказа. Следовательно, отношение Операция над заказом формируется между типами отношений Маршрутизация заказа и типом сущности Операция. Поскольку отношения могут создаваться только между типами сущностей, необходимо, чтобы первоначальный тип отношения Маршрутизация заказа был интерпретирован как тип сущности. На рис. 4.2.1-12 это иллюстрирует ромб, заключенный в прямоугольник.

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

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

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

Определение

Кластер данных описывает логическую модель некоторых типов сущностей и отношений в модели данных. Это необходимо для описания сложных объектов.

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

На рис. 4.2.1-13 представлен графический элемент кластера данных. Как показано на рис. 4.2.1-14, кластер данных – это логическая модель некоторых типов сущностей и отношений. Для описания сложного объекта Заказ клиента необходимы типы сущностей и отношений Клиент, Время, Предмет заказа, Изделие и Позиция заказа.



Рис. 4.2.1-13. Кластер данных (графическое представление)



Рис. 4.2.1-14. Кластера данных для нескольких объектов

Группировка

Определение

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

В примере, на рис. 4.2.1-15 все составные части Оборудования объединяются в Группу оборудования. Группа оборудования – это независимый объект, который может быть описан более точно с помощью дополнительных атрибутов (наименование группы оборудования, число деталей оборудования), которые не характеризуют отдельные части оборудования. Другим примером модет служить группировка рабочих мест в отделы или объединение элементов, связанных с обработкой заказа, в группу Заказ.



Рис. 4.2.1-15. Группировка
^
4.2.1.2.2. Расширенное понятие мощности

При ссылке на число, характеризующее мощность отношений, мы упоминали только про верхние пределы допустимого числа экземпляров отношений. Мощности на рис. 4.2.1-16 указывают, что проект может быть связан с максимальным числом (m) служащих и один служащий может участвовать в максимальном числе (n) проектов.



Рис. 4.2.1-16. Верхнее/нижнее ограничение (1)

Кроме верхнего ограничения, может также представлять интерес нижнее ограничение в том случае, когда нужно специфицировать минимальное число экземпляров отношений. Для этих целей мощность отношений может быть выражена, например, двумя буквами (a,b). Две буквы (a1, b1) на рис. 4.2.1-17 указывают, что для каждого проекта можно определить по крайней мере a1 и не более чем b1 экземпляров отношений типа Работать над. Это означает, что каждый проект может выполняться по крайней мере a1 и не более чем b1 сотрудниками. Две буквы (a2, b2) указывают, что один сотрудник может участвовать по крайней мере в a2 и не более чем в b2 проектах.



Рис. 4.2.1-17. Верхнее/нижнее ограничение (2)

Таким образом, каждое отношение выражается двумя степенями сложности (min - минимальной и max - максимальной). Нижним границам часто присваиваются значения 0 или 1. Диапазон значений верхней границы определяется как 1 max * (где * - универсальный знак).

Нижняя граница min = 0 указывает, что сущность может участвовать в одном отношении, но это необязательно. Нижняя граница min = 1 указывает, что сущность должна участвовать по крайней мере в одном отношении.

Нижние границы на рис. 4.2.1-18 указывают, что сотрудник может участвовать в проекте, но это необязательно (min = 0), в то время как проект должен выполняться по крайней мере одним сотрудником (min = 1). Этим здесь подчеркивается, что могут быть сотрудники, которые не участвуют ни в одном проекте. И наоборот, по крайней мере по одному сотруднику должно быть прикреплено к каждому проекту.



Рис. 4.2.1-18. Верхнее/нижнее ограничение (3)

Если разрешены минимальное значение 0 или 1 и максимальные значения 1 или *, то для пары (min,max) возможны следующие четыре сочетания: (1,1), (1,m), (0,1) и (0,m).

Приведенные ниже сокращения являются обычными для указанных сочетаний:

  • 1 (соответствует (1,1)),

  • c (соответствует (0,1)),

  • m (соответствует (1,m)),

  • cm (соответствует (0,m)), где c = choice (выбор) и m = multiple
    (многократный).

На рис. 4.2.1-19 представлен пример рис. 4.2.1-18 с использованием указанной нотации.



Рис. 4.2.1-19. Верхнее/нижнее ограничение (4)
^
4.2.1.2.3. Идентификация и существенная зависимость

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

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

Кроме того, существуют типы сущностей, которые в действительности обладают единственным ключевым атрибутом, но при этом зависят от существования других сущностей. Эти типы зависимостей могут появляться, например, при групповых операциях. Как показано на рис. 4.2.1-20, отдел имеет смысл только в том случае, если он содержит по крайней мере одно рабочее место. В свою очередь рабочее место только тогда имеет смысл, когда оно входит в отдел. Эти зависимости существования выражаются степенью сложности, или мощностью. В нотации (min,max) они определяются как (1,1) и (1,*).



Рис. 4.2.1-20. Зависимость существования

Определение зависимости существования в модели данных обеспечивает целостность основных данных, что является важным условием при реализации. Это означает, что выполнение этого условия гарантирует, что целостность содержимого базы данных обеспечивается даже после выполнения некоторых транзакций. В приведенном выше примере удалить отдел можно только в том случае, если будут удалены все рабочие места, входящие в данный отдел.
^
4.2.1.2.4. Моделирование технических терминов, используемых в компании. Модели технических терминов (Technical Term Models)

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

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

Для представления этих отношений вводится тип объекта технический термин. Теперь с каждым информационным объектом модели данных могут быть связаны разные технические термины (см. рис. 4.2.1-21).



Рис. 4.2.1-21. Технические термины

Технические термины могут быть взаимосвязаны и иерархически упорядочены.

Термины, определяемые моделью технических терминов, могут использоваться и в других диаграммах, которые содержат информационные объекты, например, в диаграммах процессов для представления входа/выхода данных для функции.
^
4.2.1.2.5. Диаграмма атрибутов eERM (eERM attribute allocation diagram)

Модели данных типа eERM (расширенные модели «сущность-отношение»), которые отображают только типы сущностей и типы отношений, очень часто имеют довольно сложную структуру. Диаграммы, включающие атрибуты сущностей и отношений, теряют свою наглядность.

С помощью диаграмм атрибутов eERM можно описать атрибуты для каждого типа сущности и отношения на отдельной диаграмме. В эту диаграмму можно включить тип объекта из диаграммы eERM (тип сущности или тип отношения) в виде копии экземпляра. Таким образом может быть смоделировано распределение атрибутов по объектам eERM. В этом контексте можно различать, является ли атрибут, связанный с объектом eERM, ключевым атрибутом, внешним ключом или описательным атрибутом. На рис. 4.2.1-22 приведен соответствующий пример.



Рис. 4.2.1-22. Атрибуты eERM для типа сущности

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

Определение

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

Группы типов атрибутов могут быть представлены так как показано на рис. 4.2.1.23.



Рис. 4.2.1-23. Группа типов атрибутов

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

4.2.1.3. Альтернативные формы представления

4.2.1.3.1. SAP — SERM

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

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

Метод моделирования, разработанный SAP AG, и информационная модель, базирующаяся на этом методе, связывает концепцию модели SERM с подходом eERM.

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

Иерархические отношения отображают односторонние существенные зависимости между информационными объектами.

Агрегатные отношения соответствуют образованию типов отношений, базирующихся на подходе eERM.

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

Специализация обозначается треугольником - по аналогии с моделью eERМ. Для того, чтобы передать идею метода моделирования, на рис. 4.2.1-24 приведен пример для модели eERМ вместе с обозначениями для модели SAP-ER. Это ясно показывает, что фундаментальное представление о предмете может быть передано из одной формы представления в другую без какой-либо потери информации.

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



Рис. 4.2.1-24. Представление моделей eERM и SAP-ERM
^
4.2.1.3.2. Модель данных IEF

Модель данных IEF соответствует обозначениям, принятым при моделировании данных с помощью инструментария CASE Information Engineering Facility(IEF) фирмы Texas Instruments Inc.

Так же как и нотация SAP-SERM, нотация IEF не поддерживает типы объектов при представлении отношений между типами сущностей.

На рис. 4.2.1-25 представлена модель данных в нотации IEF.



Рис. 4.2.1-25. Модель данных в нотации IEF
^
4.2.1.3.3. Модель SeDaM

Нотация семантической модели данных SeDaM (Semantic Data Model) – это нотация BASF AG. Она также не поддерживает типы объектов для представления отношений между типами сущностей. Типы сущностей последовательно не упорядочиваются слева направо (см. нотацию SAP-SERM). Типы объектов кластер данных и обобщенный тип также доступны.

На рис. 4.2.1-26 представлена модель данных в нотации SeDaM.



Рис. 4.2.1-26. Модель данных в нотации SeDaM

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

4.2.1.4. Резюме по наиболее важным концепциям и формам представления модели eERM


На рис. 4.2.1-27 суммированы концепции и формы представления, характерные для наиболее важных структурных элементов и операций при проектировании расширенной модели «сущность-отношение» (eERM).



Рис. 4.2.1-27. Концепции и формы представления в модели eERM
^

4.2.1.5. Моделирование потоков материалов. Диаграмма материалов


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

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

Определение

Тип материала – это совокупность материалов, имеютщих одинаковые характеристики.

Определение

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

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

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

Определение

Тип упаковочного материала - это совокупность отдельных упаковочных материалов, имеющих одинаковые характеристики.

Определение

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

На рис. 4.2.1-28 приведена диаграмма материалов, включающая иерархию уровней и классификацию.



Рис. 4.2.1-28. Диаграмма материалов
^

4.2.1.6. Модель данных стоимостей, вычисленных по методу АВС

4.2.1.6.1. Диаграмма стоимостных драйверов (СД)

Область применения диаграмм СД связана с определением стоимости по методу АВС – операционное исчисление стоимости (см. ARIS ABC). Диаграмма СД описывает иерархию стоимостных драйверов.

Определение

Стоимостной драйвер – это имеющий определенный смысл элемент некоторой измеренной/референсной величины, предназначенный для оценки стоимости отдельных операций (функций) в рамках бизнес-процесса. Референсная величина представляет собой значение, которое получено из доступных источников информации и находится в постоянной зависимости (пропорции) от стоимостных оценок.

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

Иерархия стоимостных драйверов представляется в диаграмме СД с помощью направленных соединительных линий, имеющих тип «Определяет объем». Атрибуты Числитель отношения СД и Знаменатель отношения СД должны сопровождать эту связь. Если не определен Знаменатель отношения СД, то его значение принимается за 1. Частное от деления указанных атрибутов определяет количество связей между обоими стоимостными драйверами для вычисления стоимостных характеристик процесса.

Диаграммы СД представлена на рис. 4.2.1-29. В приведенном примере имеются два стоимостных драйвера Количество автомобилей (лимузинов) и Количество дверей. Чтобы показать, что каждый лимузин имеет 4 двери, атрибут Числитель отношения СД должен установить значение 4 на линии, соединяющей стоимостной драйвер Количество автомобилей (лимузинов) со стоимостным драйвером Количество дверей.



Рис. 4.2.1-29. Диаграмма стоимостных драверов

Стоимостные драйверы связаны с конкретным процессом через управляющую модель. Множитель для каждой функции в рамках процесса определяется автоматически в соответствии с иерархией стоимостных драйверов.
^
4.2.1.6.2. Диаграмма стоимостных категорий

Область применения диаграммы стоимостных категорий – вычисление стоимости по методу АВС (см. ARIS ABC). Иерархия стоимостных категорий представляется с помощью диаграмм стоимостных категорий.

Определение

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

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

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

Иерархия стоимостных категорий представляется направленными линиями, имеющими тип является вышестоящим.

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

На рис. 4.2.1-30 для типа сущности, приведенного в качестве примера на
рис. 4.2.1.-1, показана диаграмма стоимостной категории производственных факторов с подструктурой, описывающей стоимость персонала.



Рис. 4.2.1-30. Диаграмма стоимостной категории

В ARIS ABC диаграмма стоимостной категории может быть связана с экземпляром вычислений стоимости по методу АВС. Модель стоимостных центров перечисляет все стоимостные центры, которые будут проанализированы в экземпляре вычислений стоимости по методу АВС. Некоторые стоимостные категории и необходимый набор значений могут определяться для каждого стоимостного центра (каждый - соответственно методу вычислений, тарифам, объемам и/или результатам стоимостных центров). Другие факты могут быть описаны для каждого стоимостного центра в таблице стоимостных категорий в рамках (с учетом) модели стоимостных центров.
^

4.2.1.7. Модель данных в управлении проектами

4.2.1.7.1. Диаграмма носителей информации

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

Модели ARIS могут быть описаны с помощью диаграмм PPC (цепочка процесса проекта, см. управленческую модель на уровне описания требований) в качестве «привязки» экземпляра «кластера», т. е. данные могут быть специфицированы в общем виде в «привязанном» кластере. Необходимые рабочие документы, например, файлы, подготовленные с помощью текстовых редакторов, могут быть представлены и активизированы (вызваны) с помощью ARIS Toolset через атрибуты Соединитель 1, Соединитель 2, Соединитель 3.



Рис. 4.2.1-31. Диаграмма носителей информации
1   2   3   4   5   6   7   8   9   10   ...   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
главная страница