Общие требования к курсовой работе по дисциплине «Базы данных»
| Вид материала | Исследование |
- Общие требования к курсовой работе по дисциплине «Базы данных», 27.32kb.
- Цели и тематика курсовой работы по дисциплине «Базы данных», 61.1kb.
- Методические указания к выполнению контрольных, курсовых работ По дисциплине Базы данных, 406.26kb.
- Варианты предметных областей для курсовой работы по дисциплине «Базы данных и информационные, 245.82kb.
- Учебно-методическое пособие содержит следующие структурные разделы: введение, цели, 335.07kb.
- Курсовая работа по дисциплине «Базы данных» на тему: «Разработка базы данных для учета, 154.05kb.
- Учебно-методический комплекс дисциплины базы данных Специальность, 414.37kb.
- Методические указания к курсовой работе для специальностей 220100 Вычислительные машины,, 87.91kb.
- 1 научиться создавать таблицу базы данных в режиме таблицы, 54.71kb.
- Методические указания к курсовой работе Владимир 2008, 386kb.
Общие требования к курсовой работе по дисциплине «Базы данных»
Порядок выполнения курсовой работы
- Предпроектное исследование
- Ознакомьтесь со структурой предприятия и документацией, которая используется при решении задачи, согласно вашего индивидуального задания
- На основе сделанного анализа и построенной модели сделайте постановку задачи для разработки программного обеспечения (приложения БД) задачи.
- Ознакомьтесь со структурой предприятия и документацией, которая используется при решении задачи, согласно вашего индивидуального задания
- Стадия проектирования
- Постройте концептуальную модель данных, согласно построенным контекстным диаграммам потоков данных. Уточните атрибуты каждой сущности и постройте ERD-диаграмму.
- Разработайте архитектуру системы. Постройте схему вызова модулей и процедур задачи.
- Разработайте интерфейс системы. Постройте дерево диалога (диаграмма последовательности экранных форм).
- Постройте концептуальную модель данных, согласно построенным контекстным диаграммам потоков данных. Уточните атрибуты каждой сущности и постройте ERD-диаграмму.
- Программирование
- Напишите программный код для реализации задачи. В созданной программной оболочке с использованием выбранной СУБД (Delphi, FoxPro, Access) должны быть реализованы следующие функции:
- Ввод и редактирование данных с контролем за правильностью обрабатываемой информации;
- Поиск и выборка данных по заданным критериям, имея в виду вероятные запросы потенциальных пользователей;
- Выдача на экран и печать (в текстовый файл) после проведения необходимых расчетов выходных форм, определенных в индивидуальном задании;
- Задание правил доступа к хранящейся в БД информации, в зависимости от ранга пользователя, и защиту ее от несанкционированного изменения.
- Ввод и редактирование данных с контролем за правильностью обрабатываемой информации;
- Напишите программный код для реализации задачи. В созданной программной оболочке с использованием выбранной СУБД (Delphi, FoxPro, Access) должны быть реализованы следующие функции:
- Тестирование
- Сформировать тестовые наборы данных
- Провести отладку и тестирование созданного программного приложения.
- Сформировать тестовые наборы данных
- Представление результатов
- Для проверки и получения оценки должны быть представлены следующие результаты
- Набор заполненных файлов базы данных, программных файлов (с исходным текстом программ и загрузочных), файлов-диаграмм всех созданных моделей и файлов с выходными формами;
- Отчет (в напечатанном виде и на магнитном носителе). Отчет должен соответствовать требованиям стандарта по оформлению конструкторской документации и содержать все указанные разделы (см далее)
- Презентации проекта, выполненной в Power Point.
- Набор заполненных файлов базы данных, программных файлов (с исходным текстом программ и загрузочных), файлов-диаграмм всех созданных моделей и файлов с выходными формами;
- Для проверки и получения оценки должны быть представлены следующие результаты
!При составлении отчета содержание пунктов должно соответствовать тематике представленной структуре. Заголовки пунктов содержания нужно изменить согласно решаемой задачи. Например:
1 Предметная область автоматизации → Описание предметной области автоматизации складского учета
Содержание отчета
- Предметная область автоматизации
- Документы предметной области, содержащие информацию, необходимую для решения задачи
- Описание предметной области и функции решаемой задачи
- Документы предметной области, содержащие информацию, необходимую для решения задачи
- Постановка задачи
- Организационно-экономическая сущность задачи
- Описание выходной информации
- Описание входной информации
- Организационно-экономическая сущность задачи
- Информационное обеспечение задачи
- Информационный анализ предметной области и выделение информационных объектов задачи (концептуальная модель)
- Определение логической структуры реляционной базы данных (ERD-модель)
- Информационный анализ предметной области и выделение информационных объектов задачи (концептуальная модель)
- Алгоритмы решения задачи
- Обобщенный алгоритм решения задачи и его декомпозиция на модули (функции) (схема модулей)
- Классификация и реализация используемых запросов
- Обобщенный алгоритм решения задачи и его декомпозиция на модули (функции) (схема модулей)
- Технология решения задачи
- Описание дерева диалога (форм ввода – вывода)
- Технология ввода и накопления входной информации, обеспечивающей решение задачи.
- Технология осуществления запросов
- Технология получения отчетов.
- Описание дерева диалога (форм ввода – вывода)
- Тестирование программы
- Тестовые наборы для контрольного примера
- Результаты тестирования
- Тестовые наборы для контрольного примера
- Руководство пользователя
- Заключение
- Список используемых источников
Методические рекомендации (примеры)
Постановка задачи
Организационно-экономическая сущность задачи
Администрация агентства недвижимости заказала разработку информационной системы для отдела работы с клиентами. Система предназначена для обработки данных о квартирах, которые покупает и продаёт агентство, расценках на квартиры, расценках на оказываемые услуги, о покупателях и совершённых сделках.
Система должна выдавать отчёты по запросу менеджера: прайс-лист на квартиры (возможно, с группировкой по различным признакам), на услуги, отчёты по возможным вариантам сделок для покупателей и продавцов.
Менеджер агентства просматривает, и при необходимости корректирует данные о продаваемых и покупаемых квартирах с указанием стоимости продаваемой недвижимости. Эта информация служит в качестве справочного пособия, и обновляется по мере поступления/выполнения заказов. Также в этой системе хранятся сведения об оказываемых услугах и расценках на них, с тем отличием, что эти данные обновляются в зависимости от политики агентства.
Клиент в устной форме информирует менеджера о необходимой ему услуге. Если исполнение такой услуги входит в сферу деятельности агентства, менеджер информирует клиента о стоимости услуги согласно текущему прайс-листу, и если клиента цена устраивает, то сведения о заключении сделки заносятся в базу данных. Для этого в БД вносятся данные о клиенте - ФИО, контактный телефон, адрес, № паспорта. Также вводится информация об услугах интересующих клиента.
Если клиент хочет продать квартиру, то в базу заносится её местоположение (район и полный адрес), количество помещений, площадь, площадь кухни, наличие балкона и начальная стоимость. Если же клиент выступает в роли покупателя, в базу заносятся сведения о заказе: желаемом местоположении недвижимости, её желаемая площадь, наличие балкона и количество помещений. После внесения всех данных заключается договор на оказание услуг(Ссылка на приложение).
После занесения в данных в базу информации о заключенной сделке в присутствии клиента начинается поиск вариантов методом выборки из БД по соответствующим критериям. Если никаких подходящих вариантов не найдено, клиенту предлагают подождать некоторое время появления подходящих заказов на покупку/продажу недвижимости. Для клиентов, не выбравших услугу купли/продажи, услуги оказываются сразу после заключения договора.
О появившихся в результате поиска вариантах сделок оператор информирует (непосредственно, по телефону, или иным способом) о них заинтересованного клиента. Клиент просматривает варианты, и выбирает наиболее подходящие. После этого о появившемся варианте уведомляется вторая сторона будущей сделки, и после согласования деталей в присутствии представителя агентства производится осмотр недвижимости. Если стороны пришли к соглашению, то заключается сделка о покупке – продаже недвижимости. Менеджер получает от участников сделки положенные комиссионные и удаляет данные о параметрах проданной/купленной недвижимости из базы данных вариантов. Некоторое время эти сведения хранятся в БД (обычно до момента формирования отчётности), затем направляются в архив для длительного хранения на энергонезависимых носителях.
Роль менеджера, таким образом, заключается в оформлении сделки, занесении параметров сделки в базу данных, поиске возможных вариантов сделок и уведомление заказчика о них, корректировке базы данных сделок и справочной информации (расценки, оказываемые услуги, и т.п.). Также менеджер предоставляет отчёты о сделках на различные даты дату.
Описание входной информации
Вся входная информации для решения задачи разделяется на условно-постоянную и оперативно-учетную. Условно-постоянная информация включает следующие данные:
Информация об услугах оказываемых агентством (наименование, цена)
Оперативно-учетная информация включает данные о проведении конкретной сделки:
Информация о клиенте (ФИО, адрес, телефон, номер паспорта)
Информация о квартирах выставляемых на продажу (район, полный адрес, количество комнат, площадь, площадь кухни, наличие балкона и начальная стоимость)
Информация о требованиях клиента к покупаемой квартире (желаемое местоположении, площадь, наличие балкона и количество комнат)
Описание выходной информации
Выходной информацией для «АРМ менеджера агентства недвижимости» является»:
Отчет по сделкам на определенную дату
Прайс лист на услуги
Прайс лист на однокомнатные квартиры
Прайс-лист на двухкомнатные квартиры
Прайс-лист на трехкомнатные квартиры
Прайс-лист на квартиры подходящие требованиям клиента
Договор
Все документы должны выводиться на экран и печать. Формы документов приведены в Приложении Б.
Информационное обеспечение задачи
При описании информационного обеспечения задачи проводится анализ исходной информации ПО с целью определения состава и структуры информации для последующей формализации и построения информационно-логической модели данных. Приведенные формы входных документов позволяют:
1. Выделить объекты и определить роль реквизитов для построения инфологической модели данных, в том числе:
- определить атрибуты каждой сущности и требования к ним;
- определить ключ каждой сущности;
- разработать, если необходимо, классификаторы и кодификаторы сущностей;
- определить требования к сущностям, вытекающие из бизнес-правил предметной области.
2. Выявить связи между сущностями, в том числе:
- структурные связи для выявления классов и подклассов сущностей;
- функциональные связи типа 1:1, 1: m, n:m, n-арные;
- если необходимо, определить атрибуты связей.
Для построения инфологической модели выбирается модель вида ERD-модель, которая отражает функциональные взаимосвязи между атрибутами и связи между информационными объектами.
Результаты проделанной работы рекомендуется оформить в виде следующих документов:
-каталог задач и запросов предметной области;
- альбом форм входных и выходных документов (разместить в приложении к пояснительной записке);
- граф информационных связей задач и запросов;
- таблица сущностей;
- таблица атрибутов;
- таблица связей;
- таблица атрибутов связей.
В таблице сущностей могут быть отражены следующие сведения:
- наименование сущности;
- условное обозначение;
- первичный ключ;
- количество экземпляров сущностей на момент обследования моделируемой предметной области;
- динамика изменения количества экземпляров за определённый период, например, в процентах;
- частота коррекции;
- перечень задачи и запросов, в которых используется данная сущность;
- активность, то есть минимальное количество экземпляров сущности, выбираемое при однократном обращении к ней;
- ограничение на доступность.
В таблице атрибутов для каждой сущности могут быть приведены следующие сведения:
- наименование атрибута;
- условное обозначение;
- признак ключа и тип значения (атомарное или множественное);
- формат (тип и длина);
- диапазон значений;
- возможность принимать неопределённое значение;
- ограничение на доступность (если отличается от ограничений для сущности);
- метод контроля достоверности.
В таблице для связей могут быть приведены следующие сведения:
- наименование связи;
- условное обозначение;
- тип связи;
- характеристика динамики (динамическая или статическая);
- характеристика мощности связи, то есть количество экземпляров сущностей, участвующих в связи (варианты: 0, 1 или много; 1 или много; 0 или 1; точное число);
- перечень атрибутов связи.
Описание атрибутов связей аналогично таблице атрибутов, рассмотренной выше.
На все данные, полученные в результате анализа предметной области и построения концептуальной модели должны быть ссылки в последующих разделах пояснительной записки.
Разработка даталогической модели предметной области
Следующим шагом проектирования будет переход от ERD модели к построению даталогической модели, при этом необходимо сформулировать требования, которые должны учитываться на этапе логического проектирования базы данных. Требования должны носить конкретный характер.
Требования могут содержать:
- требования к эксплуатационным характеристикам базы данных;
- тип СУБД;
- требования к разрабатываемому программному обеспечению;
- описание ролей пользователей и др.
Для осуществления логического этапа проектирования необходимо построить реляционную модель предметной области.
В процессе создания базы данных в среде конкретной СУБД необходимо:
- создать таблицы;
- определить свойства полей;
- задать ключи;
- создать необходимые индексы;
- создать связи;
- определить правила ссылочной целостности.
Примером такой модели является схема данных СУБД Access и описание ее таблиц.
Информационный анализ предметной области и выделение информационных объектов задачи
При анализе предметной области были выделены следующие наиболее важные объекты и их свойства:
- клиент (код клиента, ФИО, адрес, № паспорта). Этот объект был выделен для хранения информации о клиентах
- услуга (код услуги, наименование услуги, стоимость). Объект содержит информацию обо всех услугах, перечень которых предоставляется клиенту
- квартира (код квартиры, код клиента, кол-во комнат, площадь , кухня, наличие балкона, этаж, кол-во этажей в доме, адрес , район, цена, дополнительная информация, статус). Объект содержит информацию о квартирах выставляемых на продажу.
- требования клиента (код требований, код клиента, кол-во комнат, площадь не меньше, наличие балкона, район, дополнительная информация, статус). Объект содержит информацию о требованиях клиентов к покупаемым квартирам.
Разработка инфологической модели предметной области
С помощью инфологической модели можно наглядно представить сущности, атрибуты сущностей и связи между сущностями. Инфологическая модель может быть создана средствами ERWin или в выбранной студентом инструментальной среде для разработки ER-моделей.
На рисунке 3.13а приведена ERD-модель выбранной предметной области. На рисунке 3.13б приведена модель предметной области Учет товара на складе в нотации IDEF1X.
В модели присутствуют две бинарные и одна тернарная связи. Необходимо обратить внимание на то, что степень связи указывается только для бинарных связей.
. Связи между сущностями:
«Сделка» - это тернарная связь, которая связывает сущности «Клиент», «Услуга» и «Квартира». Каждый покупатель может заключать различные сделки на оказание услуг. Это означает, что у покупателя может быть несколько сделок. Клиент может продавать несколько квартир, но квартира принадлежит только одному клиенту и может быть продана только один раз.
Тернарная связь, соединяя три сущности, предполагает наличие кольца при переходе к даталогической модели.
«Имеет» - бинарная связь, которая связывает сущности «Клиент» и «Требования», клиент может иметь несколько различных требований, т.е. хотеть приобрести несколько различных квартир, но требования принадлежат только одному клиенту. (1:М). Класс принадлежности не обязательный для сущности «Клиент» и обязательный для сущности «Требования».
«Расположена» - связывает сущности «Квартира » и «Район», в одном районе может находиться несколько квартир, но квартира может находиться только в одном районе (М:1). Класс принадлежности обязательный.
Тернарная связь, соединяя три сущности, предполагает наличие кольца при переходе к даталогической модели.
Рисунок 3.13а – ERD модель «сущность-связь»
Рис3.13б Пример ER- модоели в нотации IDEF1X (рекомендовано)
Разработка даталогической модели предметной области
После анализа полученной модели выполняется её пошаговое преобразование в реляционную схему по следующим правилам:
1. Каждая простая сущность превращается в отношение. Простая сущность - сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем отношения.
2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствую-щие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут.
3. Компоненты уникального идентификатора сущности превращаются в первичный ключ отношения. Если имеется несколько возможных уникальных идентификаторов, выбирается наиболее используемый.
4. Связи "многие к одному" (и "один к одному") становятся внешними ключами. Для этого делается копия уникального идентификатора с конца связи "один", и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи - столбцам, не допускающим неопределенные значения.
5. В таблицах, построенных на основе ассоциаций, внешние ключи используются для идентификации участников ассоциации, а в таблицах, построенных на основе характеристик и обозначений, внешние ключи используются для идентификации сущностей, описываемых этими характеристиками и обозначениями. Специфицировать ограничения, связанные с каждым из этих внешних ключей.
6. Если в концептуальной схеме присутствовали подтипы, то возможны два способа:
- все подтипы размещаются в одной таблице;
- для каждого подтипа строится отдельная таблица.
7. Выполнить шаги по нормализации полученных отношений, приведя их к желаемой нормальной форме.
8. Указать ограничения целостности проектируемой базы данных и дать (если это необходимо) краткое описание полученных таблиц и их полей.
9. Создать индексы для первичного ключа (уникальный индекс), внешних ключей и тех атрибутов, на которых предполагается в основном базировать запросы и выполнять соединения.
Полученные таблицы и связи могут быть реализованы средствами любой СУБД, например, с помощью приложения Database Desktop создаются таблицы, формата Paradox7 (Таблицы 3.1-3.6).
Таблица 3.1 – Услуги
| Название таблицы | Поле | Тип | Размер | Описание |
| Yslugi | Код услуги | + (Autoincrement) | | Ключевое поле |
| Наименование услуги | Alpha | 30 | | |
| Цена | Long Integer | | |
Таблица 3.2 – Клиенты
| Название таблицы | Поле | Формат | Размер | Описание |
| Klient | Код клиента | +(Autoincrement) | | Ключевое поле |
| ФИО | Alpha | 20 | | |
| Адрес | Alpha | 40 | | |
| № паспорта | Long Integer | | | |
| Телефон | Long Integer | | |
Таблица 3.3 – Квартиры
| Название таблицы | Поле | Тип | Размер | Описание |
| Кvartir | Код квартиры | +(Autoincrement) | | Ключевое поле |
| Код клиента | Long Integer | | | |
| Количество комнат | Long Integer | | | |
| Площадь | Long Integer | | | |
| Площадь кухни | Long Integer | | | |
| Наличие балкона | Long Integer | | | |
| | Код района | Long Integer | | |
| Адрес | Long Integer | | | |
| Этаж | Long Integer | | | |
| Кол-во этажей в доме | Long Integer | | | |
| Цена | Long Integer | | |
Таблица 3.4 – Район
| Название таблицы | Поле | Тип | Размер | Описание |
| Rajon | Код района | +(Autoincrement) | | Ключевое поле |
| Наименование | Alpha | 20 | |
Таблица 3.5 – Требования к квартирам
| Название таблицы | Поле | Тип | Размер | Описание |
| Кvartir_p | Код требований | +(Autoincrement) | | Ключевое поле |
| Код клиента | Long Integer | | | |
| Количество комнат | Long Integer | | | |
| Площадь | Long Integer | | | |
| Наличие балкона | Long Integer | | | |
| Район | Long Integer | | |
Таблица 3.6 – Сделки
| Название таблицы | Поле | Тип | Размер | Описание |
| Sdelki | Код сделки | +(Autoincrement) | | Ключевое поле |
| Код клиента | Long Integer | | | |
| Код услуги | Long Integer | | | |
| Код квартиры | Long Integer | | | |
| Дата | Data | | |
Для того, чтобы отразить взаимосвязи между полученными таблицами по ключевым полям необходимо разработать схему данных средствами ERWin или любой СУБД.
Архитектура системы
Основной задачей этапа проектирования является разработка архитектуры системы и разбиение ее на модули. В данной разделе приводится описание обобщенного алгоритма решения задачи и выделение подзадач. Выделенные подзадачи являются основой декомпозиции программной системы на модули.
При декомпозиции необходимо учесть выделение задач поиска и выборки данных в отдельные модули.
Для описания логики модуля можно использовать структурные элементы для постоения блок-схем и технологических схем стандарта ГОСТ 19.005-85 ЕСПД. Схемы алгоритмов и программ. Обозначения условные графические и правила выполнения. В разделе 2.3 приведены основные символы стандарта и примеры схемы программы и технологической схемы системы
Обобщенный алгоритм решения задачи и его декомпозиция на модули (функции)
Для решения задачи в системе должна храниться справочная информация о квартирах, предлагаемых агентством, оказываемых агентством услугах и их стоимости. Эта информация должна быть загружена в БД до решения задачи.
По мере поступления заявок от граждан на указание услуг и совершении сделок по купле-продаже в систему должен быть осуществлен ввод данных о клиенте и его требованиях. При подготовке сделки в системе происходит формирование запроса и поиск информации по указанным критериям, в качестве которых выступают требования пользователя. Результат запроса выводится на экран, а отчет распечатывается и предъявляется клиенту для выбора подходящего ему варианта.
При заключении сделки в системе происходит расчет стоимости оказанных услуг. Все данные по сделке сохраняются в БД, на основании которых формируется договор, который распечатывается.
В
есь процесс работы с системой состоит из четырех задач: ввода и накопления данных, оформления сделки, поиск данных и формирование отчетных документов, которые можно оформить в виде отдельных модулей. Схематически процесс разбиения программы на модули представлен на рисунке 5.14.
Рисунок 3.14 – Схема модулей
Детальные алгоритмы реализации отдельных модулей задачи и их функционально-технологическая схемы.
Классификация и реализация используемых запросо
Каждая из полученных задач, оформленных в виде модулей, реализуется с помощью определенных алгоритмов и функционально-технологических схем. Необходимо рассмотреть каждую из задач отдельно. В контрольном примере рассмотрим только описание задачи ввода и накопления данных.
1) Рассмотрим задачу ввода данных и накопления данных, назовем ее А1. Для ее реализации необходимо выполнить следующие действия: сначала менеджер, работающий с системой, сортирует данные, необходимые для заполнения, далее он вносит рассортированные данные в нужные таблицы (Рисунок 3.15).
Р
исунок 3.15 –Функционально-технологическая схема задачи А1
Задача ввода данных может быть разбита на несколько основных этапов – модулей. Блок-схема алгоритма решения задачи А1 приведена на рисунке 5.16.
Р
исунок 3.16 – Блок-схема решения задачи А1
Для каждого выделенного модуля системы разрабатывается функционально-технологическая схема и детальный алгоритм для кодирования.
Полученная технологическая схема представлена на рисунках 3.21.
Рисунок 3.21 –Функционально техническая схема модуля А1.1
Процесс: Проверка и внесение данных об услуге
Вход: Информация об услуге, оказываемой агентством
Выход: Формирование данных об услуге в БД
Алгоритм:
- Проверить в накопителе наличие данных об услуге
- Если данные отсутствуют ТО
внести новую запись об услуге в БД
- Вывести данные об услуге на экран
Аналогично описываются описываются остальные модули.
Классификация и реализация используемых запросов
В программе реализуются запросы: поиска данных, запрос при оформлении отчета и при оформлении договора.
А) Осуществляется поиск клиентов, квартир и сделок. Поиск клиентов осуществляется по фамилии клиентов и по улице проживания (Рисунок 3.25).
Поиск по фамилии
Поиск по улице проживания
Рисунок 3.25 – Схема поиска клиента
Интерфейс системы
Параллельно проектированию архитектуры системы и структуры данных необходимо разработать интерфейс системы. Разработка интерфейса включает в себя проектирование его основных элементов: диалога типа вопрос-ответ, команд, форм и меню. В курсовой работе из указанных элементов обязательно разрабатываются экранные формы и меню системы, которые должны быть представлены в виде дерева диалога системы.
- Построение дерева диалога производится на основе DFD – модели следующим образом:
- На DFD выбираются процессы нижнего уровня и для каждого определяется экранная форма. Экранные формы изображаются в виде прямоугольника;
- Выделенные процессы группируются в пункты меню по функциональному признаку или по принадлежности к определенным объектам. Пункты меню изображаются в виде прямоугольников и соединяются с соответствующими формами направленными стрелками;
- Определяется верхняя форма (главная форма приложения), связывающая все формы с меню.
Диаграмма последовательности экранных форм является результатом построения абстрактной модели пользовательского интерфейса системы. Иллюстрирует данную диаграмму рисунок 40. Приложение содержит 3 формы для работы пользователя и 4 отчета.
Первой формой приложения является Pass «Приветствие» На ней расположено приветствие, окно ввода пароля в систему. Переходы к другим формам осуществляются после ввода правильного пароля и нажатия кнопки «Начать работу», иначе вход в систему невозможен.
Вторая форма f «Главная форма проекта»- многостраничная, обеспечивает ввод и редактирование данных о клиентах, услугах и районах, квартирах, сделках, требованиях клиента к квартирам, формирование и вывод отчетов. Можно корректировать записи, а также добавлять и удалять.
На вкладке «Сделки» заключается сделка на оказание услуг, здесь же производится печать договора.
На вкладке «Требования клиента» одновременно с вводом требований производится поиск квартир подходящих под эти требования и печать прайс-листа по ним.
Для удобства пользователя на форме располагается меню содержащее вкладки: ввод данных, поиск данных, отчеты, сохранить, выход, справка.
Третья форма «Поиск данных» предназначена для поиска и фильтрации данных по различным параметрам: поиск клиента – по фамилии клиента, по адресу проживания клиента; поиск квартиры – по адресу, по количеству комнат; поиск сделки по дате.
На вкладке поиск сделки по дате можно распечатать отчет по найденным датам
Форма «Поиск» содержит меню со вкладками: назад (вернуться на главную форму), выход и справка.
Программа содержит 4 вида отчета: прайс-лист на услуги, прайс-лист на квартиры(однокомнатные, двухкомнатные ,трехкомнатные, соответствующие требованиям клиента), отчет по сделкам(по всем сделкам и по найденным), договор .
Рисунок 3.29 – Диаграмма последовательности экранных форм
Технология решения задачи (сопровождается техническими схемами)
Технология ввода и накопления входной информации, обеспечивающей решение задачи
Для решения рассматриваемой задачи должен производиться ввод и накопление оперативно-учетной информации о квартирах выставленных на продажу и требованиях клиентов к покупаемым квартирам.
Справочная информация об услугах, оказываемых агентством должна быть ранее загружена в БД в процессе решения других задач данной предметной области.
В соответствии с этим технология ввода входной оперативной информации и решение рассматриваемой задачи с помощью БД приведено на рисунке 3.30
Технология осуществления запросов и их реализация
Запросы в системе необходимы для создания отчетов и поиска. SQL- запросы создаются при помощи компонента Query. Эти компоненты хранятся в Data Module. Соответствующий запрос осуществляется в момент создания отчета.
Для создания запросов по поиску клиентов на вкладке «Поиск клиентов» размещены: Edit1-поиск по фамилии, Edit2-поиск по адресу. Для события OnChange прописываем код:
procedure Tnov_tr.Edit1Change(Sender: Tobject);
begin
Dm.Klient.Filter:= ‘FIO=’ + ‘’’’+edit1.text+’’’’;
end;
procedure Tnov_tr.Edit2Change(Sender: Tobject);
begin
Dm.Klient.Filter:= ‘Adress=’ + ‘’’’+edit2.text+’’’’;
end;
Для таблицы Klient устанавливаем Filtered:=True.
Рисунок 3.30 – Технологическая схема
Для создания запросов по поиску квартир на вкладке «Поиск квартир» размещены: Edit3-поиск адресу, Edit4-поиск по кол-ву комнат. Для события OnChange прописываем код:
procedure Tnov_tr.Edit3Change(Sender: Tobject);
begin
Dm.Kvart.Filter:=’Adress=’ + ‘’’’+edit3.text+’’’’;
end;
procedure Tnov_tr.Edit4Change(Sender: Tobject);
begin
If edit4.text=’1’ then dm.DataSource3.DataSet:=dm.Query6 ;
If edit4.text=’2’ then dm.DataSource3.DataSet:=dm.Query7 ;
If edit4.text=’3’ then dm.DataSource3.DataSet:=dm.Query8 ;
If edit4.text=’4’ then dm.DataSource3.DataSet:=dm.Query9 ;
If edit4.text=’’ then dm.DataSource3.DataSet:=dm.Kvart ;
end;
В Query прописываем соответствующие SQL- запросы. Для Query6: select * from Kvartir.db where Kol_komnat=’1’. Для Query7: select * from Kvartir.db where Kol_komnat=’2’. Для Query8: select * from Kvartir.db where Kol_komnat=’3’. Для Query9: select * from Kvartir.db where Kol_komnat=’4’.
Для таблицы Kvart устанавливаем Filtered:=True.
Так же возможен поиск квартир по требованиям клиент. Он реализуется на вкладке «Требования клиента» главной формы. Для этого на форме располагается дополнительный DBGrid который ссылается на DM.DS_kv. Для DS_kv DataSet:= Query1. Для Query1 указываем свойство DataSourse:= DM.DS_kv _p(DataSourse ссылающийся на таблицу с требованиями) и прописываем SQL- запрос:
Select*from Kvartir.db
where
Kol_komnat=:Kol_komn and Id=:Id and S>=:S_ne_menshe
and Rajon=:Id_raiona and Prоdano =’2’
Для создания запросов по поиску сделок на вкладке «Поиск сделок по дате» размещены: DateTimePicker1 и три кнопки Button1(Дата больше), Button2(дата меньше), Button3(дата равно). Для таблиц sdelki, sdelki_y, sdelki_pok, sdelki_prod устанавливаем Filtered:=True и прописываем коды для кнопок:
procedure Tnov_tr.Button1Click(Sender: Tobject);
begin
Dm.report.Filter := ‘Data>=’+’’’’+datetostr(DateTimePicker1.Date)+’’’’;
end;
procedure Tnov_tr.Button2Click(Sender: Tobject);
begin
Dm.report .Filter := ‘Data<=’+’’’’+datetostr(DateTimePicker1.Date)+’’’’;
end;
procedure Tnov_tr.Button3Click(Sender: Tobject);
begin
Dm.report.Filter := ‘Data=’+’’’’+datetostr(DateTimePicker1.Date)+’’’’;
end;
Технология получения отчетов
В работе формируется несколько видов отчетов: прайс-лист на услуги, прайс-лист на квартиры, договор.
Прайс-лист на услуги (Приложение Б).
В прайсе располагаем поля Page Header, Title и Detail. В Page Header располагаем элементы QRLabel1. В Title – QRLabel2, QRLabel3 и QRLabel4. На Detail – QRDBText1, QRDBText2, QRDBText3
Для отчета устанавливаем свойство DateSet ~ DM.yslugi. Для элемента QRDBText1 устанавливаем свойства DataSet ~ DM.yslugi, DataField ~ ID_yslug.
Также связываем остальные QRDBText с соответствующими полями таблицы Yslugi
Прайс-лист на квартиры (Приложение Б).
В прайсе располагаем поля Page Header, Title и Detail. В Page Header располагаем элементы QRLabel1. В Title – QRLabel2, QRLabel3, QRLabel4, QRLabel5, QRLabel6, QRLabel7. На Detail – QRDBText1, QRDBText2, QRDBText3, QRDBText4, QRDBText5, QRDBText6.
Для прайса свойство DateSet устанавливается в зависимости от количества комнат: Query6, Query7, Query8, Query9, если это прайс-лист по требованиям то DateSet:= DM.DS_kv
Договор (Приложение Б).
Договор реализуется аналогично предыдущим отчетам, но для свойство DateSet не прописывается. Оно прописывается отдельно для каждого QRDBText1.
Тестирование программы
Тестирование программы производится с целью выявления ошибок допущенных на этапах проектирования и кодирования ПС. Для проведения тестирования необходимо разработать тестовые наборы данных, которые должны обеспечить отладку алгоритма на компьютере и подтвердить работоспособность реализации алгоритма. При разработке теста используйте основные принципы тестирования.
Тестирование — это процесс выполнения программ с целью обнаружения ошибок.
Хорошим считается тест, который имеет высокую вероятность обнаружения еще не выявленной ошибки.
Удачным считается тест, который обнаруживает еще не выявленную ошибку.
Необходимая часть всякого теста — описание ожидаемых выходных данных или результатов. Одна из самых распространенных ошибок при тестировании состоит в том, что результаты каждого теста не прогнозируются до его выполнения. Ожидаемые результаты нужно определять заранее.
Избегайте невоспроизводимых тестов, не тестируйте «с лету». Использование диалоговых систем иногда мешает хорошему тестированию. Для того чтобы тестировать программу в пакетной системе, программист обычно должен оформить тест в виде специальной ведущей программы или в виде файла тестовых данных.
Готовьте тесты, как для правильных, так и для неправильных входных данных. Тесты, представляющие неожиданные или неправильные входные данные, часто лучше обнаруживают ошибки, чем правильные тесты.
Детально изучите результаты каждого теста.
Проект системы должен быть таким, чтобы каждый модуль подключался к системе только один раз.
Тестирование, как почти всякая другая деятельность, должно начинаться с постановки целей.. Тесты должны быть спроектированы, реализованы, проверены и, наконец, выполнены.
Руководство пользователя
Для разработанного ПС должно быть создано руководство пользователя согласно ГОСТ и содержать следующие разделы:
- Введение
- Область применения
- Краткое описание возможностей
- Требования к уровню подготовки пользователя
- Перечень эксплуатационных документов, с которыми необходимо ознакомиться пользователю
- Область применения
- Назначение и условия применения
- Виды деятельности и функции для автоматизации которых предназначено данное ПС
- Условия, при соблюдении которых обеспечивается применение ПС в соответствии с назначением
- Виды деятельности и функции для автоматизации которых предназначено данное ПС
- Подготовка к работе
- Состав и содержание дистрибутивного носителя данных
- Порядок загрузки данных и программ
- Порядок контроля и проверки работоспособности
- Состав и содержание дистрибутивного носителя данных
- Описание операций - для каждой операции обработки данных должно быть указано
- Наименование
- Условия, при соблюдении которых возможно выполнение операции
- Подготовительные действия
- Основные действия в требуемой последовательности
- Заключительные действия
- Ресурсы, расходуемые на операцию
- Описание всех выполняемых функций, задач, комплексов задач, процедур
- Описание операций технологического процесса обработки данных, необходимых для выполнения функций, комплексов программ, процедур.
- Наименование
- Аварийные ситуации
- Действия в случае несоблюдения условий выполнения технологического процесса, в том числе при длительных отказах технических средств
- Действия по восстановлению программ и данных при отказе или обнаружении ошибок в данных
- Действия в случае обнаружения несанкционированного вмешательства в данные системы
- Действия в случае несоблюдения условий выполнения технологического процесса, в том числе при длительных отказах технических средств