Идеальные и реальные прецеденты

В работе [9], приводится принцип деления прецедентов на идеальные прецеденты (essential use cases) и реальные (real use cases). На диаграммах такие прецеденты ничем не отличаются друг от друга. Говоря точнее, один и тот же прецедент может являться и идеальным, и реальным - все зависит от того, каким образом описан поток событий прецедента.

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

В качестве примера рассмотрим поток событий прецедента “Снятие наличных” из банкомата, выполненный в идеальной форме.

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

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

Реальные прецеденты – конкретно описывают процесс в терминах проектных решений, на основе конкретных технологий ввода-вывода информации. Когда речь заходит об интерфейсе пользователя, реальные прецеденты зачастую определяют содержимое диалоговых окон и описывают способы взаимодействия с конкретными устройствами. Ниже приведен пример прецедента “Получение наличных”, выраженного в реальной форме.

 

 

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

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

Рекомендации по разработке диаграмм прецедентов

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

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

В некоторых источниках [3] рекомендуют общее количество актеров, вводимых в модель, не делать большим 20, а прецедентов – большим 50. В противном случае диаграмма прецедентов теряет свою наглядность и, возможно, заменяет собой одну некоторых другим диаграмм.

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

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

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

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

В своей работе [8] Боггс рекомендуют каждому заинтересованному лицу задавать следующие вопросы:

· Что он хочет делать с системой?

· Будет ли он с ее помощью работать с информацией (вводить, получать, обновлять, удалять)?

· Нужно ли будет информировать систему о каких-либо внешних событиях?

· Должна ли система в свою очередь информировать пользователя о каких-либо изменениях или событиях?

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

· Присутствует ли каждое функциональное требование к системе хотя бы в одном прецеденте? Если требование не нашло отражение в прецеденте, оно не будет реализовано.

· Учтено ли, как с системой будет работать каждое заинтересованное лицо?

· Какую информацию будет передавать системе каждое заинтересованное лицо?

· Какую информацию будет получать от системы каждое заинтересованное лицо?

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

· Учтены ли все внешние системы, с которыми будет взаимодействовать моделируемая?

· Какой информацией каждая внешняя система будет обмениваться с моделируемой?

 

Диаграмма состояний

Общие сведения

Любая информационная система харак­теризуется некото­рым поведением и функциональностью. Для общего представления функциональности предназначены диаграммы прецедентов, описывающие на концептуальном уровне сервисы, которые предоставляет актерам моделируемая система. Для того, чтобы выяснить, в процессе какого поведения система реализует эту функциональность в языке UML применяются сразу несколько канонических диаграмм, одной из которых является  диаграмма состояний (statechart diagram).

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

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

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

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

Автоматы

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

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

Рисунок 4.1. Простейшая диаграмма состояний

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

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

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

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

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

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

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

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

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

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

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

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

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

· Граф автомата не должен содержать изолированных состояний и переходов. Это условие означает, что для каждого из состояний, кроме начального, должно быть определено предшествующее состояние. Каждый переход должен обязательно соединять два состояния автомата. Допускается переход из состояния в себя, такой переход еще называют "петлей".

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

Таким образом, правила поведения объекта, моделируемого некоторым автоматом, определяются общим формализмом автомата и его графическим изображением в языке UML посредством диаграммы состояний.

Состояние

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

Состояние на диаграмме изображается прямоугольником со скругленными вершинами, как показано на рис. 4.2. Этот прямоугольник может быть разделен на две секции горизонтальной линией. Если указана лишь одна секция, то в ней записывается только имя состояния. В противном случае в первой из них записывается имя состояния, а во второй — список внутренних действий.

Рисунок 4.2. Графическое изображение состояний на диаграмме

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

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

<метка действия> '/' <выражение действия>.

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

entry — метка указывает на действие, специфицированное следующим за ней выражением действия, которое выполняется в момент входа в данное состояние (входное действие);

exit — эта метка указывает на действие, специфицированное следующим за ней выражением действия, которое выполняется в момент выхода из данного состояния (выходное действие);

do — эта метка специфицирует деятельность ("do activity"), которая выполняется в течение всего времени, пока объект находится в данном состоянии.

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