Глава 2. Методы анализа и проектирования систем управления

2.1. Методологии анализа и проектирования систем управления

Определим основные используемые далее понятия.

Методология (от метод и …логия) – учение структуре, логической организации, методах и средствах деятельности. Система (от греч. systema – целое, составленное из частей; соединение) – множество элементов, находящихся в отношениях и связях друг с другом, образующих определенную целостность, единство [3].

Методология SA/SD (Structured Analysis/Structured Design – Структурный анализ/Структурное проектирование) содержит несколько вариантов систем обозначений для формальной спецификации программных систем [48]. На этапе анализа требований и предварительного проектирования для логического описания проектируемой системы используются спецификации (формальные описания) процессов, словарь данных, функциональные диаграммы SADT, диаграммы потоков данных, диаграммы состояний и диаграммы зависимостей объектов.

Диаграмма SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования) разработана специально для того, чтобы облегчить описание и понимание искусственных систем, попадающих в разряд средней сложности. SADT-модель дает полное, точное и адекватное описание системы, имеющее конкретное назначение. Целью модели является получение ответов на некоторую совокупность вопросов.

Диаграммы потоков данных (DFD – Data Flow Diagram), составляющие основу методологии SA/SD, моделируют преобразования данных при их прохождении через систему. Методология SA/SD состоит в последовательном рассмотрении процессов, входящих в состав DFD, с представлением каждого процесса через DFD, содержащую в своем составе более простые процессы. Эта процедура представления более сложных процессов через DFD начинается с DFD всей системы и заканчивается, когда все полученные DFD содержат достаточно элементарные процессы. Для каждого процесса самого нижнего уровня составляется спецификация; спецификация описывается с помощью псевдокода, таблиц принятия решений и т.п. Детали, не учтенные в наборе DFD, содержатся в словаре данных, который определяет потоки и хранилища данных, а также семантику различных имен.

Так в методологии SA/SD организован этап структурного анализа (SA). После структурного анализа начинается этап структурного конструирования (SD), в процессе которого разрабатываются и уточняются более тонкие детали проектируемой системы. Таким образом, в методологии SA/SD проектируемая система описывается с помощью процедур (процессов). Методология SA/SD является одним из первых хорошо продуманных формальных подходов к разработке программных систем.

Методология IDEF (ICAM Definition – Комплексная автоматизация производственных процессов) семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем, позволяет отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах [45]. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными.

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

В настоящий момент к семейству IDEF можно отнести следующие методы:

IDEF0 – Function Modeling – метод функционального моделирования. С помощью наглядного графического языка IDEF0, изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы. Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique);

IDEF1 – Information Modeling – метод моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;

IDEF1X (IDEF1 Extended) – Data Modeling – метод построения реляционных структур (баз данных), относится к типу методов "Сущность-связь" (ER – Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

IDEF2 – Simulation Model Design – метод динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. В настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе "раскрашенных сетей Петри" (Color Petri Nets);

IDEF3 – Process Description Capture – Документирование технологических процессов. IDEF3 – метод документирования процессов, происходящих в системе (например, на предприятии), описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методом IDEF0 - каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3;

IDEF4 – Object-Oriented Design – метод построения объектно-ориентированных систем, позволяют отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;

IDEF5 – Ontology Description Capture – стандарт онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация;

IDEF6 – Design Rationale Capture – обоснование проектных действий. Назначение IDEF6 состоит в облегчении получения "знаний о способе" моделирования, их представления и использования при разработке систем управления предприятиями. Под "знаниями о способе" понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, "знания о способе" интерпретируются как ответ на вопрос: "почему модель получилась такой, какой получилась?" Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF6 акцентирует внимание именно на процессе создания модели;

IDEF7 – Information System Auditing – аудит информационных систем. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF8 – User Interface Modeling – метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDFE8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфейс для выполнения операции);

IDEF9 – Scenario-Driven IS Design (Business Constraint Discovery method) – метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие. Обычно, при построении моделей описанию ограничений, оказывающих влияние на протекание процессов на предприятии уделяется недостаточное внимание. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что построенные модели нежизнеспособны, просто их реализация столкнется с непредвиденными трудностями, в результате чего их потенциал будет не реализован. Тем не менее, в случаях, когда речь идет именно о совершенствовании структур или адаптации к предсказываемым изменениям, знания о существующих ограничениях имеют критическое значение;

IDEF10 – Implementation Architecture Modeling – моделирование архитектуры выполнения. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF11 – Information Artifact Modeling. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF12 – Organization Modeling – организационное моделирование. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF13 – Three Schema Mapping Design – трёхсхемное проектирование преобразования данных. Этот метод определён как востребованный, однако так и не был полностью разработан;

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

Методология ARIS (рис. 2.1) (Architecture of Integrated Information Systems – Архитектура интегрированных информационных систем) – методология для моделирования бизнес-процессов организаций [46]. Методология ARIS на данный момент времени является наиболее объемной и содержит около 100 различных бизнес-моделей, используемых для описания, анализа и оптимизации различных аспектов деятельности организации. Часть моделей методологии ARIS используются в настроечном модуле интегрированной информационной системы SAP/R3, который применяется при внедрении системе и ее настройке на деятельности компании. В виду большого количества бизнес-моделей методология ARIS делит их на четыре группы:

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

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

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

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

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

Несмотря на большее количество моделей в методологии ARIS в проектах по описанию и оптимизации деятельности в общем случае их используется не более десяти. Методология ARIS позиционирует себя как конструктор, из которого под конкретный проект в зависимости от его целей и задач разрабатывается локальная методология, состоящая из небольшого количества требуемых бизнес-моделей и объектов. В общем случае практика показала, что в проектах наиболее часто используются модели, приведенные в таблице 2.1.

Рис. 2.1. Группы моделей методологии ARIS

Таблица 2.1.

Наиболее часто используемые на практике модели методологии ARIS

№	Название модели		Описание и предназначение модели
	Английский вариант	Русский вариант
1.	OD-Objective diagram.	Диаграмма целей.	Модель описывает стратегические цели компании и их взаимосвязь с другими элементами организации.
2.	PST-Product/Service tree.	Дерево продуктов и услуг.	Модель описывает продукты и услуги, производимые компанией и их взаимосвязь с другими элементами организации.
3.	FT-Function tree.	Дерево функций.	Модель описывает функции, выполняемые в компании и их иерархию.
4.	FAD-Function allocation diagram.	Диаграмма окружения процесса.	Процессная модель описывает окружение бизнес-процесса.
5.	VACD-Value added chain diagram.	Диаграмма цепочки добавленной стоимости.	Процессная модель - прототип классического стандарта DFD. Применяется для описания бизнес-процессов верхнего уровня.
6.	PSM - Process selection matrix.	Матрица выбора процесса.	Процессная модель - прототип классического стандарта DFD. Является альтернативой модели VACD и применяется для описания бизнес-процессов верхнего уровня.
7.	eEPC - Extended event driven Process Chain.	Расширенная цепочка процессов, управляемая событиями.	Процессная модель прототип классического стандарта WFD. Применяется для описания бизнес-процессов нижнего уровня.
8.	ORG - Organizational chart.	Модель организационной структуры.	Модель описывает организационную структуру компании.
9.	ASTD-Application system type diagram.	Диаграмма типов информационных систем.	Модель описывает структуру информационных систем, используемых в компании.

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

Методология ORACLE используется для поддержки всего жизненного цикла информационных технологий на предприятии, включая поддержку внедрения продуктов и технологий Oracle [49]. Данная методология универсальна и явно не привязана к конкретным продуктам и технологиям, что даёт возможность её адаптации под другие типы ИТ-проектов. Она включает набор готовых шаблонов, руководство и структуру работ, а так же содержит программные инструменты для управления рисками, связанными с проектами.

Методология ORACLE состоит из трёх областей:

• Управление (Manage) – управления программами (Program Management Method, PGM) и проектами (Project Management Method, PJM);

• Представление (Envision) – поддержка ИТ-архитектуры на уровне предприятия, её стратегия развития и управления, а так же выявление и создание специфических проектов;

• Реализация (Implement) – реализация проектов.

Каждый проект, согласно методологии, состоит из 5 фаз:

• Начальная фаза (Inception);

• Проектирование системы (Elaboration);

• Разработка системы (Construction);

• Переход к эксплуатации системы (Transition);

• Эксплуатация системы (Production).

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

Методология BAAN – методология описания деятельности, разработанная компанией разработчиком информационных систем BAAN, содержит бизнес-модели, описание которых приведено в таблице 2.2 [46].

Таблица 2.2.

Модели методологии BAAN

№	Название модели			Описание и предназначение модели
	Английский вариант	Русский вариант
1.	ESM – Enterprise Structure Model.	Модель метаструктуры предприятия.	Модель позволяет описать географически распределенную структуру компании.
2.	BCM - Business Control Model.	Модель управления.	Процессная модель описывает бизнес-процессы компании в стандарте DFD. Применяется для описания бизнес-процессов верхнего уровня.
3.	BPM - Business Process Model.	Процессная модель.	Модель описывает бизнес-процессы компании в стандарте WFD. Применяется для описания бизнес-процессов нижнего уровня.
4.	BFM - Business Function Model	Функциональная модель	Модель описывает функции, выполняемые в компании и их иерархию.
5.	BOM - Business Organization Model.	Организационная модель.	Модель описывает организационную структуру компании.
6.	ERM – Entity-Relationship Model.	Информационная модель	Информационная модель типа "Сущность-Связь" описывает структуру информации, используемой при реализации бизнес-процессов. Позволяет описать структуру базы данных.

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

Методология OSA (Object-Oriented System Analysis – Объектно-ориентированный системный анализ) обеспечивает объектно-ориентированный анализ программных систем и не содержит возможностей, связанных с поддержкой этапа разработки [43]. Методология OSA сосредоточена только на проблемах анализа, предлагая ряд интересных соображений, связанных с объектно-ориентированным анализом систем и специально исключая из рассмотрения особенности, характерные для разработки. Предлагая удобные и тонкие методы анализа систем, методология OSA обеспечивает интерпретацию моделей на компьютере на самых ранних этапах анализа системы. Методология OSA, как и другие методологии, поддерживает три взаимно-ортогональных представления проектируемой системы:

• модель зависимостей между объектами;

• модель поведения объектов;

• модель взаимодействия объектов.

Методология OMT (Object Modeling Technique – Технология объектного моделирования) поддерживает две первые стадии разработки программных систем [43]. Эта методология опирается на программный продукт OMTTool, который позволяет разрабатывать модели проектируемой программной системы в интерактивном режиме с использованием многооконного графического редактора и интерпретатора наборов диаграмм, составляемых при анализе требований к системе и ее проектировании с использованием методологии OMT. Таким образом, как только получен достаточно полный набор диаграмм проектируемой программной системы, его можно проинтерпретировать и предварительно оценить различные свойства будущей реализации системы.

Методология UML (Unified Modelling Language – Унифицированный язык моделирования) – результат довольно длинной и еще не завершившейся эволюции методологий моделирования и дизайна [43]. Данная методология преследует три основные цели:

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

• разрешение проблем масштабирования в сложных системах;

• создание языка моделирования, используемого и человеком, и компьютером.

В настоящее время методология UML поддерживает более 10 основных видов моделей для описания бизнес-процессов предприятия.

• Диаграммы, описывающие поведение системы:

1. Диаграммы состояний (State diagrams): включает в себя состояния, переходы, события и виды дейст­вий.

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

3. Диаграммы деятельностей (Activity diagrams): частный случай диаграммы состояний; на ней представлены переходы потока управления от одной деятельности к другой внутри системы.

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

5. Диаграммы взаимодействия (Collaboration diagrams): связи между объектами; показаны, в частности, сообщения, которыми объекты могут обмениваться.

6. Диаграммы последовательностей (Sequence diagrams): частный случай диаграммы взаимодействия, отражают временную упорядоченность сообщений.

• Диаграммы, описывающие физическую реализацию системы:

1. Диаграммы компонент (Component diagrams): организация совокупности компонентов и существующие между ними зависимости;

2. Диаграммы развертывания (Deployment diagrams): конфигурация обрабатывающих узлов системы и размещенных в них компонентов.

Можно выделить основные этапы разработки системы с использованием средств UML:

1. описание задания в общих чертах на естественном языке;

2. выделение прецедентов и актеров бедующей системы;

3. определение объектов и взаимодействий между ними;

4. детализация функциональности с помощью диаграмм последовательности (переходов) для каждого прецедента;

5. группировка объектов, переход от объектов и сущностей к компонентам;

6. ревизия результатов предыдущих этапов;

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

8. Построение профиля баз данных с учетом способа хранения данных в выбранной СУБД;

9. размещение компонентов системы;

10. кодирование.

Каждый этап поддерживается соответствующими UML-диаграммами.