Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Используя принципы ООП).pdf

Деятельность (activity) - это поведение, реализуемое объектом, пока он находится в данном состоянии. Например, когда счет находится в состоянии «Закрыт», происходит возврат кредитной карточки пользователю. Деятельность — это прерываемое поведение. Оно может выполняться до своего завершения, пока объект находится в данном состоянии, или может быть прервано переходом объекта в другое состояние. Деятельность изображают внутри самого состояния, ей должно предшествовать слово do (выполнять) и двоеточие.

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

Событие (event) вызывает переход из одного состояния в другое. Событие «Клиент требует закрыть» вызывает переход счета из открытого в закрытое состояние. Событие размещают на диаграмме вдоль линии перехода. Большинство переходов должны иметь события, так как именно они, прежде всего, заставляют переход осуществиться.

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

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

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

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

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

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

На диаграмме классов в прямоугольниках в верхней части даны имена классов, в средней части – имена атрибутов, в нижней части – имена методов.

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

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

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

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

Глава 4. Мероприятия по улучшению бизнес-процесса

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

Так же было решено убрать промежуточное звено при получении оборудования на складе. Инженер самостоятельно заполнял накладную и получал оборудование на складе.

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

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

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

В целом лояльность клиентов повысилась, качество работ улучшилось.

Глава 5. Моделирование бизнес-процесса «как должно быть»

Так выглядит диаграмма использования после рефакторинга бизнес-процесса:

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

Появились дополнительные действия, такие как, запрос на обратную связь и запрос на закрытие заявки.

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

Без изменений осталась роль «Кладовщик».

Следующий тип диаграмм, это диаграмма последовательности:

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

Аналогично предыдущей диаграмме. Здесь добавлены шаги контроля качество.

Появились дополнительные действия, такие как, запрос на обратную связь и запрос на закрытие заявки.

Последний вид диаграмм, которые были изменены в следствии моделирования нового бизнес-процесса, это диаграмма деятельности

Рисунок 8. Диаграмма деятельности «как должно быть»

Здесь так же как и на предыдущих диаграммах добавлены шаги контроля качества.

Заключение

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