Разработка информационной системы "Техническое обслуживание станков"

Размещено на http://www.allbest.ru/

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ

ПЕНЗЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Факультет вычислительной техники

Кафедра «Компьютерные технологии»

КУРСОВОЙ ПРОЕКТ

по дисциплине: «Проектирование информационных систем»

на тему: Разработка информационной системы «Техническое обслуживание станков»

Выполнила:

Разокзода С.Дж.

Пенза, 2017



Ведение

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

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

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

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

Для успешной реализации проекта объект проектирования (ИС) должен быть прежде всего адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели ИС. Накопленный к настоящему времени опыт проектирования ИС показывает, что это логически сложная, трудоемкая и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов. Однако до недавнего времени проектирование ИС выполнялось в основном на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ИС. Кроме того, в процессе создания и функционирования ИС информационные потребности пользователей могут изменяться или уточняться, что еще более усложняет разработку и сопровождение таких систем. Процесс разработки таких ИСУ основывается на моделировании деятельности предприятия, описании организации и методов ведения их бизнеса, построении архитектуры системы и структуры баз данных, обосновании системы математических моделей и алгоритмов, реализации пользовательского интерфейса и выборе технических средств.

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



1. Анализ предметной области

В результате анализа выяснилось, что деятельность предприятия состоит из следующих элементов:

1) менеджеры принимают заказы клиентов (сломанные оборудования);

2) менеджеры по обработкам группируют полученные оборудования по типам;

3) менеджеры по ремонту собирают, ремонтируют станки и другие оборудования

4) менеджеры по проверки сортируют и проводят диагностику

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



2. Функциональное проектирование информационной системы

2.1 Описание case-средства проектирования системы Ramus Educational

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

В основе методологии IDEF0 лежат четыре основных понятия:

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

Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:

Верхняя сторона имеет значение “Управление” (Control);

Левая сторона имеет значение “Вход” (Input);

Правая сторона имеет значение “Выход” (Output);

Нижняя сторона имеет значение “Механизм” (Mechanism).

Графическое обозначение функционального блока

2. Итерфейсная дуга (Arrow), называемая также потоком или стрелкой. Отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком. Графическим отображением интерфейсной дуги является однонаправленная стрелка. По требованиям стандарта интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label), которое должно быть оборотом существительного.

3. Декомпозиция (Decomposition). Модель IDEF0 всегда начинается с представления системы как единого целого - одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором “А-0”.

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

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

Основные символы и термины DFD:

- потоки данных;

- процесс;

- хранилище (накопитель) данных;

- внешняя сущность (или терминатор).

Декомпозиция DFD осуществляется на основе декомпозиции процессов - каждый процесс может раскрываться с помощью DFD нижнего уровня.

2.2 Описание функциональной модели системы

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

На основе анализа предметной области разработана диаграмма верхнего уровня АИС «Техническое обслуживание станков» в методологии IDEF0. Контекстная диаграмма системы представлена на рисунке А1 в приложении А.

Из анализа деятельности предприятия определяем вход, выход, управление и механизм системы которые представлены в Таблице 1.

Таблица 1. Входы, выходы, управление и механизмы

Тип	Название	Предназначение
Вход	Оборудование	Станки и другие оборудования
Вход	Сведения об оборудование	Информация об полученных оборудованиях
Выход	Отремонтированные оборудования	Станки и другие оборудования после ремонта
Выход	Сведения об ремонте	Полная информация об сделанном ремонте
Управление	Нормативная документация	Документы содержащие требования безопасности, правила, общие характеристики, касающиеся определенных видов деятельности
Механизм	Финансовая система	Форма организации денежных отношений между всеми субъектами



В результате анализа выяснилось, что предприятия выполняет две основные вида работ.

Таблица 2

Название	Описание
Ремонт	Восстановление работоспособности или исправление состояния оборудований или станков
Обработка сведений	Полная обработка полученных сведений об оборудований

поэтому необходимо произвести декомпозицию системы (рисунок А2 приложение А).

Для дальнейшей декомпозиции работ (активностей) проводят анализ деятельности при ее выполнении.

Декомпозиция работы «Обработка сведений».

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

· Работы (активности) диаграммы декомпозиции работы «Обработка сведений».

Таблица 3

Имя работы (блока)	Описание
Классификация оборудования	Определяется виды оборудований(Код вида станка, Страна, Год выпуска, Марка)
Регламентация ремонтных работ	Определяется структура и продолжительность ремонтного цикла(Код ремонта, Название, Продолжительность, Стоимость, Примечания)
Диагностирование технического состояния	Определение технического состояния оборудований а так же сколько раз ремонтировался тот или иной станок (оборудований)



· Стрелки диаграммы декомпозиции работы «Обработка сведений».

Таблица 4

Имя стрелки	Начало	Тип начало	Окончание стрелки	Тип окончания
Нормативная документация	Граница диаграммы	Управление	Классификация оборудованный Регламентация ремонтных работ	Управление
Сведения об оборудование	Граница диаграммы	Вход	Диагностирование технического состояния	Вход
Проклассифицированные оборудования	Классификация оборудования	Выход	Диагностирование технического состояния	Управление
Сведения об регламентации ремонта	Регламентация ремонтных работ	Выход	Диагностирование технического состояния	управление
Финансовая система	Граница диаграммы	Механизм	Диагностирование технического состояния	Механизм
Обработанные сведения	Диагностирование технического состояния	Выход	Граница диаграммы	управление

2.2.1 Декомпозиция активности «Продажа и маркетинг» в методологии DFD

Диаграмма декомпозиции процесса «Ремонт оборудования» приведена на рисунке А4 приложения А.

Для декомпозиции процесса «Ремонт оборудования» необходимы дополнительные сведения о деятельности предприятия, которые были получены в результате анализа ее деятельности:

1) ремонт оборудования начинается при получении сведения об оборудования (сведения об оборудование - вход от внешней сущности);

2) при ремонте оборудования необходимо обработать все сведения (обработка сведений- процесс_1);

3) если все полученные сведения верны, то необходимо занести сведения об оборудование в соответствующие хранилище (направить данные в хранилище_2, 3, 4, 5, 6);

4) заканчивается ремонт оборудования, когда будут получены сведения об ремонте (выход на внешнюю сущность)

Таким образом, декомпозиция процесса «Ремонт оборудования» будет содержать:

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

-пять хранилищ, назовем их «Классификация оборудования», «Регламентация ремонтных работ», «Диагностика технического состояния», «Финансовая система», «Нормативная документация».



3. Описание средства проектирования Toad Data Modeler

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

Toad Data Modeler - многофункциональный инструмент разработки баз данных и приложений, который объединяет в одной интегрированной среде объектно-ориентированные и концептуальные возможности моделирования физических данных. Интуитивно понятный интерфейс пользователя и поддержка популярных СУБД делают Toad Data Modeler уникальным решением для ускорения разработки и анализа сложных распределенных приложений.

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

Toad Data Modeler - дает возможность бизнес аналитикам, системным архитекторам, IT менеджерам, прикладным разработчикам и разработчикам базы данных работать в команде при создании приложений.

Toad Data Modeler - интегрированное приложение для анализа и проектирования среды предприятия с возможностью полного отображения данных, объектов и бизнес процессов.

Toad Data Modeler - предоставляет расширенные функции создания отчетов, что помогает экономить время и сокращает затраты на документирование и понимание приложений.

3.1 Логическое проектирование системы

Построение модели для Технического обслуживание станков:

Возможный набор сущностей

Виды станков (Код вида станка, Страна, Год выпуска, Марка).

Виды ремонта (Код ремонта, Название, Продолжительность, Стоимость, Примечания).

Ремонт (Код вида станка, Код ремонта, Дата начала, Примечания).

Выделение сущностей предметной области

Анализ предметной области и информационных задач выявил следующее сущности и атрибуты:

Таблица 5

Сущность	Атрибуты
Вид станков	Код вида станков, страна, год выпуска, марка
Вид ремонта	Код ремонта, название ремонта, продолжительность, стоимость
Ремонт	Код вида ремонта, код ремонта, дата начало ремонта

Таблица 6. Выбор ключей и определение типов атрибутов сущностей

Сущность	Атрибут	Тип		Примечание
Вид станков	Код вида	Double	PK	номера код вида уникальны, поэтому атрибут Код вида станка выбран первичным ключом; других ключей нет.
	Страна	Text(50)
	Год выпуска	Data/Time
	марка	Double
	Вид станка	Text(50)
Вид ремонта	Код ремонта	Double	РК	номера код ремонта уникальны, поэтому атрибут Код вида станка выбран первичным ключом; других ключей нет.
	Название ремонта	Text(50)
	Продолжительность	Double
	стоимость	Double
Ремонт	Код вида	Double	PK	номера код вида станков уникальны, поэтому атрибут Код вида выбран первичным ключом; других ключей нет.
	Код ремонта	Double
	Дата начало ремонта	Data/Time

Все отношения (таблицы) находятся в третьей нормальной форме, так как: все отношения (таблицы) находятся в 1НФ, так как домены всех их атрибутов содержат только скалярные значения, и в таблицах не будет одинаковых строк, так как все таблицы имеют первичные ключи, значения которых не могут повторяться (за этим будет «следить» Case-средство).

Для выделения связей между сущностями при анализе предметной области было выявлено:

1) каждый код станка уникальный так как все станки имеют собственный код и категории

Связь вид станка- код станка

2) каждый код ремонта уникальный так как каждый ремонт нумеруется и разделяется на категории

Связь вид ремонта- код ремонта

3) при каждом ремонте ставится новый код так как ремонтные работы всегда отличаются

Связь ремонт-код вида

На основании выявленных сущностей и связей между ними создаем средствами Toad Data Modeler Freeware полную атрибутивную модель данных (логическую модель), которая представлена на рисунке Б1 в приложении Б.

Результат проверки логической модели средствами Toad Data Modeler Freeware:

Физическая модель - это отображение логической модели на модель данных конкретной СУБД.

Физическая модель представлена на рисунке Б2 в приложении Б. Для ее получения средствами Toad Data Modeler следует в меню View установить флаг Physical View.



Рисунок 1

Экспорт физической модели в СУБД Access 2007

Результат экспорта созданной физической модели в СУБД Access 2007 представлен на рисунке Б3 в приложении Б.

Для экспорта физической модели средствами Toad Data Modeler следует произвести необходимые действия, которые представлены в приложении С.

Тестирование созданной БД

1) заполнили таблицы данными, которые представлены на рисунке С1 в приложении С;

2) создали два запроса на выборку:

Результаты выполнения запросов представлены на рисунке С2 в приложении С. В результате проведения испытаний было установлено, что БД работоспособна.



4. Описание средства проектирования StarUML

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

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

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

В UML используются следующие виды диаграмм: 1) структурные диаграммы:

- диаграмма классов;

- диаграмма компонентов;

- диаграмма композитной/составной структуры;

- диаграмма кооперации (UML 2.0);

- диаграмма развёртывания;

- диаграмма объектов;

- диаграмма пакетов;

- диаграмма профилей (UML 2.2).

2) диаграммы поведения:

- диаграмма деятельности;

- диаграмма состояний;

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

3) диаграммы взаимодействия:

- диаграмма коммуникации (UML 2.0);

- диаграмма обзора взаимодействия (UML 2.0);

- диаграмма последовательности;

- диаграмма синхронизации (UML 2.0).

Преимущества UML:

1) UML объектно-ориентирован, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных объектно-ориентированных языках;

2) UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;

3) диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;

4) UML позволяет вводить собственные текстовые и графические стереотипы, а также применяется сфере программной инженерии;

5) UML получил широкое распространение и динамично развивается.

4.1 Объектно-ориентированное проектирование систем

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

· объекты и их отношения с другими объектами;

· поведение объектов;

· взаимодействие между объектами.

Диаграмм прецедентов

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

Созданная диаграмма прецедентов представлена на рисунке Д1 в приложении Д.

Результаты анализа предметной области:

ь менеджеры принимают заказы клиентов (сломанные оборудования);

ь менеджеры по обработкам группируют полученные оборудования по типам;

ь менеджеры по ремонту собирают, ремонтируют станки и другие оборудования

ь менеджеры по проверки сортируют и проводят диагностику

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

На основании анализа предметной области выделяем актеров и их описание:

Таблица 7

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

На основании предметной области формулируем требования к проектируемой системе:

· актер Менеджер по работе с клиентами использует систему для оформления, редактирования заказов и управления информацией о клиентах предприятия;

· актер Менеджер по обработки сведений использует систему для передачи данных об оборудованиях другому разделу;

· актер Механик по распределению оборудований использует систему для разделения станков и других оборудований на категории и передает информацию другому разделу;

· актер Механик по распределению ремонта использует систему для разделения ремонта на категории и передает информацию другому разделу;

· актер Механик по диагностике использует систему для определения работоспособности станков и других оборудований, передает полученную информацию другому разделу;

· актер Менеджер по финансовой системе использует систему для оформления счетов клиентам, а также самому предприятию;

На основании сформулированных выше требований выделяем следующие прецеденты:

Таблица 8

Прецедент	Краткое описание
Работа с заказом	Запускает менеджер по работе с клиентами для внесения, изменения, или просмотра заказа.
Управление информацией об оборудований	Запускает менеджер по обработке сведений для внесения, изменения, удаления или просмотра сведений об оборудование.
Обработка сведений по оборудованию	Запускает Механик по распределению оборудования для внесения, изменения, удаления или просмотра сведений об оборудований
Обработка сведений по ремонту	Запускает Механик по распределению ремонта для внесения, изменения, удаления или просмотра сведений о ремонте
Ремонт	Запускает Механик по диагностике для внесения, изменения, удаления или просмотра обработанных сведений
Финансовая система	Запускает Менеджер по финансовой системе для внесения, изменения, удаления или просмотра сведений об ремонте

Устанавливаем связи между актерами и прецедентами:

ь в языке UML возможен только один тип связи между актером и прецедентом - ассоциация; поэтому всех актеров связали с прецедентами связями направленная ассоциация, выделив тем самым инициатора связи;

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

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

Диаграммы деятельности бизнес-процесса

Диаграмма деятельности бизнес-процесса «Работа с клиентами» представлена на рисунке Д2 в приложении Д.

При реализации бизнес-процесса «Техническое обслуживание станков» на предприятии выполняются следующие операции:

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

b) после получения информации начинается ремонт оборудования;

c) отремонтированные оборудования передаются диагностикам;

d) если оборудование не прошел тестирование, он возвращается на повторную обработку оборудований.

e) при успешном завершении тестирования оборудование, оформляется документы об оплате и передается менеджеру по работе с клиентами.

Диаграммы деятельности потока события прецедента

Поток событий прецедента «Работа с заказом» состоит из главное потока, под-потоков и альтернативных потоков.

Чтобы не загромождать диаграмму покажем поток событий на нескольких диаграммах деятельности:

· на первой из них (условно назовем ее главной) покажем действия для основного потока и связанный с ним альтернативный поток;

· под-потоки покажем путем декомпозиции соответствующего действия главной диаграммы.

«Главная» диаграмма деятельности потока событий прецедента «Работа с заказом» представлена на рисунке Д3 в приложении Д, а диаграмма «декомпозиции» - на рисунке Д4.

Диаграммы классов

Диаграммы классов создаются на этапе предварительного проектирования с целью:

· выделения абстракций, являющихся частью системы, и их «обязанностей»;

· моделирования простых коопераций, то есть совокупностей классов и других элементов, работающих совместно для достижения некоторых целей;

· моделирования логической схемы базы данных.

Созданная диаграмма классов для сценария «Добавить новый заказ» прецедента «Работа с заказом» представлена на рисунке Д5 в приложении Д.

Выделяем классы-сущности

Рассматриваемый сценарий состоит из:

самого заказа;

клиента, который делает заказ;

оборудование, которые входят в заказ.

Ремонт оборудования;

Поэтому создаем классы-сущности: Order (Заказ), Client (Клиент), Equipment (оборудование), Repairs (Ремонт).

Так как в один заказ может входить несколько разных комплектующих изделий, и одно комплектующее изделие может входить в несколько заказов, то введем еще один класс-сущность OrderItem (Состав заказа).

Описание классов Client (клиент предприятия)

Атрибуты

name: string - наименование клиента (private)

address: string - адрес клиента (private)

phone: string - телефон клиента (private)

Операции

AddClient() - добавить нового клиента (public)

RemoveClient() - удалить существующего клиента (public)

GetInfo() - получить информацию о клиенте (public)

Order (заказ, который делает клиент)

Атрибуты

orderNumber: integer - номер заказа (private)

orderDate: date - дата оформления заказа (private)

orderComplete: date - дата выполнения заказа (private)

Операции

Create() - создать новый заказ (public)

SetInfo() - сохранить информации о заказе (public)

GetInfo() - получить информацию о заказе (public)

OrderItem (пункт заказа, который делает клиент)

Атрибуты

itemNumber: integer - номер пункта заказа (private)

quantity: integer - количество оборудований (private)

price: float - цена за ремонт (private)

Операции

Create() - создать новую строку заказа (public)

SetInfo() - сохранить информацию о строке заказа (public)

GetInfo() - получить информацию о строке заказа (public)

Equipment (оборудование)

Атрибуты

name: string - наименование (private)

manufacturer: string - производитель (private)

price: float - цена ремонта (private)

description: string- описание (private)

Операции

Add Equipment () - добавить новое оборудование (private)

Remove Equipment () - удалить оборудование (private)

GetInfo() - получить информацию об оборудование (public)

Repair of equipment (ремонт оборудования)

Атрибуты

name: string - название ремонта (private)

code: string - код ремонта (private)

price: float - цена ремонта (private)

duration: string- продолжительность ремонта (private)

Операции

Add Repair () - добавить новый код ремонта (private)

Remove Repair () - удалить код ремонта (private)

GetInfo() - получить информацию об ремонте (public)

Объявляем отношения между классами

ь классы Client и Order - отношение ассоциации, так как эти класса просто связаны друг с другом и никакие другие типы связей здесь применить нельзя; один клиент может сделать несколько заказов, каждый заказ поступает только от одного клиента, поэтому кратность связи со стороны класса Client - 1, со стороны Order - 1..*;

ь классы Order и OrderItem - отношение композиции, так как строка заказа является частью заказа, и без него существовать не может;

в один заказ может входить несколько строк заказа, строка заказа относится только к одному заказу, поэтому кратность связи со стороны Order - 1, со стороны OrderItem - 1..*;

ь классы OrderItem и Equipment - отношение агрегации, поскольку оборудование является частями строки заказа, но и те, и другие, являются самостоятельными классами;

одно оборудование может входить во много строк заказа, в одну строку заказа входит только одно оборудование, поэтому кратность связи со стороны Equipment - 1, со стороны OrderItem - 1..*.

ь классы Equipment и Repair of equipment - отношение зависимы, поскольку оборудование влияет на обработку данных для ремонта; одно оборудование может входить в одну категорию ремонта, поэтому кратность связи со стороны Equipment - 1, со стороны Repair of equipment - 1..*.

Объявим граничные и управляющие классы

Рассматриваемый сценарий - это только одно из действий, которые обеспечивает прецедент «Работа с заказом». Прецедент также позволяет просмотреть, отредактировать или удалить заказ. Это означает, что необходимо предусмотреть механизм, который позволяет выбирать необходимое действие.

Создадим для этого два граничных классы (OrderOptions и AddNewOrder) и один управляющий класс (OrderManager):

ь OrderOptions (Параметры работы с заказом) с комментарием «Класс, обеспечивающий механизм работы с заказами»;

ь AddNewOrder (Добавление нового заказа), который будет служить для добавления новых заказов с комментарием «Класс служит для добавления новых заказов»;

ь отношение между этими классами - агрегация, так как класс AddNewOrder рассматривается как часть класса OrderOptions, частями которого также будут классы для просмотра, редактирования и удаления заказов;

ь кратность связи 1 к 1, так как в состав класса OrderOptions входит только один класс AddNewOrder.

ь OrderManager (Менеджер по работе с заказами) с комментарием "Управляющий класс для обработки потока событий прецедента "Работа с заказами"", который будет обеспечивать обработку потока событий для рассматриваемого прецедента.

ь отношение между классами AddNewOrder и OrderManager - направленная ассоциация с кратностью связи 1 к 1, так как один экземпляр класса AddNewOrder взаимодействует только с одним экземпляром класса OrderManager;

ь отношение между классами OrderManager и Order - направленная ассоциация с кратностью связи 1 к 1..*, так как один класс OrderManager может взаимодействовать с несколькими классами Order.

Диаграммы последовательности

Диаграммы последовательности (sequence diagram)

Этот вид диаграмм используется для задания логики выполнения сценария прецедентов.

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

Диаграмма последовательности для сценария «Добавить новый заказ» прецедента «Работа с заказом» представлена на рисунке Д6 в приложении Д. Определяем объекты и актеров, которые будут обмениваться сообщениями

ь актер «Менеджер по работе с клиентами» - инициатор выполнения сценария;

ь объект - класс OrderOptions (Параметры работы с заказом) -- отвечает за выбор возможного действия с заказом в рассматриваемом прецеденте;

ь объект - класс AddNewOrder (Добавление нового заказа), отвечающий за добавление заказа;

ь объект - класс OrderManager (Менеджер по работе с заказами) - отвечает за обработку потока событий рассматриваемого прецедента;

ь объект - класс Order (Заказ);

ь объект - класс Client (Клиент);

ь объект - класс Equipment (оборудование)

ь объект - класс Repair of equipment (ремонт оборудования)

Определяем сообщения, которыми будут обмениваться объекты

Таблица 9

Номер сообщ.	Объект отправитель сообщения	Объект получатель сообщения	Название
1	Менеджер по работе с клиентами	OrderOption	Выбор операции «добавить»
2	OrderOption	AddNewOrder	Отоброжение полей ввода
3	Менеджер по работе клиентами	AddNewOrder	Выбор вида станка
4	AddNewOrder	OrderManager	Получения списка клиентов
5	OrderManager	Client	Получения списка клиентов
6	Client	AddNewOrder	Список клиентов
7	AddNewOrder	AddNewOrder	Отображение списка клиентов
8	Менеджер по работе с клиентами	AddNewOrder	Выбор клиента
9	AddNewOrder	OrderManager	Получения списка оборудований
10	OrderManager	Equipment	Получения списка оборудований
11	Equipment	AddNewOrder	Список полученных оборудований
12	AddNewOrder	AddNewOrder	Отображение списка полученных оборудований
13	Менеджер по работе с клиентами	AddNewOrder	Выбор подходящей категории
14	AddNewOrder	Repair of equipment	Отправка сведений
15	Менеджер по работе с клиентами	AddNewOrder	Сохранить заказ
16	AddNewOrder	OrderManager	Передача управления
17	OrderManager	Order	сохранить

Примечание. Типом всех сообщений выбран Send.

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

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

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

Диаграммы состояний описывают объекты системы (классы, прецеденты) с точки зрения теории автоматов.

Диаграмма состояний для класса Order представлена на рисунке Д7 в приложении Д.

Составим диаграмму состояний для класса Order (Заказ), так как он часто меняет свое состояние:

Ш при создании заказа он переходит в состояние Инициализация, в котором выполняются некоторые предварительные действия;

Ш после завершения инициализации заказ переходит в состояние Открыт, в котором к заказу добавляются новые пункты;

Ш выход из состояния Открыт возможен или в случае отмены заказа, или в случае заполнения всех необходимых пунктов заказа;

Ш если заполнены все необходимые пункты заказа, то он переходит в состояние Закрыт, в котором происходит выписка счета за отремонтированное оборудование;

Ш выход из состояния Закрыт произойдет только после того, как счет будет выписан;

Ш если заказ отменен, то из состояния Открыт он переходит в состояние Отменен;

Ш при выходе из этого состояния происходит удаление всех пунктов заказа

Диаграмма состояний для класса Order:

Описание диаграммы состояний в виде алгоритма начало:

класс Order устанавливается в состояние InitialState;

если в состоянии InitialState произошло событие «заказ создан»,

то Order переходит в состояние Инициализация;

при входе в это состояние выполняется входное действие «Сохранить дату принятия оборудования»,

пока Order находится в этом состоянии, то выполняется действие «Внести информацию о клиенте, а также сведения об полученном оборудование»;

если в состоянии Инициализация произошло событие «инициализация завершена», то Order переходит в состояние Открыт;

если Order находится в состоянии Открыт,

то если произошло событие «Добавление пункта заказа» и заполнены не все пункты заказа, то Order переходит из состояния Открыт в состояние Открыт, при выходе выполняется действие OrderItem.Create() (создание пункта заказа);

если произошло событие «заполнены все позиции заказа», то Order переходит в состояние Закрыт; если произошло событие «заказ отменен», то Order переходит в состояние Отменен; пока Order находится в состоянии Закрыт, но если произошло событие «счет выписан», то Order переходит в состояние FinalState, выполняется действие «Выписать счет за отремонтированное оборудование"; кц если Order находится в состоянии Отменен,

Order переходит в состояние FinalState, при выходе выполняется действия «Сохранить дату отмены» и OderItem.Delete() (удаление пункта заказа). конец

В состояние Отменен заказ переходит из состояния Открыт при наступлении события "заказ отменен". При выходе из него выполняется действие выхода "Сохранить дату отмены". При переходе из этого состояния в конечное выполняется действие "* Здесь также стоит "*", поскольку это действие будет выполняться много раз.



Заключение

информационный диаграмма программный

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

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

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

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



Список литературы

1. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. - М.: ДМК Пресс, 2001.

2. Горбаченко В.И., Убиенных Г.Ф., Бобрышева Г.В. Проектирование ИС с CA Erwin Modeling Suite 7.3. - Пенза: Изд-во Пенз. гос. ун-та, 2012. - 154 с.

3. Фаулер, М. UML в кратком изложении. / М. Фаулер. - М.: Мир, 2009 г. - 204 с.



Приложение А

Рисунок А1. Структура АИС в методологии IDEF0

Рисунок А2. Декомпозиция системы «Ремонт оборудования»



Рисунок А3. Декомпозиция активности «Обработка сведений»

Рисунок А4. Декомпозиция активности «Ремонт оборудования»



Приложение Б

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

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

Рисунок Б3. Результат экспорта физической модели в Access 2007



Приложение С

Экспорт физической модели в Access 2007

1) при создании новой модели выбрать: Target database: Access 2007,

2) создать физическую модель,

3) меню Model - Generate Script,

4) в окне Script Generating на закладке What to generate указать путь к файлу.sql и выбрать необходимые доступные опции,

5) Generate,

6) Открыть Access и создать новую БД (при создании укажите путь к БД),

7) В Access:

· меню Создать - Модуль ( )

· вставить в окно (General) сгенерированный.sql файл:

· установить курсор на начало sql-файла,

· в окне Microsoft Visual Basic for Application - …

ь меню Tools - References…

ь выбрать указанные допустимые ссылки:

ь OK

· в окне Microsoft Visual Basic for Application -…

· Run Macro (F5 или)

· в окне Macros выбрать Macro Name: Main,

· закрыть Access с сохранением модуля и БД,

· открыть Access с созданной БД.



Рисунок С1. Созданные таблицы с данными



Рисунок С2. Результаты выполнения запросов



Приложение Д

Рисунок Д1. Диаграмма прецедентов

Рисунок Д2. Диаграмма деятельности бизнес-процесса



Рисунок Д3. «Главная» диаграмма деятельности потока событий прецедента

Рисунок Д4. Диаграмма «декомпозиции» потока событий прецедента



Рисунок Д5. Диаграмма классов

Рисунок Д6. Диаграмма последовательности

Рисунок Д7. Диаграмма состояний для класса

Размещено на Allbest.ru

...