Размещено на http://www.allbest.ru/

1

Размещено на http://www.allbest.ru/

Государственный комитет Российской Федерации по рыболовству

Мурманский государственный технический университет

Специальности:

061100 «Менеджмент организации»

351401 «Прикладная информатика в экономике»

СТРУКТУРНЫЙ СИСТЕМНЫЙ АНАЛИЗ

Часть 1

ФУНКЦИОНАЛЬНОЕ МОДЕЛИРОВАНИЕ

по дисциплине

Структурный системный анализ

В. Качала

Мурманск 2000

УДК 681.51

ББК 32.81

К30

Качала В.В. Структурный системный анализ. Часть 1. Функциональное моделирование. - Мурманск, 2000. - 59 с. - (Мурманский государственный технический университет).

Учебное пособие написано в соответствии с программой дисциплины “Структурный системный анализ” для специальностей 351401 «Прикладная информатика в экономике» (071900 «Информационные системы в экономике») и 061100 "Менеджмент организации" («Менеджмент»). Рассмотрены принципы структурного анализа и вопросы создания функциональных моделей по методологии IDEF0.

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

This book has been designed in accordance with the academic plans for «Structured System Analysis» economy-oriented specialties. The principles of the structural analysis and problems of creation of functional models on the methodology IDEF0 are considered.

The manual is intended for the students of economic specialties. The teachers and experts in information systems and system analyzers also can use it.

Список лит. - 7 назв.

Рецензенты: кафедра информатики и ОТД МГПИ (зав.кафедрой доц., к.т.н. А. Ф. Шиян) и к.ф-м.н. Ю. Н. Куликов

© В.В.Качала, 2000

© МГТУ, 2000

СОДЕРЖАНИЕ

• Введение
• 1. Основы структурного системного анализа
• 1.1 Истоки структурного моделирования
• 1.2 Идеи и принципы ССА
• 1.2.1 Трудности ССА
• 1.2.2 Базовые принципы ССА
• 1.2.3 Другие принципы ССА
• 1.2.4 Классы моделей ССА
• 1.2.5 Инструментарий ССА
• 1.3 Методология SADT и стандарты IDEF
• 1.4 Основные средства ССА
• 2. Функциональное моделирование
• 2.1 Концепция IDEF0-моделей
• 2.1.1 Основные положения
• 2.1.2 Цель моделирования
• 2.1.3 Границы системы
• 2.1.4 Точка зрения модели
• 2.2 Синтаксис графических диаграмм
• 2.2.1 Функциональные блоки
• 2.2.2 Дуги
• 2.2.3 Взаимоотношения между дугами и блоками
• 2.2.4 Размещение блоков на диаграмме
• 2.2.5 Разветвление и слияние дуг
• 2.2.6 Связи между блоками
• 2.3 Основы IDEF0-моделирования
• 2.3.1 Контекстная диаграмма верхнего уровня
• 2.3.2 Узловые номера
• 2.3.3 ICOM-коды
• 2.3.4 Дуги, «помещенные в тоннель»
• 2.3.5 С-номер диаграммы
• 2.3.6 Правила построения диаграмм
• 2.3.7 Дополнительные диаграммы
• 2.4 Процесс создания IDEF0-модели
• 2.4.1 Сбор информации об исследуемом объекте
• 2.4.2 Построение IDEF0-модели
• 2.4.3 Итеративное рецензирование модели
• 2.4.4 Чтение диаграмм и моделей при рецензировании
• Литература



ВВЕДЕНИЕ

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

К любой искусственной системе, к которой относятся и предприятие и ИС, применимо понятие «жизненный цикл» (ЖЦ) - период времени от зарождения идеи новой системы, ее практического воплощения до физического или морального старения. ЖЦ состоит из следующих этапов: анализ, проектирование, реализация, внедрение и сопровождение. Анализ требований разрабатываемой системы является важнейшим среди всех этапов ЖЦ. Он оказывает существенное влияние на все последующие этапы, являясь в то же время наименее изученным процессом. На этом этапе, во-первых, необходимо понять, что предполагается сделать, а во-вторых, задокументировать это, так как, если требования не зафиксированы и не сделаны доступными для участников проекта, то они вроде бы и не существуют. При этом язык, на котором формулируются требования, должен быть достаточно прост и понятен заказчику. Требования обычно оформляются в виде спецификации - документа с перечислением условий, которым должна отвечать проектируемая система.

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

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

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

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

Главным подходом к исследованию сложных объектов считается системный анализ. Несмотря на большое количество работ по теории систем и системному анализу, обнаружилась странная особенность подобных работ: они существовали сами по себе, а многочисленные практические работы по системному анализу и управлению реальными объектами выполнялись сами по себе, без какой-либо связи с этими теоретическими изысканиями. Практической реализацией системного анализа стал структурный системный анализ (ССА). При этом слово «анализ» не надо понимать только буквально - говоря в дальнейшем о ССА, будем иметь в виду задачи анализа, описания и проектирования.

В менеджменте перед ССА ставится задача описать существующее положение вещей (объект управления) - построить так называемую модель «как есть» («AS-IS») и предложить новые решения по структуре управления или технологии выполнения бизнес-процессов - построить модель «как должно быть» («TO-BE»). При этом предприятие рассматривается как сложная бизнес-система, функционирующая на основе определенного множества бизнес-процессов. Задачей реорганизации является перевод предприятия в некоторое целевое состояние, характеризующееся, как правило, качественно более высоким уровнем организации работы за счет [3]:

повышения эффективности бизнес-процессов;

создания организационной структуры, направленной на поддержку выполнения бизнес-процессов;

создания информационной системы поддержки выполнения бизнес-процессов.

Совершенствование технологии работы сводится к всестороннему анализу функций управления на предмет [1]:

необходимости и достаточности функций управления;

исключения их дублирования и параллелизма;

определения узких мест и проблемных вопросов перераспределения функций управления;

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

определения затрат на выполнение конкретных функций;

анализа функций с точки зрения трудоемкости и сложности.

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

При создании ИС мы сталкиваемся с аналогичными задачами: построить модель «как есть» объекта автоматизации и спроектировать информационную систему - модель «как должно быть».

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

В ССА рассматриваются функциональные, информационные и динамические модели, а также модели функционально-стоимостного анализа (ABC-модели).

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



1. ОСНОВЫ СТРУКТУРНОГО СИСТЕМНОГО АНАЛИЗА

1.1 Истоки структурного моделирования

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

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

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

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

Современные методы структурно-функционального анализа и моделирования сложных систем были заложены благодаря трудам профессора Массачусетского технологического института Дугласа Росса, который впервые использовал понятие "структурный анализ" в конце 60-х годов, пытаясь создать алгоритмический язык АРТ, ориентированный на модульное программирование. Дальнейшее развитие идеи описания сложных объектов с помощью относительно небольшого набора типовых элементов привело к появлению методологии структурно-функционального моделирования и анализа сложных систем - SADT [4,5]. Со времени своего появления методология SADT постоянно совершенствовалась и широко использовалась для эффективного решения целого ряда проблем, таких как совершенствование управления финансами и материально-техническим снабжением крупных фирм, разработка программного обеспечения АСУ телефонными сетями, долгосрочное и стратегическое планирование деятельности фирм, проектирование вычислительных систем и сетей и др.

В дальнейшем появились и другие методологии структурного анализа и моделирования.



1.2 Идеи и принципы ССА

1.2.1 Трудности ССА

Главная задача ССА - так описать работу сложной системы, не теряя точности и полноты, чтобы описание было доступно как специалисту аналитику, проектировщику и программисту, так и заказчику, конечному пользователю системы. И в этом заключена наибольшая трудность. В частности, системный аналитик сталкивается с нижеследующими проблемами, которые взаимосвязаны (и это является одной из главных причин их трудноразрешимости) [2]:

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

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

аналитик сталкивается с чрезмерным количеством подробных сведений, как о предметной области, так и о новой системе;

спецификация системы из-за объема и технических терминов часто непонятна для заказчика;

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

1.2.2 Базовые принципы ССА

Для преодоления сложности описания систем в методах ССА используются следующие базовые принципы:

· расчленение их на части - «черные ящики»;

· иерархическая организация этих «черных ящиков»;

· использование графических средств.

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

каждый «черный ящик» должен реализовывать единственную функцию системы;

функция каждого «черного ящика» должна быть легко понимаема независимо от сложности ее реализации;

связь между «черными ящиками» должна вводится только при наличии связи между соответствующими функциями системы;

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

Второй важной идей, лежащей в основе структурных методов, является идея иерархии.

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

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

Третья идея ССА - широкое использование графических нотаций, что облегчает понимаемость сложных систем («одна картинка стоит тысячи слов»).

Размещено на http://www.allbest.ru/

1

Размещено на http://www.allbest.ru/

Рис. 1.1

В результате определим ССА следующим образом:

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

1.2.3 Другие принципы ССА

Все методологии ССА базируются на ряде общих принципов. Кроме описанных выше, используются следующие принципы [2]:

принцип формализации - необходимость строго методического подхода к решению проблемы;

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

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

принцип концептуальной общности - следование единой философии на всех этапах ЖЦ (структурный анализ - структурное проектирование - структурное тестирование);

принцип непротиворечивости - обоснованность и согласованность элементов;

принцип логической независимости - концентрация внимания на логическом проектировании для обеспечения независимости от физического проектирования;

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

1.2.4 Классы моделей ССА

В ССА рассматриваются следующие классы моделей:

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

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

ABC-модели, описывающие механизм формирования стоимости и других характеристик изделий и услуг на основе стоимости функций и ресурсов, задействованных в бизнес-процессах;

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

1.2.5 Инструментарий ССА

В качестве компьютерного инструмента ССА используются так называемые CASE-средства.

CASE-средства (Computer-Aided Software/Systems Engineering) - комплекс средств автоматизации для анализа, проектирования, разработки и сопровождения сложных систем.

В основе CASE лежат такие понятия как методология, метод, нотация и средство.

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

Метод - процедура или техника описания компонентов объекта исследования, программного обеспечения или ИС.

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

Средства - инструментарий для поддержки и усиления методов.

1.3 Методология SADT и стандарты IDEF

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

Автор методологии, Дуглас Росс, в 1969 г. часть своих теорий, относящихся к методологии и языку описания систем, назвал «Structured Analysis and Design Technique» (Методология структурного анализа и проектирования). Первое ее крупное приложение было реализовано в 1973 г. при разработке большого аэрокосмического проекта, а на рынке SADT появляется в 1975 г.

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

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

анализ функций, выполняемых системой;

описание спецификаций - требований и функций проектируемой системы;

проектирование системы.

Более 10 лет SADT была «бумажной» технологией, но в середине 80-х, когда на письменных столах появились персональные компьютеры с графическими возможностями, SADT «пересела» за компьютер. Одним из первых программных комплексов структурно-функционального анализа на основе SADT был пакет AUTOIDEF0, разработанный в рамках программы ВВС США по созданию интегрированной автоматизированной системы управления производством (ICAM - Integrated Computer Aided Manufacturing). В основе пакета лежит доведенное до уровня стандарта подмножество SADT - методология IDEF (IСАМ DEFinition), состоящая из трех методологий:

IDEF0 - функциональное моделирование;

IDEF1 - информационное моделирование;

IDEF2 - динамическое моделирование функций, информации и ресурсов.

Методология IDEF, основанная на принципах системного анализа и предназначенная для представления функций произвольной системы (будь то управление финансами, организация работ, обучение или автоматизация), фактически стала стандартом не только в США, но и в ряде европейских стран. Из трех названных методологий наибольшее распространение получила первая - IDEF0. В 1985 методология IDEF1 была расширена и переименована в IDEF1X. Что касается методологии IDEF2, то она не получила широкого распространения.

Всего же планировалось создать множество стандартов от IDEF0 до IDEF14. Однако не все она стали стандартами де-факто.

1.4 Основные средства ССА

Сегодня существует богатая палитра методологий и инструментальных средств ССА. Наиболее распространены следующие методологии:

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

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

IDEF1X - методология информационного моделирования, являющаяся составной частью SADT и основанная на концепции «сущность-связь».

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

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

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

DFD (Data Flow Diagrams) - диаграммы потоков данных - методология структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

ERD (Entity-Relationship Diagrams) - диаграммы «сущность-связь» (entity-relationship) - способ определения данных и отношений между ними, обеспечивающий детализацию хранилищ данных проектируемой системы, включая идентификацию объектов (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей).

STD (State Transition Diagrams) - диаграммы переходов состояний - методология моделирования последующего функционирования системы на основе ее предыдущего и текущего функционирования.

CPN (Color Petri Nets) - раскрашенные сети Петри - методология создания динамической модели бизнес-процесса, позволяющая проанализировать зависящие от времени характеристики выполнения процесса и распределение ресурсов для входящих потоков различной структуры.

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

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

моделирование диаграмма блок дуга



2. ФУНКЦИОНАЛЬНОЕ МОДЕЛИРОВАНИЕ

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

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

Наиболее подробно методология IDEF0 на русском языке излагается в книге [4], а стандарт IDEF0 на английском языке представлен в Internet [7].

2.1 Концепция IDEF0-моделей

2.1.1 Основные положения

Любая система состоит из взаимосвязанных частей (элементов системы), которые, работая совместно, выполняют некоторую функцию. В качестве элементов системы могут выступать: люди, информация, программное обеспечение, оборудование, продукты или сырье. IDEF0-модель описывает: что система делает, что она производит, как управляется, какие ресурсы и средства используются для исполнения ее функций.

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

графическое представление модели в виде иерархии диаграмм, обеспечивающее компактность представления информации;

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

строгость и точность представления;

пошаговые процедуры разработки модели, ее просмотра и объединения;

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

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

Можно назвать три основных типа диаграмм, используемых в IDEF0-моделях: графические, текстовые и глоссарии.

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

Текст и глоссарий обеспечивают дополнительную информацию для графических диаграмм. Кроме того, могут использоваться и так называемые поясняющие диаграммы - FEO (for exposition only - произносится fee-oh). При этом все диаграммы перекрестно ссылаются друг другу.

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

2.1.2 Цель моделирования

Создаваемая IDEF0-модель имеет конкретное назначение, называемое целью модели. Цель моделирования можно понять из следующего формального определения модели [4]:

M есть модель системы S, если M может быть использована для получения ответов на вопросы относительно S с точностью A.

Таким образом, целью модели является получение ответов на некоторую совокупность вопросов. Эти вопросы неявно присутствуют (подразумеваются) в процессе анализа и, следовательно, они руководят созданием модели и направляют его. Если модель отвечает не на все вопросы или ее ответы недостаточно точны, то мы говором, что модель не достигла своей цели.

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

Пример. Определение цели для модели работы деканата университета.

Вопросы:

Каковы обязанности декана?

Каковы обязанности заместителя декана?

Каковы обязанности инспектора?

По каким вопросам работники деканата общаются со студентами?

По каким вопросам работники деканата общаются с кафедрами?

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

Какая информация приходит в деканат и уходит из деканата?

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

2.1.3 Границы системы

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

2.1.4 Точка зрения модели

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

Пример. Определение точки зрения для модели деканата.

Претенденты:

Декан

Заместители декана

Инспектор

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

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



2.2 Синтаксис графических диаграмм

Компоненты синтаксиса IDEF0-диаграмм - функциональные блоки и дуги (стрелки), правила и диаграммы. Функциональные блоки представляют функции, определенные как действия, процессы или преобразования. Дуги представляют данные или объекты, связанные с функциями. Правила определяют, как компоненты используются, а диаграммы обеспечивают формат для словесного или графического изображения моделей.

2.2.1 Функциональные блоки

Размещено на http://www.allbest.ru/

1

Размещено на http://www.allbest.ru/

Рис. 2.1

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

Примеры названия блоков:

Подготовка задания на командировку

Согласование задания

Регистрация в канцелярии

Выплата денег на командировку

Следует придерживаться следующих синтаксических правил оформления блоков:

блоки должны быть выполнены сплошными линиями;

иметь прямоугольную форму, с квадратными углами;

быть достаточного размера, чтобы вставить название блока;

номер блока ставится внутри блока в нижнем правом углу.

2.2.2 Дуги

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

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

Линия дуги может быть прямой или изогнутой. Поскольку дуга часто изображает не один, а несколько данных/объектов, то она может иметь разветвление или соединение (рис. 2.2.).

Рис. 2.2 Примеры изображения дуг

Дуги должны соответствовать следующим синтаксическим правилам:

при изгибе дуга может быть изогнута только на 90є;

дуги изображаются сплошной линией;

дуги должны чертиться только горизонтально или вертикально (но не по диагонали);

дуги должны касаться внешней границы блока, но не должна входить в блок;

дуги должны присоединяться к сторонам блока, но не к углам.

2.2.3 Взаимоотношения между дугами и блоками

Между данными/объектами и функциями возможны четыре отношения: вход, управление, выход и механизм. Каждое из этих отношений изображается дугой, связанной с определенной стороной блока (рис. 2.3): левая сторона предназначена для выходных дуг (входов), правая - для выходных (выходов), верхняя сторона - для управленческих дуг и нижняя - для дуг механизмов.

Входные дуги изображают данные/объекты, используемые и преобразуемые функциями (документы, сырье, детали).

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

Размещено на http://www.allbest.ru/

1

Размещено на http://www.allbest.ru/

Рис. 2.3

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

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

Пример. Рассмотрим, как можно описать процесс издания приказа об увольнении (см. рис. 2.4). Приказ готовится на основании заявления увольняемого, но при этом опирается на статьи Кодекса законов о труде (КЗОТ), который в данном случае является управлением.

Размещено на http://www.allbest.ru/

1

Размещено на http://www.allbest.ru/

Рис. 2.4

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

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

Наименования (метки) дуг ставятся рядом со стрелкой. Если связь метки с соответствующей дугой не очевидна (для метки недостаточно места рядом с дугой), то для уточнения связи используют ломаную линию ().

Входные дуги на диаграмме IDEF0 выступают как ограничения. Соединение выхода одного блока с входом, управлением или механизмом других показывает, что моделируемая функция требует (и таким образом ограничивается) присутствия соответствующего выхода предыдущего блока. Таким образом, входные дуги данного блока представляют все данные/объекты, которые необходимы для выполнения его функции.

2.2.4 Размещение блоков на диаграмме

На диаграмме блоки выстраиваются по степени важности (так как ее понимает автор!). Этот относительный порядок называется доминированием. Доминирование понимается как влияние одного блока диаграммы на другие.

Размещено на http://www.allbest.ru/

1

Размещено на http://www.allbest.ru/

Рис. 2.5

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

Другим методом указания доминирования блоков является их нумерация: блок с меньшим номером будет иметь больше доминирование над блоком с большим номером.

2.2.5 Разветвление и слияние дуг

Дуга в IDEF0 редко изображает один объект или одни данные. Обычно она отражает их набор, поэтому дуги могут разветвляться и соединяться различными сложными способами. Вся дуга или часть ее может выходить из одного или нескольких блоков и заканчиваться в одном или нескольких блоках. Дуги на диаграммах верхнего уровня можно рассматривать как конвейеры или трубопроводы. Эти дуги имеют обобщающие метки, в то время как дуги на диаграммах низшего уровня имеют более конкретные метки (см. рис. 2.6).

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

непомеченные ветки содержат все данные/объекты, указанные в метке перед разветвлением;

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

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

Размещено на http://www.allbest.ru/

1

Размещено на http://www.allbest.ru/

Рис. 2.6

непомеченные ветки содержат все данные/объекты, указанные в общей метке после слияния;

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

2.2.6 Связи между блоками

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

управление;

вход;

обратная связь по управлению;

обратная связь по входу;

выход-механизм.

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

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

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

Размещено на http://www.allbest.ru/

1

Размещено на http://www.allbest.ru/

Рис. 2.7 Пример обратной связи по потоку данных

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

Размещено на http://www.allbest.ru/

1

Размещено на http://www.allbest.ru/

Рис. 2.8 Пример управленческой обратной связи

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

2.3 Основы IDEF0-моделирования

Для полного описания системы требуется набор IDEF0-диаграмм, которые образуют IDEF0-модель.

2.3.1 Контекстная диаграмма верхнего уровня

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

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

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

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

2.3.2 Узловые номера

Узловые номера используются для того, чтобы указать положение в иерархии модели любой диаграммы или блока. Например, диаграмма с узловым номером A21 является диаграммой, детализирующей блок 1 на диаграмме А2. Подобным же образом, А2 детализирует блок 2 на диаграмме А0, которая является самой полной диаграммой модели.

Все узловые номера графических диаграмм начинаются с буквы «A» (от Action - действие). Исходная для данной модели контекстная диаграмма имеет узловой номер А-0 (читается «А минус ноль»). Если создается более укрупненная контекстная диаграмма, в которую описываемая система входит в качестве подсистемы, то она нумеруется как A-1. Этот процесс может, если необходимо, продолжаться вверх по иерархии и дальше, однако А-0 (или А0) остается вершиной конкретной модели.

Размещено на http://www.allbest.ru/

1

Размещено на http://www.allbest.ru/

Рис. 2.9

Для дополнений к графическим диаграммам используются другие узловые номера. Номера для текстовых диаграмм содержат букву «Т» и соответствуют узловому номеру диаграммы, с которой они связаны (например, А2Т). Узловые номера для глоссария содержат букву «G» (например, A1G). Узловые номера диаграмм FEO содержат букву «F» (например, A2F). При этом, может быть несколько диаграмм FEO и словарей (например, A2F3, A2G2, …), но должно быть не более одной текстовой диаграммой, связанного с данной диаграммой.

Размещено на http://www.allbest.ru/

1

Размещено на http://www.allbest.ru/

Рис. 2.10

Узловые номера используются также для пометки на диаграмме декомпозированного блока. Если блок декомпозирован, то узловой номер диаграммы, которая представляет декомпозицию этого блока, пишется под блоком с правой стороны (рис. 2.10).

Диаграммы в модели обозначаются прибавлением наклонной черты и узлового номера к наименованию модели. Например, МОД/А3, где МОД - имя модели. Эта форма обозначения называется полным узловым номером диаграммы.

2.3.3 ICOM-коды

IDEF0 требует, чтобы все внешние дуги диаграммы были согласованы по числу и наименованию (но не обязательно по расположению) с дугами, касающимися декомпозированного блока родительской диаграммы. Для этих целей принята система обозначений, позволяющая точно идентифицировать и проверять связи по дугам между диаграммами. Это схема кодирования дуг - ICOM (от слов: Input, Control, Output, Mechanism).

Размещено на http://www.allbest.ru/

1

Размещено на http://www.allbest.ru/

Рис. 2.11

Код дуги состоит из буквы и цифры. Для входных дуг рекомендуется использовать букву I, для связей между дугами управления - C, для связей между выходными дугами - O, для связей между дугами механизма - M. После каждой буквы добавляется цифра, соответствующая положению данной дуги среди других дуг того же типа, касающихся родительского блока. Причем входные и выходные дуги пересчитываются сверху вниз, а дуги управления и механизмов - слева на право (рис. 2.11).

2.3.4 Дуги, «помещенные в тоннель»

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