Файл: Разработка регламента выполнения процесса «Покупка сырья и материалов» (Описание предметной области).pdf

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

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

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

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

Стандарт UML версии 1.1, принятый OMG в 1997 г., предлагает следующий набор диаграмм для моделирования:

– диаграммы вариантов использования (use case diagrams) – для моделирования бизнес-процессов организации и требований к создаваемой системе);

– диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними;

• диаграммы поведения системы (behavior diagrams):
• диаграммы взаимодействия (interaction diagrams):
• диаграммы последовательности (sequence diagrams) и
• кооперативные диаграммы (collaboration diagrams) – для моделирования процесса обмена сообщениями между объектами;
• диаграммы состояний (statechart diagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое;
• диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей; – диаграммы реализации (implementation diagrams):
• диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы;
• диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы.

Существует достаточно много CASE-инструментов моделирования и проектирования систем и баз данных (не только с помощью UML). В данном учебном пособии для примера моделирования системы выбран программный инструмент моделирования StarUML [7]. Данная программная платформа имеет свободную лицензию и доступна для установки с официального сайта StarUML [7]. StarUML поддерживает одиннадцать различных типов диаграмм, принятых в нотации UML 2.0, а также подход MDA (модельно- настраиваемая архитектура), предлагает настройку параметров пользователя для адаптации среды разработки, поддерживает расширения, предоставляет различного рода модули, расширяющие возможности StarUML.

Инструмент поддерживает возможность добавить плагины к базовой системе. Несмотря на то, что записано на языке Delphi, эти плагины могут быть записаны на любом COM-совместимом языке, таком как C++, Delphi, C# и VB.

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

Из прочих достоинств можно выделить:

- Генерация кода в языки: C#, Java, С++

-Поддержка работы с фреймворками

-Удобный графический редактор

-Полное соответствие стандарту UML 2.0

- Возможность расширения функционала (про это написано отдельное руководство разработчика)

-Экспорт документации в форматы: DOC, PPT, TXT, XLS…

- Поддержка паттернов

- Импорт проектов Rational Rose

- Приятный размер дистрибутива

Глава 3. Построение диаграмм

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

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

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

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

Действующие лица делятся на три основных типа – пользователи системы, другие системы, взаимодействующие с данной, и время. Время становится действующим лицом, если от него зависит запуск каких-либо событий в системе (рис.1).

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

Рисунок 1 – Диаграмма вариантов использования для системы «Салон красоты»

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

Деятельности

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

Рисунок 2 – Диаграмма деятельности системы

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

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

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

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

При этом прием сообщения инициирует выполнение определенных действий тем объектом, которому сообщение передано.

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

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

Рисунок 3 – Диаграмма последовательности системы

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

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

После исследования предметной области выявили следующие классы (рис 4.):

Рисунок 4 – Классы системы

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

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

Рисунок 5 – Атрибуты классов системы

Установим отношения между классами (рис.6):

Рисунок 6 –Диаграмма классов системы

Диаграмма состояния:

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

Существует много форм диаграмм состояний, незначительно отличающихся друг от друга семантикой. Наиболее распространенная форма, используемая в объектно-ориентированных методах, впервые применялась в методе ОМТ и впоследствии была адаптирована Гради Бучем.