
Кооперативные диаграммы
Кооперативные диаграммы отражают ту же самую информацию, что и диаграммы Последовательности. Однако делают они это по-другому и с другими целями. Показанная на рис. 1.9 диаграмма Последовательности представлена на рис. 1.10 в виде Кооперативной диаграммы.
Как и раньше, объекты изображены в виде прямоугольников, а действующие лица в виде фигур. Если диаграмма Последовательности показывает взаимодействие между действующими лицами и объектами во времени, то на Кооперативной диаграмме связь со временем отсутствует. Так, можно видеть, что устройство для чтения карточки выдает счету Джо инструкцию открыться, а счет Джо заставляет это устройство вернуть карточку владельцу. Непосредственно взаимодействующие объекты соединены линиями. Если, например, устройство для чтения карточки общается непосредственно с экраном ATM, между ними следует провести линию. Отсутствие линии означает, что непосредственное сообщение между объектами отсутствует.
Итак, на Кооперативной диаграмме отображается та же информация, что и на диаграмме Последовательности, но нужна она для других целей. Специалисты по контролю качества и архитекторы системы смогут понять распределение процессов между объектами. Допустим, что какая-то Кооперативная диаграмма напоминает звезду, где несколько объектов связаны с одним центральным объектом. Архитектор системы может сделать вывод, что система слишком сильно зависит от центрального объекта, и перепроектировать ее для более равномерного распределения процессов. На диаграмме Последовательности такой тип взаимодействия было бы трудно увидеть.
Диаграммы Классов
Диаграммы Классов отражают взаимодействие между классами системы. Классы можно рассматривать как типы объектов (см. главу 5). Например, счет Джо — это объект. Типом такого объекта можно считать счет вообще, т.е. "Счет" (Account) — это класс. Классы содержат данные и поведение (действия), влияющее на эти данные. Так, класс Account содержит идентификационный номер клиента и проверяющие его действия. На диаграмме Классов класс создается для каждого типа объектов из диаграмм Последовательности или Кооперативных диаграмм. Диаграмма Классов для варианта использования "Снять деньги" показана на рис. 1.11.
На
диаграмме показаны связи между классами,
реализующими вариант использования
"Снять деньги". В этом процессе
задействованы четыре класса: Card
Reader
(устройство для чтения карточек), Account
(счет), ATM.Screen
(экран ATM)
и Cash
Dispenser
(кассовый аппарат). Каждый класс на
диаграмме Классов изображается в
виде прямоугольника, разделенного на
три части. В первой части указывается
имя класса, во второй — его атрибуты.
Атрибут — это некоторая информация,
характеризующая класс. Например, класс
Account
(счет) имеет три атрибута: Account
Number
(номер счета), PIN
(идентификационный номер) и Balance
(баланс). В последней части содержатся
операции класса, отражающие его
поведение
(действия, выполняемые классом). Для
класса Account
определены
четыре операции: Open
(открыть), Withdraw
Funds
(снять деньги), Deduct
Funds
(вычесть сумму денег из счета) и Verify
Funds
(проверить наличие денег).
Связывающие классы линии показывают взаимодействие между классами. Так, класс Account (счет) связан с классом ATM Screen (экран ATM), потому что они непосредственно взаимодействуют друг с другом. Класс Card Reader (устройство для чтения карточек) не связан с классом Cash Dispenser (кассовый аппарат), поскольку они не общаются друг с другом непосредственно. Обратите внимание, что слева от некоторых атрибутов и операций имеются маленькие значки в виде висячего замка. Они указывают, что атрибут или операция класса закрыта (private). Доступ к закрытым атрибутам или операциям возможен только из содержащего их класса. Account Number, PIN и Balance — закрытые атрибуты класса Account. Кроме того, закрытыми являются операции Deduct Funds и Verify Funds.
Разработчики используют диаграммы Классов для реального создания классов. Такие инструменты, как Rose, генерируют основу кода классов, которую программисты заполняют деталями на выбранном ими языке. С помощью этих диаграмм аналитики могут показать детали системы, а архитекторы — понять ее проект. Если, например, какой-либо класс несет слишком большую функциональную нагрузку, это будет видно на диаграмме классов, и архитектор сможет перераспределить ее между другими классами. С помощью диаграммы можно также выявить случаи, когда между сообщающимися классами не определено никаких связей. Диаграммы Классов следует создавать, чтобы показать взаимодействующие классы в каждом варианте использования. Можно строить также более общие диаграммы, охватывающие все системы или подсистемы.
Диаграммы Состояний
Диаграммы Состояний предназначены для моделирования различных состояний, в которых может находиться объект. В то время как диаграмма Классов показывает статическую картину классов и их связей, диаграммы Состояний применяются при описании динамики поведения системы.
Диаграммы Состояний отображают поведение объекта. Так, банковский счет может иметь несколько различных состояний. Он может быть открыт, закрыт, или может быть превышен кредит по нему. Поведение счета меняется в зависимости от состояния, в котором он находится. На диаграмме Состояний показывают именно эту информацию.
На рис. 1.12 приведен пример диаграммы Состояний для банковского счета.
На данной диаграмме показаны возможные состояния счета, а также процесс перехода счета из одного состояния в другое. Например, если клиент требует закрыть открытый счет, последний переходит в состояние "Закрыт". Требование клиента называется событием (event), именно события вызывают переход из одного состояния в другое.
Когда клиент снимает деньги с открытого счета, счет может перейти в состояние "Превышение кредита". Это происходит, только если баланс по счету меньше нуля, что отражено условием [отрицательный баланс] на нашей диаграмме. Заключенное в квадратные скобки условие (guard condition) определяет, когда может или не может произойти переход из одного состояния в другое.
На диаграмме имеются два специальных состояния — начальное (start) и конечное (stop). Начальное состояние выделяется черной точкой, оно соответствует состоянию объекта в момент его создания. Конечное состояние обозначается черной точкой в белом кружке, оно соответствует состоянию объекта непосредственно перед его уничтожением. На диаграмме Состояний может быть одно и только одно начальное состояние. В то же время может быть столько конечных состояний, сколько вам нужно, или их может не быть вообще.
Когда объект находится в каком-то конкретном состоянии, могут выполняться те или иные процессы. В нашем примере при превышении кредита клиенту посылается соответствующее сообщение. Процессы, происходящие, когда объект находится в определенном состоянии, называются действиями (actions).
Диаграммы Состояний не нужно создавать для каждого класса, они применяются только в очень сложных случаях. Если объект класса может существовать в нескольких состояниях и в каждом из них ведет себя по-разному, для него, вероятно, потребуется такая диаграмма. Однако во многих проектах они вообще не используются. Если же диаграммы Состояний все-таки были построены, разработчики могут применять их при создании классов.
Диаграммы Состояний необходимы в основном для документирования. При генерации в Rose кода на основе вашей модели содержащаяся в них информация не преобразуется ни в какой код. Тем не менее для работающих в режиме реального времени систем доступны различные расширения Rose, которые позволяют генерировать исполняемый код, основываясь на диаграммах Состояний.
Диаграммы Компонентов
Диаграммы Компонентов показывают, как выглядит модель на физическом уровне. На ней изображаются компоненты программного обеспечения вашей системы и связи между ними. При этом выделяют два типа компонентов: исполняемые компоненты и библиотеки кода.
В среде Rose каждый класс модели преобразуется в компонент исходного кода. Созданные компоненты сразу добавляются к диаграмме Компонентов. Затем указываются зависимости между отдельными компонентами, соответствующие зависимостям на этапе компиляции или выполнения программы.
На рис. 1.13 изображена одна из диаграмм Компонентов для системы ATM.
На этой диаграмме показаны компоненты клиента системы ATM. В данном случае команда разработчиков решила строить систему с помощью языка C++. У каждого класса имеется свой собственный заголовочный файл и файл с расширением . СРР, так что каждый класс преобразуется в свои собственные компоненты на диаграмме. Например, класс ATM Screen преобразуется в два компонента ATM Screen диаграммы. Вместе эти компоненты представляют тело и заголовок класса ATM Screen. Выделенный темным компонент называется спецификацией пакета (package specification) и соответствует файлу тела класса ATM Screen на языке C++ (файл с расширением .СРР). Невыделенный компонент также называется спецификацией пакета, но соответствует заголовочному файлу класса языка C++ (файл с расширением . H). Компонент АТМ.ехе является спецификацией задачи и представляет поток обработки информации (thread of processing). В данном случае поток обработки программы. Компоненты соединены штриховой линией, отображающей зависимости между ними. Например, класс Card Reader зависит от класса ATM Screen. Следовательно, для того чтобы класс Card Reader мог быть скомпилирован, класс ATM Screen должен уже существовать. После компиляции всех классов может быть создан исполняемый файл ATMClient.exe. Пример ATM содержит два потока обработки, и таким образом получаются два исполняемых файла. Один из них — это клиент ATM, он содержит компоненты Cash Dispenser, Card Reader и ATM Screen. Второй файл — сервер ATM, включающий в себя компонент Account. Диаграмма Компонентов для сервера ATM
Как видно из примера, у системы может быть несколько диаграмм Компонентов в зависимости от числа подсистем или исполняемых файлов. Каждая подсистема является пакетом компонентов. В общем случае, пакеты — это совокупности компонентов (см. раздел "Основы Rose" главы 3). В примере ATM используются два пакета: клиент ATM и сервер ATM.
Диаграммы Компонентов применяются теми участниками проекта, кто отвечает за компиляцию системы. Диаграмма Компонентов дает представление о том, в каком порядке надо компилировать компоненты, а также какие исполняемые компоненты будут созданы системой. Диаграмма показывает соответствие классов реализованным компонентам. Итак, она нужна там, где начинается генерация кода.
Диаграммы Размещения
Диаграммы Размещения показывают физическое расположение различных компонентов системы в сети. В нашем примере система ATM состоит из большого количества подсистем, выполняемых на отдельных физических устройствах, или узлах (node). Диаграмма Размещения для системы ATM представлена на рис. 1.15.
Из данной диаграммы можно узнать о физическом размещении системы. Клиентские программы ATM будут работать в нескольких местах на различных сайтах. Через закрытые сети будет осуществляться сообщение клиентов с региональным сервером ATM. На нем будет работать программное обеспечение сервера ATM. В свою очередь, посредством локальной сети региональный сервер будет взаимодействовать с сервером банковской базы данных, работающим под управлением Oracle. Наконец с региональным сервером ATM соединен принтер.
Итак, данная диаграмма показывает физическое расположение системы. Например, наша система ATM соответствует трехуровневой архитектуре, когда на первом уровне размещается база данных, на втором — региональный сервер, а на третьем — клиент.
Диаграмма Размещения используется менеджером проекта, пользователями, архитектором системы и эксплуатационным персоналом для выяснения физического размещения системы и расположения ее отдельных подсистем. Менеджер проекта объяснит пользователям, как будет выглядеть готовый продукт. Эксплуатационный персонал сможет планировать работу по установке системы.
Приведенные диаграммы описывают систему с различных точек зрения. В разделе "Основы Rose" главы 3 мы детальнее рассмотрим каждую из этих диаграмм и покажем, как создавать их в среде Rational Rose. Вы сможете потренироваться в их построении и применении в этой среде. Однако прежде чем углубиться в детали Rose, стоит обсудить еще один аспект разработки программного обеспечения сам процесс. Хотя эта книга и не является учебником по методологии или по организации процесса, мы хотели бы познакомить вас с процессом разработки приложений, использующим описанные выше диаграммы UML.
Визуальное моделирование и процесс разработки программного обеспечения
Программное обеспечение может быть создано разными способами. Существует несколько различных типов процесса разработки, которые могут быть использованы в проекте: от "водопада” (waterfall) до объектно-ориентированного подхода. У каждого есть свои преимущества и недостатки. В данном разделе мы не собираемся указывать вам, какой именно процесс применять в своей работе, а представляем лишь краткое описание процесса, связанного с визуальным моделированием. Еще раз подчеркнем, что это только общий обзор.
Долгое время программное обеспечение разрабатывали, следуя так называемой модели "водопада". В соответствии с ней необходимо было сначала проанализировать требования к будущей системе, спроектировать, создать и протестировать систему, а затем установить ее у пользователей. Как видно из названия, движение в обратную сторону по этой цепочке было невозможно — вода не потечет вверх. Данный метод был официальной методологией, применявшейся в тысячах проектов, но мы готовы утверждать, что в чистом виде, как его принято понимать, он не использовался ни разу. Одним из главных недостатков модели "водопада" является невозможность возврата назад на пройденные этапы, В начале проекта, следующего такой модели, перед разработчиками стоит обескураживающая задача полностью определить все требования к системе. Для этого необходимо тщательно и всесторонне обсудить с пользователями и исследовать бизнес-процессы. Пользователи должны согласиться со всем тем, что выясняется в ходе такого обследования, хотя они могут и не ознакомиться до конца с его результатами. При некотором везении таким способом на стадии анализа удается собрать около 80% требований к системе.
Затем начинается этап проектирования. Необходимо сесть и определить архитектуру будущей системы. Мы выясняем, где будут установлены программы и какая аппаратура нужна для достижения приемлемой производительности. На данном этапе могут обнаружиться новые проблемы, их необходимо опять обсуждать с пользователями, что выразится в появлении новых требований к системе. Итак, приходится возвращаться к анализу. После нескольких таких кругов наконец наступает этап написания программного кода.
На этом этапе обнаруживается, что некоторые из принятых ранее решений невозможно осуществить. Приходится возвращаться к проектированию и пересматривать эти решения. После завершения кодирования наступает этап тестирования. Здесь выясняется, что требования не были достаточно детализированы и их реализация некорректна. Нужно возвращаться назад на этап анализа и пересматривать эти требования.
Наконец система готова и поставлена пользователям. Поскольку прошло уже много времени и бизнес, вероятно, уже успел измениться, пользователи воспринимают ее без большого энтузиазма, отвечая примерно так: "Да, это то, что я просил, но не то, что я хочу!" Это — магическая фраза, заклинание, которое разом состарит всю команду разработчиков как минимум на 10 лет!
Рассмотрев этот мрачный сценарий и задумавшись о правильности выбора профессии, давайте поразмышляем, можно ли как-нибудь улучшить процесс. Состоит ли проблема в том, что правила бизнеса изменяются слишком быстро? Может быть, пользователи не могут объяснить, чего они хотят? Может быть, они не понимают команду разработчиков? Или сама команда не придерживается определенного процесса? Ответы на эти вопросы: да, да, да и нет. Бизнес меняется очень быстро, и как профессионалы-программисты мы должны поспевать за этим. Пользователи не всегда могут сказать, чего они хотят, поскольку их работа стала для них "второй натурой". Спрашивать об этом прослужившего 30 лет банковского клерка — примерно то же самое, что спрашивать, как он дышит. Работа стала для него настолько привычной, что ее уже трудно описать. Еще одна проблема заключается в том, что пользователи не всегда понимают команду разработчиков. Команда показывает им графики, выпускает тома текста, описывающего требования к системе, но пользователи не всегда понимают, что именно им дают. Есть ли способ обойти эту проблему? Да, здесь поможет визуальное моделирование. И наконец, команда разработчиков точно следует процессу — методу "водопада". К сожалению, планирование и реализация метода — две разные вещи.
Итак, одна из проблем заключается в том, что разработчики использовали метод "водопада11, заключающийся в аккуратном и последовательном прохождении через все этапы проекта, но им приходилось возвращаться на пройденные этапы. Происходит ли это из-за плохого планирования? Вероятно, нет. Разработка программного обеспечения — сложный процесс, и его поэтапное аккуратное выполнение не всегда возможно. Если же игнорировать необходимость возврата, то система будет содержать дефекты проектирования и некоторые требования будут потеряны, возможны и более серьезные последствия. Прошли годы, пока мы не научились заранее планировать возвраты на пройденные этапы. Таким образом, мы пришли к итеративной разработке. Это название означает лишь, что мы собираемся повторять одни и те же этапы снова и снова. В объектно-ориентированном процессе нужно по многу раз небольшими шагами проходить этапы анализа, проектирования, разработки, тестирования и установки системы.
Невозможно выявить все требования на ранних этапах проектирования. Мы учитываем появление новых требований в процессе разработки, планируя проект в несколько итераций. В рамках такой концепции проект можно рассматривать как последовательность небольших "водопадиков". Каждый из них достаточно велик, чтобы означать завершение какого-либо важного этапа проекта, но мал, чтобы минимизировать необходимость возврата назад. Мы проходим четыре фазы проекта: начальная фаза (inception), уточнение (elaboration), конструирование (construction) и ввод в действие (transition). Начальная фаза — это начало проекта. Мы собираем информацию и разрабатываем базовые концепции. В конце этой фазы принимается решение продолжать (или не продолжать) проект. В фазе уточнения детализируются варианты использования и принимаются архитектурные решения. Уточнение включает в себя некоторый анализ, проектирование, кодирование и планирование тестов. В фазе конструирования разрабатывается основная часть кода. Ввод в действие — это завершающая компоновка системы и установка ее у пользователей. Далее мы рассмотрим, что означает каждая из этих фаз в объектно-ориентированном проекте.
Начальная фаза
Начальная фаза — это начало работы над проектом, когда кто-нибудь говорит: "А хорошо бы, чтобы система делала..." Затем кто-то еще изучает идею, и менеджер спрашивает, сколько времени потребует ее реализация, сколько это будет стоить и насколько она выполнима. Начальная фаза как раз и заключается в том, чтобы найти ответы на эти вопросы. Мы исследуем свойства системы на высоком уровне и документируем их. Определяем действующих лиц и варианты использования, но не углубляемся в (детали вариантов использования, ограничиваясь одним или двумя предложениями. Мы также готовим оценки для высшего руководства. Итак, применяя Rose для поддержки нашего проекта, мы создаем действующих лиц и варианты использования и строим диаграммы Вариантов Использования. Начальная фаза завершается, когда данное исследование закончено и для работы над проектом выделены необходимые ресурсы.
Начальная фаза проекта в основном последовательна и не итеративна. В отличие от нее, другие фазы повторяются несколько раз в процессе работы над проектом. Так как проект может быть начат только один раз, начальная фаза также выполняется лишь однажды. По этой причине в начальной фазе должна быть решена еще одна задача — разработка плана итераций. Это план, описывающий, какие варианты использования на каких итерациях должны быть реализованы. Если, например, в начальной фазе было выявлено 10 вариантов использования, можно создать следующий план:
Итерация 1 Варианты Использования 1, 5, 6
Итерация 2 Варианты Использования 7, 9
Итерация 3 Варианты Использования 2, 4, 8
Итерация 4 Варианты Использования 3, 10
План определяет, какие варианты использования надо реализовать в первую очередь. Построение плана требует рассмотрения зависимостей между вариантами использования. Если для того, чтобы мог работать Вариант Использования 5, необходима реализация Варианта Использования 3, то описанный выше план неосуществим, поскольку Вариант Использования 3 реализуется на четвертой итерации — значительно позже Варианта Использования 5 из первой итерации. Такой план нужно пересмотреть, чтобы учесть все зависимости.
Уточнение
В фазе уточнения проекта выполняются некоторое планирование, анализ и проектирование архитектуры. Следуя плану итерации, уточнение проводится для каждого варианта использования в текущей итерации. Уточнение включает в себя такие аспекты проекта, как кодирование прототипов (proofs-of-concept), разработка тестов и принятие решений по проекту.
Основная задача фазы уточнения — детализация вариантов использования. В разделе "Основы Rose" главы 3 рассматривается, что может входить в детали вариантов использования. Предъявляемые к вариантам использования требования низкого уровня предусматривают описание потока обработки данных внутри них, выявление действующих лиц, разработку диаграмм Взаимодействия для графического отображения потока обработки данных, а также определение всех переходов состояний, которые могут иметь место в рамках варианта использования. Из требований, определенных в форме детализированных вариантов использования, составляется документ под названием "Спецификация требований к программному обеспечению" (Software Requirement Specification, SRS). SRS содержит детальное описание всех требований к системе.
В фазе уточнения выполняются и такие задачи, как уточнение предварительных оценок, изучение SRS и модели вариантов использования с точки зрения качества проектируемой системы, анализ рисков. С помощью Rational Rose можно уточнить модель Вариантов Использования, а также разработать диаграммы Последовательности и Кооперативные диаграммы для графического представления потока обработки данных. Кроме того, в этой фазе проектируются диаграммы Классов, описывающие объекты, которые необходимо создать.
Фаза уточнения завершается, когда варианты использования полностью детализированы и одобрены пользователями, прототипы завершены настолько, чтобы уменьшить риски, разработаны диаграммы Классов. Иными словами, эта фаза пройдена, когда система спроектирована, рассмотрена и готова для передачи разработчикам.
Конструирование
Конструирование - процесс разработки и тестирования программного обеспечения. Как и в случае уточнения, эта фаза выполняется для каждого набора вариантов использования на каждой итерации. Задачи конструирования включают в себя определение всех оставшихся требований, разработку и тестирование программного обеспечения (ПО). Так как ПО полностью проектируется в фазе уточнения, конструирование не предполагает большого количества решений по проекту, что позволяет команде работать параллельно. Это означает, что разные группы программистов могут одновременно работать над различными объектами ПО, зная, что по завершении фазы система "сойдется". В фазе уточнения мы проектируем объекты системы и их взаимодействие. Конструирование только запускает проект в действие, а новых решений по нему, способных изменить это взаимодействие, не принимается.
Еще одним преимуществом такого подхода к моделированию системы является то, что среда Rational Rose способна генерировать "скелетный код" системы. Для использования этой возможности следует разработать компоненты и диаграмму компонентов на раннем этапе конструирования. Генерацию кода можно начать сразу после создания компонентов и нанесения на диаграмму зависимостей «.тя ними. В результате будет автоматически построен код, который можно создать, основываясь а I проекте системы. Это не означает, что с помощью Rose можно получить любой код, реализующий 14-логику приложений. Результат сильно зависит от используемого языка программирования, но случае предполагает определение классов, атрибутов, областей действия (общих (public), закрытых (private) и защищенных (protected)), прототипов функций и операторов наследования. Это позволяет сэкономить время, так как написание кода вручную — довольно кропотливая и утомительная работа. Получив код, программисты могут сконцентрироваться на специфических аспектах проекта, связанных с бизнес-логикой. Еще одна группа разработчиков должна выполнить экспертную оценку кода, чтобы убедиться в его функциональности и соответствии стандартам и соглашениям по проекту. Затем объекты должны быть подвергнуты оценке качества. Если в фазе конструирования были добавлены новые атрибуты или функции или если были изменены взаимодействия между объектами, код следует преобразовать в модель Rose с помощью обратного проектирования (см. главы с 19 по 24).
Конструирование можно считать завершенным, когда программное обеспечение готово и протестировано. Важно убедиться в адекватности модели и программного обеспечения; модель будет чрезвычайно полезна в процессе сопровождения ПО.
Ввод в действие
Фаза ввода в действие наступает, когда готовый программный продукт передают пользователям. Задачи в этой фазе предполагают завершение работы над финальной версией продукта, завершение приемочного тестирования, завершение составления документации и подготовку к обучению пользователей. Чтобы отразить последние внесенные изменения, следует обновить Спецификацию требований к программному обеспечению, диаграммы Вариантов Использования, Классов, Компонентов и Размещения. Важно, чтобы ваши модели были синхронизированы с готовым продуктом, поскольку они будут использоваться при его сопровождении. Кроме того, модели будут неоценимы при внесении усовершенствований в созданную систему через несколько месяцев после завершения проекта.
В фазе ввода в действие Rational Rose не настолько полезна, как в других фазах. В этот момент приложение уже создано. Rose предназначена для оказания помощи при моделировании и разработке программного обеспечения и даже при планировании его размещения. Однако Rose не является инструментом тестирования и не способна помочь в планировании тестов или процедур, связанных с размещением ПО. Для этой цели созданы другие продукты. Итак, в фазе ввода в действие Rose применяется прежде всего для обновления моделей после завершения работы над программным продуктом.
Rational Rose
Rational Rose — мощный инструмент анализа и проектирования объектно-ориентированных программных систем. Он позволяет моделировать системы до написания кода, так что вы можете с самого начала быть уверены в адекватности их архитектуры. С помощью готовой модели недостатки проекта легко обнаружить на стадии, когда их исправление не требует еще значительных затрат.
Среда Rational Rose позволяет проектировать варианты использования и их диаграммы для визуализации функциональных возможностей системы. Диаграммы Взаимодействия показывают, как объекты работают совместно, обеспечивая требуемые функциональные возможности. Для отображения объектов системы и их отношений используются диаграммы Классов. Диаграммы Компонентов иллюстрируют, как классы соотносятся с готовыми физическими компонентами системы. Наконец диаграммы Размещения применяют для визуализации проекта распределенных систем.
Модель Rose — это картина системы. Она содержит все диаграммы UML, действующих лиц, варианты использования, объекты, классы, компоненты и узлы системы. Она детально описывает, что система содержит и как функционирует, поэтому разработчики могут использовать ее в качестве эскиза или чертежа создаваемой системы.
Такой чертеж помогает решить старую проблему. Допустим, команда разработчиков обсудила с пользователями и документировала требования к приложению. Программисты готовы писать код. Один из них (назовем его Боб) берет часть требований, принимает определенные решения и пишет некоторый фрагмент кода. Другой (Джейн) тоже берет часть требований, принимает свои, совершенно отличающиеся от первого, решения по проекту и пишет другой код.
Естественно ожидать различие в стилях программирования; получив одинаковый набор требований, 20 разработчиков создадут 20 различных систем. Таким образом, без подробного обсуждения работы с каждым участником проекта будет трудно понять, какие решения по проекту приняты, из каких элементов состоит система и что представляет собой ее общая структура. Не имея документированного проекта, трудно даже быть уверенным, что созданное приложение — это именно то, чего хотели пользователи.
Традиционно процесс, которому мы следуем, выглядит следующим образом:
Хотя требования и были документированы, весь проект находится в голове Боба, и никто, кроме Боба, не понимает достаточно хорошо архитектуру системы. Когда Боб оставляет команду, информация уходит вместе с ним. Если вы оказывались в подобной ситуации, то согласитесь, как трудно бывает понять плохо документированную систему.
Модель Rose предлагает совершенно другой подход:
В этом случае проект уже документирован. Разработчики могут собраться вместе и обсудить принимаемые по проекту решения до фактического написания кода. Вам не нужно больше беспокоиться, что каждый из них пойдет своим путем в проектировании частей одного и того же приложения
Однако модели используют не только разработчики:
С помощью диаграмм Вариантов Использования потребители и менеджеры проекта получат общее представление о системе и смогут принять решение о сфере ее применения.
С помощью диаграмм Вариантов Использования и документации менеджеры проекта смогут разделить проект на отдельные управляемые задачи*
Из документации по вариантам использования аналитики и потребители смогут понять, что будет делать готовая система.
Изучив ту же документацию, технические писатели смогут приступить к написанию руководства для пользователей и к подготовке планов по их обучению.
Из диаграмм Последовательности и Кооперативных диаграмм аналитики и разработчики уяснят, насколько логично работает система, поймут ее объекты и сообщения между ними.
С помощью документации по вариантам использования, а также диаграмм Последовательности и Кооперативных диаграмм специалисты по контролю качества смогут получить информацию, требуемую им для написания тестовых сценариев.
С помощью диаграмм Классов и Состояний разработчики получат представление о фрагментах системы и их взаимодействии друг с другом.
Из диаграмм Компонентов и Размещения эксплуатационный персонал сможет узнать, какие .EXE и .DLL файлы и другие компоненты будут созданы, а также где в сети они должны быть размещены.
С помощью модели в целом команда участников проекта сможет отслеживать реализацию исходных требований до кода, а также из любого фрагмента кода выводить исходные требования, которые он реализует.
Итак, Rose — это средство, которое может быть использовано всеми участниками проекта. Это, фактически, хранилище информации о контексте и проекте системы, из которого каждый участник проекта извлекает то, что ему нужно.
Помимо всего вышесказанного, Rational Rose позволяет генерировать "скелетный код" на большом количестве различных языков, включая C++, Java, Visual Basic и PowerBuilder. Более того, можно выполнять обратное проектирование кода и создавать таким образом модели уже существующих систем. Весьма выгодно иметь модели Rose для уже существующих приложений. Если сделано изменение в модели, Rose позволяет модифицировать код для его реализации. Если же был изменен код, можно автоматически обновить соответствующим образом и модель. Благодаря этому удается поддерживать соответствие между моделью и кодом, уменьшая риск "устаревания" первой.
Среду Rose можно расширить с помощью RoseScript, языка программирования, поставляемого вместе с ней. На RoseScript можно написать код для автоматического внесения изменений в модель, для создания отчетов и выполнения других задач.
Знакомство с ROSE
Элементы экрана
Основными элементами интерфейса Rose являются браузер, окно документации, панели инструментов, окно диаграммы и журнал (log).
Браузер (browser) Используется для быстрой навигации по модели
Окно документации (documentation window) Применяется для работы с документацией элементов модели
Панели инструментов (toolbars) Обеспечивают быстрый доступ к наиболее распространенным командам
Окно диаграммы (diagram window) Используется для просмотра и редактирования одной или нескольких диаграмм UML
Журнал (log) Применяется для просмотра ошибок и отчетов о результате выполнения различных команд
Панели инструментов
|
Create new model |
Создает новый файл модели Rose (mdl) |
|
Open Existing model |
Открывает существующий файл модели Rose (.mdl) |
|
Save model or log |
Сохраняет файл модели (.mdl) |
|
Cut |
Вырезать |
|
Copy |
Копирование |
|
Paste |
Вставка |
|
Browse Class Diagram |
Находит и открывает диаграмму классов |
|
Browse Interaction Diagram |
Находит и открывает диаграмму Последовательности и Кооперативную диаграммы |
|
Browse Component Diagram |
Находит и открывает диаграмму Компонентов |
|
Browse Deployment Diagram |
Находит и открывает диаграмму Размещения |
|
Brows Parent |
Находит и открывает диаграмму порождающую данную (родительскую) |
|
Brows Previous Diagram |
Находит и открывает диаграмму, с которой вы работали перед данной |
Пользователь может изменить и настроить любую панель инструментов. Для этого следует выбрать пункт меню Tools Options (Инструменты Параметры), затем вкладку Toolbars (Панели инструментов).
ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ
Диаграмма Вариантов Использования содержит некоторые варианты использования системы, некоторых действующих лиц и связи между ними. Вариант использования (use case) — это описание функциональности системы на "высоком уровне". Действующее лицо (actor) — это все, что взаимодействует с системой. На рис. 3.1 приведен пример диаграммы Вариантов Использования.
На этой диаграмме показаны три действующих лица: клиент, банковский служащий и кредитная система. Существуют также шесть основных действий, выполняемых моделируемой системой: перевести деньги, положить деньги на счет, снять деньги со счета, показать баланс, изменить идентификационный номер и произвести оплату.
Одним из основных преимуществ применения диаграммы Вариантов Использования является то, что она предоставляет важную информацию. Взглянув на варианты использования, ваши клиенты поймут, какие функциональные возможности будут заложены в систему. Рассматривая действующих лиц, они выяснят, кто конкретно будет с ней взаимодействовать. Изучая все множество вариантов использования и действующих лиц, они определят сферу применения системы, что она должна будет делать. Это поможет им узнать также, что она не будет делать, и внести коррективы. Например, взглянув на диаграмму, пользователь может сказать: "Все это прекрасно, но я хочу иметь еще возможность получать отчет о десяти последних транзакциях для моего счета".
Часто для одной системы создается несколько диаграмм Вариантов Использования. На диаграмме высокого уровня, называемой в среде Rational Rose Главной (Main), указываются только пакеты (группы) вариантов использования. Другие диаграммы описывают совокупности вариантов использования и действующих лиц. Может потребоваться также нанести на одну диаграмму все варианты использования и всех действующих лиц системы. Количество и состав создаваемых диаграмм Вариантов Использования полностью зависит от вас. Важно только, чтобы они содержали достаточно информации, чтобы быть полезными, но не слишком много, чтобы не привести в замешательство.
Конкретная цель диаграмм Вариантов Использования — документирование вариантов использования (все входящее в сферу применения системы), действующих лиц (все вне этой сферы) и связей между ними. Разрабатывая диаграммы Вариантов Использования, старайтесь придерживаться следующих правил:
Не моделируйте связи между действующими лицами. По определению действующие лица находятся вне сферы действия системы. Это означает, что связи между ними также не относятся к ее компетенции. Для изучения коммуникации между действующими лицами применяется диаграмма потоков работ (workflow diagram).
Не соединяйте стрелкой непосредственно два варианта использования (кроме случаев связей использования и расширения, рассматриваемых ниже). Диаграммы данного типа описывают только, какие варианты использования доступны системе, а не порядок их выполнения. Для отображения порядка выполнения вариантов использования применяются диаграммы Деятельностей.
Каждый вариант использования должен быть инициирован действующим лицом. Это означает, что всегда должна быть стрелка, начинающаяся на действующем лице и заканчивающаяся на варианте использования. Исключением являются рассматриваемые далее связи использования и расширения.
Думайте о базе данных как о слое, находящемся под диаграммой. С помощью одного варианта использования можно вводить данные в базу, а получать их — с помощью другого. Для изображения потока информации не нужно рисовать стрелки от одного варианта использования к другому.
Создание диаграмм Вариантов Использования
В среде Rose диаграммы Вариантов Использования создаются в представлении Вариантов Использования. Главная диаграмма (Main) предлагается вам по умолчанию. Для моделирования системы можно разработать столько дополнительных диаграмм, сколько нужно.
Для получения доступа к Главной диаграмме Вариантов Использования:
В браузере щелкните мышью на значке "+" рядом с представлением Вариантов Использования. Данное представление будет открыто.
Вы увидите Главную диаграмму Вариантов Использования. Обратите внимание, что в левой части всех диаграмм Вариантов Использования в среде Rose находится следующая пиктограмма:
Дважды щелкнув на Главной диаграмме, откройте ее. Строка заголовка изменится — появится фраза [Use Case Diagram: Use Case view/Main] (Диаграмма Вариантов Использования: Представление Вариантов Использования/Главная).
Для создания новой диаграммы Вариантов Использования:
Щелкните правой кнопкой мыши на пакете представления Вариантов Использования в браузере.
Во всплывающем меню выберите пункт New Use Case Diagram (Создать Диаграмма Вариантов Использования)
Связывание файлов и ссылок с диаграммой Вариантов Использования
В среде Rose вы можете прикрепить к диаграмме Вариантов Использования файл или адрес Интернета (URL). Например, таким образом можно связать с диаграммой любой вспомогательный документ, например спецификации требований высокого уровня, документы концептуального характера или даже проектный план. Все связанные файлы и ссылки будут показаны в браузере под соответствующей диаграммой Вариантов Использования. По двойному щелчку мыши на файле или ссылке в браузере откроется соответствующее приложение и загрузится ваш документ, находящийся в файле или по указанному адресу Интернета.
Для прикрепления файла к диаграмме Вариантов Использования:
Щелкните правой кнопкой мыши на соответствующей диаграмме в браузере.
В открывшемся меню выберите пункт New >- File (Создать Файл).
В диалоговом окне Open (Открыть) укажите, какой файл нужно прикрепить к диаграмме.
Выберите пункт Open (Открыть), чтобы выполнить прикрепление.
Панель инструментов диаграмм Вариантов Использования
Когда открывается диаграмма Вариантов Использования, на панели инструментов диаграммы появляются соответствующие пиктограммы. Описание некоторых кнопок панели приведено в таблице 3.1. Далее рассматривается применение этих кнопок для создания вариантов использования, действующих лиц и других элементов ваших диаграмм.
Работа с вариантами использования
Вариант использования — это описание на "высоком уровне" фрагмента функциональности, которую обеспечивает система. Иначе говоря, вариант использования иллюстрирует, как можно использовать систему. Например, автоматический банкомат (ATM) предоставляет клиенту некоторый базовый набор функциональных возможностей. Он позволяет снимать деньги, делать вклад, переводить деньги с одного счета на другой, просматривать свой баланс, изменять идентификационный номер или производить оплату по безналичному расчет) с кредитной карточки. Каждая из описанных транзакций является способом, которым клиент может использовать систему. Таким образом, каждый из них — это самостоятельный вариант использования. На языке UML вариант использования изображают следующим образом:
Преимущество вариантов использования заключается в том, что можно отделить реализацию системы от описания ее принципиальных основ. Они позволяют заострить внимание на наиболее важных вещах — удовлетворении потребностей и ожиданий заказчиков — без необходимости углубления в детали реализации. Взглянув на варианты использования, пользователь сможет понять, что будет делать система, и обсудить сферу ее применения в самом начале работы над проектом.
Варианты использования предлагают подход, отличающийся от традиционных методов. Разделение проекта на варианты использования является таким способом изучения системы, который ориентирован на сам процесс, а не на его реализацию. Если при использовании функциональной декомпозиции задача заключается в последовательном разбиении проблемы на небольшие фрагменты, с которыми будет работать готовая система, то подход вариантов использования сосредоточен прежде всего на том, что ожидает от системы пользователь.
В начале работы над проектом возникает естественный вопрос: "Как обнаружить варианты использования?" Лучше всего внимательно прочитать документацию заказчика. Часто помогает также рассмотрение области использования системы на высоком уровне и документов концептуального характера. Учтите мнение каждого из заинтересованных лиц проекта. Подумайте, чего они ожидают от готового продукта. Каждому заинтересованному лицу можно задать следующие вопросы:
Что он хочет делать с системой?
Будет ли он с ее помощью работать с информацией (вводить, получать, обновлять, удалять)?
Нужно ли будет информировать систему о каких-либо внешних событиях?
Должна ли система в свою очередь информировать пользователя о каких-либо изменениях или событиях?
Как уже упоминалось ранее, варианты использования — это не зависящее от реализации высокоуровневое представление того, что пользователь ожидает от системы. Рассмотрим каждый фрагмент этого определения по отдельности.
Прежде всего варианты использования не зависят от реализации. Представьте себе, что вы пишете руководство по работе с системой. Необходимо, чтобы ваши варианты использования можно было реализовать на языках Java, C++, Visual Basic или на бумаге. Варианты использования заостряют внимание на том, что должна делать система, а не на том, как она должна это делать. Проблемы реализации вариантов использования описываются ниже.
Варианты использования — это высокоуровневое представление системы. Если, например, в вашей модели содержится 3000 вариантов использования, вы теряете преимущество простоты. Создаваемый вами набор вариантов использования должен предоставить пользователям возможность увидеть всю систему целиком на самом высоком уровне. Поэтому вариантов использования не должно быть слишком много, чтобы клиенту не пришлось долго блуждать по страницам документации с целью выяснения того, что будет делать система. В то же время вариантов использования должно быть достаточно для полного описания поведения системы. Модель типичной системы обычно содержит от 20 до 50 вариантов использования. Для разбиения вариантов использования на части применяются связи различных типов, так называемые связи использования и расширения. Для лучшей организации системы можно также формировать группы вариантов использования, объединяя их в пакеты (см. ниже).
Наконец, варианты использования заостряют внимание на том, что пользователи хотят получить от системы. Каждый вариант использования должен представлять собой завершенную транзакцию между пользователем и системой. Названия вариантов использования должны быть деловыми, а не техническими терминами. В рассматриваемом нами примере ATM нельзя назвать вариант использования "Интерфейс с банковской системой, осуществляющий перевод денег с кредитной карточки и наоборот". Вместо этого лучше дать название "Оплатить по карточке" — так будет понятнее для заказчика. Варианты использования обычно называют глаголами или глагольными фразами, описывая при этом, что пользователь видит как конечный результат процесса. Его не интересует, сколько других систем задействовано в варианте использования, какие конкретные шаги надо предпринять и сколько строчек кода требуется написать, чтобы заплатить по счету карточкой Visa. Для него важно только, чтобы оплата была произведена. Еще раз повторим, вы должны заострить внимание на результате, который потребитель ожидает от системы, а не на действиях, которые нужно предпринять для достижения этого результата.
Но как убедиться, что вы обнаружили все варианты использования? Для этого следует ответить на вопросы:
Присутствует ли каждое функциональное требование хотя бы в одном варианте использования?
Если требование не нашло отражение в варианте использования, оно не будет реализовано.
Учтено ли, как с системой будет работать каждое заинтересованное лицо?
Какую информацию будет передавать системе каждое заинтересованное лицо?
Какую информацию будет получать от системы каждое заинтересованное лицо?
Учтены ли проблемы, связанные с эксплуатацией? Кто-то должен будет запускать готовую систему и выключать ее.
Учтены ли все внешние системы, с которыми будет взаимодействовать данная?
Какой информацией каждая внешняя система будет обмениваться с данной?
Документирование потока событий
Варианты использования начинают описывать, что должна будет делать ваша система. Но чтобы фактически разработать систему, потребуются более конкретные детали. Они определяются в документе, называемом "потоком событий" (flow of events). Целью потока событий является документирование процесса обработки данных, реализуемого в рамках варианта использования. Этот документ подробно описывает, что будут делать пользователи системы и что — сама система.
Поток событий также не должен зависеть от реализации. Составляя этот документ, представьте себе, что создается автоматизированная система. Однако на данном этапе вас еще не должно волновать, будет ли она написана на языке C++, PowerBuilder или Java. Ваша цель — описать, что будет делать система, а не как она будет это делать. Обычно поток событий содержит:
Краткое описание
Предусловия (pre-conditions)
Основной поток событий
Альтернативный поток событий
Постусловия (post-conditions)
Рассмотрим последовательно эти составные части.
Описание
Каждый вариант использования должен иметь связанное с ним короткое описание того, что он будет делать. Например, вариант использования "Перевести деньги" системы ATM может содержать следующее описание:
Вариант использования "Перевести деньги" позволяет клиенту или служащему банка переводить деньги с одного счета до востребования или сберегательного счета на другой.
Следует делать описание коротким и "к месту", при этом оно должно определять типы пользователей, выполняющих вариант использования, и ожидаемый ими конечный результат. Во время работы над проектом (особенно, если проект длинный) эти описания будут напоминать членам команды, почему тот или иной вариант использования был включен в проект и что он должен делать. Четко документируя таким образом цели каждого варианта использования, можно уменьшить неразбериху, возникающую среди разработчиков.
Предусловия
Предусловия варианта использования — это такие условия, которые должны быть выполнены, прежде чем вариант использования начнет свою работу. Например, таким условием может быть выполнение другого варианта использования или наличие у пользователя прав доступа, требуемых для запуска данного варианта использования. Не у всех вариантов использования бывают предварительные условия.
Ранее мы упоминали, что диаграммы Вариантов Использования не должны отражать порядок их выполнения. Однако с помощью предусловий можно документировать и такую информацию. Например, предусловием одного варианта использования может быть то, что в это время должен выполняться другой.
Основной и альтернативный потоки событий
Конкретные детали вариантов использования отражаются в основном в альтернативном потоках событий. Поток событий поэтапно описывает, что должно происходить во время выполнения заложенной в варианты использования функциональности. Поток событий уделяет внимание тому, что (а не как) будет делать система, причем описывает это с точки зрения пользователя. Первичный и альтернативный потоки событий содержат:
Описание того, каким образом запускается вариант использования
Различные пути выполнения варианта использования
Нормальный, или основной, поток событий варианта использования
Отклонения от основного потока событий (так называемые альтернативные потоки)
Потоки ошибок
Описание того, каким образом завершается вариант использования
Например, поток событий варианта использования "Снять деньги" может выглядеть следующим образом:
Основной поток
Вариант использования начинается, когда клиент вставляет свою карточку в ATM.
ATM выдает приветствие и предлагает клиенту ввести свой персональный идентификационный номер.
Клиент вводит номер.
ATM подтверждает введенный номер. Если номер не подтверждается, выполняется альтернативный поток событий А1.
ATM выводит список доступных действий:
Положить деньги на счет
Снять деньги со счета
Перевести деньги
Клиент выбирает пункт "Снять деньги".
ATM запрашивает, сколько денег нужно снять.
Клиент вводит требуемую сумму.
ATM определяет, достаточно ли на счету денег. Если денег недостаточно, выполняется альтернативный поток А2. Если во время подтверждения суммы возникают ошибки, выполняется поток ошибок Е1.
ATM вычитает требуемую сумму из счета клиента.
ATM выдает клиенту требуемую сумму наличными.
ATM возвращает клиенту его карточку.
Вариант использования завершается.
Альтернативный поток А1: ввод неправильного идентификационного номера
ATM информирует клиента, что идентификационный номер введен неправильно.
ATM возвращает клиенту его карточку.
Вариант использования завершается.
Альтернативный поток А2: недостаточно денег на счету
ATM информирует клиента, что денег на его счету недостаточно.
ATM возвращает клиенту его карточку.
Вариант использования завершается.
Поток ошибок Е1: ошибка в подтверждении запрашиваемой суммы
ATM сообщает пользователю, что при подтверждении запрашиваемой суммы произошла ошибка, и дает ему номер телефона службы поддержки клиентов банка.
ATM заносит сведения об ошибке в журнал ошибок. Каждая запись содержит дату и время / ошибки, имя клиента, номер его счета и код ошибки.
ATM возвращает клиенту его карточку.
Вариант использования завершается.
Документируя поток событий, можно использовать нумерованные списки (как это сделано в данном примере), ненумерованные списки, разбитый на параграфы текст и даже блок-схемы. Поток событий должен быть согласован с определенными ранее требованиями. Описывая поток, помните о тех, кто будет читать ваш документ. При его изучении заказчики будут проверять, соответствует ли он их ожиданиям, а аналитики — соответствует ли он требованиям к системе. Менеджер проекта захочет лучше понять, что же будет создано, а также сделать или обновить оценки проекта. Работая над потоком, избегайте детальных обсуждений того, как он будет реализован. Уделяйте внимание обмену информацией между пользователями и системой, но не подробному описанию ее реализации.
Постусловия
Постусловиями называются такие условия, которые должны быть выполнены после завершения варианта использования.
Работа с действующими лицами
Действующее лицо (actor) — это то, что взаимодействует с создаваемой системой. Если варианты использования описывают все, что происходит внутри области действия системы, действующие лица определяют все, что находится вне ее. На языке UML действующие лица представляют в виде фигур:
Действующие лица делятся на три основных типа: пользователи системы, другие системы, взаимодействующие с данной и время.
Первый тип действующих лиц — это физические личности. Они наиболее типичны и имеются практически в каждой системе. В системе ATM, например, к этому типу относятся клиенты и обслуживающий персонал. Называя действующих лиц, используйте их ролевые имена, а не те, что соответствуют их должности. Конкретный человек может играть множество ролей. Ролевые, а не должностные, имена обеспечивают более стабильную картину действующих лиц. Должности могут меняться время от времени, при этом роли и ответственности могут перемещаться от одной должности к другой. Используя роли для названия действующих лиц, вам не придется обновлять модель каждый раз при появлении новой должности или при изменении распределения обязанностей между ними.
Вторым типом действующих лиц является другая система. Допустим, что у банка имеется кредитная система, используемая для работы с информацией о кредитных счетах клиентов. Наша система ATM должна иметь возможность взаимодействовать с кредитной системой, в таком случае последняя становится действующим лицом. Имейте в виду, что, делая систему действующим лицом, мы предполагаем, что она не будет изменяться вообще. Помните, что действующие лица находятся вне сферы действия того, что мы разрабатываем, и, следовательно, не подлежат контролю с нашей стороны. Если мы собираемся изменять или разрабатывать и кредитную систему, то она попадает в наш проект и, таким образом, не может быть показана как действующее лицо.
Третий наиболее распространенный тип действующего лица — время. Время становится действующим лицом, если от него зависит запуск каких-либо событий в системе. Например, система ATM может каждую полночь выполнять какие-либо служебные процедуры по настройке и согласованию своей работы. Так как время не подлежит нашему контролю, оно является действующим лицом.
Поместить действующее лицо на диаграмму Вариантов Использования можно следующим образом:
Нажмите кнопку Actor (Действующее лицо) панели инструментов.
Как и варианты использования, каждое действующее лицо в Rose имеет подробные спецификации. В окне спецификации действующего лица вы можете определить его имя, стереотип, количество экземпляров (множественность — cardinality) и другие детали.
Назначение стереотипа для действующего лица
Как и в случае вариантов использования, для действующего лица в окне его спецификации может быть определен стереотип. Если вы измените существующий стереотип действующего лица, Rose автоматически изменит и пиктограмму, представляющую действующее лицо на диаграмме Вариантов Использования. Вместо символа действующего лица будет использован стандартный прямоугольник, такой же, что и для класса.
Для действующего лица не поставляется никаких других стереотипов, кроме стереотипа Actor (Действующее лицо). Однако вы всегда можете определить свои собственные стереотипы и использовать их в ваших моделях.
Для назначения действующему лицу стереотипа:
Щелкните правой кнопкой мыши на действующем лице в браузере или на диаграмме Вариантов Использования.
В открывшемся меню выберите пункт Open Specification (Открыть спецификацию).
В поле Stereotype (Стереотип) введите стереотип действующего лица.
Задание множественности действующего лица
В среде Rose можно указать, сколько экземпляров конкретного действующего лица будет использоваться. Например, существует множество людей, играющих роль действующего лица-клиента, но только один человек, играющий роль действующего лица-менеджера. Чтобы зафиксировать этот факт, можно использовать поле Cardinality (Множественность) окна спецификации.
Создание абстрактного действующего лица
Абстрактным называется действующее лицо, не имеющее экземпляров. Иными словами, его множественность равна нулю. Например, у вас может быть несколько действующих лиц: служащий с почасовой оплатой, служащий с окладом и служащий, нанятый на определенное время. Все они являются разновидностями четвертого действующего лица — служащего. Однако никто в компании не является просто служащим — каждый относится к одному из трех вышеназванных типов. Действующее лицо "Служащий1' существует только для того, чтобы показать общность между этими тремя типами. У него нет экземпляров, так что это абстрактное действующее лицо. Пример абстрактного действующего лица приведен на рис.
Подробное описание того, как рисовать стрелки между действующими лицами, приводится ниже. Для создания абстрактного действующего лица:
Создайте действующее лицо в браузере или на диаграмме Вариантов Использования.
Щелкните правой кнопкой мыши на действующем лице в браузере или на диаграмме.
В открывшемся меню выберите пункт Open Specification (Открыть спецификацию).
Выберите вкладку Detail.
Установите флажок Abstract (Абстрактный).
Работа со связями
В языке UML для вариантов использования и действующих лиц поддерживается несколько типов связей. Это связи коммуникации (communication), использования (uses), расширения (extends) и обобщения действующего лица (actor generalization). Связи коммуникации описывают связи между действующими лицами и вариантами использования. Связи использования и расширения отражают связи между вариантами использования, а связи обобщения действующего лица — между действующими лицами.
Связи коммуникации
Связь коммуникации (communicates relationship) — это связь между вующим лицом. На языке UML связь коммуникации изображают
Направление стрелки показывает, кто инициирует коммуникацию. В приведенном выше примере действующее лицо Клиент инициирует коммуникацию с системой для запуска функции "Снять деньги". Вариант использования также может инициировать коммуникацию с действующим лицом:
В данном примере вариант использования
инициирует коммуникацию с действующим
лицом Кредитная система. Когда
выполняется вариант использования
"Произвести оплату", система ATM
инициирует коммуникацию с Кредитной
системой, чтобы завершить транзакцию.
Информация при этом движется в обоих
направлениях: от ATM
к Кредитной системе и обратно; стрелка
показывает только, кто инициирует
коммуникацию.
Каждый вариант использования должен быть инициирован действующим лицом; исключения составляют лишь варианты использования в связях использования и расширения.
Для добавления связи коммуникации:
Нажмите кнопку Unidirectional Association (Однонаправленная ассоциация) панели инструментов.
Проведите мышью, удерживая ее левую кнопку, от действующего лица к варианту использования.
Между вариантом использования и действующим лицом будет показана стрелка, соответствующая связи.
Для удаления связи коммуникации:
Выделите связь на диаграмме Вариантов Использования.
В меню модели выберите пункт Edit Delete from Model (Правка Удалить из модели) или нажмите сочетание клавиш CTRL+D.
Связь использования
Связь использования (uses relationship) позволяет одному варианту использования задействовать функциональность другого. С помощью таких связей обычно моделируют многократно применяемую функциональность, встречающуюся в двух или более вариантах использования.
Связь расширения
Связь расширения (extends relationship) позволяет варианту использования только при необходимости применять функциональные возможности, предоставляемые другим вариантом использования. Она напоминает связь использования. В обоих типах отношений некоторая общая функциональность выделяется в отдельный вариант использования.
Связь обобщения действующего лица
С помощью связи обобщения действующего лица (actor generalization relationship) показывают, что у нескольких действующих лиц имеются общие черты. Например, ваши клиенты могут быть двух типов корпоративные и индивидуальные. Это отношение моделируется с помощью нотации, представленной на рис.
Работа с примечаниями
При работе над диаграммой имеет смысл связывать примечания (notes) с действующими лицами и вариантами использования. Например, иногда нужно пояснить, почему конкретное действующее лицо взаимодействует с конкретным вариантом использования, почему вариант использования участвует в связях использования или расширения или почему одно действующее лицо наследует от другого. Добавление примечаний в Rose выполняется с помощью кнопки Note (Примечание) панели инструментов.
Добавление примечаний на диаграмму
На диаграмму можно поместить примечания двух типов: собственно примечания (notes) и текстовую область (text box). В общем случае, примечания позволяют добавить комментарий к какому-то одному элементу диаграммы, а текстовая область содержит сведения, общие для всей диаграммы, например ее имя.
Поместить на диаграмму примечание можно следующим образом:
Нажмите на панели инструментов кнопку Note (Примечание).
Щелкните мышью где-нибудь внутри диаграммы, чтобы поместить туда примечание.
Выделив новое примечание, введите текст.
Для прикрепления примечания к элементу диаграммы:
Нажмите кнопку Anchor Note to Item (Прикрепить примечание к элементу) панели инструментов.
Нажав левую кнопку мыши, проведите ею от примечания к варианту использования или действующему лицу, с которым оно будет связано. Между примечанием и вариантом использования или действующим лицом будет начерчена штриховая линия.
Работа с пакетами
На языке UML такие элементы, как действующие лица, варианты использования, классы и компоненты, можно сгруппировать в пакеты (packages). В частности, в представлении Вариантов Использования можно сгруппировать в пакеты варианты использования и действующих лиц. На языке UML пакет изображается следующим образом:
Создание пакетов
Для упорядочения элементов модели в среде Rose можно создавать столько пакетов, сколько нужно. При необходимости, для лучшей организации разрешается помещать один пакет внутрь другого. При создании нового пакета Rose автоматически создает диаграмму Package Overview (Обзор пакета) и список ассоциаций (Associations list).
Для добавления пакета на диаграмму:
Щелкните правой кнопкой мыши на представлении Вариантов Использования в браузере. Чтобы вложить пакет в существующий, щелкните правой кнопкой мыши на существующем пакете в браузере.
В открывшемся меню выберите пункт New > Package (Создать > Пакет)
Введите имя нового пакета.