10674

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

Практическая работа

Информатика, кибернетика и программирование

Практическая работа №1 Моделирование контекста и функциональных требований к системе Цель работы: изучение диаграммы прецедентов: ее элементов актеров и прецедентов и основных типов связи между ними получение основных навыков построения диаграммы прецедентов в п...

Русский

2013-03-30

233 KB

22 чел.

Практическая работа №1

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

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

Типы связей

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

Таблица 2.1 – Отношения

Отношение

Графическое изображение

Определение

Ассоциация

структурное отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа

Обобщение

отношение между общей сущностью (суперклассом, или родителем) и ее конкретным воплощением (субклассом, или потомком)

Зависимость

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

Ассоциацией (Association) называется структурное отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа.

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

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

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

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

Прецеденты

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

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

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

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

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

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

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


Рисунок 2.1 -  Актеры и прецеденты

Прецеденты и актеры

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

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


Рисунок 2.2 – Отношение обобщения между Актерами

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

Прецеденты и поток событий

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

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

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

Основной поток событий. Прецедент начинается, когда система запрашивает у клиента его персональный идентификационный номер (PIN). Клиент (Customer) может ввести его с клавиатуры. Завершается ввод нажатием клавиши Enter. После этого система проверяет введенный PIN и, если он правильный, подтверждает ввод. На этом прецедент заканчивается.

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

Исключительный поток событий. Клиент может в любой момент до нажатия клавиши Enter стереть свой PIN и ввести новый.

Исключительный поток событий. Если клиент ввел неправильный PIN, прецедент запускается сначала. Если это происходит три раза подряд, система отменяет всю транзакцию и не позволяет данному клиенту снова начать работу с банкоматом в течение 60 секунд.

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

Отношения включения и расширения

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

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

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

Основной поток событий. Получить и проверить номер заказа, include (Проверить клиента). Запросить статус каждой части заказа и доложить клиенту.

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

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

Основной поток событий include (Проверить Клиента). Собрать все пункты сделанного клиентом заказа. (Установить приоритет). Отправить заказ на обработку.

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

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

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

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

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

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


Рисунок 2.3 - Диаграмма прецедентов программной оболочки для управления режимами высокотемпературного широкополосного акустического канала

Диаграммой прецедентов, или использования (Use case diagram), называется диаграмма, на которой показана совокупность прецедентов и актеров, а также отношения между ними.

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

  •  прецеденты;
  •  актеры;
  •  отношения зависимости, обобщения и ассоциации.

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

Типичные примеры применения

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

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

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

Контекст системы

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

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

Моделирование контекста системы состоит из следующих шагов:

  1.  Идентифицируйте окружающих систему актеров. Для этого нужно найти группы, которым участие системы требуется для выполнения их задач; группы, которые необходимы для осуществления системой своих функций; группы, взаимодействующие с внешними программными и аппаратными средствами, а также группы, выполняющие вспомогательные функции администрирования и поддержки.
  2.  Организуйте похожих актеров с помощью отношений обобщения/специализации.
  3.  Введите стереотипы для каждого актера, если это облегчает понимание.
  4.  Поместите актеров на диаграмму прецедентов и определите способы их связи с прецедентами системы.

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


Рисунок 2.4 -
 Моделирование контекста системы

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

Требования к системе

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

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

Моделирование требований к системе производится следующим образом:

  1.  Установите контекст системы, идентифицировав окружающие ее актеры.
  2.  Для каждого актера рассмотрите поведение, которого он ожидает или требует от системы.
  3.  Поименуйте эти общие варианты поведения как прецеденты.
  4.  Выделите общее поведение в новые прецеденты, которые будут использоваться другими; выделите вариации поведения в новые прецеденты, расширяющие основные потоки событий.
  5.  Смоделируйте эти прецеденты, актеры и отношения между ними на диаграмме прецедентов.
  6.  Дополните прецеденты примечаниями, описывающими нефункциональные требования; некоторые из таких примечаний можно присоединить к системе в целом.

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


Рисунок 2.5 -  Моделирование требований к системе

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

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

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

Хорошо структурированная диаграмма прецедентов обладает следующими свойствами:

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

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

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

Упражнение. Создание диаграммы Прецедентов

Постановка задачи

"Опять!" - сказал Боб, повесив телефонную трубку.

Мэри взглянула на него, оторвавшись от компьютера: "В чем дело?"

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

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

Robertson's Cabinets, Inc.  - это маленькая компания, специализирующаяся на производстве стандартных и нестандартных кухонных шкафов. Компания началась с небольшой группы собравшихся вместе предпринимателей. Когда дело началось три года назад, поступало слишком мало заказов, и они вполне могли управляться с ними на бумаге. С ростом их репутации число заказов возрастало. Пришлось нанять новых рабочих, и за три года фирма выросла до магазина с более чем 50 сотрудниками.

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

Боб пошел звонить Сьюзан.

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

"Согласна."

"Можешь ты разработать программу на Java, которая отслеживала бы заказы?"

"Пока что не волнуйтесь по поводу реализации. Давайте решим, чего вы хотите от системы?"

"Надо, чтобы она отслеживала заказы."

"Не мог бы ты быть более конкретным? Давай рассмотрим нынешний процесс".

"Хорошо, получив звонок, мы заполняем форму заказа. Мы передаем ее Клинту в магазин, он заполняет все необходимые документы и готовит отправку товара клиенту. Копию формы мы отдаем Дону в бухгалтерию. Он вводит ее в бухгалтерскую систему и выписывает счет".

"И вы хотите, чтобы новая система поддерживала весь этот процесс?"

"Точно".

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

Создание диаграммы Прецедентов

Создайте диаграмму Прецедентов для системы обработки заказов. Требуемые для этого действия подробно перечислены далее. Готовая диаграмма Прецедентов должна выглядеть как на рисунке 2.10.

Создание прецедентов и актеров

  1.  В диалоговом окне New Project By Approach выберите Empty Project (рисунок 2.6).

  1.  В окне Model Explorer откройте правой кнопкой мыши меню Add в котором выберете Model (Рисунок 2.7). Введите имя модели Система обработки заказов Прецедентов (Main) в броузере, чтобы открыть ее.
  2.  В окне Model Explorer откройте правой кнопкой мыши меню Add diagram для модели Система обработки заказов (Рисунок 2.8) и выберете Use Case Diagram 
  3.  С помощью кнопки System Boundary (Границы системы) Панели инструментов Tool Box поместите на диаграмму границы системы.
  4.  С помощью кнопки Use Case (Прецедент) Панели инструментов Tool Box (рисунок 2.9) поместите на диаграмму новый Прецедент.
  5.  Назовите этот новый Прецедент "Ввести новый заказ".
  6.  Повторите этапы 2 и 3, чтобы поместить на диаграмму остальные прецеденты: Изменить существующий заказ, Напечатать инвентарную опись, Обновить инвентарную опись, Оформить заказ, Отклонить заказ.
  7.  С помощью кнопки Actor (Актер) панели

инструментов поместите на диаграмму новое действующее лицо.

  1.  Назовите его "Продавец"
  2.  Повторите шаги 5 и 6, поместив на диаграмму остальных действующих лиц: Управляющий магазином, Клерк магазина, Бухгалтерская система

Рисунок 2.10 - Диаграмма Прецедентов для системы обработки заказов.

Добавить ассоциации

  1.  С помощью кнопки Unidirectional Association (Однонаправленная ассоциация) панели инструментов нарисуйте ассоциацию между действующим лицом Продавец и вариантом использования "Ввести новый заказ".
  2.  Повторите этот этап, чтобы поместить на диаграмму остальные ассоциации.

Добавить связь расширения

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

Добавить описания к вариантам использования

  1.  Выделите в броузере Прецедент "Ввести новый заказ".
  2.  В окне документации Documentation введите следующее описание к этому варианту использования: Этот Прецедент дает клиенту возможность ввести новый заказ в систему.
  3.  С помощью окна документации введите описания ко всем остальным вариантам использования.

Добавить описания к действующему лицу

  1.  Выделите в броузере действующее лицо Продавец
  2.  В окне документации введите для этого действующего лица следующее описание: Продавец - это служащий, доставляющий и старающийся продать продукцию.
  3.  С помощью окна документации введите описания к оставшимся действующим лицам.

Прикрепление файла к варианту использования

  1.  Для описания главного потока событий варианта использования "Ввести новый заказ" создайте файл OrderFlow.doc, содержащий следующий текст:
  2.  Продавец выбирает пункт "Создать новый заказ" из имеющегося меню.
  3.  Система выводит форму "Подробности заказа".
  4.  Продавец вводит номер заказа, заказчика и то, что заказано.
  5.  Продавец сохраняет заказ.
  6.  Система создает новый заказ и сохраняет его в базе данных.
  7.  Выделите в броузере варианте использования "Ввести новый заказ".
  8.  В окне Attachment правой кнопкой мыши выберете Add
  9.  В открывшемся окне Add укажите путь к файлу OpenFlow.doc и нажмите на кнопку OK, чтобы прикрепить файл к варианту использования.


 

А также другие работы, которые могут Вас заинтересовать

31022. Народные движения 17-18в – городские бунты 17в, восстание Степана Разина, восстания Петровской эпохи, Пугачевщина. Причины, характер, особенности, хронология, итоги 31 KB
  Народные движения 1718в –городские бунты 17в восстание Степана Разина восстания Петровской эпохи Пугачевщина. Восстание было подавлено. В 1666 состоялось восстание под предводительсвом Василия Уса. В 1705 произошло восстание в Астрахани.
31023. Реформы и преобразования Петра1 29 KB
  Реформы и преобразования Петра1. Петром была создана регулярная армия. Появились посесионные крестьянекоторых купили для работы на заводе и приписныеПетр сам приписал их к мануфактурам Правительство увеличило налоги налоги брали с чего можно было с бани с окон разделены монастырские вотчины на определенные и заопределнныебрали налог перечеканка денег власть получила 2 млн рубликов но курс рублика снизился вдвое выросли цены на товар в 17081710 Россия была поделена на 8 губерниймосковская Питерская и прочие в 1711...
31024. Внешняя политика Петра 1 28.5 KB
  Вместо борьбы с Турцией за южные моря Россия начала борьбу со Швецией намереваясь отвоевать потерянные в Смутное время русские владения у Финского залива. В 1700 русские объявили шведам войну. После в Прибалтике началась малая война русские и шведы вели бои местного назначения. В 1710 русские захватили Ригу Таллин Выборг.
31025. Внешняя и внутренняя политика России 1725 – 1796 18.91 KB
  Екатерина –золотой век русского дворянства просвещенная монархия. 1733 – 1735 – польская кампания поддерживали Августа III 1735 – 1739 – русскотурецкая война 1736 – захват русскими Азова действия войск в Крыму 1737 – взятие крепости Очаков Сентябрь 1739 – Белградский мир между Россией и Турцией 1741 – 1743 – Русскошведская война началась по инициативе шведов 1743 – Абоский мир 1756 – 1763 – Семилетняя война 1757 – Россия вступает в войну победа в сражении при ГроссЕгерсдорфе Апраксин 1758 – взятие Кенигсберга Цорндорф...
31026. Внешняя политика в царствование Александра I 20.61 KB
  Участие России в 3й 1805 и 4й 1806 антинаполеоновских коалициях Переговоры России и Франции в г. Тильзит 1807 Русско – шведская война 1808 – 1809 Переговоры России и Франции в г. По его условиям: А Финляндия в состав России как Великое княжество с широкой автономией БШвеция обязывалась порвать союз с Англией и присоединиться к континентальной блокаде. 25 декабря – издание Манифеста о полном изгнании противника из пределов России Янв – март 1813 – освобождение Пруссии русской армией Лето 1813 – образование 6...
31027. Основные направления внутр. И внешней политики Николая 1 552.1 KB
  Один из самых реакционных правителей России. – III отделению передают корпус жандармов; страна поделена на несколько жандармских округов в России создана эффективная полицейская система. Консерватор трезво смотрящий на экономику России. Долг России после войны – 102 млн.
31029. Внешняя политика второй половины XIX века 17.39 KB
  Наполеон III хотел заручиться поддержкой России рассчитывая обеспечить ее нейтралитет в войне с Австрией. Русскофранцузское сближение не было крепким а союз Пруссии и России был выгоден обоим государствам. Январьмарт 1871 Лондонская конференция: отмена нейтрализации Черного моря у России право держать там флот введение нового режима проливов. Образование германской империи привело к новой расстановке сил на континенте что способствовало сближению России с Германией и АвтроВенгрией.
31030. ВНЕШНЯЯ ПОЛИТИКА РОССИИ ВО ВТОРОЙ ПОЛОВИНЕ XIX в 13.9 KB
  Сложившийся против России англоавстрофранцузский блок так называемая Крымская система был нацелен на сохранение ее политической изоляции и военностратегической слабости обеспеченной решениями Парижского конгресса. дальневосточное направление во внешней политике России постепенно изменяло свой периферийный характер. добровольным вхождением Мерва территория пограничная с Афганистаном в состав России.