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

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

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

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

Рис.
4.1.
Диаграмма вариантов использования для модели банкомата

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

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

Таблица
4.2.
Главный раздел сценария выполнения варианта использования «Снятие наличных по кредитной карточке»

Вариант использования	Снятие наличных по кредитной карточке
Актеры	Клиент, Банк
Цель	Получение требуемой суммы наличными
Краткое описание	Клиент запрашивает требуемую сумму. Банкомат обеспечивает доступ к счету клиента. Банкомат выдает клиенту наличные.
Тип	Базовый
Ссылки на другие варианты использования	Включает в себя ВИ: Проверка ПИН-кода кредитной карточки Идентифицировать кредитную карточку

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

Таблица
4.3.
Раздел Типичный ход событий сценария выполнения варианта использования «Снятие наличных по кредитной карточке»

Действия актеров	Отклик системы
1. Клиент вставляет кредитную карточку в устройство чтения банкомата Исключение №1: Кредитная карточка недействительна	2. Банкомат проверяет кредитную карточку 3. Банкомат предлагает ввести ПИН-код
4. Клиент вводит персональный PIN-код Исключение №2: Клиент вводит неверный ПИН-код	5. Банкомат проверяет ПИН-код 6. Банкомат отображает опции меню
7. Клиент выбирает снятие наличных со своего счета	8. Система делает запрос в Банк и выясняет текущее состояние счета клиента 9. Банкомат предлагает ввести требуемую сумму
10. Клиент вводит требуемую сумму 11. Банк проверяет введенную сумму Исключение №3: Требуемая сумма превышает сумму на счете клиента	12. Банкомат изменяет состояние счета клиента, выдает наличные и чек
13. Клиент получает наличные и чек	14. Банкомат предлагает клиенту забрать кредитную карточку
15. Клиент получает свою кредитную карточку	16. Банкомат отображает сообщение о готовности к работе

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

Таблица
4.4.
Раздел Исключения сценария выполнения варианта использования «Снятие наличных по кредитной карточке»

Действия актера	Отклик системы
Исключение №1. Кредитная карточка недействительна или неверно вставлена
	3. Банкомат отображает информацию о неверно вставленной кредитной карточке 14. Банкомат возвращает клиенту его кредитную карточку
15. Клиент получает свою кредитную карточку
Исключение №2. Клиент вводит неверный ПИН-код
	6. Банкомат отображает информацию о неверном ПИН-коде
4. Клиент вводит новый ПИН-код
Исключение №3. Требуемая сумма превышает сумму на счете клиента
	12. Банкомат отображает информацию о превышении кредита
10. Клиент вводит новую требуемую сумму

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

Отдельные небольшие по своему объему сценарии могут быть размещены на диаграмме в форме примечаний.

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

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

Графически примечания на всех типах диаграмм обозначаются прямоугольником с «загнутым» верхним правым уголком (рис. 4.2). Собственно текст примечания размещается внутри этого прямоугольника. Примечание может относиться к любому элементу диаграммы, в этом случае их соединяет пунктирная линия. Если примечание относится к нескольким элементам, то от него проводятся соответственно, несколько линий. Как уже отмечалось, примечания могут присутствовать не только на диаграмме вариантов использования, но и на других канонических диаграммах.

Рис.
4.2.
Примеры примечаний на диаграммах вариантов использования

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

Источник

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

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

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

Класс

Класс
(class) — абстрактное описание множества
однородных объектов, имеющих
одинаковые атрибуты,
операции
и отношения с объектами других
классов
.

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

Рис.
5.1.
Варианты графического изображения
класса на диаграмме классов

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

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

Рис.
5.2.
Примеры графического изображения
конкретных классов

Имя
класса

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

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

Класс
может иметь или не иметь экземпляров
или объектов. В зависимости от этого
в языке UML различают конкретные
и абстрактные
классы.

Конкретный
класс
(concrete class) — класс,
на основе которого могут быть
непосредственно созданы экземпляры
или объекты.

Рассмотренные
выше обозначения относятся к
конкретным
классам.
От них следует отличать абстрактные
классы.

Абстрактный
класс
(abstract class) — класс,
который не имеет экземпляров или
объектов.

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

В
некоторых случаях необходимо явно
указать, к какому пакету относится
тот или иной класс.
Для этой цели используется специальный
символ разделитель – двойное
двоеточие — ( ::).
Синтаксис строки имени
класса
в этом случае будет следующий: <Имя
пакета>::< Имя
класса
>.
Другими словами, перед именем
класса
должно быть явно указано имя пакета,
к которому его следует отнести.
Например, если определен пакет с
именем Банк,
то класс
Счет
в этом банке может быть записан в
виде: Банк::Счет.

Атрибуты
класса

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

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

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

<квантор
видимости> <имя атрибута>
[кратность] :

<тип
атрибута> = <исходное значение>
{строка-свойство}.

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

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

Символ
» +
» – обозначает атрибут
с областью видимости типа общедоступный
( public
). Атрибут
с этой областью видимости доступен
или виден из любого другого класса
пакета, в котором определена
диаграмма.
Символ
» #
» – обозначает атрибут
с областью видимости типа защищенный
( protected
). Атрибут
с этой областью видимости недоступен
или невиден для всех классов,
за исключением подклассов данного
класса.
Символ
» —
» – обозначает атрибут
с областью видимости типа закрытый
( private
). Атрибут
с этой областью видимости недоступен
или невиден для всех классов
без исключения.
И,
наконец, символ » ~
» — обозначает атрибут
с областью видимости типа пакетный
( package
). Атрибут
с этой областью видимости недоступен
или невиден для всех классов
за пределами пакета, в котором
определен класс
-владелец данного атрибута.

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

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

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

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

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

Если
в качестве кратности
указывается единственное число, то
кратность
атрибута
принимается равной данному числу.
Если же указывается единственный
знак » *
«, то это означает, что кратность
атрибута
может быть произвольным положительным
целым числом или нулем. В языке UML
кратность
широко используется также для задания
ролей ассоциаций, составных объектов
и значений атрибутов.
Если кратность
атрибута
не указана, то по умолчанию в языке
UML принимается ее значение равное
[1..1],
т.е. в точности 1.

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

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

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

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

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

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

Операции
класса

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

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

<квантор
видимости> <имя операции>(

список
параметров):

<выражение
типа возвращаемого значения>

{строка-свойство}

Квантор
видимости,
как и в случае атрибутов
класса,
может принимать одно из четырех
возможных значений и, соответственно,
отображается при помощи специального
символа либо ключевого слова. Символ
» +
» обозначает операцию
с областью видимости типа общедоступный
( public
). Символ » #
» обозначает операцию
с областью видимости типа защищенный
( protected
). Символ » —
» используется для обозначения
операции
с областью видимости типа закрытый
( private
). И, наконец, символ » ~
» используется для обозначения
операции
с областью видимости типа пакетный
( package
).

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

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

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

<направление
параметра> <имя параметра>:

<выражение
типа> =

<значение
параметра по умолчанию>.

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

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

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

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

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

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

Расширение
языка UML для построения моделей
программного обеспечения и
бизнес-систем

Одним
из несомненных достоинств языка UML
является наличие механизмов
расширения, которые позволяют ввести
в рассмотрение дополнительные
графические обозначения, ориентированные
для решения задач из определенной
предметной области. Язык UML содержит
два специальных расширения: профиль
для процесса разработки программного
обеспечения (The UML Profile for Software
Development Processes) и профиль для
бизнес-моделирования (The UML Profile for
Business Modeling).

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

Управляющий
класс
(control class) — класс,
отвечающий за координацию действий
других классов.
На каждой диаграмме классов
должен быть хотя бы один управляющий
класс,
причем количество посылаемых
объектам управляющего класса
сообщений мало, по сравнению с числом
рассылаемых ими. Управляющий класс
отвечает за координацию действий
других классов.
У каждой диаграммы классов
должен быть хотя бы один управляющий
класс,
контролирующий последовательность
выполнения действий этого варианта
использования. Как правило, данный
класс
является активным и инициирует
рассылку множества сообщений другим
классам
модели. Кроме специального обозначения
управляющий класс
может быть изображен в форме
прямоугольника класса
со стереотипом <<control>>
(рис.
5.3, а).
Класс
-сущность (entity class) — пассивный класс,
информация о котором должна храниться
постоянно и не уничтожаться с
выключением системы. Класс
-сущность содержит информацию,
которая должна храниться постоянно
и не уничтожается с уничтожением
объектов данного класса
или прекращением работы моделируемой
системы, связанные с выключением
системы или завершением программы.
Как правило, этот класс
соответствует отдельной таблице
базы данных. В этом случае его
атрибуты
являются полями таблицы, а операции
– присоединенными или хранимыми
процедурами. Этот класс
пассивный и лишь принимает сообщения
от других классов
модели. Класс
-сущность может быть изображен также
стандартным образом в форме
прямоугольника класса
со стереотипом <<entity>>
(рис.
5.3, б).
Граничный
класс
(boundary class) — класс,
который располагается на границе
системы с внешней средой и
непосредственно взаимодействует
с актерами, но является составной
частью системы. Граничный класс
может быть изображен также стандартным
образом в форме прямоугольника
класса
со стереотипом <<boundary>>
(рис.
5.3, в).

Рис.
5.3.
Графическое изображение классов
для моделирования программного
обеспечения

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

Сотрудник
(business worker) — класс,
служащий на диаграмме классов
для представления любого сотрудника,
который является элементом
бизнес-системы и взаимодействует
с другими сотрудниками при реализации
бизнес-процесса. Этот класс
также может быть изображен в форме
прямоугольника класса
со стереотипом <<worker>>
или <<internalWorker>>
(рис.
5.4, а).
Сотрудник
для связи с окружением (caseworker) –
класс,
служащий для представления в
бизнес-системе такого сотрудника,
который, являясь элементом
бизнес-системы, непосредственно
взаимодействует с актерами
(бизнес-актерами) при реализации
бизнес-процесса. Этот класс
также может быть изображен в форме
прямоугольника класса
со стереотипом <<caseWorker>>
(рис.
5.4, б).
Бизнес-сущность
(business entity) — специальный случай
класса
-сущности, который также не инициирует
никаких сообщений. Этот класс
служит для сохранения информации
о результатах выполнения бизнес-процесса
в моделируемой бизнес-системе или
организации. Этот класс
также может быть изображен в форме
прямоугольника класса
со стереотипом <<business
entity>>
(рис.
5.4, в).

Рис.
5.4.
Графическое изображение классов
для моделирования бизнес-систем

Интерфейс

Интерфейс
(interface) — именованное множество
операций,
которые характеризуют поведение
отдельного элемента модели.

Интерфейс
в контексте языка UML является
специальным случаем класса,
у которого имеются операции,
но отсутствуют атрибуты.
Для обозначения интерфейса
используется специальный графический
символ окружность или стандартный
способ – прямоугольник класса
со стереотипом <<interface>>
(рис.
5.5).

На
диаграмме вариантов использования
интерфейс
изображается в виде маленького
круга, рядом с которым записывается
его имя (рис.
5.5, а).
В качестве имени может использоваться
существительное, которое характеризует
соответствующую информацию или
сервис, например, » Датчик
температуры
«, » Форма
ввода
«, » Сирена
«, » Видеокамера
» (рис.
5.5, б).
С учетом языка реализации модели
имя интерфейса,
как и имена
других классов,
рекомендуется записывать на английском
и начинать с заглавной буквы I,
например, ITemperatureSensor,
IsecureInformation
(рис.
5.5, в).

Рис.
5.5.
Примеры графического изображения
интерфейсов на диаграммах классов

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

Источник

Содержание

Формализация функциональных требований к системе с помощью диаграммы вариантов использования
Создание сценариев в Excel
Пример сценариев в Excel
Сценарии Excel. С помощью диспетчера сценариев возможно:
Просмотр результатов работы сценария
Некоторые замечания
Шаги 10 для создания сценариев в Excel
Создание различных сценариев

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

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

Требование (requirement) – желательное свойство, характеристика или условие, которым должна удовлетворять система в процессе своей эксплуатации.

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

функциональные требования (Functionality)
требования удобства использования (Usability)
требования надежности (Reliability)
требования производительности (Performance)
требования возможности сопровождения (Supportability)

При этом символом “+” обозначены дополнительные условия, к которым относятся:

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

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

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

Сценарий (scenario) – определенная последовательность действий, которая описывает действия актеров и поведение моделируемой системы в форме обычного текста.

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

Таблица 4.1. Шаблон для написания сценария отдельного варианта использования

Главный раздел	Раздел “Типичный ход событий”	Раздел “Исключения”	Раздел “Примечания”
Имя варианта использования	Типичный ход событий, приводящий к успешному выполнению варианта использования	Исключение № 1	Примечания № 1
Актеры	Исключение № 2	Примечания № 2
Цель	…	…
Краткое описание
Тип
Ссылки на другие варианты использования	Исключение № N	Примечания № N

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

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

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

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

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

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

Пример сценариев в Excel

Для примера применения сценариев в практике, будем использовать простые задачи. Допустим нам нужно накопить 13 800$ за 10 лет на банковском депозите с определенной процентной ставкой. Нам нужно узнать какой будем делать ежегодный взнос на депозит. И какая процентная ставка нас устроит для накопления денежных средств.

Составьте таблицу так как указано на рисунке:
Выделите диапазон ячеек B1:B2 и выберите инструмент: «Данные»-«Работа с данными»-«Анализ что если»-«Диспетчер сценариев».
В диспетчере нажмите на кнопку «Добавить».
В окне «Добавление сценария» укажите имя «Макс.ставка%» и ссылку на диапазон изменяемых ячеек. И нажмите ОК.
Появится окно «Значения ячеек сценария», в нем введите новое значение 7% для ячейки B1, а в B2 не изменяйте как выше указано на рисунке. И нажмите ОК.
Повторите выше указанные пункты с 3 по 5. Только на этот раз в 4-ом пункте укажите имя «Макс.взнос»; в 5-том пункте укажите новое значение взноса -1100 для ячейки B2, а B1 оставьте без изменений как ниже на рисунке:
Теперь в диспетчере сценариев нажмите на кнопку отчет.
Ничего не меняя жмем ОК.

Готово!!!

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

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

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

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

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

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

Сценарии Excel. С помощью диспетчера сценариев возможно:

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

Сценарием называют именованную совокупность данных изменяемых ячеек. Отметим, что для ячеек аргументов функций можно задать разные значения. С помощью команды Меню Данные — группа Работа с данными — Анализ «что-если» — можно вызвать диалоговое окно «Диспетчер сценариев», для значений ячеек текущего листа Excel. Как показано на первом рисунке

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

Чтобы создать новый сценарий, нужно кликнуть по кнопке «Добавить», после чего появится новое диалоговое окно.

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

Последний показатель — автора, можно изменить, используя команду Сервис -> Параметры, графа «Общие», поле «Имя пользователя».

Переключатель «Запретить изменения» реализует защиту данных изменяемых ячеек приложения от какого-либо редактирования. Устанавливая флажок переключателя «Скрыть», можно добиться того, что имя сценария не будет показываться в списке. Нажимая на «ОК» вы увидите диалоговое окно, с помощью которого можно будет ввести значения изменяемых ячеек.

Просмотр результатов работы сценария

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

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

Нажимая кнопку «Закрыть», можно выйти из «Диспетчера сценариев», причем в редактируемых ячейках сохранятся значения последнего сценария, что участвовал в просмотре. Клавиша «Отчет» позволяет получать необходимые отчеты по сценариям. Вы можете выбрать нужный тип итогового отчета.

В окне «Ячейки результатов» указываются адреса ячеек, показатели которых зависят от изменяемых сценариев.

Можно наблюдать два типа отчетов:

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

Некоторое время назад мне пришлось столкнуться с такой функцией MS Excel, как Сценарии. В процессе освоения этого «НЕЧТО» у меня созрел некий небольшой обзор, которым и хочу поделиться с вами.

Для чего можно использовать функцию Сценарии? Попробую ответить на этот вопрос. Большинство людей, рано или поздно, приходят к мысли о необходимости взять кредит или же наоборот, возникает мысль вложить деньги в какой-либо инвестиционный проект, чтобы они не «лежали мертвым грузом», а «работали». И в том и в другом случае перед человеком встает множество вариантов: множество банков, предлагающих кредиты на различных условиях, множество инвестиционных проектов с различными ставками и прибылью. Какой же вариант выбрать? Как наглядно увидеть, какой проект наиболее выгоден, при каком кредите будет наименьшая переплата, ведь условий множество. Например, кредит: некоторые банки предлагают, казалось бы, выгодный процент, но берут при этом плату за открытие и обслуживание счета, другие банки не взимают платежей за обслуживание счета, но у них больший процент, а кто-то вообще берет первоначальный взнос и процент у них грабительский. Как разобраться во всем этом многообразии? Эту проблему помогают решить экселевские Сценарии. Нет, конечно, Excel не сможет принять решение за Вас куда вкладывать деньги или в какой банк идти за кредитом, но с задачей подсчета и наглядного представления информации он справляется великолепно! Итак, наглядно рассмотрим 2 варианта использования функции Сценарии: в первом варианте сравним 3 инвестиционных проекта, во втором выберем один банк из трех, предлагающий наилучшие условии кредитования.

1 вариант.

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

Год	I проект	II проект	III проект
Начальные инвестиции (год 0)	— 17 000 000 р.	-20 000 000 р.	-30 000 000 р.
Год 1	3 000 000 р.	14 000 000 р.	12 000 000 р.
Год 2	4 000 000 р	8 000 000 р.	12 000 000 р.
Год 3	17 000 000 р	4 000 000 р.	16 000 000 р.

Перенесем исходные данные в Excel.

Посчитаем простую сумму денежных вложений и поступлений для каждого проекта.

Для сравнения этих проектов нам понадобятся такие показатели как 1. чистый приведенный доход или NPV (он показывает величину денежных средств, которую инвестор ожидает получить от проекта, после того, как денежные притоки окупят его первоначальные инвестиционные затраты и периодические денежные оттоки, связанные с осуществлением проекта); и 2. Внутренняя ставка доходности или IRR (это процентная ставка, при которой чистый приведенный доход (NPV) равен 0).

Чистый приведенный доход определяется функцией ЧПС. Рассчитаем ЧПС для всех трех проектов.

Делается это c помощью Мастера функций. Выделим ячейку B9, на панели инструментов, в закладке «формулы» найдем кнопку f x. В диалоговом окне мастера функций в разделе «категория» выберем «финансовые», ниже, в разделе «выберите функцию» найдем ЧПС и выделим ее, нажмем ОК.

Появилось второе диалоговое окно мастера функций для ввода аргументов.

В поле «ставка» введем адрес ячейки B2 просто щелкнув по этой ячейке мышкой.

В поле «значение 1» — адрес ячейки B5

В поле «значение 2» — адрес ячейки B6

В поле «значение 3» — адрес ячейки B7.

Нажмем ОК. В ячейке B9 появилось значение чистого приведенного дохода. Растянем эту формулу на соответствующие ячейки двух других проектов.

В ячейке B10 рассчитаем внутреннюю ставку доходности для первого проекта посредством введения финансовой функции ВСД. В открывшемся диалоговом окне в поле аргументы «значения» введем блок ячеек B4:B7.

Нажмем ОК. В ячейке B10 появилось значение внутренней ставки доходности. Растянем формулу на соответствующие ячейки двух других проектов.

Необходимые экономические показатели для сравнения проектов вычислены.

Приступаем к построению сценариев.

На панели инструментов, в закладке «данные» находим кнопку «Анализ «что-если». Нажимаем. В появившемся меню выбираем «диспетчер сценариев». Откроется диалоговое окно «диспетчер сценариев».

Нажимаем кнопку «добавить». В диалоговом окне «добавление сценария», поле ввода «Название сценария» пишем «проект 1». В поле ввода «изменяемые ячейки» запишем латинскими буквами абсолютные адреса блока ячеек B4:B7 ($B$4:$B$7) или просто выделим этот блок ячеек мышкой. Внизу окна необходимо отключить опцию «запретить изменения».

Нажимаем ОК. В открывшемся окне «значение ячеек сценария» для проекта 1 ничего менять не нужно,

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

Но поскольку проектов у нас 3, нужно создать сценарии для проектов 2 и 3. Нажимаем кнопку «добавить». Снова открывается окно «Добавление сценария». В поле «Название сценария» пишем «проект 2». В поле ввода «изменяемые ячейки» запишем латинскими буквами абсолютные адреса блока ячеек B4:B7 ($B$4:$B$7) или просто выделим этот блок ячеек мышкой. Внизу окна необходимо отключить опцию «запретить изменения».

Нажимаем кнопку ОК. Для второго проекта значения ячеек сценария необходимо откорректировать.

Нажмем кнопку ОК. У нас снова открылось диалоговое окно, но теперь в поле сценарий уже есть сценарии для проекта 1 и для проекта 2. Создаем сценарий для третьего проекта. Нажимаем кнопку «добавить». В диалоговом окне «добавление сценария», поле ввода «Название сценария» пишем «проект 3». В поле ввода «изменяемые ячейки» запишем латинскими буквами абсолютные адреса блока ячеек B4:B7 ($B$4:$B$7) или просто выделим этот блок ячеек мышкой. Внизу окна необходимо отключить опцию «запретить изменения».

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

Нажимаем кнопку ОК. В уже хорошо знакомом нам окне «диспетчер сценариев» появились сценарии для всех трех наших проектов.

Сделаем отчет по этим сценариям. Для этого нажмем кнопку «отчет».

В открывшемся диалоговом окне «отчет по сценарию» выберем типа отчета «структура», в качестве ячеек результата выберем блок ячеек В9:В10

Нажмем ОК. Открылся вновь созданный лист с названием «Структура сценария»

Это и есть итоговая таблица – результат работы Сценариев. Теперь на листе «проекты» мы можем переключаться между различными сценариями при помощи одной кнопки. Для этого на панели инструментов, в закладке «данные» снова находим кнопку «Анализ «что-если». Нажимаем. Снова открывается окно диспетчера сценариев.

В окне «Сценарии» выделим вариант 2. Внизу диалогового окна нажмем кнопку «вывести». В ячейках В4:В10 появились значения для второго сценария.

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

Вернемся к листу «Структура сценариев». Для наглядности внесем в полученную таблицу поясняющий текст и удалим всю лишнюю информацию.

2 вариант.

Например Вы задумались о покупке машины. Для этого Вам необходим кредит. Нужно определить в каком из имеющихся банков наиболее оптимальные условия. Одним из самых главных вопросов для каждого человека, задумавшегося о кредите, является вопрос «сколько мне нужно будет отдавать в месяц своих кровно заработанных денег на погашение кредита», этот показатель необходимо просчитать и оценить заранее, чтобы потом, когда Вы уже ввяжетесь в кредит, не оказаться в ситуации, когда придется отдавать большую часть зарплаты, а оставшихся денег будет хватать только на макароны и сыр. Но помимо этого, очень важным, также считаю, переплату по кредиту. При кредите переплата непременно будет, на этом банки и зарабатывают деньги, но итоговая сумма переплаты должна быть разумной, к чему брать кредит на машину, если переплата по нему через 3 года составит 2 или 3 стоимости этого самого автомобиля?

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

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

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

нажмем ОК.

Заполним аргументы функции. В поле «ставка» заносим адрес ячейки В2. Если бы мы рассчитывали ежегодные платежи, то мы бы ничего менять не стали в этой ячейке, но поскольку мы рассчитываем ежемесячные платежи, а размер ставка – годовой, то после адреса ячейки ставим «/12». Таким образом мы высчитываем ежемесячную процентную ставку. Поле «Кпер» заполняем адресом ячейки В4. Количество периодов у нас выжарено в месяцах, поэтому здесь больше ничего делать не нужно. В поле «Пс» нужно указать адрес ячейки, которая отображает сумму, которую мы хотим взять в кредит. Если бы у нас не было первоначального взноса, то в данном поле мы бы просто указали адрес ячейки В1, но поскольку мы берем в кредит не полную стоимость автомобиля, а стоимость автомобиля за вычетом первоначального взноса. Таким образом в это поле вносим: В1-В3. В поле Бс ставим 0, т.к. после последней выплаты наш долг банку должен быть полностью погашен, т.е. равен 0. В поле Тип также ставим 0, т.к. выплаты в нашем случае производятся в конце периода.

Нажем ОК.

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

Реальная стоимость покупки = (сумма ежемесячных выплат * срок кредита) – начальный взнос – (сумма кредита * % за открытие счета) – (ежемесячные платежи за обслуживание счета * срок кредита)

Рассчитаем Суммы переплаты. Она рассчитывается по формуле: Сумма кредита + реальная стоимость покупки

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

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

Отключаем опцию «запр

етить изменения». Нажимаем ОК. В открывшемся окне «значения ячеек сценария» меняем значения в полях на соответствующие значения для Бака А.

Нажимаем ОК. Снова появляется окно диспетчера сценариев. Нажимаем кнопку «добавить». Вносим название банка и диапазон изменяемых ячеек (он соответствует диапазону ячеек для Банка А)

Отключаем опцию «запретить изменения». Нажимаем ОК. В открывшемся окне «значения ячеек сценария» меняем значения в полях на соответствующие значения для Бака ББ.

Нажимаем ОК.

Теперь в диалоговом окне диспетчера сценариев появились сценарии для двух банков: Банка А и Банка ББ.

Подобным образом создадим сценарий для Банка ВВВ. Нажимаем кнопку «добавить». Вносим название банка и диапазон изменяемых ячеек (он соответствует диапазонам ячеек для Банка А и Банка ББ). Отключаем опцию «запретить изменения».

Нажимаем ОК. В открывшемся окне «значения ячеек сценария» меняем значения в полях на соответствующие значения для Бака ВВВ.

Нажимаем ОК. Теперь в диалоговом окне диспетчера сценариев появились сценарии для двух банков: Банка А, Банка ББ и Банка ВВВ.

Теперь все сценарии готовы. Мы можем переключаться между готовыми сценариями при помощи кнопки «вывести». Но! Диспетчер сценариев дает возможность создать отчеты по сценариям, что мы сейчас и сделаем. Это очень удобно и наглядно. В диалоговом окне диспетчера сценарием нажимаем кнопку «Отчет». Появляется окошко отчета по сценарию.

Выбираем тип отчета «структура», в поле ячейки результата вносим адреса блока ячеек В9:В11.

Нажимаем кнопку ОК.

Мы оказываемся на новом листе, только что созданным Excel-ем, который называется «Структура сценария»

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

Некоторые замечания

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

Рис. 8. Отчет по сценариям в виде сводной таблицы

Если в диалоговом окне Диспетчер сценариев выбрать один из сценариев и нажать кнопку Вывести, на листе с моделью (рис. 9) появятся значения входных ячеек для выбранного сценария, и все формулы будут автоматически пересчитаны для выбранного сценария. Этот инструмент отлично подходит для подготовки презентации. Ctrl+Z отменяет работу сценария, и возвращает лист в исходное состояние.

Рис. 9. На лист с моделью выведены расчет для наиболее благоприятного сценария

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

Как и в любой структуре данных при нажатии на знак «минус» (–) в строках 5 и 9 отчета Структура сценария (см. рис. 7) строки с предполагаемыми значениями скрываются, а отображаются только результаты. При нажатии на знак «плюс» (+) отчет восстанавливается в полном объеме.

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

Шаги 10 для создания сценариев в Excel

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

2. Выберите диапазон значений, которые вы хотите сохранить в сценарии:

3. Нажмите Данные, а в группе Инструмент данных, нажмите Тестирование данных.

4. В появившемся меню нажмите Менеджер сценариев.

5. Это будет окно, которое появляется Менеджер сценариев, В этом окне нажмите Добавлять.

6. В поле Название пейзажа, назовите свой новый сценарий. В нашем примере мы создаем таблицу бюджета за август.

7. Это будет окно, которое появляется Величины сценария. При необходимости измените эти значения.

8. Нажмите Ok, Ваш новый будет создан и будет отображаться в Менеджер сценариев.

9. Повторите операцию и создайте столько сценариев, сколько вам нужно.

10. Теперь вы можете просматривать сценарий, который вы хотите. Просто выберите его в окне Менеджер сценариев, и нажмите на опцию шоу.

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

Создание различных сценариев

Что будет, если Вы продадите 70% книг по высокой цене? А что будет, если Вы продадите 80% книг? Или 90%, или 100%? Каждый другой процент продажи книг – это различный сценарий.
Вы можете использовать “Диспетчер сценариев” для создания этих сценариев.

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

Итак, приступим.

1. На вкладке Данные выберите Анализ “что если” и выберите Диспетчер сценариев из списка.
Откроется диалоговое окно Диспетчер сценариев.

2. Добавьте сценарий, нажав на кнопку Добавить.

3. Введите имя (60% книг по высокой цене), выберите ячейку C4 (% книг, которые продаются по высокой цене) для изменяемой ячейки и нажмите на кнопку OK.

4. Введите соответствующее значение 0,6 и нажмите на кнопку OK еще раз.

5. Далее, добавьте еще 4 других сценария (70%, 80%, 90% и 100% соответсвенно).

И, наконец, ваш Диспетчер сценариев должен соответствовать картинке ниже:

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

Источники

https://www.intuit.ru/studies/courses/32/32/lecture/1006
https://exceltable.com/vozmojnosti-excel/dispetcher-scenariev-v-excel
http://word-office.ru/kak-sdelat-scenariy-v-excel.html
https://baguzin.ru/wp/dispetcher-stsenariev-dlya-analiza-prognoznoj-modeli/
https://blog.luz.vc/ru/%D0%BF%D1%80%D0%B5%D0%B2%D0%BE%D1%81%D1%85%D0%BE%D0%B4%D0%B8%D1%82%D1%8C/%D0%BD%D0%B0%D1%83%D1%87%D0%B8%D1%82%D1%8C%D1%81%D1%8F-%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C-%D1%81%D1%86%D0%B5%D0%BD%D0%B0%D1%80%D0%B8%D0%B8-excel/
http://www.excelguide.ru/2016/03/what-if-analysis.html

Источник

Главная / Программирование /
Язык UML 2 в анализе и проектировании программных систем и бизнес-процессов / Тест 2

Упражнение 1:

Номер 1

Какое определение диаграммы вариантов использования (use case diagram) является правильным?

Ответ:

(1) диаграмма вариантов использования визуализирует отношения между актерами и вариантами использования

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

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

Номер 2

 Как изображается вариант использования (use case) в нотации UML 2?

Ответ:

(1) files

(2) files

(3) files

Номер 3

 Какое определение актера (actor) является правильным в UML 2?

Ответ:

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

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

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

Упражнение 2:

Номер 1

 Как изображается актер (actor) в нотации UML 2?

Ответ:

(1) files

(2) files

(3) files

Номер 2

 Какое из высказываний справедливо применительно к отношению включения?

Ответ:

(1) отношение включения связывает актера с отдельным вариантом использования

(2) отношение включения связывает только два варианта использования

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

Номер 3

 Как изображается отношение включения в нотации UML 2?

Ответ:

(1) files

(2) files

(3) files

Упражнение 3:

Номер 1

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

Ответ:

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

(2) отношение расширения связывает только два варианта использования

(3) отношение расширения связывает отдельных актеров между собой

Номер 2

 Как изображается отношение расширения в нотации UML 2?

Ответ:

(1) files

(2) files

(3) files

Номер 3

 Выберите правильное окончание следующей фразы: "Ассоциация на диаграмме вариантов использования связывает…"

Ответ:

(1) «…отдельного актера с некоторым вариантом использования»

(2) «…отдельных актеров между собой»

(3) «…отдельные варианты использования между собой»

Упражнение 4:

Номер 1

 Как изображается отношение ассоциации в нотации UML 2?

Ответ:

(1) files

(2) files

(3) files

Номер 2

 Какие из высказываний справедливы применительно к отношению обобщения?

Ответ:

(1) отношение обобщения может связывать актера с отдельным вариантом использования

(2) отношение обобщения может связывать два варианта использования

(3) отношение обобщения может связывать отдельных актеров между собой

Номер 3

 Как изображается отношение обобщения в нотации UML 2?

Ответ:

(1) files

(2) files

(3) files

Упражнение 5:

Номер 1

 Какое определение сценария (scenario) является правильным?

Ответ:

(1) сценарий представляет собой требования к пользователю, который взаимодействует с моделируемой системой

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

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

Номер 2

 Как изображается бизнес-актер (business actor) на диаграмме вариантов использования?

Ответ:

(1) files

(2) files

(3) files

Номер 3

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

Ответ:

(1) главный раздел

(2) типичный ход событий

(3) требования к интерфейсу пользователя

(4) рекомендации программистам

(5) исключения

Упражнение 6:

Номер 1

 Выберите правильное окончание следующей фразы: "Типичный ход событий сценария варианта использования…"

Ответ:

(1) «…всегда выполняется системой в первую очередь»

(2) «…приводит к успешному выполнению варианта использования»

(3) «…выполняется системой автономно без взаимодействия с актером»

Номер 2

 Как изображается бизнес-вариант использования (business use case) на диаграмме вариантов использования?

Ответ:

(1) files

(2) files

(3) files

Номер 3

 Выберите правильное окончание следующей фразы: "Исключение из типичного хода событий …"

Ответ:

(1) «…всегда выполняется системой в фоновом режиме»

(2) «…всегда приводит к успешному выполнению варианта использования»

(3) «…всегда требует спецификации дополнительных логических условий»

Упражнение 7:

Номер 1

 Какие категории требований входят в классификацию требований модели FURPS+?

Ответ:

(1) структурные требования

(2) функциональные требования

(3) требования производительности

(4) требования ответственности пользователей

(5) требования надежности

Номер 2

 Как изображается сотрудник (business worker) в нотации UML 2?

Ответ:

(1) files

(2) files

(3) files

Номер 3

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

Ответ:

(1) в форме примечаний

(2) в форме дополнительных актеров

(3) в форме дополнительных вариантов использования

(4) в форме вложенных диаграмм вариантов использования

Упражнение 8:

Номер 1

 Какие дополнительные требования входят в классификацию требований модели FURPS+?

Ответ:

(1) требования написания сценариев

(2) проектные ограничения

(3) требования выполнения

(4) психологические требования

(5) физические требования

Номер 2

 Какой графический символ служит для изображения примечания (note) в нотации UML 2?

Ответ:

(1) files

(2) files

(3) files

Номер 3

 Выберите правильное окончание следующей фразы: "При разработке диаграммы вариантов использования…"

Ответ:

(1) «…в первую очередь необходимо определить главных и второстепенных актеров»

(2) «…в первую очередь необходимо определить базовые классы моделируемой системы »

(3) «…в первую очередь необходимо определить варианты использования системы»

Источник