Новиков Ф.А. Учебно-методическое пособие по дисциплине Анализ и проектирование на UML

Подождите немного. Документ загружается.

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

использования зависит от другого варианта использования.

В UML имеются два стандартных стереотипа зависимости между вариантами

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

•

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

включает в себя в качестве подпоследовательности действий сценарий

зависимого варианта использования;

•

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

может быть в определенном месте вставлен в качестве подпоследовательности

действий сценарий независимого варианта использования.

На первый взгляд не очень понятно, чем отличается семантика этих

зависимостей — ведь обе они отражают отношение включения для

последовательностей действий. Нам будет удобнее объяснить тонкости семантики

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

примерами.

Рассмотрим еще раз вариант использования увольнение сотрудника (один из самых

сложных в реальных системах управления персоналом). Известно, что при

увольнении сотрудника следует в целях информационной безопасности удалить

(или заблокировать) учетную запись пользователя в локальной сети организации.

Причем эта последовательность действий должны быть выполнена в любом

сценарии увольнения. С другой стороны, при выполнении определенных условий,

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

неиспользованный отпуск, выходное пособие при сокращении и т. д.). Все это

примеры последовательностей действий (т. е. вариантов использования), которые

вполне могут быть востребованы как при увольнении, так и помимо него.

Отношения зависимости между всеми этими вариантами использования могут

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

рис. 2.9.

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

отдела кадров

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

После того, как построено представление использования, то есть выделены

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

ними, встает естественный вопрос: что дальше? То есть, как далее следует

продолжать моделирование средствами UML?

Вообще говоря, ответ может быть такой: ничего больше не делать на UML.

Представление использования, если оно тщательно продумано и детально

прорисовано, является формой технического задания, содержащей достаточно

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

методом. Может статься, что в коллективах программистов, в совершенстве

владеющих какой-либо другой методикой проектирования и реализации, такое

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

Однако, UML содержит средства не только для моделирования использования, но и

для поддержки всех

остальных фаз процесса разработки, и эти средства по

меньшей мере не хуже альтернативных. Таким образом, UML полезно знать, даже

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

Поэтому мы рассмотрим все средства UML в оставшейся части книги. Цель этого

параграфа — изложить наше видение возможных путей перехода от

моделирования использования к других видам моделирования.

Действующие лица находятся вне системы — с ними ничего делать не нужно.

Можно сказать, что действующие лица уже выполнили свою задачу, просто

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

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

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

показали, что делает система, теперь нужно определить, как это делается. Это

обычно называется реализацией вариантов использования.

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

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

составить текстовое описание типичного сценария варианта использования.

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

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

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

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

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

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

4. Бухгалтерия рассчитывает выходное пособие

Системный администратор удаляет учетную запись

Менеджер штатного расписания обновляет базу данных

Казалось бы что здесь неясного? А неясно, например, во что: как должна вести себя

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

не только не ясен ответ, но, хуже того, при невнимательном чтении можно и не

заметить, что есть вопрос.

Текстовые описания сценариев всем хороши: просты, всем понятны, легко и

быстро составляются. Плохи они тем, что могут быть неполны и неточны, и эти

недостатки незаметны.

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

Повторим еще раз: вариант использования — это описание множества

последовательностей действий, доставляющих значимый для действующего лица

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

последовательностей действий состоит в указании алгоритма, выполнение

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

Чаще всего алгоритмы указывают с помощью программ — текстов на некотором

языке.

Если программа предназначена для выполнения компьютером, то она должна быть

записана на сугубо формальном (и на сегодняшний день довольно примитивном)

языке, который называют в этом случае языком программирования. Если же

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

человеком, то можно применить менее формальный (и более удобный) язык,

который в этом случае обычно называют псевдокодом. Обычно в псевдокод

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

неформальные выражения на естественном языке, обозначающие выполняемые

действия. Эти выражения должны быть понятны человеку, который пишет (или

читает) программу на псевдокоде, но совсем

не обязаны быть допустимыми

выражениями языка программирования. Текст на псевдокоде похож на код

программы на языке программирования, но таковым не является — отсюда и

название.

Последовательность действий при конкретном выполнении алгоритмы называется протоколом

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

рассматривать как протокол выполнения алгоритма варианта использования.

Метод пошагового уточнения

Метод пошагового уточнения при разработке программ был

предложен Н. Виртом в период развития структурного

программирования. Суть состоит в том, что на первом шаге

выписывается (очень короткая) программа на псевдокоде, содержащая

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

этих обозначений раскрывается (уточняется) с помощью своего текста

на псевдокоде, возможно с

введением новых обозначений для более

мелких частей алгоритма. Затем вновь введенные обозначения в свою

очередь раскрываются и так далее, пока процесс уточнения не дойдет

до уровня исполнимого языка программирования.

Метод пошагового уточнения предполагает строгое следование

дисциплине структурного программирования и хорошо работает при

проектировании сверху вниз. С его помощью получаются понятные

хорошо документированные программы. При разработке программы

для отдельного действительно сложного алгоритма этот метод

является, видимо, одним из наилучших среди известных методов

конструирования программ. Однако метод пошагового уточнения

напрямую никак не связан с парадигмой объектно-ориентированного

программирования. Современный стиль программирования имеет

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

классов, каждый

из которых имеет очень простые (с алгоритмической

точки зрения) операции. Таким образом, область применимости метода

пошагового уточнения сужается.

Первый способ реализации варианта использования — записать алгоритм на

псевдокоде. Этот способ хорош тем, что понятен, привычен и доступен любому.

Однако в настоящее время вряд ли можно рекомендовать такой способ реализации,

как основной, по следующим причинам.

• Реализация на псевдокоде плохо согласуется с современной парадигмой

объектно-ориентированного программирования.

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

UML: наглядная визуализация с помощью картинки, строгость и точность

языка проектирования и реализации, поддержка распространенными

инструментальными средствами.

•

Решения на псевдокоде практически невозможно использовать повторно.

Тем не менее, рассмотрим пример реализации вариантов использования на

псевдокоде (см. рис. 2.10).

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

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

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

В этих текстах использовано ключевое слово

include, отражающее наличие

зависимостей с таким стереотипом в модели. А именно, это означает, что в этом

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

текст псевдокода для варианта использования

DeleteAccount.

Вариант использования PayCompensation запускается, если есть условия для

выплаты компенсаций. При этом основные варианты использования не должны

знать, каковы эти условия и как рассчитывается компенсация — за это отвечает

вариант использования PayCompensation. Зависимость со стереотипом «extend»

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

включен в текст основных вариантов использования. При этом вариант

использования PayCompensation должен знать, в какое место ему нужно

включиться. Для этого в основных вариантах использования определена точка

расширения — а по сути просто метка в программе.

Мы надеемся, что этот пример в достаточной мере объясняет сходство и различие

между зависимостями со стереотипом include и extend. В обоих случаях речь о

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

состоит в том, где хранится информация о включении.

В случае стереотипа «

include» включающая программа знает имя включаемой, а

включаемая программа не обязана знать, что ее куда-то включают. В случае

стереотипа «extend» наоборот, включаемая программа знает имя включающей, а

включающая программа не обязана знать, что в нее что-то включают. Поскольку

включающая программа знает свою структуру, то при использовании стереотипа

include» ей не нужно никакой дополнительной информации о месте включения.

Напротив, поскольку включаемая программа не знает структуры включающей

программы, то при использовании стереотипа «

extend» включаемой программе

нужна информация о месте включения — имя точки расширения, то есть метки в

тексте включающей программы.

Для зависимости со стереотипом include никакой метки не нужно: место включения

определяется тем, где стоит ключевое слово include.

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

Третий способ реализации варианта использования — описать алгоритм с

помощью диаграммы деятельности. С одной стороны, диаграмма деятельности —

это полноценная диаграмма UML, с другой стороны, диаграмма деятельности

немногим отличается от блок-схемы (а тем самым и от псевдокода). Таким

образом, реализация варианта использования диаграммой деятельности является

компромиссным способом ведения разработки — в сущности, это проектирование

сверху вниз в терминах и обозначениях UML.

Например, в информационной системе отдела кадров прием сотрудника может

быть организован так, как показано на рис. 2.11.

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

системы отдела кадров при помощи диаграммы деятельности

Приблизило ли нас появление этой диаграммы в модели к завершению работы над

системой? С одной стороны, вместо одной сущности, подлежащей реализации

(вариант использования

HirePerson) появилось пять новых: три сторожевых

условия и две деятельности, которые в свою очередь теперь нуждаются в

реализации. С другой стороны, каждая из этих новых сущностей кажется более

простой и понятной, а значит быстрее и надежнее реализуемой. Кроме того, эту

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

проектируемая нами логика

работы системы соответствует тому бизнес-процессу,

который существует в реальности.

Применение диаграмм активности для реализации вариантов использования не

слишком приближает к появлению целевого артефакта — программного кода,

Большинство инструментов не генерируют никакого кода по диаграммам активности.

однако может привести к более глубокому пониманию существа задачи и даже

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

усмотреть в первоначальной постановке задачи.

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

что процесс может иметь три исхода.

•

Нормальное завершение, которое предполагает обязательное выполнение

деятельности

FillPosition. Резонно предположить, что при выполнении этой

деятельности в базу данных будет записана какая-то информация, что,

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

• Исключительная ситуация, возникающая в том случае, когда процесс не может

быть нормально завершен (мы хотели принять человека на работу, и он был

согласен, а текущее состояние штатного расписание не позволило этого

сделать). Факт возникновения такой ситуации, хотя формально и не является

значимым результатом для менеджера персонала, на самом деле может быть

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

• Завершение процесса без достижения какого-либо видимого результата.

Например, менеджер персонала сделал кандидату какие-то предложения, но ни

одно из них кандидата не устроило, после чего они расстались, как будто

ничего и не было.

Этот простой анализ наталкивает на следующие соображения. Вариант

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

нет, то что-то спроектировано не так, как нужно. Действительно, все известные нам

практические информационные системы отдела кадров обязательно накапливают

статистическую информацию о всех проведенных кадровых операциях. Такая

статистика совершенно необходима для так называемого анализа движения

кадров — важной составляющей процесса управления организацией. Однако

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

тем, учет этой информации, например, учет причин, по которым кандидаты не

принимают предложенной работы или, наоборот, причин, по которым организации

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

формирования кадровой политики организации.

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

можем усовершенствовать нашу диаграмму, например так, как показано на

рис. 2.12.

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

информационной системы отдела кадров

Вот теперь (формально) все хорошо: информация не теряется. Более того, имеет

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

включить в модель новые варианты использования (может быть, как

низкоприоритетные и подлежащие реализации в последующих версиях системы).

Так реализация вариантов использования может приводить к изменению и

усовершенствованию самих вариантов использования. Моделирование имеет

итеративный характер, о чем мы уже говорили в главе 1.

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

Четвертый из основных способов реализации варианта использования — создать

диаграмму взаимодействия (в форме диаграммы кооперации или диаграммы

последовательности), которая описывает сценарий данного варианта

использования. Этот способ в наибольшей степени соответствует идеологии UML

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

Рассмотрим основные достоинства и недостатки реализации варианта

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

• На диаграмме взаимодействия представлено взаимодействие объектов, т. е.

экземпляров некоторых классов. Тем самым построение такой диаграммы с

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

существовать в модели и некоторых операций этих классов (а именно тех,

которые появятся в форме сообщений типа вызова операции на диаграмме

взаимодействия). Более того, поскольку сообщения передаются вдоль связей

(экземпляров ассоциаций), оказываются выявленными и некоторые

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

диаграммой взаимодействия обеспечивает органичный переход от

моделирования использования к моделированию структуры (глава 4) и

поведения (глава 5).

• При составлении диаграмм взаимодействия для нескольких вариантов

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

разные роли в различных кооперациях (см. главу 5). Одинаковое поведение и

структура, проявляющиеся в разных вариантах использования, оказываются

реализованными одним классом. Такой стиль моделирования полностью

соответствует объектно-ориентированному подходу и обеспечивает

концептуальную целостность проектируемой системы.

• При реализации вариантов использования диаграммами взаимодействия на

ранних этапах моделирования появляются сопутствующие фрагменты

диаграмм классов (и, может быть, диаграмм реализации). Эти диаграммы

гораздо ближе к целевому артефакту — программному коду — нежели

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

поддерживают генерацию кода по диаграммам классов, а некоторые — и по

диаграммам взаимодействия. Таким образом, появляется возможность

автоматизированного построения прототипов (версий системы,

обеспечивающих функциональность частично), что полностью соответствует

идеологии инкрементальной разработки.

Однако у диаграмм взаимодействия UML есть существенное ограничение. В целом

эти диаграммы формулируются на уровне объектов, а потому позволяют

реализовать только отдельный сценарий (экземпляр варианта использования).

Другими словами, диаграммы взаимодействия позволяют описать протокол

выполнения алгоритма, но не сам алгоритм, они не являются универсальной

моделью вычислимости. Возникает вопрос: насколько существенным и

обременительным оказывается это ограничение при практическом моделировании?

Если алгоритм варианта использования линеен (просто последовательность

действий, без ветвлений и циклов), то проблемы нет — линейные алгоритмы суть

протоколы выполнения. Для ветвлений и циклов диаграммы взаимодействия

содержат некоторые (весьма ограниченные, см. главу 5) средства моделирования.

Иногда этих средств может оказаться достаточно.

Что же делать, если все-таки никак не удается построить исчерпывающую

диаграмму взаимодействия для варианта использования? В этом случае

рекомендуется применять следующие методы. Во-первых, реализовать вариант

использования несколькими диаграммами взаимодействия. Каждая диаграмма

описывает отдельный сценарий, а все вместе они дают достаточное представление

об алгоритме варианта использования. Во-вторых, можно пересмотреть

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

реализуемые варианты использования. Например, с помощью обобщения выделить

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

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

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

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

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

Visio, даже не поддерживают использование деятельности, определенной на одной диаграмме, в

другой диаграмме.

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

множества сценариев и легче реализуются диаграммами взаимодействия. Обычно

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

результат.

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

взаимодействия варианта использования прием сотрудника на работу

информационной системы отдела кадров.

Сначала рассмотрим типовой сценарий, когда прием проходит безо всяких

осложнений: есть вакантное рабочее место и кандидат готов его занять. Диаграмма

последовательности для такого сценария приведена на рис. 2.13.

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

информационной

системы отдела кадров

На приведенной диаграмме (рис. 2.13) последовательность посылаемых сообщений

примерно соответствует последовательности действий на диаграмме деятельности

(см. рис. 2.12) в том случае, когда поток управления проходит по диаграмме сверху

вниз один раз. Таким образом, диаграмма 2.13 до некоторой степени определяет

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

HirePerson. Однако, помимо

определения последовательности выполняемых действий диаграмма 2.13 содержит

и другую информацию, существенную для дальнейшего проектирования. А

именно, построив такую диаграмму, мы постулировали существование в системе

некоторых классов (возможно, еще не всех), объекты которых должны

взаимодействовать для обеспечения требуемого поведения моделируемого

варианта использования. Действующее лицо

PersonnelManager уже было

определено при моделировании использования, здесь же в нашей модели

появились новые сущности:

• класс HireForm, ответственный за интерфейс, необходимый для выполнения

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

•

класс Person, ответственный за хранение данных о конкретном человеке;

•

класс Position, ответственный за хранение данных и выполнение операций с

конкретной должностью.