38574

РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ ПО ОБСЛУЖИВАНИЮ КЛИЕНТОВ СОЛ «РОВЕСНИК»

Дипломная

Информатика, кибернетика и программирование

Язык программирования Object Pscl Среда разработки Delhi 7 СУБД SQL Нормативно-техническая документация Перечень вопросов подлежащих разработке Анализ требований Изучение и анализ предметной области задачи Разработка функциональной модели Как есть Разработка функциональной модели Как надо Обзор существующих решений Разработка технического задания Проектирование системы Построение логической модели БД Построение физической модели БД Разработка проекта системы...

Русский

2013-09-28

2.8 MB

234 чел.

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

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

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

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

Факультет              Электротехнический

Кафедра    Системы информатики

«Допущен к защите»

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

д.т.н., проф. __________ Найханова Л.В.

«__»__________ 2010г.

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

(Дипломный проект)

(Д.635.1.011.05.ПЗ)

на тему:  РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ ПО ОБСЛУЖИВАНИЮ КЛИЕНТОВ СОЛ «РОВЕСНИК»

Исполнитель: студент очной формы обучения группы 635

Будаев Бато Валерьевич___________________________ «__» ______ 2010 г.

Руководитель работы _______ «__»___2010 г. / к.п.н., доцент Е.Г Чимитова./

Консультанты:

- Анализ требований - _______«__»___2010 г. / к.т.н., доцент Н.Н. Аюшеева/

- Проектирование ИС - ______«__»___2010 г. / к.т.н., доцент С.Д. Данилова/

- Реализация проекта - ______ «__»___2010 г. / к.т.н., доцент И.С. Евдокимова/

- ЭОПР - __________________«__»___2010 г. / к.т.н., доцент Н.Н. Аюшеева/

- Документирование - _______«__»___2010 г. / к.т.н., доцент И.С. Евдокимова/

Нормоконтролер    _________ «__»___2010 г. / ассистент Н.В. Андреева/

Рецензент _________________«__»___2010 г. / к.т.н. доцент Бильгаева Л.П.

Улан-Удэ, 2010 г.


Государственное образовательное учреждение

высшего профессионального образования

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

Электротехнический факультет

Кафедра Систем информатики

«Утверждаю»

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

д.т.н., проф. _________ Найханова Л.В.

                         

«09» марта 2010 г.

ЗАДАНИЕ

по подготовке дипломного проекта

Будаева Бато Валерьевича

Тема    ВКР   «Разработка   информационной   системы   по обслуживанию

клиентов СОЛ «Ровесник»

Утверждена приказом по ВСГТУ от «19» января 2010 г.

Срок сдачи законченной работы: «07» июня 2010 г.

Исходные данные к ВКР

  1.  CASE-средства Data Modeler 7.2, Process Modeler 7.2, Rational Rose 7.0     
  1.  Язык программирования Object Pascal
  1.  Среда разработки Delhi 7
  1.  СУБД SQL
  1.  Нормативно-техническая документация

                 

Перечень вопросов, подлежащих разработке

  1.  Анализ требований
  1.  Изучение и анализ предметной области задачи
  1.  Разработка функциональной модели «Как есть»
  1.  Разработка функциональной модели «Как надо»
  1.  Обзор существующих решений
  1.  Разработка технического задания

  1.  Проектирование системы
  1.  Построение логической модели БД
  1.  Построение физической модели БД
  1.  Разработка проекта системы

  1.  Реализация проекта
  1.  Генерация базы данных (реализация)
  1.  Кодирование
  1.  Разработка пользовательского интерфейса
  1.  Отладка и тестирование

  1.  Экономическая оценка принятых решений
  1.  Расчет стоимости разработанного программного продукта по КОМОСТ
  1.  Оценка затрат труда на разработку программной системы  

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

       

Содержание ВКР в виде расчетно-пояснительной записки на 123  листах формата А4 с приложениями на 17 листах формата А4 в количестве 2 экз.

Перечень иллюстрационного материала:

  1.  Демонстрационный ролик ПО
  2.  Презентация доклада в Power Point
  3.  Графические листы

Электронная версия РПЗ, ПО, презентации, демонстрационного ролика на CD-диске в количестве 1 экз.

Дата выдачи задания: «09» марта 2010 г.

Контрольные точки: «26» апреля, «17» мая, предзащита «7» июня                                                                           

Руководитель Чимитова Елена Гендуновна, к.п.н., доцент  

        (фам., иниц., должн., уч.степень)

Задание принял к исполнению «09» марта 2010 г.  _______________                         

                                                                                                             (подпись исполнителя)        


АННОТАЦИЯ

 

БУДАЕВ Б.В.

РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ ПО ОБСЛУЖИВАНИЮ КЛИЕНТОВ СОЛ «РОВЕСНИК»

Выпускная квалификационная работа (дипломный проект). ЭТФ ВСГТУ, 2010, 121 с., 54 рис., 11 табл.,   17 источников,  7 прил., 3 плаката ф. А0.

Данная выпускная квалификационная работа посвящена вопросам  проектирования и разработки информационной системы по обслуживанию клиентов СОЛ «Ровесник».

В рамках данного проекта были выполнены: анализ предметной области, выбор  CASE-средств, построены функциональные модели «Как есть», «Как надо», написано техническое задание на разработку системы, построены концептуальная модель и другие модели UML, логическая и физическая модели базы данных, а также разработано пользовательское приложение.

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

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

_________________________ «    » июня 2010 г.


СОДЕРЖАНИЕ

 


ПРИЛОЖЕНИЕ З ДИАГРАММЫ СОТРУДНИЧЕСТВА 147


ВВЕДЕНИЕ


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

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

Для достижения поставленной цели, необходимо решить следующие задачи:

  •  изучить специфику работы СОЛ «Ровесник»
  •  получить все необходимые сведения и материалы, касающиеся процессов, которые требуется автоматизировать в работе сотрудников выполнить анализ всей полученной информации;
  •  выявить недостатки в процессе обслуживания клиентов
  •  на основе разработанных путей исправления недостатков описать будущую информационную систему и оценить возможность ее реализации;
  •  программно реализовать, протестировать и отладить описанную информационную систему;
  •   экономически оценить принятые решения, рассчитать стоимость реализованного программного продукта;
  •   разработать руководство пользователя и руководство администратора системы.


1. АНАЛИЗ ТРЕБОВАНИЙ


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

  1.   Общая характеристика СОЛ «Ровесник»

История спортивно-оздоровительного лагеря «Ровесник» начиналась в 1965 году. В 5 километрах от села Максимиха был открыт лагерь для студентов, и в 1965 году за 2 сезона там отдохнули 35 человек. В 1968 году был построен спальный корпус на 30 мест, в 1970 году - на 96 мест. В том же 1970 году была построена столовая на 70 мест с летним павильоном на 200 мест.  

Сейчас за семь летних сезонов лагерь «Ровесник» принимает более 500 студентов и преподавателей университета. К услугам всех отдыхающих гостиницы, столовая, библиотека, игровой и танцевальный залы, баня. Именно здесь в самых комфортабельных условиях ежегодно проходят десятки научных конференций самых разных направлений (только летом 2009 г. было проведено 14 научно-практических конференций).

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

К услугам отдыхающих 6 гостиниц на 141 мест, которые сдаются покомнатно или по местам:

  •  две благоустроенные гостиницы по 12 мест (2-х местные): 2-спальная кровать, тумбочки, табуреты, плательный шкаф, холодильник,  душ, туалет.  
  •  две полублагоустроеные  на 14(2-х местные) и 25 мест (12 2-х местных, один 1-местный): 2-спальные или односпальные кровати, тумбочки, стулья, шкаф для белья, туалет.
  •  две неблагоустроенные на 60 мест, 18 мест: односпальные кровати, тумбочки, стулья.

Питание обеспечивается столовой,  рассчитанной на 230 чел, которая делится на 2 зала:

  •  Прием продуктов – прием продуктов выданных со склада.
  •  Производство блюд – приготовление блюд, указанных в меню,  с занесением записи о приготовлении.
  •  Составление меню – составление меню, расчет необходимых продуктов, составление требований для выдачи продуктов на складе.

  1.   Построение функциональной модели “Как есть”

Построение модели “Как есть” осуществляется согласно методологии структурного моделирования SADT, и разработанной на ее основе методологии IDEF0. Данная методология позволяет строить функциональную модель объекта какой-либо предметной области, отображая его функциональную структуру, т.е. производимые им действия и связи между этими действиями.

На  рисунке 1 представлена контекстная диаграмма функциональной модели «Как есть».

Рисунок 1.1 - Контекстная диаграмма «Как есть»

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

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

Управляющие потоки: стандарты приготовления блюд, правила проживания, санитарные нормы, а также нормативно-правовые акты.

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

Исполнительные потоки: шеф повар, директор, администратор, обслуживающий персонал.

Детализация контекстной диаграммы “ Как есть” включает в себя 2 процесса:

- работа гостиницы;  

- работа столовой;

        Рисунок 2 – Детализация контекстной диаграммы «Как есть»

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

                  Рисунок 1.2 – Процесс “Работа гостиниц”

«Работа гостиниц» включает в себя процессы :

- регистрация;

- продление проживания;

- переселение;

- расчет;

- выселение;

Рисунок 1.3 – Процесс “Регистрация”

В процессе «Регистрация» производится занесение данных и срока проживания клиентов в журнал регистрации, выбор номера, составление заявки на питание,  определение стоимости проживания, составление таблицы размещений.

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

                   Рисунок 1.4 – Процесс “Продление проживания”

                                   Рисунок 1.5 – Процесс “Переселение”

Все расчеты с клиентом производятся в процессе «Расчет», который заключается в внесении записи о произведенной оплате в журнал регистрации.

 Рисунок 1.6 – Процесс “Расчет”

В процессе «Выселение» проходит выдача квитанции об оплате клиенту, занесение новой информации в журнал регистрации и таблицу размещений.

 

                                    Рисунок 1.7 – Процесс “Выселение”

Как уже описывалось ранее модель «Как надо» включает в себя процесс «Работа столовой».

В «Работу столовой» входит:

- работа складов;

- работа кухни;

- обслуживание клиентов столовой;

 Рисунок 1.8 – Процесс “Работа столовой”

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

  

              Рисунок 1.9 – Процесс «Работа складов»

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

Рисунок 1.10 – Процесс «Работа кухни»

Обслуживание клиентов столовой состоит из приема блюд с кухни, разноса по столикам.

Рисунок 1.11– Процесс «Обслуживание клиентов»

  1.   Обзор существующих систем

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

Среди зарубежных информационных гостиничных систем наиболее известной является система Fidelio, а также Lodging Touch. К настоящему времени появился и успешно функционирует ряд разработок отечественных фирм, обеспечивающих автоматизацию управления гостиничным комплексом. К ним относятся программные продукты «Эдельвейс», «Реконлайн», «Барсум» (фирма «Рек-Софт»), система Hotel-2000 (фирма «Интур-Софт»), программный комплекс «Русский отель» (Фирма «Сервис плюс» совместно с фирмой «Ист Консепт»), системы «Отель-Симпл», «Меридиан-1» (фирма Nortel), система Kei-Hotel (фирма Kei-Company).

Система автоматизации гостиниц Hotel-2000

Система предназначена для гостиниц с любым числом номеров. Система имеет модульную структуру и состоит из подсистем автоматизации гостиничных функций (Hotel-2000) и автоматизации ресторанов и баров (Restaurant-2000).

Система Hotel-2000 позволяет получить более 100 различных статистических и финансовых отчетов и проанализировать информацию о гостинице. Обеспечивает учет кассовых операций с применением зарегистрированных учетно-кассовых машин.

Эта система функционирует в гостиницах «Академическая», «Союз», «Шереметьево-2» (Москва), «Береста Палас Отель» (Нижний Новгород), бизнес-отелях «ЛУКойл-Москва» (Москва), «Яхонт» (Красноярск), «Сахалин-Саппоро» (Южно-Сахалинск), пансионате «Урал» (Анапа) и др.

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

Автоматизированная система управления гостиницей «Русский отель»

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

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

Автоматизированная информационная система для гостиниц «Отель - Симпл»

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

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

Технические характеристики системы: число корпусов - до 9; суммарное число мест в гостиничном комплексе - до 4000; нумерация комнат - 4-значная; номера телефонов - 7-значные; режим работы – круглосуточный с перерывами на профилактику (30 мин 2 раза в нед.)

Система «Отель-Симпл» внедрена и эксплуатируется в гостиничном комплексе Российской академии государственной службы (РАГС) (два корпуса, 1500 мест) и в гостинице «Академическая» РАН (три корпуса, 900 мест).

Система «Меридиан-1»

Система «Меридиан-1» является специализированным программным продуктом, обеспечивающим автоматизацию выполнения ряда функций по сбору, обработке и хранению информации в системе гостиницы.

Функциональные возможности системы «Меридиан-1»:

1) Система позволяет хранить, обрабатывать и выдавать необходимую информацию, которая включает: данные о состоянии номеров (занят, свободен, забронирован и т.п.); сведения о гостях (ФИО, длительность пребывания гостя в гостинице и т.п.); сведения об уровне обслуживания номеров; предъявление счета за телефонные услуги и др. Эта информация позволяет менеджерам гостиницы оперативно анализировать текущее состояние дел в гостинице и сразу определять те направления, где необходимо улучшить работу.

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

3) Использование дистанционной системы «Компаньон» предоставляет менеджерам возможность не пропустить важный звонок, находясь в любом месте гостиницы. Система «Компаньон» также может быть использована для улучшения внутренней работы, помогая ускорить внутреннюю связь в гостинице и связаться с сотрудником гостиницы, где бы он ни находился.

4) В комплекс дополнительных услуг системы «Меридиан-1» входят: автобудильник; прослушивание номера, если гость оставил там ребенка одного и попросил последить за ним; наличие жидкокристаллического дисплея на телефоне, показывающего время и дату; конференц-звонок — это стандартная функция, применяемая во всем деловом мире, может быть активизирована всеми гостями гостиницы; функция «Не беспокоить» дает возможность гостям направлять звонки, которые приходят на их имя, в их собственный ящик голосовой почты, например, когда они спят, выходят из номера, проводят совещание в своем номере. Время получения ответа на звонок заказчиком может быть сведено к минимуму. В гостинице также может быть установлена «горячая линия» для выбора CRS, чтобы быть уверенным в том, что ни одно бронирование места не пропущено.

Система управления «Эдельвейс»

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

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

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

Пользователями системы в России являются гостиницы «Пулковская», «Юность», «Гранд-отель Европа», бизнес-центр «Нептун» (Санкт-Петербург), «Арктика» (Салехард), «Калининград» (Калининград), «Полярные зори», «Меридиан», «Арктика» (Мурманск) и др. За рубежом имеются более 150 инсталляций (Швейцария, Австрия, Германия, Великобритания, Венгрия, ЮАР, Австралия и пр.).

Система управления «Реконлайн»

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

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

Система «Реконлайн » имеет следующие преимущества:

- обеспечивает одновременное подключение к самым крупным GDS: Sabre, Amadeus, Galileo, Worldspan;

- обрабатывает все типы GDS запросов (телетайпные и on-line);

- сокращает временные затраты на обработку запросов типа «В»;

- допускает различные варианты подключения: интерактивный (по цифровому каналу связи); полуавтоматический (по аналоговому каналу связи); ручной (с использованием факса); предлагает более низкие цены на подключение и эксплуатацию по сравнению с прямым подключением к GDS.

1.4 Актуальность разработки системы.

В таблице 1.1 приведены сравнительные характеристики рассмотренных ИС.

Таблица 1.1 – Сравнительные характеристики рассмотренных ИС.

Критерии оценки

Hotel-2000

«Отель - Симпл»

«Русский отель»

«Меридиан-1»

«Эдельвейс»

«Реконлайн»»

Хранение информации о клиентах.

да

да

да

да

да

да

Хранение сведений о состоянии номеров.

да

да

да

да

да

Да

Проведение расчетов с клиентами и выдача платежных документов;

да

да

да

да

да

да

Ведение учета продуктов на складах

нет

нет

да

нет

нет

нет

Обеспечение работы объектов общественного питания

да

нет

да

нет

нет

нет

Стоимость

стоимость установочного диска – 17000 рублей

стоимость 1 рабочего места – 30000 рублей

стоимость минимально необходимого комплекта рабочих мест – 164000 рублей

базовый комплект -39950 рублей

базовый комплект -90000 рублей

от

130 000

руб.

Таблица 1.1 – Сравнительные характеристики рассмотренных ИС.

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

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

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

  1.  Построение функциональной модели “Как надо”

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

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

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

Контекстная диаграмма  функциональной модели “Как надо” имеет следующий вид, представленный на  рисунке 13.

Рисунок 1.12– Контекстная диаграмма «Как надо»

Детализация контекстной диаграммы «Как надо» представлена на рисунке 14

Рисунок 1.13 – Детализация контекстной диаграммы «Как надо»

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

В процессе «Работа гостиниц» главные изменения состоят в том, что работа со всеми данными осуществляется посредством автоматизированной системы.

Рисунок 1.14– Процесс «Работа гостиниц »

Для примера рассмотрим процесс «Регистрация».

Рисунок 1.15 – Процесс «Регистрация»

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

Рисунок 1.16 - Процесс «Заполнения формы регистрации»

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

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

Рисунок 1.17 – Процесс «Работа столовой»

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

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

На основании проведённого анализа рассматриваемой предметной области составим техническое задание:

1. Введение. 

  1.   Наименование программы

Информационная система обслуживания клиентов Спортивно оздоровительного лагеря «Ровесник» (далее СОЛ «Ровесник»).

  1.  Краткая характеристика области применения

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

2. Основания для разработки

2.1 Основание для проведения разработки

Основанием для проведения разработки является Договор № 603038/09 от 11.01.2010 года  на проведение практики студентов. Договор согласован с директором СОЛ «Ровесник» Оздоноевой Валентины Иргизиновны именуемым в дальнейшем Заказчиком.

  1.  Наименование и условное обозначение темы разработки

Наименование темы разработки – «Разработка информационной системы обслуживания клиентов СОЛ «Ровесник» ».

Условное обозначение темы разработки (шифр темы) – «Ровесник».  

  1.  Назначение разработки  

3.1 Функциональное назначение

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

  1.  Эксплуатационное назначение

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

Конечными пользователями программы должны являться сотрудники

СОЛ «Ровесник».

4.  Требования к программе или программному изделию

4.1 Требования к функциональным характеристикам

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

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

Требования к организации входных данных

Входные данные программы должны быть организованы в виде информации.

Требования к организации выходных данных

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

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

Требования к временным характеристикам программы не предъявляются.

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

Требования к обеспечению надежного (устойчивого) функционирования программы

  1.  организация бесперебойного питания технических средств;
  2.  использование лицензионного программного обеспечения;
  3.  регулярное выполнение требований ГОСТ 51188-98. Защита информации. Испытание пpогpаммных средств на наличие компьютерных вирусов.

4.3 Восстановления после отказа

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

Отказы из-за некорректных действий оператора

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

4.3 Условия эксплуатации

Климатические условия эксплуатации

Программа будет прекрасно работать от плюс 5 до плюс 35 °C при относительной влажности 90% и атмосферном давлении 462 мм.рт.ст., поскольку такие условия приблизительно соответствуют условиям эксплуатации современных компьютеров непромышленного исполнения.

Требования к видам обслуживания

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

Требования к численности и квалификации персонала

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

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

Шеф-повар – пользователь , функции которого заключаются в обеспечении работы столовой, и обслуживание клиентов.

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

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

  •  ПЭВМ с техническими характеристиками не ниже Pentium III, ОЗУ 256 Мб;
  •  MS SQL SERVER 2005
  •  Операционная система Windows (2000/XP);
  •  Свободное место на HDD от 120 Мб и более для самой программы и хранимых данных;
  •  Периферийные устройства, с которыми должна взаимодействовать проектируемая система – принтер;

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

Требования к информационным структурам и методам решения

Требования к информационным структурам (файлов) на входе и выходе, а также к методам решения не предъявляются.

Требования к исходным кодам и языкам программирования

Исходные коды программы должны быть реализованы на языке C++. В качестве интегрированной среды разработки программы должна быть использована среда Borland C++ Buider.

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

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

Требования к защите информации и программ

Требования к защите информации и программ не предъявляются.

4.6 Требования к маркировке и упаковке

Программа поставляется в виде программного изделия - на дистрибутивном (внешнем оптическом) носителе (компакт-диске).

4.7 Требования к транспортированию и хранению

Условия транспортирования и хранения

Допускается транспортирование программного изделия в транспортной таре всеми видами транспорта (в том числе в отапливаемых герметизированных отсеках самолетов без ограничения расстояний). При перевозке в железнодорожных вагонах вид отправки - мелкий малотоннажный.

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

  •  температура окружающего воздуха, °С - от + 5 до + 50;
  •  атмосферное давление, кПа - такое-то;
  •  относительная влажность воздуха при 25 °С - такая-то.

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

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

5.   Требования к программной документации

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

Состав программной документации должен влючать в себя:

  1.  техническое задание;
  2.  руководство системного программиста;
  3.  руководство оператора;

6. Стадии и этапы разработки

6.1 Стадии разработки

Разработка имеет 3 стадии:

  1.  разработка технического задания;
  2.  проектирование;
  3.  внедрение.

6.2 Этапы разработки

На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:

  1.  разработка программы;
  2.  разработка программной документации;
  3.  испытания программы.

7. Порядок контроля и приемки

7.1 Виды испытаний

Приемо-сдаточные испытания должны проводиться на объекте Заказчика после выполнения программы.

Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель документируют в Протоколе проведения испытаний.

7.2 Общие требования к приемке работы

На основании Протокола проведения испытаний Исполнитель, совместно с Заказчиком, подписывают Акт приемки-сдачи программы в эксплуатацию.

8. Приложения

Приложений к техническому заданию нет.


2 ПРОЕКТИРОВАНИЕ СИСТЕМЫ


2.1 Выбор и обоснование способа и средств разработки

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

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

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

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

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

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

  1.  Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования не только программ, но и проектов, что, в конце концов, ведет к созданию среды разработки. Объектно-ориентированные системы часто получаются более компактными, чем их не объектно-ориентированные эквиваленты. А это означает не только уменьшение объема кода программ, но и удешевление проекта за счет использования предыдущих разработок, что дает выигрыш в стоимости и времени.
  2.  Использование объектной модели приводит к построению систем на основе стабильных промежуточных описаний, что упрощает процесс внесения изменений. Это дает системе возможность развиваться постепенно и не приводит к полной ее переработке даже в случае изменений исходных требований.
  3.  Объектная модель уменьшает риск разработки сложных систем, прежде всего потому, что процесс интеграции растягивается на все время разработки, а не превращается в единовременное событие. Объектный подход состоит из ряда хорошо продуманных этапов проектирования, что также уменьшает степень риска и повышает уверенность в правильности принимаемых решений.

В качестве средств проектирования было решено использовать CASE-средства, такие как BPwin, Rational Rose, ERwin, которые позволяют быстро и эффективно разрабатывать информационные системы. Современный CASE-инструментарий обеспечивает полностью интегрированное моделирование бизнес-процессов, физическое моделирование баз данных и объектное моделирование. Важной особенностью CASE-технологий является автоматизированное и полное документирование каждой стадии работы над проектом.

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

CASE – инструмент проектирования модели данных ERwin 4.0 - простое в использовании средство конструирования баз данных, удовлетворяет большинству запросов, которые необходимо будет разрешать в процессе проектирования – от этапа проектирования логической модели до реализации БД в контексте конкретной СУБД.

В CASE-инструментарии ERwin предусмотрена возможность автоматического параллельного проектирования физической  модели БД, а также предусмотрена возможность переключения между диаграммами физической и логической моделей.

ERwin 4.0 является инструментом разработки, способным автоматически создавать таблицы и генерировать большие объемы текста хранимых процедур и триггеров для всех популярных СУБД. В состав ERwin 4.0 включен целый ряд оптимизированных шаблонов триггеров и мощный макроязык, который позволяет создавать собственные триггеры и хранимые процедуры. Таким образом, могут быть автоматически сформированы тысячи строк кода, что обеспечивает непревзойденную продуктивность разработки на основе моделей. ERwin 4.0 поддерживает все наиболее популярные реляционные СУБД, включая Oracle, Microsoft SQL Server, Sybase, DB2 и Informix. Одна и та же модель может быть использована для создания нескольких баз данных или для переноса приложения с платформы одной СУБД на другую.

Для построения объектно-ориентированных моделей программных систем существует специальная нотация – унифицированный язык моделирования (UML). Этот язык позволяет описать программную систему в виде диаграмм, которые в совокупности составляют объектную модель.

В качестве средства, реализующего язык UML, был выбран CASE-инструментарий Rational Rose. Rational Rose – CASE-инструментарий фирмы Rational Software Corporation (США) – предназначенный для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML – Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

Rational Rose имеет ряд преимуществ по сравнению с другими CASE – средствами:

  •  функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX);
  •  поддерживает генерацию кода и обратное проектирование (т.е. построение модели по программному коду) сразу для нескольких языков, включая Visual Basic, C++, Java, PowerBuilder, CORBA Interface Definition Language (IDL), Data Definition Language для большинства СУБД, Erwin модели;
  •  поддерживает визуальное объектно-ориентированное моделирование, полностью совместимое с UML, которой с 1997 года определен как стандарт языка для этой быстро развивающейся области инструментальных средств;
  •  имеет широкие перспективы развития, в том числе за счет появления дополнительных продуктов – «переходников» (Links) тесно интегрированных с Rational Rose и создаваемых многочисленными независимыми разработчиками инструментальных средств в рамках программы Rational Rose Link Partner Program;
  •  охватывает все этапы разработки проекта;
  •  присутствуют средства автоматического контроля, позволяющие вести отладку проекта по мере его разработки;
  •  существует возможность описания проекта на разных уровнях для различных категорий пользователей;
  •  система имеет широкий спектр применения - базы данных, банковские системы, телекоммуникация, системы реального времени, большие информационные системы и т.д.

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

В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие диаграммы: диаграммы прецедентов; диаграммы классов; диаграммы состояний; диаграммы сценариев; диаграммы модулей; диаграммы процессов .

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

2.2 Проектирование логической модели данных

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

Именование объектов логической модели

Очень важно дать объектам модели (сущностям и атрибутам) правильные имена, это заслуживает серьезного внимания. Имена, которые присвоены объектам и атрибутам используются долгое время, поэтому нельзя жертвовать ясностью ради краткости. Сущности и атрибуты должны      быть описательными и отличаться друг от друга, однако достаточно обобщенными, чтобы представить все элементы объекта, должны иметь наименование с четким смысловым значением, именоваться существительными в единственном числе и не носить "технических" наименований.

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

Были учтены такие характеристики как:

–длина имени – она не должна быть слишком длинной, иначе ERwin 4.0  произведет автоматическое усечение, и могут возникнуть ошибки;

– все имена должны быть на русском языке;

–атрибуты, которые являются для других сущностей внешними ключами, должны иметь название с префиксом  “Код” (код преподавателя);

–атрибуты, которые содержат даты, включают в свое имя слово “Дата” (дата поступления).

Атрибуты

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

–трибуты, входящие в первичный ключ (располагаются над чертой внутри сущности);

–атрибуты, не входящие в первичный ключ (располагаются под чертой).

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

Сущности

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

В ERwin 4.0 сущности представляются в виде прямоугольников. Над прямоугольником находится название сущности. Внутри сущности находятся ключевые и неключевые атрибуты, разделенные линией.  Независимая сущность изображается в виде прямоугольника с острыми углами, зависимая – с закругленными углами. Сущность всегда создается независимой.

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

Общие правила построения ключей:

– ключ должен быть уникальным; 

– ключ должен быть достаточным и неизбыточным;

– в состав ключа не могут входить поле некоторых типов, например, графическое и поле комментариев.

Ключ обеспечивает:

–однозначную и идентификацию записей таблицы;

–предотвращение повторения значений ключей;

–ускорение выполнения запросов к БД;

–установление связи между отдельными таблицами БД;

–использование ограничений ссылочной целостности.

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

В результате проектирования было создано 20 сущностей, описание которых приведено ниже в таблице 1.

Таблица 2.1 - Описание логической модели

Название сущности

Описание

11

Спр_Гостиниц

Отражает информацию об гостиницах

22

Спр_Категории_номеров

Отражает информацию о категории номеров

23

Спр_Документов

Отражает информацию о документах клиентов

34

Спр_Складов

Отражает информацию об имеющихся складах

45

Спр_Столиков

Отражает информацию об столиках  столовой

56

Справочник_Ед_измерения

Отражает информацию об единицах измерения продуктов на складе

Продолжение Таблицы 2.1

67

     Клиенты

Отражает информацию о клиентах

98

Заявка_на_питание

Отражает информацию о заявке на питание клиента

19

Приложение_к_заявке

Дополняет информацию заявки на питание

110

Блюдо

Отражает информацию о блюдах

111

Ингридиенты

Отражает информацию о ингредиентах блюд

112

Продукты

Отражает информацию об продуктах на складе

113

Ячейка

Отражает информацию о ячейке в которой находится продукт

114

Запрос_на_полуфабрикат

Отражает информацию о запросах на полуфабрикаты

115

Счет_клиента

Отражает информацию о счете клиента

116

Расчет

Отражает информацию об произведенном расчете

117

Квитанции

Отражает информацию о выданных квитанциях

118

Размещение

Отражает информацию об размещениях клиентов в гостинице

119

Номера

Отражает информацию о номерах гостиниц

220

Отметка

Отражает информацию о отметки состояния номера (занят, свободен)

Конечный результат разработки логической модели БД представлен ниже в приложении В.

Домены

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

В ERwin 4.0 домен может быть определен только один раз и использоваться как в логической, так и в физической модели.

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

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

Связи (отношения)

Связь - это соотношение либо между двумя сущностями, либо между сущностью и этой же сущностью. Связь - “логический” объект, представленный одним или несколькими атрибутами – внешними ключами. Имеются следующие свойства связей в ERwin 4.0: тип связи, родительский конец связи, дочерний конец связи, знак “обязательности” связи и кардинальность связи.

Одна из наиболее мощных возможностей ERwin 4.0 – способность распространять внешние ключи.

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

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

Нормализация

Основная цель проектирования БД - это сокращение избыточности хранимых данных, а следовательно, экономия объема используемой памяти, уменьшение затрат на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте. Так называемый, "чистый" проект базы данных (БД), когда каждый факт находится в одном месте, можно создать, используя методологию нормализации отношений. И хотя по некоторым методологиям проектирования нормализация должна использоваться на завершающей проверочной стадии проектирования БД, было решено для сокращения общего этапа проектирования, использовать ее с самого начала разработки логической модели БД.

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

Каждая таблица в реляционной БД удовлетворяет условию, в соответствии с которым в позиции на пересечении каждой строки и столбца таблицы всегда находится единственное атомарное значение, и никогда не может быть множества таких значений. Любая таблица, удовлетворяющая этому условию, называется нормализованной по 1НФ (нормальной форме). Фактически, ненормализованные таблицы, т.е. таблицы, содержащие повторяющиеся группы, даже не допускаются в реляционной БД.

Теория нормализации основывается на наличии той или иной зависимости между полями таблицы, в ней известны к настоящему времени пять нормальных форм. Во многих источниках, описывающих процесс и результаты нормализации, указывается, что полная нормализованность таблиц в сложных проектах является идеалом. Т.е. ее нужно стремиться достичь, но при этом необходимо учитывать, что чрезмерное увлечение нормализацией может приводить к усложнению логики в обрабатывающих SQL-кодах. Такое не всегда желательно, т.к. оптимизатор кода СУБД будет затруднен в выборе оптимального графика запуска.

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

2.3 Проектирование физической модели данных

После построения логической модели, ее необходимо преобразовать в физическую. Физическая модель зависит от конкретной СУБД и содержит информацию обо всех объектах базы данных. Всем сущностям логической модели соответствуют таблицы в физической модели, а атрибутам сущностей в свою очередь соответствуют поля таблицы. Каждый экземпляр сущности представляется в виде записи в соответствующей таблице.

Именование объектов физической модели

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

Выбор типа данных является важной процедурой. Требуется одновременно учитывать и эффективность хранения и эффективность использования типа данных. Выбранная целевая СУБД также влияет на выбор типа данных для поля, так как каждая СУБД имеет различный набор типов данных. ERwin может преобразовывать типы данных между различными СУБД, однако этот процесс не может гарантировать точности преобразования.

Целостность данных

Целостность данных необходима для поддержки внутреннего логического соответствия данных, хранящихся в базе данных. PostGreSQL может хранить логику в самой базе данных, поддерживая правильность связей и тем самым значительно упрощая поддержку информационной системы. В этом случае необходимость в поддержке правил клиентским приложением существенно уменьшается, так как все правила хранятся вместе с данными и единственная точка контроля целостности находится на сервере. То есть в случае возникновения необходимости разработчику изменить правила, он может это сделать, внеся изменение только в одном месте, - на самом SQL Server.

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

Таблица 2.2 –Таблица сущностей

Имя сущности

Имя атрибута сущности

Ключевое

Имя таблицы

Имя столбца таблицы

Тип данных столбца таблицы

1

2

3

4

5

6

Спр_гостиниц

Код_гостиницы

Да

Sprav_gostinic

Kod_gostinici

int()

№ гостиницы

_gostinici

int()

Код_номера

Kod_nomera

int()

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

Kol_vo_mest

int()

            Справочник категории номеров

Код_категории номеров

Да

Sprav_kategorii_nomerov

Kod_kategorii_nomerov

int()

Категория

Kategoriya

varchar(20)

Справочник документов

Код_документа

Да

Sprav_kategorii_nomerov

Kod_dokumenta

int()

Серия

Seriya

Int()

Номер

Nomer

Int()

Дата_выдачи

Data_vidachi

datetime()

Кем_выдан

Kem_vidan

Int()

Продолжение таблицы 2.2

1

2

3

4

5

6

Справ_складов

Код_склада

Да

Sprav_skladov

Kod_ sklada

int()

Тип_склада

Tip_sklada

varchar(20)

Справ_складов

Код_склада

Да

Sprav_skladov

Kod_sklada

int()

Тип_склада

Tip_sklada

varchar(20)

Справ_столиков

Код_столика

Да

Sprav_stolikov

Kod_stolika

int()

Номер    столиков

Nomer_stolika

int()

Справ_ед_ измерения

Код_ед_измерения

Да

Sprav_ed_izmereniya

Kod_ed_izmereniya

int()

Название_ед_измерения

Nazvanie_ed_izmereniya

varchar(20)

Клиент

Код_клиента

Да

Klient

Kod_ klienta

int()

Фамилия

Familiya

varchar(20)

Имя

Name

varchar(20)

Отчество

Othestvo

varchar(20)

Продолжение таблицы 2.2

Приложение_к_заявке

Код_приложения_к_заявке

Да

Prilogenie_k_zayavke_na_pitanie

Kod_ inspection equipment

int()

Код_заказа

Kod_zakaza

int()

Код_блюда

Kod_bliuda

int()

Кол_во_порций

Kol_vo_porcii

int()

Код_заявки_на питание

Kod_zayavki_na_pitanie

int()

Блюдо

Код_блюда

Да

Bludo

Kod_bliuda

int()

Название_блюда

Nazvanie

varchar(20)

Кол_во_порций

Kol_vo_porcii

varchar(20)

Код_заявки_на_питание

Kod_zayavki_na_pitanie

int()

Ингридиенты

Код_ингридиентов

Да

Ingridienti

Kod_ ingridienta

int()

Вес

        Ves

int()

Название

Nazvanie

varchar(20)

Продукты

Код_продукта

Да

Produkti

Kod_ purchase info

int()

Код_склада

Kod_sklada

int()

Количество

Kolichestvo

int()

Код_запроса

Kod_zaprosa

int()

Код_зоны

Kod_zoni

int()

Название

Nazvnie

varchar(20)

Код_ед_измерения

Kod_ed_izmereniya

int()

Продолжение таблицы 2.2

Ячейка

Код_зоны

Да

iyacheika

Kod_zoni

int()

Адрес_ячейки

Adress_iacheiki

int()

Запрос_на_полуфабрикат

Код_запроса

Да

Zapros_na_polufabrikat

Kod_zaprosa

int()

Код_ингридиента

Kod_ingridienta

int()

Счет_клиента

Код_счета_клиента

Да

Schet_klienta

Kod_zoni

int()

Код_размещения

Kod_razmeshenia

int()

Номер_счета

Nomer_scheta

int()

Состояние_счета

Sostoiyanie_scheta

int()

Код_заявки_на_питание

Kod_zayavki_na_pitanie

int()

Код_размещения

Kod_razmesheniya

  int()

Расчет

Код_расчета

Да

Raschet

Kod_zaprosa

int()

Сумма_расчета

Kod_ingridienta

int()

Дата_расчета

Data_rascheta

int()

Код_счета_клиента

Kod_scheta_klienta

int()

Размещение

Код_размещения

Да

Razmeshenie

Kod_razmesheniya

int()

Дата_размещения

Kod_razmesheniya

datetime()

Код_клиента

Kod_klienta

int()

Срок_проживания

Srok_progivaniya

datetime()

Код_гостини

Kod_gostinici

int()

Продолжение Таблицы 2.2

Номера

Код_номера

Да

Nomera

Kod_nomera

int()

Стоимость

Stoimost

int()

№номера

№nomerA

int()

Код_категории_номера

Kod_kategorii_nomera

int()

Отметки

Код_отметки

Да

Otmetki

Kod_otmetki

int()

Отметка

Otmetka

varchar(20)

2.4 Проектирование системы 

Для создания моделей анализа и проектирования объектно-ориентированных программных систем используют языки визуального моделирования. Разработка визуальных моделей автоматизированного рабочего места инженера по охране труда была выполнена в среде IBM Rational Rose  в нотации языка UML.

2.4.1 Концептуальная модель системы

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

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

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

Разработка диаграммы вариантов использования (use case diagram) преследует цели:

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

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

На диаграмме отражены следующие актеры:

  •  администратор – регистрирует, продлевает проживание, переселяет, выселяет клиентов, производит расчет с клиентами;
  •  шеф повар – производит прием заявок на питание, составляет меню, ведет учет продуктов на складе;

  - директор – получает различные справки (о проживающих в гостинице, о наличии свободных номеров, состояние складов, ).

Рисунок 2.1 - Модель прецедентов.

В представленной модели используются 12 прецедентов, в совокупности, определяющие основные функциональные возможности системы. Для описания деятельности элементов Use Case используются диаграммы деятельности, взаимодействия и последовательности. Опишем основные прецеденты по шаблону.

1 Прецедент –  вход в систему;

 Главное действующее лицо – администратор (администратор, шеф повар, директор);

Внешний контекст - вход в систему администраторов;

Уровень – обобщенный;

Исходные условия - ввод кода доступа;

Минимальный результат - отказ системы в доступе;

Результат успешного завершения - вход в систему;

Триггер - активация кнопки «Вход в систему»;

Основной успешный сценарий:

Шаг1 - система открывает форму авторизации;

Шаг2 - ввод имени пользователя;

Шаг3 - ввод кода доступа;

Шаг4 – проверка кода доступа;

Шаг5 – вход в систему;

Шаг6 – выход;

Расширения:

Шаг4- Отклонение1 - если неверно введен код доступа, то система выводит сообщение о неверно введенном коде доступа;

Шаг5 - Отклонение2 - если пользователь пытается заново ввести код доступа, то выполнять Шаг3, иначе Шаг6;

2  Прецедент –  регистрация клиента;

Главное действующее лицо – администратор;

Внешний контекст - регистрация клиента, т. е. внесение информации о клиенте, предоставление ему номера и выяснение сроков проживания;

Уровень – цель пользователя;

Исходные условия – вход в систему;

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

Результат успешного завершения - клиент зарегистрирован, ему предоставлен номер на удобное время. Вся информация о регистрации сохранена;

Триггер - активация кнопки «Регистрация»;

Основной успешный сценарий:

Шаг1 - открытие формы регистрации;

Шаг2 – ввод даты регистрации;

Шаг3 – ввод данных клиента;

Шаг4 – если  в справочнике клиентов есть клиент с такими данными, то выполнять Шаг5;

Шаг5 – система определяет код клиента;

Шаг6 – система определяет код расчетного счета клиента;

Шаг7 – выбор номера;

Шаг8 – ввод срока проживания клиента;

Шаг9 – система определяет стоимость проживания;

Шаг10 – система вносит изменения в состояние расчетного счета клиента;

Шаг11 – система устанавливает отметку о регистрации;

Шаг12 – система сохраняет результаты регистрации;

Шаг13 – выход;

Расширения:

Шаг4 – Отклонение1 - если клиента с такими данными нет, то выполнять Шаг5;

Шаг5 – система присваивает код клиенту;

Шаг6 – система создает расчетный счет клиента. Переход  к Шагу7;

3 Прецедент –  продление проживания клиента;

Главное действующее лицо – дежурный администратор;

Внешний контекст – продление срока проживания клиента;

Уровень – цель пользователя;

Исходные условия – вход в систему;

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

Результат успешного завершения – срок проживания клиента продлен на нужное время. Все изменения сохранены;

Триггер - активация кнопки «Продление проживания»;

Основной успешный сценарий:

Шаг1 – открытие формы продления проживания;

Шаг2 – ввод даты продления проживания;

Шаг3 – ввод кода размещения клиента;

Шаг4 – ввод срока продления проживания;

Шаг5 – система вносит изменения в состояние расчетного счета клиента;

Шаг6 – система сохраняет изменения;

Шаг7 – выход;

4 Прецедент –  переселение клиента;

Главное действующее лицо – дежурный администратор;

Внешний контекст – переселение клиента в другой номер;

Уровень – цель пользователя;

Исходные условия – вход в систему;

Минимальный результат - клиент переселен в другой номер. Все изменения сохранены;

Результат успешного завершения – клиент переселен в другой номер. Все изменения сохранены;

Триггер - активация кнопки «Переселение»;

Основной успешный сценарий:

Шаг1 - открытие формы переселения;

Шаг2 – ввод даты переселения;

Шаг3 – ввод кода размещения клиента;

Шаг4 – выбор нового номера;

Шаг5 – система вносит изменения в соответствующие справочники;

Шаг6 – система сохраняет изменения;

Шаг7 – выход;

5  Прецедент –  выселение клиента с выдачей квитанций;

Главное действующее лицо – дежурный администратор;

Внешний контекст – выселение клиента с выдачей квитанций о произведенных расчетах;

Уровень – цель пользователя;

Исходные условия – вход в систему;

Минимальный результат – клиент выселен. Все изменения сохранены;

Результат успешного завершения – клиент выселен. Все изменения сохранены;

Триггер - активация кнопки «Выселение»;

Основной успешный сценарий:

Шаг1 – открытие формы выселения;

Шаг2 – ввод даты выселения;

Шаг3 – ввод кода размещения клиента;

Шаг4 – система ставит отметку о выселении клиента;

Шаг5 – система сохраняет изменения;

Шаг6 – система выдает квитанции о произведенных расчетах с клиентом на экран;

Шаг7 – распечатка квитанций;

Шаг8 – выход;

6 Прецедент –  расчет с клиентом;

 Главное действующее лицо – дежурный администратор;

Внешний контекст – расчет с клиентом за проживание в гостинице;

Уровень – цель пользователя;

Исходные условия – вход в систему;

Минимальный результат – расчет с клиентом. Сохранение результатов расчета;   

Результат успешного завершения – расчет с клиентом. Сохранение результатов расчета;

Триггер - активация кнопки «Расчет»;

Основной успешный сценарий:

Шаг1 – открытие формы расчета;

Шаг2 – ввод даты расчета;

Шаг3 – ввод кода счета клиента;

Шаг4 – система формирует квитанцию;

Шаг5 – система выводит квитанцию на экран;

Шаг6 – система сохраняет квитанцию в справочнике квитанций;

Шаг7 – система изменяет состояние счета клиента;

Шаг8 – выход;

7 Прецедент - получение справки;

Главное действующее лицо – директор;

Внешний контекст – получение справки;

Минимальный результат – необходимая справка не получена;

Результат успешного завершения – необходимая справка получена и распечатана;

Триггер – активация кнопки «Получение справки»;

Основной успешный сценарий:

Шаг1 – открытие формы получения справок;

Шаг2 – ввод запроса;

Шаг3 – активация кнопки «Найти»;

Шаг4 – система определяет к какому справочнику относится запрос и там осуществляет поиск;

Шаг5 – если информация по запросу найдена, то выполнять Шаг6;

Шаг6 – система формирует результаты поиска в справку и выдает их на экран;

Шаг7 – если надо распечатать справку, то выполнять Шаг8;

Шаг8 – распечатка справки;

Шаг9 – выход;

Расширения:

Шаг5 - Отклонение1 - если информация по запросу не найдена, то

выполнять Шагу6;

Шаг6 – система выдает на экран сообщение «Поиск не дал результатов». Перейти к Шагу9;  

Шаг7 – Отклонение2 - если справку распечатывать не надо, то выполнять Шаг9;

8 Прецедент – формирование меню;

Главное действующее лицо – шеф повар;

Внешний контекст – формирование меню;

Минимальный результат – формирование меню, сохранение результата;

Результат успешного завершения–формирование меню, сохранение результата;

Триггер – активация кнопки «Создание меню»;

Основной успешный сценарий:

Шаг1 – открытие формы меню;

Шаг2 – ввод блюд;

Шаг3 – ввод количества порций;

Шаг4 – распечатка меню;

Шаг5 – выход;

2.5.2 Диаграммы действий

Для моделирования процесса выполнения операций используются так называемые диаграммы действий (activity diagram).

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

Пример диаграммы действий представлен на рисунке 2.2

Рисунок 2.2 - Диаграмма действий для прецедента «Регистрация пользователя»

2.5.3 Диаграммы последовательности действий

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

Рисунок 2. 3 - Диаграмма последовательности действий для прецедента «Регистрация пользователя»

2.5.4 Диаграммы сотрудничества

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

Диаграмма сотрудничества – это диаграмма взаимодействия, которая выделяет структурную организацию объектов, посылающих и принимающих сообщения. Элементами диаграмм взаимодействия являются участники взаимодействия – объекты, связи, сообщения. Диаграмма сотрудничества представлена на рисунке 2.24. Диаграммы сотрудничества для других прецедентов приведены в приложении И.

Рисунок 2.4 - Диаграмма сотрудничества для прецедента «Регистрация клиента»

2.5.5 Диаграммы классов

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


3 РЕАЛИЗАЦИЯ ПРОЕКТА СИСТЕМЫ


3.1 Реализация базы данных

Для формирования метаданных в файле создаваемой БД на основе модели БД, представленной с помощью ERD, используется процесс прямого проектирования – Forward Engineering.

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

Для создания файла БД необходимо в Enterprise Manager из пакета Microsoft SQL Server создать БД под названием Turbaza

Созданный файл БД необходимо прописать в ODBC-администраторе и используя псевдоним Turbazar в ERWin нужно произвести связь с БД (пункт меню Database −> Database Connection −> SQL Server Connection). После этого можно приступать к Forward Engineering в меню Tools.

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

3.2 Технология первичного заполнения БД

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

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

Имеются следующие справочники:

              - Справочник номеров

              - Справочник гостиниц

              - Справочник рецептов

              - Справочник Ингридинтов

              - Справочник категорий блюд

              - Справочник единиц измерения

              - Справочник складов

3.3 Выбор и обоснование среды разработки

В качестве среды разработки для реализации проекта было решено выбрать Borland Delphi 7.0 – компилирующую визуальную среду разработки прикладных программ Windows.

Язык программирования Delphi происходит от Pascal – языка, разработанного Никласом Виртом специально для обучения структурному программированию. Начиная с версии 5.5, язык стал объектно-ориентированным. В Delphi используется Object Pascal версии 7.0, включающий объектно-ориентированные дополнения, новый расширенный объектный синтаксис.

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

В объектно-ориентированной модели программных компонент основной упор делается на максимальном "переиспользовании" кода. Это позволяет строить приложения весьма быстро из заранее подготовленных объектов, а также дает возможность создавать свои собственные объекты для среды Delphi. Никаких ограничений по типам объектов, не существует. В стандартную поставку Delphi входят основные объекты, которые образуют удачно подобранную иерархию из 270 базовых классов. Но если возникнет необходимость в решении какой-то специфической проблемы на Delphi, есть вероятность, что в списке свободно распространяемых или коммерческих компонент, разработанных третьими фирмами, есть необходимые компоненты.

Среда Delphi включает в себя полный набор визуальных инструментов для скоростной разработки приложений (RAD – rapid application development), поддерживающей разработку пользовательского интерфейса и подключение к корпоративным базам данных. VCL – библиотека визуальных компонент, включает в себя стандартные объекты построения пользовательского интерфейса, объекты управления данными, графические объекты, объекты мультимедиа, диалоги и объекты управления файлами, управление BDE и OLE.

В Delphi визуальные компоненты пишутся на Object Pascal, на нем же пишется алгоритмическая часть приложения. И визуальные компоненты Delphi получаются открытыми для надстройки и переписывания.

Многократно используемые и расширяемые компоненты. Среда устраняет необходимость программировать такие компоненты Windows общего назначения, как метки, пиктограммы и даже диалоговые панели, позволяя при этом экономить программные усилия. Delphi позволяет приспособить эти компоненты к имеющейся задаче, чтобы они работали именно так, как требуется создаваемому приложению. Здесь также используются предварительно определенные визуальные и не визуальные компоненты, включая кнопки, объекты с данными, меню, диалоговые панели и т.д.

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

Палитра компонентов, редактор кода, шаблоны приложений и форм – примеры областей, где Delphi может быть полностью настроена в соответствии с пожеланиями программиста.

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

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

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

3.4  Реализация доступа к БД

Для доступа к MS SQL Server используется объект класса TQuery, который позволяет использовать операторы SQL для того, чтобы определять или создавать наборы данных, которые можно отобразить на экране или обработать в памяти.

Основные свойства компонента TQuery:

  •  Active – указывает, открыт (true) или закрыт (false) данный запрос.
  •  Eof, Bof – эти свойства принимают значение true, когда указатель текущей записи расположен на последней или соответственно первой строке набора данных, являющегося результатом выполнения запроса.
  •  DatabaseName – имя каталога либо псевдоним (alias) удаленной БД, к которой осуществляется запрос.
  •  DataSource – указывает источник данных для параметризованных запросов (т.е. запросов с параметрами, значение которых заранее неизвестно).
  •  Fields – это свойство доступно только во время выполнения (run-time only) и используется для чтения или модификации поля, определяемого по порядковому номеру.
  •  Params – содержит параметры для параметризованного запроса.
  •       SQL – строковый массив, содержащий текст оператора запроса SQL. Отметим, что язык запросов SQL, традиционно применяемый при работе с серверными СУБД, может быть использован и при работе с таблицами формата dBase и Paradox. Не вдаваясь в подробное описание синтаксиса этого языка, отметим одну его особенность: SQL – язык непроцедурный. На нем можно написать, что нужно получить в результате запроса, но нельзя написать, как это сделать, то есть нельзя описать саму процедуру выполнения запроса. Дело в том, что реализация выполнения тех ли иных операторов SQL серверами баз данных может быть различна, и в большинстве случаев неинтересна клиентскому приложению, создаваемому с помощью Delphi. В случае таблиц dBase или Paradox реализацию SQL берет на себя библиотека Borland Database Engine.

Основные методы TQuery:

  •  ExecSQL – выполняет SQL-запрос, содержащийся в свойстве SQL, если запрос не возвращает данные. Следует употребить этот метод при вставке, редактировании или удалении данных. При выполнении же оператора SELECT (выбор данных) следует использовать метод Open.
  •  Open – открывает компонент TQuery. Он эквивалентен присвоению свойству Active значения true. Используется, если результатом запроса является набор данных (такие запросы обычно начинаются с оператора SELECT).
  •  Close – закрывает компонент TQuery. Вызов Close эквивалентен присвоению свойству Active значение false.
  •  Prepare – обеспечивает передачу серверу баз данных запроса, содержащегося в свойстве SQL, для оптимизации и компиляции. Полный запрос с параметрами не передается, пока не вызваны методы Open или ExecSQL. Даже если метод Prepare не вызывается явно, он будет вызван неявно, если используются методы Open или ExecSQL.

3.5 Реализация приложения

На данном этапе жизненного цикла программной системы осуществляется реализация разработанных единиц – классов, функций, модулей, которые в совокупности составляют разрабатываемую систему. Реализация данной программы осуществляется с помощью языка программирования Object Pascal

             .

Рисунок 3.2 – Главное меню

В главном меню, представленном на рисунке 3.2, предлагается выбрать пункт «Работа Гостиниц». При нажатии выводится модуль «Работа Гостиниц» в данном модуле производится добавление, изменение и редактирование сведений о клиентах проживающих в гостиницах. (рис. 3.3).

Рисунок 3.3 – Модуль «Работа Гостиниц»

В пункте меню «Клиенты» (рис. 3.4) редактируется информация о клиентах гостиниц.

Рисунок 3.4 – Меню «Клиенты»

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

При выборе в главном меню пункта «Работа столовой» выводится модуль по обслуживанию столовой.

Рисунок 3.5 – Меню «клиенты»

В данном модуле производится добавление, удаление, и изменение информации о блюдах, напитках, клиентах столовой. Формируется заказ на питание (рис 3.6).

3.6 Тестирование приложения

Обработка ошибок и неправильных действий пользователя — обязательная составляющая любого проекта.

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

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

Пользователь просматривает на экране данные – это результат использования набора данных.

Пользователь решил изменить какие-то данные – он изменит содержимое ячейки набора данных.

При закрытии приложение сохраняет все изменения – это набор данных передается в базу данных для сохранения.

Для проверки обеспечения всех этих функций реализован процесс тестирования.

Процесс тестирования можно разделить на три этапа:

  1.  проверка в нормальных условиях;
  2.  проверка в экстремальных условиях;
  3.  проверка в исключительных ситуациях.

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

Различают две стратегии тестирование программы - тестирование системы на соответствие своей спецификации и тестирование управляемой логикой.

Тестирование системы на соответствие своей спецификации. 

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

Методы тестирования:

  1.  эквивалентное разбиение – это метод тестирования, при котором область входных значений разбивается на пару эквивалентных классов. Предполагается,  что если один тест данного класса обнаруживает ошибку. То и все другие тесты этого класса будут обнаруживать эту ошибку;
  2.  анализ граничных условий – метод, при котором исследуются ситуации, возникающие на и вблизи границ эквивалентного разбиения.
  3.  применение функциональных диаграмм, метод, когда исследуются комбинации входных условий или иначе причинно-следственные связи, он позволяет обнаруживать неполноту и неоднозначность исходных спецификаций;
  4.  предположение об ошибке – метод, основанный на интуиции.

Тестирование, управляемое логикой.

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

Методы тестирования:

  1.  покрытие операторов подразумевает выполнение каждого оператора, хотя бы один раз и чтобы каждой точке входа управление передавалось хотя бы один раз;
  2.  покрытие решений, метод, когда каждое решение должно принять значение истина или ложь и при этом каждый оператор выполнялся бы, по крайней мере, один раз;
  3.  покрытие условий, метод, при котором все возможные результаты каждого условия в решении выполнялись бы, по крайней мере, один раз;
  4.  покрытие решений/условий – это комбинированный метод, когда все возможные результаты каждого условия в решении выполнялись бы, по крайней мере, один раз, все возможные результаты каждого решения в решении выполнялись бы, по  крайней мере, один раз;
  5.  комбинаторное покрытие условий требует, чтобы все возможные комбинации результатов в каждом решении и все точки входа выполнялись, по крайней мере, один раз.

Каждый метод имеет определенные достоинства и недостатки, (возможность обнаруживать и пропускать различные типы ошибок), поэтому необходимо использовать несколько методов.

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

В таблице 3.1 приведены условия и результаты тестирования.

Таблица 3.1 – Результаты тестирования

Условия тестирования

Результаты тестирования

Введены не все данные

Сообщение об отсутствии некоторых данных

Введены все данные

Загрузка данных в БД

В области ввода даты введены данные неправильного формата

Сообщение об ошибке

В области ввода кода введен повторный код

Сообщение о повторяющем коде

Ввод поиска несуществующей записи

Сообщение о том, что ни одной записи не найдено

Ввод поиска существующей записи

Вывод данных по поиску

Попытка создания новой записи в БД

Создание новой записи

Попытка редактирования записи в БД

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

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

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

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

Таблица 3.2 – Результаты контроля надежности

Отказовая ситуация

Метод устранения отказа

Нехарактерная длительность загрузки

Анализ в диаграммах Rational Rose и устранение несогласованности работ классов (устранение тупиков)

Потеря несохраненной информации при нештатной ситуации (отключения электроэнергии)

Ввод данных

Потеря несохраненной информации при нештатной ситуации (потеря связи в сети)

Оперативный контроль, форсированный метод испытаний

Потеря несохраненной информации при нештатной ситуации (занесение вируса)

Создание RAID массива и архивной копии на CD дисках

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

Оценим сложность информационной системы (таблица 3.3).

Таблица 3.3 – Сложность программного изделия

Показатель сложности

Единица измерения

Значение характеристики

Заключение

Длина информационной системы

операторы

36 624

Средний

Количество модулей

шт.

6

Средний

Количество переменных

типов

1

Средний

Допустимое время отклика

сек.

10

Средний

Трудоемкость создания

чел./год

0,5

Средний

Длительность разработки

год

0,5

Средний

Количество разрабатывающих специалистов

чел.

1

Средний

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

3.7 Разработка пользовательского интерфейса с учетом эргономических  требований

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

Хорошо разработанный интерфейс гарантирует удобство работы с приложением и, в конечном итоге, его коммерческий успех.

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

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

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

  •  Стандартизация. Рекомендуется использовать стандартные, проверенные многими программистами и пользователями интерфейсные решения. Для Delphi это, разумеется, решения Microsoft. Причем в качестве стандарта может служить любое из приложений — Word, Excel или другие приложения Microsoft. Под решениями подразумеваются дизайн форм, распределение элементов управления в формах, их взаимное расположение, значки на кнопках управления, названия команд меню.
  •  Удобство и простота работы. Интерфейс должен быть интуитивно понятным. Желательно, чтобы все действия легко запоминались и не требовали утомительных процедур: выполнения дополнительных команд, лишних нажатий на кнопки, вызова промежуточных диалоговых окон.
  •  Внешний дизайн. Нельзя, чтобы интерфейс утомлял зрение. Он должен быть рассчитан на длительную работу пользователя с приложением в течение дня.
  •  Неперегруженность форм. Формы должны быть оптимально загружены элементами управления. При необходимости можно использовать вкладки или дополнительные страницы форм.
  •  Группировка. Элементы управления в форме необходимо группировать по смыслу, используя элементы группировки: рамки, фреймы.
  •  Разреженность объектов форм. Элементы управления следует располагать на некотором расстоянии для выделения элементов управления можно организовать пустые пространства в форме.

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

В настоящее время для приложений, разрабатываемых в среде Windows при помощи Delphi 7, используется три типа интерфейса: однодокументный  SDl (Single-Document Interface), многодокументный MDI (Multiple-Document Interface) и интерфейс типа проводник (Explorer).

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

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

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

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

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

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

В состав интерфейса MDI входят следующие элементы:

  •  главное меню;
  •  панель инструментов с элементами управления;
  •  главное окно приложения (MDI-окно);
  •  дочерние окна;
  •  элементы управления для работы с данными, расположенные в дочерних окнах;
  •  строка состояния.

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

При проектировании меню следует руководствоваться определенными принципами. Главный из них — стандарты. Рекомендуется придерживаться стандартных названий команд меню и их расположения.

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

В данной информационной системе соблюдались эти принципы.

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

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

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

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

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


4 ЭКОНОМИЧЕСКАЯ ОЦЕНКА ПРИНЯТЫХ РЕШЕНИЙ

 


4.1 Оценка затрат труда на разработку программной системы

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

В КОМОСТ ЧМ состоит из 152 часов рабочего времени, месяц из 19 дней, год из 12 месяцев.

В КОМОСТ, как правило не используются денежные оценки затрат, т.к. издержки на оплату исполнителей могут быть разными. Оценивание выполняется в ЧМ, так как данный показатель является более постоянной величиной.

4.2 Затраты труда и сроки разработки

В КОМОСТ рассматриваются три типа ПО: распространенный, встроенный и полунезависимый.

К распространенному типу разработки относят создание программ, пакетов и ПС, ориентированных на решение разнообразных задач науки и производства (типовые задачи).

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

      Полунезависимый тип - это промежуточный тип разработки, который обладает чертами распространенного и встроенного типов.

Точность определения затрат труда и сроков разработки, с помощью базовой КОМОСТ достаточна только на этапе приблизительного предварительного исследования ПИ. Промежуточная КОМОСТ позволяет достичь большей точности, поэтому было принято решение: затраты труда и сроки разработки проводить с помощью промежуточной КОМОСТ.

Промежуточная КОМОСТ

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

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

В промежуточной КОМОСТ оценивание затрат труда на программную разработку выполняется в два этапа:

  1.  определяются номинальные затраты по таблице 4.1;
  2.  полученные значения корректируются путем умножения на коэффициенты затрат труда, соответствующие стоимости атрибутам.

Таблица 4.1 – Уравнения номинальных значений затрат труда

№п/п

Тип разработки

Затраты труда

Сроки разработки

1

2

3

Распространенный

Полунезависимый

Встроенный

ЧМном = 3,2 * КЧИК1.05

ЧМном = 3,0 * КЧИК1.12

ЧМном = 2,8 * КЧИК1.20

СР = 2,5 * ЧМ0.38

СР = 2,5 * ЧМ0.35

СР = 2,5 * ЧМ0.32

Определим тип разработки:

В данном проекте определены следующие характеристики:

  1.  необходимость соответствия программного обеспечения требованиям – относительный, так как при разработке учитывались только требования заказчика;
  2.  необходимость соответствия спецификациям внешнего интерфейса – относительный, так как учитывались пожелания заказчика и требования эргономики;
  3.  параллельная разработка новых ТО и вычислительных процессов – незначительный, так как при разработке и реализации проекта не производилась дополнительная разработка новых ТО и ВП;
  4.  необходимость новых системных алгоритмических решений – минимальный, так как при разработке и реализации проекта необходимость в каких-либо новых решениях для реализации не требовалась, т.е. использовались стандартные методы решения поставленной задачи.

Все приведенные показатели соответствуют распределенному типу разработки, которые свидетельствуют, что мы имеем именно такой тип, следовательно, уравнение затрат труда будет:  

                               ЧМ ном = 3,2 * КЧИК 1.05                                             (4.1)

где  ЧМ ном – номинальные затраты человеко-месяцев на разработку       программы;

КЧИК – число исходных команд программной системы, в килокомандах.

ЧИК нашей программной системы составляет около 3340 команд.  

Следовательно, ЧМ ном  = 11,35 человеко-месяцев.

Для определения стоимостных атрибутов в промежуточной КОМОСТ имеются 15 входных параметров:

1) Требуемая надежность ПО – номинальный (1,0), сбой программного обеспечения приводит к умеренным, восполняемым потерям, для их ликвидации требуются усилия;

2) Размер БД – высокий (1,08), т.к. размер базы данных составляет 5,5 Mb, а ЧИК=2500, то, рассчитав по формуле РБД/ЧИК, получаем 110 – это число входит в предел 100<n<1000, относящийся к рейтингу – высокий;

3) Сложность изделия – номинальный (1,0), определяется следующими атрибутами:

  •  управление выполнением – простая вложенность;
    •  вычисления – использование стандартных операций;
    •  управление устройствами – ввод-вывод с выбором устройств;
    •  управление данными – ввод из нескольких файлов и вывод в один файл;

4) Ограничение по быстродействию – номинальный (1,0), так как при работе с программным обеспечением не требуется очень высокого быстродействия;

5) Ограничения по памяти – номинальный (1,0), при работе программы не выполняются какие-либо  операции, требующие большого количества оперативной памяти;

6) Изменяемость виртуальной машины – низкий (0,80), так как обновления ТО ЭВМ и операционной системы производится, не будут;

7) Цикл обращения к ЭВМ – низкий (0,87), основывается на работе пользователя с программой в диалоговом режиме, т.е. пользователь не ждет длительного времени, пока выполнится та или иная операция, исключение составляет только работа с запросами и поиск данных, время выполнения которых зависит от полноты БД и сложности запроса или поиска;

8) Квалификация    аналитика     –    номинальный  (1,0),   определяется совокупностью следующих критериев:

  •   способность к анализу – номинальный (1,0);
  •   эффективность и тщательность выполнения работы – номинальный (1,0);
  •  способность к общению и сотрудничеству – номинальный (1,0);

9) Опыт работы в данной прикладной области – номинальный (1,0);

10) Квалификация программиста – номинальный (1,0), определяется совокупностью следующих критериев:

  •  способность к программированию – номинальный (1,0);
  •  эффективность и тщательность выполнения работы – номинальный (1,0);
  •  способность к общению и сотрудничеству – номинальный (1,0);

11) Опыт работы с виртуальной машиной – номинальный (1,0), определяется опытом работы;

12) Опыт работы с языком программирования  - номинальный (1,0);

13) Применение современного программирования – высокий (0,91), определяется использованием современной среды программирования;

14) Использование инструментальных средств – высокий (0,91), определятся использованием при разработке и реализации ОС с виртуальной памятью (MS Windows), средством проектирования БД (ERwin, Rational Rose), средством реализации (Borland Delphi);

15) Ограничение сроков работы – номинальный (1,0), определяется уравнением промежуточной КОМОСТ.

Оценки стоимостных атрибутов системы приведены в таблице 4.2.

Таблица 4.2 – Оценка стоимости атрибутов программного проекта

Вид атрибута

Оценка

Изделия:

ТНПО (требуемая надежность ПО)

Номинальный 1,0

РБД (размер базы данных)

Высокий 1,08

СИЗ (сложность изделия)

Номинальный 1,0

ЭВМ:

ОБД (ограничение по быстродействию)

Номинальный 1,0

ОП (ограничения по оперативной памяти)

Номинальный 1,0

ИВМ (изменяемость виртуальной машины)

Низкий 0,80

ЦО (цикл обращения к ЭВМ)

Низкий 0,87

Исполнителей:

КА (классификация аналитика)

Номинальный 1,0

ОРП (опыт работы в данной прикладной области)

Номинальный 1,0

КП (классификация программиста)

Номинальный 1,0

ОРВМ (опыт работы с виртуальной машиной)

Номинальный 1,0

ОРЯП (опыт работы с языком программирования)

Номинальный 1,0

Проекта:

ПСП (применение современного

программирования)

Высокий 0,91

ИИС (использование инструментальных средств)

Высокий 0,91

ОСР (ограничение сроков разработки)

Номинальный 1,0

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

Коэффициент К, получившийся в результате перемножения всех оценок стоимостных факторов, равен 0,35.

Затраты труда на  разработку программной системы равны 11,35*0,35=3,9 человеко-месяцев.  

СР = 2,5 * ЧМ0.38      (4.2)

Cрок разработки равен СР = 2,5 * ЧМ0.38 =4,19 месяцев.                                           ЧИ =3,9 /4,19 1 чел.

4.3 Расчет стоимости разработки

В расчет стоимости разработки программного комплекса входит зарплата, выплачиваемая программисту за период работы и срок разработки (СР) программного изделия. Предположим, что зарплата программиста составляет 15000 рублей/человеко-месяц. Таким образом, оплата за все время разработки, которую мог бы получить программист, составит 15000*4,19*1= 6285 рублей.

Также в стоимость программного продукта необходимо включить стоимость используемых программных продуктов (по данным сайта www.itshop.ru):

  •  Rational Rose (лицензия на 1 год) – 127836 рублей;
  •  AllFusion Erwin Data Modeler (лицензия на 1 год) – 25392 рублей;
  •  AllFusion Process Modeler (лицензия на 1 год) – 17129 рублей;
  •  Delphi 7(лицензия на 1 год) -34 640 рублей;
  •  Microsoft SQL Server 2005 (лицензия на 1 год) - 1 175 рублей.

Общая стоимость разработки, таким образом, составит:

 6285+ 206172 = 260157 рублей.

4.4 Расчет цены программы

Цена программы рассчитывается по формуле:

                                Ц=С/Р                                                                                 (4.3)

где       Ц - цена программы;

С - стоимость программы;

Р - количество единиц рынка сбыта.

Количество единиц рынка сбыта равно 16.

В результате получаем цену программы 8233 рублей.


5 ДОКУМЕНТИРОВАНИЕ


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

Характеристика программы

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

Программа представляет собой windows-приложение, работающее с базой данных под управлением СУБД MS SQL Server. В базе данных храниться вся необходимая для автоматизации деятельности комплекса информация. Имеется возможность  отчетов и экспорт в  Excel.

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

  •  Intel Pentium III MHz ;
  •  32 MB RAM (128 Mb рекомендовано);
  •  Свободное место на HDD от 100 Мб и более для самой программы и   хранимых данных.

Периферийные устройства:

  •  Принтер для выведения отчетов на печать;
  •  Мышь;
  •  Клавиатура.

Требуемое программное обеспечение:

  •  Операционная система:
  •  Microsoft Windows XP/2000;
  •  Microsoft SQL Server 2005;
  •  Microsoft Office 2000/2003.

5.1.2. Выполнение программы

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

Для запуска приложения  необходимо запустить файл Turbaz.exe». После запуска приложения появится диалоговое окно выбора модуля.

Рисунок 5.1 - Главное окно

  При выборе модуля «Работа Гостиниц» выводится форма «Гостиницы».

Рисунок 5.2 – Модуль «Работа Гостиниц»

Работа с клиентами.

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

Для добавления нового необходимо на главной форме программы выбрать вкладку «Клиенты». (рис.5.3)

Рисунок 5.3 – Добавление клиента

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

Рисунок 5.4 – Сведения о размещении клиента

Работа со справочниками гостиниц (номера, категории номеров, корпуса гостиниц ) осуществляется во вкладках «номер» (рисунок 5.5), «тип номера» (рисунок 5.6), «корпуса» (рисунок 5.7) соответственно.

Рисунок 5.5 Вкладка «Номер»

Рисунок 5.6 Вкладка «Тип номера»

Рисунок 5.7 Вкладка «Корпус»

Работа столовой.

При выборе в главном окне пункта «Работа Столовой» выводится модуль обслуживания столовой (рисунок 5.8).

Рисунок 5.8 - Модуль «Обслуживание столовой»

При нажатии на вкладку клиенты (как показано выше) выводится информация о клиентах.

Редактирование справочников виды блюд, вид напитка, напитки, блюда осуществляется в соответствующих вкладках (рисунки 5.9, 5.10, 5.11, 5.12).

Рисунок 5.9-  Вкладка «Вид блюд»

Рисунок 5.10 -  Вкладка «Вид напитка»

Рисунок 5.11 -  Вкладка «Напитки»

Рисунок 5.12 -  Вкладка «Блюда»

Формирование заказа на питание и печать заказа осуществляется в вкладке «Заказ».

Рисунок 5.13 -  Вкладка «Заказ»

При нажатии на клавишу «Печать заказа» производитя формирование заказа и вывод его на печать

Рисунок 5.14 - Печать заказа

5.2 Руководство администратора базы данных

5.2.1 Внешние настройки

В данной работе в качестве целевого сервера БД (target server) была использована MS SQL SERVER.

Для того чтобы приложение через сеть могло обращаться к БД, необходимо подключится к серверу, где находится база «Turbaza», если на данном компьютере отсутствует база «Turbaza», то для этого требуется:

  1.  выбрать в дереве программы SQL Server «Базы Данных», и нажать правой кнопкой мыши, появится контекстное меню, где необходимо выбрать «Присоединить», как показано на рис 5.15.

Рисунок 5.15 - Настройка БД

  1.  в появившемся окне нажать на кнопку «Добавить», где необходимо выбрать путь к базе данных (рис 5.15).

Рисунок. 5.16 - Путь к БД.

3) Нажать «ОК»

5.2.2 Резервное копирование базы данных

База данных, с которой ведется работа из приложения «Ровесник» представляет собой один файл Tubaza.mdf, в котором храниться вся информация о структуре таблиц, типах данных и так далее (метаданные), а также сами данные.

Резервное копирование – backup – заключается в создании копии базы данных с текущим содержимым. Эта копия представляет собой упакованный файл БД, сохраненный в так называемом «транспортабельном» формате, т.е. его можно будет восстановить на любой системе, поддерживающей работу с MS SQL Server.

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

Порядок создания резервной копии.

1)Запустить программу SQL Server

2)Открыть окно создания резервной копии (рис. 5.16) (нажать правой мыши на базу данных «Turbaza» и выбрать пункт меню «ЗадачиСоздать резервную копию»)

Рисунок 5.17-  Резервное копирование базы данных

  1.  В открывшимся диалоговом окне «Резервное копирование базы данных» нужно ввести имя резервного набора и описание, выбрать опцию Типа резервной копии – Полная, для создания полной резервной копии и указать в списке Назначение устройство резервного копирования. Кнопки «Добавить» и «Удалить» позволяют создать новое устройство или удалить существующее. Если вы не знаете, что храниться на выбранном вами устройстве, щелкните на кнопке Содержимое и посмотрите его содержимое. По желанию можно  во вкладке Параметры установить параметры «Переписать носитель» и «Надежность».

2 . Нажать «Ок»

Восстановление БД.

При восстановлении БД выбрать пункт меню ЗадачиВосстановитьБаза Данных (рис. 5.17).

Рисунок 5.18 -  Восстановление базы данных


ЗАКЛЮЧЕНИЕ


Разработанная автоматизированная информационная система предназначена для автоматизации обслуживания клиентов СОЛ «Ровесник»

В процессе работы были получены следующие результаты:

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

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


СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ


1

Бутаков Е.А. Методы создания качественного программного обеспечения ЭВМ. – М.: Энергоатомиздат, 1984. – 232 с.

2

Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. – М.: Финансы и статистика, 1998. - 320 с.

3

Гультяев А.К., Машин В.А. Проектирование и дизайн пользовательского интерфейса. – СПб.: КОРОНА принт, 2000. – 352 с.

5

Кантор М. Управление программными проектами. Практическое руководство по разработке успешного программного обеспечения.: пер. с англ. – М.: Вильямс, 2002. – 176 с.

6

Кватрани Т. Визуальное моделирование Rational Rose 2000 и UML. – [б.м.]: ДМК, 2001. – 176 с.

7

Маклаков Ю.В. BPWin, ERWin. CASE-инструментарий разработчика ПО. - М.: Диалог-Мифи,  1999. - 256 с.

8

Материалы сайта компании «Interface Ltd» [Электронный ресурс]. – режим доступа: www. Interface Ltd.com.

9

Материалы сайта Центра информационных технологий [Электронный ресурс]. –  режим доступа: www.citforum.ru.

     10

Материалы FAQ по Delphi, Interbase, BDE [Электронный ресурс]. – www.delphisources.ru

11

Найханова Л. В., Чимитова Е. Г. Технология разработки программного обеспечения: курс лекций. – Улан-Удэ: ВСГТУ, 2005. – 277 с.

     12

Найханова Л.В., Тулохонова И.С., Янсанова Е. Н. ВКР. Общие требования к структуре расчетно-пояснительной записки и правила ее оформления. - Улан-Удэ: ВСГТУ.  2007. – 81. с.

     13

Найханова Л.В., Евдокимова И.С. Методы и алгоритмы трансляции естественно-языковых запросов к базе данных в SQL-запросы: Монография. Улан-Удэ: ВСГТУ, 2004. 148 с.

14

Райордан Р. Основы реляционных баз данных. – М.: Русская Редакция, 2001. – 384 с.

15

Фаронов В.В., Шумаков П.В. Руководство разработчика баз данных. – М.: «Нолидж», 1999. – 560 с.

16

Фаулер Мартин, Скотт Кендал. UML. Краткое руководство. – СПб: Символ – Плюс, 2002. – 192 с.

17

Фокс Дж. Программное обеспечение и его разработка. – М.: Мир, 1985.- 184


ПРИЛОЖЕНИЕ А

ФУНКЦИОНАЛЬНАЯ МОДЕЛЬ «КАК ЕСТЬ»

Рисунок A.1

Рисунок A.2

Рисунок А.3

Рисунок А.4

Рисунок А.5

Рисунок  А.6

Рисунок А.7

Рисунок А.8

Рисунок А.9

Рисунок А.10

Рисунок А.11

Рисунок А.12


ПРИЛОЖЕНИЕ Б

ФУНКЦИОНАЛЬНАЯ МОДЕЛЬ «КАК НАДО»

Рисунок  Б.1

Рисунок Б.2

Рисунок Б.3

Рисунок Б.4

Рисунок Б.5

Рисунок Б.6


ПРИЛОЖЕНИЕ В

ЛОГИЧЕСКАЯ МОДЕЛЬ ДАННЫХ

 

Рисунок В.1

ПРИЛОЖЕНИЕ Г

ФИЗИЧЕСКАЯ МОДЕЛЬ ДАННЫХ

Рисунок Г.1


ПРИЛОЖЕНИЕ Д

 МОДЕЛЬ ПРЕЦЕДЕНТОВ

Рисунок Д.1

ПРИЛОЖЕНИЕ Е

ДИАГРАММЫ ДЕЙСТВИЙ

Рисунок Е.1

Рисунок Е.2

Рисунок Е.3

Рисунок Е.4

Рисунок Е.5

Рисунок Е.6


ПРИЛОЖЕНИЕ Ж

ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ ДЕЙСТВИЙ

Рисунок Ж.1

Рисунок Ж.2

Рисунок Ж.3

ПРИЛОЖЕНИЕ З

ДИАГРАММЫ СОТРУДНИЧЕСТВА

Рисунок З.1

Рисунок З.2

Рисунок З.3

Рисунок З.4


 

А также другие работы, которые могут Вас заинтересовать

32228. Составление плана расследования. Основные и вспомогательные формы планов 35 KB
  Составление плана расследования. Это приводит к необходимости планирования расследования различных дел во времени подготовка документов отчётов и т. 2 План расследования по конкретному преступлению. Составляется план расследования по версиям.
32229. Каноническое представление уравнения Эйлера 137.5 KB
  Например требуется определить закон изменения якорного тока и скорости вращения двигателя постоянного тока который поворачивает платформу экскаватора. Динамика двигателя описывается уравнением равновесия моментов – момент развиваемый двигателем уравновешивается динамическим моментом и моментом сопротивления: п.1 где Мдв=Смi – момент развиваемый двигателем См – постоянная двигателя i – якорный ток J – момент инерции приведенный к валу двигателя скорость вращения...
32230. Синтез оптимального управления при ограничениях на управляющее воздействие 163 KB
  Более эффективно решение задач синтеза оптимального управления при ограничениях управляющих воздействий осуществляется путем использования принципа максимума предложенного в 1956 году академиком Л. Принцип максимума является дальнейшим развитием вариационного исчисления. Это условие положено в основу принципа максимума. Рассмотрим применение принципа максимума Понтрягина для решения задач оптимизации.
32231. Метод динамического программирования Р. Беллмана 1.14 MB
  6 величина определяется в соответствии с уравнениями 7.10 При условиях ; Оптимальное уравнение определяется в результате решения уравнения 7.10 можно заменить уравнениями в частных производных 7.4 получим Из уравнения получим П 7.
32232. Связь между принципами максимумами и динамическим программированием 359.5 KB
  17 является скалярным произведением векторов Ψ и X: Н = ψ 8. Вектор касателен к траектории t и нормален к векторам ψ и –ψ что определяет оптимальный процесс перехода из в . Максимальное быстрое уменьшение J будет происходить очевидно что если вектор скорости Хточка в направлении убывании убывание J будет максимальным. Для обеспечения этого необходимо чтобы проекция вектора скорости движения изображающей точки Хточка на вектор отрицательной нормалям к поверхности J...
32233. Синтез оптимального по быстродействию программного управления 211 KB
  3 Где уравнение динамики объекта управления Поскольку то максимум функции Н реализуется одновременно с максимумом функции: 9. Решим задачу определения оптимального по быстродействию программного управления на примере объекта второго порядка: .1 То структурная схема объекта представлена на рис. Структурная схема объекта управления В соответствии со структурной схемой на рис.
32234. Синтез замкнутых систем управления, оптимальных по быстродействию 147 KB
  невозможно путём интегрирования уравнений объекта найти уравнения траекторий в nмерном пространстве.6 в этом случае можно представить относительно других координат: где i = 12n Тогда уравнения проекций фазовых траекторий на координатные плоскости при U = const будут иметь вид: Интегрируя это выражение получим: где ; координаты точек через которые проходит проекция 10.2 С помощью уравнений проекций фазовых траекторий определяем координаты точек переключений U.6 получим выражение...
32235. Аналитическое конструирование регуляторов (АКОР) 137.5 KB
  он ограничивает и отклонение переменных состояния объекта управления и управляющего воздействие данная задача определения оптимального регулятора получила широкое распространение. Задана динамика объекта управления: ; 1 или 1 где А=[nn] коэффициентная матрица динамики объекта B=[nm] – матрица коэффициентов управляющих воздействий xiн=xi0 xiк=xitк – граничные условия. Критерий...
32236. Системы, оптимальные по расходу ресурсов 199 KB
  Все они имеют ограничения по величине управляющего воздействия что довольно очевидно.4 В качестве критерия выберем интегральный критерий обеспечивающий одновременно ограничение переходного процесса по времени и по расходу управляющего воздействия п1.16 Системы из исходного состояния х10х20 в начале координат х1к=0х2к=0 должно производится следующим путем изминения управляющего воздействия: п1.17 Следовательно необходимо найти...