Рассмотрим нашу задачу об учете отпуска готовой продукции со склада. Цель – создать модель бизнес-процессов данной предметной области с использование методологии RUP и инструментария Rational Suite.
Напомним основные положения методологии RUP.
Методология RUP (Rational Unified Process) создана для поддержки управления инкрементной моделью жизненного цикла разработки ИС. С помощью этой методологии можно подробно описать технические и организационные аспекты создания информационной системы на стадиях определения требований к системе, анализа и проектирования.
Методология Rational Unified Process структурирована в двух направлениях:
- время (разделение жизненного цикла на фазы и версии или итерации);
- компоненты процесса (создание необходимого набора средств для выполнения четко определенных задач).
Первое направление относится к динамической составляющей RUP, второе направление – к статической составляющей. Оба направления должны быть хорошо проработаны для получения успешного проекта.
Работа над проектом состоит из следующих временных этапов:
- задумка (inception) - определение общей идеи проекта;
- проработка (elaboration) - планирование необходимых работ и ресурсов, указание особенностей и создание архитектуры;
- создание (construction) - построение продукта при помощи серии последовательных версий;
- переходный период (transition) - поставка продукта пользователям (производство, распространение, обучение).
В разрезе компонентов процесс делится на следующие стадии:
- построение бизнес-модели (business modeling) - определение необходимых возможностей системы и потребностей пользователей;
- определение требований к системе (requirements) - изложение общей идеи системы совместно с функциональными и нефункциональными условиями ее работы;
- анализ (analysis) и проектирование (design) - описание способов исполнения системы на этапе реализации;
- реализация (implementation) - кодирование и генерация работающих программных модулей системы;
- тестирование (test) - проверка функционирования системы;
- внедрение (deployment) - поставка системы конечным пользователям и их обучение.
Каждая стадия в разрезе компонентов процесса обычно применяется к конкретной фазе временного направления (рис.9). Однако степень применения каждого компонента зависит от этапа разработки. Например, вы можете испытать концептуальный прототип системы на стадии задумки, и тогда вам потребуется не только определение требований - необходимо будет провести анализ, проектирование, реализацию и тестирование, чтобы завершить создание прототипа. Важность анализа выявляется на этапе проработки.
Рис.8. Стадии разработки RUP
Создатели RUP определяют его как итеративный, архитектурно – ориентированный и управляемый прецедентами процесс разработки программного обеспечения. Для характеристики RUP Пером Кроллом введено понятие «Дух RUP», которое заключено в восьми принципах:
- атаковать риски как можно раньше, пока они сами не перешли в атаку;
- разрабатывать именно то, что нужно заказчику;
- главное внимание – исполняемой программе;
- приспосабливаться к изменениям с самого начала проекта;
- создавать архитектурный каркас как можно раньше;
- разрабатывать систему из компонентов;
- работать как одна команда;
- сделать качество стилем жизни.
Итак, начнем создание модели бизнес-процесса с помощью этой методологии. Модели бизнес-процессов (функциональные модели) описывается в методологии RUP с помощью модели прецедентов. Она отображает системные прецеденты (use cases), системное окружение (действующих лиц или актеров - actors) и связи между прецедентами и актерами (диаграммы прецедентов - use cases diagrams). В нотации UML их чаще называют диаграммами вариантов использования. Основная задача модели прецедентов или диаграмм вариантов использования - представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.
Разработка модели прецедентов начинается с выбора актеров и определения общих принципов функционирования системы. Актеры не являются частью системы - они представляют собой кого-то или что-то, что должно взаимодействовать с системой. Актеры могут:
- только снабжать информацией систему;
- только получать информацию из системы;
- снабжать информацией и получать информацию из системы.
Обычно актеры определяются из описания задачи или путем переговоров с заказчиками и экспертами. Для выявления актеров может быть использована следующая группа вопросов:
1. Кто заинтересован в определенном системном требовании?
2. Какую роль система будет выполнять в организации?
3. Кто получит преимущества от использования системы?
4. Кто будет снабжать систему информацией, использовать информацию и получать информацию от системы?
5. Кто будет осуществлять поддержку и обслуживание системы?
6. Использует ли система внешние ресурсы?
7. Выступает ли какой-либо участник системы в нескольких ролях?
8. Выступают ли различные участники в одной роли?
9. Будет ли новая система взаимодействовать со старой?
Актеры делятся на три основных типа: пользователи системы, другие системы, взаимодействующие с данной, и время.
Приступим к определению актеров в нашей задаче. Покупатель будет осуществлять запрос к системе с целью определения нужной ему номенклатуры товара. Сотрудник отдела продаж будет поддерживать и обслуживать систему. Менеджер по договорам будет снабжать систему информацией о состоянии договора и пользоваться информацией для закрытия договора. Из внешней системы, отвечающей за поступление товара на склад, будет поступать информация о текущем состоянии склада. Система оплаты должна получать информацию об оплате за товар. Кладовщик будет также поддерживать и обслуживать систему (ввод данных о том, что товар отпущен).
Итак, можно выделить следующих актеров:
- покупатель – человек, который желает приобрести крепежные изделия в свободной продаже или по договорам;
- сотрудник отдела продаж – человек, который проверяет по запросу покупателя интересующий его товар, имеющийся в свободной продаже или произведенный по договору, выписывает документы на оплату и заносит информацию об оплате товара;
- менеджер по договорам – человек, который вносит информацию о выполнении договора (по информации о приходе на склад) и после отгрузки товара по договору закрывает договор.
- кладовщик – человек, который осуществляет отпуск товара со склада, делает отметку в журнале об отпуске товара и выписывает сопроводительные документы на товар;
- система склад – внешняя система, выполняющая функцию регистрации прихода товара на склад по разным категориям: договор или свободная продажа.
Следующий элемент модели – прецедент. С помощью прецедентов (use cases) моделируется диалог между актером и системой. Другими словами, они определяют возможности, обеспечиваемые системой для актера. Набор всех прецедентов системы определяет способы ее использования. Можно сказать, что прецедент - это последовательность транзакций, выполняемых системой, которая приводит к значимому результату для определенного актера.
Чтобы выделить прецеденты для системы, можно использовать следующую серию вопросов:
1. Каковы задачи каждого актера?
2. Будет ли актер создавать, хранить, изменять, удалять или получать информацию из системы?
3. Какой прецедент будет создавать, хранить, изменять, удалять или получать эту информацию?
4. Должен ли актер информировать систему о внезапныхизменениях внешней среды?
5. Должен ли актер быть проинформирован об изменениях состояния системы?
6. Какие прецеденты будут поддерживать и обслуживать систему?
7. Могут ли все функциональные требования быть реализованы прецедентами?
На протяжении многих лет велись дискуссии на тему правильности прецедентов. Одной из проблем, с которой сталкиваются проектировщики, является уровень их детализации. Насколько мал или велик он должен быть? Здесь нет однозначного ответа. Рекомендуется использовать следующее правило: прецедент обычно определяет основной элемент функциональности и совершается от начала до конца. Он должен приносить что-то значимое для актера.
Приступим к определению прецедентов нашей системы. Итак, в системе должны обеспечиваться следующие потребности:
- актер покупатель использует систему для запроса товара, для оплаты товара и для получения товара;
- актер сотрудник отдела продаж использует систему для проверки товара на складе (в свободной продаже или произведенного по договору), подготовки документов на оплату и занесения информации об оплате товара;
- актер менеджер по договорам использует систему для внесения информацию о выполнении договора (по информации о приходе на склад) и закрытия договора после отгрузки товара.
- актер кладовщик использует систему для отметки в журнале об отпуске товара и подготовки сопроводительных документов на товар;
- актер склад будет создавать и хранить информацию о поступлении товарной продукции на склад.
На основании перечисленных потребностей можно выделить следующие прецеденты:
- запрос товара;
- оплата товара;
- получение товара;
- проверка товара на складе;
- подготовка документов на оплату;
- занесение информации об оплате;
- занесение информации о выполнении договора;
- закрытие договора;
- отпуск товара;
- подготовка сопроводительных документов;
- создание и хранение информации о состоянии склада.
Поскольку выделено достаточно много прецедентов, их можно сгруппировать и получить следующие прецеденты:
- запрос товара;
- оплата товара;
- получение товара;
- управление информацией об оплате;
- управление информацией о договоре;
- управление отпуском товара;
- управление информацией о состоянии склада.
Последним элементом диаграммы прецедентов являются ассоциативные отношения между актерами и прецедентами. Такой тип связи часто называют коммуникативной ассоциацией (communicate association).
Ассоциативная связь может быть либо двухсторонней (от актера к прецеденту и от прецедента к актеру), либо односторонней (от актера к прецеденту или от прецедента к актеру). Направление связи показывает, кто является ее инициатором (актер или прецедент). Такой тип отношений изображается в виде линии, соединяющей взаимодействующие элементы. Направление связи обозначается стрелками на линии связи.
Существует два типа отношений между прецедентами: включает и дополняет. Различные прецеденты могут иметь одинаково функционирующие фрагменты. Их обычно помещают в отдельный прецедент, чтобы не повторять несколько раз. Отношение включает (include relationship) создается, когда один из прецедентов использует другой. Отношение включаетизображается как отношение зависимости, которое направлено от базового прецедента к используемому.
Отношение дополняет (extend relationship) применяется для отражения:
- дополнительных режимов;
- режимов, которые запускаются только при определенных условиях, например сигнала тревоги;
- альтернативных потоков, которые запускаются по выбору актера.
Исходя из условия задачи, выбранных актеров и прецедентов, можно определить отношения:
- актер покупатель связан со следующими прецедентами: запрос товара, оплата товара и получение товара, при этом он связан с кладовщиком через прецедент получение товара и с сотрудником отдела продаж через прецедент запрос товара;
- актер сотрудник отдела продаж связан с прецедентами: управление информацией об оплате и управление информацией о состоянии склада;
- актер менеджер по договорам связан с прецедентами: управление информацией о состоянии склада и управление информацией о договоре;
- актер кладовщик связан с прецедентом управление отпуском товара;
- актер склад связан с прецедентами управление информацией о состоянии склада и управление отпуском товара;
- прецедент управление информацией о состоянии склада включает в себя отношение управление отпуском товара;
- прецедент управление отпуском товара включает в себя получение товара;
- прецедент управление информацией об оплате включает в себя оплату товара.
Графическое изображение модели прецедентов реализации готовой продукции со склада отображено на рис.9.
Рис.9. Модель прецедентов
Поскольку любая модель строится для лучшего понимания между заказчиком и проектировщиком, то возникает потребность в описании всех графических элементов модели. Это делается с помощью краткого описания актеров, краткого описания прецедентов и описания потока событий для каждого прецедента. Добавим эти описания в нашу модель. При этом напомним, что описание потока событий создается и хранится в любом текстовом файле и связывается с прецедентом.
Поскольку краткое описание каждого актера и прецедента уже имеются, опишем поток событий. Для него в книге Терри Кватрани «Rational Rose 2000 и UML. Визуальное моделирование» предложен следующий шаблон:
Поток событий для прецедента «имя прецедента».
Предусловия.
Главный поток.
Подпотоки (если имеются).
Альтернативные потоки.
В качестве примера описания потока событий рассмотрим поток событий для прецедента «оплата товара».
Поток событий для прецедента «оплата товара».
Предусловия: Этот прецедент может быть выполнен только тогда, когда сотрудник отдела продаж на основании запроса покупателя о наличии интересующего его товара на складе будет убежден, что на складе нужный товар имеется.
Главный поток: сотрудник отдела продаж выписывает документ на оплату, покупатель оплачивает товар, сотрудник отдела продаж убеждается в том, что оплата произведена.
Альтернативный поток:
Товар полностью оплачен покупателем при заключении договора, в этом случае документы на оплату не выписываются, оплата не производится.
Методология RUP также как методология SADT предполагает декомпозицию функций – прецедентов. Это делается с помощью создания дополнительных диаграмм. При этом все необходимые графические изображения с главной диаграммы прецедентов перетаскиваются вручную. На рисунке 10 изображена дополнительная диаграмма прецедента запроса товара.
Рис.10. Дополнительная диаграмма прецедентов
Задания для самостоятельной работы:
1. Закончить моделирование задачи по реализации готовой продукции со склада, дополнив диаграмму описаниями потоков событий для всех прецедентов диаграммы.
2. Дополнить главную диаграмму прецедентов 2-3 дополнительными диаграммами (выбрать соответствующие прецеденты самостоятельно).
3. Создать модель бизнес-процесса выбранной в пункте 2.1. задачи для самостоятельного решения с использованием методологии RUP и инструментария Rational Suite.
