Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Информационное обеспечение управляющих систем реального времени

..pdf
Скачиваний:
3
Добавлен:
15.11.2022
Размер:
3.63 Mб
Скачать

указать тип перекрестка. Все перекрестки нумеруются (префикс J и номер).

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

Различаются три стиля объекта ссылок: безусловные

(unconditional), синхронные (synchronous) и асинхронные (asynchronous).

Далее указывают типы перекрестков: asynchronous and (Fan-in Junction – все предшествующие процессы должны быть завершены / Fan-out Junction – все следующие процес-

сы должны быть запущены), synchronous and (Fan-in Junction – все предшествующие процессы должны быть завершены одновременно / Fan-out Junction – все следующие процессы запускаются одновременно), asynchronous or (Fan-in Junction – один или несколько предшествующих процессов должны быть завершены / Fan-out Junction – один или несколько предшествующих процессов должны быть запущены), synchronous or (Fan-in Junction – один или несколько предшествующих процессов должны быть завершены одновременно / Fan-out Junction – один или несколько предшествующих процессов запускаются одновременно), XOR (Fan-in Junction только один предшествующий процесс должен быть завершен / Fan-out Junction – только один следующий процесс запускается).

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

41

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

Рассмотрим процесс декомпозиции диаграмм IDEF3, включающий действие аналитика и экспертов предметной области. Перед проведением сеанса экспертизы у экспертов предметной области должны быть документированные сценарии и рамки модели, для того чтобы понять цели декомпозиции. Эксперт передает аналитику текстовое описание сценария и документацию, описывающую интересующие процессы. Аналитик должен из этих документов составить предварительный список работ (отглагольные существительные) и объектов (существительные – результат работы), которые необходимы для перечисленных работ.

Различают типы объекта ссылки: object (описывает участие важного объекта в работе), goto (циклический переход в повторяющейся последовательности работ), uob (unit of behavior множественное использование какой-либо работы, но без цикла), note (документирование какой-либо важной информации), elab (Elaboration – детальное описание).

На рис. 12 представлено описание процесса «Обслуживание клиента» в методологии IDEF3.

Рис. 12. Обслуживание клиента

42

IDEF3 поддерживает простую схему нумерации работ. Для разных аналитиков назначаются разные диапазоны работ [8]. Пример диапазонов приведен на рис. 13.

Рис. 13. Диапазоны номеров

IDEF3 поддерживает дополнения из диаграмм IDEF0 и DFD. Может быть создана смешанная модель, которая наилучшим образом описывает все стороны деятельности предприятия (рис. 14) [8].

Рис. 14. Смешанная модель [8]

1.3.Формализация бизнес-модели, разработка логической модели бизнес-процессов

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

мы «сущность – связь» (ER (Entity-Reationship) – CASE-

диаграммы). В результате разрабатывается информацион-

43

ное обеспечение АИС: схемы и структуры данных для всех уровней модульности АИС, документация по логической структуре АИС, сгенерированные скрипты для создания объектов БД.

1.3.1. Диаграммы «сущность – связь». Концептуальная схема предметной области

Модель «сущность – связь» (ER-модель) (англ. entityrelationship model, ERM) – модель данных, позволяющая описывать концептуальные схемы предметной области [6].

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

ER-диаграмма – классы сущностей (слабых и сильных) представлены прямоугольниками, а связи между ними – ромбами с указанием кардинальности (1:1,1:N,N:M). Сущность (entity) – это некоторый объект, идентифицируемый в рабочей среде пользователя. Атрибуты (свойства) – характеристики сущности. Взаимоотношения сущностей выра-

жаются связями (relationships).

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

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

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

44

виде «вилки» на конце связи. Модальность связи также изображается графически – необязательность связи помечается кружком на конце связи. Тип связи указывается индексами «1» или «М» надсоответствующейлинией (рис. 15).

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

Рис. 15. Последовательное формирование реляционных БД на основе ER-моделей

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

45

кретной постановкой задачи. Для графического представления сущностей используются специальные обозначения

(рис. 16).

Рис. 16. Графические изображения для обозначения сущностей

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

(рис. 17).

Рис. 17. Графические изображения для обозначения связей

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

Рассмотрим в качестве простого примера ситуацию, которая описывается двумя сущностями: «Сотрудник»

и«Компания». Рассматривается отношение принадлежности сотрудника данной компании. Если учесть соображения о том, что в компании работают несколько сотрудников,

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

46

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

Рис. 18. Диаграмма «сущность – связь» для примера сотрудников некоторой компании

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

Рис. 19. Диаграмма «сущность – связь» для примера сотрудников, участвующих в работе над проектами

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

47

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

1.3.2.Диаграмма сценариев использования. Контекстная диаграмма АИС

Диаграмма вариантов использования (Use case diagram, диаграмма прецедентов) – диаграмма, на которой отражены отношения, существующие между актерами и вариантами использования. Данный тип диаграмм используется при описании бизнес-процессов автоматизируемой предметной области, определении требований к будущей программной системе. Отражает объекты как системы, так и предметной области и задачи, ими выполняемые. Основная задача – дать возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы. Диаграмма вариантов использования является высокоуровневым представлением модели, поэтому она не должна содержать слишком много вариантов использования и актеров [24].

Актер (actor) – это множество логически связанных ролей, исполняемых при взаимодействии с прецедентами или сущностями (система, подсистема или класс). Актером может быть человек или другая система, подсистема или класс, которые представляют нечто вне сущности [6].

Прецедент (use case) – описание множества последовательных событий (включая варианты), выполняемых системой, которые приводят к наблюдаемому актером результату. Прецедент представляет поведение сущности, описывая взаимодействие между актерами и системой. Прецедент не показывает, «как» достигается некоторый результат, а только «что» именно выполняется.

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

48

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

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

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

Стрелка включения должна быть направлена от базового (составного) варианта к включаемому и помечена стереотипом include (англ. «включает») или uses (англ. «использует»).

В отличие от отношения включения, отношение расширения определяет потенциальную возможность включения поведения одного варианта использования в состав другого. Стрелка расширения должна быть направлена от включаемого варианта к базовому и помечена стереотипом extend (англ. «расширяет»).

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

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

49

данные элементы могут быть использованы в соответствующем контексте. Диаграммы важны для тестирования исполняемых систем в процессе прямого проектирования и для понимания их внутреннего устройства при обратном проектировании [24].

Диаграммы прецедентов обычно включают в себя: прецеденты, актеров, отношения зависимости, обобщения и ассоциации.

1.3.3. Диаграмма объектов. Логическая модель АИС

Диаграмма объектов (Object diagram) – демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаютсяэкземплярыклассов(объекты) системысуказаниемтекущих значений их атрибутов и связей между объектами. Объект (object) – экземпляр класса. Объект обозначается прямоугольником, но его имя подчеркивается. Для указания значений атрибутов объекта в его обозначении может быть предусмотрена специальнаясекция. Диаграммыобъектов(рис. 20) показывают множество объектов – экземпляров классов (изображенных на диаграмме классов) и отношений между ними в некоторый моментвремени(статическийвидИС).

Рис. 20. Диаграмма объектов

50