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

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

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

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

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

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

Объектно-ориентированный анализ (Object-Oriented Analysis, OOA)

Одна из типичных методик ООАП реализована в технологии Rational Unified Process (RUP). Согласно этой методике, объектно-ориентированный анализ включает два вида деятельности: архитектурный анализ и анализ вариантов использования.

Архитектурный анализ включает в себя:

• утверждение общих стандартов (соглашений) моделирования и документирования системы;

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

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

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

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

Объектно-ориентированное проектирование (Object-Oriented Design, OOD)

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

Объектно-ориентированное проектирование включает два вида деятельности:

• проектирование архитектуры системы;

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

Проектирование архитектуры системы выполняется архитектором системы и включает в себя:

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

• анализ взаимодействий между классами анализа, выявление подсистем и интерфейсов;

• формирование архитектурных уровней;

• проектирование конфигурации системы.

Проектирование элементов системы включает в себя:

• проектирование классов (детализация классов, уточнение операций и атрибутов, моделирование состояний, уточнение связей между классами);

• проектирование баз данных (в зависимости от типа используемой для хранения данных СУБД – объектной или реляционной).

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

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

Модель предметной области — это не описание программных объектов. Это представление понятий, выраженных в терминах реального мира. Эту модель также называют концептуальной объектной моделью (conceptual object model).

Моделирование может и должно способствовать лучшему пониманию проблемы или пространства решений. С этой точки зрения "применение UML" (что на самом деле должно означать “применение ООА/П”) вовсе не означает, что проектировщик должен создать множество детальных диаграмм UML, которые использовал бы программист (большинство из них склонны к не очень гибкому мышлению “в духе” каскадного процесса.) Моделирование должно позволить быстрее (по сравнению с кодированием) исследовать возможные альтернативы и наметить путь для получения качественных проектных решений.

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

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

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

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

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

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

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

Модель предметной области с использованием UML

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

• Объекты предметной области или концептуальные классы.

• Ассоциации между концептуальными классами.

• Атрибуты концептуальных классов.

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

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

В процессе разработки модели предметной области необходимо идентифицировать связи (ассоциации) между концептуальными классами, удовлетворяющие информационным требованиям сценариев, а также выделить те из них, которые способствуют лучшему пониманию модели предметной области. Ассоциация (association) — это отношение между классами (или точнее, экземплярами этих классов), отражающая некоторое значимые и полезные связи между ними. В языке UML ассоциации описываются как “семантические взаимосвязи между двумя или несколькими классификаторами и их экземплярами”.

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

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

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

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

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

Уточнение модели предметной области

Непродуманная классификация и некорректное обобщение - это проклятие организованной жизни.
(Обобщение Г. Дж. Уэллса (H.G. Wells))

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

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

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

Все элементы множества концептуальных подклассов являются элементами множества их суперкласса.

В объектно-ориентированном языке программирования подкласс наследует (inherits) атрибуты и определения операций своих суперклассов, создавая тем самым иерархию программных классов (software class hierarchy). Наследование (inheritance) — это программный механизм реализации совместимости подклассов с определениями суперклассов.

Аналитическое моделирование имеет стратегическое значение

Аналитическая модель системы среднего размера и сложности включает от 50 до 100 классов анализа. При создании аналитической модели крайне важно ограничиться лишь теми классами, которые являются частью словаря предметной области. Всегда есть искушение поместить в аналитическую модель и проектные классы (такие как классы, используемые для установления соединений или доступа к базе данных), но этого необходимо избегать (если только предметная область не касается связи или баз данных)! Такое ограничение накладывается в попытке сделать аналитическую модель кратким, простым описанием структуры и поведения системы. Все решения по реализации должны приниматься в рабочих потоках проектирования и реализации.

Правила создания хорошей аналитической модели:

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

• Создаваемые модели должны «рассказывать историю». Каждая диаграмма должна раскрывать некоторые важные части поведения системы.

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

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

• Всегда необходимо стремиться минимизировать связанность (coupling). Каждая ассоциация между классами увеличивает их связанность.

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

• Всегда должен задаваться вопрос: «Модель полезна для всех заинтересованных сторон?» Нет ничего хуже, чем создавать аналитическую модель, которая игнорируется пользователями или проектировщиками и разработчиками. Пока что это происходит очень часто, особенно с неопытными аналитиками.

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

Анализ заключается в создании моделей, отображающих основные требования и характеристики целевой системы – аналитическое моделирование имеет стратегическое значение.