CASE-средства создания информационных систем

Практическая работа

«CASE-средства создания информационных систем.
Создание модели процессов в BPWin»

Цель работы

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

CASE-средства создания информационных систем

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

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

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

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

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

3. 3. Жизненный цикл создания сложной ИС сопоставим с ожидаемым временем ее эксплуатации. Другими словами, в современных условиях компании перестраивают свои бизнес-процессы примерно раз в два года, столько же требуется (если работать по традиционной технологии) для создания ИС. Может оказаться, что к моменту сдачи ИС она уже никому не нужна, поскольку компания, ее заказавшая, вынуждена перейти на новую технологию работы. Следовательно, для создания ИС необходим инструмент значительно (в несколько раз) уменьшающий время разработки ИС.

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

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

CASE-cредство BPWin предназначено для проведения анализа и реорганизации бизнес-процессов. BPWin поддерживает методологию IDEF0 (функциональная модель). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии или идеального положения вещей – того, к чему нужно стремиться. Методология IDEF0 предписывает построение иерархической системы диаграмм – единичных описаний фрагментов системы. В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной – функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.

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

Среда BPWin

При запуске BPWin по умолчанию появляется основная панель инструментов, палитра инструментов и, в левой части экрана, навигатор модели (иерархическая структура модели).

Модель BPWin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные - в виде стрелок.

Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется всплывающее контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.

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

При создании новой модели возникает диалог, в котором следует указать имя модели, которая будет создана, выбрать методологию моделирования Business Process (IDEF0) и нажать ОК.

Рисунок 1 – Создание новой модели

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

Рисунок 2 - Контекстная диаграмма с единственной работой, изображающей систему в целом

Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы.

Рисунок 3 – Внесение имени работы

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

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

Рисунок 4 – Декомпозиция работы

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

Рисунок 5 – Диаграмма декомпозиции

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

Взаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелки представляют собой некую информацию и именуются существительными (например, «Заготовка», «Изделие», «Заказ» и т.д.).

В IDEF0 различают 5 типов стрелок. Рассмотрим более подробно 4 из них.

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

Управление (Control) – правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Стрелка управления рисуется как входящая в верхнюю грань работы. Управление влияет на работу, но не преобразуется работой. Каждая работа должна иметь хотя бы одну стрелку управления.

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

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

Для внесения стрелок необходимо нажать на кнопку с символом .

Внесение стрелок необходимо начинать с контекстной диаграммы.

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

Рисунок 6- Пример внесения стрелок

Словарь стрелок редактируется с помощью специального редактора Arrow Dictionary Editor, в котором определяется стрелка и вносится относящийся к ней комментарий.

Рисунок 7 – Редактор стрелок

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

Рисунок 8 - Пример несвязных стрелок

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

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

Ниже приведен пример отредактированной диаграммы декомпозиции.

Рисунок 9 - Отредактированная диаграмма декомпозиции

По окончании рисования стрелок для перехода в режим редактирования модели необходимо нажать кнопку .

Далее каждая работа может быть разбита на более мелкие работы, до требуемого уровня детализации.

Для проверки синтаксиса модели следует вызвать диалог Tools/Reports/Model Consistency Report. После чего появится диалоговое окно.

Затем следует выбрать пункт Preview для предварительного просмотра списка синтаксических ошибок модели. Список синтаксических ошибок может включать:

- - неименованные функциональные блоки и стрелки (unnamed arrows, unnamed activities);

- - несвязанные стрелки (unconnected border arrow);

- - неразрешенные стрелки (unresolved (square tunneled) arrow connection);

- - блоки, не имеющие по крайней мере одной стрелки выхода и одной стрелки управления (activity “Наименование функционального блока” has no Control) и т.д.

Для наглядного представления количества уровней декомпозиции и отношений между родительскими и дочерними диаграммами следует сформировать отчет Node Tree. Для этого нужно вызвать диалог Diagram/Add Node Tree.После чего появится диалоговое окно, где будет предложено название отчета (можно написать другое) – Node Tree Name, верхний уровень диаграммы, с которого следует начать строить отчет – Top level activity, и выбрать количество уровней который будет иметь отчет – Number of levels.

Рисунок 10 – Окно построения отчета Node Tree

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