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

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

Данная цель будет достигнута посредством решения следующих задач:

- сформировать четкое понимание основной цели использования диаграммы деятельности;

- объяснить основные принципы построения диаграммы деятельности;

- сформировать представление о применении диаграммы деятельности на различных стадиях разработки ИС.

Аудитория тренинга

Данный тренинг предназначается для аналитиков компании EPAM Systems, которые в ходе своей деятельности сталкивались с задачами создания различных видов UML-диаграмм.

Входные требования

К слушателям предъявляются следующие требования:

- Знание основных этапов разработки ПО

- Понимание роли аналитика при разработке ПО

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

Ожидаемые результаты

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

2. Описание занятия

2.1 Объявление темы занятия

Приветствие.

Мы продолжаем курс занятий посвященных изучению унифицированного языка моделирования (UML), тема сегодняшнего занятия «Диаграмма деятельности» (1 слайд).

2.2 Постановка цели

Многие из вас уже имеют опыт создания моделей с использованием UML, в том числе и диаграммы деятельности (activity). Поэтому основной целью данного занятия является определить назначение диаграмм деятельности и возможности применения при разработке ИС (слайд 2).

Для достижения нашей цели нам потребуется рассмотреть следующие вопросы:

- Для чего применяется диаграмма деятельности?

- Какие основные термины и понятия связаны с данным типом UML диаграммы?

- В каких случаях следует применять диаграмму деятельности в ходе проектирования и разработки информационной системы

2.3 Обращение к материалу предыдущего занятия

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

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

Вспомним основные положения задачи, поставленной перед нами заказчиком (слайд 3).

Итак, Заказчик имеет:

- Off-line магазин.

- Склад товаров.

- Внутреннюю учетную систему, в которой есть данные о наличии товара, о поступлении оплаты.

Для увеличения объема продаж Заказчик хочет:

- Открыть интернет-магазин по продаже имеющихся у него товаров.

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

Давайте вспомним, какие варианты использования были выявлены для нашего интернет-магазина? (Записать на доске варианты использования верхнего уровня: «Управление заказами», «Прием и выполнение заказов»).

Итак, у нас есть два актера: «Покупатель» и «Менеджер».

Для покупателя мы можем выделить следующие варианты использования:

- Управление заказами:

o Выбрать товар;

o Оформить заказ;

o Оплатить заказ.

Для продавца мы можем выделить варианты использования:

- Прием и выполнение заказа:

o Проверить наличие товара;

o Сформировать счет на оплату;

o Оформить доставку.

2.4 Основная часть

Основные понятия и терминология

В качестве графического представления для выделения основных функций Системы мы применяем диаграмму вариантов использования (use case).

Таким образом, диаграмма вариантов использования дает нам представление ЧТО должна делать Система. На вопрос КАК мы можем ответить, используя диаграмму активности (слайд 5).

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

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

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

Покупатель выбирает товар из каталога, оформляет заказ, в результате этой деятельности формируется объект «Заказ». Далее Менеджер проверяет наличие товара с помощью стороннего приложения и фиксирует результат. Если товар в наличие, Менеджер формирует счет и готовит сопроводительные документы для отправки товара. В результате деятельности «Оформить счет» создается объект «Счет», который передается покупателю. Покупатель оплачивает счет и получает товар.

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

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

Деятельность выполняется, только тогда, когда готовы все его «входы», после выполнения, деятельность передает управление и(или) данные на свои «выходы». Саму диаграмму деятельности принято располагать таким образом, чтобы действия следовали слева направо или сверху вниз.

Чтобы указать, где именно находится процесс, используется абстрактная точка «маркер» (или «токен»). Визуально на диаграмме маркер не показывается, данное понятие вводится только для удобства описания динамического процесса.

Переход маркера осуществляется между узлами. Маркер может не содержать никакой дополнительной информации (пустой маркер) и тогда он называется маркером управления (control flow token) или же может содержать ссылку на объект или структуру данных, и тогда маркер называется маркером данных (data flow token).

Для создания диаграммы деятельности используются следующие узлы (слайд 6):

- Узел управления (control node) - это абстрактный узел действия, которое координирует потоки действий.

- Начальный узел деятельности (или начальное состояние деятельности) (activity initial node) является узлом управления, в котором начинается поток (или потоки) при вызове данной деятельности извне.

- Конечный узел деятельности (или конечное состояние деятельности) (activity final node) является узлом управления, который останавливает (stop) все потоки данной диаграммы деятельности. На диаграмме может быть более одного конечного узла.

- Конечный узел потока (или конечное состояние потока) (flow final node) является узлом управления, который завершает данный поток. На другие потоки и деятельность данной диаграммы это не влияет.

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

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

Узел решения предназначен для определения правила ветвления и различных вариантов дальнейшего развития сценария.

В точку ветвления входит ровно один переход, а выходит - два или более. Для каждого исходящего перехода задается булевское выражение, которое вычисляется только один раз при входе в точку ветвления. Ни для каких двух исходящих переходов эти сторожевые условия не должны одновременно принимать значение "истина", иначе поток управления окажется неоднозначным. Желательно чтобы условия покрывали все возможные варианты, иначе поток остановится.

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

Далее следует обратить внимание на такой элемент, как узел объединение. Узел объединения имеет два и более входящих узла и один исходящий.

Узлы решения объединения аналогичны логическому выражению «строгое или», т.е. для узла объединения - только при выполнении того или иного действия осуществляется переход к следующему узлу управления. Соответственно для узла решения - только при выполнении того или иного условия становится доступна возможность перехода к одному из следующих действий.

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

Точка разделения обеспечивает разделение одного потока на несколько параллельных потоков:

- входит ровно один поток;

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

Точка слияния обеспечивает синхронизацию нескольких параллельных потоков.

- входят два или более потока, причем эти потоки выполняются параллельно;

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

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

Передача сигнала (send signal action) - действие, которое на основе своих входов создает экземпляр сигнала и передает его внешней Системе.

Прием события (receive event action) - действие, которое ожидает некоторого события, принимает и обрабатывает полученное сообщение.

На данном примере остановимся подробно. На диаграмме представлено взаимодействие двух независимых Систем: «Учетная система» и «Веб-магазин».

1. Результатом действия по приему банковской выписки и разнесению оплаты является входящий сигнал для ИС «Веб-магазин» сообщающей об оплате товара.

2. Соответственно при получении входящего сигнала в ИС «Веб-магазин» фиксируется факт оплаты, который инициализирует действие «Разрешить отгрузку».

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

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

Центральный буфер - объект, который управляет потоками между множественными источниками и приемниками. На диаграмме центральный буфер представляется в виде объекта со стереотипом <<centralBuffer>>.

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

На рисунке представлена диаграмма, которая отражает сценарий формирования списка сравнения товаров:

1. В центральный буфер поступает информация о товаре, выбранном для сравнения пользователем из каталога товаров.

2. Данные товара хранятся в центральном буфере какой-то промежуток времени.

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

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

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

Частный случай Центрального буфера - Хранилище данных (слайд 11).

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

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

Далее следует подробно рассмотреть разбиение деятельности на разделы (слайд 12).

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

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

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

В UML 2 принято правило применять горизонтальное расположение дорожек для отображения модели бизнес-процесса.

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

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

Спецификация UML дает несколько способов представления декомпозиции деятельности на диаграмме. Мы можем использовать обозначение под-деятельности (subactivity state), где указываем:

- наименование деятельности;

- предусловие и постусловие

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

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

При необходимости описание последовательности действий для под-деятельности может быть размещено непосредственно на основной диаграмме. Для этого описание под-деятельности размещается в отдельный фрейм.

При таком способе декомпозиции мы можем указать:

- предусловия и постусловия;

- входные и выходные параметры (объекты);

- внутреннее устройство деятельности.

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

Диаграмма деятельности - мощный инструмент, который интенсивно используется при создании ИС (слайд 16).

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

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

Цель концептуального описания - показать целостную картину бизнес-процессов предметной области (слайд 17).

Для описания концепции процесса совершения покупки через интернет-магазин можно использовать диаграмму действия в стиле IDEF0, где указываются следующие параметры:

- входные и выходные данные;

- объекты, управляющие процессом (в нашем случае это каталог товаров и прайс-лист);

- используемые ресурсы (в нашем примере это Покупатель и Менеджер).

На слайде показаны стандартные UML-объекты «действие» и «объект», но со специальными стереотипами:

- Для действия - стереотип <<process>>

- Для объекта - стереотип <<information>>, <<resourse>>

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

Диаграмма деятельности данного вида хорошо отражает:

- последовательность действий;

- события, инициирующие действия или являющиеся конечным результатом;

- условия расширения сценария;

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

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

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

Также диаграмма деятельности целесообразна для описания требований на уровне взаимодействия компонентов Системы (слайд 19). Целевой аудиторией в данном случае будет являться команда разработчиков.

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

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

Если на диаграмме необходимо показать последовательность действий, вызываемых сторонними Системами, то целесообразно добавить элементы получения и приема сигналов. В нашем примере для того чтобы началась проверка данных пользователя, необходимо получение переменных «логин» и «пароль».

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

If (логин/пароль совпадают)

{Переход к следующему действию}

Else {сообщение об ошибке}

2.5 Закрепление пройденного материала

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

На уровне описания бизнес-процесса нам достаточно использовать такие элементы диаграммы как:

- разделительные дорожки;

- узлы управления;

- начальный и конечный узел

- узлы расширения и объединения;

- узлы разделения и соединения.

На уровне детального описания последовательности действий внутри ИС целесообразно дополнить диаграмму такими элементами как:

- объект передачи сигнала и приема события;

- объект центральный буфер и его разновидности - хранилища данных.

2.6 Контрольный пример

Постановка проблемы от заказчика:

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

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

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

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

Заказчик (директор завода) хочет оптимизировать временные затраты на ремонт оборудования путем автоматизации процесса обработки заявок.

Задание

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

- описать процесс организации ремонта оборудования производственного цеха;

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

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

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

Список рекомендуемой литературы

1. Г. Буч, Д. Рамбо, А. Джекобсон. “Язык UML Руководство пользователя”

2. Леоненков А. “Самоучитель UML”

3. Martin Fowler. “UML Distilled: A Brief Guide to the Standard Object Modeling Language”

Размещено на Allbest.ru