Окраска автомобилей

Автор работы: Пользователь скрыл имя, 29 Ноября 2014 в 12:48, курсовая работа

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

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

Содержание

ВВЕДЕНИЕ………………………………………………………………….5
1. ПРЕДПРОЕКТНАЯ СТАДИЯ…………………………………………..6
1.1 Описание предметной области…………………………………………6
1.2 Разработка функциональной модели предметной области…………..11
1.3 Построение UML диаграмм в среде Pacestar UML Diagrammer……..13
2. СТАДИЯ ПРОЕКТИРОВАНИЯ…………………………………………15
2.1 Выбор программных средств разработки……………………………...15
2.2 Разработка логической модели……………………………………….…15
2.3 Разработка физической модели……………………………………..….16
3. РЕАЛИЗАЦИЯ ПРОЕКТА……………………………………………….18
3.1 Серверная часть………………….………………………………………18
3.2 Клиентская часть…………………………………………….…………..20
3.3 Реализация запросов…………………………………………………….25
ЗАКЛЮЧЕНИЕ………………………………………………………………32
СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ……………………………..33

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

сборка курсовой окрас автом.doc

— 625.00 Кб (Скачать файл)

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

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

 

 

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 состоит в построении моделей процессов по принципу последовательно выполняемых во времени работ.

 

 

Рисунок 1.1 - Смешанная диаграмма

 

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

На рисунке 1.3 представлена смешанная диаграмма, которая со всех сторон описывает процесс деятельности предприятия, которая получена дополнением диаграммы IDEF0 диаграммами DFD и IDEF3.

 

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

 

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. Диаграмма компонентов.

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

 

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.

    Информация о работе Окраска автомобилей