Ведение. 1. Примерная организационная структура предприятия 4

• Название: 1. Примерная организационная структура предприятия 4
• Дата: 10.05.2023
• Размер: 0.92 Mb.
• Имя файла: Ведение.docx
• Тип: Документы; #1118836

Оглавление

1. Примерная организационная структура предприятия 4

2. Разработка модели бизнес-процессов организации IDEF0 "как есть". Разработка модели бизнес-процессов организации IDEF0 "как должно быть" 4

3. Разработка логической и физической модели структуры базы данных IDEF1x 8

4. Разработка модели вариантов использования с применением UML 10

5. Анализ и выбор программно-аппаратных средств для проведения автоматизации 19

6. Разработка требований к информационной системе компании (модификации, сопровождению). Постановка задачи на автоматизацию для реализации 20

Заключение 22

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

Ведение

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

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

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

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

заложенными в них правилами обработки информации.

Для успешной реализации проекта объект проектирования (ИС) должен

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

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

1. Примерная организационная структура предприятия

Организационная структура управления отдела, занимающегося ремонтом и обслуживанием оборудования изображена на рисунке 1.



Рисунок 1 - Организационная структура управления отдела по ремонту станков и оборудования.

2. Разработка модели бизнес-процессов организации IDEF0 "как есть". Разработка модели бизнес-процессов организации IDEF0 "как должно быть"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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



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

3. Разработка логической и физической модели структуры базы данных IDEF1x

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

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

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

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

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

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

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

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

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

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

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

Нормализация БД

Все отношения (таблицы) находятся в третьей нормальной форме, так как:

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

Разработка структуры связей

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

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

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

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

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

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

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



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



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

4. Разработка модели вариантов использования с применением UML

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 получил широкое распространение и динамично развивается.

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

• 
  объекты и их отношения с другими объектами;
  
• 
  поведение объектов;
  
• 
  взаимодействие между объектами.
  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 
  на первой из них (условно назовем ее главной) покажем действия для основного потока и связанный с ним альтернативный поток;
  
• 
  под-потоки покажем путем декомпозиции соответствующего действия главной диаграммы.
  

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

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

Созданная диаграмма классов для сценария «Добавить новый заказ» прецедента «Работа с заказом» представлена на рисунке Д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)

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



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



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



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



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



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



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

5. Анализ и выбор программно-аппаратных средств для проведения автоматизации

Выбор пал на Microsoft Access.

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

Наиболее удобной и популярной системой управления базой данных (СУБД), которая позволит реализовать все необходимые задачи по разработке базы данных и программного приложения является продукт компании Microsoft – Access.

Microsoft Access является настольной СУБД реляционного типа. Достоинством Access является то, что она имеет очень простой графический интерфейс, который позволяет не только создавать собственную базу данных, но и разрабатывать простые и сложные приложения. В отличие от других настольных СУБД, Access хранит все данные в одном файле, хотя и распределяет их по разным таблицам.

Access позволяет не только вводить данные в таблицы, но и контролировать правильность вводимых данных. Для этого необходимо установить правила проверки прямо на уровне таблицы. Тогда каким бы образом не вводились данные — прямо в таблицу, через экранную форму или на странице доступа к данным, Access не позволит сохранить в записи те данные, которые не удовлетворяют заданным правилам.

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

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

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

Access может поддерживать одновременную работу с базой данных 50 пользователей, при этом все пользователи гарантировано будут работать с актуальными данными.

6. Разработка требований к информационной системе компании (модификации, сопровождению). Постановка задачи на автоматизацию для реализации

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

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

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

Функции проектируемой БД:

хранение информации о станках,

хранение информации о ремонтах,

хранения информации о производителях,

обновление и добавление информации,

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

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

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

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

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

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

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

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

Для успешной эксплуатации программного продукта необходим персональный компьютер со следующими характеристиками: процессор Intel Pentium с тактовой частотой 800 МГц и выше, оперативная память – не менее 256 Мбайт, свободное дисковое пространство – не менее 700 Мбайт, устройство для чтения компакт-дисков, монитор типа Super VGA (число цветов – 256) с диагональю не менее 15″, принтер.

Заключение

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

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

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

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

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

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

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