Кооперативные диаграммы

Кооперативные диаграммы отражают ту же самую информацию, что и диаграммы Последовательно­сти. Однако делают они это по-другому и с другими целями. Показанная на рис. 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 мы детальнее рассмотрим каждую из этих диаграмм и покажем, как создавать их в среде Ratio­nal 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 можно уточнить модель Вариантов Использования, а также разрабо­тать диаграммы Последовательности и Кооперативные диаграммы для графического представления потока обработки данных. Кроме того, в этой фазе проектируются диаграммы Классов, описываю­щие объекты, которые необходимо создать.

Фаза уточнения завершается, когда варианты использования полностью детализированы и одоб­рены пользователями, прототипы завершены настолько, чтобы уменьшить риски, разработаны диа­граммы Классов. Иными словами, эта фаза пройдена, когда система спроектирована, рассмотрена и готова для передачи разработчикам.

Конструирование

Конструирование - процесс разработки и тестирования программного обеспечения. Как и в случае уточнения, эта фаза выполняется для каждого набора вариантов использования на каждой итерации. Задачи конструирования включают в себя определение всех оставшихся требований, разработку и те­стирование программного обеспечения (ПО). Так как ПО полностью проектируется в фазе уточне­ния, конструирование не предполагает большого количества решений по проекту, что позволяет команде работать параллельно. Это означает, что разные группы программистов могут одновременно работать над различными объектами ПО, зная, что по завершении фазы система "сойдется". В фазе уточнения мы проектируем объекты системы и их взаимодействие. Конструирование только запуска­ет проект в действие, а новых решений по нему, способных изменить это взаимодействие, не прини­мается.

Еще одним преимуществом такого подхода к моделированию системы является то, что среда Rati­onal 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 может содержать следу­ющее описание:

Вариант использования "Перевести деньги" позволяет клиенту или служащему банка перево­дить деньги с одного счета до востребования или сберегательного счета на другой.

Следует делать описание коротким и "к месту", при этом оно должно определять типы пользовате­лей, выполняющих вариант использования, и ожидаемый ими конечный результат. Во время работы над проектом (особенно, если проект длинный) эти описания будут напоминать членам команды, по­чему тот или иной вариант использования был включен в проект и что он должен делать. Четко доку­ментируя таким образом цели каждого варианта использования, можно уменьшить неразбериху, возникающую среди разработчиков.

Предусловия

Предусловия варианта использования — это такие условия, которые должны быть выполнены, прежде чем вариант использования начнет свою работу. Например, таким условием может быть выполнение другого варианта использования или наличие у пользователя прав доступа, требуемых для запуска дан­ного варианта использования. Не у всех вариантов использования бывают предварительные условия.

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

Основной и альтернативный потоки событий

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

• Описание того, каким образом запускается вариант использования

• Различные пути выполнения варианта использования

• Нормальный, или основной, поток событий варианта использования

• Отклонения от основного потока событий (так называемые альтернативные потоки)

• Потоки ошибок

• Описание того, каким образом завершается вариант использования

Например, поток событий варианта использования "Снять деньги" может выглядеть следующим образом:

Основной поток

1. Вариант использования начинается, когда клиент вставляет свою карточку в ATM.

2. ATM выдает приветствие и предлагает клиенту ввести свой персональный идентификацион­ный номер.

3. Клиент вводит номер.

4. ATM подтверждает введенный номер. Если номер не подтверждается, выполняется альтерна­тивный поток событий А1.

5. ATM выводит список доступных действий:

• Положить деньги на счет

• Снять деньги со счета

• Перевести деньги

6. Клиент выбирает пункт "Снять деньги".

7. ATM запрашивает, сколько денег нужно снять.

8. Клиент вводит требуемую сумму.

9. ATM определяет, достаточно ли на счету денег. Если денег недостаточно, выполняется альтер­нативный поток А2. Если во время подтверждения суммы возникают ошибки, выполняется по­ток ошибок Е1.

10. ATM вычитает требуемую сумму из счета клиента.

11. ATM выдает клиенту требуемую сумму наличными.

12. ATM возвращает клиенту его карточку.

13. Вариант использования завершается.

Альтернативный поток А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 (Множественность) окна спецификации.

Создание абстрактного действующего лица

Абстрактным называется действующее лицо, не имеющее экземпляров. Иными словами, его множест­венность равна нулю. Например, у вас может быть несколько действующих лиц: служащий с почасо­вой оплатой, служащий с окладом и служащий, нанятый на определенное время. Все они являются разновидностями четвертого действующего лица — служащего. Однако никто в компании не является просто служащим — каждый относится к одному из трех вышеназванных типов. Действующее лицо "Служащий¹' существует только для того, чтобы показать общность между этими тремя типами. У него нет экземпляров, так что это абстрактное действующее лицо. Пример абстрактного действующего лица приведен на рис.

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

• Создайте действующее лицо в браузере или на диаграмме Вариантов Использования.

• Щелкните правой кнопкой мыши на действующем лице в браузере или на диаграмме.

• В открывшемся меню выберите пункт 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 (Создать > Пакет)

• Введите имя нового пакета.