ВНЕДРЕНИЕ ПРОЕКТА РЕИНЖИНИРИНГА БП 1 страница

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

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

Вопросы для самоконтроля

1. Что такое бизнес-процесс и чем процесс управления бизнес-процессом отличается от управления ресурсами

2. Что понимают под реинжинирингом бизнес-процессов. Какие задачи решает реинжиниринг?

3. Перечислите основные этапы реинжиниринга бизнес-процессов.

4. Что понимают под моделью проблемной области.

5. Какие требования предъявляют к модели проблемной области.

6. Какие существуют критерии для оценки модели проблемной области?

ЛЕКЦИЯ 8
АВТОМАТИЗИРОВАННОЕ ПРОЕКТИРОВАНИЕ ЭИС
(CASE – ТЕХНОЛОГИИ)

ОСНОВНЫЕ ПОНЯТИЯ И КЛАССИФИКАЦИЯ
CASE – ТЕХНОЛОГИЙ

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

Наибольшая потребность в использовании CASE–систем испытывается на начальных этапах разработки, а именно на этапах анализа и спецификации требований к ЭИС. Так как цена ошибок, допущенных на этих этапах, превышает цену ошибок, допущенных на последующих стадиях разработки. Преимущества CASE–технологии по сравнению с традиционной технологией оригинального проектирования:

· улучшение качества разрабатываемого программного приложения за счет средств автоматического контроля и генерации;

· возможность повторного использования компонентов разработки;

· поддержание адаптивности и сопровождения ЭИС;

· снижение времени создания системы, возможность получения на ранних стадиях прототипа системы и его оценки;

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

CASE – средства имеют следующую архитектуру.

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

· проектировщиков и их прав доступа к различным компонентам системы;

· организационных структур;

· диаграмм;

· компонентов диаграмм;

· связей между диаграммами;

· структур данных;

· программных модулей;

· процедур;

· библиотеки модулей.

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

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

· создавать элементы диаграмм и взаимосвязи между ними;

· задавать описания элементов диаграмм;

· задавать описания связей между элементами диаграмм;

· редактировать элементы диаграмм, их взаимосвязи и описания.

Верификатор диаграмм служит для контроля правильности построения диаграмм в заданной методологии проектирования ЭИС. Он выполняет следующие функции:

· мониторинг правильности построения диаграмм;

· диагностику и выдачу сообщений об ошибках;

· выделение на диаграмме ошибочных элементов.

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

Администратор проекта представляет собой инструменты, необходимые для выполнения следующих административных функций:

· инициализации проекта;

· задания начальных параметров проекта;

· назначения и изменения прав доступа к элементам проекта;

· мониторинга выполнения проекта.

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

Современные CASE–системы классифицируются по следующим признакам:

· по поддерживаемым методологиям проектирования: функционально (структурно)-ориентированные, объектно-ориентированные, комплексно-ориентированные (набор методологий проектирования);

· по поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями, с наиболее распространенными нотациями;

· по степени интегрированности:

tools (отдельные локальные средства);

toolkit (набор неинтегрированных средств, охватывающих большинство этапов разработки ЭИС);

workbench (полностью интегрированные средства, связанные с репозиторием);

· по типу и архитектуре вычислительной техники: ориентированные на ПЭВМ, ориентированные на ЛВС, Ориентированные на ГВС, смешанного типа;

· по режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального времени разработки проекта, ориентированные на режим объединения подпроектов;

· по типу ОС.

Помимо поддержки начальных этапов разработки важное значение приобретают CASE-системы, ориентированные на проектирование и генерацию БД и пользовательских интерфейсов.

ФУНКЦИОНАЛЬНО – ОРИЕНТИРОВАННОЕ
ПРОЕКТИРОВАНИЕ ЭИС

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

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

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

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

· BFD – диаграмма бизнес-функций (функциональные спецификации):

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

Функция – некоторое действие ИС, необходимое для решения экономической задачи;

Декомпозиция функций – разбиение функций на множество подфункций;

· SAGнотация:

· DFD – диаграмма потоков данных (ДПД);

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

· STD – диаграмма переходов состояний (ДПС - матрицы перекрестных ссылок);

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

· SSD – диаграмма структуры программного приложения задает взаимосвязь функций и программных модулей, которые их реализуют. Представляет собой иерархическую взаимосвязь программных модулей, которые реализует ИС. Служит мостом для перехода от системных требований, которые отображены в предыдущих диаграммах, к реализации информационной системы. Фрагмент SSD-диаграммы в нотации SAG для задачи аналитического учета на складах имеет вид:

· ERD – ER-модель данных предметной области (информационно-логические модели «сущность – связь»):

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

 

ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ ЭИС

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

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

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

Для ОО моделирования используется унифицированный язык моделирования (UML). Система ОО моделей в соответствии с нотациями UML включает в себя следующие диаграммы:

1. Диаграмму прецедентов использования (Use-case diagram), которая отображает функциональность ЭИС в виде совокупности выполняющихся последовательных транзакций;

2. Диаграмму классов объектов (Class diagram), которая отображает структуру совокупности взаимосвязанных классов объектов аналогично ER-диаграмме функционально-ориентированного подхода;

3. Диаграммы состояний (Statechart diagram), каждая из которых отображает динамику состояний объектов одного класса и связанных с ним событий;

4. Диаграммы взаимодействия объектов (Interaction diagram), каждая из которых отображает динамическое взаимодействия объектов в рамках одного прецедента использования;

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

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

7. Диаграмму компонентов (Component diagram), которая отображает физические модули программного кода;

8. Диаграмму размещения(Deployment diagram), которая отображает распределение объектов по узлам вычислительной сети.

Диаграмма прецедентов использования (ДПИ)

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

 

Актер – внешний пользователь процесса

 

 

Прецедент использования (БП)

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

Информирование об отложенном заказе Информирование о заказе на закупку

выполнить заказ клиента

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

формирование

заказа

удаление подтверждение

Менеджер заказа заказа Менеджер

по продажам ввод по закупкам

данных

оформление

договора

 

Рис. 6. Пример ДПИ

В реализации прецедентов использования (ПИ) возможно выделение нескольких потоков событий:

· основной поток событий, который приводит к требуемому результату наиболее коротким путем, например выполнение заказа без задержек;

· альтернативные потоки событий, например временное откладывание или полный отказ от выполнения заказов.

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

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

выполнить заказ клиента

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

заключить договоры с частными лицами     с частными лицами

заключить договор с юридическими лицами

выборка данных

ввод uses

данных

Менеджер

оформление uses

договора

extends extends

 

Рис. 7 Пример применения отношений использования и расширения

Диаграммы классов объектов (ДКО)

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

 

 

Интерфейсный объект –	Управляющий объект -	Сущность –
активный объект форма взаимодействия ИС с пользователем (экранная форма, меню, кнопка)	активный объект, координирующий выполнение функций	пассивный объект над которым выполняются операции обработки

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

Диаграммы состояний (ДС)

ДС отображает поведение объектов одного класса в динамике, связь состояний объектов с событиями и определяет:

· типичные состояния проходит объект;

· события, ведущие к изменению состояния объекта;

· действия выполняемые, когда он получает сообщение об изменении состояния;

· объекты создаются и уничтожаются (входные и выходные точки диаграммы).

Используются следующие обозначения:

 

Входная точка Состояние Переход состояний Выходная точка

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

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

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

· назначение – состояние объекта, в которое перейдет объект после перехода состояния.

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

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

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

Переход состояний графически помечается меткой линии, на которой задается, по крайней мере, один из следующих атрибутов: Вызов, Условие перехода, Действие.

Диаграмма взаимодействия объектов

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

· в форме диаграммы последовательностей, показывающей последовательность взаимодействий на графе;

· в форме кооперативной диаграммы, показывающей взаимодействие объектов в табличной форме.

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

Диаграмма кооперативного поведения представлена в табличном виде по следующим правилам.

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

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

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

Диаграмма деятельностей

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

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

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

Имеют место следующие обозначения:

Деятельность

Выход

Поток от деятельности к деятельности

Итерация

Синхронизация

 

Решение

Разделение потока на деятельности,

выполняемые параллельно или произвольно

 

Диаграммы пакетов

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

Пакетная технология группирования классов объектов позволяет:

· упростить разработку и эксплуатацию ЭИС;

· применить гибкую адаптацию типовых компонентов с позиции их повторного использования;

· оптимизацию клиент-серверной архитектуры ЭИС.

Обычно ЭИС разбивается на функциональные и обеспечивающие пакеты. Функциональные пакеты, соответствующие решаемым проблемам (задачам), объединяются в один общий пакет «Проблемная область». Каждый пакет, в свою очередь, может быть разбит на подпакеты в соответствии с семантической близостью и теснотой взаимодействия классов объектов. Обычно пакеты проблемной области содержат иерархии обобщения и агрегации. Классы объектов, требуемые в нескольких подсистемам выделяются в самостоятельные пакеты. В одном пакете, как правило, выделяется не более 20 компонентов.

С обеспечивающей точки зрения ЭИС разбивают на пять основных пакетов:

· Интерфейс, объекты которого реализуют функции взаимодействия пользователей с ЭИС по вводу-выводу информации и обмен сообщениями между системами;

· БД, объекты выполняющие доступ к данным внешней памяти;

· Управление задачами, объекты которого осуществляют функции диспетчеризации и маршрутизации обработки объектов, например, в системе управления рабочими потоками;

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

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

Диаграммы компонентов и размещения

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

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

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

Рассмотрим подробнее эти операции.

Анализ системных требования к ЭИС

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

ТС анализа системных требований к ЭИС имеет следующий вид.

Разработка диаграммы классов объектов

Разработка диаграммы прецедентов использования ЭИС

Разработка диаграммы состояний объектов

Разработка диаграммы пакетов

 

 

Рис. 8. ТСП анализа системных требований к ЭИС

Так, в объектно-ориентированной (ОО) методологии анализа и проектирования предусматриваются:

· описание БП как прецедентов использования, актерами которых служат внешние участники БП (клиенты, поставщики).

· задание порядка разработки и автоматизации БП в соответствии с определенными критериями, например, наибольшим эффектом для заказчика, простотой и быстротой разработки.

· неформальное словесное описание БП.

Структура основных БП и их взаимодействий описывается в соответствии с требованиями модели классов объектов.

Анализ системных требований начинается с идентификации основных прецедентов использования и объектов-сущностей, которые будут применяться в ИС. Работы по идентификации прецедентов использования классов объектов-сущностей, как правило, выполняются параллельно. В случае ОО оформления результатов предпроектного обследования данная работа упрощается в силу однозначности соответствия БП и прецедентов использования ЭИС, бизнес-объектов и объектов сущностей.

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

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

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

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

Логическое проектирование ЭИС

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

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