Файл: Анализ и оценка средств реализации объектно-ориентированного подхода к проектированию экономической информационной системы ( История возникновения объектно-ориентированного подхода проектирования информационных систем ).pdf

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

Основной диаграммой UML, используемой в данном методе, является диаграмма деятельности. Метод Eriksson-Penker представляет процесс в виде деятельности со стереотипом "process" (основой данного представления является расширение метода IDEF0). Полная бизнес-модель включает множество представлений, подобных представлениям архитектуры ПО. Каждое представление выражено в одной или более диаграммах UML. Диаграммы могут иметь различные типы и изображать процессы, правила, цели и ресурсы во взаимодействиях друг с другом. Метод использует четыре различных представления бизнес-модели:

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

Методика моделирования RUP [13] предусматривает построение двух моделей:

• модели бизнес-процессов (Business Use Case Model);
• модели бизнес-анализа (Business Analysis Model).

Модель бизнес-процессов представляет собой расширение модели вариантов использования UML за счет введения набора стереотипов - Business Actor (стереотип действующего лица) и Business Use Case (стереотип варианта использования). Business Actor (действующее лицо бизнес-процессов) - это некоторая роль, внешняя по отношению к бизнес-процессам организации. Business Use Case (вариант использования с точки зрения бизнес-процессов) определяется как описание последовательности действий (потока событий) в рамках некоторого бизнес-процесса, приносящей ощутимый результат конкретному действующему лицу. Это определение подобно общему определению бизнес-процесса, но имеет более точный смысл. В терминах объектной модели Business Use Case представляет собой класс, объектами которого являются конкретные потоки событий в рамках описываемого бизнес-процесса.

Описание Business Use Case может сопровождаться целью процесса, которая, так же, как и в методе Eriksson-Penker, моделируется с помощью класса со стереотипом "goal", а дерево целей изображается в виде диаграммы классов.

Для каждого Business Use Case строится модель бизнес-анализа - объектная модель, описывающая реализацию бизнес-процесса в терминах взаимодействующих объектов (бизнес-объектов - Business Object), принадлежащих к двум классам - Business Worker и Business Entity. Business Worker (исполнитель) - класс, представляющий собой абстракцию исполнителя, выполняющего некоторые действия в рамках бизнес-процесса. Исполнители взаимодействуют между собой и манипулируют различными сущностями, участвуя в реализациях сценариев Business Use Case. Business Entity (сущность) является объектом различных действий со стороны исполнителей.

Кроме диаграммы данных классов, модель бизнес-анализа может включать:

• Диаграммы последовательности (и кооперативные диаграммы), описывающие сценарии Business Use Case в виде последовательности обмена сообщениями между объектами-действующими лицами и объектами-исполнителями. Такие диаграммы помогают явно определить в модели обязанности каждого исполнителя в виде набора его операций.
• Диаграммы деятельности, описывающие взаимосвязи между сценариями одного или различных Business Use Case.
• Диаграммы состояний, описывающие поведение отдельных бизнес-объектов.
• Методика моделирования Rational Unified Process обладает следующими достоинствами:
• модель бизнес-процессов строится вокруг участников процессов (заинтересованных лиц) и их целей, помогая выявить все потребности клиентов организации. Такой подход в наибольшей степени применим для организаций, работающих в сфере оказания услуг (торговые организации, банки, страховые компании и т.д.);
• моделирование на основе вариантов использования способствует хорошему пониманию бизнес-модели со стороны заказчиков.

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

Спецификация требований к ПО является составной частью процесса управления требованиями [15]. Выявленные в результате применения перечисленных методов требования к ПО оформляются в виде ряда документов и моделей. Так, в технологии RUP функциональные требования к системе моделируются и документируются с помощью вариантов использовании. Стиль их написания зависит от масштаба, количества участников и критичности проекта.

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

4.2 Анализ и проектирование информационной системы

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

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

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

Анализ вариантов использования выполняется проектировщиками и включает в себя:

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

В потоках событий варианта использования выявляются классы трех типов:

• Граничные классы (Boundary) - служат посредниками при взаимодействии внешних объектов с системой. Типы граничных классов: пользовательский интерфейс (обмен информацией с пользователем, без деталей интерфейса - кнопок, списков, окон), системный интерфейс и аппаратный интерфейс (используемые протоколы, без деталей их реализации).
• Классы-сущности (Entity) - представляют собой основные абстракции (понятия) разрабатываемой системы, рассматриваемые в рамках конкретного варианта использования.
• Управляющие классы (Control) - обеспечивают координацию поведения объектов в системе. Примеры управляющих классов: менеджер транзакций, координатор ресурсов, обработчик ошибок.

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

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

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

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

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

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

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

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

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

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

Заключение

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