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

Содержание:

Введение

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

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

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

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

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

При написании данной работы были использованы следующие виды диаграмм UML:

• диаграмма вариантов использования
• диаграмма классов
• диаграмма состояния
• диаграмма взаимодействия
• диаграмма деятельности

Для их построения выбран инструмент gliffy.

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

Глава 1. Описание предметной области. Постановка Задачи

Для изучения и проектирования возьмем объектную модель. Объектная модель подчиняется правилам объектно-ориентированного программирования и используется для описания язык UML.

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

1.1 Основные принципы построения объектной модели. Основные элементы объектной модели

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

Объекты имеют свойства и методы.

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

Методы объекта – это программные процедуры, обеспечивающие выполнение им определенных действий.

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

Основными принципами объектно-ориентированного программирования являются наследование, инкапсуляция и полиморфизм.

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

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

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

Модульность — это свойство системы, связанное с возможностью ее декомпозиции на ряд внутренне сильно сцепленных, но слабо связанных между собой подсистем (модулей). Модульность снижает сложность системы, позволяя выполнять независимую разработку отдельных модулей. Инкапсуляция и модульность создают барьеры между абстракциями.

Иерархия — это ранжированная или упорядоченная система абстракций, расположение их по уровням.

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

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

К основным понятиям объектно-ориентированного подхода (элементам объектной модели) относятся:

· объект;

· класс;

· атрибут;

· операция;

· полиморфизм (интерфейс);

· компонент;

· связи.

Объект определяется как осязаемая сущность (tangible entity) — предмет или явление (процесс), имеющая четко определяемое поведение.

Объект может представлять собой абстракцию некоторой сущности предметной области (объект реального мира) или программной системы (архитектурный объект). Любой объект обладает состоянием (state), поведением (behavior) и индивидуальностью (identity).

Состояние объекта - одно из возможных условий, в которых он может существовать, оно изменяется со временем.

Состояние объекта характеризуется перечнем всех возможных (статических) свойств данного объекта и текущими значениями (динамическими) каждого из этих свойств. Состояние объекта определяется значениями его свойств (атрибутов) и связями с другими объектами.

Поведение определяет действия объекта и его реакцию на запросы от других объектов.

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

Каждый объект обладает уникальной индивидуальностью.

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

Любой объект является экземпляром (instance) класса. Определение классов и объектов — одна из самых сложных задач объектно-ориентированного проектирования.

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

Атрибут - это элемент информации, связанный с классом.

Так как атрибуты содержатся внутри класса, они скрыты от других классов. В связи с этим может понадобиться указать, какие классы имеют право читать и изменять атрибуты. Это свойство называется видимостью атрибута (attribute visibility).

У атрибута можно определить три возможных значения этого параметра:

• Public (общий, открытый). Это значение видимости предполагает, что атрибут будет виден всеми остальными классами. Любой класс может просмотреть или изменить значение атрибута. В соответствии с нотацией UML общему атрибуту предшествует знак «+».
• Private (закрытый, секретный). Соответствующий атрибут не виден никаким другим классом. Закрытый атрибут обозначается знаком «-» в соответствии с нотацией UML.
• Protected (защищенный). Такой атрибут доступен только самому классу и его потомкам в иерархии наследования.

Нотация UML для защищенного атрибута — это знак «#».

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

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

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

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

Операции реализуют связанное с классом поведение (иначе говоря, реализуют обязанности класса — responsibilities).

1.2 Унифицированный язык моделирования UML

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

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

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

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

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

• • 1. структурные диаграммы:

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

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

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

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

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

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

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

- диаграмма профилей.

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

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

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

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

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

- диаграмма коммуникации;

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

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

- диаграмма синхронизации.

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

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

Главными в разработке UML были следующие цели:

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

Глава 2. Выбор средства для моделирования бизнес-процесса

Для проектирования бизнес системы будем использовать диаграммы UML, которые для удобства разработаем с использованием инструмента Gliffy, рабочая панель изображена на рисунке 1.

Рисунок 1. Рабочая панель Gliffy

Gliffy — это веб-приложение, написанное на flash.

1. Имеет в своем арсенале средства для создания блок-схем, структур, пользовательских интерфейсов, UML диаграмм.
2. Представляет средства удобной публикации и совместной разработки документов.
3. Есть возможности импорта как в растровую, так и в векторную графику.
4. В бесплатной версии существует ограничение на максимальное количество документов — 5.

Сервис Gliffy предлагает пользователям инструменты совместной работы. Меню «Поделиться» позволит опубликовать схему в интернете. Готовый вариант можно опубликовать на другом сайте, сославшись на изображение или вставив HTML-код. Более того, доступна совместная работа над схемами с несколькими пользователями сразу. Для этого есть пункт «Сотрудничать» в том же меню.

Готовый рабочий вариант можно сохранить. По умолчанию система сохранит схему в Gliffy, но есть экспорт в форматы SVG, GXML, JPG, PNG. Ещё одно преимущество — сохранение в виде шаблона для дальнейших работ.

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

MS Visio 2007 — это универсальное средство для построения диаграмм, графиков, схем любого рода. Включает мощные средства визуализации и подходит для решения широкого круга задач.

Axure заточен под создание и быстрое прототипирование каркасов веб-сайтов. Интерфейс похож на MS Visio. Содержит очень большую библиотеку с набором объектов для дизайна страницы и пользовательских интерфейсов. Позволяет не только создавать графическое представление, но и привязывать события, связывать блоки между собой и многое другое. Широкие возможность экспорта готовой схемы.

SmartDraw 2009 Очень мощное средство, позволяющее создавать все возможные виды интерфейсов. Интерфейс похож на MS Office 2007. Гигантская библиотека объектов (дополнительные элементы доступны на официальном сайте), и всевозможные типы диаграмм.

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

Основная задача диаграммы «как есть» заключается в определении слабых мест бизнес-процесса и исходной точки для его изменения. Модель бизнес-процесса «КАК ЕСТЬ» описывает принципы и механизмы не автоматизированного функционирования. Указанная информация является основой для комплексного, системного анализа процессов, поиска проблем и путей их преодоления.

3.1 Описание и построение диаграмм

Все диаграммы UML можно условно разбить на две группы, первая из которых ‒ общие диаграммы. Общие диаграммы практически не зависят от предмета моделирования и могут применяться в любом программном проекте без оглядки на предметную область, область решений. Для проектирования диаграмм был выбран инструмент Gliffy. Этот инструмент отлично подходит для личного пользования, малого бизнеса и особенно для сетевых администраторов, которым необходимо быстро и легко создать диаграммы. Приложение получило оценку 4 звезды в категории программного обеспечения для малого бизнеса.

3.1.1 Диаграмма вариантов использования

Диаграмма использования (use case diagram) ‒ это наиболее общее представление функционального назначения системы.

Диаграмма использования призвана ответить на главный вопрос моделирования: что делает система во внешнем мире?

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

1. ассоциация между действующим лицом и вариантом использования;
2. обобщение между действующими лицами;
3. обобщение между вариантами использования;
4. зависимости (различных типов) между вариантами использования.

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

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

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

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

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

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

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

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

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

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

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

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

Диаграммы деятельности предпочтительнее использовать в следующих ситуациях:

• анализ потоков событий в конкретном варианте использования. Здесь нас не интересует связь между действиями и объектами, а нужно только понять, какие действия должны иметь место и каковы зависимости в поведении системы. Связывание действий и объектов выполняется позднее с помощью диаграмм взаимодействия;
• анализ потоков событий в различных вариантах использования. Когда варианты использования взаимодействуют друг с другом, на диаграмме деятельности удобно представить и проанализировать все их потоки событий (в этом случае диаграмма с помощью вертикальных пунктирных линий разделяется на зоны — так называемые «плавательные дорожки». В каждой зоне изображаются потоки событий одного из вариантов использования, а связи между разными потоками — в виде переходов или потоков объектов).

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

Диаграмма последовательности (sequence diagram) ‒ это способ описания поведения системы на основе указания последовательности передаваемых сообщений.

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

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

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

Ось времени может быть направлена горизонтально, в этом случае считается, что время течет слева направо.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

• • 1. Буч, Г. UML: Руководство пользователя. / Г. Буч, Джекобсон И. и др. - М.: ДМК, 2008 г. – 356 с.
    2. Фаулер, М. UML в кратком изложении. / М. Фаулер. - М.: Мир, 2009 г. – 204 с.
    3. Марка, Д. Методология структурного анализа и проектирования. / Д. Мар- ка. - М.: Мир, 2008 г. – 304 с.
    4. Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. / А.М. Вендров. - М.: Финансы и статистика, 2009 г. – 758 с.
    5. Калянов, Г.Н. CASE-технологии. / Г.Н. Калянов. - М.: Финансы и статистика, 2008 г. – 435 с.
    6. Липаев, В.В. Системное проектирование сложных программных средств для информационных систем. / В.В. Липаев. - М.: Синтег, 2009 г. – 156 с.
    7. Дубенецкий, Б.Я. Проектирование информационных систем. / Б.Я. Дубенецкий. - Л.: ЛЭТИ, 2008 г. – 675 с.
    8. Грабер, М. Введение в SQL. / М. Грабер. - М.: ЛОРИ, 2008 г. – 568 с.
    9. Шлеер, С. Объектно-ориентированный анализ: моделирование мира в со- стояниях. / С. Шлеер. - М.: Диалектика, 2008 г. – 476 с.
    10. Зиндер, Е.З. Системное проектирование. / Е.З. Зиндер. - М.: Мир, 2009 г. – 535 с.