Разработка сайта для ресторана «МАО»

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

" Оренбургский государственный университет"

Индустриально-педагогический колледж Отделение автоматизации информационных и технологических процессов

Курсовой проект

по дисциплине " Разработка и эксплуатация автоматизированной информационной системы "

Разработка сайта для ресторана " МАО"

ИПК ОГУ 230 103.51.4014.23 КП Руководитель работы О. В. Саликова Исполнитель студент группы АСУ-10

А.И. Рубинштейн Оренбург 2014

• Введение
• 1. Аналитическая часть
• 1.1 Описание объекта автоматизации
• 1.2 Обоснование необходимости автоматизации
• 1.3 Анализ аналогов подобных программных систем
• 1.4 Постановка задачи
• 1.5 Описание структуры разрабатываемого АРМ
• 1.6 Обзор обоснования выбора инструментальных средств
• 1.7 Обзор обоснования методов защиты данных
• 2. Проектная часть
• 2.1 Анализ предметной области
• 2.1.1 Иерархия функций
• 2.1.2 Формализованное описание предметной области
• 2.2 Концептуальный уровень базы данных
• 2.2.1 Модель «объект — отношение»
• 2.2.2 Даталогическая модель БД
• 2.2.3 Анализ схем отношений на соответствие нормальной формы Бойса — Кодда
• 2.3 Физическая модель БД на основе выбранной СУБД
• 2.3.1 Описание проектируемых объектов БД
• 2.3.2 Технология создания базы данных
• 2.3.3 Реализация ограничения целостности базы данных
• 2.4 Проектирование интерфейса АРМ
• 2.4.1 Требования к пользовательскому интерфейсу
• 2.4.2 Создание справочной системы
• 2.5 Инсталляция АИС
• 2.6 Руководство пользователя
• Заключение
• Список использованных источников
• Приложения

Достаточно актуальной в наше время становится реклама в системе Интернет, число пользователей которого постоянно увеличивается. По моим оценкам правильно организованный и хорошо сайт способен давать до 20−25% посетителей. Мощное и раскрученное недорогое по сравнению с другими средствами СМИ средство продвижения ресторана. Возможность оперативного размещения новой либо корректировки уже имеющейся информации. Наличие обратной связи со своими клиентами, позволяющей проводить опросы о качестве обслуживания ресторана, его достоинствах и недостатках, пожеланиях и предложениях посетителей. Прежде всего, надо отметить, что сайт ресторана — это второе «я» заведения. Будучи безмолвным помощником, он, в то же время, красноречиво

Тема данного курсового проекта: Разработка сайта для ресторана «МАО»

Цель проекта: Создания сайта для ресторана «МАО»

Задачи:

обеспечение удобного и эффективного интерфейса пользователя;

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

обеспечение удобного просмотра меню ресторана;

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

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

обеспечение удобного и эффективного интерфейса служащих;

1. Аналитическая часть

1.1 Описание объекта автоматизации

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

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

1.2 Обоснование необходимости автоматизации

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

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

1.3 Анализ аналогов подобных программных систем

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

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

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

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

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

физическое размещение в памяти данных;

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

организация понятного и простого в управлении пользовательского интерфейса;

организация банка данных, для дальнейшего использования;

обеспечение более удобного доступа к данным путем гибкого поиска;

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

1.5 Описание структуры разрабатываемого АРМ

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

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

1.6 Обзор обоснования выбора инструментальных средств

Для разработки приложения было выбрано следующее ПО: СУБД (система управления базами данных) MS Access и система программирования Delphi.

База данных — это совокупность записей различного типа, содержащая перекрестные ссылки.

СУБД - это комплекс языковых и программных средств, предназначенный для создания, ведения и совместного использования БД многими пользователями.

В стандартную поставку Delphi входят основные объекты из 270 базовых классов (рисунок 1), при этом основным достоинством системы является простота создания графического интерфейса программы. Создание интерфейса реализуется методом draganddrop (бери и тащи), что делает процесс создания интерфейса простым и быстрым, требующим минимального написания программного кода.

1.7 Обзор обоснования методов защиты данных

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

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

Все эти средства защиты делятся на технические и нетехнические.

К техническим средствам защиты относят:

аппаратные и программные средства;

криптографическое закрытие информации.

К нетехническим средствам защиты относят:

аппаратные методы защиты;

программные методы защиты;

резервное копирование;

криптографическое шифрование информации;

физические меры защиты.

организационные мероприятия по защите информации.

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

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

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

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

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

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

Программная защита является наиболее распространенным видом защиты, чему способствуют следующие положительные свойства:

универсальность;

гибкость;

простота реализации;

практически неограниченные возможности изменения и развития и т. п.

2. Проектная часть

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

Во время предпроектного исследования было составлено описание предметной области решаемой задачи.

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

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

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

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

В АРМ входящей информацией является:

список группы;

сведения о студентах, их успеваемости;

сведения об активе учебной группы;

достижение группы;

потери контингента группы за время обучения.

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

2.1.1 Иерархия функций

К функциям оператора отнесем следующие:

ввод данных о группе, ее достижениях;

ввод сведений о студентах;

ввод сведений о потери контингента группы;

анализ отчета, составленного на основании таблиц, находящихся в базе данных.

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

2.1.2 Формализованное описание предметной области

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

Атрибутами сущности «Актив учебной группы» является: код, староста, заместитель старосты, физкультурно-спортивный сектор, культурно-массовый сектор, санитарно-бытовой сектор.

Атрибутами сущности «Достижения учебной группы» является: код, достижения первого полугодия, достижения второго полугодия.

сайт ресторан предметная область Атрибутами сущности «Потери контингента за период обучения» является: код, дата отчисления, причина отчисления, отчисление по другим причинам (указать), ФИО.

Атрибутами сущности «Семья» является: семья, многодетная, полная, неполная.

Атрибутами сущности «Социальный паспорт учащегося» является: счетчик, № п/п, фамилия, имя, отчество, дата рождения, гражданство, домашний адрес, телефон, сведения о состоянии здоровья, семья, отец, мать, другие сведения, семейное положение, фото.

Атрибутами сущности «Список групп» является; счетчик, № п/п, фамилия, имя, отчество, контактный телефон.

Формализованное представление базы данных представлено в таблице 1.

Таблица 1 — Формализованное представление базы данных

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

Таблица 2 — Связи объектов

2.2 Концептуальный уровень базы данных

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

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

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

2.2.1 Модель «объект — отношение»

Модели типа «Объект — Отношение» (ER-модель) относится к классам моделей данных, которые называются расширенными или семантическими моделями. Они позволяют включать сведения о смысловом значении данных, хранящейся в БД. С помощью этой модели строится инфологическая модель предметной области.

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

хорошая наглядность;

подобная модель позволяет проектировать БД с внушительным количеством атрибутов и объектов;

ER-модель реализована в большинстве современных систем для автоматизированного проектирования БД.

Основные элементы ER-моделей:

атрибуты объектов;

объекты (сущности);

связи между объектами.

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

Существует несколько методик построения ER-диаграмм. Наиболее известными являются диаграммы, построенные по методике Ричарда Баркера. Для сравнительного анализа так же была рассмотрена методика Мартина.

В нотации Баркера используется только один тип диаграмм — ER Сущность представляется прямоугольником любого размера, содержащим внутри себя имя сущности, список имен атрибутов (возможно, неполный) и указатели ключевых атрибутов (знак «#» перед именем атрибута). Все связи являются бинарными и представляются линиями с двумя концами (соединяющими сущности), для которых должно быть определено имя, степень множественности и степень обязательности. Для множественной связи линия присоединяется к прямоугольнику сущности в трех точках, а для одиночной связи — в одной точке. При обязательной связи рисуется непрерывная линия до середины связи, при необязательной — пунктирная линия.

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

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

ER диаграмма нашей базы данных представлена на рисунке 2.

Рисунок 2 — ER-диаграмма базы данных АРМ

2.2.2 Даталогическая модель БД

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

актив учебной группы (код, староста, заместитель старосты, физкультурно-спортивный сектор, культурно-массовый сектор, санитарно-бытовой сектор);

достижения учебной группы (код, достижения первого полугодия, достижения второго полугодия);

потери контингента за период обучения (код, дата отчисления, причина отчисления, отчисление по другим причинам (указать), ФИО);

семья (код, многодетная, полная, неполная);

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

список групп (счетчик, № п/п, фамилия, имя, отчество, контактный телефон).

Более удобным считается графическое отображение даталогической модели базы данных (рисунок 3).

Рисунок 3 — Графическое изображение даталогической модели базы данных разрабатываемого АРМ.

2.2.3 Анализ схем отношений на соответствие нормальной формы Бойса — Кодда

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

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

исключение некоторых типов избыточности;

устранение некоторых аномалий обновления;

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

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

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

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

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

Схема находится в 1НФ если все значения атрибутов являются атомарными. Так как в разрабатываемой базе данных все значения атрибутов атомарны (фамилия, имя, отчество, статус и т. д.), то она соответствует 1НФ.

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

Отношение находится в 3НФ тогда и только тогда, когда выполняются следующие условия:

отношение находится во второй нормальной форме;

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

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

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

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

Таким образом, разрабатываемая база находится в 3НФБК, и можно предполагать, что она не содержит избыточных данных, а значит, при вводе или изменении данных не будет наблюдаться аномалий.

2.3 Физическая модель БД на основе выбранной СУБД

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

2.3.1 Описание проектируемых объектов БД

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

Типы и свойства полей таблицы «Актив учебной группы», разработанной в СУБД MS Access представлен на рисунке 4.

Рисунок 4 — Физическое представление таблицы «Актив учебной группы» в СУБД MS Access

Типы и свойства полей таблицы «Отделение» представлены в таблице 4.

Таблица 4 — Тип и свойство полей таблицы «Отделение»

Типы и свойства полей таблицы «Достижения учебной группы» разработанной в СУБД MS Access представлены на рисунке 5.

Рисунок 5 — Физическое представление таблицы «Достижения учебной группы», разработанной в СУБД MS Access

Типы и свойства полей таблицы «Достижения учебной группы» представлены в таблице 5.

Таблица 5 — Типы и свойства полей таблицы «Достижения учебной группы»

Типы и свойства полей таблицы «Потери контингента за период обучения», разработанной в СУБД MS Access, представлен на рисунке 6.

Рисунок 6 — Физическое представление таблицы «Потери контингента за период обучения», разработанной в СУБД MS Access

Таблица 6 — Тип и свойства полей таблицы «Потери контингента за период обучения»

Типы и свойства полей таблицы «Семья», разработанной в СУБД MS Access, представлены на рисунке 7.

Рисунок 7 — Физическое представление таблицы «Семья», разработанной в СУБД MS Access

Таблица 7 — Типы и свойства полей таблицы «Семья»

Типы и свойства полей таблицы «Социальный паспорт учащегося», разработанной в СУБД MS Access, представлен на рисунке 8.

Рисунок 8 — Физическое представление таблицы «Социальный паспорт учащегося», разработанный в СУБД MS Access

Таблица 8 — Типы и свойства полей таблицы «Социальный паспорт учащегося»

2.3.2 Технология создания базы данных

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

Для доступа к таблице базе данных Access используется компонент ADOConnection с панели компонентов ADO, к компоненту ADOConnection подключаем компонент ADOTable для каждой таблицы, используемой для работы в конкретной форме, а затем к нему подключаем компонент промежуточного уровня TDataSoure c панели DataAccess (доступ к данным). Этот компонент служит посредником между таблицами СУБД и экранными элементами управления.

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

В нашем случае не используется DataModule, так как ADOTable и TDataSoure были размещены на конкретных формах.

Рисунок 9 — Компоненты на форме

На некоторых формах (за исключением главной), необходимо сделать отображения данных, хранимых в БД Access, в виде таблицы. Для этой цели используем компонент TDBGrid с панели DataControls (Элементы управления данными) (рисунок 10).

Рисунок 10 — Таблица с данными о списке группы

Для упрощения навигации по таблице, а так же по формам, где отображения в таблицы отсутствует (что немаловажно при наличии большого количества записей) в системе Delphi 7 имеется компонент TDBNavigator. Этот компонент размещается на форме под компонентом TDBGrid и привязывается к нему через свойство DataSoure. Значение этого свойства должно совпадать со значением такого же свойства связанной таблицы (рисунок 11).

Рисунок 11 — Размещение на форме присоединенного средства навигации

2.3.3 Реализация ограничения целостности базы данных

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

Рисунок 12 — Ограничение целостности БД

2.4 Проектирование интерфейса АРМ

Проектирование интерфейса является важным этапом разработки АРМ, так как интерфейс является средством взаимодействия пользователя с программным средством.

Для создания интерфейса АРМ использовались визуальные компоненты панели Standart, additional и другие.

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

TLabel — используется для отображения текста в форме, которую нельзя изменять непосредственно через графический интерфейс пользователя;

TEdit — однострочное редактируемое текстовое поле, хранящее в себе текст, который можно помещать в данный компонент, как во время проектирования, так и во время выполнения программы;

TMemo — (Область просмотра) предназначен для вывода на экран нескольких строк текста;

ТChart — позволяет строить различные диаграммы и графики. В данном случае была построена линейная диаграмма;

ТDBGrid — компонент визуальных данных, в котором отражаются данные формы;

ТTimer — позволяет задавать в приложении интервалы времени;

Button — наиболее часто используемая кнопка, которая предназначена для выполнения какой-либо операции;

ADOConnection — используется для связи с набором данных ADO, может работать с несколькими компонентами наборов данных как диспетчер выполнение их команд;

ADOTable — используется для работы с одной таблицей. Может связываться с ней непосредственно, или через ADOConnection;

ADOQuery — используется для работы с набором данных с помощью запросов SQL, включая такие запросы языка DDL (datadefinitionlanguage), как Createtable. Может связываться с набором данных непосредственно или через ADOConnection.

Для проектирования ввода пароля были использованы элементы edit и button. Так же был использован алгоритм проверки правильности ввода данных, для входа в систему администрирования (рисунок 13).

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

Рисунок 13 — Форма ввода пароля

После успешного ввода пароля появляется главное окно программы (рисунок 14). Основным элементом главной формы является компонент «Главное меню», позволяющий осуществлять необходимые действия.

Рисунок 14 — Главное окно программы

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

" Ввод данных личных данных студента" ;

" Просмотр и редактирование актива группы" ;

" Просмотр и редактирование списка группы" ;

" Просмотр и редактирование данных о потери контингента группы" ;

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

Рисунок 15 — Форма просмотра, редактирования сведений о студентах

Рисунок 16 — Форма просмотра, редактирования сведений об активе группы

Рисунок 17 — Форма просмотра, редактирования списка группы

Рисунок 18 — Форма просмотра, редактирования данных о потери контингента группы

Рисунок 19 — Форма просмотра, редактирования данных о достижениях группы

2.4.1 Требования к пользовательскому интерфейсу

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

2.4.2 Создание справочной системы

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

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

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

подготовка справочной информации (создание файла документа справочной информации);

преобразование файла справочной информации в файл справочной системы.

Рисунок 20 — Справочная система

2.5 Инсталляция АИС

Для инсталляции программного средства необходимо запустить исполняемый файл Auto_Installer_АРМ. exe. В появившемся диалоговом окне будет предложено подтвердить установку программы в указанную директорию, при необходимости укажите нужный вам путь установки и нажмите Install. После установки программы будет автоматически создан ярлык к ней на рабочем столе, а так же запущена сама программа, полностью готовая к работе.

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

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

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

Через главное меню главного окна программы можно закрыть программу, через меню «Открыть» и «Справочники» открыть необходимую форму и работать с данными, хранящимися в БД; вносить новые данные или править существующие.

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

Заключение

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

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

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

В результате проделанной работы по описанию предметной области была разработана концептуальная, а затем и реляционная модели БД. Разработанная АРМ отвечает всем требованиям предметной области.

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

АРМ было разработано в среде программирования Delphi 7, с использованием базы данных MS Access.

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

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

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

1. Архангельский, А. Я. Программирование вDelphi для Windows. Версии 2010, 2012, TurboDelphi / А. Я. Архангельский. — М.: Бином — Пресс, 2010. — 617 с. — ISBN 978−5-9518−0202−6.

2. Бобровский, С.И. Б72 Delphi 7: учебное пособие — СПб.: Питер, 2010. — 736 с. — ISBN 5−8046−0086−9.

3. Григорьев, А.Б. О чем не пишут в книгах по Delphi / А. Б. Григорьев — М.: БХВ-Петербург, 2010. — 623с. ISBN 978−5-9775−0190−3.

4. Могилев, А. В. Практикум по информатике: учебное пособие / А. В. Могилев. — М.: Академия, 2010. — 608с. — ISBN 978−5-7695−6591−5.

5. Сафонов, В. О. Основы современного программирования Delphi: учебное пособие / В. О. Сафонов. — М.: Бином — Пресс, 2011. — 583с. — ISBN 8−5-993−0495−0.

6. Фигурнов, В.Э. Delphi для разработчика / В. Э. Фигурнов. — М.: ИНФРА, 2011. — 408с. — ISBN 5−86 225−471−4.

7. Фаронов, В. В. Программирование баз данных в Delphi 7: учебный курс / В. В. Фаронов. — СПб.: Питер, 2011. — 352 с. — ISBN 5−318−100−9.

8. Гофман В. Delphi 7/Хоменко А., Гофман В., Мещеряков Е., Никифоров В. — М.: БХВ — Петербург, 2011. — 1216 с. — ISBN 5−9964−0168−8.

Приложения

Приложение А

(справочное)

Листинг программы

unit Unit8;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, StdCtrls, Buttons, DB, ADODB, DBCtrls, ExtCtrls;

type

TForm8 = class (TForm)

Panel1: TPanel;

Label1: TLabel;

Label2: TLabel;

Edit1: TEdit;

DBLookupComboBox1: TDBLookupComboBox;

ADOConnection1: TADOConnection;

ADOTable1: TADOTable;

DataSource1: TDataSource;

BitBtn1: TBitBtn;

BitBtn2: TBitBtn;

Button1: TButton;

procedure BitBtn1Click (Sender: TObject);

procedure BitBtn2Click (Sender: TObject);

procedure Button1Click (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form8: TForm8;

implementation

uses Unit1, Unit2;

{$R *. dfm}

procedure TForm8. BitBtn1Click (Sender: TObject);

begin

Application. Terminate;

end;

procedure TForm8. BitBtn2Click (Sender: TObject);

begin

if Edit1. Text=ADOTable1. FieldByName ('Пароль'). AsString then

begin

form8. Visible: =false;

form1. ShowModal;

form8. Close;

end

else

if Edit1. Text='' then

ShowMessage ('Введите пороль')

else

if Edit1. Text<>ADOTable1. FieldByName ('Пароль'). AsString then

ShowMessage ('Введенный пороль не верный');

end;

procedure TForm8. Button1Click (Sender: TObject);

begin

Messagedlg ('Введите Ваши имя пользователя и пароль! ', mtinformation, [mbOk], 0);

end;

end.

unit Unit1;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, XPMan, Menus, ExtCtrls, StdCtrls, jpeg;

type

TForm1 = class (TForm)

MainMenu1: TMainMenu;

N1: TMenuItem;

N5: TMenuItem;

N7: TMenuItem;

XPManifest1: TXPManifest;

N2: TMenuItem;

N3: TMenuItem;

N10: TMenuItem;

N17: TMenuItem;

N18: TMenuItem;

Label1: TLabel;

Label2: TLabel;

Label3: TLabel;

procedure N3Click (Sender: TObject);

procedure N9Click (Sender: TObject);

procedure N10Click (Sender: TObject);

procedure N5Click (Sender: TObject);

procedure N6Click (Sender: TObject);

procedure N15Click (Sender: TObject);

procedure N16Click (Sender: TObject);

procedure N17Click (Sender: TObject);

procedure N18Click (Sender: TObject);

procedure N19Click (Sender: TObject);

procedure N20Click (Sender: TObject);

procedure N7Click (Sender: TObject);

procedure N4Click (Sender: TObject);

procedure N8Click (Sender: TObject);

procedure N13Click (Sender: TObject);

procedure N11Click (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form1: TForm1;

implementation

uses Unit2, Unit3, Unit4, Unit9, Unit11, Unit13, Unit15, Unit17, Unit19, Unit21, Unit23, Unit25, Unit27, Unit29, Unit32;

{$R *. dfm}

procedure TForm1. N3Click (Sender: TObject);

begin

Form2. ShowModal;

end;

procedure TForm1. N9Click (Sender: TObject);

begin

Form3. ShowModal;

end;

procedure TForm1. N10Click (Sender: TObject);

begin

Form1. Close;

end;

procedure TForm1. N5Click (Sender: TObject);

begin

Form4. ShowModal;

end;

procedure TForm1. N6Click (Sender: TObject);

begin

Form9. ShowModal;

end;

procedure TForm1. N15Click (Sender: TObject);

begin

Form11. ShowModal;

end;

procedure TForm1. N16Click (Sender: TObject);

begin

form13. showModal;

end;

procedure TForm1. N17Click (Sender: TObject);

begin

Form15. ShowModal;

end;

procedure TForm1. N18Click (Sender: TObject);

begin

Form17. ShowModal;

end;

procedure TForm1. N19Click (Sender: TObject);

begin

Form19. ShowModal;

end;

procedure TForm1. N20Click (Sender: TObject);

begin

Form21. ShowModal;

end;

procedure TForm1. N7Click (Sender: TObject);

begin

Form23. ShowModal;

end;

procedure TForm1. N4Click (Sender: TObject);

begin

Form25. ShowModal;

end;

procedure TForm1. N8Click (Sender: TObject);

begin

Form27. ShowModal;

end;

procedure TForm1. N13Click (Sender: TObject);

begin

Form29. ShowModal;

end;

procedure TForm1. N11Click (Sender: TObject);

begin

Form32. ShowModal;

end;

end.

unit Unit15;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, StdCtrls, DB, ADODB, DBCtrls, Mask, ExtCtrls, Buttons;

type

TForm15 = class (TForm)

Panel1: TPanel;

Label1: TLabel;

Label2: TLabel;

Label3: TLabel;

Label4: TLabel;

DataSource1: TDataSource;

DBEdit1: TDBEdit;

DBEdit2: TDBEdit;

DBEdit3: TDBEdit;

DBComboBox1: TDBComboBox;

ADOTable1: TADOTable;

ADOConnection1: TADOConnection;

GroupBox1: TGroupBox;

BitBtn1: TBitBtn;

BitBtn2: TBitBtn;

BitBtn3: TBitBtn;

BitBtn4: TBitBtn;

DBNavigator1: TDBNavigator;

procedure BitBtn1Click (Sender: TObject);

procedure BitBtn2Click (Sender: TObject);

procedure BitBtn4Click (Sender: TObject);

procedure BitBtn3Click (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form15: TForm15;

implementation

uses Unit16;

{$R *. dfm}

procedure TForm15. BitBtn1Click (Sender: TObject);

begin

Form15. Close;

end;

procedure TForm15. BitBtn2Click (Sender: TObject);

begin

if MessageDlg ('Удалить текущую запись? '

mtConfirmation, [mbYes, mbNo], 0) = idYes

then

Form15. ADOTable1. Delete;

end;

procedure TForm15. BitBtn4Click (Sender: TObject);

begin

if MessageDlg ('Сохранить измененя? '

mtConfirmation, [mbYes, mbNo], 0) = idYes

then

begin

Form15. ADOTable1. Edit ();

Form15. ADOTable1. Post ();

end;

end;

procedure TForm15. BitBtn3Click (Sender: TObject);

begin

if MessageDlg ('Добавить новую запись? '

mtConfirmation, [mbYes, mbNo], 0) = idYes

then

begin

Form15. ADOTable1. Insert ();

form16. ShowModal;

end;

end;

end.

unit Unit17;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, DBCtrls, StdCtrls, DB, Grids, DBGrids, ADODB, ExtCtrls, Buttons;

type

TForm17 = class (TForm)

Panel1: TPanel;

ADOConnection1: TADOConnection;

ADOTable1: TADOTable;

DataSource1: TDataSource;

GroupBox1: TGroupBox;

DBGrid1: TDBGrid;

ADOTable1DSDesigner: TAutoIncField;

ADOTable1DSDesigner1: TWideStringField;

ADOTable1DSDesigner2: TWideStringField;

Label1: TLabel;

DBNavigator1: TDBNavigator;

BitBtn1: TBitBtn;

BitBtn2: TBitBtn;

BitBtn3: TBitBtn;

BitBtn4: TBitBtn;

procedure BitBtn1Click (Sender: TObject);

procedure BitBtn2Click (Sender: TObject);

procedure BitBtn3Click (Sender: TObject);

procedure BitBtn4Click (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form17: TForm17;

implementation

uses Unit18;

{$R *. dfm}

procedure TForm17. BitBtn1Click (Sender: TObject);

begin

Form17. Close;

end;

procedure TForm17. BitBtn2Click (Sender: TObject);

begin

if MessageDlg ('Удалить текущую запись? '

mtConfirmation, [mbYes, mbNo], 0) = idYes

then

Form17. ADOTable1. Delete;

end;

procedure TForm17. BitBtn3Click (Sender: TObject);

begin

if MessageDlg ('Добавить новую запись? '

mtConfirmation, [mbYes, mbNo], 0) = idYes

then

begin

Form17. ADOTable1. Insert ();

form18. ShowModal;

end;

end;

procedure TForm17. BitBtn4Click (Sender: TObject);

begin

if MessageDlg ('Сохранить измененя? '

mtConfirmation, [mbYes, mbNo], 0) = idYes

then

begin

Form17. ADOTable1. Edit ();

Form17. ADOTable1. Post ();

end;

end;

end.

unit Unit2;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, DB, ADODB, Grids, DBGrids, ExtCtrls, StdCtrls, Buttons, DBCtrls;

type

TForm2 = class (TForm)

Panel1: TPanel;

DBGrid1: TDBGrid;

ADOConnection1: TADOConnection;

DataSource1: TDataSource;

ADOTable1: TADOTable;

ADOTable1DSDesigner2: TWideStringField;

ADOTable1DSDesigner3: TWideStringField;

ADOTable1DSDesigner4: TWideStringField;

ADOTable1DSDesigner5: TIntegerField;

GroupBox1: TGroupBox;

BitBtn1: TBitBtn;

BitBtn2: TBitBtn;

BitBtn3: TBitBtn;

BitBtn4: TBitBtn;

DBNavigator1: TDBNavigator;

procedure BitBtn4Click (Sender: TObject);

procedure BitBtn3Click (Sender: TObject);

procedure BitBtn2Click (Sender: TObject);

procedure BitBtn1Click (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form2: TForm2;

implementation

uses Unit6;

{$R *. dfm}

procedure TForm2. BitBtn4Click (Sender: TObject);

begin

if MessageDlg ('Сохранить измененя? '

mtConfirmation, [mbYes, mbNo], 0) = idYes

then

begin

Form2. ADOTable1. Edit ();

Form2. ADOTable1. Post ();

// form2. ADOTable1. Sort: ='Код';

end;

end;

procedure TForm2. BitBtn3Click (Sender: TObject);

begin

if MessageDlg ('Добавить новую запись? '

mtConfirmation, [mbYes, mbNo], 0) = idYes

then

begin

Form2. ADOTable1. Insert ();

Form6. ShowModal;

end;

end;

procedure TForm2. BitBtn2Click (Sender: TObject);

begin

if MessageDlg ('Удалить текущую запись? '

mtConfirmation, [mbYes, mbNo], 0) = idYes

then

Form2. ADOTable1. Delete;

end;

procedure TForm2. BitBtn1Click (Sender: TObject);

begin

Form2. Close;

end;

end.

unit Unit23;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, StdCtrls, Buttons, Mask, DBCtrls, ExtCtrls, DB, ADODB;

type

TForm23 = class (TForm)

ADOConnection1: TADOConnection;

ADOTable1: TADOTable;

DataSource1: TDataSource;

Panel1: TPanel;

Label1: TLabel;

Label2: TLabel;

Label3: TLabel;

Label8: TLabel;

Label10: TLabel;

Label12: TLabel;

Label15: TLabel;

GroupBox1: TGroupBox;

DBNavigator1: TDBNavigator;

BitBtn1: TBitBtn;

BitBtn2: TBitBtn;

BitBtn3: TBitBtn;

BitBtn4: TBitBtn;

DBEdit1: TDBEdit;

DBEdit2: TDBEdit;

DBEdit7: TDBEdit;

DBEdit9: TDBEdit;

DBEdit11: TDBEdit;

Button1: TButton;

procedure BitBtn4Click (Sender: TObject);

procedure BitBtn3Click (Sender: TObject);

procedure BitBtn2Click (Sender: TObject);

procedure BitBtn1Click (Sender: TObject);

procedure Button1Click (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form23: TForm23;

implementation

uses Unit24, Unit34;

{$R *. dfm}

procedure TForm23. BitBtn4Click (Sender: TObject);

begin

if MessageDlg ('Сохранить измененя? '

mtConfirmation, [mbYes, mbNo], 0) = idYes

then

begin

Form23. ADOTable1. Edit ();

Form23. ADOTable1. Post ();

end;

end;

procedure TForm23. BitBtn3Click (Sender: TObject);

begin

if MessageDlg ('Добавить новую запись? '

mtConfirmation, [mbYes, mbNo], 0) = idYes

then

begin

Form23. ADOTable1. Insert ();

end;

end;

procedure TForm23. BitBtn2Click (Sender: TObject);

begin

if MessageDlg ('Удалить текущую запись? '

mtConfirmation, [mbYes, mbNo], 0) = idYes

then

Form23. ADOTable1. Delete;

end;

procedure TForm23. BitBtn1Click (Sender: TObject);

begin

Form23. Close;

end;

procedure TForm23. Button1Click (Sender: TObject);

begin

// Form34. QuickRep1. PreviewModal;

end;

end.

unit Unit4;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, DB, ADODB, StdCtrls, Mask, DBCtrls, ExtCtrls, Grids, DBGrids,

Buttons, ExtDlgs, OleCtnrs;

type

TForm4 = class (TForm)

Label1: TLabel;

Panel1: TPanel;

Label2: TLabel;

DBEdit1: TDBEdit;

Label3: TLabel;

DBEdit2: TDBEdit;

Label4: TLabel;

DBEdit3: TDBEdit;

Label5: TLabel;

DBEdit4: TDBEdit;

Label6: TLabel;

DBEdit5: TDBEdit;

Label8: TLabel;

DBEdit7: TDBEdit;

Label9: TLabel;

DBEdit8: TDBEdit;

Label10: TLabel;

Label11: TLabel;

DBEdit9: TDBEdit;

DBComboBox1: TDBComboBox;

Label13: TLabel;

DBComboBox2: TDBComboBox;

GroupBox1: TGroupBox;

BitBtn1: TBitBtn;

BitBtn4: TBitBtn;

BitBtn3: TBitBtn;

BitBtn2: TBitBtn;

DBNavigator1: TDBNavigator;

Label14: TLabel;

DBEdit11: TDBEdit;

Label15: TLabel;

DBEdit12: TDBEdit;

OpenPictureDialog1: TOpenPictureDialog;

BitBtn5: TBitBtn;

DBImage1: TDBImage;

Button1: TButton;

DataSource1: TDataSource;

ADOTable1: TADOTable;

ADOConnection1: TADOConnection;

procedure BitBtn1Click (Sender: TObject);

procedure BitBtn2Click (Sender: TObject);

procedure BitBtn3Click (Sender: TObject);

procedure BitBtn4Click (Sender: TObject);

procedure BitBtn5Click (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form4: TForm4;

implementation

uses Unit5, Unit31;

{$R *. dfm}

procedure TForm4. BitBtn1Click (Sender: TObject);

begin

Form4. Close;

end;

procedure TForm4. BitBtn2Click (Sender: TObject);

begin

begin

if MessageDlg ('Сохранить измененя? '

mtConfirmation, [mbYes, mbNo], 0) = idYes

then

begin

Form4. ADOTable1. Edit ();

Form4. ADOTable1. Post ();

end;

end;

end;

procedure TForm4. BitBtn3Click (Sender: TObject);