СОДЕРЖАНИЕ

Введение

1. Предпроектная  стадия

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

1.2 Разработка функциональной модели предметной области

1.3 Построение UML диаграмм в среде Pacestar UML Diagrammer

2. СТАДИЯ ПРОЕКТИРОВАНИЯ

2.1 Выбор программных средств разработки

2.2 Разработка логической модели

2.3 Разработка физической модели

3. РЕАЛИЗАЦИЯ ПРОЕКТА

3.1 Серверная часть

3.2 Клиентская часть

3.3 Реализация запросов

4. ЭКСПЛУАТАЦИЯ И СОПРОВОЖДЕНИЕ ПРОЕКТА

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

Приложение 1

Введение

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

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

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

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

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

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

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

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

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

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

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

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

o           диаграмма 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 диаграмм в среде Pacestar UML Diagrammer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. СТАДИЯ ПРОЕКТИРОВАНИЯ

2.1 Выбор программных средств разработки

программный разработка приложение access

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

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

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

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

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

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

5.   СУБД: MS SQL Server 2005.

6.    MS office Access 2003 и выше

2.2 Разработка логической модели

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

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

·          Клиент. Атрибуты клиента – код клиента, ФИО, телефон, адрес;

·          Заказ. Атрибуты заказа – код заказа, дата заказа, автомобиль наименование детали, вид работы, цвет, стоимость;

·          Материалы. Атрибуты Материалов – код материала, тип материалов, наименование, количество, стоимость, сумма;

·          Персонал. Атрибуты персонала - код работника, ФИО, адрес, телефон, должность;

·          Этап работы. Атрибуты этапа работы - код этапа работы, наименование этапа, дата начала этапа;

·          Контроль. Атрибуты контроля – код контроля, дата контроля;

·          Вид контроля. Атрибуты вида контроля – вид контроля, комментарии;

·          Оценка. Атрибуты оценки – оценка, комментарии;

·          Реализация. Атрибуты реализации – код реализации, дата реализации, стоимость всего заказа;

Рис 2.1. Логическая модель данных

2.3 Разработка физической модели

 

Физическая модель данных зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т.д. Полученная физическая модель для СУБД MS SQL Server 2005представлена на рис.2.2.

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

Рис 2.2. Физическая модель данных

3. РЕАЛИЗАЦИЯ ПРОЕКТА

3.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 Импорт БД.

3.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. Форма отчеты

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

3.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.Стоимость используемых для заказа материалов

4. ЭКСПЛУАТАЦИЯ И СОПРОВОЖДЕНИЕ ПРОЕКТА

АИС «Аверс» имеет элементарный и легкодоступный интерфейс, что упрощает работу с ней.

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

ЗАКЛЮЧЕНИЕ

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

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

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1.         Заботина Н.Н. Проектирование информационных систем: Учебное пособие / Заботина Н.Н. –Братск: Филиал ГОУВПО «БГУЭП», 2007. – Ч.1 – 146 с.

2.         Заботина Н.Н. Проектирование информационных систем: Учебное пособие / Заботина Н.Н. –Братск: Филиал ГОУВПО «БГУЭП», 2007. – Ч.2 – 132 с.

3.         Мартин Ф., Кендалл С. UML Основы / Ф.Мартин, С.Кендалл. – СПб.:Символ-Плюс, 2002. – 192 с.

4.         Бланшет Ж., Саммерфилд М. Qt 4: программирование GUI на C++ / Ж. Бланшет, М.Саммерфилд. – М.:КУДИЦ-ПРЕСС, 2008. – 736 с.

5.         Арлоу Д., Нейштадт И. UML 2 и Унифицированный процесс / Д. Арлоу, И. Нейштадт. – СПб.: Символ-Плюс, 2007. – 624 с.

СОДЕРЖАНИЕ Введение 1. Предпроектная  стадия 1.1 Описание предметной области 1.2 Разработка функциональной модели предметной области 1.3 Построение UML диаграмм в среде Pacestar UML Diagrammer 2. СТАДИЯ ПРОЕКТИРОВАНИЯ 2.1 Вы

 

• 14:21 05 Июля 2016
  Российско-китайский медуниверситет откроет магистерскую программу по TCM
• 01:21 05 Июля 2016
  На форуме МГУ Россия и Китай обсудят научно-образовательное сотрудничество
• 11:00 04 Июля 2016
  Реморенко: "ЕГЭ-туризм" в России сходит на нет
• 10:52 04 Июля 2016
  Летняя российско-австрийская школа откроется в Москве
• 15:31 01 Июля 2016
  В СПбГУ могут воссоздать географический факультет

Заказать уникальную работу