Пример модели информационного обеспечения бизнеса

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

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

В отличии от примера в работе [84], покупатели не рассматриваются в качестве акторов для моделируемой системы по той причине, что они фактически не взаимодействуют с данной компьютерной системой.

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

На рисунках 4.19 и 4.20 представлены диаграммы деятельности (активности) для прецедентов «Продать товар» и «Принять товар» соответственно. Данные диаграммы уточняют поток событий конкретного прецедента. Это уточнение необходимо для выявления классов и построения объектной модели.

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

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

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

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

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

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

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

Диаграмма кооперации (рис. 4.22) может быть автоматически преобразована в Rational Rose в диаграмму последовательности. Результата такого преобразования представлен на рисунках 4.23 – 4.24.

Таким образом, объектно-ориентированная методология, использующая стандартный язык UML, предоставляет полезные средства анализа и моделирования как информационных, так и организационных систем. При этом используется три вида моделей, аналогичных по своему предназначению трем моделям технологии 3VM или стандартам IDEF [84, 105]:

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

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

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

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

Выводы

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

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

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

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

Дата добавления: 2014-12-27