2.3.1. Текстовые описания

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

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

Сценарий варианта использования Увольнение по собственному желанию
1. Сотрудник пишет заявление
2. Начальник подписывает заявление
3. Если есть неиспользованный отпуск, 
   то бухгалтерия рассчитывает компенсацию
4. Бухгалтерия рассчитывает выходное пособие
5. Системный администратор удаляет учетную запись
6. Менеджер персонала обновляет базу данных 

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

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

2.3.2. Реализация программой на псевдокоде

Разработчики чаще всего описывают алгоритмы с помощью программ — текстов на некотором языке.

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

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

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

Тем не менее, рассмотрим пример реализации вариантов использования на псевдокоде^∇.

Параллельно советуем смотреть на рис. Зависимости между вариантами использования).

Use case Self Fire
    Получить заявление
add_payment:
    Pay Compensation(Self Fire, add_payment)
    Include Delete Account
    Обновить информацию в базе данных

Use case Adm Fire
    Получить приказ
add_payment:
    Pay Compensation(Adm Fire, add_payment)
    Include Delete Account
    Обновить информацию в базе данных

Use case Pay Compensation
    if (add_payment)
        if (from Self Fire)
            начислить за неиспользованный отпуск
        else if (from Adm Fire)
            начислить выходное пособие

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

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

Вариант использования Pay Compensation запускается, если есть условия для выплаты компенсаций. При этом основные варианты использования не должны знать, каковы эти условия и как рассчитывается компенсация ‒ за это отвечает вариант использования Pay Compensation. Зависимость со стереотипом «extend» означает, что псевдокод варианта использования Pay Compensation должен быть включен в текст основных вариантов использования. При этом вариант использования Pay Compensation должен знать, в какое место ему нужно включиться. Для этого в основных вариантах использования определена точка расширения (extension point) ‒ по сути, просто метка в программе^∇.

Мы надеемся, что этот пример в достаточной мере объясняет сходство и различие между зависимостями со стереотипом «include» и «extend».

2.3.3. Реализация диаграммами деятельности

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

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

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

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

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

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

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

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

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

2.3.4. Реализация диаграммами взаимодействия

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

Рассмотрим основные достоинства и недостатки реализации варианта использования диаграммами взаимодействия. Начнем с положительного. На диаграммах взаимодействия представлено взаимодействие объектов, т. е. экземпляров некоторых классов. Тем самым построение такой диаграммы с необходимостью приводит к выявлению некоторых классов, которые должны существовать в модели и некоторых операций этих классов (а именно тех, которые появятся в форме сообщений типа "вызов операции" на диаграмме взаимодействия)^∇. Более того, поскольку сообщения передаются от объекта к объекту вдоль связей (в основном, экземпляров ассоциаций), то оказываются выявленными и некоторые необходимые ассоциации. Таким образом, реализация варианта использования какой-либо диаграммой взаимодействия обеспечивает органичный переход от моделирования использования к моделированию структуры и моделированию поведения.

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

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

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

Если алгоритм выполнения варианта использования линеен (просто последовательность действий, без ветвлений и циклов), то проблемы нет ‒ линейные алгоритмы суть протоколы своего выполнения. Для ветвлений и циклов диаграммы взаимодействия содержат некоторые (см. главу 4) средства моделирования. Иногда этих средств может оказаться достаточно.

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

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

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

На приведенной диаграмме последовательность посылаемых сообщений примерно соответствует последовательности действий на диаграмме деятельности рис. Реализация варианта использования при помощи диаграммы деятельности в том случае, когда поток управления проходит по диаграмме сверху вниз один раз. Таким образом, представленная диаграмма последовательности до некоторой степени определяет типовой сценарий варианта использования Hire Person. Однако, помимо определения последовательности выполняемых действий, эта диаграмма содержит и другую информацию, существенную для дальнейшего проектирования^∇.

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

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

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

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

Возвращаясь к нашему примеру, заметим, что предыдущая диаграмма последовательности семантически не полна: она не отражает все сценарии варианта использования, которые мы выявили. Сравните.

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

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

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