Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Описание потока событий

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

Абстрактные варианты использования

Категории вариантов использования

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

 
 

В UML актёр представляется в виде фигуры (имя обязательно), вариант использования в виде эллипса (имя обязательно):

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

Между прецедентами существует два типа отношений зависимости:

1. Отношение включения (include relationship).

2.
Отношение дополнения (extend relationship).

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

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

Отношение дополнения используется для отражения:

- дополнительных режимов;

- режимов, которые запускаются только при определённых условиях (например, сигнал тревоги);

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

Отношение дополнения направлено от дополнительного прецедента к базовому прецеденту.


Главная диаграмма функций системы РЕГИСТРАТОР:

2.7.2 Идентификация актёров и вариантов использования

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

1. Анализ актёров. Идентификация кого-то или чего-то, что связано с предприятием, и что должно взаимодействовать с системой. Это могут быть исполняемые людьми роли (начальник, диспетчер, клиент, системный администратор); другие компьютерные системы (бухгалтерская система, система безопасности); электромеханические устройства (напольная автоматика, датчик), время (если от него зависит выполнение системой каких-либо функций). Далее детализируются для каждого действующего лица процессы, которые эти лица инициируют или в которых участвуют (кассир – регистрация в системе, работа с деньгами; покупатель – покупка товаров, возврат товаров).

2. Анализ событий. Идентификация внешних событий, на которые должна реагировать система. Связывание событий с актёрами и вариантами использования.

Рассмотрим пример определения актёров в системе регистрации курсов университета. Допустим, известны следующие события:

1. Студент хочет зарегистрироваться на курсы.

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

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

4. Регистратор должен хранить информацию о студентах, преподавателях и курсах.

5. Система оплаты должна получать необходимую информацию из системы регистрации.

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

1. Актёры:

- студент,

- преподаватель,

- регистратор,

- система оплаты.

2. Прецеденты:

- для студента: регистрироваться на курсы;

- для преподавателя: выбирать курсы; запрашивать расписание;

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

Следующий пример демонстрирует идентификацию актёров и прецедентов автоматизированной системы розничной торговли.

Допустим, в результате анализа определены следующие актёры и связанные с ними прецеденты:

Кассир Регистрация в системе Оформление покупки
Покупатель Покупка товара Возврат товара
Менеджер Включение системы Отключение системы
Системный администратор Добавление новых пользователей

Варианты использования так же, как и функции системы, делятся на категории. Для классификации use cases приняты следующие категории: основные, второстепенные и дополнительные:

1. Основные (primary use cases) – представляют самые общие процессы. Например, покупка товара.

2. Второстепенные (secondary use cases) – представляют менее значительные или редкие процессы. Например, запрос на новый ассортимент товаров.

3. Дополнительные (optional use cases) – описывают процессы, реализация которых в системе не является обязательной. Например, авторизация главного кассира.

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

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

Вариант использования Покупка товара – Buy Items
Актёры Покупатель, кассир
Категория Основной
Описание Покупатель подходит к кассе с выбранными товарами. Кассир вводит информацию о товаре и оформляет оплату. Покупатель уходит с покупками.

 

Вариант использования Включение – Start Up
Актёры Менеджер
Категория Основной
Описание Менеджер включает систему POST для её дальнейшего использования кассирами и проверяет правильность системной даты и времени, после чего система считается готовой к использованию.

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

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

Конкретные прецеденты записываются в описании потока событий.

2.7.6 Запись актёров и вариантов использования

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

К каждому варианту использования следует подключить текстовый файл в формате MS Word. В этом файле должно находиться подробное описание потока событий для варианта использования – flow of events.

Описание потока событий обычно содержит:

1. Краткое описание.

2. Предусловия (pre-conditions).

3. Основной поток событий.

4. Альтернативный поток событий (или альтернативные потоки).

5. Постусловия (post-conditions).

<== предыдущая лекция | следующая лекция ==>
Использование бизнес-модели на этапах разработки | Основной поток событий
Поделиться с друзьями:


Дата добавления: 2014-01-07; Просмотров: 1839; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.011 сек.