Метод IDEF0 (Icam DEFinition) применяют на ранних стадиях выполнения проекта при исследовании прикладной области, когда требуется выявить и понять сущность функционирования данной области. Затем, на основе моделей IDEF0, развивается дальнейшее моделирование системы методами IDEF3, DFD и др.

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

На рисунке 1 изображен основной бизнес-процесс рассматриваемой системы.

Рис. 1. Контекстная диаграмма «Трудоустройство»

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

Для дальнейшего понимания предметной области проведем декомпозицию главного процесса (рис. 2).

Рис. 2. Декомпозиция основного процесса «Трудоустройство»

Рис. 3. Декомпозиция процесса «Поиск вариантов кандидатур»

Рис. 4. Декомпозиция процесса «Анализ и прогнозирование состояния рынка труда»

Диаграмма DFD

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

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

В настоящее время для объектно-ориентированного моделирования проблемной области широко используется язык моделирования UML (Unified Modeling Language).

Система объектно-ориентированных моделей в соответствии с нотациями UML включает в себя следующие диаграммы:

1. диаграммы вариантов использования (Use Case Diagrams) - для моделирования бизнес - процессов организации (требований к системе);

2. диаграммы классов (Class Diagram)- для моделирования статической структуры классов системы и связи между ними;

3. диаграммы поведения:

3.1. диаграммы состояний (Statechart Diagrams) - для моделирования поведения объектов системы при переходе из одного состояния в другое;

3.2. диаграммы деятельности (Activity Diagrams) - для моделирования поведения системы в рамках различных вариантов использования (отображают потоки работ во взаимосвязанных прецедентах использования);

3.3. диаграммы взаимодействия (Interaction Diagrams) - для моделирования процесса обмена сообщениями между объектами. Существуют два вида диаграмм взаимодействия:

3.3.1. диаграммы последовательности (Sequence Diagrams) -последовательность сообщений;

3.3.2. кооперативные диаграммы (Collaboration Diagrams) - пространственное расположение объектов, чтобы показать их статическое взаимодействие;

4. диаграммы реализации (Implementation Diagrams):

4.1. диаграммы компонентов (Component Diagrams) - для моделирования иерархии компонентов (подсистем) системы (отображаются физические модули программного кода);

4.2. диаграммы размещения или развертывания (Deployment Diagrams) - для моделирования физической архитектуры системы (отображает распределение объектов по узлам вычислительной сети).

Диаграмма вариантов использования (UML Use Case)

На рис.8 показана диаграмма вариантов использования (Use Case).

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

- Регистрация заявок;

- Подбор подходящего варианта;

- Предложение вариантов кандидатур;

- Регистрация трудовых соглашений;

- Анализ и прогнозирование безработицы.

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

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

Границы системы обозначаются с помощью простого прямоугольника.

Рис.8. Диаграмма вариантов использования (Use Case).

Диаграмма классов (UML Static Structure)

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

Построение диаграмм классов можно рассматривать в различных аспектах:

· концептуальный аспект - диаграммы классов отображают понятия изучаемой предметной области (моделируемой организации). Концептуальную модель можно рассматривать как не зависимую от средств реализации (языка программирования);

· аспект спецификации - модель спускается на уровень ПО, но рассматриваются только интерфейсы, а не программная реализация классов (под интерфейсом здесь понимается набор операций класса, видимых извне);

· аспект реализации - модель действительно определяет реализацию классов ПО. Этот аспект наиболее важен для программистов.

При построении диаграммы необходимо выбрать единственный аспект. Так на рис.9 показана диаграмма классов процесса трудоустройства в концептуальном аспекте.

Рис.9. Диаграмма классов (Static Structure).

Класс (class) в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. Графически класс изображается в виде прямоугольника, который разделен на разделы или секции. В этих разделах могут указываться имя класса, атрибуты (переменные) и операции (методы).

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

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

· + обозначает атрибут с областью видимости типа общедоступный (public). Атрибут с этой областью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма.

· # обозначает атрибут с областью видимости типа защищенный (protected). Атрибут с этой областью видимости недоступен или невиден для всех классов, за исключением подклассов данного класса.

· - обозначает атрибут с областью видимости типа закрытый (private). Атрибут с этой областью видимости недоступен или невиден для всех классов без исключения.

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

Диаграмма взаимодействия (UML Sequence)

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

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

Диаграмма взаимодействия показана на рис.10. Здесь:

- объект Сотрудник отдела по подбору персонала является экземпляром актера Сотрудник отдела по подбору персонала диаграммы Use Case;

- объект Системы по трудоустройству является экземпляром класса Работодатель или Безработный (в зависимости от критерия поиска) диаграммы Static Structure.

Рис.10. Диаграмма взаимодействия (Sequence).

Диаграмма деятельности (UML Activity)

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

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

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

Конечное состояние представляет собой такое состояние, которое также не содержит никаких внутренних действий. В этом состоянии находится объект по умолчанию в конечный момент времени.

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

Если из состояния действий выходит единственный переход, то он может быть никак не помечен. Если же таких переходов несколько, то сработать может только один из них. Именно в этом случае для каждого из таких переходов должно быть записано сторожевое условие в прямых скобках. При этом для всех выходящих из некоторого состояния переходов должно выполняться требование истинности только одного из них. Подобный случай встречается тогда, когда последовательно выполняемая деятельность должна разделиться на альтернативные ветви в зависимости от значения некоторого промежуточного результата. Такая ситуация получила название ветвления, а для ее обозначения применяется специальный символ - ромб. Диаграмма деятельности показана на рис.11. На данной диаграмме описывается порядок деятельности при подборе персонала или вакансии.

Рис.11. Диаграмма деятельности (Activity).

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