то бухгалтерия рассчитывает компенсацию

1. Бухгалтерия рассчитывает выходное пособие
2. Системный администратор удаляет учетную запись
3. Менеджер штатного расписания обновляет базу данных

При более внимательном прочтении неясно, например, как должна вести себя система, если на шаге 2 начальник НЕ подписывает заявление. Из текста сценария не только не ясен ответ, но, хуже того, при невнимательном чтении можно и не заметить, что есть вопрос.

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

Наиболее часто используемый метод описания множества последовательностей действий состоит в указании алгоритма. Чаще всего алгоритмы указывают с помощью программ — текстов на некотором языке.

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

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

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

Тем не менее, рассмотрим пример реализации вариантов использования на псевдокоде (Рисунок 2.10).

Рисунок 2.10. Реализация вариантов использования при помощи программы на псевдокоде

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

В этих текстах использовано ключевое слово include, отражающее наличие зависимостей с таким стереотипом в модели. А именно, это означает, что в этом месте в текст псевдокода для данного варианта использования нужно включить текст псевдокода для варианта использования DeleteAccount.

Вариант использования PayCompensation запускается, если есть условия для выплаты компенсаций. При этом основные варианты использования не должны знать, каковы эти условия и как рассчитывается компенсация — за это отвечает вариант использования PayCompensation. Зависимость со стереотипом «extend» означает, что псевдокод варианта использования PayCompensation должен быть включен в текст основных вариантов использования. При этом вариант использования PayCompensation должен знать, в какое место ему нужно включиться. Для этого в основных вариантах использования определена точка расширения — а по сути просто метка в программе.

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

В случае стереотипа «include» включающая программа знает имя включаемой, а включаемая программа не обязана знать, что ее куда-то включают. В случае стереотипа «extend» наоборот, включаемая программа знает имя включающей, а включающая программа не обязана знать, что в нее что-то включают. Поскольку включающая программа знает свою структуру, то при использовании стереотипа «include» ей не нужно никакой дополнительной информации о месте включения. Напротив, поскольку включаемая программа не знает структуры включающей программы, то при использовании стереотипа «extend» включаемой программе нужна информация о месте включения — имя точки расширения, то есть метки в тексте включающей программы.

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

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

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

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

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

Например, рассматривая схему процесса на рисунке 2.11, мы видим, что процесс может иметь три исхода.

• Нормальное завершение, которое предполагает обязательное выполнение деятельности FillPosition. Резонно предположить, что при выполнении этой деятельности в базу данных будет записана какая-то информация, что, несомненно, является значимым для пользователя результатом.
• Исключительная ситуация, возникающая в том случае, когда процесс не может быть нормально завершен (мы хотели принять человека на работу, и он был согласен, а текущее состояние штатного расписание не позволило этого сделать). Факт возникновения такой ситуации, хотя формально и не является значимым результатом для менеджера персонала, на самом деле может быть весьма важен для высшего руководства или менеджера штатного расписания.
• Завершение процесса без достижения какого-либо видимого результата. Например, менеджер персонала сделал кандидату какие-то предложения, но ни одно из них кандидата не устроило, после чего они расстались, как будто ничего и не было.

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

Немного подумав над этой проблемой (или посоветовавшись с заказчиком), мы можем усовершенствовать нашу диаграмму, например так, как показано на рисунке 2.12.

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

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

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

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

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

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

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

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

Сначала рассмотрим типовой сценарий, когда прием проходит безо всяких осложнений: есть вакантное рабочее место и кандидат готов его занять. Диаграмма последовательности для такого сценария приведена на рисунке 2.13.

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

На приведенной диаграмме (Рисунок 2.13) последовательность посылаемых сообщений примерно соответствует последовательности действий на диаграмме деятельности (Рисунок 2.12) в том случае, когда поток управления проходит по диаграмме сверху вниз один раз. Таким образом, диаграмма 2.13 до некоторой степени определяет типовой сценарий варианта использования HirePerson. Однако, помимо определения последовательности выполняемых действий диаграмма 2.13 содержит и другую информацию, существенную для дальнейшего проектирования. А именно, построив такую диаграмму, мы постулировали существование в системе некоторых классов (возможно, еще не всех), объекты которых должны взаимодействовать для обеспечения требуемого поведения моделируемого варианта использования. Действующее лицо PersonnelManager уже было определено при моделировании использования, здесь же в нашей модели появились новые сущности:

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

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

Заметим, что диаграмма 2.13 семантически не полна: она не отражает все сценарии варианта использования, которые предусматриваются, например, диаграммой 2.12. Как уже было сказано, в этом случае можно составить дополнительные диаграммы взаимодействия, реализующие альтернативные сценарии варианта использования. Например, на рисунке 2.14 показан сценарий приема сотрудника, соответствующий исключительной ситуации, когда нет вакантных должностей. На этот раз мы представим сценарий в форме диаграммы кооперации (коммуникации).

Рисунок 2.14. Диаграмма кооперации для исключительной ситуации при приеме сотрудника информационной системы отдела кадров

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

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

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