Файл: Моделирование предметной области «Управление заявками на техническое обслуживание» с помощью UML.pdf

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

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

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

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

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

• потоки данных;
• процесс;
• хранилище (накопитель) данных;
• внешняя сущность (или терминатор).

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

---

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

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

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

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

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

1. структурные диаграммы (Structure Diagram):

• диаграмма классов (Class diagram);
• диаграмма компонентов (Component diagram);
• диаграмма композитной/составной структуры (Composite Structure diagram);
• диаграмма развёртывания (Deployment diagram);
• диаграмма объектов (Object diagram);
• диаграмма пакетов (Package diagram);
• диаграмма профилей (Profile diagram).

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

• диаграмма деятельности (Activity diagram);
• диаграмма состояний/автомата (State machine diagram);
• диаграмма вариантов использования (Use case diagram).

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

• диаграмма коммуникации (Communication diagram);
• диаграмма последовательности (Sequence diagram);
• диаграмма синхронизации (Timing diagram).
• диаграмма обзора взаимодействия включается в себя Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества);

---

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

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

2.2 Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию

Диаграмма вариантов использования (диаграмма прецедентов). Принятие техники в ремонт. Рисунок 1

Рисунок 1. Принятие техники в ремонт

Варианты использования.

1. Краткая консультация
2. Создание заявки на ремонт
3. Предварительная диагностика
4. Выдача акта приема оборудования

Спецификации

Наименование: Краткая консультация

Основной сценарий:

1. Клиент приходит в СЦ, обращается к оператору с неисправным оборудованием.
2. Оператор консультирует клиента по стоимости и срокам ремонта.
3. Клиент принимает решение о ремонте

Наименование: Создание заявки на ремонт

Основной сценарий:

1. Клиент передает оборудование оператору
2. Оператор записывает контактные данные клиента.
3. Оператор проводит осмотр техники, и записывает информацию о технике, состояние, комплектацию.

Наименование: Предварительная диагностика

Основной сценарий:

1. Оператор производит предварительную диагностику
2. Уточняет дополнительную информацию: логины, пароли, необходимость сохранения данных на носителях и т.д.
3. Записывает результат предварительной диагностики

---

Наименование: Выдача АКТ приема оборудования

Основной сценарий:

1. Оператор на основе полученных сведений распечатывает акт приема оборудования в ремонт. Ставит свою подпись.
2. Просит клиента расписаться на акте.
3. Отдает акт клиенту.

Ремонт оборудования. Рисунок 2.

Рисунок 2. Ремонт оборудования

Варианты использования:

1. Прием в ремонт
2. Выполнение ремонтных работ
3. Внесение данных о выполненных работах
4. Завершение ремонта

Спецификации

Наименование: Прием в ремонт

Основной сценарий:

1. Ознакомление с результатами предварительной диагностики
2. В случае необходимости звонок клиенту, для уточнения информации

Наименование: Выполнение ремонтных работ

Основной сценарий:

1. Постановка точного диагноза, оценка стоимости работ
2. Согласование с клиентом стоимости работ
3. Выполнение работ

Наименование: Внесение данных о выполненных работах

Основной сценарий:

1. Записываются выполненные работы и их стоимость
2. Указываются комментарии по дальнейшему использованию

Наименование: Завершение ремонта

Основной сценарий:

1. Статус работы меняется на «Выполненный»
2. Оборудование передается оператору

Выдача готового оборудования. Рисунок 3

Рисунок 3. Выдача готового оборудования

Варианты использования:

1. Передача техники
2. Оплата
3. Закрытие заявки

Спецификации

Наименование: Передача техники

Основной сценарий:

1. Оператор передает клиенту отремонтированную технику
2. Клиент проверяет технику после ремонта

Наименование: Оплата

Основной сценарий:

1. Клиент производит оплату
2. Оператор выдает чек

Наименование: Закрытие заявки

Основной сценарий:

1. Оператор распечатывает акт выполненных работ и передает его клиенту
2. Оператор закрывает заявку и списывает ее в архив.

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

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

Вариант использования: Принятие техники в ремонт. Рисунок 4

Рисунок 4. Принятие техники в ремонт

---

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

Вариант использования: Ремонт техники. Рисунок 5

Рисунок 5. Ремонт техники.

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

Вариант использования: Выдача техники. Рисунок 6

Рисунок 6. Выдача техники

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

Диаграмма состояний по решаемой задаче

Рисунок 7. Диаграмма состояний, работы СЦ

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

---