АИС поддержки борьбы с аварийными ситуациями в городе

Автор работы: Пользователь скрыл имя, 08 Октября 2013 в 21:08, курсовая работа

Описание работы

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

Содержание работы

ВВЕДЕНИЕ. 3
ГЛАВА 1. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ. 5
1.1.Общие сведения о спасательной службе. 5
1.2 Организационная структура. 11
1.3.Проблемы предметной области, 15
1.3.1Концепция информационной системы. 15
ГЛАВА 2. СОЗДАНИЕ ЧАСТИ АВТОМАТИЗИРОВАННОЙ СХЕМЫ ОБЩЕГО ПРОЕКТА. 18
2.1. Создание модели информационных процессов в BPwin 18
2.2. Принцип построения модели DFD. 29
ГЛАВА 3. РЕАЛИЗАЦИЯ АВТОМАТИЗИРОВАННОГО ПРОГРАММНОГО ПРОДУКТА С ПОМОЩЬЮ СРЕДСТВ VISUAL STUDIO С ПОДКЛЮЧЕНИЕМ SQL SERVER. 35
3.1. Построение модели базы данных службы спасения. 35
3.2. Определение требований к базе данных. 42
3.3 Описание подключения базы данных Access 2007 в SQL Management Studio 43
ЗАКЛЮЧЕНИЕ.

Файлы: 1 файл

Пример работы.doc

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

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

    • внешние сущности;
    • системы/подсистемы;
    • процессы;
    • накопители данных;
    • потоки данных.

Нотация DFD включает такие  понятия, как внешняя ссылка и  хранилище данных, что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота.

 

2.3. Принцип построения модели IDEF3.

 

Для описания процессов  в виде последовательности событий  или работ был разработан способ описания процессов IDEF3.

 

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

 

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

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

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

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

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

Диаграмма декомпозиции А122.1:

Рис.10 Осуществление инструктажа  работников.

 

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

 Типы перекрестков 

 

 

Обозначение

 

Наименовани

Смысл в случае слияния  стрелок (Fan-in Junction)

Смысл в случае

разветвления стрелок (Fan-out Junction)

||&

Asynchronous AND

Все предшествующие процессы должны быть завершены

Все следующие процессы должны быть запущены

||&||

Synchronous AND

Все предшествующие процессы завершены одновременно

Все следующие процессы запускаются одновременно

||O

Asynchronous OR

Один или несколько  предшествующих процессов должны быть завершены

Один или несколько  следующих процессов должны быть запущены

||O||

Synchronous OR

Один или несколько  предшествующих процессов завершены  одновременно

Один или несколько  следующих процессов запускаются  одновременно

||X

XOR

(Exclusive OR)

Только один предшествующий процесс завершен

Завершен Только один следующий процесс запускается


 

Все перекрестки на диаграмме  нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Definition Editor. В отличие от IDEFO и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки.

Объект ссылки. Объект ссылки в IDEF3 выражает некую идею, концепцию  или данные, которые нельзя связать  со стрелкой, перекрестком или работой. Для внесения объекта ссылки служит кнопка |R| – (добавить в диаграмму объект ссылки - Referent) в палитре инструментов. Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы. Имя объекта ссылки задается в диалоге Referent (пункт всплывающего меню Name Editor), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок – безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются.

Глава 3. Реализация автоматизированного программного продукта  с помощью средств VISUAL STUDIO с подключением  SQL SERVER.

  • 3.1. Построение модели базы данных  службы спасения.

 

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

Целью разработки любой  базы данных является хранение и использование информации о какой-либо предметной области.

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

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

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

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

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

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

ERwin имеет два уровня  представления модели – логический  и физический. На логическом уровне  данные не связаны с конкретной  системой управления данными.  Физический уровень данных –  это по существу отображение  системного каталога, который зависит от конкретной реализации системы управления базой данных. Для создания моделей данных в Erwin используются две методологии: IDEF1X и IE.

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

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

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

Данная логическая модель имеет следующую структуру:

Рис. 12 структурная таблица  «Вызов»

 

Рис.13 Структурная таблица  «Дежурство»

Рис.14 Структурная таблица  «Имущество»

 

 

 

Рис.15 Структурная таблица  «Карьера»

Рис.16 Структурная таблица  «Оператор»

 

 

 

Рис.17 Структурная таблица  «Отчет»

       

Рис.18 Структурная таблица  «Позвонивший»

 

Рис.19 Структурная таблица  «Сотрудник»

 

Рис.20 Структурная таблица  «Сотрудник осн»

 

Рис.21 Структурная таблица  «Спасатель»

 

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

   

  • 3.2. Определение  требований к базе данных.

 

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

     Хорошо  спроектированная база данных  должна выполнять следующие требования:

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

 

 

 

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

  • 3.3 Описание подключения базы данных Access 2007 в SQL Management Studio

 

 

1. Проверка базы данных системой  безопасности.

 

Рис.22 Подключения базы данных Access 2007 в SQL

Рис. 23 Мастер преобразования баз данных.

С его помощью можно создать  новую базу данных или использовать существующую. В нашем случае необходимо создать новую базу данных.

Рис. 24 Создание новой базы данных.

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

 

Рис.25 Экспорт таблиц в базу данных SQL.

При нажатии двойной стрелки  все компоненты таблиц БД экспортируются в БД SQL Server и окно мастера преобразований примет вид как изображено на рисунке

Завершение экспорта таблиц в базу данных SQL.

Убедившись, что все компоненты перенесены в SQL Server нажимаем кнопку «Далее».

Рис.26 Преобразование атрибутов данных и таблиц.

Указываем какие атрибуты необходимо преобразовать и нажимаем «далее»

В данном окне можно выбрать какие изменения можно внести в приложение. Создать новое приложение, связать таблицы с существующим приложение или не менять приложение. Выбираем «вязать таблицы с существующим приложением» и жмем «Далее».

 

Рис.27 Мастер преобразования в формат SQL

В данном окне мастер информирует  нас о том что все необходимые  свендения получены для преобразования базы данных. Наживаем «Готово»

Рис.28 Мастер преобразования в формат SQL

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

Мастер преобразования в формат SQL

Рис. 29. Мастер преобразования в формат SQL

Завершающий этап работы мастера. Вывод  отчета.

 

3.4 Разработка  программной среды

 

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

Информация о работе АИС поддержки борьбы с аварийными ситуациями в городе