Контакты

Алгоритмическое представление правил игры. Создание компьютерной игры "эволюция" Диаграмма прецедентов игры человек против человека

  • 25.12.2019

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

Назначение

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

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

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

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

Элементы

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

Отношения между прецедентами

Часть дублирующейся информации в модели прецедентов можно устранить указанием связей между прецедентами :

  • обобщение прецедента - стрелка с незакрашенным треугольником (треугольник ставится у более общего прецедента),
  • включение прецедента - пунктирная стрелка со стереотипом «include»,
  • расширение прецедента - пунктирная стрелка со стереотипом «extend» (стрелка входит в расширяемый прецедент, в дополнительном разделе которого может быть указана точка расширения и, возможно в виде комментария, условие расширения)

Правила

При работе с вариантами использования важно помнить несколько простых правил:

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

Напишите отзыв о статье "Диаграмма прецедентов"

Примечания

Программирование Это заготовка статьи о программировании . Вы можете помочь проекту, дополнив её.
Просмотр этого шаблона
Акторы
Прочее
Концепции
Структура
Поведение
Отношения
Растяжимость
Диаграммы
Структурные
Поведения
Взаимодействия

Отрывок, характеризующий Диаграмма прецедентов

– Простите мою нескромность, Ваше святейшество, но, во избежание ошибки с моей стороны, не соблаговолите ли Вы мне более точно объяснить, что Вы хотели этим сказать? – очень осторожно ответила я.
Караффа мягко улыбнулся и, взяв мою дрожащую руку в свои изящные, тонкие пальцы, очень тихо произнёс:
– Вы – первая женщина на земле, мадонна Изидора, которая, по моему понятию, достойна настоящей любви... И Вы очень интересный собеседник. Не кажется ли Вам, что Ваше место скорее на троне, чем в тюрьме инквизиции?.. Подумайте об этом, Изидора. Я предлагаю Вам свою дружбу, ничего более. Но моя дружба стоит очень многого, поверьте мне... И мне очень хотелось бы Вам это доказать. Но всё будет зависеть от Вашего решения, естественно... – и, к моему величайшему удивлению, добавил: – Вы можете здесь остаться до вечера, если желаете что-то почитать; думаю, Вы найдёте здесь для себя очень много интересного. Позвоните в колокольчик, когда закончите, и Ваша служанка покажет Вам дорогу назад.
Караффа был спокоен и сдержан, что говорило о его полной уверенности в своей победе... Он даже на мгновение не допускал мысли, что я могла бы отказаться от такого «интересного» предложения... И уж особенно в моём безысходном положении. А вот именно это и было самым пугающим... Так как я, естественно, собиралась ему отказать. Только, как это сделать я пока что не имела ни малейшего представления...
Я огляделась вокруг – комната потрясала!.. Начиная с вручную сшитых переплётов старейших книг, до папирусов и рукописей на бычьей коже, и до поздних, уже печатных книг, эта библиотека являлась кладезем мировой мудрости, настоящим торжеством гениальной человеческой Мысли!!! Это была, видимо, самая ценная библиотека, которую когда-либо видел человек!.. Я стояла, полностью ошеломлённая, завороженная тысячами со мной «говоривших» томов, и никак не могла понять, каким же образом это богатство могло ужиться здесь с теми проклятиями, которые так яро и «искренне» сыпала на им подобное инквизиция?... Ведь для настоящих инквизиторов все эти книги должны были являться самой чистой ЕРЕСЬЮ, именно за которую люди горели на кострах, и которая категорически запрещалась, как страшнейшее преступление против церкви!.. Каким же образом здесь, в подвалах Папы, сохранились все эти ценнейшие книги, которые, якобы, во имя «искупления и очищения душ», до последнего листочка, сжигались на площадях?!.. Значит, всё, что говорили «отцы-инквизиторы», всё, что они творили – было всего лишь страшной завуалированной ЛОЖЬЮ! И эта безжалостная ложь глубоко и крепко сидела в простых и открытых, наивных и верующих человеческих сердцах!.. Подумать только, что я когда-то была абсолютно уверена, что церковь была искренна в своей вере!.. Так как любая вера, какой бы странной она не казалась, для меня всегда воплощала в себе искренний дух и веру человека во что-то чистое и высокое, к чему, во имя спасения, стремилась его душа. Я никогда не была «верующей», так как я верила исключительно в Знание. Но я всегда уважала убеждения других, так как, по моему понятию, человек имел право выбирать сам, куда направить свою судьбу, и чужая воля не должна была насильно указывать, как он должен был проживать свою жизнь. Теперь же я ясно видела, что ошиблась... Церковь лгала, убивала и насиловала, не считаясь с такой «мелочью», как раненая и исковерканная человеческая душа...
Как бы я не была увлечена увиденным, пора было возвращаться в действительность, которая для меня, к сожалению, в тот момент не представляла ничего утешительного...
Святой Отец Церкви, Джованни Пьетро Караффа любил меня!.. О, боги, как же он должен был за это меня ненавидеть!!! И насколько сильнее станет его ненависть, когда он вскоре услышит мой ответ...
Я не могла понять этого человека. Хотя, до него, чуть ли не любая человеческая душа была для меня открытой книгой, в которой я всегда могла свободно читать. Он был совершенно непредсказуем, и невозможно было уловить тончайшие изменения его настроений, которые могли повлечь за собой ужасающие последствия. Я не знала, сколько ещё смогу продержаться, и не знала, как долго он намерен меня терпеть. Моя жизнь полностью зависела от этого фанатичного и жестокого Папы, но я точно знала только одно – я не намерена была лгать. Что означало, жизни у меня оставалось не так уж много...

Лекция 6:

Диаграммы прецедентов: крупным планом

Несколько слов о требованиях

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

Если обратиться к классикам, например, к той же "банде трех" (Якобсон, Буч, Рамбо), мы узнаем, что требование - это желаемая функциональность, свойство или поведение системы . Именно со сбора требований начинается процесс разработки ПО . Если изобразить процесс разработки ПО в виде " черного ящика " (уверены, читатель знает, что это такое, если нет - "Википедия" к вашим услугам), на выходе которого мы получаем программный продукт , то на вход этого "черного ящика" будет подаваться именно набор требований к программному продукту (рис. 6.1 )!


Рис. 6.1.

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

Кстати, вернемся к требованиям. Да, мы сказали, что на вход нашего "черного ящика" подается набор требований. Но в какой форме? Как их документируют, эти требования? Думаю, большинство читателей помнит, что такое техническое задание - основной документ, без составления которого не начинался в советские времена ни один проект. Документ это был большой, многостраничный, с четкой структурой, определяемой ГОСТами (государственными отраслевыми стандартами). И описывал он, по сути, не что иное, как требования к создаваемой системе!

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

· диаграммы прецедентов ;

· нефункциональные требования.

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

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



Рис. 6.2.

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

· четко разграничить систему и ее окружение;

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

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

Подобный вид деятельности обычно выполняется в такой последовательности:

1. Определение действующих лиц.

2. Определение прецедентов.

3. Составление описания каждого прецедента.

4. Описание модели прецедентов в целом (этот этап включает в себя создание словаря предметной области).

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

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

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

Прецедент

Действующее лицо

разместить меню

секретарь

ознакомиться с меню

сделать заказ

сотрудник, секретарь, офис-менеджер

сформировать счет

офис-менеджер

оплатить счет

офис-менеджер

Здесь нигде не сказано о том, что система должна быть написана на ASP .NET . Почему - понятно: это ведь нефункциональное требование! И еще, очевидно, что секретарь и офис -менеджер тоже являются сотрудниками. Читатель, внимательно прочитавший предыдущие лекции, заподозрит, что в данном случае, создавая модель прецедентов, говоря о действующих лицах, можно бы применить генерализацию. Действительно, диаграмма прецедентов , построенная на основе этой таблицы, может быть, например, такой (рис. 6.3 ):



Рис. 6.3.

Диаграммы прецедентов и их нотация

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

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

Кроме рамок системы или ее контекста на диаграмме мы видим еще два вида связанных с ней сущностей - это действующие лица (экторы, actors) и прецеденты . Начнем с экторов. Довольно часто в русскоязычной литературе по UML для обозначения действующих лиц можно встретить термин "актер ". В принципе, смысл его более-менее понятен и оригинальному английскому термину он созвучен. Более того, есть еще одна причина такого перевода. Какое слово первым приходит к вам в голову, когда вы слышите слово "актер "? Да, конечно же - слово "роль"! Именно о ролях мы вскоре и поговорим, когда будем пытаться разобраться, что скрывается за понятием "действующее лицо". А пока, да простит нас читатель, далее мы все же будем пользоваться словом "эктор" - транскрипцией оригинального термина. Помнится, мы уже как-то писали о нашем отношении к буквальному переводу терминологии...

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

Возможно, слова "роли, исполняемые пользователем" в определении эктора звучат не очень понятно. Очень забавно это понятие объясняется в Zicom Mentor:

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

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

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


Рис. 6.4.

Несмотря на "человеческий" вид этого обозначения, не следует забывать, что экторы - это не обязательно люди. Эктором, как мы уже говорили ранее, может быть внешняя система, подсистема, класс и т. д. Кстати, человечек ("stick-person" ) - это не единственное обозначение эктора, используемое в UML . На диаграммах прецедентов обычно применяется именно "человекоподобная" форма эктора, но на других диаграммах, и особенно в случаях, когда эктор имеет атрибуты , которые важно показать, используется изображение эктора как класса со стереотипом <> (рис. 6.5 ):


Рис. 6.5.

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

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

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

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



Рис. 6.6.

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

Внимательный читатель, возможно, отметил то, как незаметно мы ввели в употребление слово " сценарий ". Что же такоесценарий и как понятие сценария связано с понятием прецедента? На первый вопрос хорошо отвечают классики (Г. Буч):

Сценарий - это конкретная последовательность действий, иллюстрирующая поведение.

Сценарий - это повествовательный рассказ о совершаемых эктором действиях, история, эпизод, происходящий в данных временных рамках и данном контексте взаимодействия. Сценарии (в различных формах представления) широко применяются в процессе разработки программного обеспечения. Как мы уже только что отметили, написание сценария напоминает написание художественного рассказа, и этим объясняется тот факт, что использование сценариев широко распространено среди аналитиков, которые часто обладают художественными или литературными способностями. Несмотря на непрерывный повествовательный характер, сценарии можно рассматривать как последовательности действий (делать раскадровку ). При разработке пользовательского интерфейса сценарии описывают взаимодействие между пользователем (или категорией пользователей, например, администраторами системы, конечными пользователями) и системой. Такой сценарий состоит из последовательного описания комбинаций отдельных действий и задач (например, нажатий клавиш, щелчков по элементам управления, ввода данных в соответствующие поля и т. д.). Вспомните, к примеру, описания последовательностей действий пользователя (предназначенных для достижения определенных результатов, решения определенных задач), которые вы находите в справке к малознакомой программе. То же самое можно сказать о модных сейчас "how-to videos", в которых такие последовательности отображаются визуально, на конкретных примерах. В любом случае, цель подобных справочных материалов - предоставить описание типичных сценариев использования системы, сценариев взаимодействия между пользователем и системой.

Сценарии также иногда можно увидеть на диаграмме прецедентов. Иногда их изображают в виде " листа бумаги ", на котором написано имя файла , - прямоугольника с загнутым нижним левым уголком. В этом случае указанный файл содержит в себе описание данного сценария. А иногда сценарий записывается в комментарий. Как вы, наверное, помните, комментарии (ноутсы, notes) изображаются прямоугольниками с загнутым верхним правым углом и соединяются с элементом, который они поясняют, пунктирной линией (рис. 6.7 ).



Рис. 6.7.

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

Вот пример простого (неформализованного) текстового описания сценария.

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

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

А вот тот же сценарий в табличном представлении:

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

А пока попробуем ответить на второй вопрос, а именно: как связаны понятия сценария и прецедента . Прецеденты, как мы уже говорили, рождаются из требований к системе. Но говорят они о том, что делает система. Как система это делает, говорят сценарии. Таким образом, прецедент можно специфицировать путем описания потока действий или событий в текстовой форме - в виде, понятном для "постороннего" (не занятого в непосредственной разработке системы) читателя. А ведь такое описание - это и есть сценарий ! Таким образом, сценарии специфицируют прецеденты . И еще. Поскольку сценарии - это, по сути, рассказы, они являются весьма эффективным средством извлечения информации из бесед с заказчиком и предоставляют превосходное, понятное непрофессионалу описание создаваемого приложения. Сценарии, да и вообще диаграммы прецедентов (дополненные сценариями) являются отличным средством общения между разработчиками и заказчиком , причем, в силу простоты нотации, - средством, понятным обеим сторонам. В конечном итоге, взаимосвязь между требованиями, прецедентами и сценариями можно изобразить такой "псевдодиаграммой" (рис. 6.8 ).



Рис. 6.8.

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

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

"Хватит ходить вокруг да около!" - воскликнет нетерпеливый читатель. Уже заканчиваем. Мы просто хотели мягко подвести читателя к вопросу об отношениях между прецедентами. А отношения эти весьма многообразны. Начнем со старого знакомого - отношения обобщения (наследования, генерализации). О генерализации мы уже говорили не раз, когда рассматривали диаграммы классов . Но все же напомним суть этого понятия. Как говорят классики, обобщение - это отношение специализации (обобщения), в котором объекты специализированного элемента (потомка) могут быть подставлены вместо объектов обобщенного элемента (родителя, или предка).

Точно так же, как мы обычно поступаем с классами, после того как мы выделили и описали каждый прецедент , мы должны просмотреть их все на предмет наличия одинаковых действий - поискать, а не выполняются ли (используются) некоторые действия совместно несколькими вариантами использования. Этот совместно используемый фрагмент лучше описать в отдельном прецеденте. Таким образом мы уменьшим избыточность модели за счет применения обобщения прецедентов (иногда, правда, говорят не об обобщении, а об использовании прецедентов; почему - сейчас поймете). Как это и "положено" при наследовании, экземпляры обобщенных прецедентов (потомков) сохраняют поведение, присущее обобщающему прецеденту (предку). Другими словами, наличие (использование) в варианте использования X обобщенного варианта использования Y говорит нам о том, что экземпляр прецедента X включает в себя поведение прецедента Y . Обобщения применяются, чтобы упростить понимание модели вариантов использования за счет многократного задействования "заготовок" прецедентов для создания прецедентов, необходимых заказчику (помните, как мы рассматривали вопрос о том, всегда ли необходимо создавать новый класс , или лучше воспользоваться готовым решением, чувствуете аналогию?). Такие "полные" прецеденты называются конкретными прецедентами . "Заготовки" прецедентов, созданные лишь для многократного использования в других прецедентах, называют абстрактными прецедентами. Абстрактный прецедент (как и абстрактный класс ) не существует сам по себе, но экземпляр конкретного прецедента демонстрирует поведение, описываемое абстрактными прецедентами, которые он (повторно) использует. Прецедент , который экторы наблюдают при взаимодействии с системой ("полный" прецедент , как мы называли его ранее), часто называют еще " реальным " прецедентом.

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

Изображается обобщение , как, конечно, помнит внимательный читатель, линией с "незакрашенной" треугольной стрелкой на конце. Обобщение - это отношение между предком и потомком, и стрелка всегда указывает на предка. Если вспомнить, что потомки наследуют (используют) свойства предка, то вполне логично вспоминается наше утверждение о том, что стрелки в UML всегда направлены в сторону того, от кого что-то требуют, чьими сервисами пользуются (рис. 6.9 ):



Рис. 6.9.

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

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

А как же изображается включение? Да очень просто - как зависимость (пунктирная линия со стрелкой, помните?) со стереотипом <> . При этом стрелка направлена, естественно, в сторону включаемого прецедента. Этот факт легко объяснить, если вспомнить утверждение, которое мы уже несколько раз использовали в этом курсе: стрелка всегда направлена в сторону того элемента, от которого что-то требуется, чьими сервисами пользуются. А если считать, что объемлющий прецедент включает в себя, заимствует (использует) поведение включаемых прецедентов, становится ясно, что стрелка может быть направлена только таким образом. А вот и диаграмма , иллюстрирующая вышесказанное, которую мы позаимствовали из Zicom Mentor (рис. 6.10 ):


увеличить изображение
Рис. 6.10.

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

На очереди - отношение расширения . Чтобы уяснить себе смысл расширения, представим себе, что мы говорим об оплате некоторого купленного нами товара. Мы можем оплатить товар наличными, если сумма не превышает $ 100. Или оплатить кредитной картой, если сумма находится в пределах от $ 100 до $ 1000. Если же сумма превышает $ 1000, нам придется братькредит . Таким образом мы расширили понимание операции оплаты купленного товара и на случаи, когда используются другие средства оплаты, нежели наличные. Но сами эти случаи возникают только при строго определенных условиях: когда цена товара попадает в определенные рамки.

Расширение дополняет прецедент другими прецедентами, "срабатывающими" при некоторых условиях, - просто добавляет в исходный прецедент последовательность действий, содержащуюся в другом прецеденте. Отношение расширения прецедента А к прецеденту В означает, что экземпляр прецедента В может включать в себя (при определенных условиях, которые могут быть описаны в расширении; как именно описаны, мы скажем чуть позже) поведение, описанное в прецеденте А. Пример показан на следующей диаграмме (рис. 6.11 ):



Рис. 6.11.

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

Точка расширения описывается в дополнительном разделе прецедента, отделенном от его названия горизонтальной линией - точно так же, как в отдельных разделах перечисляются атрибуты класса и его операции . Ниже показан пример описания точки расширения, позаимствованный нами из Zicom Mentor (рис. 6.12 ).



Рис. 6.12.

В этом примере регистрация пассажиров авиарейса включает в себя контроль службы безопасности, а при условии (указанном в примечании после служебного слова "Condition :"), что человек часто летает и салон переполнен (обратите внимание на операторAND , говорящий об одновременности выполнения условий), класс билета может быть повышен, например, с "эконом" до "бизнес-класса". Причем такой апгрейд может произойти только после того, как билет предъявлен на стойку регистрации - это и есть точка расширения. Она описана (ее имя указано) в дополнительном разделе прецедента после служебной фразы "Extension points:". Предваряя вопрос читателя, скажем, что прецедент может иметь сколь угодно много точек расширения. А сопоставить конкретный расширяющий прецедент с определенной точкой расширения можно, прочитав условия расширения, указанные в комментариях, - само условие записывается после служебного слова "Condition :" в фигурных скобках, за которыми идет служебная фраза "Extension point :", и после нее указывается имя точки расширения. Посмотрите еще раз на наш пример с регистрацией пассажиров в аэропорту и убедитесь сами, что все это очень просто!

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

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

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

На этом разговор о нотации диаграмм прецедентов можно было бы и завершить. Хотелось бы только сказать еще пару слов о соотношении между понятиями прецедента и кооперации . О кооперации мы уже говорили ранее (помните диаграммы взаимодействия ?) как о множестве ролей, работающих вместе, чтобы обеспечить некоторое поведение системы. Мы также упоминали о том, что прецеденты отвечают на вопрос "что делает система?", но не говорят, как именно она это делает. На этапе анализа понимать, как именно система реализует свое поведение, действительно не нужно. Но при переходе к реализации неплохо бы знать, какие именно классы (или другие элементы модели), совместно работая, обеспечивают нужное поведение . То есть мы логично перешли от разговора о прецедентах к разговору о кооперации! Недаром обозначения кооперации и прецедента очень похожи (читатель, конечно, помнит, что кооперация обозначается пунктирным эллипсом) (рис. 6.13 ).


Рис. 6.13.

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

Моделирование при помощи диаграмм прецедентов

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

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

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

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

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

Прецеденты полезны и для прямого, и для обратного проектирования. При прямом проектировании мы, по сути, осуществляем "перевод" с UML на некий язык программирования . И тестировать созданное приложение следует, основываясь именно на потоках событий, описываемых прецедентами. Обратное проектирование предполагает перевод с языка программирования на язык UML -диаграмм. Такими вещами приходится заниматься в силу ряда причин:

· С целью поиска ошибок и чтобы убедиться в адекватности дизайна :

отличная идея после первого перевода с UML на язык программирования сделать обратный перевод и сравнить исходные и восстановленные UML-модели (желательно, чтобы эти переводы выполнялись разными командами). Это позволит убедиться в том, что дизайн системы соответствует модели, никакая информация в ходе перевода не была утеряна, да и попросту выловить некоторые "баги". Такой подход называется обратной семантической трассировкой (или RST - Reverse SemanticTraceability ) и разрабатывается компанией INTSPEI ( http://www.intspei.com ) как одна из базовых техник методологии INTSPEI P-Modeling Framework, краткие сведения о которой вы можете найти в приложении к этому курсу.

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

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



Рис. 6.14.

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


Рис. 6.16.

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



Рис. 6.17.

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

И наконец, третья картинка, которая не является хорошим примером диаграммы прецедентов , но просто забавна. Это рассказ о способах поведения, позволяющих гарантированно (!) провалить любой экзамен (рис. 6.18 ):



Рис. 6.18.

Выводы

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

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

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

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

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

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

· Каждый прецедент реализуется одной или несколькими кооперациями.

· Сценарии специфицируют прецеденты, а диаграммы взаимодействий визуализируют сценарии.

Контрольные вопросы

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

· Какие способы изображения экторов вы знаете?

· В какие отношения могут вступать экторы между собой?

· В чем состоит смысл отношений включения и расширения?

· Что такое точка расширения?

· Перечислите известные вам причины использования прецедентов.

· Как прецеденты применяют в прямом и обратном проектировании?


Аннотация: Предметом этого курса является The UML - унифицированный язык моделирования. В предыдущей лекции было рассказано о том, что же такое UML, о его истории, назначении, способах использования языка, структуре его определения, терминологии и нотации. Было отмечено, что модель UML - это набор диаграмм. В этой лекции мы рассмотрим такие вопросы: почему нужно несколько видов диаграмм; виды диаграмм; ООП и последовательность построения диаграмм

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

Мы строим модели сложных систем, потому что не можем описать их полностью, "окинуть одним взглядом". Поэтому мы выделяем лишь существенные для конкретной задачи свойства системы и строим ее модель, отображающую эти свойства. Метод объектно-ориентированного анализа позволяет описывать реальные сложные системы наиболее адекватным образом. Но с увеличением сложности систем возникает потребность в хорошей технологии моделирования. Как мы уже говорили в предыдущей лекции, в качестве такой "стандартной" технологии используется унифицированный язык моделирования ( Unified Modeling Language , UML ), который является графическим языком для спецификации, визуализации, проектирования и документирования систем. С помощью UML можно разработать подробную модель создаваемой системы, отображающую не только ее концепцию, но и конкретные особенности реализации. В рамках UML -модели все представления о системе фиксируются в виде специальных графических конструкций, получивших название диаграмм.

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

Почему нужно несколько видов диаграмм

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

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

Да, не слишком информативно. А что же такое тогда подсистема? Чтобы прояснить ситуацию, обратимся к классикам:

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

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

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

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

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

Модель - это некий (материальный или нет) объект , отображающий лишь наиболее значимые для данной задачи характеристики системы. Модели бывают разные - материальные и нематериальные, искусственные и естественные, декоративные и математические...

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

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

Уравнение, изображенное выше - тоже модель, но это модель математическая, и описывает она движение материальной точки под действием силы тяжести.

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

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

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

Виды диаграмм

UML 1.5 определял двенадцать типов диаграмм , разделенных на три группы:

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

Текущая версия UML 2.1 внесла не слишком много изменений. Диаграммы слегка изменились внешне (появились фреймы и другие визуальные улучшения), немного усовершенствовалась нотация , некоторые диаграммы получили новые наименования.

Впрочем, точное число канонических диаграмм для нас абсолютно неважно, так как мы рассмотрим не все из них, а лишь некоторые - по той причине, что количество типов диаграмм для конкретной модели конкретного приложения не является строго фиксированным. Для простых приложений нет необходимости строить все без исключения диаграммы. Например, для локального приложения не обязательно строить диаграмму развертывания. Важно понимать, что перечень диаграмм зависит от специфики разрабатываемого проекта и определяется самим разработчиком. Если же любопытный читатель все-таки пожелает узнать обо всех диаграммах UML , мы отошлем его к стандарту UML (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Напомним, что цель этого курса - не описать абсолютно все возможности UML , а лишь познакомить с этим языком, дать первоначальное представление об этой технологии.

Итак, мы кратко рассмотрим такие виды диаграмм, как:

  • диаграмма прецедентов ;
  • диаграмма классов;
  • диаграмма объектов ;
  • диаграмма последовательностей;
  • диаграмма взаимодействия;
  • диаграмма состояний;
  • диаграмма активности ;
  • диаграмма развертывания .

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

Диаграмма прецедентов (use case diagram)

Любые (в том числе и программные) системы проектируются с учетом того, что в процессе своей работы они будут использоваться людьми и/или взаимодействовать с другими системами. Сущности, с которыми взаимодействует система в процессе своей работы, называются экторами , причем каждый эктор ожидает, что система будет вести себя строго определенным, предсказуемым образом. Попробуем дать более строгое определение эктора. Для этого воспользуемся замечательным визуальным словарем по UML Zicom Mentor :

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

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

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


Рис. 2.1.

Тот же внимательный читатель мог заметить промелькнувшее в определении эктора слово "прецедент". Что же это такое? Этот вопрос заинтересует нас еще больше, если вспомнить, что сейчас мы говорим о диаграмме прецедентов . Итак,

Прецедент (use-case) - описание отдельного аспекта поведения системы с точки зрения пользователя (Буч).

Определение вполне понятное и исчерпывающее, но его можно еще немного уточнить, воспользовавшись тем же Zicom Mentor "ом:

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

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

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

    • Диаграммы прецедентов (Use case diagrams) - применяются для моделирования поведения системы, подсистемы или класса с точки зрения прецедентов (или вариантов использования).

    Диаграммы прецедентов включают следующие элементы:

    Прецеденты;

    Участников (актеров);

    Отношения зависимости, обобщения и ассоциации.

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

    Рис. 3.5.6.1. Графическое отображение примера прецедентов в UML.

    Участник (субъект, актер) - множество ролей, которые пользователи прецедентов исполняют при взаимодействии с ними. В качестве участника может выступать человек, устройство, другая программная система. Графическое отображение примера участников приведено на рис. 3.5.6.2.

    Рис. 3.5.6.2. Графическое отображение примера участников в UML

    Диаграммы прецедентов обычно применяются для решения сле­дующих задач:

    Моделирование контекста системы, подразумевающего иденти­фикацию участников, взаимодействующих с системой, а также их ролей;

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

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

    Моделирование системы необходимо проводить, следуя следую­щим этапам:

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

    Рассмотреть и описать потоки событий для прецедентов отраженных на главной диаграмме прецедентов, а именно: предусловия, главный поток, подпотоки, альтернативные потоки, постусловия;

    Организовать похожих участников с помощью отношений обобщения/специализа-ции;

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

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

    Моделирование требований к системе необходимо проводить, сле­дуя следующим этапам:

    Установление контекста системы, идентификация окружающих систему участников;

    Для каждого участника - рассмотрение поведения, которое он ожидает и требует от системы;

    Именование выделенных вариантов поведения как прецедентов;

    Выделение общего поведения в новые прецеденты, которые бу­дут использоваться другими;

    Выделение вариации поведения в новые прецеденты, расширяющие основные потоки событий;

    Моделирование выделенных прецедентов, участников, отноше­ний между ними на диаграмме прецедентов;

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

    Моделирования диаграмм прецедентов на конкретных примерах приведены на рис. 3.5.6.3. и рис. 3.5.6.4.

    Рис. 3.5.6.3. Графическое отображение прецедентов на примере обслуживания

    абонентов сотовой телефонной связи.

    Следует отметить дополнение прецедентов примечаниями, описывающими не­функциональные специфические требования, т.е.комментариями, которыми могут сопровождаться некоторые отношения между вариантами использования. Так, смысл отношения "include" состоит в том, что в данном примере «Подключение» включает в себя «Выбор оператора связи». Смысл же связи <> в том, что прецедент, например, «Рассмотрение анкеты» "расширяется" вариантом использования «Заключение договора». Это можно в данном случае объяснить тем, что «Заключить договор» можно только после проверки оператором анкеты. «Рассмотрение заявления» "расширяет" прецедент «Блокировка номера», «Замена sim-карты», «Детализация счета», «Замена абонентского номера». Таким образом, связь <> говорит о выполнении того или иного прецедента в зависимости от определенных условий.

    Рис. 3.5.6.4. Графическое отображение прецедентов

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

    Данные диаграммы прецедентов описывают участников при их взаи­модействии с системой на предприятиях.

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

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

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

    В программной и системной инженерии USE CASE-диаграмма представляет собой список действий или шагов мероприятия, которые обычно определяют взаимодействие между ролью (известной на языке унифицированного моделирования как «актер») и системой для достижения цели. "Актер" может быть человеческой или другой внешней системой.

    Определение

    USE CASE-диаграммы языка UML — это важный и ценный метод анализа требований, который широко используется в современной разработке программного обеспечения со времени его официального введения Иваром Джекобсоном в 1992 году. Разработка с использованием приложений зависит от многих моделей процессов и структур, таких как ICONIX, Unified Process (UP), IBM Rational Unified Process (RUP) и Oracle Unified Method (OUM).

    История

    В 1986 году Ивар Джекобсон сначала сформулировал текстовые, структурные и визуальные методы моделирования для определения вариантов использования. В 1992 году его соавтор книги «Объектно-ориентированная разработка программного обеспечения — подход, основанный на USE CASE», помог популяризовать технику сбора функциональных требований, особенно в разработке ПО.

    Другие эксперты также внесли большой вклад, в частности Алистер Кокберн, Ларри Константин, Дин Леффингвелл, Курт Биттнер и Гуннар Овергаард.

    Характер взаимодействия элементов

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

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

    USE CASE-диаграммы: состав, виды связей

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

    Существует три основных элемента процесса:

      "Актеры" — это тип пользователей, которые взаимодействуют с системой.

      Система — функциональные требования, которые определяют предполагаемое поведение элементов.

      Цели — USE CASE обычно инициируются пользователем для выполнения целей, описывающих действия и варианты, участвующие в их достижении.

    Характеристики методики:


    Шаги при разработке диаграмм:

      Определите пользователей системы.

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

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

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

    Терминология

    USE CASE-диаграмма в Rational Rose — это диаграмма динамического поведения в UML, которая моделирует функциональность системы с использованием участников, прецедентов и других важнейших объектов. Случаи использования — это набор действий, служб и функций, которые должна выполнять система. В этом контексте система — это то, что разрабатывается или эксплуатируется, например веб-сайт. «Актеры» (условный термин) — это люди или организации, которые работают под определенными ролями внутри системы.

    Для чего применяются USE CASE-диаграммы?

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

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

    Что такое диаграмма UML?

    USE CASE-диаграмма UML — это способ визуализации программного обеспечения с использованием набора диаграмм. Основоположники технологии — Грэди Буч, Джеймс Румбо, Ивар Джекобсон и компания Rational Software Corporation. Их работы легли в основу объектно-ориентированного дизайна, затем спецификации были расширены, чтобы охватить более широкий спектр проектов разработки программного обеспечения. Сегодня UML принимается группой управления объектами (OMG) в качестве стандарта для разработки программного обеспечения для моделирования.

    Чтобы ответить на вопрос о том, использования в UML, необходимо сначала понять ее строительные блоки. Общие компоненты включают:

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

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

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

    В профессиональном сообществе программистов для объяснения структуры часто применяют диаграммы USE CASE «по курочке Рябе» — визуальное изображение сюжета популярной сказки в виде схемы.

    Что такое UML?

    UML означает Unified Modeling Language. UML 2.0 помог расширить исходную спецификацию, чтобы охватить более широкую часть усилий по разработке программного обеспечения, включая гибкие методы. Также были реализованы следующие разработки:


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

    Типы диаграмм

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

    Эти диаграммы организованы в две различные группы: структурные и диаграммы поведения (или взаимодействия).

    Структурные, в свою очередь, делятся на следующие виды диаграмм:

      Классов — являются основой почти каждого объектно-ориентированного метода, включая UML. Они описывают статическую структуру системы.

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

      Объекта — описывают статическую структуру системы в определенное время. Они могут использоваться для проверки диаграмм классов для точности.
      Композитные структурные диаграммы показывают внутреннюю часть класса. Моделируют функциональность системы с использованием участников и прецедентов.

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

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

    Поведенческие имеют в своем составе диаграммы:

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

    Символы и обозначения

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

    Зависимости отмечены пунктирной линией со стрелкой. Использование << >> позволяет указать свойства этой зависимости. Множественность обычно отображается с номером на одном конце стрелки и * с другой.

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

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

    Почему мы используем UML?

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

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

    Пример USE CASE-диаграммы — графическое изображение взаимодействий между методология, используемая в системном анализе для выявления, уточнения и организации системных требований. В этом контексте термин «система» относится к тому, что разрабатывается или эксплуатируется, например к веб-сайту по продаже и обслуживанию товаров по почте. USE CASE-диаграмма в UML (Unified Modeling Language) — стандартная нотация для моделирования объектов и систем реального мира.

    Расшифровка понятий

    Цели системы могут включать в себя планирование общих требований, проверку аппаратного проектирования, тестирование и отладку разрабатываемого программного продукта, создание справки по оперативной помощи или выполнение задачи, ориентированной на потребителя. Например, использование диаграммы вариантов USE CASE diagram в среде продаж включает в себя упорядочивание товаров, обновление каталога, обработку платежей и отношения с клиентами. Диаграмма использования выглядит как блок-схема. Интуитивные символы представляют собой элементы системы. Сценарии прецедентов диаграмм USE CASE-банкомата содержат четыре компонента:

      Граница, которая определяет систему интереса к окружающему миру.

      "Актеры", обычно люди, связанные с системой, определяемые в соответствии с их ролями.

      Варианты использования, которые являются конкретными ролями, которые играют "актеры" внутри и вокруг системы.

      Взаимоотношения между субъектами.

    На унифицированном языке моделирования диаграмма может суммировать сведения о пользователях вашей системы (также известных как субъекты) и их взаимодействии с системой. Чтобы построить один объект, вы будете использовать набор специализированных символов и коннекторов. Например, USE CASE-диаграмма интернет-магазина может помочь вашей команде обсудить и представить:

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

      цели и методы их достижения;

      объем системы.

    Практическое применение

    USE CASE-диаграмма не имеет большого значения при отсутствии четкого понимания процесса — она не будет моделировать порядок выполнения шагов, если не заложен четкий алгоритм. Эксперты рекомендуют использовать данные диаграммы для дополнения текстового варианта. В диаграмме на высоком уровне демонстрируется взаимосвязь между вариантами использования, субъектами и системами. По этой причине часто используются USE CASE uml-диаграммы для политической партии при моделировании структуры.

    Диаграмма идеальна в таких ситуациях:

      представление целей системно-пользовательских взаимодействий;

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

      выявление контекста и требований системы;

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

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

    Для моделирования системы наиболее важным аспектом является захват динамического поведения, которое означает поведение системы при ее запуске и дальнейшей работе. В UML существует пять диаграмм, доступных для моделирования динамического характера, и пример USE CASE-диаграммы наиболее нагляден.

    Назначение

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

    Когда начальная задача завершена, диаграммы случайных ситуаций моделируются для представления внешнего вида. Целями при создании USE CASE-диаграмм можно назвать следующее:

      сбор требований;

      получение внешнего вида системы;

      влияние внешних и внутренних факторов;

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

    Процесс создания

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

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

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

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

      Дайте подходящее имя для актеров.

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

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

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

    Сферы применения

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

    Чтобы понять динамику, нужно использовать разные типы диаграмм. USE CASE-диаграммы, состав, виды связей — наилучший пример. Ее конкретная цель - собирать системные требования участников.

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

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

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


    Статьи по теме

    Последние статьи
    Популярные статьи
    Выбор редакции
    mixcoin.ru