Разработка АРМ "Меню"

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

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

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

 

 

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

 

Примерные формы входных и выходных документов

 

Таблица 6

        Отчет по заказам на поставку и изготовление продукции

 

Код поставки	Наименование  получателя	Наименование  товара	Цена	Количество	Сумма	Дата

 

Таблица 7

        Заказ на поставку продукции

 

Дата	Получатель	Товар	Цена	Количество	Сумма	Итого сумма

 

Логический (концептуальный) уровень построен с учетом специфики  и особенностей конкретной СУБД. Этот уровень представления данных ориентирован больше на компьютерную обработку и  на программистов, которые занимаются ее разработкой. На этом уровне формируется концептуальная модель данных, то есть специальным способом структурированная модель предметной области, которая отвечает особенностям и ограничениям выбранной СУБД. Модель логического уровня, поддерживаемую средствами конкретной СУБД, называют еще даталогической (таблицы 8,9,10).

 

Таблица 8

Даталогическая модель таблицы  «Заказчики»

 

Название поля	Тип данных	Ключевое/неключевое
Код заказчика	Числовой, счетчик	Первичный ключ
Наименование	Текстовый	Неключевое
ФИО конт. лица	Текстовый	Неключевое
Контакты	Текстовый	Неключевое

 

Таблица 9

Даталогическая модель таблицы  «Товары»

 

Название поля	Тип данных	Ключевое/неключевое
Код товара	Числовой, счетчик	Первичный ключ
Название	Текстовый	Неключевое
Описание	Текстовый	Неключевое
Цена	Числовой	Неключевое

 

Таблица 10

Даталогическая модель таблицы  «Поставки»

Название поля	Тип данных	Ключевое/неключевое
Код поставки	Числовой, счетчик	Первичный ключ
Код заказчика	Числовой	Внешний ключ
Код товара	Числовой	Внешний ключ
Количество	Текстовый	Неключевое
Сумма	Текстовый	Неключевое
Дата	Дата/время	Неключевое

 

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

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

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

Физическая модель базы данных «Планирование поставок» реализована с помощью СУБД MS Access (рисунок 3).

 

 

Рисунок 3. Схема данных базы данных «Планирование поставок»

 

База данных для разрабатываемой  ИС создана в СУБД MS Access. MS Access представляет собой приложение Microsoft Office, которое  позволяет создавать программные  средства для получения определенных результатов.

Не смотря на простоту, MS Access позволяет  создавать базы данных достаточно сложной  структуры. Удобство MS Access состоит также  и в том, что это приложение интегрировано с другими приложениями Microsoft Office.

Работа с Microsoft Access предполагает создание определенных объектов БД – таблиц, запросов, форм, отчетов, макросов, модулей. Однако в зависимости от требований предметной области не все объекты СУБД MS Access могут быть использованы при создании конкретного приложения. В частности, речь идет о макросах, модулях и страницах данных. Использование этих объектов предполагает достаточно высокие требования к конечному программному продукту [5].

 

 

Одним из базовых понятий методологии  проектирования ИС является понятие  жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим ЖЦ, является международный стандарт ISO/IEC 12207. Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

 Структура ЖЦ ПО по стандарту  ISO/IEC 12207 базируется на трех группах процессов:

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

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

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

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

Модели жизненного цикла.

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под  моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи  процессов, действий и задач, выполняемых  на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение  получили следующие две основные модели ЖЦ:

• каскадная модель (70-85 г.г.);
• спиральная модель (86-90 г.г.).

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

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

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

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

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

 

1. СОЗДАНИЕ БАЗЫ ДАННЫХ ПОДСИСТЕМЫ «МЕНЮ»

1.2.2.1.1. СОЗДАНИЕ ИНФОЛОГИЧЕСКИЙ  И ДАТОЛОГИЧЕСКОЙ МОДЕЛИ БАЗЫ  ДАННЫХ

 

 

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

Анализ элементов БД и отношений между ними позволяет  построить структуру реляционной БД на основе идентификации объектов данных и связей между ними.

При анализе необходимо выявить следующее:

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