Автоматизированная система мониторинга зависимости заказов сезонных продуктов от климатических условий

Автор работы: Пользователь скрыл имя, 15 Января 2014 в 11:35, дипломная работа

Краткое описание

Целью данного дипломного проекта является разработка автоматизированной системы мониторинга зависимости заказов сезонных продуктов (АСМЗЗСП) от климатических условий.
Для того чтобы автоматизировать мониторинг зависимости заказов сезонных продуктов от климатических условий, необходимо решить следующие задачи:
1. Собрать материал об аналогичных программных продуктах.
2. Проанализировать сущность задач мониторинга зависимости заказов сезонных продуктов от климатических условий.
3. Выявить преимущества и недостатки разработки программ с использованием среды разработки Borland C++ Builder.
4. Обосновать использование вычислительной техники.
5. Формализовать расчеты.
6. Обосновать разработки по всем видам обеспечения.
7. Построить инфологическую модель.
8. Охарактеризовать входную, постоянную, промежуточную и результатную информацию.
9. Реализовать выбранный вариант проекта.
10. Осуществить модульное тестирование программного продукта.
11. Разработать систему рекомендаций по улучшению системы мониторинга.

Содержание

Введение…………………………………………………………………………3
1 Теоретические аспекты программных продуктов по мониторингу зависимости заказов сезонных продуктов от климатических условий…..…6
1.1 Постановка задачи на разработку………………………………..….6
1.2 Исследование специфика деятельности предприятий, которые занимаются заказом продуктов питания………………………………………8
1.3 Исследование программного обеспечения по мониторингу и учету заказов продуктов……………………………………………………………….10
1.4 Методы проектирования автоматизированных систем мониторинга……………......................................................................................43
1.5 Сравнительный анализ современных средств разработки………...49
2 Проектирование и реализация автоматизированной системы мониторинга зависимости заказов сезонных продуктов от климатических условий……...55
2.1 Обоснование выбора технической платформы проектируемой программы………………………………………………………………………55
2.2 Структурное описание и функциональный анализ программного продукта…………………………………………………………………………57
2.3 Описание и обоснование методов организации входных и выходных данных…………………………………………………………...........................59
2.4 Логическая структура программного продукта……………………69
2.5. Тестирование и надежность программного продукта…………….73
2.6 Руководство пользователя………………………………………….83
2.7 Практические результаты и перспективы разработки……………93
3 Экономическое обоснование…………………………………………………95
3.1 Организация работ………………………………..………………….95
3.2 График проведения работ…………………………………………...101
3.3 Расчет затрат и цены………………………………………………...103
3.4 Обоснование экономической целесообразности…………………..107
4 Экологическая безопасность и безопасность жизнедеятельности………111
Заключение……………………………………………………………….…….117
Список использованных источников…………………………………………121
Приложения…………………………………………………………………….122

Вложенные файлы: 1 файл

Дипломная работа.doc

— 1.30 Мб (Скачать файл)

ТопМаг.ру

Интернет-магазин, специализирующийся на всех видах бытовой техники - различная техника для кухни, уборки, гигиены и пр. (из особенных мне запомнился лишь измельчитель пищевых отходов). А также домашняя аудио и видео техника. В общем всё, что может пригодиться Вам, чтобы сделать свой дом удобным! Наличный и безналичный расчёт. Доставка по Москве осуществляется курьерской службой магазина (о цене ничего не сказано, но видимо она невысока, либо вообще отсутствует). Доставка в другие города оговаривается отдельно. Возможен самовывоз.

Электровеник.ru

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

 

 

 

 

 1.4 Методы проектирования автоматизированных систем мониторинга

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

 

1.4.1 Иерархическая модель данных.

Иерархическая модель [6] данных представляет собой иерархию в виде дерева. Данная модель данных базируется на сегменте, который представляет собой совокупность полей, характеризующих данный сегмент. Сегменты различаются по типу, а каждый тип характеризуется фиксированной длиной и конкретным разбиением на поля данных. Два связанных сегмента, расположенных на смежных уровнях называются исходным (более высокого уровня) и порожденным (более низкого). Иерархическая запись – система взаимосвязанных сегментов, в которой каждый порожденный сегмент представлен столько раз, сколько необходимо для полного раскрытия данного сегмента. В иерархической структуре есть сегмент, который не имеет исходного и называется головным или корневым. В этом сегменте обычно располагается идентификатор объекта, свойства которого раскрываются в сегментах второго и более низких уровней иерархии.

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

• Сложность реализации “многие ко многим”, требующая избыточности данных на физическом уровне, что приведет к нежелательному и не оправданному увеличению БД;

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

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

В связи с тем, что  иерархическая модель обладает большим  количеством недостатков она  не будет применятся для моделирования  разрабатываемой АСМ.

 

 

1.4.2 Сетевая модель данных.

Сеть [5] – более общая структура в сравнении с иерархией. Узлами сети являются отдельные экземпляры записи. Узлы записи являются единицей доступа к БД. Поскольку отдельный узел может иметь несколько непосредственно старших узлов, так же, как и несколько непосредственно подчиненных, то данная структура обеспечивает прямое представление отношения “многие ко многим”. Для связи между записями-узлами существует связующая запись, все экземпляры которой помещаются в цепочку для связи двух экземпляров.

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

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

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

 

 

1.4.3 Реляционная модель данных.

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

Особенность реляционной  модели заключается в том, что  в отличии от сетевой и иерархической моделей реальные объекты и взаимосвязи между ними представляются в базе данных единообразно в виде нормализованных отношений [14].

Основной недостаток реляционной модели данных связывается  с низкой производительностью реляционной  СУБД. Но разработка современных СУБД таких как, ORACLE, InterBase, Acsses и др. позволило преодолеть и этот недостаток.

Достоинства реляционной  модели можно разделить на две  группы:

1) достоинства для пользователя:

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

• не нужно помнить пути доступа к данным и строить алгоритмы и процедуры обработки своего запроса;

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

2) достоинства обработки данных реляционной БД:

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

• точность. Направленные связи в реляционной БД отсутствуют. Отношения по своей природе обладают более точным смыслом и поддаются манипулированию с использованием таких средств, как алгебра и исчисление отношений [5], обеспечивающих наглядность и гибкость модели данных;

• гибкость. Операции проекции и объединения [17] позволяют разрезать и склеивать отношения, так что программист может получать разнообразные файлы в нужной форме;

• секретность. Контроль секретности упрощается. Для каждого отношения имеется возможность задания правомерности доступа, засекреченные показатели можно выделить в отдельные отношения с проверкой прав доступа.

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

• Независимость данных. БД должна допускать возможность расширения, т.е. добавления новых атрибутов и отношений.

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

 

 Выбор концептуальной  модели.

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

• Семантическая модель;

• Фреймы;

• Модель “сущность-связь”.

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

• Описание объектов предметной области происходит естественным языком;

• Все записи, поступающие в БД накапливаются в относительно однородной структуре.

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

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

Модель “сущность-связь” описывается в терминах сущность, связь, значение. Сущность – понятие  которое может быть идентифицировано. Связь – соединение сущностей. Для представления связей и сущностей введен специальный метод: ER-диаграма [17]. Различаются сущности трех основных классов: стержневые, ассоциативные и характеристические. Стержневая сущность – это независимая сущность (ей свойственно независимое существование). Ассоциативная сущность или ассоциация рассматривается как связь между двумя или более сущностями типа "многие -ко- многим" или подобные им. Характеристическая сущность (или характеристика) представляет собой сущность, единственная цель которой, в рамках рассматриваемой предметной области, состоит в описании или уточнении некоторой другой сущности. ER-диаграма – графическое представление взаимосвязей сущностей. Каждое множество сущностей представляется прямоугольником, а множество связей – ромбом. Связи могут быть трех типов: “один к одному”, “один ко многим”, “многие ко многим”. данные типы связи присущи реляционной модели, как и сущности, которым в реляционной модели соответствуют таблицы.

Вывод: в связи с  тем, что модель “сущность-связь” наиболее близка по принципам организации к реляционной модели и реализация последней на основе первой наиболее удобна, то в качестве концептуальной модели выбрана модель “сущность-связь”.

 

 

 

 

 

1.5 Сравнительный анализ современных средств разработки

При создании программного продукта АСМ “Зависимость заказов сезонных продуктов от климатических условий” главным критерием выбора программных средств разработки являлись:

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

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

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

  • Наличие опыта разработки с использованием данного программного продукта;
  • Требования  по ресурсам;
  • Поддержка операционной системы;
  • Наглядность разработки интерфейса;
  • Предоставляемые возможности работы с базами данных;
  • Доступность;
  • Скорость работы разработанного программного обеспечения;
  • Обработка исключительных ситуаций;
  • Время создания разработанного программного обеспечения;
  • Удобство эксплуатации;

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

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

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

Результаты приведены в таблице  1.1

 

 

Таблица 1.1

Средство разработки

 

Характеристика средств разработки

 

 

Delpi

 

 

Visual C++

 

 

Borland C++ Builder

 

 

Visual FoxPro

Наличие опыта разработки с использованием данного программного продукта;

6

6

8

4

Требования  по ресурсам;

6

6

7

5

Поддержка операционной системы;

8

8

8

7

Наглядность разработки интерфейса;

8

7

9

5

Предоставляемые возможности  работы с базами данных;

4

6

8

7

Скорость работы разработанного программного обеспечения;

8

7

6

7

Обработка исключительных ситуаций;

8

8

8

6

Время создания разработанного программного обеспечения;

5

6

9

7

Удобство эксплуатации;

8

8

7

7

Всего:

60

62

70

56

 

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