6.Основные принципы нотации проектирования последовательности работ idef3. Смысловые примитивы. Связи. Декомпозиция. Перекрёстки. Нотация idef3 как средство моделирования потоков работ

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

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

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

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

• Единицы работы (Unit of Work)- основной компонент диаграммы IDEF3 близкий по смыслу к работе IDEF0.

• Связи (Links)- Связи, изображаемые стрелками, показывают взаимоотношения работ. В IDEF3 различают три типа связей:

  • Связь предшествования (Precedence)- показывает, что прежде чем начнется работа-приемник, должна завершиться работа-источник. Обозначается сплошной линией.

  • Связь отношения (Relational)- показывает связь между двумя работами или между работой и объектом ссылки. Обозначается пунктирной линией.

  • Поток объектов (Object Flow)- показывает участие некоторого объекта в двух или более работах, как, например, если объект производится в ходе выполнения одной работы и потребляется другой работой. Обозначается стрелкой с двумя наконечниками.

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

Типы перекрестков

Исключающий ИЛИ:
– запускается (завершается) только одна последующая (предшествующая) работа
И:
Асинхронный:
– запускаются (завершаются) все последующие (предшествующие) работы
Синхронный
– все последующие (предшествующие) работы запускаются (завершаются) одновременно
ИЛИ:
Асинхронный:
– запускаются (завершаются) одна или несколько последующих (предшествующих) работ
Синхронный
– одна или несколько последующих (предшествующих) работ запускаются (завершаются) одновременно

Примеры неправильных перекрестков

На одной диаграмме IDEF3 может быть создано несколько перекрестков различных типов. Определенные сочетания перекрестков для слияния и разветвления могут приводить к логическим несоответствиям. Чтобы избежать конфликтов, необходимо соблюдать следующие правила:

1. Каждому перекрестку для слияния должен предшествовать перекресток для разветвления.

2. Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа синхронного или асинхронного "ИЛИ". Действительно, после работы 1 может запускаться только одна работа - 2 или 3, а для запуска работы 4 требуется окончание обеих работ-2 и 3. Такой сценарий не может реализоваться.

Неверное размещение перекрестков. Перекресток для слияния "И" не может следовать за перекрестком для разветвления "ИЛИ"

3. Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа исключающего "ИЛИ".

Неверное размещение перекрестков. Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа исключающего "ИЛИ"

4. Перекресток для слияния типа исключающего "ИЛИ" не может следовать за перекрестком для разветвления типа "И" (рис. 1.4.14). Здесь после завершения работы 1 запускаются обе работы - 2 и 3, а для запуска работы 4 требуется, чтобы завершилась одна и только одна работа - или 2, или 3.

Неверное размещение перекрестков. Перекресток для слияния типа исключающего "ИЛИ" не может следовать

5. Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.

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

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

В IDEF3декомпозицияиспользуется длядетализацииработ.

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

7.Основные принципы нотации информационного проектирования IDEF1X. Логическая и физическая модели данных. Смысловые примитивы. Сущности. Атрибуты. Связи.

Нотация IDEF1X как средство построения модели данных

Для проектирования информационной модели бизнес-процессов используется методология IDEF1X Метод моделирования, который поддерживает графическое описание:

• логических конструкций данных, используя сущности, атрибуты и связи сущностей;

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

Документирование модели. Многие СУБД имеют ограничение на именование объектов (например, ограничение на длину имени таблицы или запрет использования специальных символов - пробела и т. п.). Зачастую разработчики ИС имеют дело с нелокализованными версиями СУБД. Это означает, что объекты базы данных могут называться короткими словами, только латинскими символами и без использования специальных символов (т. е. нельзя назвать таблицу предложением - только одним словом). Кроме того, проектировщики баз данных нередко злоупотребляют "техническими" наименованиями, в результате таблица и колонки получают наименования типа RTD_324 или CUST_A12 и т. д. Полученную в результате структуру могут понять только специалисты (а чаще всего только авторы модели), ее невозможно обсуждать с экспертами предметной области. Разделение модели на логический и физический уровни позволяет решить эту проблему. На физическом уровне объекты базы данных могут называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы - имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов. Например, таблице CUST_A12 может соответствовать сущность Постоянный клиент. Такое соответствие позволяет лучше задокументировать модель и дает возможность обсуждать структуру данных с экспертами предметной области.

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

Атрибут (поле) - составная часть сущности (свойство сущности), которая описывает отдельную, атомарную смысловую область сущности с определением для нее:

• самостоятельного имени , отличающегося от имен других атрибутов данной сущности;

• типа данных;

• назначения;

• условий использования.

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

Экземпляр атрибута (строки)- это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. Атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута. Атрибут может быть либо обязательным, либо необязательным. Обязательность означает, что атрибут не может принимать неопределенных значений (null values).

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

Связи отражают взаимоотношения между сущностями.

Существует несколько видов связи:

• идентифицирующая связь;

• неидентифицирующая связь;

• множественная связь;

• рекурсивная связь;

• категориальная связь

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

• Неидентифицирующая связь– проводится между двумя независимыми сущностями. При такой связи null-значения разрешены.