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

Автор работы: Пользователь скрыл имя, 07 Января 2011 в 10:27, курсовая работа

Описание работы

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

Содержание работы

1.Анализ предметной области………………………….4
2.Требования к системе………………………………...6
3.Модель прецедентов информационной системы…...9
4.Прецедент «авторизоваться»………………………..12
5.Диаграмма последовательности для прецедента «авторизоваться»……………………………………………16
6.Диаграмма классов…………………………………..17
7.Используемая литература…………………………...20

Файлы: 1 файл

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

— 163.50 Кб (Скачать файл)
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

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

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

  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   

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

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

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

   Постоянно. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

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

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

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

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

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

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

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

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

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

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

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

    Классы:

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

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

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

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

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

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

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

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

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

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