2.2.1. Действующие лица

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

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

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

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

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

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

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

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

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

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

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

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

2.2.2. Варианты использования

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

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

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

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

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

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

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

2.2.3. Комментарии

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

В отличие от большинства языков программирования комментарии в UML синтаксически оформлены с помощью специальной нотации и выступают на тех же правах, что и остальные сущности^∇. А именно, комментарий имеет свою графическую нотацию ‒ прямоугольник с загнутым уголком ("собачье ухо"), в котором находится текст комментария. Комментарии могут находиться в отношении соответствия с другими сущностями ‒ эти отношения изображаются пунктирной линией без стрелок. Если пунктирная линия отсутствует, то комментарий относится ко всей диаграмме.

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

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

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

• «requirement» — описывает общее требование к системе;
• «responsibility» — описывает ответственность сущности (классификатора).

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

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

2.2.4. Отношения на диаграммах использования

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

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

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

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

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

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

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

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

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

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

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

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

Данное требование следует оформить в виде дополнительного варианта использования ‒ Browse. Если мы проектируем систему отдела кадров для обычной организации, а не для государственной секретной службы, то разумно предположить, что просматривать данные могут все категории пользователей. В этом случае можно установить ассоциации между новым вариантом использования и всеми действующими лицами, а можно поступить так, как показано следующем рисунке, т.е. ввести обобщенного абстрактного пользователя User 1, который будет связан ассоциацией с вариантом использования Browse 2. При этом все специализации 3 и  4 обобщенного пользователя автоматически будут связаны ассоциацией с вариантом использования Browse.

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

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

Система должна поддерживать два способа увольнения сотрудника: по инициативе администрации и по собственному желанию.        

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

Обобщенный абстрактный (имя написано курсивом) вариант использования Fire Person имеет две специализации, которые соответствуют увольнению работника по собственному желанию Self Fire и по инициативе администрации Adm Fire.

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

• «include» — показывает, что в каждый сценарий зависимого варианта использования в определенном месте вставляется в качестве подпоследовательности действий в сценарий независимого варианта использования.
• «extend» — показывает, что в некоторый сценарий независимого варианта использования может быть в определенном месте вставлен в качестве подпоследовательности действий сценарий зависимого варианта использования. Другой вариант интерпретации: в определенном месте сценария независимого варианта использования вызывается для выполнения сценарий зависимого варианта использования. При этом последовательность действий в вызываемом сценарии определяется местом, откуда он был вызван, т.е. из какого варианта использования и конкретно из какого места какого сценария этого варианта использования.

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

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

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

Учетная запись сотрудника при увольнении должна быть заблокирована.           

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

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

2.2.5. Способы применения моделей использования

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

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

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

Внутренняя часть, выделяемая границами, имеет в UML конкретное название ‒ субъект.

Если границы системы используются на диаграмме, то можно указать имя (и стереотип!), которые будут относиться к субъекту^∇.

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

В приведенных примерах действующими лицами являются категории пользователей. Это не случайно, в большинстве случаев действующими лицами в моделях UML действительно являются категории пользователей. Но оборот "в большинстве случаев" еще не означает "всегда". В самом деле, в определениях действующего лица (параграф 2.2.1) и варианта использования (параграф 2.2.2) ничто не указывает на ограничения в применении этих понятий. Выше мы отметили, что варианты использования описывают внутренность системы, а действующие лица ‒ ее окружение. Так вот, в качестве системы может выступать любая сущность, для которой можно определить функциональные или не функциональные требования. Это может быть и подсистема главной системы, отдельный компонент и просто класс. Если мы рассматриваем модель использования некоторой подсистемы, то другие подсистемы (взаимодействующие с рассматриваемой) будут действующими лицами для рассматриваемой подсистемы. Если мы рассматриваем модель использования некоторого класса, то другие классы (взаимодействующие с рассматриваемым) будут действующими лицами для рассматриваемого класса.

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

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

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

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

На следующей диаграмме действующее лицо ИС ОК ‒ это наша информационная система отдела кадров, действующее лицо ERP ‒ некоторая другая информационная система, а Adapter ‒ модуль с единственным вариантом использования. Обратите внимание, что на этой диаграмме все сущности ‒ программные системы, никаких пользователей здесь нет!