CASE-технологии разработки информационных систем, Информационные технологии

Содержание

ВВЕДЕНИЕ3

1 Представление и возможности CASE-технологий4

1.1 Понятие CASE-технологии4

1.2 Преимущества и проблемы CASE-технологий5

2 CASE-система Silverrun7

2.1 Контекст использования системы Silverrun7

2.2 Структура и функции Silverrun9

2.3 Взаимодействие с другими средствами10

2.4 Групповая работа и среда функционирования12

2.5 Моделирование процессов12

ЗАКЛЮЧЕНИЕ14

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ15

Выдержка из текста работы

Разработанная информационная система «Авиазавод» уменьшает количество времени на оформления документов, а также позволяет сотрудникам предприятия работать более слаженно и оперативно.

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

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

Проектирование выполнялось с использованием CASE-средств BPWin, ERWin и Rational Software, средства разработки прототипа программного продукта — Borland Delphi 7.0.

1. Информационное проектирование

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

Для построения моделей было использовано CASE-средство ERWin, которое реализует проектирование схемы БД, генерацию её описания на языке целевой СУБД (InterBase).

Рассмотрим инфологическую модель данных, в нотации Чена, рисунок 1.1. Основными элементами инфологической модели являются сущности, связи между ними и их свойства. Сущности изображаются прямоугольниками, ассоциации — ромбами или шестиугольниками, атрибуты — овалами, а связи между ними- направленными рёбрами, над которыми проставлены степени связи (1 или буква «М», заменяющая слово «много») [4].

Рисунок 1.1 — Инфологическая модель в нотации Чена.

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

Рисунок 1.2 — Концептуальная модель данных, на логическом уровне в ERWin

Физический уровень модели данных содержит те же сущности, что и логический уровень, однако модель данных на физическом уровне содержит информацию о всех объектах базы данных, о типе данных каждого из атрибута, отображает представления на английском языке. В каждой из сущностей отображен первичный ключ (обозначен «ключом»). Так же в сущностях имеются атрибуты, являющиеся внешним ключом (обозначены аббревиатурой «FK») [1, с.46].

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

Рисунок 1.3 — Концептуальная модель данных, представленная на физическом уровне в ERWin

2. Структурно-функциональное проектирование

Для дальнейшего создания ИС «Авиазавод», была построена модель бизнес-процесса в нотации IDEF0. В качестве инструмента разработки было использовано CASE-средство BPWin.

Методология функционального моделирования IDEF0 отображается логические отношения между работами.

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

Предметной областью является «Авиазавод». Клиент обращается в АРЗ, делает заказ на ремонт АТ. Данный заказ направляется в цех, который специализируется на определённом виде ремонта. Цех отправляет запрос на склад о наличии необходимой детали. Если необходимой детали нет на складе, то осуществляется закупка нужной детали. Детали для ремонта «АРЗ» закупает у поставщиков. Закупленные детали поступают на склады, за каждым складом стоит зав.складом, в подчинении у которого в порядке 20-30 человек. Со складов деталь поступает в тот цех, который и делал запрос на данную деталь. Затем, производится ремонт авиационной техники. После ремонта заказчик может забрать отремонтированную деталь или самолёт.

На рисунке 2.1 показан основной бизнес-процесс «Авиазавод». Входом в бизнес-процесс «Авиазавод» являются данные о клиентах и данные новых деталях. Управлением является Документация и информация о наличии деталей и стоимости поступивших от поставщиков. Механизмом в данной модели будут сотрудники Авиазавода. Выход — готовые изделия и заказ поставщикам.

Рисунок 2.1 — Основной функциональный блок.

Чтобы получить более подробную модель, декомпозирован процесс «Авиазавод», рисунок 2.2.

Декомпозиция — это система, разбивающаяся на подсистемы, и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности [2, с.97].

На рисунке 2.2 видно, что основной процесс «организация ремонта авиационной техники» декомпозирован на три подпроцесса: Оформление заказа, Выполнение заказа, Подготовка отчётности. Можно увидеть, что управления, входящая, выходящая информация и механизмы тоже более детально разделены.

Рисунок 2.2 — Декомпозиция процесса «Организация ремонта авиационной техники».

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

Рисунок 2.3 — декомпозиция процесса «Оформление заказа».

Рисунок 2.4 показывает декомпозицию процесса «Выполнение заказа». Процесс декомпозирован на три блока: подготовка оборудования к диагностике, диагностика оборудования, проведение технических работ. Входом является установленное оборудование и материалы, а выход — готовые изделия и информация о ремонте.

Рисунок 2.4- декомпозиция процесса «Выполнение заказа».

И заключением диаграммы IDEF0 является декомпозиция процесса «Подготовка отчетности», рисунок 2.5. Процесс также декомпозируется на три блока: подготовка отчетов по выполненным работам, отчет по отдельным типам самолетов и анализ качества поставляемых деталей, входом которого является данных о поступивших деталях и данные о закупленных деталях и материалах. Выход — Готовый отчёт.

Рисунок 2.5 — декомпозиция процесса «Подготовка отчетности».

Диаграмма потоков данных (DFD — Data Flow Diagrams), рисунок 2.6 является основным средством моделирования функциональных требований к проектируемой системе. Требования представляются в виде набора процессов, связанных потоками данных.

· DFD показывает, как каждый процесс выявляет данные (входные выходные) и выявляет отношения между процессами.

· DFD используют для описания документооборота организации и обработки информации.

Основными графическими компонентами DFD являются процессы или работы, внешние сущности, потоки данных и накопители, хранилища данных.

Внешняя сущность представляет собой материальный предмет или физическое лицо, которое является источником или приемником информации. Все сущности всегда находятся за пределами анализируемой системы. Хранилище данных представляет собой абстрактное устройство для хранения информации, которую можно в любой момент поместить в хранилище и через какое-то время извлечь, причем способы помещения и извлечения могут быть любыми. Физически хранилище данных может быть реализовано в виде картотеки, папки с документами, таблицы в оперативной памяти, файлах, базах данных [2, c.166].

На примере работы «Авиазавод» рассмотрим систему поддержки документооборота. Процессом является непосредственно сама система поддержки документооборота авиазавода.

Рисунок 2.6 — Поддержка документооборота авиазавода.

На рисунке 2.7 показана декомпозиция «Поддержки документооборота», с внешними сущностями, БД Договоры и План работ.

Рисунок 2.7 — Декомпозиция процесса «Поддержка документооборота».

3. Объектно-ориентированное проектирование

Следующим этапом создания информационной системы «Авиазавод» будет создание UML-диаграмм, таких как диаграмма прецедентов, диаграмма активности, диаграмма последовательности и диаграмма классов. В качестве инструмента разработки было использовано CASE-средство Rational Rose.

Так как программа является системой, то в ней можно выделить составные части и определить их взаимосвязи. Для таких описаний и используется общепринятый язык UML (Unified Modeling Language). В самых общих чертах, любая информация, записанная на этом языке, представляет собой набор диаграмм, которые довольно легко читаются [3].

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

Рисунок 3.1 — Диаграмма прецедентов «Авиазавод».

Строим диаграмму состояний «Выполнение заказа» (рисунок 3.2).

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

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

Рисунок 3.2 — диаграмма состояний «Выполнение заказа»

Диаграмма последовательности «Выполнение заказа» показана на рисунке 3.3. Диаграмма последовательности упорядочены по времени и она аналогична с диаграммой состояний.

Рисунок 3.3 — Диаграмма последовательности «Выполнение заказа»

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

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

На диаграмме отображено 5 классов:

· Клиент

· Заказ

· Детали

· Склад

· Цеха

Каждый класс содержит свойства с типом данных:

· Клиент (Название:String, Адрес:String, Телефон:String);

· Заказ (Название: String, Дата начала заказа:Date, дата исполнения:Date, дата окончания:Date, стоимость:Integer);

· Детали (Название: String, Количество: Integer, ГОСТ: Integer, Стоимость: Integer);

· Склад (Номер: Integer, Адрес: String, Телефон: String,);

· Цех (Название: String).

Рисунок 3.3 — Диаграмма классов «Авиазавод»

4. Реализация ИС

Реализация информационной системы — завершающий этап проектирования ИС. В качестве инструмента был применен прототип программного продукта — Borland Delphi 7.0.

База данных, хранящаяся в СУБД Interbase, была подключена к объектно-ориентированному языку Delphi 7, затем создана главная форма, на которой расположены инструменты взятые с панели Interbase, такие как IBTable, IBQuery, IBDatabase, IBTransaction; инструмент с панели DataAccess — DataSource и инструмент MainMenu c панели Standart. Затем было создано ещё дополнительно 11 форм для каждого пункта меню. Каждая форма соединена друг с другом путем нажатия комбинации клавиш Alt+F11, после нажатия, которого появляется окно со списком форм не подключенных к главной форме и к другим соответственно. Из этого списка нужно выбрать ту форму (Unit), которую требуется подключить, чтобы продолжить работу с ней. На каждую форму устанавливаются свои инструменты (DBGrid, DBEdit, Label, ComboBox, Button и др.), которые настраиваются в пунктах properties и events. На кнопки, формы прописывается программный код.

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

5. Краткое руководство пользователю по применению разработанной ИС

При запуске программы «Авиазавод» появится окно, которое предлагает начать работу, окно примет вид, приведенный на рисунке 5.1.

Рисунок 5.1 — Интерфейс программы «Авиазавод»

Программа «Авиазавод» имеет 6 вкладок с выпадающим меню, каждое из которых сопровождается рисунком:

1. Клиенты (Рис.5.1.1)

Рисунок 5.1.1 — Клиенты

2. Заказы (рис.5.1.2)

Рисунок 5.1.2 — Заказы

3. Детали (рис 5.1.3)

Рисунок 5.1.3 — Детали

4. Цеха (рис.5.1.4)

Рисунок 5.1.4 — Цеха

5.Отчёты (рис.5.1.5)

Рисунок 5.1.5 — Отчеты

6. Справка (рис.5.1.6)

Рисунок 5.1.6 — Справка

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

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

Рисунок 5.2 — Окно «Информация о клиентах»

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

Рисунок 5.3 — Окно «Список заказов»

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

Рисунок 5.4 — Окно «Информация о деталях»

На вкладке Цеха, при нажатии на Список цехов, открывается окно (рисунок 5.5) на котором показан номер цеха и его название.

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

Рисунок 5.5 — Окно «Список цехов»

При нажатии на вкладку «Отчеты» выпадает список:

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

1. Отчёт «Клиенты из Москвы» показан на рисунке 5.6

Рисунок 5.6 — Отчет «Клиенты из Москвы»

2. На рисунке 5.7 показан отчет «Самый дорогостоящий заказ»

Рисунок 5.7 — Отчет «Самый дорогостоящий заказ»

3. На рисунке 5.8 показан отчет «Наличие деталей на складе»

Рисунок 5.8 — Отчет «Наличие деталей на складе»

4. На рисунке 5.9 показан отчет «Регистрация заказа в период с 01.04.2013 по 30.04.2013г.г.»

Рисунок 5.9 — Отчет «Регистрация заказа в период с 01.04.2013 по 30.04.2013 г.»

5. На рисунке 5.10 показан отчет «Заказы, которые выполнялись в цеху №3».

Рисунок 5.10 — Отчет «Заказы, которые выполнялись в цеху №3»

При нажатии на вкладку справка, появится окно (рисунок 5.11).

Рисунок 5.11 — Окно Справка — «О программе»

Требования к аппаратному и системному ПО.

Для обеспечения работы информационной системы необходим персональный компьютер с системными характеристиками:

· операционная система: Windows 98/Me/NT/2000/XP/Vista

· процессор: 1 Ггц

· память: система требует минимум 256 Мб оперативной памяти.

· управление: требуется клавиатура и мышь

· устройства чтения: 1 Гб свободного места на жестком диске для установки и запуска системы

· печатающее устройство.

Заключение

В ходе выполнения курсовой работы было проведено проектирование информационной системы «Авиазавода».

Проектирование выполнялось с использованием CASE-средств BPWin, ERWin и Rational Software.

Для того чтобы спроектировать базу данных и построить концептуальную модель (на физическом и логическом уровне), сгенерированную далее в СУБД InterBase, было использовано CASE-средство ERWin.

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

Также применялось CASE-средство Rational Rose, посредством которого были созданы диаграмма прецедентов, диаграмма активности, диаграмма последовательности и диаграмма классов.

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

Поэтому предлагаемая программа должна существенно упростить работу любого авиазавода.

информационный документооборот авиазавод программный

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

1. Каталог лучших рефератов сети: [Электронный ресурс] // URL: www. (Дата обращения: 19.12.2013).

2. Маклаков, С.В. BPWin и ERWin. CASE- средства разработки информационных систем. — М.: «ДИАЛОГ — МИФИ «, 1999. — 256с.

3. Трофимов С. UML Диаграммы в Rational Rose: [Электронный ресурс] // URL: www.caseclub.ru/articles/rose2.html?next=51 (Дата обращения 18.12.2013).

4. Инфологическое моделирование: Модели баз данных: [Электронный ресурс] // URL: http://orloff.am.tpu.ru/data_base/kr1/infomodel.htm (Дата обращения 18.12.2013).

Приложение А

Таблица 1 — Описание сущностей

Сущность	Описание	Физический уровень таблицы	Атрибуты	Поля	Тип данных	Ключ
Цеха	Помещения, в которых осуществляется замена деталей и ремонт авиатехники.	Shop	Номер цеха Название цеха	ID_shop Name_shop	INTEGER INTEGER	PK
Заказ	Сотрудник заключает с клиентом договор на ремонт или изготовление авиатехники.	Orders	Код заказа Наименование Дата начала заказа Дата исполн-я заказа Дата оконч-я заказа Номер цеха Код клиента Стоимость заказа	ID_order Name_order Start_date Date_execution End_date ID_shop ID_customet Cost_of_the_order	CHAR CHAR DATE DATE DATE INTEGER INTEGER DECIMAL(8,2)	PK FK FK
Клиент	Предприятие или организация, которому оказывает услуги авиазавод.	Customer	Код клиента Название Адрес Телефон	ID_ Customer Name Address Phone	INTEGER CHAR CHAR CHAR
Деталь	Деталь, необходимая для ремонта авиатехники.	Detail	Код детали Наименование Количество ГОСТ Номер склада Код поставщика Стоимость детали	ID_detail Name Number_detail GOST Store_number ID_provider Cost_of_the-part	INTEGER CHAR CHAR CHAR INTEGER INTEGER DECIMAL(8,2)	PK FK FK
Склад	Помещение, в котором хранятся необходимые детали для ремонта авиатехники.	Stock	Номер склада Адрес телефон	Stock_number Address phone	INTEGER CHAR CHAR	PK
Поставщик	Организация, которая поставляет необходимые детали для ремонта авиатехники.	Provider	Код поставщика Название Адрес Телефон	ID_provider Name Address phone	INTEGER CHAR CHAR CHAR	PK

Размещено на