Автоматизация обработки информации по работе туристической фирмы

Министерство образования  и науки РФ

Федеральное государственное  бюджетное  учреждение высшего профессионального  образования

«ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ  НЕФТЕГАЗОВЫЙ  УНИВЕРСИТЕТ»

КАФЕДРА АВТОМАТИЗАЦИИ ВЫЧИСЛИТЕЛЬНОЙ ТЕХНИКИ

 

 

 

 

 

 

 

 

 

 

 

 

Курсовая работа

по дисциплине «Технология разработки программного обеспечения» на тему:

«Автоматизация обработки информации по работе

туристической фирмы»

 

 

 

 

 

 

 

 

 

Выполнила: студентка группы

ИВТм-11-1 Томилова Н. А.

Проверила:  Лозикова И.О.

 

 

 

 

 

 

 

 

 

 

Тюмень 2011 

Содержание

Глава 1. Техническое задание

1.1 Описание и анализ задачи

   1.1.1 ОПИСАНИЕ ЗАДАЧИ И СОСТАВЛЕНИЕ ГЛОССАРИЯ ПРОЕКТА

   1.1.2 СОЗДАНИЕ МОДЕЛИ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ (use case diagram)

   1.1.3 ОПИСАНИЕ ПОТОКОВ СОБЫТИЙ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

1.2 Постановка задачи

    1.2.1 ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ

    1.2.2 НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ

    1.2.3 ВЫХОДНЫЕ СООБЩЕНИЯ

    1.2.4 ВХОДНЫЕ СООБЩЕНИЯ

1.3 Тестирование системы

    1.3.1 МЕТОДЫ ТЕСТИРОВАНИЯ

    1.3.2 ТЕСТОВЫЕ СЛУЧАИ

Глава 2. Проектирование программного обеспечения

2.1 Описание подхода к проектированию 

  2.1.1 Объектно-ориентированное  проектирование

  2.1.2 Описание языка моделирования  UML

  2.1.3 Соглашения по моделированию  

2.2 Аналитическая модель программного  обеспечения

  2.2.1 Диаграмма вариантов использования  (use case diagram) 

  2.2.2 Диаграммы кооперации (collaboration diagram)

  2.2.3 Диаграммы последовательности  вариантов использования (sequence diagram)

  2.2.3 Диаграммы классов уровня  концепции (class diagram)

2.3 Логическая модель программного  обеспечения 

  2.3.1 Диаграммы классов (class diagram)

  2.3.2 Диаграммы состояний классов  (statechart diagram)

  2.3.1 Диаграмма деятельности (activity diagram)

2.4 Физическая модель программного  обеспечения (реализация системы)

  2.4.1 Диаграмма компонентов (component diagram)

  2.4.2 Диаграмма развертывания  (deployment diagram) 

  2.4.3 Генерация кода

Глава 3. Разработка программного обеспечения

3.1 Общие сведения 

  3.1.1 Язык программирования и  среда программирование

  3.1.2 Соглашение по кодированию  программы

3.2 Спецификации программы

  3.2.1 Модульный и файловый  состав 

  3.2.2 Описание классов 

3.3 Руководство пользователя 

  3.3.1 Установка программы

  3.3.2 Пользовательский интерфейс  программы

Приложение А Полный текст соглашения по кодированию

Приложение В Текст программы

Приложение С Результаты тестирования программы

Введение

 

Автоматизация туристического агентства  — это понятие, которого не существует и не может существовать в принципе. Хотя бы потому, что 90% успеха сделки между агентством и туристом состоит в личном контакте. Туристу важно знать своего менеджера, задать ему самые простые вопросы и просто убедиться, что его отдых был отдан в надежные руки. Если бы нынешний рынок был готов к роботам, которые выдавали ваучеры, билеты и страховки в обмен на деньги, то в России бы не было порядка 10 тысяч туристических агентств.

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

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

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

В данной работе будет рассмотрен процесс разработки информационной системы для туристической фирмы.

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

Глава 1. Техническое задание

1.1 Описание задачи

 

Разработать ПС по автоматизации работы туристической фирмы «Круиз».

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

Проводить анализ ситуации на рынке  отдыха:

- выяснить места отдыха, предпочитаемые различными слоями населения;

- определить корреляционную зависимость  между доходом отдыхающих и  суммой, затраченной на отдых;

- выяснить тенденцию к увеличению или уменьшению количества отдыхающих в зависимости от сезона.

Сделать графическую интерпретацию  полученных результатов.

 

 

1.2 Постановка задачи

1.2.1 Функциональные требования

 

   Разрабатываемая программа должна обеспечивать:

1. Создание и ведение информации о турах;
2. Создание и ведение информации отдыхающих;
3. Предоставление путевки отдыхающим;
4. Анализ ситуации на рынке отдыха:

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

5)  Графическая интерпретация результатов анализа.

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

  

Требования к  надежности

 

К надёжности системы предъявляются следующие  требования:

• способность к продолжительной безошибочной работы;
• устойчивость к сбоям в работе программного и аппаратного обеспечения.
• Обеспечение безопасности: многопользовательский режим доступа к базе данных.

 

Требования к  составу и параметрам технических  средств

 

Для работы необходимо наличие персональной ЭВМ, обладающей ниже перечисленными характеристиками.

Объем оперативной памяти должен быть не менее 128МБ.

Процессор должен быть не ниже Pentium II – 400.

Наличие свободного места на жестком  диске в размере не менее 10Мб.

Сетевой адаптер для обмена базами данных и работы в сети: Ethernet-совместимая  карта пропускной способностью 10Мbs.

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

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

Требования к  программной совместимости

 

Для функционирования программы необходимо следующее:

• Операционная система – Windows XP Professional, Windows 7, Windows Vista;
• СУБД - MySQL
• Visual Studio 2010.

 

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

 

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

К пользовательскому интерфейсу системы  предъявляются следующие требования:

• эргономичность;
• эстетическая привлекательность.

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

 

1.2.3 Выходные сообщения

Путевка

Идентификатор: «Путевка»

 Форма представления: 

Вид представления: текстовые  данные

Периодичность: по требованию.

Получатели  и назначение выходной информации: форма «Клиент» предназначена для добавления клиентов сотрудниками, администратором и клиентом. Редактирование для администратора и сотрудников.

Анализ

Идентификатор: «Анализ»

Форма представления:

Вид представления: текстовые  данные

Периодичность: по требованию.

Получатели  и назначение выходной информации: форма «Тур» содержит информацию о туре. Добавление для всех пользователей, редактирование для администратора.

1.2.4 Входные сообщения

Клиент

Фамилия, Имя, Отчество, Возраст, Семейное положение, Образование, Серия паспорта, Номер паспорта.

Источник информации: информацию о клиенте вводит клиент, администратор, сотрудник.

Тур

Название,  Дата с, Дата по, Цена, Место отдыха.

Источник информации: информацию о клиенте вводит администратор, сотрудник.

Место проживания

Название, Тип проживания, Адрес, Телефон, Класс.

Источник информации: информацию о клиенте вводит клиент, администратор, сотрудник.

ТС

Название (тип), Класс.

Источник информации: информацию о клиенте вводит клиент, администратор, сотрудник.

 

 

Глава 2.  Проектирование программного обеспечения

2.1 Описание подхода  к проектированию

2.1.1 Объектно-ориентированное проектирование

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2.1.2 Описание языка моделирования  UML

  2.1.3 Соглашения по моделированию  

 

 

2.2 Аналитическая модель программного  обеспечения

  2.2.1 Диаграмма вариантов использования  (use case diagram) 

  2.2.2 Диаграммы кооперации (collaboration diagram)

  2.2.3 Диаграммы последовательности  вариантов использования (sequence diagram)

  2.2.3 Диаграммы классов уровня  концепции (class diagram)

2.3 Логическая модель программного  обеспечения 

  2.3.1 Диаграммы классов (class diagram)

  2.3.2 Диаграммы состояний классов  (statechart diagram)

  2.3.1 Диаграмма деятельности (activity diagram)

2.4 Физическая модель программного  обеспечения (реализация системы)

  2.4.1 Диаграмма компонентов (component diagram)

  2.4.2 Диаграмма развертывания  (deployment diagram) 

  2.4.3 Генерация кода

3.1 Проектирование  базы данных методом сущность-связь

 

В настоящее время существует много  различных методик проектирования концептуальных схем. Большая часть  из них поддерживает концепцию ER-модели (Entity-Relationship Model – модель типа "Сущность-Связь"), являющуюся одной из разновидностей семантических моделей данных.

Основные преимущества ER-моделей:

• наглядность;
• модели позволяют проектировать базы данных с большим количеством объектов и атрибутов;
• ER-модели реализованы во многих системах автоматизированного проектирования баз данных (например, ERWin).

3.1.1 Построение  диаграммы ER-типа

 

В соответствии с описанием предметной области можно выделить следующие сущности:

1. Блюда
2. Тип блюд
3. Расход
4. Рецепт
5. Продукты

 

Таблица 1 – Информация о сущностях

Сущности	Атрибуты	Идентификатор	Тип
Dish	N_Dish Dish_Name Price Caloric_content Picture	N_Dish	Integer Varchar(20) Integer Integer Blob
Type	N_Type Type_Name	N_Type	Integer Varchar(20)
Consumption	N_Consumption N_Portion Data_of_order	N_Consumption	Integer Integer Data
Продолжение таблицы 1
Сущности	Атрибуты	Идентификатор	Тип
	Table Adress FIO Telefon		Integer Varchar(20) Varchar(20) Integer
Recipe	N_Recipe Coocing_method	N_Recipe	Integer Varchar(500)
Product	N_Product Product_Name Quantity	N_Product	Integer Varchar(20) Integer

 

Определим связи:

Связь между сущностями Type/Dish(тип/блюдо):

Блюдо имеет один тип. Один тип может  соответствовать разным блюдам. Блюдо обязано иметь тип. Из этого следует, что один экземпляр сущности Type может быть связан с N экземплярами сущности Dish. Один экземпляр сущности Dish связан только с одним экземпляром сущности Type. Таким образом, мы получили связь 1 :N. Класс принадлежности сущности Dish обязательный.

Связь  Dish/Recipe (блюдо/рецепт) имеет следующие характеристики:

Каждое блюдо может иметь один рецепт. В свою очередь каждый рецепт принадлежит одному блюду. Блюдо может не иметь рецепта. Рецепт должен иметь блюдо. Из этого следует, что один экземпляр сущности Dish может быть связан c 1 экземплярами сущности Recipe. Каждый экземпляр сущности Recipe может быть связан с 1 экземплярами сущности Dish. Таким образом, мы получили связь    1:1, класс принадлежности сущности Recipe обязательный.

Связь Dish/Consumption(блюдо/расход):

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

Dish/Product (блюдо/продукт):

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

Логическая модель представлена в приложении А (рис. 5).

3.1.2 Генерация набора предварительных отношений

 

Генерация набора предварительных  отношений производится по 8 основным правилам. В результате было получено 6 отношений:

Тип (Номер типа, Название типа);

Блюдо (Номер блюда, Номер типа, Название блюда, Цена, Калории, Рисунок);

Рецепт (Номер рецепта, Описание рецепта, Номер блюда);

Расход (Номер расхода, Номер блюда, Количество порций, Дата, Столик, Адрес, Фамилия_Имя_Отчество, Телефон);

Продукт_Блюдо (Номер блюда, Номер продукта, Вес);

Продукт (Номер продукта, Название продукта, Количество продукта).

База данных проектировалась на Erwin 4.1. Физическая модель представлена в приложении А (рис. 6).

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

Генераторы

CREATE GENERATOR объявляет генератор для  базы данных и устанавливает его начальное значение в нуль. Генератор это последовательный номер, который может быть вставлен в столбец с помощью функции GEN_ID(). Генератор часто используется, что бы гарантировать уникальное значение в PRIMARY KEY, такой как номер счета, который должен уникально идентифицировать ассоциированную строку.

Например, добавление генератора к  таблице Product:

CREATE GENERATOR Product_ID;

set term !! ;

CREATE TRIGGER tI_Product_ID FOR Product Before INSERT  POSITION 0 AS

   begin

   New.N_Product=Gen_ID(Product_ID,1);

end!!

Триггеры

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

Триггер никогда не вызывается непосредственно. Наоборот, когда приложение или пользователь пытаются выполнить инструкцию INSERT, UPDATE или DELETE над строкой в таблице, любые триггеры связанные с этой таблицей и операцией автоматически выполняются.

Рассмотрим пример. Ниже приведен код триггера, который срабатывает  при добавлении нового блюда:

CREATE TRIGGER tI_Dish FOR Dish AFTER INSERT AS

DECLARE VARIABLE numrows INTEGER;

BEGIN

    select count(*)

      from Type

      where

        NEW.N_Type = Type.N_Type into numrows;

    IF (

      numrows = 0

    ) THEN

    BEGIN

      EXCEPTION ERWIN_CHILD_INSERT_RESTRICT;

    END

END !!

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

Хранимая процедура FIND_CONSUMPTION возвращает в выходном параметре название блюда NAZ_DISH, количество  порций KOL и цену PR блюд, дата потребления которых находится в интервале дат (входной параметр), причем количество порций блюд за предложенный период суммируется:

CREATE PROCEDURE FIND_CONSUMPTION (B_DATA DATE,A_DATA DATE)

RETURNS (NAZ_DISH VARCHAR (20), KOL INTEGER, PR INTEGER)  

AS

BEGIN

      FOR

             SELECT Dish_Name ,sum(N_Portion),sum(Price* N_Portion)

             FROM Dish,Consumption

             WHERE Dish.N_Dish=Consumption.N_Dish AND

                   Consumption.Date_of_order BETWEEN :B_Data AND :A_DATA

             GROUP BY Dish_Name

       INTO : NAZ_DISH ,:KOL, :PR  

       DO

BEGIN  

SUSPEND;

  END

 END;

 

Хранимая процедура TIP_DISH возвращает в выходном параметре LIST номер типа блюда, задаваемого входным параметром T_N:

 

CREATE PROCEDURE TIP_DISH (T_N INTEGER)

RETURNS (LIST VARCHAR (20))  

AS

BEGIN

      FOR

             SELECT Distinct Dish_Name FROM Dish,Tip

             WHERE :T_N = Dish.N_Type

             INTO : LIST

     DO

      BEGIN

       SUSPEND;

     END

 END;

 

Хранимая процедура FIND_PRODUCT возвращает в выходых параметрах PROD продукты и REC рецепт, соответствующие номеру блюда - входному параметру В_N:

 

CREATE PROCEDURE FIND_PRODUCT (B_N INTEGER)

RETURNS (PROD CHAR (18), REC VARCHAR (500))  

AS

BEGIN

      FOR

             SELECT Product_Name, Cooking_method

             FROM PRODUCT, RECIPE,Product_Dish

             WHERE :B_N = Product_Dish.N_Dish

             AND Product.N_product=Product_Dish.N_Product

             AND Product_Dish.N_Dish=RECIPE.N_Dish

             INTO : PROD, :REC

      DO

       BEGIN

        SUSPEND;

       END

 END;

 

Полученный SQL–скрипт приведен в приложении Б.

3.1.3 Исследование набора отношений на избыточность

 

Ни одно отношение не имеет множества  атрибутов, являющегося подмножеством множества атрибутов какого-либо другого отношения

 

 

4 Тестирование информационной модели с использованием CASE-пакета

 

   Информационная модель тестируется при помощи программы Erwin Examiner. Обнаружены следующие ошибки:

В результате тестирования модели были выявлены два вида ошибок, носящих рекомендательный характер:

• UndefinedAlternateKey. Таблица имеет суррогатный первичный ключ и не имеет альтернативного ключа.

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

 

• MissingIndex. Отсутствие индексов, например на внешнем ключе.

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

 

5 ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

5.1.1 Функциональные требования

 

На  основе Постановки задачи и дополнительных требований к системе определён окончательный набор функций:

• Предоставление информации по запросу пользователя;
• Обеспечение многопользовательского режима доступа к базе данных;
• Предоставлять возможность редактирования записей в базе данных;
• Учет продуктов;
• Учет ежедневного потребления блюд;
• Учет заказов и расчет стоимости заказа;
• Управление запасами;
• Формирование отчетов.

Требования  к программному обеспечению

Для функционирования программы необходимо следующее:

• Операционная система – Windows XP Professional, Windows 7, Windows Vista;
• СУБД InterBase версии 1.0 и выше;

 

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

Удобство использования

 

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

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

К пользовательскому интерфейсу системы  предъявляются следующие требования:

• эргономичность;
• эстетическая привлекательность;

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

 

Надёжность

 

К надёжности системы  предъявляются следующие требования:

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

5.2 Архитектура и структура системы

 

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

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

5.3 Базовое программное обеспечение

5.3.1 Операционная система

 

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

5.3.2 Средства разработки

 

Процесс разработки ведётся  в визуальной среде программирования Borland С++ 6. Драйверы баз данных dbGo for ADO, dbExpress и BDE, входящие в состав C++Builder, обеспечивают высокопроизводительную работу приложений с такими СУБД, как DB2, Informix, Oracle, Sybase, Microsoft SQL Server, MySQL, Access, Paradox и InterBase. Широкий выбор управляемых данными элементов интерфейса дает возможность быстро создавать прототипы приложений. SQL Monitor и другие отладочные инструменты служат повышению производительности, масштабируемости и уменьшению времени отклика приложений баз данных.

Для создания базы данных использовался InterBase SMP 2009, который объединяет в себе преимущества производительности, которые предлагает мультигенерационная архитектура (multi-generational architecture), с возможностями журналирования и восстановления после сбоев. Новые функции безопасности и шифрования обеспечивают улучшенную защиту данных. Удобная установка, компактность, автоматическое восстановление после сбоев, Unicode, встроенная поддержка симметричной многопроцессорной обработки, соответствие стандарту SQL 92 и минимальные требования к обслуживанию делают InterBase SMP 2009 идеальной базой данных (БД) для встроенных и ответственных серверных приложений для малых и средних организаций.

5.4 Диаграмма вариантов использования

 

Диаграмма вариантов использования     (Use Case, а также: вариант использования, сценарий использования) - спецификация последовательности действий (варианты последовательности), которые может осуществлять система, подсистема или класс, взаимодействуя с внешними актерами (англ. Actors).

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

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

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