Курсовая работа №3647 «Проектирование приложения для гостиницы»

Posted on:
Categories: КУРСОВЫЕ РАБОТЫ

Содержание

Введение 4

1 Первоначальная постановка задачи 5

1.1 Спецификация требований к системе 5

1.2 Проектирование прецедентов 7

1.3 Создание диаграмм прецедентов…8

1.3.1 Определение классов приложения 9

1.3.2 Определение свойств классов 10

1.3.3 Определение ассоциаций классов 11

1.3.4 Моделирование поведения классов 12

2 Развитие постановки задачи 15

2.1 Спецификация требований к системе 15

2.2 Определение классов приложения 16

2.2.1 Определение свойств классов 16

2.2.2 Определение ассоциаций классов 18

2.2.3 Моделирование поведения классов 20

Заключение 22

Список использованных источников 24

Внимание!

Это ОЗНАКОМИТЕЛЬНАЯ ВЕРСИЯ работы №3647, цена оригинала 1000 рублей. Оформлена в программе Microsoft Word.

Оплата. Контакты.

Введение

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

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

На сегодняшний день в качестве средства, реализующего методологию объектно-ориентированного программирования, чаще всего применяется язык моделирования UML[2, 3].

1 Первоначальная постановка задачи

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

1.1 Спецификация требований к системе

Объекты взаимодействующие с системой:

• Пользователь (сотрудник гостиницы) – имеет право подавать запросы на состояние номеров, количество номеров, стоимость номеров, занимается заполнением номерного фонда и изменением цены номера;

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

Функции системы:

• При входе в систему пользователь должен указать свое имя и пароль;

• Пользователь имеет возможность в отдельном окне системы вводить параметры проживающего;

• Пользователь имеет возможность вносить изменения в отдельный справочник номерного фонда;

• Пользователь имеет возможность вносить изменения в отдельный справочник цен номеров в зависимости от сезонности проживания в номере.

• Менеджер гостиницы – при входе в систему должен указать свое имя и пароль;

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

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

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

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

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

1.2 Проектирование прецедентов

Cписок актеров:

• Актер 1 — пользователь;

• Актер 2- менеджер гостиницы.

Прецеденты проектируемого нами приложения сведены в таблицу 1.1.

Таблица 1.1 – Прецеденты приложения

Название Актеры Описание

Вход в систему Пользователь,

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

Просмотр справочника номеров Пользователь, Менеджер гостиницы Просмотр справочника номеров, добавление новых номеров в справочник, смена категории номера в справочнике

Просмотр справочника цен Пользователь, Менеджер гостиницы Просмотр справочника цен, изменение цен в справочнике в зависимости от сезона, добавление новых цен в справочник

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

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

Запрос на дату выезда и въезда Пользователь, Менеджер гостиницы Пользователь нажатием кнопки может найти даты выезда и въезда проживающих

Регистрация приезжающих Пользователь, Менеджер гостиницы Пользователь заполняет данные о приезжающих в открывающихся диалоговых окнах

Размещение приезжающих Пользователь, Менеджер гостиницы Пользователь устанавливает соответствие между номером в гостинице и данными приезжающих с помощью специального диалогового окна

1.3 Создание диаграмм прецедентов

После подготовки спецификации требований можно приступать к созданию диаграмм прецедентов. На рисунке 1.1 приведен проект такой диаграммы разработанный с помощью MicrosoftVisio 2010.

Рисунок 1.1 – Проект диаграммы прецедентов

1.3.1 Определение классов приложения

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

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

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

Таблица 1.2 – Предполагаемы классы системы

Прецедент Возможные классы

Вход в систему Пользователь (сотрудник отдела, менеджер) имя пользователя, пароль, вход в систему, отказ в регистрации

Просмотр справочника номеров Пользователь (сотрудник отдела, менеджер), справочник номеров, категория номера, количество мест, цена

Просмотр справочника цен Пользователь (сотрудник отдела, менеджер), справочник цен, сезонность

Запрос на наличие свободных номеров Пользователь (сотрудник отдела, менеджер), номер, количество, категория номера, цена

Запрос на поиск проживающих Пользователь (сотрудник отдела, менеджер), номер, количество, категория номера, цена

Запрос на дату выезда и въезда Пользователь (сотрудник отдела, менеджер), дата заезда, период проживания, дата отъезда

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

Размещение приезжающих Пользователь (сотрудник отдела, менеджер), фио, количество членов семьи, номер, период проживания

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

Сотрудник отдела;

Менеджер;

Гость (приезжающий);

Номера;

Категория номера;

Цены.

Эскиз диаграммы классов изображен на рисунке 1.2:

Рисунок 1.2 – Эскиз диаграммы классов

1.3.2 Определение свойств классов

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

Свойства классов проектируемого приложения перечислены в таблице 1.

Таблица 1. Свойства классов проектируемого приложения

Класс Свойства Тип значения

Сотрудник отдела ID сотрудника (идентификатор сотрудника) Число

Зарегистрированное имя Строка

Пароль Строка

Имя Строка

Фамилия Строка

Гость ID гостя Число

Имя Строка

Фамилия Строка

Номер паспорта Число

Регистрация Строка

Дата регистрации Дата

Номер гостиницы Число

Менеджер ID сотрудника (идентификатор сотрудника) Число

Зарегистрированное имя Строка

Пароль Строка

Имя Строка

Фамилия Строка

Номера ID номера Число

Категория номера Строка

Количество мест Число

Цена номера Число

Цены ID цены Число

Категория цены Число

Период Дата

Категория номера ID категории номера Число

Категория Строка

1.3.3 Определение ассоциаций классов

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

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

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

Экземпляр класса «Сотрудник отдела» — несколько экземпляров класса «Номера»

Экземпляр класса «Номера» — один экземпляр класса «Сотрудник отдела»

Экземпляр класса «Номера» — несколько экземпляров класса «Цены»

Экземпляр класса «Цены» — несколько экземпляров класса «Номера»

Экземпляр класса «Гость» — один экземпляр класса «Номера»

Экземпляр класса «Номера» — несколько экземпляров класса «Гость»

Экземпляр класса «Цены» — один экземпляр класса «Категория номера»

Экземпляр класса «Категория номера» — несколько экземпляров класса «Цены»

Экземпляр класса «Менеджер» — несколько экземпляров класса «Номера»

Экземпляр класса «Номера» — один экземпляр класса «Менеджер»

1.3.4 Моделирование поведения классов

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

Рассмотрим сценарий выполнения прецедента «Вход в систему»:

1. На экране появляется диалоговое окно входа в систему;

2. Пользователь вводит свое имя и пароль;

3. Пользователь подтверждает введенную информацию;

4. Выполняется проверка имени и пароля, проверяется их подлинность;

5. Появляется окно для выполнения запроса.

Следующим сценарием будет выполнение прецедента «Просмотр справочника номеров».

1. Пользователь подтверждает данные, введенные при входе в систему;

2. Пользователь открывает каталог «Справочник номеров»;

3. Пользователь просматривает каталог «Справочник номеров»;

4. Пользователь обновляет информацию в справочнике.

Рассмотрим сценарий прецедента «Просмотр справочника цен».

1. Пользователь подтверждает данные, введенные при входе в систему;

2. Пользователь открывает каталог «Справочник цен»;

3. Пользователь просматривает каталог «Справочник цен»;

4. Пользователь обновляет информацию в справочнике.

Рассмотрим сценарий прецедента «Запрос на наличие свободных номеров».

1. Пользователь подтверждает данные, введенные при входе в систему;

2. Пользователь открывает форму запроса «Наличие свободных номеров»;

3. Пользователь нажимает на кнопку «Выполнить запрос»;

4. Пользователь просматривает информацию в форме;

5. Пользователь формирует отчет по запросу, нажав на кнопку «Отчет»;

6. Пользователь выводит информацию на печать;

7. Пользователь закрывает диалоговое окно.

Рассмотрим сценарий прецедента «Запрос на поиск проживающих».

1. Пользователь подтверждает данные, введенные при входе в систему;

2. Пользователь открывает форму запроса «Количество проживающих»;

3. Пользователь нажимает на кнопку «Выполнить запрос»;

4. Пользователь просматривает информацию в форме, показывающую количество проживающих в диалоговом окне;

5. Пользователь закрывает диалоговое окно.

Рассмотрим сценарий прецедента «Запрос на дату выезда и въезда».

1. Пользователь подтверждает данные, введенные при входе в систему;

2. Пользователь открывает форму запроса «Дата выезда и въезда»;

3. Пользователь вводит в форму данные о госте гостиницы;

4. Пользователь просматривает информацию в форме, показывающую дату въезда и выезда гостя из гостиницы;

5. Пользователь закрывает диалоговое окно.

Рассмотрим сценарий прецедента «Регистрация приезжающих».

1. Пользователь подтверждает данные, введенные при входе в систему;

2. Пользователь открывает форму «Регистрация приезжающих»;

3. Пользователь вносит данные в соответствующие поля формы;

4. Пользователь сохраняет данные формы с помощью кнопки «Сохранить»;

5. После нажатия на кнопку данные автоматически фиксируются в соответствующем справочнике.

Последним сценарием приложения будет сценарий «Размещение приезжающих».

1. Пользователь подтверждает данные, введенные при входе в систему;

2. Пользователь открывает форму «Размещение приезжающих»;

3. Пользователь вносит данные о приезжающих в соответствующие поля формы и ставит им в соответствие номер в гостинице;

4. Пользователь сохраняет данные формы с помощью кнопки «Сохранить»;

5. После нажатия на кнопку данные автоматически фиксируются в соответствующем справочнике.

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

2 Развитие постановки задачи

2.1 Спецификация требований к системе

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

1. словесные спецификации на естественном языке;

2. модельные спецификации;

3. формальные спецификации.

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

Поэтому рассмотрим в развитии постановки задачи модельную спецификацию системы.

Опишем объекты, взаимодействующие с системой в виде моделей, как показано на рисунке. Создадим соответствие между объектами и классами проектируемого приложения.

2.2 Определение классов приложения

2.2.1 Определение свойств классов

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

Прецедент «Вход в систему»:

• Предусловие. Пользователь регистрируется в системе, получая имя и пароль.

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

• Постусловие. Пользователь имеет возможность сохранить свои учетные данные или выйти из системы без сохранения.

Прецедент «Просмотр справочника номеров»:

• Предусловие. Пользователь регистрируется в системе, указывая свое имя и пароль, и получает доступ к приложению.

• Описание. На экране отображается каталог со списком номеров. В таблице указывается тип номера, его категория, краткое описание и стоимость. Пользователь может просматривать всю информацию о номерах.

• Постусловие. Пользователь имеет возможность оформить запрос или заполнить форму на заселение или выйти из системы.

Прецедент «Просмотр справочника цен»:

• Описание. На экране отображается каталог со списком цен на номера. В таблице указывается цена в зависимости от даты. Каталог разбит на соответствующие подкаталоги. Пользователь может просматривать всю информацию о ценах в зависимости от сезонности заселения.

• Постусловие. Пользователь имеет возможность оформить запрос или заполнить форму на изменение цены или выйти из системы.

Прецедент «Запрос на наличие свободных номеров»:

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

• Постусловие. Пользователь имеет возможность перейти в форму оформления гостя или распечатать полученные из запроса данные.

Прецедент «Запрос на поиск проживающих»:

• Описание. На экране отображается форма запроса, куда пользователь вводит Имя Фамилию и Отчество гостя.

Прецедент «Запрос на дату выезда и въезда»:

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

• Постусловие. Пользователь имеет возможность распечатать полученные из запроса данные.

Прецедент «Регистрация приезжающих»:

• Описание. На экране отображается форма регистрации. Пользователь вносит в форму регистрационные данные гостя.

Прецедент «Размещение приезжающих»:

• Описание. На экране отображается форма размещения. Пользователь вносит в форму данные гостя и членов его семьи и ставит ему в соответствие требуемый номер.

• Постусловие. Пользователь после нажатия на кнопку «Сохранить» и «Печать» выводит листок размещения.

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

2.2.2 Определение ассоциаций классов

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

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

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

Инкапсуляция, наследование и полиморфизм — три кита, на которых держится ООП.

В любой системе между объектами существуют отношения разных типов.

Отношение зависимости означает, что реализация одного класса зависит от спецификации операций другого класса.

Ассоциация выражает отношение между несколькими равноправными объектами и может иметь направление, роли и кратность, а также изображаться в виде класса ассоциации.

Композиция и агрегация используются, если между объектами существуют отношения типа «часть-целое», причем композиция предполагает, что части не могут существовать отдельно от целого.

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

Теперь рассмотрим схему состояний системы перед последним формированием сценария работы системы и формирования ее интерфейса.

Схема состояний системы показана на рисунке ниже.

2.2.3 Моделирование поведения классов

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

Диаграмма развертывания представлена ниже.

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

Форма входа в систему представлена ниже.

Заключение

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

Итак, подводя итоги, мы можем сформулировать три причины использования прецедентов. Или, вернее, три способа использования прецедентов (не случайно в русском переводе частенько можно встретить словосочетание «вариант использования»!) в ходе работы над системой:

• Прецеденты дают возможность аналитикам, пользователям и разработчикам говорить на одном языке: используя прецеденты, аналитики (эксперты в предметной области) могут на основе пожеланий заказчика описать поведение системы с точки зрения пользователя с такой степенью детализации, что разработчики смогут без труда сконструировать «внутренности» системы. В то же время, нотация диаграмм прецедентов настолько проста, что даже неподготовленный пользователь (заказчик) способен понять их смысл и помочь в их уточнении — ведь картинки (а тем более комиксы, каковыми, по сути, являются диаграммы UML) воспринимаются намного легче, чем текст!

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

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

Список использованных источников

1 Григорьев, В. Н. Высокоуровневые методы информатики и программирования / В. Н. Григорьев. — Саратовский госуниверситет.

2 Кларк, Д. Объектно ориентированное программирование в VisualBasic .NET. Библиотека программиста / Д. Кларк. — СПб.: Питер; 2003. — 352 с.: ил.

3 Буч, Г. Язык UML. Руководство пользователя. 2-е изд. / Г. Буч, Д. Рамбо, И. Якобсон ; пер. с англ. Н. Мухин — М.: ДМК Пресс, 2006. — 496с.: ил.

admin

1812