Лекции - Проектирование автоматизированных систем обработки и управления (АСОиУ)

Подождите немного. Документ загружается.

19 МЕТОДОЛОГИЯ IDEF3

Для описания логики взаимодействия информационных потоков

сущ ес твует ме тодоло г ия IDEF3, ис п оль зую ща я г р аф ич ес ко е оп и с ан и е

информационных потоков, взаимоотношений между процессами обработки

информации и объектов, являющихся частью этих процессов. Диаграммы

Workflow могут быть использованы в моделировании бизнес-процессов для

анализа завершенности процедур обработки информации. С их помощью

можно описывать сценарии действий сотрудников организации, например

по следовательность обработки заказа или события, которые необходимо

обработать за конечное время. Каждый сценарий сопровождается описанием

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

IDEF3 – это метод, описывающий ситуацию, когда процессы

выполняются в определенной последовательности, а также описать объекты,

участвующие совместно в одном процессе.

В отличие от других методик описаний процессов IDEF3 не ограничивает

аналитика чрезмерно жесткими рамками синтаксиса, что может привести к

созданию неполных или противоречивых моделей.

Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-процесса

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

цель и рамки модели, важно, чтобы работы именовались отглагольным

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

такое существительное.

Точка зрения на модель должна быть документирована. Обычно это точка

зрения человека, ответственного за работу в целом. Также не обходимо

документировать цель модели – те вопросы, на которые призвана ответить

модель.

Диаграмма является основной единицей описания в IDEF3. Важно

правильно построить диаграммы, поскольку они предназначены для чтения

другими людьми (а не только автором).

Единицы работы – Unit of Work (UOW) – также называемые работами

(activity), являются центральными компонентами модели. В IDEF3 работы

изображают ся прямоугольниками с прямыми углами и имеют имя, выраженное

отглагольным существительным и другое имя существительное, отображающее

основной выход работы (например, «Изготовление изделия»). Также имеет

идентификатор работы, который присваивается при создании и не меняется

никогда. Даже если работа будет удалена, ее идентификатор не будет вновь

использоваться для других работ.

Связи показывают взаимоотношения работ. Все св язи в IDEF3

однонаправлены и могут быть направлены куда угодно, но обычно диаграммы

IDEF3 стараются построить так, чтобы связи были направлены слева направо. В

IDEF3 различают три типа стрелок, изображающих связи:

• старшая – сплошная линия, связывающая единицы работ. Рисуется слева

направо или сверху вниз. Показывает, что работа-источник должна

закончиться прежде, чем работа-цель начнется;

• отношения – пунктирная линия, использующаяся для изображения связей

между единицами работ, а также между единицами работ и объектами

ссылок;

• потоки объектов – стрелка с двумя наконечниками, применяетс я для

описания того факта, что объект используется в двух или более единицах

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

другой;

Окончание одной работы может служить сигналом к началу нескольких

работ, или же одна работа для своего запуска может ожидать окончания

нескольких работ. Для отображения логики взаимодействия стрелок при

слиянии и разветвлении используются перекрестки. Различают перекрестки для

слияния и разветвления стрелок.

Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс

J. В IDEF3 стрелки могут сливаться и разветвляться только через перекрестки.

Объект ссылки в IDEF3 выражает некую идею, концепцию или данные,

которые нельзя связать со стрелкой, перекрестком или работой. Объекты

ссылки должны быть связаны с единицами работ или перекре стками

пунктирными линиями.

В I D E F 3 декомпозиция используется для детализации работ.

Методология IDEF3 позволяет декомпозировать работу многократно, т. е.

работа может иметь множество дочерних работ. Это позволяет в одной модели

описать альтернативные потоки. Возможность множественной декомпозиции

предъявляет дополнительные требования к нумерации работ. Так, номер работы

состоит из номера родительской работы, версии декомпозиции и собственного

номера работы на текущей диаграмме.

20 МЕТОДОЛОГИЯ РАЗРАБОТКИ ИНФОРМАЦИОННОЙ

БАЗЫ – IDEF1Х

Метод IDEF1, разработ анный Т. Рэмей, позволяет построить модель

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

основе совершенствования методологии IDEF1 создана ее новая версия –

методология IDEF1X. IDEF1X разработана с учетом таких требований, как

про стота изучения и возможно сть автоматизации. IDEF1X-диаграммы

используются рядом распространенных CASE-средств (в частности, ERwin,

Design/IDEF).

Сущность в методологии IDEF1X является независимой от

идентификаторов или просто независимой, если каждый экземпляр сущности

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

другими сущностями. Сущность называется зависимой от идентификаторов или

просто зависимой, если однозначная идентификация экземпляра сущности

зависит от его отношения к другой сущности.

Рисунок 23.1 – Сущности

Каждой сущно сти присваивается уникальное имя и номер, разделяемые

косой чертой «/» и помещаемые над блоком.

Связь может дополнительно определяться с помощью указания степени

или мощности (количества экземпляров сущности-потомка, которое может

существовать для каждого экземпляра сущности-родителя). В IDEF1X могут

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

• каждый экземпляр сущности-родителя может иметь ноль, один или более

связанных с ним экземпляров сущности-потомка;

• каждый экземпляр сущности-родителя должен имет ь не менее одного

связанного с ним экземпляра сущности-потомка;

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

связанного с ним экземпляра сущности-потомка;

• каждый экземпляр сущно сти-родителя связан с некоторым фиксированным

числом экземпляров сущности-потомка.

Если экземпляр сущности-потомка однозначно оп ределяется своей связью

с сущностью-родителем, то связь называется идентифицирующей, в противном

случае – неидентифицирующей.

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

сущностью-потомком с точкой на конце линии у сущности-потомка. Мощность

связи обозначается как показано на рисунке 23.2 (мощность по умолчанию – N).

Рисунок 23.2 – Мощность связи

Идентифицирующая связь между сущностью-родителем и сущностью-

потомком изображается сплошной линией (рисунок 2.32). Сущность-потомок в

идентифицирующей связи является зависимой от идентификатора сущностью.

Сущность-родитель в идентифицирующей связи может быть как независимой,

так и зависимой от и дентификатора сущностью (это определяется ее связями с

другими сущностями).

Пунктирная линия изображает неидентифицирующую связь. Сущность-

потомок в неидентифицирующей связи будет независимой от идентификатора,

если она не является также сущностью-потомком в какой-либо

идентифицирующей связи.

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

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

отделяются от других атрибутов горизонтальной чертой.

Сущности могут иметь также внешние ключи, которые могут

использоваться в качестве части или целого первичного ключа или неключевого

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

сущности имен атрибутов, после которых следуют буквы FK в скобках.

21 МЕТОДОЛОГИЯ UML: ДИАГРАММЫ ВАРИАНТОВ

ИСПОЛЬЗОВАНИЯ, КЛАССОВ, ПОСЛЕДОВАТЕЛЬНОСТИ

21.1 Диаграммы вариантов использования

Диаграмма вариантов использования – это исходное концептуальное

представление или концептуальная модель системы в процессе ее

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

имеет следующие цели:

• определить общие границы и контекст моделируемой предметной области на

нача ль ных этапах проектирования системы;

• сформулировать общие требования к функциональному поведению

проектируемой системы;

• разработать исходную концептуальную модель системы для ее последующей

детализации в форме логических и физических моделей;

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

системы с ее заказчиками и пользователями.

Назначение данной диаграммы состоит в следующем: проектируемая

программная система представляется в форме так называемых вариантов

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

Актером называется любой объект, субъект или система, взаимодействующая с

моделируемой бизнес-системой извне. Вариант использования служит для

описания сервисов, которые система предоставляет актеру. Другими словами

каждый вариант использования определяет набор действий, совершаемый

системой при диалоге с актером. При этом ничего н е говорится о том, каким

образом будет реализовано взаимодействие актеров с системой и собственно

выполнение вариантов использования.

В самом общем случае, диаграмма вариантов использования представляет

собой граф специального вида, который является графической нотацией для

представления конкретных вариантов использования, актеров и отношений

между этими элементами. При этом отдельные элементы диаграммы заключают

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

в ремя отношения, кот орые могут быть изображен ы н а данном графе,

представляют собой только фиксированные типы взаимосвязей между актерами

и вариантами использования, которые в совокупности описывают сервисы или

функциональные требования к моделируемой системе.

Базовыми элементами диаграммы вариантов использования являют ся

вариант использования и актер.

Вариант использования – внешняя спецификация последовательности

действий, которые система или другая сущность могут выполнять в процессе

взаимодействия с актерами.

Содержание варианта использования может быть представлено в форме

дополнительного пояснительного текста, который раскрывает смысл или

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

пояснительный текст получил название текста-сценария или просто сценария.

Отдельный вариант использования обозначается на диаграмме эллипсом,

внутри которого содержится его краткое имя в форме существительного

(рисунок 24.1, а) или глагола (рисунок 24.1, б) с пояснительными словами. Сам

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

Имя (name) – строка текста, которая используется для идентификации

любого элемента модели.

Рисунок 24.1 – Графическое обозначение варианта использования

Актер – согласованное множество ролей, которые играют внешние

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

ними. Стандартным г рафическим обозначением актера на диаграммах являет ся

фигурка «человечка», под которой записывается имя актера (рисунок 24.2).

Рисунок 24.2 – Графическое обозначение актера

Имена актеров должны н ачинаться с заглавной буквы и следовать

рекомендациям использования имен для типов и классов модели. При этом

символ отдельного актера связывает соответствующее описание актера с

конкретным именем.

Поскольку в общем случае актер всегда находится вне системы, его

внутренняя структура никак не определяется. Для актера имеет значение только

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

Актеры взаимодействуют с системой по средством передачи и приема

сообщений от вариантов использования. Сообщение представляет собой запрос

актером сервиса от системы и получение этого сервиса. Это взаимодействие

может быть выражено посредством ассоциаций между отдельными актерами и

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

интерфейсы, которые определяют, каким образом другие элементы модели

взаимодействуют с этими актерами.

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

модели.

Между элементами диаграммы вариантов использования могут

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

экземпляров одних актеров и вариантов использования с экземплярами других

актеров и вариантов. Один актер может взаимодействовать с несколькими

вариантами использования. В этом случае этот актер обращается к нескольким

сервисам данной системы. В свою очередь один вариант использования может

взаимодействовать с несколькими актерами, предоставляя для всех них свой

сервис.

В языке UML имеется несколько стандартных видов отношений между

актерами и вариантами использования:

• ассоциации;

• включения;

• расширения;

• обобщения.

При этом общие свойства вариантов использования могут быть

представлены тремя различными способами, а именно – с помощью отношений

включения, расширения и обобщения.

Отношение ассоциации служит для обозначения специфической роли

актера при его взаимодействии с отдельным вариантом использования. На

диаграмме вариантов использования, так же как и на других диаграммах,

отношение ассоциации обозначается сплошной линией между актером и

вариантом использования (рисунок 24.3).

Рисунок 24.3 – Отношение ассоциации между актером и вариантом использования

Включение – это разновидность отношения зависимости между базовым

вариантом использования и его специальным случаем. При этом отношением

зависимости является такое отношение между двумя элементами модели, при

котором изменение одного элемента (независимого) приводит к изменению

другого элемента (зависимого).

Отношение включения устанавливается только между двумя вариантами

использования и указывает на то, что заданное поведение для одного варианта

использования включается в качестве составного фрагмента в последователь-

ность поведения другого варианта использования.

Графически данное отношение обозначается как отношение зависимости

в форме пунктирной линии со стрелкой, направленной от базового варианта

использования к включаемому варианту использования. При этом данная линия

помечается стереотипом <<include>> (рисунок 24.4).

Рисунок 24.4 – Отношение включения между вариантами использования

Семантика этого отношения определяется следующим образом. Процесс

выполнения базового варианта использования включает в себя как собственное

подмножество последовательность действий, которая определена для