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

Рисунок 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 (оборудование)

---