Файл: Моделирование предметной области “Кадровое делопроизводство” с помощью UML.pdf

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

Разработка программного обеспечения является высокозатратным процессом. Стоимость процесса разработки во многом определяется как объемом необходимой работы и качеством принимаемых решений.

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

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

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

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

---

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

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

Свойство однозначности создаваемых моделей позволяет с использованием специального программного обеспечения (например Rational Rose или Rational XDE) проводить автоматическую генерацию программного кода.

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

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

Проведем характеристику существующих типов диаграмм UML.

1. Диаграммы вариантов использования (Use Case)

С помощью диаграмм вариантов использования описываются функциональные возможности системы или операции, которые система должна выполнять. Целями разработки диаграммы вариантов использования являются:

- определение общих границ и контекста моделируемой прикладной задачи;

- формулировка общих требований к функциональности проектируемой системы;

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

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

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

---

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

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

Указанный тип диаграмм отражает следующие стороны проектируемых систем:

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

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

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

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

Для описания взаимодействия объектов в UML предусмотрены следующие виды диаграмм:

Диаграмма последовательности – моделирует последовательность обмена сообщениями между объектами

Диаграмма коммуникаций – модулирует структуру взаимодействующих компонентов (для данного вида диаграммы в UML 1 используется наименование «диаграмма коопераций»)

Временные диаграммы – моделирует изменение состояния нескольких объектов в момент взаимодействия

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

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

1. Диаграммы классов

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

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

---

1. Диаграммы состояний

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

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

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

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

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

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

---

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

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

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

1. Диаграмма компонентов

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

---