12. Функциональное моделирование. Области применения. Методология IDEF0. Предназначение. Графические обозначения. Процесс разработки модели в стандарте IDEF0.

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

Изначально IDEF0 использовалась для проектирования и разработки ИС. Сейчас широко используется при проектировании ИС и описании бизнес-процессов предприятия.

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

В основе методологии IDEF0 лежат четыре основных понятия (принципа)

Функциональный блок (Activity Box).

Интерфейсная дуга (Arrow).

Декомпозиция (Decomposition).

Глоссарий (Glossary) - описание сущности элемента модели IDEF0.

Процесс разработки модели в стандарте IDEF0.

1 Контекстная диаграмма А-0 При построении модели IDEF0 необходимо определить назначение модели — набор вопросов, на которые должна отвечать модель.

2 Декомпозиция и выделение подпроцессов

13 Функциональное моделирование. Области применения. Методология EPC Предназначение. Графические обозначения. Процесс разработки модели.

Нотация EPC (Event-Driven Process Chain – событийная цепочка процессов) используется для описания процессов нижнего уровня.

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

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

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

Графические обозначения

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

Блок «Функция» – действие или набор действий, выполняемых над исходным объектом (документом, ТМЦ и прочим) с целью получения заданного результата.

Стрелка отображает связи элементов диаграммы процесса EPC между собой.

Субъект (Организационная единица) — используется для отображения на диаграмме организационных единиц (должности, подразделения, роли, внешнего субъекта) – исполнителей, владельцев или участников функций.

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

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

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

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

Если оператор обладает входящей связью от элемента «событие», то он должен обладать исходящей связью к элементу «функция» и наоборот

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

14 Объектно-ориентированное моделирование. Назначение и способы использования языка uml. Представления архитектуры ис с точки зрения uml.

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

UML (Unified Modeling Language, унифицированный язык моделирования) – это язык для визуализации, специфицирования, конструирования (проектирования) и документирования артефактов программных систем.

Артефакт (artifact) — физический элемент информации, который используется или порождается в процессе разработки программного обеспечения.

Что моделируется ?

Предметная область - любая специфическая область человеческой деятельности

Система - то, что с чем мы работаем (проектируем, описываем, ...)

Модуль - логически связанное множество элементов и/или модулей (часть системы) = компонент (ООП)

Элемент - элементарная (на данном уровне детализации) часть системы = класс (ООП)

UML (Unified Modeling Language, унифицированный язык моделирования) – это язык для

визуализации,

специфицирования,

конструирования (проектирования) ,

документирования

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

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

Словарь UML включает три вида строительных блоков:

1. Сущности (things)

2. Связи (relationships)

3. Диаграммы (diagrams)

Сущности (things) – это абстракции, которые являются основными элементами модели, связи (relationships) соединяют их между собой, а диаграммы (diagrams) группируют представляющие интерес наборы сущностей

Визуализация, специфицирование, конструирование и документирование программных систем требуют их представления с различных точек зрения.

Представление вариантов использования (Use Case View) системы охватывает варианты использования, описывающие поведение системы с точки зрения конечных пользователей, аналитиков и тестировщиков.

Представление системы с точки зрения проектирования (дизайна, design view) охватывает классы, интерфейсы и кооперации, формирующие словарь проблемы и ее решение.

Представление взаимодействия (вид с т.з. процессов, Process View ) системы показывает поток управления, проходящий через разные ее части, включая возможные механизмы параллелизма и синхронизации.

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

Представление развертывания (deployment view) отражает топологию связей аппаратных средств и размещения на них компонентов. Это представление в основном связано с поставкой, распределением и установкой частей, составляющих физическую систему.

15 Проектирование структуры ис с помощью uml. Виды и примеры диаграмм.

Основные типы UML-диаграмм, используемые в проектировании информационных систем. Взаимосвязи между диаграммами. Поддержка UML итеративного процесса проектирования ИС. Этапы проектирования ИС: моделирование бизнес-прецедентов, разработка модели бизнес-объектов, разработка концептуальной модели данных, разработка требований к системе, анализ требований и предварительное проектирование системы, разработка моделей базы данных и приложений, проектирование физической реализации системы.

UML обеспечивает поддержку всех этапов жизненного цикла ИС и предоставляет для этих целей ряд графических средств - диаграмм.

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

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

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

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

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

Диаграммы видов деятельности (диаграммы деятельностей, activity diagrams) - модель бизнес-процесса или поведения системы в рамках прецедента.

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

Диаграммы состояний (statechart diagrams) - модель динамического поведения системы и ее компонентов при переходе из одного состояния в другое.

Диаграммы классов (class diagrams) - логическая модель базовой структуры системы, отражает статическую структуру системы и связи между ее элементами.

Диаграммы базы данных (database diagrams) - модель структуры базы данных, отображает таблицы, столбцы, ограничения и т.п.

Диаграммы компонентов (component diagrams) - модель иерархии подсистем, отражает физическое размещение баз данных, приложений и интерфейсов ИС.

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

На рис. 12.1 показаны отношения между различными видами диаграмм UML. Указатели стрелок можно интерпретировать как отношение «является источником входных данных для...» (например, диаграмма прецедентов является источником данных для диаграмм видов деятельности и последовательности). Приведенная схема является наглядной иллюстрацией итеративного характера разработки моделей с использованием UML.