4.1. Методологии моделирования проблемной области

В основе реинжиниринга бизнес-процессов и проектирования КИС лежит моделирование проблемной области.

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

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

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

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

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

Поэтому все современные технологии проектирования КИС основываются на использовании методологии моделирования проблемной области.

К моделям проблемных областей предъявляются следующие требования:

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

• понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;

• реализуемость, т.е. наличие средств физической реализации модели проблемной области в ИС;

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

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

Структурный аспект функционирования ИС предполагает построение:

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

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

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

• Организационной структуры, отражающих взаимодействие организационных единиц предприятия и персонала в процессах;

• Технической структуры, которая описывает топологию расположения и способы коммуникации комплекса технических средств.

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

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

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

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

Трудности возникают при переходе от этапа анализа требований к системе к этапу проектирования и в особенности к программированию.

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

Рассмотрим особенности построения моделей проблемной области на трех уровнях детализации.

Объектная структура.

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

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

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

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

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

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

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

Функциональная структура

Функция (операция) представляет собой некоторый преобразователь входных объектов в выходные.

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

Функция бизнес-процесса может порождать объекты любой природы (материальные, денежные, информационные). Например, функция отгрузки готовой продукции осуществляется на основе документа «Заказ». Этот документ, в свою очередь, порождает документ «Накладная», который сопровождает партию отгруженного товар.

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

На внешнем уровне моделирования определяется список основных бизнес-функций или видов бизнес-процессов. Обычно таких функций насчитывается 15-20.

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

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

Структура управления

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

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

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

Такая последовательность событий составляет конкретную реализацию бизнес-процесса.

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

Информационно некоторое событие отражается в виде некоторого сообщения. Это сообщение фиксирует факт выполнения некоторой функции изменения состояния или появление нового объекта.

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

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

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

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

На внутреннем уровне выполняется формализация бизнес-правил в виде триггеров или вызовов программных модулей.

Организационная структура

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

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

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

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

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

На концептуальном уровне для каждого подразделения задается организационно-штатная структура должностей (ролей персонала).

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

Техническая структура

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

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

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

На внутреннем уровне строится модель «клиент-серверной» архитектуры вычислительной сети.

Все описанные модели проблемной области нацелены на проектирование отдельных компонентов ИС:

• данных;

• функциональных программных модулей;

• управляющих программных модулей;

• программных модулей интерфейсов пользователей;

• структуры технического комплекса.

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

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

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

Однако все многообразие этих методологий можно разделить на две группы:

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

2. методологии объектно-ориентированного анализа и проектирования ИС (объектно-ориентированные методологии).

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

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

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

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

В функциональном подходе объектные модели данных разрабатываются отдельно в виде ER-диаграмм «сущность-связь».

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

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

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

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

Главным компонентом таких моделей является класс объектов с набором функций, которые могут обращаться к атрибутам этого класса (скрытые данные).

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

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

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

Для объектно-ориентированного подхода разработаны графические методы моделирования проблемной области, которые обобщены в языке моделирования UML.

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

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

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

В полной мере комбинированный подход к моделированию проблемной области реализован в инструментальном средстве ARIS-Toolset (Architecture of Integrated Information System). Это инструментальное средство реализует множество различных методологий, соответствующих различным взглядам на проектирование ИС: объекты, функции, организационная структура.

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

DFD-диаграммы и SADT-технология стали основой для разработки в 80-х годах ХХ-века в США серии стандартов методологий структурного анализа, получивших название методологии IDEF (Integrated Computer Automated Manufacturing DEFinition). Они применялись для моделирования как сложных военных систем и структур, так и в корпоративном управлении.

Всего было создано 14 стандартов IDEF, в том числе:

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

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

3. IDEF1X - моделирование данных;

4. IDEF2 - динамическое моделирование;

5. IDEF3 - описание процессов;

6. IDEF4 - объектно-ориентированные методы проектирования;

7. IDEF8 - интерфейс пользователя;

8. IDEF14 - проектирование вычислительных сетей.

Детальное описание стандартов IDEFможно найти по адресу http://www.indel.com

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

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

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

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

В настоящий время наиболее широко используются следующие стандарты IDEF:

• IDEF0 - методология функционального моделирования. С помощью наглядного графического языка IDEF0 представляет изучаемую систему в виде набора взаимосвязанных функций ("функциональных блоков"). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы;

• IDEF1 - методология моделирования информационных потоков внутри системы. Позволяет отображать и анализировать их структуру и взаимосвязь;

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

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

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

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

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