Конспект лекции «Моделирование использования»

Для большинства средств UML нетрудно отыскать аналоги среди широко используемых практических методов конструирования программных систем. И это не удивительно, ведь именно эти методы были унифицированы посредством UML. А вот для диаграмм использования известный аналог указать труднее. Мы попытаемся объяснить прагматику моделирования использования на конкретном примере.
Сквозной пример В остальных частях учебного пособия рассматривается один сквозной Пример моделирования сравнительно приложения — информационной системы отдела кадров. Выбор примера обусловлен следующими соображениями. Во-первых, предметная область до некоторой знакома всем. Таким образом, суть задачи заранее ясна, и можно сосредоточить внимание на тонкостях применения UML, а не на объяснении особенностей предметной области.
Во-вторых, информационная система отдела кадров — это типичное офисное приложение из самого распространенного класса систем автоматизации делопроизводства. UML как нельзя лучше подходит для моделирования именно таких систем и все средства языка можно проиллюстрировать естественным образом. В-третьих, авторам случалось разрабатывать системы на самом деле, а не только в книге.
ТЕХНИЧЕСКОЕ ЗАДАНИЕ

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

1. Прием, перевод и увольнение сотрудников.

2. Создание и ликвидация подразделений.

2. Создание вакансий и сокращение должностей.

Конечно, техническое задание из одного абзаца текста и трех нумерованных пунктов — это не более чем учебный пример. Однако даже на этом примере видны многие характерные «особенности» подобных документов, которые, увы, слишком часто встречаются в реальной жизни. С одной стороны, что-то написано, а, с другой стороны не очень понятно, что делать дальше. Безо всяких объяснений заказчик использует термины свой предметной области — разработчик должен их знать и понимать. Требований к реализации нет вовсе. Функции не упорядочены по приоритетам: не ясно, что является критически важным, а чем можно поступиться в случае необходимости. В общем, раскритиковать это техническое задание в пух и прах не составляет труда.
Список новых диаграмм и их названий:

Диаграмма внутренней структуры (Composite Structure diagram)
Диаграмма пакетов (Package diagram)
Диаграмма автомата (State machine diagram)
Диаграмма коммуникации (Communication diagram)
Обзорная диаграмма взаимодействия (Interaction Overview diagram)
Диаграмма синхронизации (Timing diagram)

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

1.Общие диаграммы
Практически не зависят от предмета моделирования
Могут применяться в любом программном проекте
Диаграмма использования

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

Диаграмма классов (class diagram) ‒ основной способ описания структуры системы.

Диаграмма автоматов

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

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

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

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

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

Диаграмма коммуникации

Диаграмма коммуникации (communication diagram) ‒ способ описания поведения, семантически эквивалентный диаграмме последовательности.

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

Диаграмма компонентов (component diagram) ‒ показывает взаимосвязи между модулями (логическими или физическими), из которых состоит моделируемая система.

Диаграмма размещения

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

2.Специальные диаграммы

Служат для дополнения какой-либо общей диаграммы
Являются частным случаем
Уточняют детали
Диаграмма объектов

Диаграмма объектов (object diagram) ‒ является экземпляром диаграммы классов.

Диаграмма внутренней структуры

Диаграмма внутренней структуры (composite structure diagram) используется для более подробного представления структурных классификаторов, прежде всего классов и компонентов.

Обзорная диаграмма взаимодействия

Обзорная диаграмма взаимодействия (interaction overview diagram) является разновидностью диаграммы деятельности с расширенным синтаксисом: в качестве элементов обзорной диаграммы взаимодействия могут выступать ссылки на взаимодействия (interaction use), определяемые диаграммами последовательности.

Диаграмма синхронизации

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

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

Диаграмма пакетов (package diagram) ‒ средство группирования элементов модели.
Представления

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

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

Можно сказать, что представление ‒ это средство логического структурирования модели.

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

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

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

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

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

Представление размещения (Deployment view) отражает топологию связей аппаратных средств и размещения на них компонентов. Структурные аспекты передаются диаграммами размещения, а поведенческие аспекты ‒ диаграммами взаимодействия, состояний и деятельности.

В следующей таблице приведен набор представлений, описанных авторами языка в фундаментальной книге «UML Language Refenece», которая в русском переводе получила странное название «UML. 2-е издание». Первоначальные пять представлений, ассоциирующиеся с UML 1, при переходе к UML 2 были дополнены и в результате образовали набор уже из восьми представлений.

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

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

Представление использования (Use Case view) описывает функционирование системы в терминах вариантов использования и рассматривает их с точки зрения заинтересованных действующих лиц.

Представление автоматов (State machine view) специфицирует поведение отдельных элементов, для которых можно ввести понятие жизненного цикла, описываемого набором состояний и переходов между ними.

Представление деятельности (Activity view) описывает функционирование системы с точки зрения различных элементов деятельности, соединенных потоками управления и потоками данных.

Представление взаимодействия (Interaction view) отражает последовательность обмена сообщениями между элементами системы во время выполнения приложения.

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

Представление управления моделью (Model Management view) отражает внутреннюю организацию модели, описывая ее разбиение на пакеты и указывая отношения между ними. Включение этого аспекта в число представлений авторам представляется спорным.

Три представления

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

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

Бизнес-анализ и моделирование

Бизнес — систематическая деятельность
Организация — ведет бизнес
Бизнес-процесс — последовательность действий, в результате которой происходит выполнение некоторой функции
Бизнес-модель — конструктивное описание бизнес-процессов
Бизнес-анализ — процесс построения бизнес-модели
Реинжиниринг бизнеса

Целенаправленное изменение бизнес-процессов требует бизнес-модели

В последние годы большую популярность приобрел метод использования бизнес-анализа для изменения бизнеса, который называется реинжиниринг бизнеса. Суть этого метода заключается в следующем:
1. Составляется бизнес-модель «как есть»
2. Ставится некоторое «измеримое» цель (набор целей) , которое требуется достичь
3. Проводится одна или несколько итераций преобразования моделей «как есть», составляется модель «как должно
но быть», которая удовлетворяет поставленной цели