Файл: Проектирование реализации операций бизнес-процесса «Покупка сырья и материалов» (Выбор комплекса задач автоматизации).pdf

Рисунок 2. Информационная модель по учету сырья и материалов

2.2. Характеристика нормативно-справочной, входной и оперативной информации

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

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

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

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

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

База

данных

«Учет сырья и материалов»

Общие сведения о товарах Сводная ведомость

Приходная ведомость

учета товара

Приходная накладная Расходная ведомость

учета товара

Рисунок 3 - Структурная схема объекта автоматизации

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

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

 2.3. Характеристика результатной информации

Выходными данными в процессе работы базы данных являются – формирование приходной и расходной ведомостей учета товара, а также расходной накладной. Выходные данные являются итогом работы базы данных. Они являются важными документами, необходимыми для дальнейшей работы торговой компании АО «ГОЛД ПРОДУКТ».

 2.4. Общие положения (дерево функций и сценарий диалога)

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

Рисунок 3 - Структурная схема пакета

 2.5. Характеристика базы данных

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

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

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

Данный программный продукт пишется для открытого акционерного общества компании АО «ГОЛД ПРОДУКТ». В результате изучения организации работы АО «ГОЛД ПРОДУКТ» выяснилось, что данный программный продукт будут применяться для хранения информации о продукции АО «ГОЛД ПРОДУКТ».

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

• тип;
• поставщик;
• срок гарантии;
• стоимость;
• поставщик;
• ответственное лицо;
• дата покупки (поступления).

Так же нужно хранить информацию о бракованной продукции:

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

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

• отдел оформивший заявку;
• ответственное лицо;
• дата подачи заявки.

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

Логическая модель – нормализация всех отношений и нахождение связей между ними.

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

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

Главное условие проектирования – сокращение избыточности данных так, чтобы каждый факт встречался в базе данных только один раз.

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

Между отношениями в базе данных может существовать четыре типа связей: 1:1; 1:М; М:1; М:М.

Взаимосвязи отношений базы данных «Учет сырья и материалов» представлены в Приложении 2.

 2.6. Структурная схема пакета (дерево вызова программных модулей)

На рисунке 4 представлено дерево вызова программных модулей.

Авторизация

SplashScreen

Главное меню

Фильтр материалов

Справка

Справочники

О программе

Об авторе

Группы товаров

Сырье и материалы

добавление

изменение

удаление

Рисунок 4 - Дерево вызова программных модулей

 2.7. Описание программных модулей

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

Таблица 1. Описание программных модулей системы

 2.8. Контрольный пример реализации проекта и его описание

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

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

1) Правильное и удобное для пользователя размещение элементов управления:

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

2) Соблюдать порядок перехода:

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

3) Согласованность элементов пользовательского интерфейса:

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

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

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

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

4) Понятность элементов:

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