71256

Автоматизированная информационная система предприятия по изготовлению корпусной мебели» (кратко «АИС Корпусная мебель»)

Курсовая

Информатика, кибернетика и программирование

Изготовление частей изделия получает в качестве входных данных согласованный проект в управлении участвуют характеристики материалов методики изготовления ГОСТы по изготовлению мебели а также согласованный проект. В качестве выходных данных выступают части изделия готовые к сборке.

Русский

2014-11-04

2.96 MB

13 чел.

 

СОДЕРЖАНИЕ

ВВЕДЕНИЕ 5

1 ПРЕДПРОЕКТНЫЙ АНАЛИЗ ОБЪЕКТА АВТОМАТИЗАЦИИ 6

1.1 Описание предметной области……………………...…………………….. 6

1.2 Функции и организационная структура………………………..………….6

1.3 Описание потоков данных и бизнес процессов…………………………..8

1.4 Обзор и анализ существующих проектных решений, выявление их достоинств и недостатков………………………………………………….....18

2 СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ ИС 20

2.1 Разработка концепции, архитектуры построения и платформы реализации ИС…………………………………………………………………20

2.2 Структура информационной системы, состав функциональных и обеспечивающих подсистем………………………………………………….23

2.3 Техническое обеспечение ИС…………………………………………….25

3 ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ 27

3.1 Описание концептуальной модели информационной базы…………….27

3.2 Описание логической структуры информационной базы………………29

3.3 Описание физической реализации БД…………………………………...32

4 ПРОГРАММНАЯ РЕАЛИЗАЦИЯ ИС 38

4.1 Описание структуры программного обеспечения………………………38

4.2 Алгоритмизация типовых информационных запросов…………………41

4.3 Описание пользовательского интерфейса……………………………….45

ЗАКЛЮЧЕНИЕ 53

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ………………..……………54


ВВЕДЕНИЕ

В данной работе будет представлен проект информационной системы        «Автоматизированная информационная система предприятия по изготовлению корпусной мебели» (кратко «АИС Корпусная мебель»). Основное назначение «АИС Корпусная мебель» - автоматизация работы предприятия ОАО «КорпСбор»,  изготавливающего корпусную мебель.

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

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

Ввиду указанных причин, целью создания  «АИС Корпусная мебель» является снижение экономических затрат на материалы за счет оптимизации их использования.

1 ПРЕД ПРОЕКТНЫЙ АНАЛИЗ ОБЪЕКТА АВТОМАТИЗАЦИИ

1.1 Описание предметной области

Мебельное предприятие ОАО «Корпусная мебель» - молодая, быстро развивающаяся компания по производству и продаже корпусной мебели по индивидуальным заказам, вышедшая на российский рынок в 2013 году.

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

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

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

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

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

1.2 Функции и организационная структура

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

ОАО  «Корпусная мебель» состоит из следующих отделов:

  1.  директор;
  2.  административный отдел;
  3.  отдел производства;
  4.  отдел доставки.

Организационная структура предприятия отражена на рисунке 1.

Рисунок 1 - Организационная модель

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

Отдел производства осуществляет разработку проекта изделие, его последующее изготовление и сборку.

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

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

1.3 Описание потоков данных и бизнес процессов

1.3.1 Моделирование бизнес-процессов.  Бизнес-процесс — это совокупность взаимосвязанных мероприятий или задач, направленных на создание определенного продукта или услуги для потребителей. Для наглядности бизнес-процессы визуализируют при помощи блок-схемы бизнес-процессов[1]. Моделирование бизнес-процессов - деятельность по формированию моделей организаций, включающая описание деловых объектов (подразделений, должностей, ресурсов, ролей, процессов, операций, информационных систем, носителей информации и т. д.) и указание связей между ними. Требования к формируемым моделям и их соответствующее содержание определяются целями моделирования. Бизнес-моделированием также называют дисциплину и отдельный подпроцесс в процессе разработки программного обеспечения, в котором описывается деятельность компании и определяются требования к системе — те подпроцессы и операции, которые подлежат автоматизации в разрабатываемой информационной системе[2].

Проанализировав деятельность мебельного цеха, и проведя пред-проектное исследование, можно выделить три основных бизнес-процесса АИС «Корпусная мебель»:

  1.  Принятие заказа.
  2.  Изготовление частей изделия.
  3.  Расчет с заказчиком.

Функциональное моделирование бизнес-процессов представлено методологией IDEF0. Она описывает те деловые процессы, которые протекают в объекте автоматизации. Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в IDEF0 представлена совокупностью иерархически упорядоченных и логически связанных диаграмм. Каждая диаграмма располагается на отдельном листе. Можно выделить четыре типа диаграмм:

  1.  контекстную диаграмму А-0 (в каждой модели может быть только одна контекстная диаграмма);
  2.  диаграммы декомпозиции (в том числе диаграмма первого уровня декомпозиции А0, раскрывающая контекстную);
  3.  диаграммы дерева узлов;
  4.  диаграммы только для экспозиции (FEO).

Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой (как правило, здесь описывается основное назначение моделируемого объекта). После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы (т.е., получения диаграммы А0) проводится декомпозиция каждого блока диаграммы А0 на более мелкие фрагменты и так далее, до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы - эксперты предметной области (обычно это интервьюируемые аналитиками сотрудники предприятий) указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели[3].

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

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

Функциональный блок «Принятие заказа» включает регистрацию заказа, разработку эскиза, а затем и проекта изделия, а также его согласование с заказчиком. В случае внесения заказчиком каких-либо изменений, эскиз и проект разрабатываются заново. В управлении блоком «Принятие заказа» участвуют характеристики материалов, порядок обслуживания клиентов, проекты готовых решений, ГОСТы по изготовлению мебели. На вход поступает заявка на выполнение работ, на выходе получен согласованный проект и договор. В качестве исполнителей выступают менеджер и мастер-технолог. Диаграмма декомпозиции блока «Принятие заказа» представлена на рисунке 1.4.

Функциональный блок «Изготовление частей изделия» получает в качестве входных данных согласованный проект, в управлении участвуют характеристики материалов, методики изготовления, ГОСТы по изготовлению мебели, а также согласованный проект. В качестве исполнителей выступают мастер-технолог, рабочие, станки и оборудование. В качестве выходных данных выступают части изделия, готовые к сборке.

Рисунок 1.1 - Диграмма последовательности ИС

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

Рисунок 1.2 – Контекстная диаграмма


Рисунок 1.3 - Диаграмма декомпозиции контекстной диаграммы


Рисунок 1.4 - Диаграмма декомпозиции блока «Принятие заказа»

Блок «Изготовление частей изделия» имеет в своем составе следующие блоки: заказ и получение материалов, раскрой плиты на детали, сверление соединительных отверстий облицовывание кромочным материалом. Диаграмма декомпозиции блока «Изготовление частей изделия» представлена на рисунке 1.5. Для автоматизации процесса раскроя потребовалось уточнить, какие процессы входят в блок «Раскрой плиты на детали». Поэтому была составлена и его диаграмма декомпозиции, которая представлена на рисунке 1.6.

Функциональный блок «Расчет с заказчиком» включает доставку, сборку, оплату и закрытие заявки. На вход поступают части изделия, готовые к сборке, в качестве выходных данных выступает акт о выполненных работах. Управляют данным блоком согласованный проект, договор, порядок обслуживания клиентов. Исполнителями являются рабочие, курьер, бухгалтер-кассир и менеджер. Диаграмма декомпозиции функционального блока «Расчет с заказчиком» представлена на рисунке 1.7.

1.3.2 Диаграмма потоков данных. Диаграммы потоков данных (Data Flow Diagramming) являются основным средством моделирования функциональных требований к проектируемой системе. Требования представляются в виде иерархии процессов, связанных потоками данных. Диаграммы потоков данных показывают, как каждый процесс преобразует свои входные данные в выходные, и выявляют отношения между этими процессами. DFD-диаграммы успешно используются как дополнение к модели IDEF0 для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет моделируемую систему как сеть связанных работ. Основные компоненты DFD (как было сказано выше) – процессы или работы, внешние сущности, потоки данных, накопители данных (хранилища). В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой.

Рисунок 1.5 - Диаграмма декомпозиции блока «Изготовление частей изделия»


Рисунок 1.6 - Диаграмма декомпозиции блока «Раскрой плиты на детали»


Рисунок 1.7 – Диаграмма декомпозиции блока «Расчет с заказчиком»

1.4 Обоснование необходимости разработки информационной системы.

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

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

Так как данные хранятся в бумажном варианте или в виде отдельных файлов Excel и Word, то при расчетах с клиентами часто происходит утеря информации о выполнении заказа, то есть имеется риск не выполнить заказ ввиду отсутствия данных о заказчике.

Расчет стоимости заказа ведется вручную. В стоимость заказа включается стоимость материалов, работ по изготовлению и доставки.

На основании вышеперечисленных фактов и с учетом возможностей  существующих проектных решений, составим список функций «АИС Корпусная мебель», которые необходимо реализовать:

- создание заказа;

- сохранение заказа;

- создание плана раскроя листа и возможность его сохранения;

- печать плана раскроя, договора, счета;

- расчет суммы заказа;

- формирование акта о выполненных работах.


2 СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ ИС

2.1 Разработка концепции, архитектуры построения и платформы реализации ИС

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

В настоящее время наиболее распространенными архитектурами являются:

  1.  файл-сервер;
  2.  клиент-сервер;
  3.  многоуровневая архитектура.

Файл-серверная архитектура подразумевает под собой то, что сервер возлагает на себя лишь функцию хранения данных, а обработка производится  на клиентских машинах. Это означает, что данные необходимо передавать по сети, что приведет к сильной загрузке сетевого трафика. А это в свою очередь приведет к снижению производительности при увеличении числа пользователей. Также при реализации архитектуры файл-сервер, проблема целостности, согласованности и одновременного доступа к данным решается децентрализовано: данные хранятся на сервере, а обрабатываются на клиенте. Вследствие этого снижается надежность приложения. Еще одним недостатком являются высокие затраты на модернизацию и сопровождение сервисов бизнес - логики на каждой клиентской рабочей станции. Однако данная архитектура обладает и рядом преимуществ, таких как низкая стоимость разработки, высокая скорость разработки и  невысокая стоимость обновления и изменения программного обеспечения.

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

Следующей ступенью развития архитектур ИС стала многоуровневая архитектура, в которой бизнес-логика выполняется на сервере приложений. Многоуровневая архитектура обладает следующими достоинствами:

  1.  масштабируемость;
  2.  конфигурируемость - изолированность уровней друг от друга позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней;
  3.  высокая безопасность;
  4.  высокая надёжность;
  5.  низкие требования к скорости канала (сети) между терминалами и сервером приложений;
  6.  низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости.

Однако, несмотря на неоспоримые достоинства, данная система не получила распространения, по следующим причинам:

  1.  сложность разработки систем на основе многоуровневой архитектуры, т.к  очень сложно «состыковать» различные модули, особенно если они написаны разными группами. А изменение в одном модуле, как правило, вызывает лавинообразные изменения в остальных, и с этой точки зрения даже простую систему, основанную на многоуровневой архитектуре, будет сложнее выполнить в 2 раза;
  2.  высокие требования к производительности серверов приложений и сервера базы данных, а, значит, и высокая стоимость серверного оборудования;
  3.  высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений;
  4.  высокая сложность администрирования[7].

Рассмотрев  все достоинства и недостатки каждой из архитектур, для реализации системы «АИС Корпусная мебель» выбираем архитектуру клиент-сервер. Данная архитектура позволяет оптимально распределить работу между клиентскими и серверными частями системы: приложение, работающее на рабочей станции, не читает записи базы данных «напрямую», а посылает запросы на сервер, где они последовательно обрабатываются,  а результаты обработки отсылаются на рабочую станцию. А это существенно сокращает информационные потоки в ЛВС.

Схема функционирования и построения информационной системы представлена рисунке 2.1

Рисунок 2.1 - Архитектура "клиент-сервер"

2.2 Структура информационной системы, состав функциональных и обеспечивающих подсистем

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

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

  1.  информационная;
  2.  техническая;
  3.  программная;
  4.  математическая;
  5.  лингвистическая.

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

Состав обеспечивающих подсистем не зависит от выбранной предметной области и имеет:

  1.  функциональную структуру;
  2.  информационное обеспечение;
  3.  математическое (алгоритмическое и программное) обеспечение;
  4.  техническое обеспечение;
  5.  организационное обеспечение,

а на стадии разработки ИС дополнительные обеспечения:

  1.  правовое;
  2.  лингвистическое;
  3.  технологическое;
  4.  методологическое;
  5.  интерфейсы с внешними ИС.

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

Математическое обеспечение состоит из алгоритмического и программного.

Организационное обеспечение – это совокупность средств и методов организации производства и управления ими в условиях внедрения ИС.

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

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

Структура информационной системы, состав функциональных и обеспечивающих подсистем представлена на рисунке 2.2

Рисунок 2.2 - Состав функциональных и обеспечивающих подсистем

2.3 Техническое обеспечение ИС

В соответствие с пунктом 4.3.5.1 Технического задания (приложение А), система реализована посредством технических средств, приобретаемых Заказчиком.

В комплекс технических средств должны входить следующие элементы:

  1.  рабочие станции;
  2.  источники бесперебойного питания;
  3.  средства для построения ЛВС;
  4.  сервер БД;
  5.  принтер.

Требования к серверу:

  1.  память 8 Гб;
  2.  процессор 2.2 ГГц Intel Xeon 5500 минимум;
  3.  скорость диска SATA 8 Гбит/с;
  4.  сетевой адаптер 10 Гбит/с;
  5.  операционная система Windows Server 2008.

Требования к рабочей станции:

  1.  процессор 2 Ггц;
  2.  память 2 Гб;
  3.  жесткий диск не менее 500;
  4.  операционная система Windows 7;
  5.  сетевой адаптер 100 Мбит/с.

Технические средства ИС описаны с учетом требований к функционированию прикладного программного комплекса. Технические средства должны обеспечить:

  1.  круглосуточный режим работы комплекса технических средств и оборудования;
  2.  гарантированное выполнение всего комплекса программного обеспечения в случае сбоя или выхода из строя части оборудования;
  3.  защиту данных от несанкционированного доступа;
  4.  сервера и рабочие места должны быть объединены локальной сетью.

На рисунке 2.3 представлена топология локальной вычислительной сети (ЛВС) для ОАО «КорпСбор».

На рассматриваемом рисунке видно, что через коммутатор к серверу БД и файловому серверу подключены 5 рабочих станций. Топология сети – звезда.

Рисунок 2.3 - Логическая схема сети ОАО "КорпСбор"

3 ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

  1.  Описание концептуальной модели информационной базы

Для хранения данных в информационной системе используется реляционная база данных под управлением СУБД Oracle 11g. Концептуальная схема структуры информационной базы приведена на рисунке 3.1.

В АИС «Корпусная мебель» основными объектами являются Заказ, Детали, Материалы, Счет, Заказчик, Фурнитура, План раскроя, Акт о выполненных работах.Рассмотрим отдельно каждый из объектов.

У сущности «Заказ» есть следующие атрибуты: Номер заказа, Дата поступления, Наименование заказа, Количество комплектов, Срок выполнения, Id заказчика, Id плана.

Сущность «Детали» имеет следующие атрибуты: Id детали, Длина, Ширина, Наименование, Id заказа, Id материала, Количество.

Сущность «Материал» имеет атрибуты: Наименование, Id материала, Цена за лист, Длина, Ширина.

Сущность «Счет» имеет атрибуты: Id счета, Сумма к оплате, Id заказа.

Сущность «Заказчик» имеет атрибуты: Id заказчика, ФИО, Адрес, Телефон.

Сущность «Фурнитура» имеет атрибуты: Id фурнитуры, Наименование, Количество, Стоимость, Id заказа.

Сущность «План раскроя» имеет атрибуты: Id плана, Файл-изображение (переменная строкового типа, в которой будет храниться ссылка на изображение с планом раскроя), Наименование.

Сущность «Акт о выполненных работах» имеет атрибуты: Id плана, Дата окончания работ, ФИО исполнителя, Id заказа.

Между объектами Заказ и Детали максимальная мощность связи 1:N, т.е. одному заказу может принадлежать множество деталей.

Рисунок 3.1 - Концептуальная схема базы данных

Между объектами Детали и Материал максимальная мощность связи 1:N, т.е. на листе материала может быть множество деталей.

Между объектами Акт о выполненных работах и Заказ максимальная мощность связи 1:1, т.е. одному заказу может соответствовать 1 акт о выполнении работ.

Между объектами Заказ и Счет максимальная мощность связи 1:1, т.е. заказу может соответствовать только 1 счет.

Между объектами Заказ и План раскроя максимальная мощность связи 1:N, т.е. в заказе может быть создано несколько планов раскроя.

Между объектами Заказ и Заказчик максимальная мощность связи 1:N, т.е. у одного заказчика может быть множество заказов.

Между объектами Детали и Материал максимальная мощность связи 1:N, т.е. на листе материала может быть множество деталей.

Между объектами Фурнитура и Заказ максимальная мощность 1:N, т.е. одному заказу может соответствовать множество единиц фурнитуры.

3.2 Описание логической структуры информационной базы

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

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

Нормальная форма — свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, потенциально приводящей к логически ошибочным результатам выборки или изменения данных. Нормальная форма определяется как совокупность требований, которым должно удовлетворять отношение. Процесс преобразования отношений базы данных (БД) к виду, отвечающему нормальным формам, называется нормализацией. Нормализация предназначена для приведения структуры БД к виду, обеспечивающему минимальную логическую избыточность, и не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение физического объёма базы данных. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в базе данных информации. Общее назначение процесса нормализации заключается в следующем:

  1.  исключение некоторых типов избыточности;
  2.  устранение некоторых аномалий обновления;
  3.  разработка проекта базы данных, который является достаточно «качественным» представлением реального мира, интуитивно понятен и может служить хорошей основой для последующего расширения;
  4.  упрощение процедуры применения необходимых ограничений целостности.

Устранение избыточности производится, как правило, за счёт декомпозиции отношений таким образом, чтобы в каждом отношении хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов)[9].

В создании и развитии теории нормализации принимали участие многие учёные. Однако первые три нормальные формы и концепцию функциональной зависимости предложил Э. Кодд.

Первая нормальная форма (1NF): переменная отношения находится в первой нормальной форме (1НФ) тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов. В реляционной модели отношение всегда находится в первой нормальной форме по определению понятия отношение. Что же касается различных таблиц, то они могут не быть правильными представлениями отношений и, соответственно, могут не находиться в 1НФ.

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

Третья нормальная форма (3NF): переменная отношения находится в третьей нормальной форме тогда и только тогда, когда она находится во второй нормальной форме и отсутствуют транзитивные функциональные зависимости неключевых атрибутов от ключевых.

Нормальная форма Бойса-Кодда (BCNF): переменная отношения находится в нормальной форме Бойса-Кодда (иначе — в усиленной третьей нормальной форме) тогда и только тогда, когда каждая ее нетривиальная и неприводимая слева функциональная зависимость имеет в качестве своего детерминанта некоторый потенциальный ключ.

Четвёртая нормальная форма (4NF): переменная отношения находится в четвёртой нормальной форме, если она находится в нормальной форме Бойса — Кодда и не содержит нетривиальных многозначных зависимостей.

Пятая нормальная форма (5NF): переменная отношения находится в пятой нормальной форме (иначе — в проекционно-соединительной нормальной форме) тогда и только тогда, когда каждая нетривиальная зависимость соединения в ней определяется потенциальным ключом (ключами) этого отношения[10].

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

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

Рисунок 3.2 – Логическая структура информационной базы

3.3 Описание физической реализации БД

Физическое проектирование — создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т.д.[11].

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

Т.е. в физической модели между параметрами объекта и модели одинаковой физической природы существует однозначное соответствие. В этом случае элементом системы ставятся в соответствие физические эквиваленты, воспроизводящие структуру, основные свойства и соотношения изучаемого объекта. При физическом моделировании, основой которого является теория подобия, сохраняются особенности проведения эксперимента в натуре с соблюдением оптимального диапазона изменения соответствующих физических параметров[9].

В конструкторе были созданы следующие таблицы: Details, Materials, invoice, Furnitur, Zakaz, Zakazchik, Design_cutting, Akt_work_perfomed. Физическая модель АИС «Корпусная мебель» представлена на рисунке 3.3.

Описание созданных таблиц базы данных приведены в таблицах 3.1-3.7.

Рисунок 3.3 - Физическая модель

Таблица 3.1 - Описание полей таблицы Zakaz

Наименование поля БД

Описание поля

Тип данных

Примечание

Id_zakaz

Номер заказа

Integer

PK

Date_invite

Дата заказа

Date

-

Name_zakaza

Имя заказа

Varchar2(255)

-

quantity_komplects

Количество комплектов

Integer

-

Period_execution

Срок выполнения

Date

-

Id_zakazchik

Идентификационный номер заказчика

Integer

FK

Таблица 3.2 - Описание полей таблицы Zakazchik

Наименование поля БД

Описание поля

Тип данных

Примечание

Id_zakazchik

Идентификационный номер заказчика

Integer

PK

FIO

ФИО заказчика

Varchar2(255)

-

Adress

Адрес заказчика

Varchar2(255)

-

Telephone

Телефон

Integer

-

Таблица 3.3 - Описание полей таблицы Details

Наименование поля БД

Описание поля

Тип данных

Примечание

Id_det

Номер детали

Integer

PK

Name

Имя детали

Varchar2(255)

-

Dlina

Длина детали

Decimal(10,2)

-

Shirina

Ширина детали

Decimal(10,2)

-

Kolvo

Количество таких деталей в проекте

Integer

-

Id_zakaz

Идентификатор заказа

Integer

FK

Id_mater

Идентификатор материала

Integer

FK

Таблица 3.4 - Описание полей таблицы Furnitur

Наименование поля БД

Описание поля

Тип данных

Примечание

id_furnit

Номер детали

Integer

PK

Name

Имя детали

Varchar2(255)

-

quantity

Количество

Integer

-

cost

Цена за штуку

Decimal(10,2)

-

Id_zakaz

Идентификатор заказа

Integer

FK

Таблица 3.5 - Описание полей таблицы Materials

Наименование поля БД

Описание поля

Тип данных

Примечание

id_mater

Номер листа

Integer

PK

Name

Имя детали

Varchar2(255)

-

Dlina

Длина

Decimal(10,2)

-

Cost_of_list

Цена за лист

Decimal(10,2)

-

Shirina

Идентификатор заказа

Decimal(10,2)

-

Таблица 3.6 - Описание полей таблицы invoice

Наименование поля БД

Описание поля

Тип данных

Примечание

Id_schet

Идентификационный номер счета

Integer

PK

Date_invoice

Дата оплаты

Date

-

Summ_for_pay

Сумма к оплате

Decimal(10,2)

-

Summ_work

Оплата работы

Decimal(10,2)

Summ_of_materials

Затраты на материалы

Decimal(10,2)

-

Id_zakaz

Номер заказа

Integer

FK

Таблица 3.7 - Описание полей таблицы Akt_work_perfomed

Наименование поля БД

Описание поля

Тип данных

Примечание

Id_act

Идентификационный номер счета

Integer

PK

Data_end

Дата выполнения

Date

-

FIO_worker

ФИО исполнителя

Varchar2(255)

-

Id_zakaz

Номер заказа

Integer

FK

Таблица 3.8 - Описание полей таблицы Design_cutting

Наименование поля БД

Описание поля

Тип данных

Примечание

Id_design

Идентификационный номер плана

Integer

PK

File_raskroy

Файл с планом раскроя

Blob

-

Name_design

Наименование плана

Varchar2(255)

-

Id_zakaz

Номер заказа

Integer

FK

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

Рисунок 3.4 – Пример заполнения таблиц в базе данных Oracle

4 ПРОГРАММНАЯ РЕАЛИЗАЦИЯ ИС

4.1 Описание структуры программного обеспечения

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

Oracle Database 11g помогает снизить затраты на информационные технологии и повысить качество услуг за счет консолидации в облака баз данных и готовые системы, например, Oracle Exadata и Oracle Database Appliance. Это быстрая, надежная, безопасная и легкая в управлении система, подходящая для выполнения всех задач, связанных с базами данных, в том числе с приложениями для предприятий, банками данных и анализом крупных объемов данных. Oracle Exadata — это единственная машина баз данных, которая обеспечивает высочайшую производительность как для банков данных, так и онлайн-обработки транзакций, что делает ее идеальной платформой для консолидации связанных с базами данных смешанных нагрузок в частные облачные среды.

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

Начиная с версии 10g компания Oracle позиционирует свою СУБД как платформу для GRID вычислений. Концепция GRID вычислений достаточно проста, понятна, гибка и позволяет экономить средства предприятия. Поэтому в последнее время наблюдается постепенное внедрение этой архитектуры в IT инфраструктуру. Все большую популярность приобретают многоядерные процессоры. Сейчас большинство новых серверов имеет двух – четырех ядерные процессоры и это не предел. Поэтому эра систем с тысячами процессоров уже не за горами. Нужна платформа, позволяющая эффективно реализовывать приложения на этой инфраструктуре. Oracle предлагает в качестве такой платформы GRID на основе СУБД Oracle 11g.

Для реализации клиентской части приложения будет применена среда разработки Microsoft Visual Studio 2010. Microsoft Visual Studio — линейка продуктов компании Майкрософт, включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств. Данные продукты позволяют разрабатывать как консольные приложения, так и приложения с графическим интерфейсом, в том числе с поддержкой технологии Windows Forms, а также веб-сайты, веб-приложения, веб-службы как в родном, так и в управляемом кодах для всех платформ, поддерживаемых Microsoft Windows, Windows Mobile, Windows CE, .NET Framework, .NET Compact Framework и Microsoft Silverlight.

Visual Studio включает в себя редактор исходного кода с поддержкой технологии IntelliSense и возможностью простейшего рефакторинга кода. Встроенный отладчик может работать как отладчик уровня исходного кода, так и как отладчик машинного уровня. Остальные встраиваемые инструменты включают в себя редактор форм для упрощения создания графического интерфейса приложения, веб-редактор, дизайнер классов и дизайнер схемы базы данных. Visual Studio позволяет создавать и подключать сторонние дополнения (плагины) для расширения функциональности практически на каждом уровне, включая добавление поддержки систем контроля версий исходного кода (как например, Subversion и Visual SourceSafe), добавление новых наборов инструментов (например, для редактирования и визуального проектирования кода на предметно-ориентированных языках программирования или инструментов для прочих аспектов процесса разработки программного обеспечения (например, клиент Team Explorer для работы с Team Foundation Server)[12].

На рисунке 4.1 представлена структура проекта Microsoft Visual Studio 2010.

Рисунок 4.1 - Обозреватель решений проекта

Созданы следующие формы:

  1.  KorpSbor.cs – экранная форма главного окна программы;
  2.  Spravochnik.cs – экранная форма справочника материалов;
  3.  Zakaz.cs – экранная форма создания заказа;
  4.  Plan_raskroya.cs – экранная форма справочника планов раскроя;
  5.  Plan_postr.cs – экранная форма диалогового окна после построения плана раскроя.

Также были созданы экранные формы для справочников «Заказы», «Детали», «Фурнитура», «Заказчики», «Акты», «Счета», но они здесь не приведены, так как их интерфейс аналогичен интерфейсам справочников «Материалы» и «Планы раскроя» и отличается лишь другими столбцами данных.

4.2 Алгоритмизация типовых информационных запросов

4.2.1 Алгоритм реализации раскроя. Для построения планов раскроя использовался модифицированный метод Нелдера-Мида с использованием генетического алгоритма.

Данный метод (далее – алгоритм)  используется   для  получения  плотной   упаковки   k  прямоугольников на   шаге 2 генетического  алгоритма.  Дано  k – число  прямоугольников. Для описания взаимного  расположения  прямоугольников  на   плоскости  будем  использовать   2k -мерное  пространство. Координаты центров прямоугольников будем интерпретировать   как  точку  2k -мерного  пространства.

Для  применения  алгоритма  Нелдера- Мида  важнейшими   шагами  являются  выбор начальной  точки и  критерий  преобразования симплекса. В  алгоритме, изложенном  ниже,  предложен   новый способ выбора  начальной  точки, который   позволяет  двигаться  к  решению   не   выходя  за   пределы построенной допустимой  области  в   пространстве   размерности  2k+2.  Сложность   выбора критерия   преобразования   симплекса   связана  с  необходимостью  предотвратить преждевременную   остановку  алгоритма  из - за   попадания  симплекса   в  локальный   минимум.

Шаг 1.  Построение  правильного  симплекса   в   пространстве   размерности  2k + 2.  При   построении   симплекса   используем   свойство,  что  проекция   любой   его вершины   на   противоположную   грань  совпадает  с  центром  масс  этой   грани.

Шаг 2.  Построение  ограничений  на   расстояния   между   центрами прямоугольников (каждого   с  каждым).

Шаг 3.  Построение  ограничений  для  расстояний   между   центрами прямоугольников  и  сторонами   полосы (для  каждого   прямоугольника   со   всеми сторонами). Эти ограничения преобразуем в ограничения  пространства   2k+2, как  это  было описано  на   предыдущем  шаге.

Шаг 4. Поиск  максимальной  и  минимальной   высоты  полосы.

Шаг 5. Вычисление  текущей   высоты  полосы  как  среднего значения между  максимальной  и  минимальной   высотой  полосы.

Шаг 6.  Вписываем   правильный  симплекс  в   сферу   радиуса . Увеличиваем размер допустимой  области  путем  сдвига  ограничений  на  R.

Шаг 7.  Вычисляем   целевую   функцию   для  каждой  вершины   симплекса. Целевая  функция   C – расстояние   от   вершины   до  ограничений.  По  построению точка  не   нарушает  ограничение,  если   значение   целевой  функции   отрицательно  (чем   меньше  значение   целевой  функции,  тем   оно   ближе   к  искомому решению).  Уменьшаем  размер   допустимой  области  на   величину,  равную модулю  целевой  функции,  умноженному   на   коэффициент   Q.

Шаг 8.  Сортировка  вершин  симплекса   в   зависимости  от   значения   целевой функции   от   максимальных к  минимальным   значениям.

Шаг 9.  Отражаем  i- ую  вершины   симплекса   относительно   своей противоположной   грани   и  получаем  точку I. Если  значение   целевой  функции  для  точки  I строго   отрицательно   и  разность   между   целевой  функцией  и  сдвигом   меньше  ε (чем меньше  ε,  тем   точнее   работа   алгоритма),  то   решение  найдено.

Шаг 10.  Если  значение   целевой  функции   в   точке I отрицательно   и  i- ая вершина   симплекса   не   была  получена   из   точки  I  на   предыдущем преобразовании    симлекса   и  выполнено   хотя   бы  одно  из   следующих   условий 1 или  2,  то   тогда  i-ая   вершина   симплекса   заменяется   своей  противоположной  точкой   и осуществляется   переход  на   Шаг 8.

Шаг 11.  Если  длина   ребра  симплекса   больше  ε,  то   переход  на   Шаг 7.  В противном   случае   решение   не   может   быть  найдено  и  алгоритм   завершает работу.

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

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

Шаг 2.  Выбираем  текущую   высоту  как  среднее  значение   между   минимальной  и  максимальной  высотой.

Шаг 3.  Находим   точку  внутри   допустимой  области.

Шаг 4.  Если допустимая  область  существует,  то  максимальную  высоту  делаем  текущей,  иначе  минимальную  высоту  делаем   текущей.  Если  разность   между  минимальной   и  максимальной  высотой   больше  некоторого   числа  ε,  переходим  на   Шаг 2, в   противном   случае   алгоритм   завершает  свою  работу.

Следует  также   заметить,  что  для  увеличения   скорости   работы  алгоритма можно   увеличить  допустимую  область.  Для  этого  необходимо  увеличить ширину  полосы (например,  на  1-3%),  а  ширину  прямоугольников  уменьшить  (на  1-2%).  Далее  алгоритм   уплотнения   упаковки,  используя  реальные   размеры  полосы,  прямоугольников  и  данные  о   взаимном  расположении прямоугольников,  проверяет  возможность   данной  упаковки.  Если  такая упаковка   возможна,  то   решение   найдено.  Если  увеличение   ширины  полосы  и  уменьшение  ширины  прямоугольников  приводят   к  невозможности   реализации  такой  упаковки,  то   упаковку   необходимо  проводить  с исходными   данными[13].

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

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

Рассмотрим некоторые имеющие место запросы:

  1.  Вывести заказ по его номеру:

select *

from Zakaz

where id_zakaz ='111'

Результат представлен на рисунке 4.2.1:

Рисунок 4.2.1 - Результат запроса поиска заказа по его номеру

  1.  Вывести ФИО и адрес заказчика по дате заказа:

select zk.id_zakazchik, zk.FIO, zk.Adress

from Zakazchik zk, Zakaz z

where z.Date_invite ='25.12.2012'

AND zk.id_zakaz= z.id_zakaz

Результат представлен на рисунке 4.2.2:

Рисунок 4.2.2 - Результат запроса поиска заказчика по дате заказа

  1.  Вывести детали по дате заказа:

select d.*

from Detali d,Zakaz z

where z.Date_invite ='25.12.2012'

AND d.id_zakaz= z.id_zakaz

Результат представлен на рисунке 4.2.3:

Рисунок 4.2.3 - Результат запроса поиска детали по дате заказа

Возможность выполнения таких запросов включена в пользовательский интерфейс.

4.3 Описание пользовательского интерфейса

Пользовательский интерфейс представлен в виде иерархии форм.

В начале работы пользователь видит окно, представленное на рисунке 4.3. Соответствии с техническим заданием (приложение А), в АИС «КорпСбор» существует разграничение доступа на уровне функций. Поэтому, при работе с программой пользователь должен выбрать отдел, в котором он работает и далее ввести пароль (окно ввода пароля представлено на рисунке 4.4). Работникам административного отдела доступны все функции, работникам производственного не доступно изменение заказа, справочных данных заказчика, а также счетов и актов о выполнении работ.

Рисунок 4.3 – Выбор отдела пользователя

Рисунок 4.4 - Окно ввода пароля

При неправильном вводе пароля форма ввода открывается заново. При успешном вводе пароля открывается главное окно программы, представленное на рисунке 4.5.

Рисунок 4.5 - Главное окно программы

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

Рисунок 4.6 - Меню "Заказ"

При нажатии на «Создать» пользователь видит форму создания заказа, представленную на рисунке 4.7.

Рисунок 4.7 - Создание нового заказа

Кнопка «Экспорт» используется, чтобы экспортировать данные о заказе в Microsoft Word для последующей их печати.

При нажатии на кнопку «Сохранить» внесенные изменения сохраняются без выхода из формы ввода, при нажатии на кнопку «ОК» происходить сохранение и выход, при нажатии на кнопку «Отмена» - выход без сохранения изменений.

Вкладки «Заказчик», «Счет» и «Акт» имеют аналогичную вкладке «Заказ» структуру.

Вкладка «Детали» используется для внесения данных по деталям для данного заказа и представлена на рисунке 4.8. Вкладка «Материалы» имеет ту же структуру.

При нажатии на кнопку «Рассчитать план раскроя» появляется окно с результатами расчета. На на рисунках 4.9-4.11 представлен план раскроя для заказа 111. Программа автоматически выполняет раскладку на листы. Вкладки соответствуют листам. Учитывается материал каждого листа.

Рисунок 4.8 - Добавление новых деталей в заказ

Рисунок 4.9 - План раскроя

Рисунок 4.10 - План раскроя. Лист 2

Рисунок 4.11 - План раскроя. Лист 3

При нажатии на кнопку «Сохранить остаток как новый лист» выполняется добавление в справочник «Материалы» нового листа с размерами, соответствующими размерами остатка. Номер новому материалу присваивается автоматически. При нажатии на кнопку «Печать» появляется диалоговое окно печати изображения плана раскроя. При нажатии на кнопку «Сохранить» план раскроя и текст с данными о раскрое экспортируется в Microsoft Word. Все созданные планы раскроя хранятся в базе данных в соответствующем справочнике.

На вкладке «Счет» производится расчет итоговой суммы заказа. Интерфейс вкладки «Счет» представлен на рисунке 4.12. Для заполнения доступны все поля, кроме поля «Итого сумма к оплате». Данное поле рассчитывается автоматически после нажатия на кнопку «Рассчитать итоговую сумму».

Рисунок 4.12 - Вкладка "Счет"

В программе реализован поиск данных. Доступ к поиску осуществляется через меню «Справочники» главного окна программы. На рисунке 4.13 представлено меню для поиска данных по заказу.

Рисунок 4.13 - Поиск заказа

При нажатии на «Поиск по номеру» появляется окно поиска заказа. Поиск данных по заказу с номером 111 представлен на рисунке 4.14.

Рисунок 5 - поиск данных по заказу с номером 111

Для других справочников так же реализована возможность поиска по идентификационному номеру элемента справочника, по номеру заказа, по дате.


ЗАКЛЮЧЕНИЕ

В соответствии с поставленными задачами проектирования информационной системы Internet-сообщества в рамках курсового проекта были выполнены следующие этапы:

  1.  выполнен анализ предметной области;
    1.  разработана функциональная схема АИС «Корпусная мебель»;
    2.  разработана концепция, выбраны архитектура построения и платформа реализации системы;
  2.  спроектирована концептуальная модель АИС «Корпусная мебель»;
  3.  спроектирована логическая модель системы АИС «Корпусная мебель» на основе концептуальной модели;
  4.  определена физическая структура сервера баз данных;
  5.  разработан прототип информационной системы АИС «Корпусная мебель»;

Результатом работы стала АИС «Корпусная мебель», обеспечивающая возможность создания заказа и плана раскроя листа материала, ведение документов о выполнении работ и расчете с заказчиком, поиска данных по заданным пользователем критериям, а также обеспечивающая возможность сохранения и печати создаваемых документов, включая план раскроя. Кроме того, в АИС «Корпусная мебель» существует ограничение доступа пользователя на уровне функций.


СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ

  1.  Грекул, В. И. Проектирование информационных систем/ В. И. Грекул. - М.: Интернет-Университет Информ.технологий, 2005.- 304 с.
  2.  Гвоздева, Т. В.  Проектирование информационных систем/ Т. В. Гвоздева. -  М.: Феникс, 2009.- 512 с.
  3.  Вендров, А. М.Проектирование программного обеспечения экономических информационных систем./ А.М. Вендров – М.: Финансы и статистика, 2000.
  4.  Репин, В. В.  Бизнес-процессы: регламентация и управление/ В. В. Репин.  – М.: ИНФРА, 2004.
  5.  Черемных, С. В.  Структурный анализ систем. IDEF-технологии/ С. В. Черемных, И. О. Семенов. – М.: Финансы и статистика, 2002.
  6.  Марка, Д. А. SADT - методология структурного анализа и проектирования/ Д.А. Марка. – М.: Метатехнология, 1993.
  7.  Дейт, К.Дж. Введение в системы базы данных / К. Дж. Дейт – Вильямс, 2001. – 1072 с.
  8.  Вендров, А.М. Практикум по проектированию программного обеспечения экономических информационных систем  / А.М. Вендров.  – М.: Финансы и статистика,2006. – 192 с.
  9.  Маклаков С.В. Создание информационных систем с AllFusion Modeling Suite / С.В. Маклаков. –М.: Диалог-Мифи, 2003. – 432 с.
  10.  10. Коровкина, Н.Л. Проектирование ИС/ Н.Л. Коровкина. - . -  М.: Феникс, 2007.- 305 с.

Разраб.

Медведев Н.С.

Разраб.

Медведев Н.С.

СИС-42 ЗУ

СИС-42 ЗУ

54

54

Листов

Листов

Лит.

Лит.

Проектирование «АИС Корпусная мебель»

Проектирование «АИС Корпусная мебель»

Утверд.

Иванова О.Г.

Утверд.

Иванова О.Г.

Н. Контр.

Иванова О.Г.

Н. Контр.

Иванова О.Г.

Реценз.

Реценз.

Провер.

Иванова О.Г.

Провер.

Иванова О.Г.

ТГТУ – 230201.404

ТГТУ – 230201.404

4

1

4

1

Лист

Лист

Дата

Дата

Подпись

Подпись

№ докум.

№ докум.

Лист

Лист

Изм.

Изм.

  Инв. № дубл.

  Инв. № дубл.

 Взам. Инв.

 Взам. Инв.

    Подп. и дата

    Подп. и дата

 Инв. № подп.  

 Инв. № подп.  


 

А также другие работы, которые могут Вас заинтересовать

76640. Восточные славяне в древности 32.5 KB
  Однако историки сходятся во мнении что реальными предшественниками русских людей были восточные славяне принадлежащие к группе индоевропейских народов. В результате разгрома сарматами славяне продвигаются на север в лесную зону ассимилируя литовско-латышские и финно-угорские племена. Главными действующими лицами в нем были германцы и славяне.
76641. Особенности становления государственности в России и в мире. Киевская Русь 32.5 KB
  Центром этого государства был Киев. Название этого государства неизвестно. Иногда его называют Каганат русов поскольку глава этого государства по аналогии с соседним хазарским носил титул Кагана. На эти сведения опирается так называемая норманская теория происхождения русского государства.
76642. Крещение Руси 34.5 KB
  Оно имеет длительную историю: распространение христианства на Руси началось задолго до крещения на Днепре и продолжалось еще в течение полутора веков. Православные источники связывают проникновение христианства на территорию Киевской Руси с миссионерской деятельностью апостола Андрея Первозванного в I веке н. Владимир предпринял первую религиозную реформу суть которой состояла в попытке слияния разнородных богов всех племен Киевской Руси в единый пантеон во главе с княжеским богом Перуном.
76643. Феодальная раздробленность Руси 27 KB
  Как и в Западной Европе тенденции к политической раздробленности на Руси проявились рано. Именно с этого времени историческая наука ведет отсчет феодальной раздробленности на Руси. В первые полтора века существования Киевской Руси дружина полностью находилась на содержании у князя.
76645. Русские земли в 15 в. и европейское средневековье. Складывание централизованного государства. Возвышение Москвы 39 KB
  Возвышение Москвы Как и в Западной Европе после периода феодальной раздробленности на Руси в XIVXV вв. На Руси хотя экономические связи между отдельными княжествами без сомнения развивались но общий всероссийский рынок возник позже только в XVII в. Таким образом политические процессы на Руси опережали экономические. Усилиями нескольких поколений выдающихся деятелей на Руси складывается такое государство.
76646. Россия в 16 в. в контексте развития европейской цивилизации. Иван-4 – первый царь Всея Руси. Опричина 35 KB
  Период опричнины В 1560 г. царь вводит новый порядок управления государством получивший название опричнины. Политическим и административным центром опричнины стал особый двор со своей Боярской думой и приказами. В опричнине была особая казна и особое опричное войско: первоначально одна тысяча к концу опричнины шесть тысяч.
76647. Россия в 16 в. в контексте развития европейской цивилизации. «Смутное время». Воцарение династии Романовых 38 KB
  Главной отраслью экономики России оставалось с х а основными с х культурами были рожь и овес. За счет освоения новых земель в Поволжье в Сибири на юге России производилось больше с х продукции чем в прошлом веке хотя методы обработки земли оставались прежними с помощью сохи бороны; плуг внедрялся медленно. – период в истории России названный Смутным временем.
76648. Россия и мир в 18 в. Оформление Российского абсолютизма. Петр 1 27 KB
  В России в XVIII в. При Петре I в России окончательно утвердился абсолютизм Петр был провозглашен императором что означало усиление власти самого царя он стал монархом самодержавным и неограниченным. В России была проведена реформа государственного аппарата – вместо Боярской думы учреждался Сенат в состав которого входили девять сановников ближайших Петру I. В России упразднялась должность патриарха наблюдение за церковью поручалось оберпрокурору Синода.