Определение вариантов использования системы с помощью rational rose и uml
Среда, 23 Март 2011 8:45Для создания моделей анализа и проектирования объектно-ориентированных программных систем используют языки визуального моделирования. Появившись сравнительно недавно, в период с 1989 по 1997 год, эти языки уже имеют представительную историю развития.
В настоящее время различают три поколения языков визуального моделирования. И если первое поколение образовали 10 языков, то численность второго поколения уже превысила 50 языков. Наиболее популярными из них были язык Буча (G. Booch), язык Рамбо (J. Rumbaugh) и язык Джекобсона (I. Jacobson). Каждый язык вводил свои выразительные средства, ориентировался на собственный синтаксис и семантику. В результате разработчики (и пользователи этих языков) перестали понимать друг друга. Возникла острая необходимость унификации языков.
Идея унификации привела к появлению языков 3-го поколения. В качестве стандартного языка был принят унифицированный язык моделирования (Unified Modeling Language— UML). UML представляет собой успешную попытку стандартизации составляющих процесса анализа и проектирования – семантических моделей, синтаксической нотации и диаграмм. UML в качестве стандарта языка моделирования был одобрен и утвержден Object Management Group (OMG) в ноябре 1997 года. На сегодняшний день существует версия 1.4 стандарта и продолжается работа над версией UML 2.O.
Для успешной разработки программной системы должны использоваться три основных компонента – система обозначений (нотация, язык), процесс и инструмент. Можно изучить язык, но, не зная, как его применять (т.е. не владея процессом), легко зайти в тупик. Если в вашем распоряжении имеется замечательный процесс, но вы не умеете с ним обращаться (т.е. не знаете системы обозначений), работа также обречена на неудачу. Наконец, не приходится ожидать ничего хорошего и в том случае, когда в отсутствие подходящего инструмента вы не в состоянии зафиксировать результаты своей работы.
Процесс проектирования программной системы обычно является многоэтапным и итеративным. Одной из наиболее современных методологий управления таким процессом является Rational Unified Process, содержащая исчерпывающий набор правил, охватывающих технологические и организационные аспекты жизненного цикла создания системы. Процесс, описываемый с помощью Rational Unified Process, структурируется по двум измерениям:
• время — расчленение жизненного цикла системы на фазы и итерации;
• компоненты — выявление множеств сущностей с ясно определенными параметрами деятельности.
Для достижения успеха проекта следует учитывать значения по обоим измерениям. Структура проекта, связанная с осью времени, включает следующие фазы:
• начало — определение целей проекта и их обоснование;
• планирование — обдумывание необходимых действий и уточнение потребности в ресурсах; спецификация условий и проектирование архитектуры;
• создание — конструирование продукта в виде серии последовательных итераций;
• внедрение — доставка продукта потребителю (установка, настройка и обучение пользователей).
Упорядочение структуры проекта по множеству компонентов процесса предполагает осуществление следующих действий:
• бизнес-моделирование — определение свойств системы с учетом пожеланий потребителя;
• уточнение требований — сужение множества функций и качеств системы до необходимого и достаточного уровня;
• анализ и дизайн — описание вариантов и способов реализации;
• реализация — создание программного кода;
• тестирование — проверка корректности функционирования;
• передача в эксплуатацию и обучение пользователей.
Ни одна из методологий разработки программ не обходится без некоторого инструмента. Семейство продуктов Rational Rose обеспечивает разработчика полным набором инструментов визуального моделирования, позволяющим получать высоконадежные и эффективные решения, удовлетворяющие требованиям современного бизнеса и пригодные для использования в распределенных средах “клиент/сервер” и системах реального времени. Средства Rational Rose основаны на едином стандарте и делают моделирование доступным как для лиц, далеких от компьютерных наук, но желающих оптимизировать бизнес-процессы в близких им предметных областях, так и для профессионалов, нуждающихся в инструментах моделирования логики программных приложений.
Процесс регистрации студентов, желающих прослушать те или иные курсы (в американских университетах), и распределения последних между профессорами зачастую весьма непрост и продолжителен.
После принятия профессорами решений о том, какие курсы они собираются преподавать на протяжении очередного семестра (обычно не более четырех), служащий деканата вводит полученную информацию в компьютерную систему и распечатывает отчет, содержащий сведения о распределении педагогической нагрузки. Соответствующий каталог курсов также публикуется и передается студентам.
Каждый студент заполняет многостраничную форму, отмечает выбранные курсы и возвращает форму в деканат. (Типичный студент в течение семестра посещает занятия по четырем курсам.) Данные из форм, полученных от студентов, также поступают в систему. Как только вся информация введена, выполняется процедура формирования учебного плана. В большинстве случаев первый вариант выбора, предъявленный студентом, оказывается и окончательным; если же возникают разногласия или несоответствия, студент приглашается в деканат, где его требования и предпочтения уточняются и заново учитываются. По завершении “увязки и утряски” студентам рассылаются “твердые” копии расписаний занятий. На весь процесс обычно уходит неделя, хотя в отдельных случаях он может растянуться и на две.
После окончания регистрации профессорам передаются реестры студентов по каждому курсу.
В начале каждого семестра студенты вправе запросить каталог, содержащий список курсов, которые предлагаются для изучения на протяжении этого семестра. Информация о каждом курсе, включающая его аннотацию, необходимые предварительные условия и фамилию профессора, помогает студентам принять осмысленные решения.
Разрабатываемая система обязана позволять студенту выбирать четыре основных курса. Аудитория каждого курса должна насчитывать не более десяти и не менее трех студентов. Курс, на который зарегистрировалось менее трех студентов, аннулируется. Поэтому каждый студент может указать два дополнительных курса на тот случай, если какие-либо из выбранных им основных курсов пользуются чрезмерной или недостаточной популярностью. По окончании регистрации система учета курсов отсылает соответствующую информацию во внешнюю систему учета студентов.
Каждому профессору предоставляется возможность доступа к системе с целью выбора курсов, которые он хотел бы преподавать, и просмотра информации о том, кто из студентов предпочел эти курсы.
Семестру предшествует период времени, в течение которого студенты, обращаясь к системе, способны изменять расписания своих занятий путем добавления или удаления тех или иных курсов.
Характеристики поведения разрабатываемой системы фиксируются и документируются средствами визуальной модели, которая отображает функции (варианты использования— use cases) продукта, представляет окружение системы (множество активных субъектов— actors) и определяет связи между вариантами использования и активными субъектами (диаграммы вариантов использования— use case diagrams). Наиболее важной является коммуникативная составляющая модели, позволяющая группам разработчиков, заказчиков и конечных пользователей, обсуждающим свойства системы, говорить на одном языке.
Основы модели закладываются уже на начальной фазе процесса разработки, когда идентифицируются основные активные субъекты и варианты использования системы, а позже, на этапе планирования, модель развивается и пополняется за счет уточнения существующих и добавления новых элементов.
Каждый из внешних активных субъектов (actors) отождествляется с чем-то или с кем-то, взаимодействующим с системой. Активный субъект способен выполнять различные функции:
• только вводить данные в систему;
• только получать информацию из системы;
• взаимодействовать с системой в обоих направлениях.
Множество активных субъектов обычно обнаруживается уже в результате анализа постановки задачи или в ходе обсуждения проблемы с потребителями и экспертами в предметной области. Помощь в отыскании активных субъектов окажут ответы на следующие вопросы.
• Кто именно заинтересован в выполнении определенного требования?
• В каком подразделении организации должна использоваться система?
• Кто получит преимущества от внедрения системы в эксплуатацию?
• Кто будет поставлять системе те или иные данные, обращаться к ним и нести ответственность за их обновление и удаление?
• Кому предстоит выполнять обязанности администратора системы?
• Должна ли система использовать внешние ресурсы?
• Способен ли один и тот же активный субъект играть несколько различных ролей?
• Разрешено ли нескольким субъектам осуществлять в системе одинаковые функции?
• Будет ли система использоваться совместно с какими-либо существующими унаследованными системами?
В языке UML активный субъект представляется символом, показанным на рис.1. Процедура определения активных субъектов системы заслуживает особого внимания и обычно отличается итеративным характером — первый вариант списка субъектов редко бывает окончательным. Например, являются ли ранее зарегистрированный и новый студенты различными активными субъектами? Допустим, что изначально ответ на этот вопрос утвердителен. Далее следовало бы выяснить, каким именно образом субъекты-”студенты” обязаны взаимодействовать с системой. Если “новый” студент выполняет иные функции, нежели студент, уже “известный” системе, речь, разумеется, должна вестись о различных активных субъектах. Если же, напротив, процесс использования системы студентами единообразен, все они отображаются в модели в виде одного и того же активного субъекта.
Внимательно анализируя роли сущностей, взаимодействующих с системой, со временем нетрудно прийти к адекватному множеству активных субъектов. В контексте системы учета университетских курсов могут быть получены следующие ответы на поставленные выше вопросы.
• Каждому студенту полагается выбрать курсы для изучения.
• Профессорам следует распределить между собой курсы, которые должны быть прочитаны в течение семестра.
• Служащие деканата обязаны создать каталог курсов и составить индивидуальные расписания работы студентов.
• Ответственность за администрирование базы данных со сведениями о профессорах, курсах и студентах возлагается на деканат.
• Система учета курсов должна передавать информацию во внешнюю систему учета студентов.
На основании перечисленных ответов легко выделить следующие категории активных субъектов, взаимодействующих с системой учета университетских курсов “студент”, “профессор”, “сотрудник деканата” и “система учета студентов”.
2.4. Создание и документирование активных субъектов
Для создания активного субъекта в Rational Rose необходимо выполнить следующую последовательность действий.
1. Расположить курсор мыши над элементом Use Case View окна браузера (Browser) и щелкнуть правой кнопкой, чтобы активизировать контекстное меню.
2. Выбрать элемент меню New=>Actor; дерево, отображаемое в окне Browser, пополнится элементом NewClass, соответствующим новому активному субъекту.
3. Выбрать элемент NewClass и изменить его название, введя требуемое имя активного субъекта.
Перечень активных субъектов системы учета университетских курсов, отображаемый в окне Browser, показан на рис. 2.
В модель следует включить краткое описание каждого активного субъекта, которое должно определять его роль в процессе использования системы. Описания активных субъектов системы учета университетских курсов могут выглядеть следующим образом:
• Студент — лицо, зарегистрированное в качестве слушателя университетских курсов;
• Профессор – лицо, наделенное полномочиями вести занятия в университете;
• Сотрудник деканата – служащий, ответственный за функционирование системы учета университетских курсов;
• Система учета студентов — внешняя система, обеспечивающая хранение информации о студентах.
Для документирования активного субъекта в Rational Rose необходимо выполнить следующую последовательность действий.
1. Если окно документирования (Documentation) не отображается, открыть его, активизировав элемент меню View => Documentation.
2. В окне Browser выбрать элемент дерева, соответствующий требуемому активному субъекту.
3. Разместить курсор в окне Documentation и ввести текстовое описание активного субъекта.
Окно Documentation с текстом, документирующим активный субъект “студент”, показано на рис. 3.
Варианты использования (use cases) позволяют моделировать диалог между активным субъектом и системой и отображают функции последней, предоставляемые в распоряжение субъекта. Набор вариантов использования системы охватывает множество заслуживающих внимания способов ее применения. Говоря формально, вариант использования — это последовательность выполняемых системой транзакций, которая приводит к получению некоего ощутимого результата, в котором заинтересован определенный активный субъект.
Помощь в выборе вариантов использования системы окажут ответы на следующие вопросы.
• Какие задачи решает каждый активный субъект?
• Способен ли тот или иной субъект создавать, сохранять, изменять, удалять или считывать фрагменты данных в контексте системы?
• Какие варианты использования гарантируют выполнение указанных выше функций обработки данных?
• Должны ли активные субъекты сообщать системе о каких- либо непредвиденных внешних обстоятельствах?
• Имеет ли субъект право получать информацию об определенных событиях, происходящих в системе?
• Какие варианты использования связаны с поддержкой и администрированием системы?
• Удовлетворяются ли вариантами использования все функциональные требования, предъявляемые к системе?
В языке UML вариант использования представляется символом, показанным на рис. 4. Для определения вариантов использования имеется следующее правило:
“Вариант использования обычно охватывает изрядную долю функций, выполняемых системой от начала и до конца, и должен представлять для того или иного активного субъекта определенную ценность”.
Система учета университетских курсов обязана удовлетворять следующим требованиям.
• Активный субъект “студент” регистрирует курсы, которые он намеревается прослушать.
• По завершении регистрации информация о студенте передается во внешнюю систему учета студентов.
• Субъект “профессор” использует систему для выбора курсов, которые он хотел бы преподавать в течение семестра, и для получения реестров студентов по каждому курсу.
• Субъект “сотрудник деканата” несет ответственность за ведение и опубликование каталога курсов на семестр и сохранение всей информации о расписаниях, студентах и профессорах.
Варианты использования системы, идентифицированные на основе названных требований, перечислены ниже:
• регистрация курсов студентом;
• выбор курсов профессором;
• получение реестра студентов по курсу;
• сохранение информации о курсах;
• сохранение информации о профессорах;
• сохранение информации о студентах;
• ведение каталога курсов.
Для создания варианта использования в Rational Rose необходимо выполнить следующую последовательность действий.
1. Расположить курсор мыши над элементом Use Case View окна Browser и щелкнуть правой кнопкой, чтобы активизировать контекстное меню.
2. Выбрать элемент меню New=>Use Case; дерево, отображаемое в окне Browser, пополнится элементом NewClass, соответствующим новому варианту использования.
3. Выбрать элемент NewClass и изменить его название, введя требуемое имя варианта использования.
Перечень вариантов использования системы учета университетских курсов, отображаемый в окне Browser, показан на рис. 5.
Описание варианта использования, выраженное в виде нескольких предложений, должно содержать определение соответствующих функций системы. Варианты использования документируются на начальной фазе процесса разработки по мере их выявления и обоснования.
Вот как может выглядеть краткое описание варианта использования “регистрация курсов студентом”.
“Вариант использования инициируется активным субъектом Студент и предлагает возможности создания, просмотра и/или модификации индивидуального расписания на указанный семестр.”
Для документирования активного субъекта в Rational Rose необходимо выполнить следующую последовательность действий.
1. Если окно документирования (Documentation) не отображается, открыть его, активизировав элемент меню View=>Documentation.
2. В окне Browser выбрать элемент дерева, соответствующий требуемому варианту использования.
3. Разместить курсор в окне Documentation и ввести текстовое описание варианта использования.
Окно Documentation с текстом, документирующим вариант использования “регистрация курсов студентом”, показано на рис. 6.
С каждым вариантом использования связан определенный поток событий, происходящих по мере выполнения соответствующих функций системы. При описании потока событий определяется, что необходимо осуществить, и игнорируются аспекты того, как это делается. Другими словами, события воспроизводятся средствами языка предметной области, а не в терминах практической реализации функций. Схема потока событий должна содержать ответы на следующие вопросы.
• Как и когда вариант использования инициируется и завершается?
• Каким образом активные субъекты взаимодействуют с системой?
• Какие данные затрагиваются вариантом использования?
• Что представляет собой нормальная последовательность событий, предусматриваемых вариантом использования?
• Существуют ли альтернативные потоки событий для нештатных ситуаций?
Потоки событий обычно документируются на фазе планирования по мере потребности. Вначале дается краткое описание действий, необходимых для обеспечения штатного функционирования системы. Далее информация изменяется и уточняется, а в завершение пополняется сведениями об исключительных ситуациях вида “что произойдет, если…”.
Описание потока событий для варианта использования системы содержится в документе вида Use Case Specification (“спецификация варианта использования”). Для создания подобного документа в каждом проекте должен применяться некий стандартный шаблон. Воспользуемся шаблоном, заимствованным из регламента Rational Unified Process.
1.0.Наименование варианта использования
1.1.Краткое описание
2.0.Потоки событий
2.1.Основной поток
2.2.Альтернативные потоки
2.2.x <Альтернативный поток х>
3.0. Специальные требования
3.x <Специальное требование х>
4.0. Предусловия
4.x. <Предусловие х>
5.0. Постусловия
5.x <Постусловие х>
6.0. Дополнительные замечания
6.x Дополнительное замечание х>
Ниже приведен полный текст спецификации одного из вариантов использования системы учета университетских курсов.
Спецификация варианта использования “выбор курсов профессором”
1.0. Наименование варианта использования: “выбор курсов профессором”.
1.1. Краткое описание: вариант использования инициируется активным субъектом “профессор” и предлагает возможности выбора до четырех курсов, которые должны вестись в определенном семестре.
2.0. Потоки событий
2.1. Основной поток
Функции варианта использования начинают выполняться с регистрацией субъекта “профессор” в системе и заданием его индивидуального пароля. Система проверяет пароль на достоверность (если пароль неверен, активизируется альтернативный поток 2.2.1), позволяет профессору выбрать текущий либо будущий семестр (при неправильном задании семестра выполняется поток 2.2.2) и предлагает указать одну из следующих опций: “добавление”, “удаление”, “просмотр”, “печать”и “выход”.
Если выбрана опция “добавление”, система отображает окно с полями ввода наименования и номера курса. Профессор вводит наименование и номер курса (при задании неверной информации выполняется поток 2.2.3). Система воспроизводит текст с предложением на ведение курса (если наименование курса не может быть отображено, выполняется поток 2.2.4), и профессор подтверждает свой выбор. Система связывает текущий субъект “профессор” с указанным курсом (если связь не может быть создана, выполняется поток 2.2.5). Вариант использования активизируется с начала.
Если выбрана опция “удаление”, система отображает окно с полями ввода наименования и номера ранее предложенного профессором курса. Профессор вводит наименование и номер курса (при задании неверной информации выполняется поток 2.2.3). Система удаляет связь между курсом и текущим субъектом “профессор” (если связь удалить нельзя, выполняется поток 2.2.6). Вариант использования активизируется сначала.
Если выбрана опция “просмотр”, система извлекает и отображает следующую информацию обо всех предложениях на ведение курсов, поданных текущим субъектом “профессор” (если данные получить нельзя, выполняется поток 2.2.7): наименование и номер курса, номер предложения, а также время и место проведения занятий. По завершении просмотра вариант использования активизируется сначала.
Если выбрана опция “печать”, система посылает на принтер расписание занятий, проводимых текущим субъектом “профессор” (если расписание не может быть распечатано, выполняется поток 2.2.8). Вариант использования активизируется сначала.
Если выбрана опция “выход”, выполнение функций, предусмотренных вариантом использования системы, завершается.
2.2. Альтернативные потоки
2.2.1. Неверный пароль: введен неверный пароль; субъекту предоставляется возможность повторить ввод или завершить вариант использования.
2.2.2. Неверный семестр: система сообщает субъекту о неверном вводе информации о семестре и предлагает повторить операцию или завершить вариант использования.
2.2.3. Неверная комбинация наименования и номера курса: система сообщает субъекту о неверном вводе информации о наименовании и номере курса и предлагает повторить операцию или завершить вариант использования.
2.2.4. Ошибка воспроизведения текста с предложением на ведение курса: система сообщает субъекту о том, что в данный момент запрошенный курс недоступен; вариант использования активизируется сначала.
2.2.5. Ошибка создания связи между субъектом и выбранным им курсом: информация сохранена, система создаст связь позже; вариант использования активизируется сначала.
2.2.6. Ошибка удаления связи между субъектом и выбранным им курсом: информация сохранена, система удалит связь позже; вариант использования активизируется сначала.
2.2.7. Ошибка извлечения данных о предложениях на ведение курсов: система сообщает субъекту о том, что в данный момент информация недоступна; вариант использования активизируется сначала.
2.2.8. Ошибка печати расписания занятий: система сообщает субъекту о том, что в данный момент функция недоступна; вариант использования активизируется сначала.
3.0. Специальные требования: специальные требования не определены.
4.0. Предусловия
4.1. Перед активизацией варианта использования должен быть выполнен поток варианта использования “сохранение информации о курсах”.
5.0. Постусловия: постусловия не определены.
6.0. Дополнительные замечания: дополнительных замечаний нет.
Текст спецификации сохраняется в документе, внешнем по отношению к инструментальной системе Rational Rose (например, в документе редактора Word), и ассоциируется с вариантом использования посредством связи.
Для соединения документа спецификации потока событий с вариантом использования необходимо выполнить следующую последовательность действий.
1. Расположить курсор мыши над элементом окна Browser, соответствующим требуемому варианту использования, и щелкнуть правой кнопкой, чтобы активизировать контекстное меню.
2. Выбрать элемент меню Open Specification.
3. Перейти на вкладку Files диалогового окна Use Case Specification.
4. Расположить курсор мыши в пределах области окна и щелкнуть правой кнопкой, чтобы активизировать контекстное меню.
5. Выбрать элемент меню Insert File.
6. С помощью средств навигации диалогового окна Открытие файла проследовать к нужной папке и выбрать требуемый файл.
7. Щелкнуть на кнопке Открыть.
8. Щелкнуть на кнопке ОК окна Use Case Specification.
Результат связывания документа спецификации с вариантом использования отображается в окне Browser. Диалоговое окно Use Case Specification с выбранным документом спецификации приведено на рис. 7.
Диаграмма вариантов использования (use case diagram) — это графическое представление подмножеств активных субъектов, взаимодействующих с системой посредством тех или иных вариантов ее использования. При проектировании любой системы обычно конструируется основная диаграмма (Main Use Case Diagram), представляющая множество пользователей (активных субъектов) и ключевые функции (варианты использования) системы. При необходимости создаются и дополнительные диаграммы. Вот некоторые типичные примеры:
• диаграмма, представляющая все варианты использования, инициируемые определенным активным субъектом;
• диаграмма, изображающая варианты использования, подлежащие последовательной реализации;
• диаграмма, описывающая некоторый вариант использования и все его связи.
Для создания основной диаграммы вариантов использования необходимо выполнить следующую последовательность действий.
1. Двойным щелчком на элементе Main поддерева Use Case View, отображаемого в окне Browser, открыть окно основной диаграммы вариантов использования.
2. В окне Browser выбрать элемент, соответствующий требуемому активному субъекту, и перетащить его в окно диаграммы.
3. Повторить действие, указанное в п. 2, для всех активных субъектов, подлежащих включению в диаграмму.
4. В окне Browser выбрать элемент, соответствующий требуемому варианту использования, и перетащить его в окно диаграммы.
5. Повторить действие, указанное в п. 4, для всех вариантов использования, подлежащих включению в диаграмму.
Как создать коммуникативную ассоциацию
1. Щелкнуть на пиктограмме Association или Unidirectional Association панели инструментов Diagram.
2. В окне диаграммы щелкнуть на символе активного субъекта и, не отпуская кнопку мыши, построить линию связи, направленную к символу соответствующего варианта использования.
Чтобы снабдить ассоциацию необязательной меткой стереотипа «communicate», надлежит выполнить следующие действия.
1. В окне диаграммы дважды щелкнуть на линии, представляющей ассоциацию, чтобы открыть диалоговое окно Association Specification.
2. Щелкнуть на кнопке со стрелкой в правой части поля Stereotype и выбрать в раскрывающемся списке опцию communicate.
3. Закрыть окно Association Specification щелчком на кнопке ОК.
Как создать включающую связь
1. Щелкнуть на пиктограмме Dependency панели инструментов Diagram.
2. В окне диаграммы щелкнуть на символе базового варианта использования и, не отпуская кнопку мыши, построить линию связи, направленную к символу соответствующего “включаемого” варианта использования.
3. Дважды щелкнуть на линии, представляющей связь, чтобы открыть диалоговое окно Dependency Specification.
4. Щелкнуть на кнопке со стрелкой в правой части поля Stereotype и выбрать в раскрывающемся списке опцию include.
5. Закрыть окно Dependency Specification щелчком на кнопке ОК.
Основная диаграмма вариантов использования системы учета университетских курсов изображена на рис. 8.
Как создать дополнительную диаграмму вариантов использования
1. Расположить курсор мыши над элементом Use Case View окна Browser и щелкнуть правой кнопкой, чтобы активизировать контекстное меню.
2. Выбрать элемент меню New=>Use Case Diagram; дерево, отображаемое в окне Browser, пополнится элементом NewDiagram, соответствующим новой диаграмме вариантов использования.
3. Выбрать элемент NewDiagram и изменить его название, введя требуемое имя диаграммы.
4. Двойным щелчком на элементе открыть окно дополнительной диаграммы вариантов использования и включить в нее требуемые активные субъекты, варианты использования и связи.
Пример дополнительной диаграммы вариантов использования системы учета университетских курсов изображена на рис. 9. В ней с помощью включающей связи указано соединение с подмножеством функций, вынесенных в отдельный вариант использования.
2.8. Диаграммы действий
На рассматриваемой стадии процесса разработки системы нередко создаются и диаграммы действий (activities diagrams), отображающие динамические характеристики системы. Диаграммы действий воспроизводят поток функций управления, показывают, какие ветви процесса могут выполняться параллельно, и определяют альтернативные пути достижения целей. Диаграммы действий, конструируемые на начальных фазах жизненного цикла системы, представляют потоки, которые охватывают несколько вариантов использования или протекают на уровне определенного варианта. Позже, по мере детализации проекта, создаются и диаграммы действий, иллюстрирующие особенности реализации отдельных операций.
Элементами диаграммы действий служат собственно действия (activities), переходы (transitions) от одного действия к другому, точки принятия решений (decision points) и полосы синхронизации (synchronization bars). В UML для описания действия, перехода, точки принятия решения и полосы синхронизации применяются соответственно прямоугольник с округленными углами, направленная стрелка, ромб и отрезок утолщенной прямой (горизонтальный или вертикальный). Все эти символы приведены на рис. 10.
Для создания диаграммы действий необходимо выполнить приведенную ниже последовательность действий.
1. Расположить курсор мыши над элементом Use Case View окна Browser и щелкнуть правой кнопкой, чтобы активизировать контекстное меню.
2. Выбрать элемент меню New=>Activity Diagram; дерево, отображаемое в окне Browser, пополнится элементом NewDiagram, соответствующим новой диаграмме действий.
3. Выбрать элемент NewDiagram и изменить его название, введя требуемое имя диаграммы.
4. Двойным щелчком на элементе открыть окно диаграммы действий.
Окно Browser с элементом, представляющим вновь созданную диаграмму действий, может выглядеть так, как показано на рис. 11.
Действия
Действие (activity) описывает некоторый фрагмент поведения системы в контексте потока функций управления.
Как создать действие
1. Щелкнуть на пиктограмме Activity панели инструментов Diagram.
2. Включить элемент действия в диаграмму, щелкнув в соответствующем месте рабочей области открытого окна диаграммы действий.
3.
Выбрать элемент и ввести наименование действия.
Переходы
Элемент перехода (transition) применяется в диаграмме действий с целью обозначения направления передачи управления от одного действия к другому. Функция перехода обычно активизируется по завершении действия-источника.
Как создать переход
1. Щелкнуть на пиктограмме State Transition панели инструментов Diagram.
2. В окне диаграммы щелкнуть на символе действия-источника и, не отпуская кнопку мыши, построить линию перехода, направленную к символу соответствующего действия-приемника.
Примеры действий и переходов изображены на рис. 12.
Точки принятия решений
В процессе моделирования поведения системы зачастую необходимо определить, в какие моменты и в каких точках поток управления претерпевает ветвление в зависимости от принимаемых системой или пользователем решений. Переход, который берет начало в точке принятия решения (decision point), содержит контролируемое условие (guard condition), определяющее направление ветвления. Точки принятия решений совместно с соответствующими контролируемыми условиями позволяют наглядно продемонстрировать возможные альтернативные пути протекания процесса функционирования системы.
Как создать точку принятия решения
1. Щелкнуть на пиктограмме Decision панели инструментов Diagram.
2. Включить элемент точки принятия решения в диаграмму действий, щелкнув в соответствующем месте рабочей области открытого окна диаграммы.
3. Выбрать элемент и ввести наименование точки принятия решения.
4. Щелкнуть на пиктограмме State Transition панели инструментов Diagram.
5. В окне диаграммы щелкнуть на символе действия-источника и, не отпуская кнопку мыши, построить линию перехода, направленную к символу соответствующей точки принятия решения.
Как создать контролируемый переход
1. Щелкнуть на пиктограмме State Transition панели инструментов Diagram.
2. В окне диаграммы щелкнуть на символе точки принятия решения и, не отпуская кнопку мыши, построить линию перехода, направленную к символу соответствующего действия-приемника. (Система Rational Rose способна поместить новый элемент перехода поверх существующего; чтобы разделить элементы, достаточно выбрать один из них и, не отпуская кнопку мыши, перетащить в сторону.)
3. Дважды щелкнуть на линии, представляющей переход, чтобы открыть диалоговое окно State Transition Specification.
4. Перейти на вкладку Detail.
5. В поле Guard Condition ввести текст контролируемого условия.
6. Закрыть окно State Transition Specification щелчком на кнопке ОК.
Как привести линии диаграммы к ортогональному виду
1. В окне диаграммы щелчком левой кнопки мыши выбрать линию, подлежащую преобразованию (удерживая нажатой клавишу <Shift>, можно выбрать несколько линий одновременно).
2. Выбрать элемент меню Format=>Line Style=>Rectilinear.
3. При необходимости щелкнуть на линии и, не отпуская кнопку мыши, переместить линию в нужном направлении.
Вариант диаграммы действий с ортогональными линиями приведен на рис. 14.
Полосы синхронизации
Процесс функционирования системы зачастую содержит стадии, которые могут выполняться параллельно. Полосы синхронизации (synchronization bars) позволяют указать, какие действия допускают единовременное выполнение или подлежат логическому объединению. Возможны ситуации, когда полоса синхронизации снабжается несколькими входящими связями и единственной исходящей и наоборот.
Как создать полосу синхронизации
1. Щелкнуть на пиктограмме Horizontal Synchronization или Vertical Synchronization панели инструментов Diagram.
2. Включить элемент полосы синхронизации в диаграмму действий, щелкнув в соответствующем месте рабочей области открытого окна диаграммы.
3. Щелкнуть на пиктограмме State Transition панели инструментов Diagram и снабдить полосу синхронизации необходимой входящей (исходящей) связью; повторить операцию для создания остальных связей-переходов.
Зоны
Диаграмма действий может быть разделена на зоны (swimlanes), каждая из которых обычно связана с определенным активным субъектом, ответственным за выполнение соответствующего подмножества действий.
Как поделить диаграмму действий на зоны
1. Щелкнуть на пиктограмме Swimlane панели инструментов Diagram.
2. Включить элемент зоны в диаграмму действий, щелкнув в пределах рабочей области открытого окна диаграммы. Диаграмма пополнится новой зоной с именем NewSwimlane.
3. Двойным щелчком на текстовой метке NewSwimlane открыть диалоговое окно Swimlane Specification.
4. В поле Name ввести требуемое имя зоны.
5. Закрыть окно Swimlane Specification щелчком на кнопке ОК.
6. Для изменения размера зоны щелкнуть на границе зоны и, не отпуская кнопку мыши, переместить границу в нужном направлении.
7. Применяя технику перетаскивания, расположить в пределах зоны все нужные элементы диаграммы (или создать новые).
Исходное и завершающее действия
Для обозначения исходного (start) и завершающего (end) действий в диаграмме применяются специальные символы в виде круга и стилизованного кольца. Обычно поток управления содержит одно исходное и несколько завершающих действий, по одному на каждый из возможных альтернативных путей протекания процесса функционирования системы.
Как создать исходное (завершающее) действие
1. Щелкнуть на пиктограмме Start State (End State) панели инструментов Diagram.
2. Включить элемент исходного (завершающего) действия в диаграмму действий, щелкнув в соответствующем месте рабочей области открытого окна диаграммы.
3. Щелкнуть на пиктограмме State Transition панели инструментов Diagram.
4. В окне диаграммы щелкнуть на символе исходного действия (или соответствующего действия-источника) и, не отпуская кнопку мыши, построить линию перехода, направленную к символу соответствующего действия-приемника (завершающего действия).