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

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

К наиболее распространенным, простым в использовании и поддерживаемым программными средствами методологиям относятся:

¦ SADT — интересна как основополагающая методология, заложившая принципы современного моделирования и послужившая основой для разработки стандарта IDEF0;

¦ IDEF0 — методология и стандарт функционального моделирования. С помощью графического языка IDEF0 изучаемая система предстает в виде набора взаимосвязанных функциональных блоков. Моделирование средствами IDEF0, как правило, является первым этапом изучения системы;

¦ IDEF3 — с помощью IDEF3 описывается логика выполнения действий. IDEF3 может использоваться самостоятельно и совместно с методологией IDEF0: любой функциональный блок IDEF0 может быть представлен в виде последовательности процессов или операций средствами IDEF3. Если IDEF0 описывает что делается в системе, то IDEF3 описывает как это делается.

Методология SADT, разработанная Дугласом Россом, является одной из самых известных и широко используемых систем моделирования. SADT (Structured Analysis and Design Technique — технология структурного анализа и проектирования) -это графические обозначения и метод описания процессов. SADT может применяться на всех стадиях жизненного цикла системы. Признание полезности SADT привело к стандартизации и публикации ее части, предназначенной для функционального моделирования, как методологии и стандарта функционального моделирования IDEFO.

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

С точки зрения SADT модель может быть сосредоточена либо на функциях системы, либо на ее объектах. SADT-модели, ориентированные на функции, принято называть функциональными моделями, а ориентированные на объекты системы — моделями данных. Функциональная модель представляет с требуемой степенью детализации систему функций, которые отражают свои взаимоотношения через объекты системы. Здесь рассматриваются только функциональные модели SADT.

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

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

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

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

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

Рис. 20.3. Цель и точка зрения модели Очень часто только с позиции одной точки зрения можно получить описание, удовлетворяющее цели моделирования. Например, создание согласованной модели производства продукции можно осуществлять как с точки зрения мастера, так и с точки зрения оператора или контролера, но ни одна из них не даст модели, которая позволила бы написать должностные инструкции для всего персонала. Только с позиции начальника цеха можно увидеть все виды работ, выполняемых в цехе при производстве продукции. Именно с его точки зрения можно проследить взаимосвязи обязанностей различных работников. Точка зрения начальника цеха позволяет создателю модели определить роль каждого работника в изготовлении отдельных деталей и описать обязанности персонала.

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

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

Рисунки 20.3 и 20.4 иллюстрируют функциональное моделирование в нотации IDEF0 и его поддержку программными средствами BPWin. IDEFO-модели состоят из трех типов документов: графических диаграмм, текста и глоссария. Эти документы имеют перекрестные ссылки друг на друга. Графическая диаграмма — главный компонент IDEFO-модели, содержащий блоки, стрелки, соединения блоков и стрелок и ассоциированные с ними отношения. Блоки представляют собой основные функции моделируемого объекта. Основные объекты нотации IDEF0: работы (Activity), отображают функции; стрелки (Arrows). Стрелка входа (Input) отображает входящие документы, материальные и информационные ресурсы, необходимые для выполнения работы. Работа может не иметь ни одной стрелки входа. Стрелка выхода (Output) отображает исходящие документы, материальные и информационные ресурсы, являющиеся результатом выполнения работы. Стрелка управления (Control) отображает правила, ограничения и другие управляющие воздействия. В нотации каждая работа должна иметь не менее одной стрелки управления. Стрелка механизма (Mechanism) отображает те ресурсы, которые необходимы для выполнения работы, но которые не подвергаются изменению. Стрелка

Рис. 20.4. Декомпозиция и представление функций.

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

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

Для описания процесса в IDEF3 определены две стратегии и соответственно два типа диаграмм:

• 1) process-centered strategy — стратегия описания процесса как последовательности выполняемых действий. Диаграммы этого типа получили название Process Flow Description Diagrams (PFDD) -диаграммы потокового описания процесса;
• 2) object-centered strategy — стратегия описания процесса как последовательности изменений состояний объекта, над которым выполняются действия. Диаграммы такого типа получили название Object State Transition Network (OSTN) — диаграммы последовательности изменений состояний объекта.

Описание процесса в IDEF3 может содержать диаграммы PFDD и OSTN или диаграммы какого-либо одного типа.

Для диаграмм PFDD в IDEF3 используется понятие сценария в качестве базовой структурной единицы описания процесса. Описание процесса может состоять из одного или нескольких сценариев. Сценарий определяется как повторяющаяся ситуация, некий набор ситуаций, описывающих типичный класс проблем в системе или организации, обстановка или среда, в которой происходит рассматриваемый процесс. Основным назначением сценария является определение контекста описания через присвоение сценарию имени. Именем сценария может быть глагол с поясняющими словами («Оформить заказ на товары», «Проверить пригодность товара») или название совокупности характерных действий («Выполнение последовательности проверок»). Таким образом, сценарий устанавливает ориентацию и границы описания.

Предметная область диаграммы потоков данных (Data Flow Diagramm — DFD) в нотации Йордона — Де Марко строится из элементов (табл. 20.2).

Таблица 20.2. Типы обозначений элементов DFD-диаграммы.

Помимо нотации Йордона -Де Марко для элементов DFD-диаграмм могут использоваться и другие условные обозначения (ОМТ, SSADM, нотация Гейна — Сарсона и т. д.). Все они обладают практически одинаковой функциональностью и различаются лишь в деталях. Инструментальные средства проектирования (CASE-системы), как правило, поддерживают несколько нотаций представления DFD-диаграмм.

В современном компьютерном мире наметилась тенденция моделирования сложных систем визуальными (наглядными) моделями. Наиболее известными визуальными моделями являются диаграммы языка UML [3] и стандарта IDEF0, таблицы и диаграммы стандарта IDEF1X. Эти визуальные модели имеют математическую основу в виде теорий графов, множеств и матриц. Документирование исходных кодов программ UML диаграммами и спецификациями создает единый язык общения между программистами, системными аналитиками и заказчиками автоматизированных систем. Но самое главное, что дает UML, — это возможность широкой стандартизации языков программирования. Известно, что в разных языках программирования используются одинаковые операции и методы, но они имеют разные названия и символьные обозначения. Язык UML позволяет стандартизовать как сами операции и методы языков программирования, так и их терминологию.

Язык UML имеет иерархическую структуру, первый уровень которой составляют сущности, отношения между сущностями и наглядные диаграммы. Сущности на втором уровне подразделяются на виды: структурные, поведенческие, группирующие и аннотационные сущности. На третьем уровне к структурным сущностям относятся классы, интерфейсы, кооперации, прецеденты, активные классы, компоненты, узлы. Поведенческие сущности делятся на два вида диаграмм. Диаграммы первого вида называются взаимодействиями, второго вида — автоматами. Группирующие сущности имеют только один вид пиктограмм, называемых пакетами. Аннотационные сущности также имеют один вид пиктограмм, называемых примечаниями. Отношения на втором уровне включают в себя отношения зависимостей, ассоциаций, обобщений, реализаций. Выделяют следующие диаграммы второго уровня: классов, объектов, прецедентов, последовательностей, коопераций, состояний, действий, компонентов, развертывания. Например, диаграмма прецедентов (use case diagram) — графическое представление всех или части действующих лиц (actors — кто-то (или что-то), внешний по отношению к компьютерной системе, кто (или что) взаимодействует с ней). Графически изображается в виде пиктограммы (рис. 20.5), представляющей человека, прецедентов и взаимодействий между ними. Наиболее часто actor — это человек или группа людей, использующих данные, предоставляемые компьютерной системой. Диаграммы классов применяются для моделирования объектно-ориентированных систем. UML-диаграммы классов включают в себя как частный случай диаграммы «сущность — связь» (Entity-relationship diagrams), которые используются для логического проектирования реляционных, объектно-ориентированных и гибридных объектно-реляционных БД.

Рис. 20.5. Пример UML-диаграммы прецедентов Среди инструментальных программ поддержки языка UML наиболее известной является пакет Rational Rose.

С 2000 г. развивается методика ВРМ (Business Process Management) — одна из современных управленческих методик, включающая в себя совокупность идеологии и программного обеспечения управления бизнес-процессами. С точки зрения управления ВРМ предполагает переход от функционального осмысления деятельности организации к ее видению как совокупности бизнес-процессов, пересекающих функциональные границы. Здесь в отличие от реинжиниринга ориентация происходит на непрерывный процесс усовершенствования бизнес-процессов компании. Кроме того, концепция ВРМ предполагает фокус на взаимодействии как между людьми, так и системами и аппаратными средствами.

Для моделирования архитектуры предприятия в целом применяется специальный унифицированный язык моделирования UEML (Unified Enterprise Modeling Language).

UEML включает в себя:

¦ инструментальные средства общего, визуального, базированного на шаблонах языка, моделирования предприятий и программных систем класса workflow;

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

¦ репозитарий моделей предприятий.

Моделирование осуществляется в соответствии с международными стандартами: ISO 14 258 Rules and Guidelines for Enterprise Models (Правила и руководящие принципы для моделей предприятия); ISO 15 704 Requirements for enterprise-reference architectures and methodologies (Требования и методологии по описанию архитектуры предприятия).

Инструментальными средствами моделирования предприятий, поддерживающими язык UEML, являются: Metis (Computas), e-MAGIM (GraiSoft), MOzGO (IPK) и др.