Содержание:

Введение

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

Цели курсовой работы:

- применение на практике знаний, полученных в процессе изучения курса «Проектирование ИС»;

- получение практических навыков создания АИС, основанных на БД.

Задачи курсовой работы:

- получение представлений о методах и средствах проектирования современных ИС;

- приобретение навыков использования CASE-систем проектирования ИС;

- развитие самостоятельности при разработке ИС на базе программных продуктов AllFusion Process Modeler r7, AllFusion Data Modeler r7 и СУБД SQL Server 2005.

Курсовая работа состоит из следующих частей:

- Построение функциональной модели предметной области в программной среде AllFusion Process Modeler r7, что включает в себя 3 вида диаграмм:

- диаграммы IDEF0;

- диаграмма DFD;

- диаграмма IDEF3.

- Построение UML диаграмм в среде Pacestar UML diagrammer;

- Проектирование логической и физической модели данных в программной среде AllFusion Data Modeler r7;

- Разработка клиентского приложения ИС в среде Access с использованием БД, находящихся в СУБД MySQL Server 5.1.

Глава 1. АНАЛИТИЧЕСКАЯ ЧАСТЬ. Характеристика комплекса задач

1.1 Выбор комплекса задач автоматизации

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

Технологический процесс состоит из следующих стадий, представленных на рис. 2.

Мойка автомобиля

Сушка автомобиля

Разборка автомобиля

Выправление окрашиваемой детали

Зачистка поверхности

Обезжиривание поверхности

Шпатлевка детали

Грунтовка детали

Окрашивание

Грунтовка детали

Замывка детали

Замывка детали

Окрашивание детали

Просушка деталей

Рис 2. Схема технологического процесса предприятия «Аверс»

Контроль качества

Осмотр автомобиля

Проверка качества сборки

Проверка качества окраски

Технологический процесс предприятия заключается в последовательном выполнении шагов на различных стадиях выполнения заказа. Выполнение заказа начинается с правильной подготовки автомобиля или детали к окраске. Сначала автомобиль тщательно и неоднократно моется водой, а после сушиться в специальной камере при температуре 90 0С. Затем с автомобиля снимают все декоративные детали с гальваническим покрытием, резиновые прокладки. Затем кузов разбирается на части для чего снимается капот, крышка багажника, двери и в некоторых случаях крылья. Если деталь деформирована, то ее выправляют и придают ей нужную форму. Затем производится зачистка поверхности от старой краски и ржавчинами путем обработки ее наждачной бумагой и стальными щетками с различного рода растворами. Затем поверхность кузова обезжиривается уайт-спиртом. Проверка качества обезжиривания проводится с помощью фильтровальной бумаги: если на бумаге остаются следы жира или грязи, то поверхность необходимо промыть растворителем еще раз (а возможно, и не раз — пока она не будет полностью обезжирена). Затем поверхность выравнивается с помощью шпатлевки. Толщина слоя шпатлевки не должна превышать 0,3 мм. Время сушки зашпатлеванной поверхности должно выдерживаться в соответствии с техническими условиями на используемую шпатлевку. После высыхания шпатлевки следует загрунтовать зашпатлеванные места. После проведения подготовительных работ приступают к следующему этапу.

Этот этап включает в себя замывку детали, то есть обработку ее крупной шкуркой с водой для удаления неровностей, после чего деталь последний раз грунтуют для лучшего наложения краски и ее фиксации. Затем производят еще одну замывку детали мелкой шкуркой с водой для выравнивания окрашиваемой поверхности и убирания лишних слоев грунтовки, после чего приступают к окрашиванию детали. Окрашивание происходит в два этапа через пульверизатор: первый- нанесение проявочного слоя краски отчетливо проявляющий все дефекты подготовленной поверхности (краска разводится 1 к 4 с растворителем); второй - через 20 минут после нанесения проявочного слоя краски, можно наносить основной, декоративный слой(краска разводится 1 к 3 с растворителем). Оба слоя наносятся быстрыми горизонтальными движениями сверху вниз. В зависимости от пожеланий клиента выполняется аэрография. После нанесения краски автомобиль сушится в сушильной камере при температуре 90 0С 2-3 дня.

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

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

Система создается для обслуживания следующих групп пользователей:

• Администрация предприятия
• Начальники участков
• Работники склада расходных материалов

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

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

• клиентах
• заказах
• ассортименте работ
• стоимости работ
• сотрудниках
• расходных материалах
• поставщиках

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

Организационная структура управления предприятием, которая включает состав подразделений, приведена на рис.3.

Рис.3 Схема организационной структуры предприятия «Аверс»

Участок предварительных работ

Участок окрасочных работ

Участок заключительных работ

Участок контроля качества

Участок работы с клиентами

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

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

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

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

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

Система сквозного контроля за работой предприятия дает возможность полностью отслеживать технологическую цепочку от поступления автомобиля на участок предварительных работ, до его одобрения на участке контроля качества. Это обеспечивает неизменное качество для конечного потребителя, контролируя качество окраски автомобиля по стандартам и технологиям официально предписанными мировыми автокорпорациями как VAG (Audi, VW, Skoda ), PAG (Ford, Volvo, Porsche) BMV RT (BMV, MINI) GM (Opel, Сhevrolet), Toyota, Daimler-Chrysler специально для выполнения ремонтных кузовных и окрасочных работ.

Контроль и обеспечение высокого качества окраски автомобилей — это целый комплекс мероприятий, включающий в себя контроль производимых работ после обработки детали на предварительном этапе и после ее окрашивания. Также происходит контроль качества сборки окрашенного автомобиля. Сквозной контроль проводится с целью предотвращения реализации некачественных работ, не соответствующих требованиям, установленным нормативными документами по стандартизации (ISO/TS 16949).

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

Основными задачами системы сквозного контроля качества работ являются:

1. разработка, внедрение и поддержание систем менеджментана предприятии;

2. разработка и совершенствование схем контроля качества производимых работ;

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

4. обеспечение фонда нормативных документов;

5. обеспечение бесперебойной работы всех участков;

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

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

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

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

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

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

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

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

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

В соответствии с предметной областью система строиться с учетом следующих особенностей:

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

Функциональные возможности:

• Ведение БД (запись, чтение, модификация, удаление);
• Обеспечение логической непротиворечивости БД;
• Реализация наиболее часто встречающихся запросов в готовом виде;

Готовые запросы:

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

1.2. Характеристика существующих бизнес –процессов

Наиболее широко используемой методологией описания бизнес-процессов является стандарт IDEF0. Подход IDEF0 был разработан на основе методологии структурного анализа и проектирования SADT. С момента разработки стандарт не претерпел существенных изменений. В настоящее время развитие методологии IDEF0 сопряжено с развитием поддерживающих ее инструментов – программных продуктов для моделирования бизнес-процессов (BPWin, ProCap, IDEF0/EM Tool и др.) Методология IDEF0 предоставляет аналитику прекрасные возможности для описания бизнеса организации на верхнем уровне с акцентом на управлении процессами. Нотация позволяет отражать в модели процесса обратные связи различного типа: по информации, по управлению, движение материальных ресурсов. Продуманные механизмы декомпозиции модели процесса в IDEF0 позволяют существенно упростить работа аналитика. Следует отметить, что модели в нотации IDEF0 предназначены для описания бизнеса на верхнем уровне. Их основное преимущество состоит в возможности описывать управление процессами организации.

Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований к проектируемой системе. С их помощью система представляется в виде иерархии компонентов (процессов), связанных потоками данных. Главная цель такого представления - продемонстрировать, как каждый процесс преобразует входные данные в выходные, а также выявить отношения между этими процессами. Диаграмма IDEF3 — методология моделирования, использующая графическое описание информационных потоков, взаимодействий между процессами обработки информации и объектов, являющихся частью этих процессов. Методология описания IDEF3 очень близка к алгоритмическим методам построения блок-схем.

В настоящее время для описания бизнес-процессов используется несколько методологий. К числу наиболее распространенных относятся методологии моделирования бизнес-процессов (Business Process Modeling), методологии описания потоков работ (Work Flow Modeling) и методологии описания потоков данных (Data Flow Modeling).

Наиболее широко используемой методологией описания бизнес-процессов является стандарт IDEF0. Подход IDEF0 был разработан на основе методологии структурного анализа и проектирования SADT. С момента разработки стандарт не претерпел существенных изменений. В настоящее время развитие методологии IDEF0 сопряжено с развитием поддерживающих ее инструментов – программных продуктов для моделирования бизнес-процессов (BPWin, ProCap, IDEF0/EM Tool и др.) Методология IDEF0 предоставляет аналитику прекрасные возможности для описания бизнеса организации на верхнем уровне с акцентом на управлении процессами. Нотация позволяет отражать в модели процесса обратные связи различного типа: по информации, по управлению, движение материальных ресурсов. Продуманные механизмы декомпозиции модели процесса в IDEF0 позволяют существенно упростить работа аналитика. Следует отметить, что модели в нотации IDEF0 предназначены для описания бизнеса на верхнем уровне. Их основное преимущество состоит в возможности описывать управление процессами организации.

Второй важнейшей методологией описания процессов является методология IDEF3. Формально эта методология называется Work Flow Modeling, что отражает ее сущность. Стандарт IDEF3 предназначен для описания рабочих процессов или, говоря другими словами, потоков работ. Методология описания IDEF3 очень близка к алгоритмическим методам построения схем процессов стандартными средствами построения блок-схем (построение блок-схемы в MS Word). Основа методологии IDEF3 состоит в построении моделей процессов по принципу последовательно выполняемых во времени работ.

Еще одной группой методологий, активно используемых на практике, являются нотации DFD (Data Flow Diagramming). Эти нотации предназначены для описания потоков данных. Они позволяют отразить последовательность работ, выполняемых по ходу процесса, и потоки информации, циркулирующие между этими работами. Кроме того, нотация DFD позволяет описывать потоки документов (документооборот) и потоки материальных ресурсов (движение материалов от одной работы к другой). С помощью схемы процессов в DFD выявляют основные потоки данных. Это важно для последующего создания моделей структуры данных и разработки требований к информационной системе организации.

Для модели, разработанной в курсовой работе, все виды диаграмм представлены в Приложении 1. Также был произведён стоимостной анализ проекта, результаты которого представлены в Приложении 2. Общая стоимость проекта составила 11 850 руб.

В результате того, что диаграмма IDEF0 была дополнена диаграммами DFD и IDEF3, была получена смешанная диаграмма, которая со всех сторон описывает процесс деятельности предприятия (рис. 1.1).

Рис 1.1. Смешанная диаграмма

1.3. Характеристика документооборота, возникающего при решении задачи

UML (сокр. от англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем.

Использование UML не ограничивается моделированием программного обеспечения. Его также используют для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

UML позволяет разработчикам ПО достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (generalization), объединение (aggregation) и поведение) и больше сконцентрироваться на проектировании и архитектуре.

UML позволяет создавать диаграммы, такие как:

1. Диаграмма вариантов использования.

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

1. Диаграмма взаимодействия.

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

1. Кооперативная диаграмма.

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

1. Диаграмма классов.

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

1. Диаграмма состояний.

Диаграмма состояний, State Machine diagram (диаграмма конечного автомата, диаграмма состояний) — диаграмма, на которой представлен конечный автомат с простыми состояниями, переходами и композитными состояниями. Конечный автомат — спецификация последовательности состояний, через которые проходит объект или взаимодействие в ответ на события своей жизни, а также ответные действия объекта на эти события. Конечный автомат прикреплён к исходному элементу (классу, кооперации или методу) и служит для определения поведения его экземпляров.

1. Диаграмма пакетов.

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

1. Диаграмма деятельности.

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

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

1. Диаграмма компонентов.

Это статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса. Структура ИИС представлена на рис.1.9.

1.4. Обоснование проектных решений по информационному обеспечению

Оболочка клиента будет разработана при помощи Acess, в связи с его тотальным распространением, так как данный продукт является интегрированным в ОС Windows. Не смотря на все увеличивающийся спрос на ОС написанных на ядре Linux подовляющее большинство пользователей работают на различных версиях операционной системы от компании Microsoft. Серверная часть проекта будет базироваться на СУБД MySQL. MySQL имеет двойное лицензирование. MySQL может распространяться в соответствии с условиями лицензии GPL. Однако по условиям GPL, если какая-либо программа включает исходные коды MySQL, то она тоже должна распространяться по лицензии GPL. Это может расходиться с планами разработчиков, не желающих открывать исходные тексты своих программ. Для таких случаев предусмотрена коммерческая лицензия, которая также обеспечивает качественную сервисную поддержку. MySQL также является кроссплатформенным приложением, данная СУБД удобна в использовании, логична, легка в понимании. MySQL является надежным инструментом для управлениями БД. В данной курсовой работе будет использоваться версия MS SQL Server 2005.

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

Процессор: х86-совместимый процессор, желательно класса Intel Celeron IV и выше; частота от 1800 Mhz;

Оперативная память – от 512 Мб;

Видеоадаптер: любая современная видеокарта, от 64Мб ОЗУ;

ОС: Windows: 2000/XP/2003 server x86 .

СУБД: MS SQL Server 2005.

MS office Access 2003 и выше

Информационное обеспечение (ИО) подсистемы представляет собой информационную модель работы сотрудников предприятия. Различают внемашинное и внутримашинное обеспечение.

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

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

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

К информационному обеспечению предъявляются следующие общие требования:

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

для кодирования информации должны использоваться принятые классификаторы;

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

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

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

структура документов и экранных форм должна соответствовать характеристиками терминалов на рабочих местах конечных пользователей;

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

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

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

1.5. Обоснование проектных решений по программному обеспечению

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

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

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

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

Windows 7,

Windows Vista,

Linux Ubuntu

Apple Mac OS X.

Сравнение ОС наиболее логично проводить по следующим критериям:

интерфейс;

безопасность;

программное обеспечение;

цена и производительность.

Установленная на компьютерах пользователей операционная система Windows XP является уже устаревшей, а Windows Vista отличается от нее только в худшую сторону.

Сильной стороной Мас OS является практическое отсутствие вирусов для Мacintosh. Минус – это то, что Mac OS устанавливается только на компьютеры Мacintosh производства фирмы Apple.

Большинство дистрибутивов Linux являются бесплатными, их можно свободно и бесплатно использовать. На основе программного кода как самой Linux, так и входящих в неё программ и на их основе создавать свои продукты.[4] Поставляется со стандартным набором прикладного ПО. В Linux пользователь может выбрать тот дистрибутив, который больше подходит для решения его задач, а затем ещё и оптимизировать систему «под себя». Существование графического интерфейса освобождает от необходимости править конфигурационные файлы в неудобном виде. Положение дел с безопасностью в Linux в общем очень похоже на Mac OS X. Она находятся на очень высоком уровне в обеих системах и значительно опережают Windows.

Результатом политики GPL явилось то, что сейчас имеется более тысячи разных дистрибутивов Linux. Не все из них достойны внимания, пользователю трудно разобраться в таком множестве версий и выбрать то, что нужно. Кроме того, бесплатность подразумевает практически полное отсутствие технической поддержки пользователей. Другой минус – не такая уж и бесплатная получается система, ведь нужно либо купить с ней диск, что тоже деньги, либо скачивать.

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

Наиболее правильным в данной ситуации является выбор операционной системы Windows 7 по следующим причинам:

Знакомый пользователям интерфейс;

Отсутствие необходимости переобучения;

Легкость администрирования;

Меньшая стоимость, чем у ОС компании Apple;

Наличие всех необходимых функций.

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

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

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

Perl (Practical Extraction and Reporting Language) - является одним из наиболее мощных и популярных языков программирования.

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

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

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

Perl легко переносим, он работает на всех основных и многих менее значимых платформах, может получать доступ к соединениям TCP/IP и интегрироваться с языком С. Он обладает также многими специализированными расширениями для доступа к базам данных и каталогам Х.500. Однако главным его достоинством является большое количество новостей и Web-узлов, что обеспечивает программистам на Perl поддержку и ресурсы. Накладываемые ограничения немногочисленны, он исключительно гибок и обладает широкими возможностями поддержки.

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

РHP представляет собой скриптовый язык программирования, который применяется в основном в сфере различных Интернет-приложений. Синтаксис основных конструкций PHP похож на язык программирования C++. PHP – это достаточно молодой язык, пришедший на замену Perl, он в большей степени ориентирован на web-программирование, не сложен в изучении, имеет большое количество разнообразных подключаемых модулей, расширяющие его практическое применение. Главной целью применения PHP является создание динамического HTML, позволяющего отображать различный контекст в приложении, в зависимости от действий пользователя.

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

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

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

В качестве недостатка PHP 3 выделяют его низкую по сравнению с Perl производительность на сложных приложениях при обработке больших скриптов, то есть в тех случаях, когда сайт состоит из нескольких страниц, но с длинным кодом. В таких ситуациях выгодней использовать CGI. Поэтому при выпуске новой версии PHP 4 основное внимание было уделено повышению быстроты работы. Также были затронуты вопросы безопасности и была внедрена поддержка сессий. Новая версия PHP содержала в себе ядро Zend Engine, которое позволило добиться увеличения производительности и стабильности за счет более качественной поддержки модулей.

В дальнейшем проводились работы по улучшению технологии Zend в части поддержки модели объектно-ориентированного программирования, что вылилось в создание PHP версии 5. Это версия включает в себя ядро Zend Engine 2, поддержку языка разметки XML, в PHP появились такие понятия объектно-ориентированной модели как деструкторы, интерфейсы, клонирование объектов.

Ruby on Rails — это полноценный, многоуровневый фреймворк для построения веб-приложений, использующих базы данных, который основан на архитектуре Модель-Представление-Контроллер (Model-View-Controller, MVC).

Rails предоставляет однородную среду разработки на Ruby для динамичных AJAX-интерфейсов: обработки запросов и выдачи данных в контроллерах. Для работы необходима только — это база данных и веб-сервер.

Rails — это, прежде всего, инфраструктура, поэтому среда подходит для любого типа веб-приложений.

Rails работает со многими веб-серверами и СУБД. В качестве веб-сервера рекомендуется использовать Apache или lighttpd как с FastCGI, так и с SCGI. В качестве СУБД можно использовать MySQL, PostgreSQL, SQLite, Oracle, SQL Server, DB2 или Firebird. Использовать Rails можно на практически любой операционной системе, однако для развертывания рекомендуются системы семейства Unix.

ASP.NET – это часть технологии .NET, используемая для написания мощных клиент-серверных интернет приложений. Она позволяет создавать динамические страницы HTML. ASP.NET возникла в результате объединения более старой технологии ASP (активные серверные страницы) и .NET Framework. Она содержит множество готовых элементов управления, используя которые можно быстро создавать интерактивные web-сайты. Также есть возможность использовать сервисы, предоставляемые другими сайтами, прозрачно для пользователей собственной разработки.

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

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

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

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

Благодаря этим и другим усовершенствованиям ASP.NET намного увеличивает возможности разработчиков – за счет чего она популярна и очень быстро развивается.

На основании проведенного анализа выбран язык PHP.

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

Выбор системы управления базами данных (СУБД) представляет собой сложную задачу, для решения которой необходимо учесть множество факторов и параметров. Эта задача является одним из самых важных этапов при разработке приложений баз данных. Выбранный программный продукт должен удовлетворять как текущим, так и будущим потребностям предприятия, при этом следует учитывать финансовые затраты на приобретение необходимого оборудования, самой системы, разработку необходимого программного обеспечения на ее основе, а также обучение персонала. Кроме того, необходимо убедиться, что новая СУБД способна принести предприятию реальные выгоды [1].

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

Структура данных;

Функциональные возможности;

Особенности разработки приложений;

Производительность;

Требования к рабочей среде.

Рассмотрим каждую из этих групп в отдельности.

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

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

3. Особенности разработки приложений. Многие производители СУБД выпускают также средства разработки приложений для своих систем. Как правило, эти средства позволяют наилучшим образом реализовать все возможности сервера, поэтому при анализе СУБД стоит рассмотреть также и возможности средств разработки приложений. К данной группе требований можно отнести следующие: средства проектирования, многоязыковая поддержка, возможности разработки Web-приложений.

4. Производительность. Производительность системы является одним из самых важных показателей, который будет использоваться в статье в качестве основного критерия для выбора СУБД. Существует несколько факторов, которые можно отнести к производительности системы и которые могут учитываться для оценки производительности данной СУБД. Такими факторами являются следующие: рейтинг ТРС (Transactions per Cent), возможности параллельной архитектуры, возможности оптимизирования запросов.

5. Требования к рабочей среде. К данной группе требований можно отнести следующие: поддерживаемые аппаратные платформы, минимальные требования к оборудованию и операционной системе [1].

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

В качестве альтернатив рассмотрим следующие СУБД:

DB2;

Oracle;

Microsoft SQL Server;

MySQL;

PostgreSQL.

Сравним выбранные СУБД по критерию «Структура данных».

Все рассматриваемые альтернативы реализуют реляционную модель данных (РСУБД) или объектно-реляционную модель данных (ОРСУБД), следовательно, все рассматриваемые системы подходят для анализа и сравнения. Проводится анализ рассматриваемых альтернатив по предусмотренным типам данных. По результатам этого анализа можно построить матрицу попарных сравнений альтернатив по первому критерию (таблица 1.2), рассчитать вектор приоритетов, главное собственное значение и остальные показатели [3].

Таблица 1.2

Матрица попарных сравнений альтернатив по критерию «Структура данных»

	DB2	Oracle	MySQL	MS SQL	Postgre SQL
DB2	1	1	1	1	1
Oracle	1	1	1/4	1/5	1/3
MySQL	1	4	1	1/2	2
MS SQL	1	5	2	1	2
Postgre SQL	1	3	1/2	1/2	1

Вектор приоритетов: ОД 8 0,08 0,24 0,33 0,17

Главное собственное значение: 5,34. Индекс согласованности (ИС): 0,084. Отношение согласованности (ОС): 0,07. Как видно, ОС в пределах нормы.

Сравним выбранные СУБД по критерию «Функциональные возможности».

Пункт «Триггеры и хранимые процедуры» определяет наличие в некоторой СУБД класса процедур, функций. Триггер -программа базы данных, вызываемая всякий раз при вставке, изменении или удалении строки таблицы. Триггеры обеспечивают проверку любых изменений на корректность, прежде чем эти изменения будут приняты. Хранимая процедура - программа, которая хранится на сервере и может вызываться клиентом. Поскольку хранимые процедуры выполняются непосредственно на сервере баз данных, обеспечивается более высокое быстродействие, нежели при выполнении тех же операций средствами клиента БД [1]. Проведем анализ альтернатив по данному пункту (таблица 1.3).

Таблица 1.3

Анализ альтернатив по пункту «Триггеры и х ранимые процедуры»

	Триггер	Функция	Процедура
DB2	+	+	+
Microsoft SQL Server	+	+	+
MySQL	+	+	+
Oracle	+	+	+
PostgreSQL	+	+	+

Пункт «Масштабируемость» предполагает возможности рассматриваемой СУБД по увеличению объема данных со временем и в случае необходимости [4]. Необходимо рассмотреть максимально возможный объем хранимых данных для каждой альтернативы (таблица 1.4).

Таблица 1.4

Анализ альтернатив по пункту «Масштабируемость»

	Размер БД	Размер таблицы	Размер строки
DB2	512ТБ	512 ТБ	32677 В
Microsoft SQL Server		524258 ТБ	524258 ТБ	∞
MySQL		∞	256ТВ	64KB
Oracle		∞	4 Гб* Размер блока	8KB
Postgre SQL		∞	32 ТБ	1,6 ТБ

Таким образом, проведен анализ рассматриваемых альтернатив по пунктам критерия «Функциональные возможности». По результатам анализа можно построить матрицу попарных сравнений альтернатив по второму критерию (таблица 1.5, рассчитать вектор приоритетов и основные показатели.

Таблица 1.5

Матрица попарных сравнений альтернатив по критерию «Функциональные возможности»

	DB2	Oracle	MySQL	MS SQL	Postgre SQL
DB2	1	1/4	2	1/7	1/5
Oracle	4	1	1	1/4	1/2
MySQL	1/2	1	1	1/4	1/2
MS SQL	7	4	4	1	3
Postgre SQL	5	2	2	1/3	1

Вектор приоритетов: 0,07 0,13 0,09 0,49 0,22

Главное собственное значение: 5,45. Индекс согласованности (ИС): ОД 11. Отношение согласованности (ОС): 0,09.

Рассмотрим критерий «Особенности разработки приложений». При рассмотрении этого критерия необходимо оценить трудозатраты на администрирование баз данных. Основные задачи такого администрирования: установка и конфигурирование базы данных, текущее администрирование базы данных, резервное копирование/восстановление [5].

Таким образом можно построить матрицу попарных сравнений альтернатив по третьему критерию (таблица 1.6), рассчитать вектор приоритетов и основные показатели.

Таблица 1.6

Матрица попарных сравнений альтернатив по критерию «Особенности разработки приложений»

	DB2	Oracle	MySQL	MS SQL	Postgre SQL
DB2	1	1	1	1/6	1
Oracle	1	1	1	1/4	1
MySQL	1	1	1	1/4	1
MS SQL	6	4	4	1	3
Postgre SQL	1	1	1	1/3	1

Главное собственное значение: 5,04. Индекс согласованности (ИС): 0,01. Отношение согласованности (ОС): 0,01.

Сравним выбранные СУБД по критерию «Производительность».

Для тестирования производительности применяются различные средства, и существует множество тестовых рейтингов. Одним из самых популярных и объективных является ТРС-анализ производительности систем. Показатель ТРС - это отношение количества запросов, обрабатываемых за некий промежуток времени, к стоимости всей системы. Следует отметить, что для СУБД PostgreSQL не проводится тест ТРС, а система MySQL проводит собственные тесты производительности. Результаты теста производительности ТРС-С представлены в таблица 1.12 [6].

Таблица 1.7

Результаты теста TPC

Название	Количество транзакций, tpmC	Стоимость транзакции, долл./tpmC	Монитор транзакций
Microsoft SQL Server 2005 х64	661,475	1.16USD	Microsoft COM+
Oracle Database Standard	631,766	1.08 USD	Microsoft COM+
IBM DB2 9.5	1,200,011	1.99 USD	Microsoft COM+

По имеющимся данным оценим рассматриваемые СУБД по критерию «Производительность», построим матрицу попарных сравнений альтернатив (таблица 1.8).

Таблица 1.8

Матрица попарных сравнений альтернатив по критерию «Производительность»

по	DB2	Oracle	MySQL	MS SQL	Postgre SQL
DB2	1	4	5	3	5
Oracle	1/4	1	3	1/2	3
MySQL	1/5	1/3	1	1/4	1
MS SQL	1/3	2	4	1	4
Postgre SQL	1/5	1/3	1	1/4	1

Вектор приоритетов: 0,47 0,15 0,07 0,24 0,07

Главное собственное значение: 5,14. Индекс согласованности (ИС): 0,036. Отношение согласованности (ОС): 0,03.

Рассмотрим критерий «Требования к рабочей среде». В таблица 1.9 приводятся результаты анализа альтернатив по критерию «Поддерживаемые операционные системы» [3].

Таблица 1.9

Поддерживаемые ОС рассматриваемых систем

	DB2	MS SQL Server	MySQL	Oracle	Postgre SQL
Windows	+	+	+	+	+
Mac OS	+	+	+	+	+
Linux	+	+	+	+	+
BSD	-	+	+	-	+
UNIX	+	+	+	+	+
AmigaOS	-	+	+	-	-
Symbian	-	+	+	-	-

Оценим рассматриваемые СУБД относительно критерия «Требования к рабочей среде», построим матрицу попарных сравнений альтернатив (таблица 1.10).

Таблица 1.1

Матрица попарных сравнений альтернатив по критерию «Требования к рабочей среде»

	DB2	Oracle	MySQL	MS SQL	Postgre SQL
DB2	1	1	1/4	1/4	1/3
Oracle	1	1	1/4	1/4	1/2
MySQL	4	4	1	1	3
MS SQL	4	4	1	1	3
Postgre SQL	3	2	1/3	1/3	1

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

Построим матрицу попарных сравнений критериев (таблица 1.16), для удобства пронумеруем критерии от 1 до 5.

Таблица 1.2

Матрица попарных сравнений критериев

	1	2	3	4	5
1	1	1	1/2	1/6	1/4
2	1	1	1/2	1/6	1/3
3	2	2	1	1/5	1/2
4	6	6	5	1	2
5	4	3	2	1/2	1

Вектор приоритетов альтернатив: 0,07 0,07 0,12 0,49 0,25

Главное собственное значение: 5,03. Индекс согласованности (ИС): 0,01. Отношение согласованности (ОС): 0,01.

Таким образом, веса рассматриваемых СУБД распределены следующим образом: MySQL (0.32), DB2 (0.28), MS SQL Server (0.16), Oracle (0.13), PostgreSQL (0.11).(рисунок 1.10).

Рисунок 1.8 Результаты анализа СУБД

На основании данного сравнения выбираем для использования СУБД MySQL.

Глава 2. ПРОЕКТНАЯ ЧАСТЬ. Информационное обеспечение задачи

2.1. Информационная модель и её описание

Серверная часть проекта базируется на СУБД SQL Server 2005. SQL Server - система управления реляционными базами данных, разработанная корпорацией Microsoft. Основной используемый язык запросов — Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для работы с базами данных размером от персональных до крупных баз данных масштаба предприятия.

Для обеспечения доступа к данным Microsoft SQL Server поддерживает Open Database Connectivity (ODBC) — интерфейс взаимодействия приложений с СУБД. Версия SQL Server 2005 обеспечивает возможность подключения пользователей через веб-сервисы, использующие протокол SOAP. Это позволяет клиентским программам, не предназначенным для Windows, кроссплатформенно соединяться с SQL Server. Компания Microsoft также выпустила сертифицированный драйвер JDBC, позволяющий приложениям под управлением Java (таким как BEA и IBM WebSphere) соединяться с Microsoft SQL Server 2000 и 2005.

Для создания серверной части была создана новая база данных Avers. Размер файла данных обозначен в 20 мб, файл лога в 3 мб. Имеется возможность работать сразу нескольким пользователям с таблицами БД. Данная БД совместима только с SQL Server 2005. Все остальные параметры были оставлены по умолчанию.

В следствии использования для клиентской части MS Access 2007, AllFusion ERwin Data Modeler не имел возможности перенести данные в данную версию (ERwin интегрирует данные в MS Access 2000/2002/2003). В результате не было возможности использовать AllFusion ERwin Data Modeler для переноса данных и таблицы. В результате в БД были созданы новые таблицы, идентичные таблицам в AllFusion ERwin Data Modeler.

Для создания таблицы, необходимо открыть раздел "Tables" и вызвать меню "New Table...". В Microsoft SQL Server получили необходимые таблицы(рис.3.1.1). Ключевые поля полностью соответствуют аналогичным полям в ERwin. Все поля, кроме ключевых, не должны иметь пустых значений.

Рис.3.1.1. Перенесенные таблицы.

Затем между таблицами были обозначены и проведены связи(рис. 3.1.2).

Рис.3.1.2 Диаграмма связей между таблицами.

Для установки и использования этой БД, необходимо скопировать файлы "Avers.mdf" и " Avers_log.ldf" в директорию местонахождения БД в SQL Server. По умолчанию это C:\Program Files\Microsoft SQL Server\MSSQL.1\ MSSQL\Data. Затем необходимо запустить SQL Server, выбрать раздел "Database" и в контекстном меню выбрать пункт "Attach". В появившемся окне необходимо нажать кнопку "Add" и выбрать файл "Avers.mdf" и нажать "Ok" (рис 3.1.3).

Рис.3.1.3 Импорт БД.

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

Для клиентской части использовался MS Access 2003. Microsoft Access — реляционная СУБД корпорации Microsoft. Имеет широкий спектр функций, включая связанные запросы, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных.

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

Все таблицы связаны связями типа «один-ко-многим» или «один – к -одному» с обеспечением целостности данных(рис.3.1).

Рис 3.1. Связи между таблицами

При запуске АИС пользователь оказывается в главном меню программы (рис. 3.2).

Рис 3.2. Главное окно программы

Менеджер, работая с программой, может внести информацию о новом клиенте, добавить новый заказ, а так же редактировать ранее введенную информацию. Чтобы добавить нового клиента, следует щелкнуть на соответствующей кнопке. Откроется окно добавления нового клиента (рис. 3.3):

Рис 3.3. Окно добавления нового клиента

При нажатии на кнопку «Оформить заказ» внизу окна происходит переход на форму внесения данных о новом заказе (рис. 3.4):

Рис 3.3. Ввод нового заказа

В случае, если с системой работает работник цеха, то он может внести данные о этапе работы с заказом нажав на кнопку «Внести данные о этапе» в главном меню программы (рис 3.4)

Рис 3.4. Ввод данных о этапе выполнения заказа

Работник так же может вносить данные об используемых для выполнения заказа на этапах материалах. Для этого необходимо перейти на форму внесения материалов, нажав на кнопку «Оформить материалы» в главном меню, или на кнопку «Внести материалы» с формы заполнения данных о этапе работы (рис.3.5).

Рис 3.5. Ввод данных об используемых материалах

После заполнения полей о количестве и стоимости одной штуки материалов следует нажать на кнопку «рассчитать сумму», что приведет к автоматическому заполнению поля «сумма» данными, рассчитанными с использованием данных из ранее упомянутых полей.

Главный технолог предприятия, работая с данным приложением, может вносить данные о результатах сквозного контроля качества выполнения этапов заказа. Для этого в главном меню необходимо нажать кнопку «Внести данные о контроле» после чего откроется форма внесения данных о контроле(рис.3.6).

Рис 3.6. Ввод данных об используемых материалах

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

Рис 3.7. Отчет о прохождении контроля

Так же главный технолог может вносить данные о реализации заказа, перейдя по кнопке «Реализация» главного меню.(рис3.8).

Рис.3.8. Ввод данных о реализации.

При нажатии кнопки «Отчеты» откроется форма с возможными отчетами (рис.3.9)

Рис 3.9. Форма отчеты

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

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

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

Запрос «Выполненные заказы» (рис.3.10) находит информацию о всех реализованных заказах. Результат запроса представлен в виде формы, просмотреть которую можно нажав на кнопку «Выполненные заказы» формы «Отчеты»(рис.3.11).

Рис.3.10.Запрос «Выполненные заказы»

Рис.3.11.Форма «Выполненные заказы»

Запрос по оценке контроля (рис.3.12.) ищет все работы, оценка контроля которых соответствует выбранному варианту на форме «Отчеты». После выбора интересующей оценки на данной форме и нажатия кнопки «Отчет по оценки контроля» предоставляется отчет(рис.3.13) с соответствующей информацией.

Рис3.12.Запрос по оценке контроля

Рис.3.13.Отчет по оценке контроля

Так же представлены отчеты предоставляющие список используемых материалов как для всего заказа в целом (рис.3.14.) так и для отдельного этапа заказа (рис.3.15.)

Рис.3.14. Отчет «Материалы для заказа»

Рис.3.15.Отчет «материалы для этапа заказа»

Эти отчеты основаны на запросах материалы для заказа (рис.3.16.) и материалы для этапа заказа (рис.3.17).

Рис.3.16.Запрос «Материалы для заказа»

Рис.3.17.Запрос материалов на этап закзаза

При оформлении и реализации заказа необходимо документальное подтверждение. Для организации отчетов «Оформление заказа» и «Оформление реализации заказа» реализуются соответствующие запросы (рис.3.18-3.19) Для распечатки данных отчетов(рис.3.20-3.21) на форме «Отчеты» необходимо ввести номер заказа, на который необходимо распечатать отчет и нажать на соответствующую кнопку.

Рис3.18.Запрос «Оформление заказа»

Рис.3.19.Запрос «Реализация заказа»

Рис.3.20.Отчет об оформлении заказа

Рис.3.21.Отчет о реализации заказа.

Так же реализован запрос о прохождении стадий контроля определенным заказом (рис.3.22). Интересующий заказ выбирается на форме «Отчеты» и после нажатия на кнопку «Прохождение заказом контроля» будет предоставлен отчет в виде формы (рис.3.23.).

Рис.3.22.Запрос о прохождении стадий контроля

Рис.3.23.Очет о прохождении заказом стадий контроля

В АИС «Аверс» для расчета полной стоимости заказа необходимо определить стоимость используемых для выполнения заказа материалов, для этого устраивается запрос «стоимость материалов» основанные на запросе «материалов для заказа»(рис.3.16), результаты которого находятся в форме (рис3.24.).

Рис.3.24.Стоимость используемых для заказа материалов

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

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

Работу с системой осуществляет менеджер отдела продаж. Дерево функций системы представлено на рисунке 2.2.

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

Основным документом является счет-фактура, которая формируется по факту продаж и служит основным отчетным документом.

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

Сценарии диалога, формирующийся на основе дерева функций, приведен на рис. 2.3.

Рис. 2.2 Сценарий диалога для пользователя

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

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

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

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

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

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

Рис. 2.3 ER-диаграмма базы данных

Описание каждой таблицы базы данных приведено ниже.

Таблица 2.2

Структура таблицы Счет-фактуры

Поле	Тип	Описание поля	Null	По умолчанию
idchet	int(11)	Код записи	Нет
Продолжение таблицы 2.4
idklientchet	int(11)	Код клиента	Нет
idprodchet	int(11)	Код продукции	Нет
kolvochet	int(11)	Количество	Нет
datechet	text	Дата	Нет
Nomer	int(11)	Номер счет-фактуры	Нет

Таблица 2.3

Структура таблицы Типы товаров

Поле	Тип	Описание поля	Null	По умолчанию
iddolg	int(11)	Код записи	Нет
namedolg	varchar(45)	Наименование типа	Да	NULL
udald	int(1)	Флаг удаления	Нет	0

Таблица 2.4

Структура таблицы Клиенты

Поле	Тип	Описание поля	Null	По умолчанию
idKlient	int(11)	Код записи	Нет
namekl	varchar(255)	Наименование	Да	NULL
krnamekl	varchar(45)	Краткое наименование	Да	NULL
adresskl	varchar(45)	Адрес фактический	Да	NULL
uradrkl	varchar(45)	Адрес юридический	Да	NULL
banrekKl	varchar(45)	Банк	Да	NULL
kontlizoKl	varchar(45)	Контактное лицо	Да	NULL
tlfKl	varchar(45)	телефон	Да	NULL
emailKl	varchar(45)	Email	Да	NULL
dateregKl	timestamp	Дата регистрации	Нет	CURRENT_TIMESTAMP
tipkl	int(1)	Тип клиента	Нет
udalKl	int(1)	Флаг удаления	Нет	0
nameorg	varchar(255)	Наименование оргформы	Нет
login	varchar(25)	Логин	Нет
parol	varchar(25)	Пароль	Нет
tel	varchar(30)	Доп. Телефон	Нет	0
opistel	varchar(100)	Описание доп. Телефона	Нет	0
adres	varchar(255)	Адрес доп.	Нет	0
email	varchar(30)	Email доп.	Нет	0
opisemail	varchar(100)	Описание	Нет	0
Продолжение таблицы 2.6
namec	varchar(255)	Наименование дополнительного контакта	Нет	0
idconka	int(11)	Описание дополнительного контакта	Нет

Таблица 2.5

Структура таблицы Группы товаров

Поле	Тип	Описание поля	Null	По умолчанию
ido	int(100)	Код записи	Нет
nameob	varchar(255)	Наименование группы товаров	Нет
udalo	int(1)	Флаг удаления	Нет	0

Таблица 2.6

Структура таблицы Персоны

Поле	Тип	Описание поля	Null	По умолчанию
idper	int(11)	Код записи	Нет
firma	int(11)	Код клиента	Нет
namep	varchar(255)	Фамилия	Нет
imap	varchar(255)	Имя и отчество	Нет
datep	text	Дата	Нет
dolgp	int(11)	Должность	Нет
telp	varchar(255)	Телефон	Нет
emailp	varchar(255)	Email	Нет
primp	text	Примечание	Нет
udalp	int(1)	Флаг удаления	Нет	0

Таблица 2.7

Структура таблицы Товары

Поле	Тип	Описание поля	Null	По умолчанию
idprod	int(11)	Код записи	Нет
nameprod	text	Наименование	Да	NULL
art	varchar(45)	артикул	Да	NULL
idvz	int(11)	Код группы	Да	NULL
idtz	int(11)	Код типа	Да	NULL
model	varchar(255)	Модель	Да	NULL
prise	varchar(45)	Стоимость	Да	NULL
primP	text	Примечание	Да	NULL
udalPr	int(1)	Флаг удаления	Нет
optst	varchar(255)	Стоимость опт	Нет
Продолжение таблицы 2.9
rozst	varchar(255)	Стоимость розница	Нет
edizmpr	varchar(255)	Единица измерения	Нет

Таблица 2.8

Структура таблицы Менеджеры

Поле	Тип	Описание поля	Null	По умолчанию
idsotr	int(11)	Код записи	Нет
name	varchar(45)	Фамилия	Да	NULL
dolg	varchar(45)	Должность	Да	NULL
login	varchar(45)	Логин	Да	NULL
parol	varchar(45)	Пароль	Да	NULL
dates	timestamp	Дата регистрации	Нет	CURRENT_TIMESTAMP
surname	varchar(45)	имя, отчество	Да	NULL
datebor	varchar(45)	Дата рождения	Да	NULL
udal	int(1)	Флаг удаления	Нет

Таблица 2.9

Структура таблицы Типы оргформ

Поле	Тип	Описание поля	Null	По умолчанию
idtipagent	int(11)	Код записи	Нет
nametipagent	varchar(255)	Наименование	Нет
krnametipagent	varchar(255)	Краткое наименование	Нет
udalnametipagent	int(1)	Флаг удаления	Нет	0

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

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

Система состоит из двух основных модулей – базы данных MySQL и приложения для взаимодействия с базой данных, реализованного на языке программирования PHP и c использованием HTML.

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

Структурная схема пакета представлена на рис. . 2.5.

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

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

Таблица 2.3

Характеристика программных модулей

№ п/п	Наименование модуля	Функции модуля
	ПМ загрузка главного меню	Содержит процедуры, позволяющие сформировать главное меню
	ПМ формирования подменю учета продаж	Содержит предопределенные процедуры формы списка и элемента подменю работы со документами учета продаж
	ПМ формирования счетов-фактур	Содержит предопределенные процедуры, позволяющие учесть продажу
	ПМ поиска	Содержит предопределенные процедуры, позволяющие получить результаты поиска
	ПМ отчетов	Содержит предопределенные процедуры, позволяющие получить отчеты
	ПМ оборотов	Содержит предопределенные процедуры, позволяющие получить отчет по оборотам
	ПМ печати документов	Содержит предопределенные процедуры, позволяющие отправить на печать сформированный документ
Продолжение таблицы 2.12
	ПМ экспорта в MS Excel	Содержит предопределенные процедуры, позволяющие экспортировать сформированный документ в файл MS Excel
	ПМ формирования подменю работы со справочниками	Содержит предопределенные процедуры формы списка и элемента подменю работы со справочниками
	ПМ справочника Клиенты, Товары, Типы товаров, Группы товаров, Типы оргформ, Менеджеры	Содержит предопределенные процедуры, позволяющие добавлять, удалять, редактировать записи в справочнике Клиенты, Товары, Типы товаров, Группы товаров, Типы оргформ, Менеджеры, а также осуществлять поиск
	ПМ Администрирования	Содержит предопределенные процедуры, позволяющие формировать подменю настроек системы
	ПМ Настройки	Содержит предопределенные процедуры, позволяющие определять основные настройки системы
	ПМ Локализация	Содержит предопределенные процедуры, позволяющие определять настройки локализации системы
	ПМ Метаданные	Содержит предопределенные процедуры, позволяющие определять настройки метаданных системы
	ПМ обмена данными с 1С	Содержит предопределенные процедуры, позволяющие определять настройки по обмену с 1С

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

Схема описания работы программного модуля представляет собой блок-схему и состоит из:

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

Схема модуля учета товаров приведена на рис. 2.6.

Рисунок 2.5 Схема программного модуля

Листинг программных модулей приведен в Приложении.

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

В данном пункет рассмотрим контрольны пример работы системы учета продаж.

После прохождения авторизации пользователю необходимо произвести первоначальное заполнение справочников (рисунок 2.7).

Рисунок 2.6 Учет типов обуви

Справочник Типы обуви хранит информацию о типах обуви. Для формирования справочника Товары также необходимо заполнить Справочник Группы обуви.

Рисунок 2.7 Справочник Группы товаров

Справочник товаров хранит информацию о товарах, а именно об обуви, которая находится в ассортименте торгового дома.

Рисунок 2.8 Экранная форма для заполнения справочника Товары

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

Рисунок 2.9 Список товаров

Для учета продаж также необходим учет клиентов (рисунок 2.11)

Рисунок 2.10 Учет клиентов

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

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

Рисунок 2.11 Список клиентов

Рисунок 2.12 Список контактов

Рисунок 2.13 Список персон для ЗАО «Удача»

При наличии данной информации появляется возможность учета продаж путем формирования счет-фактуры (рисунок 2.15).

Рисунок 2.14 Экранная форма учета продаж

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

Рисунок 2.15 Создание счет-фактуры

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

Рисунок 2.16 Формирование счет-фактуры

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

Рисунок 2.17 Список счет-фактур

Нажав на иконку с изображением документа, можно просмотреть его содержание (рисунок 2.19).

Рисунок 2.18 Содержание счет-фактуры

При этом подсчитываются итоги в виде количества наименований и общей стоимости реализованного товара.

Заключение

В ходе выполнения курсовой работы были достигнутые поставленные цели, такие как: применение на практике знаний, полученных в процессе изучения курса «Проектирование ИС» и получение практических навыков создания автоматизированных информационных систем (АИС), основанных на БД.

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

Список использованной литературы

1. Введение в системы баз данных – СПб: Издательский дом "Вильямс", 2013. - 848 с.;
2. Вендров А.М., CASE-технологии. Современные методы и средства проектирования информационных систем - М.: Финансы и статистика, 2016.
3. Гаджинский А.М. Основы логистики: Учеб.пособие/ Инфоpм.-внедpен.центp "Маpкетинг".- М., 2015.- 121, с.: ил., табл.
4. Дейв Крейн, Эрик Паскарелло, Даррен Джеймс. AJAX в действии: Учебник – М.: Вильямс, 2016. 450 – 490 с.
5. Джексон Г. Проектирование реляционных баз данных для использования с микро-ЭВМ М.: Финансы и статистика, 2011.
6. Диго С.М. Базы данных: проектирование и использование: Учебник. – М.: Финансы и статистика, 2015. – 592 с.
7. Дэвид Флэнаган. JavaScript. Подробное руководство: Учебник – М.: Символ Плюс, 2015. 243 – 249 с.
8. Зеленков Ю.А. Введение в базы данных. Центр Интернет ЯрГУ, 2016.
9. Зелковиц М., Шоу А., Гэннон Дж. Принципы разработки программного обеспечения / Пер. с англ. — М.: Мир, 2012. — 386 с., ил.
10. Ивлиев М.К., Порошина Л.А. Автоматизация оперативного и бухгалтерского учета товаров, 2014.
11. Информационные системы: Учебник для вузов. 2-е изд. СПб: "Питер", 2015 г - 656 стр.
12. Керри Н. Праг, Майкл Р. Ирвин, Access 2000 - Библия пользователя, Диалектика, 2014.
13. Крис Дейт. Введение в базы данных, 6-е изд. Киев, Диалектика, 2014.
14. Кристиан Дари, Богдан Бринзаре, Филип Черчез-Тоза, Михай Бусика. AJAX и PHP. Разработка динамических веб-приложений: Учебник – М.: Символ Плюс, 2016.
15. Лифшиц Н.И., Левин Е.Т Механизация и автоматизация процессов отборки и комплектования заказов на складах М., 2014.
16. Практическое руководство по программированию / Пер. с англ. Б. Мик, П. Хит, Н. Рашби и др.; под ред. Б. Мика, П. Хит, Н. Рашби. — М.: Радио и связь, 2014. — 168 с., ил.
17. Проектирование и использование баз данных: Учебник. М.:Финансы и статистика, 2015г. – 191 с.;
18. Разработка программного обеспечения - СПб : "Питер", 2014 г - 592 стр.
19. Реляционные базы данных: практические приемы оптимальных решений. – СПб.: БХВ-Петербург, 2015 – 400с.:ил;
20. Симионов Ю.Ф., Боромотов В.В. Информационный менеджмент. — Ростов н.Д: Феникс, 2016, 250с., ил.;
21. Фокс Дж. Программное обеспечение и его разработка / Пер. с англ. — М.: Мир, 2015. - 368 с., ил.
22. Язык компьютера. Пер. с англ, под ред. и с предисл. В. М. Курочки-на. — М.: Мир, 2016. - 240 с., ил. Глушаков С.В., Ломотько Д.В. Базы данных, 2000.