Диаграммы использования

Диаграмма использования является основным средством моделирования использования в UML. На диаграмме использования применяются следующие типы сущностей:

• действующие лица;

• варианты использования;

• примечания;

• пакеты.

Между этими сущностями устанавливаются следующие типы отношений:

• ассоциация между действующим лицом и вариантом использования;

• обобщение между действующими лицами;

• обобщение между вариантами использования;

• зависимости (двух стереотипов) между вариантами использования;

• зависимости между пакетами.

На рисунке 2.1. представлена графическая нотация элементов диаграмм использования, справедливая дл версии UML 2.0.

Рисунок 2.1. Нотация диаграмм использования (UML 2.0)

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

Действующие лица. Вопрос о выделении (или идентификации) действующих лиц при составлении модели — один из самых болезненных. Неудачный выбор действующих лиц может отрицательно повлиять на всю модель в целом. Здесь легко впасть в крайность: объявить, что имеется одно действующее лицо (внешний мир), взаимодействующее со всеми вариантами использования или, наоборот, придумать искусственных действующих лиц для каждого варианта использования. Формального метода идентификации действующих лиц не существует. Перечислим некоторые приемы, которые полезно, по нашему мнению, иметь в виду при выделении действующих лиц и покажем применение этих приемов на нашем сквозном примере. Для начала укажем более детальное определение действующего лица.

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

Роль в UML — это интерфейс, поддерживаемый данным классификатором в данной ассоциации.

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

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

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

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

В первом приближении выделяем две категории пользователей:

• менеджер персонала, который работает с конкретными людьми;

• менеджер штатного расписания, который работает с абстрактными должностями и подразделениями.

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

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

На рисунке 2.2 показано формирование представление использования информационной системы отдела кадров. Менеджер персонала имеет имя Personnel Manager, а менеджер штатного расписания — Staff Manager, в соответствии с используемой дисциплиной имен.

Рисунок 2.2. Действующие лица информационной системы отдела кадров

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

• набор различных характеристик именуемых объектов (и области значений этих характеристик), которые учитываются в данной дисциплине;

• набор правил формирования имен по заданным значениям выбранных характеристик (с учетом возможных лексических ограничений системы программирования);

• набор операций (помимо операции чтения человеком), которые выполняются над множествами имен.

Важным вопросом при формировании имен является выбор набора символов. Для идентификаторов в программах обычно используют буквы латинского алфавита. Для содержательных (семантических) частей желательно, чтобы имена являлись узнаваемыми словами или словосочетаниями. Использование транслитерированных русских слов выглядит ужасно. Использование правильных английских слов хорошо, но требует, чтобы все читатели и писатель программы одинаково владели английским. Выход заключается в том, чтобы составить жаргонный словарь из слов, сокращений и аббревиатур и пользоваться только им.^[3]

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

Выделение вариантов использования — ключ ко всему дальнейшему моделированию. На этом этапе определяется функциональность системы, то есть, что она должна делать.

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

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

Каждая конкретная последовательность действий называется сценарием. Таким образом, вариант использования является классификатором (см. главу 3), экземплярами которого являются сценарии.

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

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

• прием сотрудника;

• перевод сотрудника;

• увольнение сотрудника;

• создание подразделения;

• ликвидация подразделения;

• создание вакансии;

• сокращение должности;

Опираясь на знание предметной области, которое не отражено в техническом задании (характерный случай), заметим, что термин "вакансия" является сокращением оборота "вакантная должность", то есть должность в некотором особом состоянии. Само же слово "должность" многозначно. Это может быть и обозначение конкретного рабочего места — позиции в штатном расписании, и обозначение совокупности таких позиций, имеющих общие признаки: функциональные обязанности, зарплата и т. п. Например: "в организации различаются должности: программист, аналитик, руководитель проекта" или "в отделе разработки предусмотрены 9 программистов, 3 аналитика и 2 руководителя проектов". Кадровые работники легко различают эти случаи по контексту. Примем рабочую гипотезу о том, что автор технического задания использовал слово должность в первом смысле и получим набор вариантов использования, представленный на рисунке 2.3.

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

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

В отличии от большинства языков программирования примечания в UML синтаксически оформлены с помощью специальной нотации и выступают на тех же правах, что и остальные сущности. А именно, примечание имеет свою графическую нотацию — прямоугольник с загнутым уголком, к котором находится текст примечания. Примечания могут находиться в отношении соответствия с другими сущностями — эти отношения изображаются пунктирной линией без стрелок.

Примечания содержат текст, который вводит пользователь — создатель модели. Это может быть текст в произвольном формате: на естественном языке, на языке программирования, на формальном логическом языке, например, OCL и т. д. Более того, если возможности инструмента это позволяют, в примечаниях можно хранить гиперссылки, вложенные файлы и другие внешние по отношению к модели артефакты.

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

Примечания могут иметь стереотипы. В UML определены два стандартных стереотипа для примечаний:

• requirement — описывает общее требование к системе;

• responsibility — описывает ответственность класса.

Примечания первого типа часто применяют в диаграммах использования, а примечания второго типа — в диаграммах классов.

Возвращаясь к нашему примеру, будет совсем не лишним указать, что информацию о состоянии кадров нужно хранить постоянно, т. е. она не должна исчезать после завершения сеанса работы с системой (Рисунок 2.4).

Рисунок 2.4. Требование к информационной системе отдела кадров

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

• ассоциация между действующим лицом и вариантом использования;

• обобщение между действующими лицами;

• обобщение между вариантами использования;

• зависимости между вариантами использования;

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

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

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

Рисунок 2.5. Ассоциации между действующими лицами и вариантами использования информационной системы отдела кадров

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

Такое обобщение является весьма мощным средством моделирования.

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

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

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

Рисунок 2.7. Абстрактное действующее лицо в информационной системе отдела кадров

Обобщение между вариантами использования показывает, что один вариант использования является частным случаем (подмножеством множества сценариев) другого варианта использования.

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

Рисунок 2.8. Обобщение между вариантами использования в информационной системе отдела кадров

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

В UML имеются два стандартных стереотипа зависимости между вариантами использования, которые в некотором смысле двойственны друг другу:

• include — показывает, что сценарий независимого варианта использования включает в себя в качестве подпоследовательности действий сценарий зависимого варианта использования;

• extend — показывает, что в сценарий зависимого варианта использования может быть в определенном месте вставлен в качестве подпоследовательности действий сценарий независимого варианта использования.

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

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

Рисунок 2.9. Зависимости между вариантами использования в информационной системе отдела кадров

2.3 Реализация вариантов использования

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

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

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

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

■ Увольнение по собственному желанию

1. Сотрудник пишет заявление

2. Начальник подписывает заявление

3. Если есть неиспользованный отпуск,