Файл: Федеральное государственное бюджетное образовательное учреждение высшего образования тверской государственный технический университет.doc
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 08.11.2023
Просмотров: 21
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
МИНОБРНАУКИ РОССИИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ
УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ
«ТВЕРСКОЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»
Кафедра (предметная комиссия) ИНФОРМАЦИОННЫЕ СИСТЕМЫ .
| СОГЛАСОВАНО | | УТВЕРЖДАЮ |
| Гл. специалист предприятия, для которого выполнен реальный проект (работа) | | Заведующий кафедрой ИС |
| | | |
| подпись, инициалы, фамилия | | подпись, инициалы, фамилия |
| «»2023 г. | | «»2023 г. |
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
к курсовому проекту (работе)
На тему: Разработка информационной системы Торгово-закупочной фирмы (BPwin,Erwin,Access).
Автор курсового проекта (работы). Буланов И.И. _________ .
подпись, инициалы, фамилия
Обозначение курсового проекта (работы)_________________группа ИСТ-2035 _________.
Специальность:. Информационные системы и технологии_________ . номер, наименование
Руководитель проекта (работы):. _Козлова Ю.Г. ______.
подпись, дата, инициалы, фамилия
Проект (работа) защищен(а): .оценка:..
дата
Консультанты по разделам:
. Аналитическая часть ____ ...
краткое наименование раздела подпись, дата, инициалы, фамилия
. Проектная часть ...
краткое наименование раздела подпись, дата, инициалы, фамилия
Нормоконтролер..
подпись, дата, инициалы, фамилия
Тверь 2023
Тверской государственный технический университет
Кафедра Информационные системы
| СОГЛАСОВАНО | | УТВЕРЖДАЮ |
| Гл. специалист предприятия, для которого выполнен реальный проект (работа) | | Заведующий кафедрой ИС |
| | | |
| подпись, инициалы, фамилия | | подпись, инициалы, фамилия |
| «»2020 г. | | «»2023 г. |
ЗАДАНИЕ на выполнение курсового проекта
(работы)
Студенту: Буланову И.И.
Тема проекта (работы): Разработка информационной системы Торгово-закупочной фирмы (BPwin,Erwin,Access).
(утверждена приказом по ВУЗу от № ).
Срок сдачи студентом законченного проекта (работы):.
Исходные данные к проекту (работе): ____________.
Содержание расчётно-пояснительной записки курсового проекта (работы):
а) Аналитическая часть: ______________________________________________________.
б) Проектная часть: ______________________________________________________.
Перечень графического (иллюстративного) материала:_________________________________________________________________
____________________________________________________________________________________________________________________________________________________
Консультанты по проекту (работе) с указанием относящихся к ним разделов проекта.
Дата выдачи задания: .
Руководитель: ______
подпись
Задание принял к исполнению “____”2023 г.
(подпись студента)
Содержание
Введение…………………………………………………………………...4
-
Разработка модели процессов………………………………………...5 -
Создание модели данных……………………………………………13 -
Приведение модели к 3 нормальной форме………………………..16 -
Связывание моделей…………………………………………………18 -
Интеграция модели данных ERWIN и SQL SERVER 2000 ………20 -
Перевод базы данных на SQL SERVER 2000………………………21 -
Разработка клиентского приложения……………………………….23 -
Диаграммы в аннотации UML………………………………………27
Заключение………………………………………………………………29
Список литературы……………………………………………………...30
Введение
В настоящее время инструментальные средства (ИС) проектирования играют жизненно важную роль в создании информационной системы. К одним из таких средств можно отнести такие CASE-средства разработки, как Bpwin и Erwin, а также систему поиска и исправления ошибок модели данных Model Validator. Преимуществами этих программных продуктов является крайне гибкий инструмент моделирования в условиях изменения требований к ИС, который значительно уменьшает время её разработки, увеличивает степень автоматизации, а также имеет хорошее соотношение стоимость/эффективность.
-
Разработка модели процессов
Ф
ункциональная модель предназначена для описания существующих бизнес-процессов на предприятии и идеального положения вещей - того, к чему нужно стремиться. Для этого была созданo описание системы в целом и ее взаимодействие с внешней средой. Контекстная диаграмма деятельности фирмы представлена на рисунке 1.
Рисунок 1. Диаграмма декомпозиции IDEF0 функционирования фирмы.
Входом для общей работы являются товар, поступивший от поставщиков, и сопроводительные документы с ним, а также заказы клиентов на товар. Управление осуществляется на основе существующего законодательства и, сложившейся на данный момент, ситуацией на рынке. В качестве механизмов рассматриваются сотрудники и оборудование. Результатом торгово-закупочной деятельности фирмы являются, в первую очередь, проданный товар, прибыль, деньги поставщику за предоставленный товар и оказанные услуги по транспортировке, а также размещение заказов, отчетность и налоги в государственную казну.
После описания контекстной диаграммы проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. В результате такого разбиения, каждый фрагмент системы изображается на отдельной диаграмме декомпозиции и включает три работы: “Закупка”, “Хранение” и “Продажа”.
Р
Для отдела закупок входом является товар с документами, который поставляется и заказывается у производителя или посредника фирмы. Так как фирма является торгово-закупочной, то заказы могут быть как на закупку определенного вида продукции, так и на продажу уже доставленного товара Доставленный товар складируется в отделе хранения, а информация о состоянии отдела хранения хранится в БД “Товары”. Затем при совершении акта купли-продажи составляются необходимые документы и выписываются накладные, по которым выдается товар со склада.
Диаграммы потоков данных (DFD), используются для описания документооборота и обработки информации. В отличии от диаграммы (IDEF0) здесь показывается, как объекты и данные двигаются от одной работы к другой. Диаграмма декомпозиции “Закупка” включает следующие работы: Оформление договоров на поставку, после которой происходит отслеживание недоброкачественной и конкурентной продукции. Результатом этих работ является сохранение информации о проделанной работе в хранилище данных ”Статистика” и на основе собранной информации принимается решение о доставке товара в отдел хранения. Диаграмма декомпозиции “Закупка” представлена на рисунке 3.
Рисунок 3. Диаграмма декомпозиции “Закупка”
Декомпозицию подсистемы ”Хранение” (нотация DFD) можно описать следующим образом: отдел хранения принимает “Доставленный товар” из отдела закупок и накладные поступавшие из отдела продаж, затем делается запрос на склад и, если такой товар имеется, по ним выписывается товар. Потом вносятся соответствующие изменения в БД товаров и заказов, а по выписанным накладным в отделе продаж, отгруженный товар продаётся к
лиентам. Описанная схема изображена на рисунке 4.
Рисунок 3. Диаграмма декомпозиции “Хранение ”
Для описания логики взаимодействия информационных потоков используется IDEF3, использующая графическое описание потоков и взаимоотношений между процессами. IDEF0 позволяет описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе. Для наглядного изображения, что из себя представляет эта нотация, я изобразил отдел продаж в виде IDEF0. Диаграмму декомпозиции “Продажа” изображена на Рисунке 5. На ней отображается процесс продажи товара покупателю от обработки заявки на заказ клиента до формирования партии или получения товара клиентом “на руки”. Для отображения логики взаимодействия, здесь работы представлены во временном отношении. Об этом свидетельствуют п
ерекрестки слияния и разветвления.
Рисунок 3. Диаграмма декомпозиции “Продажа ”
Инструментальное средство Bpwin содержит несколько типов отчетов.
Информацию о контексте модели можно получить в отчете Model Report, представленном ниже:
Model Name: Firma
Definition: Коммерческая организация, приобретающая факторы производства с целью создания и продажи благ и получение на этой основе прибыли.
Scope: Технологические, финансовая и управленческие аспекты деятельности торгово-закупочной фирмы.
Viewpoint: Руководитель предприятия
Time Frame: (AS-IS)
Status: WORKING
Purpose: Описание функционирования торгово-закупочной фирмы с целью создания её информационной модели.
Source: Торгово-закупочная фирма.
Author Name: Алексеев Е.И.
Creation Date: 10.10.2005
System Last Revision Date: 15.05.2011
User Last Revision Date: 15.05.2011
Отчет по конкретной диаграмме ( на примере диаграммы “Продажа”) включает список объектов - работ, стрелок, хранилищ данных, внешних ссылок и так далее:
Report for Diagram: A3.1, Продажа
Activity Name: Обработка заявок
Activity Status: WORKING
Activity Author: Алексеев Е.И.
Object Type: Activity
Activity Number: 2
Activity Name: Оформление накладных
Activity Status: WORKING
Activity Author: Алексеев Е.И.
Object Type: Activity
Activity Number: 3
Activity Name: Заполнение формы заявки
Activity Status: WORKING
Activity Author: Алексеев Е.И.
Object Type: Activity
Activity Number: 1
Activity Name: Составление отчетности
Activity Status: WORKING
Activity Author: Алексеев Е.И.
Object Type: Activity
Activity Number: 4
Activity Name: Переоформление заявок
Activity Status: WORKING
Activity Author: Алексеев Е.И.
Object Type: Activity
Activity Number: 5
Activity Name: Оформление документов
Activity Status: WORKING
Activity Author: Алексеев Е.И.
Object Type: Activity
Activity Number: 12
Activity Name: Формирование партии товара
Activity Status: WORKING
Activity Author: Алексеев Е.И.
Object Type: Activity
Activity Number: 11
Link Name: Авторизованный заказ
Link Status: WORKING
Link Author: Алексеев
Link Name: Неверно-оформленная заявка
Link Status: WORKING
Link Author: Алексеев
Link Name: Правильно оформленная заявка
Link Status: WORKING
Link Author: Алексеев
Referent Name: Заказы клиентов
Referent Status: WORKING
Referent Author: Алексеев Е.И.
Referent Name: Клиент
Referent Status: WORKING
Referent Author: Алексеев Е.И.
Referent Name: Склад
Referent Status: WORKING
Referent Author: Алексеев Е.И.
-
Создание модели данных
Д
ля разработки модели данных использовалось инструментальное средство Erwin. Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире. Объекты модели, представляемые на логическом уровне - сущности и атрибуты. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД. Логический уровень модели данных представлен на рисунке 6.
Рисунок 6. Логический уровень представления
Логический уровень отличается от физического тем, что на нем данные выглядят как в реальности. Между тем физический уровень зависит от конкретной СУБД (MS SQL Server 2000), фактически являясь отображением системного каталога. Создав логическую модель, можно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. В физической модели содержится информация о всех объектах БД.
По заданию на курсовое проектирование нам необходимо использовать нотацию IDEF1X.
Р
исунок 7. Физический уровень представления
По глубине представления данных модель представляет наиболее детальное представление структуры данных: данные в третьей нормальной форме и включает все сущности, атрибуты и связи, т.е. разработана полная атрибутивная модель системы торгово-закупочной фирмы. На физическом уровне сущности соответствует таблица, экземпляру сущности - строка в таблице, а атрибуту - колонка таблицы. При построении модели данных я определил сущности и атрибуты, а также определил какая информация будет храниться в них, задал связи между сущностями. Хотя в IDEF1X и различают зависимые и независимые сущности, в моей модели использовались только зависимые связи, приводящие к возникновению дочерних и родительских сущностей с миграцией атрибутов. Для однозначного идентифицирования экземпляров сущности были выбраны первичные ключи и альтернативные ключи, не ставшие первичными. Типы данных физической модели однозначно соответствуют типам данных СУБД.
Для того, чтобы удостовериться, что каждый атрибут определен для своей сущности, сократить объем памяти для хранения информации и устранить аномалии необходимо нашу модель данных нормализовать.
-
Приведение модели к 3 нормальной форме
Сущность находится в третьей н.ф., когда все атрибуты содержат атомарные значения, каждый не ключевой атрибут полностью зависит от первичного ключа и не зависит от другого не ключевого атрибута.
После построения модели данных она проверяется в Erwin Validator на наличие ошибок. В Erwin Validator есть средство ERWin Examiner. С помощью него можно анализировать структуру баз данных с целью выявления недочетов и ошибок проектирования. Ошибки бывают 4 категорий:
-
Ошибки проектирования колонок -
Ошибки индексов и ограничений -
Ошибки нормализации( приведения к 1,2,3 н.ф.) -
Ошибки связей
Исправление ошибок довольно длительная операция. В случае наличия недочетов принимается решение о существенности данных недочетов, и если они существенны, то опять в модель данных вносятся изменения.
Рисунок 8. Отчет об ошибках
В результате проведения анализа модели была выявлена ошибка индексов, что не противоречит условиям приведения модели к третьей нормальной форме, где главное внимание уделяется отсутствию ошибок нормализации.
-
Связывание моделей
После разработки модели данных её следует связать с моделью процессов, что гарантирует завершенность анализа, корректности и согласованности сущностей и работ. Для этого необходимо в Erwin выбрать пункт меню File/Export/Bpwin и создать файл экспорта *.eax, а затем в Bpwin выбрать File/Import/Erwin.
На рисунке 9 отображены те сущности, которые были импортированы в Bpwin.
Рисунок 9. Импорт сущностей в Bpwin.
После внесения данных в модель процессов можно связать сущности и атрибуты со стрелками.
Рисунок 10. Связывание со стрелками сущностей и атрибутов.
Рисунок 11. Таблица связывания.
В таблице связывания в виде иерархического списка показываются все работы модели, стрелки, которые касаются работ, сущности и атрибуты, которые были связаны со стрелками.
-
Интеграция модели данных Erwin и SQL Server 2000
После получения схемы модели данных необходимо интегрировать функциональную модель, созданную в Erwin c СУБД. Для этого произвелось подключение к серверу SQL. Затем я создал там базу данных Firma. После соединения в неё добавились 8 таблиц, аналогичных таблицам Erwin и MS Access.
Рисунок 12. Таблица “товары” в БД Firma.
Рисунок 13. БД “Клиенты” в БД Firma.
В результате интеграции, изменяя данные в MS Access изменения вносились и в таблицы расположенные на SQL Server’е.
-
Перевод базы данных на SQL Server 2000
Для того чтобы перевести базу данных в формат SQL Server 2000, необходимо выполнить следующие действия: создать на сервере базу данных командой create database Firma, где Firma – уникальное в пределах сервера имя базы данных, cоздать в Microsoft Access проект существующей базы данных.
Р
исунок 14. Связь с данными.
Рисунок 15. Импорт объектов.
Рисунок 16. Создание приложения Access "клиент-сервер".
В результате проделанных операций все данные базы данных Access сохранились в базе данных на SQL сервере.
-
Разработка клиентского приложения
Разработка клиентского приложения осуществлялась с помощью MS Access.
Были созданы следующие формы, таблицы и запросы:
Рисунок 17. БД товаров.
Рисунок 18. Форма регистрации клиентов.
Форма определения к какому отделу принадлежит сотрудник фирмы:
Рисунок 19. Форма "Просмотр сотрудников".
Таблица клиентов, из рисунка видно, что таблица связана с таблицей заказы:
Рисунок 20. Связывание таблиц.
Таблица сотрудников фирмы:
Рисунок 21. Таблица "Сотрудники".
По коду заказа клиент может просмотреть свой заказ:
Рисунок 22. Форма "Просмотр состояния заказа".
Аналогично предыдущей форме работает запрос:
Рисунок 23. Запрос "Просмотр состояния заказа".
После ввода значения кода заказа (например 32) выводятся характеристики заказа:
Рисунок 24. Запрос "Данные заказа".
Структуру взаимодействия таблиц отображает схема данных фирмы:
Рисунок 25. Схема данных.
Результатом проделанных операций стала клиентская часть прототипа торгово-закупочной фирмы, представленная в виде запросов, форм и таблиц MS Access.
-
Диаграммы в аннотации UML
В соответствии с заданием на курсовое проектирование необходимо разработать диаграммы функционирования информационной системы, на основе AllFusion Component Modeler’а. Этот пакет позволяет эффективно генерировать код приложений. AllFusion Component Modeler поддерживает методологию CA Catalysys, ориентированную на технологию компонентной разработки. Для характеристики торгово-закупочной фирмы необходимо описать архитектуру фирмы, которую наиболее полно отражают диаграммы компонентов и размещения. По клиентскому приложению была построена диаграмма классов.
Рисунок 26. Диаграмма компонентов.
Рисунок 27. Диаграмма размещения.
Рисунок 28. Диаграмма классов.
Заключение
В процессе курсового проектирования была спроектирована информационная система торгово-закупочной фирмы. В ходе проектирования были изучены способы применения профессиональных программных CASE-средств. Таким образом, были на практике закреплены знания, полученные в ходе изучения дисциплины “Проектирование информационно-управляющих систем”.
Список литературы
1. Маклаков С.В. Создание информационных систем с AllFusion Modelling Suite. – М.: ДИАЛОГ – МИФИ, 2002. – 224с.
2. Сайт case-web «Информационные системы».
3. «Информационные системы» (http://alice.stup.ac.ru/case).
4. Макарычев П.П.: Курс лекций по дисциплине «Проектирование информационно-управляющих систем».