V этап. Синтез
компьютерной модели объекта.
В процессе создания компьютерной
модели можно выделить некоторые стадии,
типичные для любой СУБД.
Стадия 1. Запуск СУБД, создание нового
файла базы данных или открытие созданной
ранее базы.
Стадия 2. Создание исходной таблицы
или таблиц.
Создавая исходную таблицу,
необходимо указать имя и тип каждого
поля. Имена полей не должны повторяться
внутри одной таблицы. В процессе работы
с БД можно дополнять таблицу новыми полями.
Созданную таблицу необходимо сохранить,
дав ей имя, уникальное в пределах создаваемой
базы.
При проектировании таблиц,
рекомендуется руководствоваться следующими
основными принципами:
1. Информация в таблице
не должна дублироваться. Не должно
быть повторений и между таблицами.
Когда определенная информация
хранится только в одной таблице,
то и изменять ее придется
только в одном месте. Это делает
работу более эффективной, а также
исключает возможность несовпадения
информации в разных таблицах.
Например, в одной таблице должны
содержаться адреса и телефоны
клиентов.
2. Каждая таблица должна
содержать информацию только
на одну тему. Сведения на каждую
тему обрабатываются намного
легче, если они содержатся в
независимых друг от друга
таблицах. Например, адреса и заказы
клиентов лучше хранить в разных
таблицах, с тем, чтобы при удалении
заказа информация о клиенте
осталась в базе данных.
3. Каждая таблица должна
содержать необходимые поля. Каждое
поле в таблице должно содержать
отдельные сведения по теме
таблицы. Например, в таблице с
данными о клиенте могут содержаться
поля с названием компании, адресом,
городом, страной и номером телефона.
При разработке полей для каждой
таблицы необходимо помнить, что
каждое поле должно быть связано
с темой таблицы. Не рекомендуется
включать в таблицу данные, которые
являются результатом выражения.
В таблице должна присутствовать
вся необходимая информация. Информацию
следует разбивать на наименьшие
логические единицы (Например, поля
"Имя" и "Фамилия", а не
общее поле "Имя").
4. База данных должна
иметь первичный ключ. Это необходимо
для того, чтобы СУБД могла
связать данные из разных таблиц,
например, данные о клиенте и
его заказы.
Стадия 3. Создание экранных форм.
Первоначально необходимо указать
таблицу, на базе которой будет создаваться
форма. Ее можно создавать при помощи мастера
форм, указав, какой вид она должна иметь,
или самостоятельно. При создании формы
можно указывать не все поля, которые содержит
таблица, а только некоторые из них. Имя
формы может совпадать с именем таблицы,
на базе которой она создана. На основе
одной таблицы можно создать несколько
форм, которые могут отличаться видом
или количеством используемых из данной
таблицы полей. После создания форму необходимо
сохранить. Созданную форму можно редактировать,
изменяя местоположение, размеры и формат
полей.
Стадия 4. Заполнение БД.
Процесс заполнения БД может
проводиться в двух видах: в виде таблицы
и в виде формы. Числовые и текстовые поля
можно заполнять в виде таблицы, а поля
типа МЕМО и OLE – в виде формы.
VI этап. Работа
с созданной базой данных.
Работа с БД включает в себя
следующие действия:
поиск необходимых сведений;
изменение и дополнение данных.
- Постановка задачи.
Сбор исходных данных
Требуется разработать БД,
обеспечивающую автоматизацию процессов
ведения и распространения информации
о студентах, проживающих в общежитии
(ВУЗа). Cтуденты, проживающие в общежитии,
при поступлении заполняют необходимые
документы (анкету). Потребителем информации
из БД являются комендант, обеспечивающий
проживание приезжих студентов.
Для внесения входной информации
созданы семь базы данных: база студентов,
групп, происшествии, комнат, мебелей,
факультетов.
Входная информация поступает
в БД виде:
- Информация о самих
студентах;
- Информация о месте
проживания(комната) ;
- Информация о родителях;
- Инвентарные номера
мебелей;
- сведений о нарушении
дисциплины в общежитии (сведения
о студентах, проживающих в этой
комнате, дата происшествия и
т. д.).
На выходе пользователи системы
получают информацию в виде:
- сортированный список
студентов общежития, курс, факультет
и т.д. ;
- № комнаты с прикрепленными
мебелями, с инвентарными номерами;
- информация о нарушении
дисциплины с описанием, № комнаты
и дата;
- информация о родителях
(контактные данные), в случаях
ЧС;
- количество студентов
общежития по группам;
Основными требованиями к
функциям БД общежития (информация о студентах)
могут считаться следующие:
получить список студентов
в определенной комнате;
контролировать количество
и дату происшествии в комнатах;
ФИО студентов, ответственные
за определенные мебели;
список студентов по группам;
получить количество студентов
по группам.
Каждый студент ВУЗа проходит
обучение в одной из нескольких учебных
групп, каждая из которых объединяет студентов
одной специальности. Специальности, по
которым ВУЗ обеспечивает подготовку
специалистов, объединяются в факультеты,
причем на разных факультетах специальности
не повторяются. Каждая группа характеризуется
следующими параметрами:
- индекс группы;
- номер курса;
- специальность;
- факультет
У каждого студента есть родители,
следовательно необходимо внести в БД
следующие информации:
- фамилия, имя, отчество
родителей;
- номера телефонов(мобильный,
рабочий);
- место работы;
В комнатах общежития, часто
происходят происшествия (драка, употребление
спиртного, шум среди ночи и т.д.). Для учета
таких происшествии в БД вносятся такие
данные как:
- Дата происшествия;
- Вид происшествия;
- Комната;
Также в каждой комнате имеются
мебели (кровать, вентилятор, стол, стулья
и т.д.). Каждая мебель имеет свой индивидуальный
инвентарный номер и в никакой другой
комнате номер не повторяется. Для получения
списка мебелей в комнате необходимы:
- Инвентарный номер;
- Название мебели;
- Номер комнаты;
- Определение формы
входных и выходных данных. Определение
структуры входных
и выходных данных
Входной информацией являются
4 таблицы.
Которые представляют собой
файл базы данных SQL:
-Информация о самих студентах;
- Информация о месте
проживания(комната) ;
- Информация о родителях;
- Инвентарные номера
мебелей;
- сведений о нарушении
дисциплины в общежитии (сведения
о студентах, проживающих в этой
комнате, дата происшествия и
т. д.).
Выходной информацией являются
различные выборки данных из таблиц: предоставление
информации о студенте (его данные,
список всех платежей, а так же комната
и дата заселения), получение списка всех
заказов за заданный период времени, и
прочие не маловажные запросы. Так же реализована
возможность вывода информации на новый
заказ путем распечатки принтера.
- Модульное и объектное
проектирование
Все таблицы реализованы в SQL Server 2005.
Данная СУБД очень надежна и идет в
ногу со временем.
Структура таблицы «платеж»:
Структура таблицы «Студент»:
Структура таблицы «Комната»:
Структура таблицы «Вселение»:
- Определение стадий
разработки программ
. Стадия «Техническое
задание». Этапы и содержание
работ на этой стадии представлены
в табл. 1.
Таблица 1. Работы, выполняемые
на стадии «Техническое задание»
Этапы работ |
Содержание работ |
Обоснование необходимости
разработки программы |
Постановка задачи. Сбор исходных
материалов. Выбор и обоснование критериев
эффективности и качества разрабатываемой
программы. Обоснование необходимости
проведения научно-исследовательских
работ |
Научно-исследовательские работы |
Определение структуры входных
и выходных данных. Предварительный выбор
методов решения задач. Обоснование целесообразности
применения ранее разработанных программ.
Определение требований к техническим
средствам. Обоснование принципиальной
возможности решения поставленной задачи |
Разработка и утверждение технического
задания |
Определение требований к программе.
Разработка технико-экономического обоснования
разработки программы. Определение стадий,
этапов и сроков разработки программы
и документации на нее. Выбор языков программирования |
Разработка и утверждение технического
задания |
Определение необходимости
проведения научно-исследовательских
работ на последующих стадиях. Согласование
и утверждение технического задания |
Документ «Техническое задание»
оформляется в соответствии с ГОСТ 19.106—78
на листах формата А4 и А3 номера листов
(страниц) проставляются в верхней части
листа над текстом.
Содержание технического задания
должно соответствовать ГОCT 19.201—78 и включать
следующие разделы:
введение;
основания для разработки;
назначение разработки;
требования к программе или
программному изделию;
требования к программной документации;
технико-экономические показатели;
стадии и этапы разработки;
порядок контроля и приемки;
в техническое задание допускается
включать приложения.
В зависимости от особенностей
программы или программного изделия допускается
уточнять содержание разделов, вводить
новые разделы или объединять некоторые
из них.
Для внесения изменений или
дополнений в техническое задание на последующих
стадиях разработки программы или программного
изделия выпускают дополнение к нему.
Согласование и утверждение дополнения
к техническому заданию проводят в том
же порядке, который установлен для технического
задания.
В разделе «Введение» указывают
наименование, краткую характеристику
области применения программы или программного
изделия и объекта, в котором используют
программу или программное изделие.
Все разработки программных
систем можно разбить на три группы: управляемые
потребителем, контролируемые потребителем
и независимые от потребителя. В случае
управляемой потребителем разработки
характеристики области применения задаются
ее потребителем; в случае разработки,
контролируемой потребителем, характеристики
области применения формулируются совместно
разработчиком и потребителем; в случае
независимой от потребителя разработки
вся ответственность за выбор характеристик
области применения ложится на .разработчика.
В разделе «Основания для разработки»
должны быть указаны:
документ (документы), на основании
которых ведется разработка;
организация, утвердившая этот
документ, и дата его утверждения;
наименование и (или) условное
обозначение темы разработки. В разделе
«Назначение разработки» должно быть
указано функциональное и эксплуатационное
назначение программы или программного
изделия.
Раздел «Требования к программе
или программному изделию» должен содержать
следующие подразделы:
требования к функциональным
характеристикам;
требования к надежности;
условия эксплуатации;
требования к составу и параметрам
технических средств;
требования информационной
и программной совместимости;
требования к маркировке и упаковке;
требования к транспортированию
и хранению;
специальные требования.
В подразделе «Требования к
функциональным характеристикам» должны
быть указаны требования к составу выполняемых
функций, организации входных и выходных
данных, временным характеристикам и т.
д.
В этом подразделе должно быть
описано поведение системы с точки зрения
соотношения входа и выхода, без конкретизации
ее внутренней структуры. Описание выполняемых
программой функций (внешних спецификаций)
может быть сделано либо в форме обычного
текста, либо заданием соотношений между
входными и выходными переменными, либо
на некотором специальном языке. Описание
входа заключается в фиксации синтаксиса
(формата, диапазонов значений и т. д.) и
семантики всех входных сообщений. Под
входными сообщениями понимается числовая
и текстовая информация, команды диспетчера,
управляющие команды, преобразованный
в цифровую форму аналоговый сигнал и
т. д. Описание выхода должно содержать
точное описание всех возможных выходных
сообщений программы: форматов выходных
файлов, выходных устройств, графических
и текстовых дисплеев, управляющих сигналов
на цифро-аналоговый преобразователь
и др. При этом существенное значение имеет
описание выхода в тесной взаимосвязи
со входом, так чтобы можно было достаточно
легко определить выход, соответствующий
любому входному сообщению, а также реакцию
программы на непредусмотренные сообщения
на входе.