Разработка модели вариантов использования и их спецификаций. лаба 4. Отчет по лабораторной работе 4 Разработка модели вариантов использования и их спецификаций

Название	Отчет по лабораторной работе 4 Разработка модели вариантов использования и их спецификаций
Анкор	Разработка модели вариантов использования и их спецификаций
Дата	28.10.2022
Размер	72.98 Kb.
Формат файла
Имя файла	лаба 4.docx
Тип	Отчет #760139

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

«Сибирский государственный университет науки и технологий

имени академика М.Ф. Решетнева»

Отчет по лабораторной работе №4

«Разработка модели вариантов использования и их спецификаций»

Руководитель:

___________________ В.В. Кукарцев

^{(подпись)}

________________________________

^{(оценка, дата)}

Выполнил:

студент группы БПЭ 17-01

____________________ И.О. Фамилия

^{(подпись)}

________________________________

^(дата)

Красноярск 2019

Содержание

Введение 4

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

1.1 Модель вариантов использования 5

1.2 Построение модели вариантов использования 5

2. Спецификация вариантов использования 11

Заключение 14

Введение

Цель данного этапа заключается в разработке требований к программному обеспечению. В России стандартом оформления требований является ГОСТ 34.602-89, который регламентирует содержание технического задания (ТЗ) на разработку автоматизированных информационных систем.

Существуют и другие широко применяемые в мире стандарты, например, IEEE (Institute of Electrical and Electronics Engineers) 830: Standard for Software Requirements Specification (1994).

Процесс разработки требований к ПО (или спецификаций требований) условно можно разделить на три этапа, которые позволяют описать требования на трёх уровнях: 1 уровень – потребности заинтересованных лиц; 2 уровень – функции системы; 3 уровень – требования к реализации функций. Каждый уровень позволяет описать требования на столько детально, насколько этого требует уровень абстракции.

Цель лабораторной работы:

1. научиться разрабатывать модели вариантов использования;

2. научиться организовывать модель вариантов использования;

3. научиться разрабатывать спецификации вариантов использования.

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

1.1 Модель вариантов использования

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

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

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

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

1.2 Построение модели вариантов использования

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

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

Модели вариантов использования приведены на рисунках 1 – 8.

Рисунок 1 – Подсистемы в модели вариантов использования

Рисунок 2 – Диаграмма вариантов использования «Регистрация заказов в АИС»

Рисунок 3 – Диаграмма вариантов использования «Отображение информации о требующихся заказах, сгруппированной по цехам»

Рисунок 4 – Диаграмма вариантов использования «Автоматизированный контроль за сроком маркировок»

Рисунок 5 – Диаграмма вариантов использования «Автоматизированное составление отчетов»

Рисунок 6 – Диаграмма вариантов использования «Автоматизированный контроль за количеством и сроком годности продуктов на складе»

Рисунок 7 – Диаграмма вариантов использования «Автоматизированный формирование бух/нал отчетности»

Рисунок 8 – Диаграмма вариантов использования «Автоматизированное начисление з/п»

2. Спецификация вариантов использования

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

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

Исходя из вариантов использования, предполагается разработать следующие спецификации вариантов использования:

1. Регистрация заказов в АИС;

2. Отображение информации о требующихся заказах, сгруппированной по цехам;

3. Автоматизированный контроль за сроком маркировок;

4. Автоматизированное составление отчетов;

5. Автоматизированный контроль за количеством и сроком годности продуктов на складе;

6. Автоматизированное формирование бух/нал отчетности;

7. Автоматизированное начисление з/п.
1. Регистрация заказов в АИС.

Регистрация заказов в АИС – это первый и самый главный этап во всей системе. Все данные о заказах должны быть внесены в базу данных.

Регистрация может осуществляться двумя способами:

- традиционно, через общий компьютер в зале;

- современно, с помощью индивидуального планшета у официантов.

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

- дата и время заказа (определяется автоматически);

- номер заказа (определяется автоматически);

- индивидуальный номер официанта (определяется автоматически);

- номер столика;

- содержимое заказа (наименование и кол-во блюд).

2. Отображение информации о требующихся заказах, сгруппированной по цехам.

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

3. Автоматизированный контроль за сроком маркировок.

Шеф-повар вводит свой логин и пароль и ему открывается приложение из трех вкладок «Уведомления», «Календарь», «Продукты» и кнопки «Отчет».

На вкладке «Уведомления» содержится информация о продуктах, у которых истек или скоро истечет срок маркировки.

На вкладке «Календарь» открывается календарь, с открытой по умолчанию текущей датой. На этой вкладке шеф-повар сможет добавлять и удалять маркировки, а также смотреть что нужно будет списать в интересующую дату.

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

Кнопка «Отчет» описана в следующем пункте.

4. Автоматизированное составление отчетов.

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

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

5. Автоматизированный контроль за количеством и сроком годности продуктов на складе.

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

6. Автоматизированное формирование бух/нал отчетности.

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

7. Автоматизированное начисление з/п.

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

Заключение

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