Методика IDEF1X

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

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

Сущность определяют как множество объектов, обладающих общими свойствами. Конкретные элементы этого множества называют экземплярами сущности. Если сущность A может быть определена только с помощью ссылки на свойства некоторой другой сущности B, то A называют зависимой (дочерней) сущностью, а B выступает в роли родительской сущности. Сущности в IDEF1X-диаграммах изображают в виде прямоугольников, причем рекомендуется у зависимых сущностей углы прямоугольников изображать скругленными.

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

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

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

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

Свойства сущностей, отображаемые в ИМ, называют атрибутами.

Различают ключевые и неключевые атрибуты. Значение ключевого атрибута (ключа) однозначно идентифицирует экземпляр сущности. Ключевые атрибуты могут быть составными. Например, чтобы однозначно определить "учебное занятие" нужно указать индекс учебной группы (потока) и название дисциплины, т.е. эти два атрибута вместе являются составным ключом. Неключевыми атрибутами сущности "учебное занятие" в нашем примере могут быть время проведения занятия, аудитория, фамилия преподавателя.

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

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

Основные элементы графического языка IDEF1X представлены на рис. 1.

Рис. 1. Элементы языка IDEF1X

В качестве примера рассмотрим формирование ИМ приложения "Научно-исследовательская деятельность вуза".

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

Поэтому в первоначальный вариант ИМ были введены сущности "НТП" — научно-техническая программа, "ГРНТИ" — Государственный реестр научно-технической информации, "НИР" — научно-исследовательская работа, "Специалист", "Кал. план" — календарный план, "Этап", "Факультет (НИИ)", "Кафедра (Отдел)". Затем были определены связи. Отношение между сущностями "НИР" и "Специалист" оказалось неспецифическим, оно было сведено к специфическому введением сущности-посредника "Исполнитель". В атрибуты сущностей-потомков вошли ключевые атрибуты сущностей-родителей. После составления списков атрибутов получилась IDEF1X-диаграмма, представленная на рис. 2, на которой внешние ключи выделены курсивом.

После рецензирования первоначальный вариант ИМ был расширен, в него дополнительно введены такие сущности, как "Диссертация", "Диссертационный совет", "Специальность ВАК", "Аспирант", "Научно-техническая комиссия", "Партнеры" (в том числе зарубежные) и т.п. с соответствующими связями и атрибутами.

Рис. 2. IDEF1X-диаграмма приложения "Научно-исследовательская деятельность вуза"

UML

Идеи системного подхода и их реализация в объектно-ориентированной методологии являются естественной базой современного проектирования и управления сложными системами. Такие понятия как сложная система, структура, состояние, иерархия, событие, пришедшие из системотехники, дополненные понятиями класса, объекта, атрибута, инкапсуляции, отношений обобщения, агрегации и др. стали основой парадигмы объектно-ориентированного проектирования (ООП), широко используемого в современных автоматизированных системах. Идеи ООП воплощены в основных языках, составляющих лингвистическое обеспечение CALS, таких как Express, или UML.

Среди языков, используемых в системах CASE на стадии концептуального проектирования сложных систем, господствующее положение в последнее время занял язык Unified Modeling Language (UML). Он был разработан по инициативе компании Rational Software, основные разработчики Гради Буч (Grady Booch), Ивар Якобсон (Ivar Jacobson) и Джим Рамбо (Jim Rumbaugh). Язык UML поддерживается и развивается консорциумом OMG (Object Management Group), первую версию языка (UML 1.0) OMG выпустила в 1997 г.

Язык UML предназначен для описания, визуализации и документирования объектно-ориентированных систем в процессе их разработки, в первую очередь, программного обеспечения систем.

Разработка модели приложения с помощью языка UML начинается с построения диаграмм использования (use case diagram). Эти диаграммы характеризуют функциональность создаваемой системы с позиций пользователя и служат для отображения взаимодействия пользователей с проектируемой системой. В диаграммах в виде овалов представлены варианты использования, т.е. те функции, которые должна выполнять система (рис. 1). Пользователи изображаются в виде стилизованных фигурок, ими могут быть не только люди, но и любые внешние образования, пользующиеся услугами проектируемой системы. Благодаря диаграммам использования, определяется и согласовывается внешняя функциональность системы и в итоге формируется техническое задание на разработку этой системы

Рис. 1. Фрагмент диаграммы использования

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

Для изображения классов ООП используют прямоугольники, которые разделяются на секции. В верхней секции записывают имя класса, в средней секции — атрибуты класса и в нижней секции — процедуры класса, как это сделано в примере на рис. 2. Знаки +, - или # ставится перед именем атрибута или метода, если элемент имеет статус соответственно public, private или protected.

Рис. 2. Пример изображения класса

Классы и их отношения составляют сущность диаграмм классов (class diagram). Связи (ассоциации) в этих диаграммах показывают линиями между связанными классами, причем у концов линии можно указать характер отношения ("один — к одному", "один — ко многим" и т.п.). Отношения зависимости (влияния одного класса на другой, зависимость можно обнаружить по изменению описания подчиненного элемента, если изменяется описание влияющего элемента) изображают стрелкой с пунктирной линией, направленной к зависимому элементу. Если отношением связаны равноправные элементы, то такая ассоциация изображается сплошной линией, если отношением связано более двух классов, то в диаграмму добавляется ромбовидная связка, как показано на рис. 3,а.

Рис. 3. Отношения тернарной ассоциации (а), агрегирования и наследования (б) в диаграммах классов

Частные случаи ассоциаций — обобщение и агрегирование. Отношение обобщения (наследования) изображают сплошной линией, заканчивающейся незакрашенной стрелкой около родительского элемента. Отношение агрегирования (отношение "часть — целое") показывают такой же линией, но с ромбовидной стрелкой, заканчивающейся у элемента "целое". Ромбовидная стрелка закрашивается, если части не могут существовать без целого, т.е. если при ликвидации класса "целое" ликвидируются и все его "части". Отметим, что в этом случае отношение агрегирования иногда называют отношением композиции.

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

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

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

В диаграммах последовательностей (sequence diagram), называемых также диаграммами сценариев, отражается последовательность событий, заключающихся в воздействиях одного объекта на некоторый другой объект. В этих диаграммах объекты изображаются прямоугольниками и располагаются каждый в своей вертикальной колонке диаграммы. Ось времени направлена вертикально вниз. От каждого объекта параллельно оси времени идут так называемые их линии жизни. Каждое событие изображается горизонтальной линией со стрелкой от линии жизни объекта, посылающего сообщение, к линии жизни объекта, принимающего сообщение. Над этими линиями возможен поясняющий текст. Линии располагаются одна над другой в порядке, в котором события совершаются. Пример диаграммы сценариев дан на рис. 4, где прямоугольники объектов расположены в верхней части своих колонок.

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

Рис. 4. Вид диаграммы сценариев

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

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

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

Диаграммы деятельности (activity diagram) близки по своей семантике к диаграммам состояний. Отличаются они тем, что каждой вершине графа соответствует некоторое элементарное действие и переход в новое состояние происходит по завершении этого действия. Вершины изображаются прямоугольниками с округлыми боковыми сторонами, переходы — линиями с обычными стрелками, переходы из нескольких вершин в одну последующую (переходы типа слияния — join) или из одной вершины в несколько последующих (переходы типа разделения — fork) — утолщенными короткими линиями так же, как изображаются переходы в сетях Петри. Переход по условию в одну из альтернативных вершин изображается с помощью ромба, из которого выходят дуги переходов к альтернативным вершинам.

В UML используются также диаграммы компонентов (Component Diagram). и развертывания (Deployment Diagram), используемые для моделирования физической организации системы. Например, к компонентам программной системы могут относиться программные модули, библиотеки, файлы. В диаграммах развертывания показывают распределение классов по аппаратным средствам.

Примером программной системы, поддерживающей язык UML, является система Rational Rose компании Rational Software.