Функциональная модель программы это

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

IDEF0 (Integration Definition for Function Modeling) – методология функционального моделирования для описания функций предприятия, предлагающая язык функционального моделирования для анализа, разработки, реинжиниринга и интеграции информационных систем бизнес процессов; или анализа инженерии разработки ПО (or software engineering analysis).[1]

Методология IDEF0 является развитием метода структурного анализа и проектирования SADT (Structured Analysis and Design Technique).

IDEF0 как стандарт был разработан в 1981 году в рамках программы ICAM (Integrated Computer Aided Manufacturing – интегрированная компьютерная поддержка производства).

IDEF0 – Integration DEFinition language 0 – основан на SADT и в своей исходной форме включает одновременно: определение языка графического моделирования (синтаксис и семантику) и описание полной (comprehensive) методологии разработки моделей. [pdf]

построение модели на основе idef3

Последняя редакция IDEF0 была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).

В 1993 году IDEF0 была принята в качестве федерального стандарта в США, а в 2000 году – в качестве стандарта в Российской Федерации.

IDEF0 используется для создания функциональной модели, то есть результатом применения методологии IDEF0 к системе есть функциональная модель IDEF0.

Функциональная модель – это структурное представление функций, деятельности или процессов в пределах моделируемой системы или предметной области.

Методология IDEF0 может быть использована для моделирования широкого спектра как автоматизированных, так и неавтоматизированных систем.

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

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

Цели стандарта IDEF0 [pdf]

Основные цели (objectives) стандарта:

1. задокументировать и разъяснить технику моделирования IDEF0 и правила ее использования;
2. обеспечить средства для полного и единообразного (consistently) моделирования функций системы или предметной области, а также данных и объектов, которые связывают эти функции;
3. обеспечить язык моделирования, который независим от CASE методов или средств, но может быть использован при помощи этих методов и средств;
4. обеспечить язык моделирования, который имеет следующие характеристики:

• общий (generic) – для анализа систем и предметных областей;
• строгий и точный (rigorous and precise) – для создания корректных, пригодных к использованию моделей);
• краткий (concise) – для облегчения понимания, коммуникации, согласия между заинтересованными лицами и проверки. (to facilitate understanding, communication, consensus and validation);
• абстрактный (conceptual) ­– для представления функциональных требований, независимых от физических или организационных реализаций;
• гибкий ­– для поддержки различных фаз жизненного цикла проекта.

Строгость и точность (Rigor and Precision) [IDEF.com (http://www.idef.com/IDEF0.htm)] Правила IDEFØ требуют достаточной строгости и точности для удовлетвроения нужд без чрезмерных ограничений аналитика (to satisfy needs without overly constraining the analyst). IDEFØ правила включают следующее:

• управление детализацией (control of the details communicated at each level) – от трех до шести функциональных блоков на каждом уровне декомпозиции;
• связанный контекст (Bounded Context) – не должно быть недостающийх или лишних, выходящих за установленные рамки деталей;
• связанность интерфейса диаграмм (Diagram Interface Connectivity) – номера узлов, функциональных блоков, C-numbers и Detail Reference Expression);
• связанность структуры данных. (Data Structure Connectivity) – ICOM codes and the use of parentheses;
• уникальные метки и заголовки (Unique Labels and Titles) – отсутствие повторяющихся названий;
• синтаксические правила для графики (Syntax Rules for Graphics) – функциональные блоки и стрелки;
• ограничения на разветвления стрелок данных (Data Arrow Branch Constraint) – метки для ограничений потоков данных на разветвлениях;
• разделение данных на Вход и Управление (Input versus Control Separation) – правило для определения роли данных);
• маркировка стрелок данных. Data Arrow Label Requirements (minimum labeling rules);
• наличие Управления (Minimum Control of Function) – все функции должны иметь минимум одно Управление;
• цель и точка зрения (Purpose and Viewpoint) – все модели имеют формулировку цели и точки зрения.

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

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

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги»). На диаграмме функциональный блок изображается прямоугольником (рис.). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:

• верхняя сторона имеет значение «Управление» (Control);
• левая сторона имеет значение «Вход» (Input);
• правая сторона имеет значение «Выход» (Output);
• нижняя сторона имеет значение «Механизм» (Mechanism).

Рис. Функциональный блок Интерфейсная дуга/стрелка (Arrow) отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, представленную данным функциональным блоком. Интерфейсные дуги часто называют потоками или стрелками. С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.). В зависимости от того, к какой из сторон функционального блока подходит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей». Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую. Это и понятно – каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла. Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram). Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели. Декомпозиция позволяет постепенно и структурированно представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой. Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0 – диаграмм, функциональных блоков, интерфейсных дуг – существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией. Моделирование. Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой. В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint). Определение и формализация цели разработки IDEF0-модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь. Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему.

Лекция 2: Функциональная модель, структурная модель и модель взаимодействия

Источник: studfile.net

Функциональная модель программного комплекса

Разработка функциональной модели программного комплекса сводится к разработке:

общего алгоритма работы;

Рассмотрим вышеперечисленные элементы более подробно.

1 Обобщенный алгортим работы программного комплекса.

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

процесс создания обучающего курса;

2 Диаграммы потоков данных.

В ходе изучения предметной области были выделены внешние сущности, процессы и потоки данных. Все они описаны в таблицах 1.3, 1.4, 1.5 соответственно.

Таблица 1.3 — Внешние сущности контекстной диаграммы

Сущность, составляющая обучающий материал.

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

Таблица 1.4 — Процессы контекстной диаграммы

Обучить с помощью электронной системы

Процесс, выполняющий обучение при помощи электронной системы.

Таблица 1.5- Потоки, представленные на контекстной диаграмме

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

Запрос на обучение

Поток, указывающий какую информацию показывать.

Материал, наполняющий курс обучения.

Информация о результатах обучения.

Сама контекстная диаграмма приведена на рисунке .1.4

Рисунок 1.4 -Контекстная DFD — диаграмма

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

Таблица 1.6 — Процессы детализирующей диаграммы

1.1 Создать курс обучения

Предусматривает ввод обучающего материала в соответствии с определенной структурой его хранения

1.2 Обеспечить обучение дисциплине

Предусматривает обучение дисциплине. Выдача необходимой информации на определенные запросы пользователя.

1.3 Обеспечить контроль обучения

Описание функциональной модели

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

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

Функциональные подсистемы ЭИС могут строиться по различным принципам:
— по предметному,
— по функциональному,
— по проблемному,
— смешанному (предметно-функциональному).

• Уровни Функциональные подсистемы управления Сбыт Производство Снабжение Финансы
• Стратегический уровень
• Новые продукты и услуги
• Исследования и разработки
• Производственные мощности
• Выбор технологий
• Материальные источники
• Товарный прогноз
• Финансовые источники
• Выписка счетов и накладных
• Обработка производственных заказов
• Складские операции
• Заказы на закупку
• Ведение бухгалтерских книг

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

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

Функциональная модель IDEF0.
Метод SADT (IDEF0) (Structured Analysis and Design Technique) считается классическим методом процессного подхода к управлению. Основной принцип процессного подхода заключается в структурировании деятельности организации в соответствии с ее бизнес-процессами, а не организационно-штатной структурой. Именно бизнес-процессы, формирующие значимый для потребителя результат, представляют ценность, и именно их улучшением предстоит в дальнейшем заниматься. Модель, основанная на организационно-штатной структуре, может продемонстрировать лишь хаос, царящий в организации (о котором в принципе руководству и так известно, иначе оно бы не инициировало соответствующие работы), на ее основе можно только внести предложения об изменении этой структуры. С другой стороны, модель, основанная на бизнес-процессах, содержит в себе и организационно-штатную структуру предприятия.

В соответствии с этим принципом бизнес-модель должна выглядеть следующим образом:

1. Верхний уровень модели должен отражать только контекст системы — взаимодействие моделируемого единственным контекстным процессом предприятия с внешним миром.
2. На втором уровне модели должны быть отражены основные виды деятельности (тематически сгруппированные бизнес-процессы) предприятия и их взаимосвязи. В случае большого их количества некоторые из них можно вынести на третий уровень модели. Но в любом случае под виды деятельности необходимо отводить не более двух уровней модели.
3. Дальнейшая детализация бизнес-процессов осуществляется посредством бизнес-функций — совокупностей операций, сгруппированных по определенным признакам. Бизнес-функции детализируются с помощью элементарных бизнес-операций.
4. Описание элементарной бизнес-операции осуществляется посредством задания алгоритма ее выполнения.

Метод SADT разработан Дугласом Россом (SoftTech, Inc.) в 1969 г. для моделирования искусственных систем средней сложности.
Данный метод успешно использовался в военных, промышленных и коммерческих организациях США для решения широкого круга задач, таких как долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, разработка ПО для оборонных систем, управление финансами и материально-техническим снабжением и др. Метод SADT поддерживается Министерством обороны США, которое было инициатором разработки семейства стандартов IDEF (Icam DEFinition), являющегося основной частью программы ICAM (интегрированная компьютеризация производства), проводимой по инициативе ВВС США. Метод SADT реализован в одном из стандартов этого семейства — IDEF0, который был утвержден в качестве федерального стандарта США в 1993 г., его подробные спецификации можно найти на сайте http://www.idef.com.

Существует также российская версия данного стандарта. Вместе со стандартом IDEF0 обычно используются стандарт моделирования процессов IDEF3 и стандарт моделирования данных IDEF1Х.
Метод SADT представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этого метода основываются на следующих концепциях:
• Графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих «ограничения», которые, в свою очередь, определяют когда и каким образом функции выполняются и управляются.
• Строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают: ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков — ограничение мощности краткосрочной памяти человека), связность диаграмм (номера блоков), уникальность меток и наименований (отсутствие повторяющихся имен), синтаксические правила для графики (блоков и дуг), разделение входов и управлений (правило определения роли данных).
• Отделение организации от функции, т.е. исключение влияния административной структуры организации на функциональную модель.
Метод SADT может использоваться для моделирования самых разнообразных процессов и систем. В существующих системах метод SADT может быть использован для анализа функций, выполняемых системой, и указания механизмов, посредством которых они осуществляются.

Состав функциональной модели
Результатом применения метода SADT является модель , которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы — главные компоненты модели, все функции организации и интерфейсы на них представлены как блоки и дуги соответственно. Место соединения дуги с блоком определяет тип интерфейса.

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

Рисунок 1. Функциональный блок и интерфейсные дуги

Одной из наиболее важных особенностей метода SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель.
На Рис. 2, где приведены четыре диаграммы и их взаимосвязи, показана структура SADT-модели. Каждый компонент модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует «внутреннее строение» блока на родительской диаграмме.

Рисунок 2. Структура SADT-модели. Декомпозиция диаграмм

Источник: resheniya.info