Ирина Эланс

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

Анализ требований программного продукта "Диско-бар"

ФЕДЕРАЛЬНОЕ АГЕНТСВО ПО ОБРАЗОВАНИЮ

Томский государственный университет

систем управления и радиоэлектроники (ТУСУР)

Кафедра автоматизации обработки информации (АОИ)

УТВЕРЖДАЮ

Заведующий кафедрой АОИ

д-р техн. наук, проф.

___________Ю.П. Ехлаков

«___»_____________2007 г.

Диско-бар

курсовая работа по дисциплине

«Объектно-ориентированный анализ и программирование»

ФСУ 0640601

Студент гр. _____

___________Абрамов В.В.

«___»_____________2009 г.

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

Ст. преп. каф. АОИ ____________Д.А. Соловьев

«___»_____________2009 г.

2009

Федеральное агентство по образованию

Томский государственный университет

систем управления и радиоэлектроники (ТУСУР)

Кафедра автоматизации обработки информации (АОИ)

УТВЕРЖДАЮ

Заведующий кафедрой АОИ

д-р техн. наук, проф.

___________Ю.П. Ехлаков

«___»_____________2006 г.

ЗАДАНИЕ

на курсовую работу

студенту Абрамову В.В. группы 406 факультета систем управления

1.Тема работы: проектирование АИС “Диско-бар”

2. Срок сдачи работы на кафедру: «___»________________2009 г.

3. Содержание:

4. Дата выдачи задания: «___»_________________________2009 г.

Руководитель: старший преподаватель кафедры АОИ Соловьев Д.А. «___»___________________2009 г. _____________________________

(подпись руководителя)

Задание принял к исполнению:

«___»___________________2009 г. ______________________________

(подпись студента)

Содержание

1.Анализ предметной области………………………….4

2.Требования к системе………………………………...6

3.Модель прецедентов информационной системы…...9

4.Прецедент «авторизоваться»………………………..12

5.Диаграмма последовательности для прецедента «авторизоваться»……………………………………………16

6.Диаграмма классов…………………………………..17

7.Используемая литература…………………………...20

1.Анализ предметной области

В 21-ом веке, веке информаций, человек начинает проводить всё меньше времени за работой. Работа в новом веке приобрела немного иной смысл – работа в веке информаций подразумевает, что человек больше общается с компьютерами, роботами и другими системами, которые могут выполнить работу за человека. Человек всё меньше начинает тратить время на работу, так как она занимает меньше усилий, нагрузок и времени. В 21-ом веке человек может работать и дома. Соответственно, и время на отдых становится больше, а сам отдых разнообразнее. Перечислять все виды отдыха в 21-ом веке нет смысла, мы же сосредоточимся на интересующей нас теме – бар. Бар – со времён своего появления стал явлением уже привычным, несмотря на то, что первые бары не пользовались популярностью, а их назначение было немного иным. Однако, сейчас бар можно встретить практически на каждом углу и обойтись без него уже, кажется, невозможно. Баром мы пользуемся на дискотеке, в ресторане, спорт - центрах и кафе. Услугами бара пользовался каждый человек, но при этом мало кто задумывался как бар функционирует. Со стороны, конечно, работа бара и бармена кажется до боли простой. Однако, существует целая культура баров, барменов и обслуживания гостей. 21-й век позволил сделать работу бармена проще. Информационная система, которой пользуется бармен, просто способ взаимодействия бармена и гостя. Гости, получив свой заказ и чек к нему, мало когда обращают внимание на то, что написано в чеке, помимо цены. Однако подобный чек может показать, что гость в заведении обслуживается определённым официантом/барменом и определённое время. В целом, информационная система может вести учёт бара и его расходов, являться справочной системой для барменов и официантов, упрощать работу барменов и официантов, делать пребывание гостей в заведении приятнее, когда они видят, за что они платят.

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

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

Заинтересованные стороны:

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

Функции системы(функциональные требования):

Функция 1: учёт товара в баре.
Функция 2: ведение и сохранение отчётов для налоговой.
Функция 3: учёт всех действий, совершаемых при работе с системой (запуск, закрытие, время работы, действия пользователей).
Функция 4: работа с заказами: оформление, изменение, закрытие, расчёт и т.д.
Функция 5: система должна хранить информацию по некоторым позициям меню (коктейли, блюда).
Функция 6: хранение информации о пользователях: статус, идентификационный код, время работы с системой для начисления з/п, проценты с продаж конкретному пользователю.
Функция 7: система должна разграничить права пользователей.

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

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

Ограничения системы:

Тип ограничения:	Пояснение:
Системные	АИС должна поддерживать ОС Microsoft Windows 98,ME,XP,Vista. Минимальные системные требования для АИС: Processor 1,4Ггц, 216 Гб ОЗУ, 200 мб на жёстком диске, клавиатура, мышь, монитор.

Технические

Система должна взаимодействовать с программами Microsoft Word, Miсrosoft Excel для создания отчётов и занесения информации в систему.

3.Модель прецедентов системы

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

Модель разрабатывается для достижения следующих целей:

определить границы и контекст моделируемой системы;

•сформулировать требования к поведению системы;

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

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

Актёры:

Пользователь – тот, кто непосредственно работает с системой. Это может быть бармен или официант.
Администратор – тот, кто занимает управлением системы: запуск/закрытие, назначение персонала, просмотр отчётов.

Прецеденты:

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

4. Прецедент «Авторизоваться»

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

Основной актёр: Пользователь.

Заинтересованные пользователи и их потребности:

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

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

Постусловия (результаты): Авторизация выполнена. Права пользователя определены. Открыто меню работы с системой. Факт и время авторизации запомнены.

Основной успешный сценарий для прецедента «Авторизоваться»:

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

Альтернативные потоки:

*а. При каждом выходе системы из строя.

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

1.Администратор перезапускает систему, регистрируется и предлагает восстановить предыдущее состояние.

2.АИС восстанавливает предыдущее состояние.

2а. АИС определяет аномалию, повлекшую сбой.

1.АИС уведомляет об ошибке администратора, регистрирует ошибку и переходит в начальное состояние.

4. а) Пользователь ввёл не цифровое значение.

1.АИС выдаёт сообщение об ошибке.

2.Пользователь нажимает клавишу Повтор посредством мышки или нажав клавишу Enter.

3.АИС открывает меню авторизации.

4. б) Система не нашла введенный код в базе данных.

1.АИС выводит сообщение об ошибке.

2.Пользователь нажимает клавишу Esc.

2а. Пользователь бездействует, система ждёт 10 секунд.

3. АИС выводит на экран меню авторизации.

6. а) Если статус кода Администратор, система открывает меню администратора.

б) Если статус кода бармен, система открывает Меню столов.

в) Если статус кода официант, система ограничивает права на закрытие заказа и открывает Меню столов.

Специальные требования:

Отклик системы должен происходить в период времени от 0 до 10 секунд.
Монитор, клавиатура, мышь.
Интерфейс должен быть минимизирован, с чёткими цифрами и буквами. Не объёмными, но и не маленькими.

Частота использования:

Постоянно.

5.Диаграмма последовательности для прецедента «авторизоваться»

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

Пользователь – внешний по отношению к системе исполнитель.

ИС – система как «чёрный ящик».

База данных – ресурс системы, хранящий всю информацию по работе с системой.

6.Диаграмма классов

Основной составляющей объектно-ориентированного анализа или исследования является декомпозиция проблемы на отдельные классы понятий (концептуальные классы) или объекты.

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

Модель предметной области — это один из артефактов, создаваемых в рамках дисциплины бизнес-моделирования.

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

Объекты предметной области или концептуальные классы.
Ассоциации между концептуальными классами.
Атрибуты концептуальных классов.

Классы:

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

Пользователь – класс, представляющий собой пользователей, работающих с системой. Пользователь может обращаться к АИС для получения необходимых ресурсов. Пользователь в системе отвечает за стол, который он создал посредствам системы. Атрибуты: ФИО, статус –определяет возможности пользователя в системе (статусы: бармен, официант, администратор), IDD – идентификационный номер пользователя, необходим для авторизации в системе.

Стол – представляет факт создания стола определённым пользователем в определённое время. Класс стол представляет собой объект, за который отвечает пользователь и обращается к нему посредством АИС. Хранит в себе информацию о заказах. Атрибуты: номер – номер одновременно в системе может быть открыто несколько столов и соответственно каждый должен иметь свой номер, дата создания/дата закрытия – хранит информацию о времени создания, закрытий и работы со столом, общая сумма – хранит информацию об общей сумме заказа, зарегистрированного на этом столе с учётом налогов и комиссионных пользователям.

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

Оплата – класс, отвечающий за факт оплаты заказа. Атрибуты: дата, время регистрируют, в какое время была совершена оплата.

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

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

7.Используемая литература

Крачтен Филипп. Введение в Rational Unified Process. 2-е изд.. : Пер. с англ. — М: Издательский дом “Вильямс”, 2002. — 240 с. : ил.
Леоненков А. В. Самоучитель UML. — 2-е изд., перераб. и доп. — СПб.: БХВ-Петербург, 2006. - 432 с.: ил.
Буч Грейди, Рамбо Джеймс, Джекобсон Айвар. Язык UML. Руководство пользователя: Пер. с англ. - М.: ДМК,2000. - 432с.:ил. (Серия “Для программистов”).
Розенберг Дуг, Кендалл Скот. Применение объектного моделирования с использованием UML и анализ прецедентов. Пер. с англ. – М.: “ДМК-Пресс”, 2002. – 160 с.:ил. (Серия “Объектно-ориентированные технологии в программировании”).
Ларман Крэг. Применение UML и шаблонов проектирования. Введение в объектно-ориентированный анализ и проектирование. Пер. с англ.: Уч. Пос. — М: Издательский дом “Вильямс”, 2001. — 496 с.: ил.
Боггс Уэнди, Боггс Майкл. UML и Rational Rose. Пер. с англ. — М: Издательство “Лори”, 2000. — 582 с.: ил.
Леффингуэл Дин, Уидриг Дон. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. Пер. с англ. — М: Издательский дом “Вильямс”, 2002. — 448 с.: ил.
Брайен А. Уайт. Управление конфигурацией программных средств. Практическое руководство по Rational ClearCase. Пер. с англ. – М.: “ДМК-Пресс”, 2002. – 272 с.:ил. (Серия “Объектно-ориентированные технологии в программировании”).
Коналлен Джим. Разработка Web-приложений с использованием UML. Пер. с англ. – М.: Издательский дом “Вильямс”, 2001. – 288 с.:ил.
Электронная версия Rational Unified Process. http://muma.tusur.ru/~sda/RUP/, http://www.rational.com/rup_info/.

Анализ требований программного продукта Диско-бар 📙 Курсовая → 🆔 20712