ЛекUML

SelectVacantPosition

[offer rejected]

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

Нормальное

завершение

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

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

3.3.2. Реализация диаграммами взаимодействия

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

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

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

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

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

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

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

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

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

На приведенной диаграмме последовательность посылаемых сообщений примерно соответствует последовательности действий на диаграмме деятельности в том случае, когда поток управления проходит по диаграмме сверху вниз один раз. Таким образом, диаграмма последовательности до некоторой степени определяет типовой сценарий варианта использования HirePerson. Однако, помимо определения последовательности выполняемых действий диаграмма содержит и другую информацию, существенную для дальнейшего проектирования. А именно, построив такую диаграмму, мы постулировали существование в системе некоторых классов (возможно, еще не всех), объекты которых должны взаимодействовать для обеспечения требуемого поведения моделируемого варианта использования. Действующее лицо PersonnelManager уже было определено при моделировании использования, здесь же в нашей модели появились новые сущности:

класс HireForm, ответственный за интерфейс, необходимый для выполнения варианта использования прием сотрудника;

класс Person, ответственный за хранение данных о конкретном человеке;

класс Position, ответственный за хранение данных и выполнение операций с конкретной должностью.

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

Идентификация действующих лиц и вариантов использования — ключ к дальнейшему проектированию.

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

Лекция 4. Моделирование структуры

Что такое моделирование структуры?

В чем заключаются особенности объектно-ориентированного моделирования структуры?

Какие элементы применяются для моделирования структуры? Как и для чего создаются диаграммы классов и объектов?

В каких случаях применяются диаграммы компонентов и размещения?

4.1. Объектно-ориентированное моделирование структуры

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

4.1.2. Назначение структурного моделирования

Рассмотрим более детально, какие именно структуры нужно моделировать и зачем. Мы выделяем следующие структуры:

структура связей между объектами во время выполнения программы; структура хранения данных; структура программного кода; структура компонентов в приложении;

структура используемых вычислительных ресурсов.

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

может хранится указатель (ссылка) на объект, содержащий вызываемый метод. Еще вариант: ссылка на объект с вызываемым методом может быть передана в качестве аргумента вызывающему методу. Возможно, используется какой-либо системный механизм удаленного вызова процедур, обеспечивающий доступ к объектам (например, такие как CORBA или DCOM) по идентификаторам. Если свойства объектов представлены записями в таблице базы данных, а методы — хранимыми процедурами СУБД (нередкий вариант реализации), то идентификация объектов осуществляется по первичному ключу таблицы. Как бы то ни было, во всех случаях имеет место следующая ситуация: один объект "знает" другие объекты и, значит, может вызвать открытые методы, использовать и изменять значения открытых свойств и т. д. В этом случае, мы говорим что объекты связаны, т. е. между ними есть связь. Для моделирования структуры связей в UML используются отношения ассоциации на диаграмме классов.

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

persistent — экземпляры классификатора, ассоциации или значения атрибута, соответственно, должны быть хранимыми;

transient — противоположно предыдущему — сохранять экземпляры не требуется (значение по умолчанию).

В настоящее время самой распространенным способом хранения объектов является использование системы управления базами данных (СУБД). При этом хранимому классу соответствует таблица базы данных, а хранимый объект (точнее говоря, набор значений хранимых атрибутов) представляется записью в таблице. Вопрос структуры хранения данных является первостепенным для приложений баз данных. Структура программного кода. Не секрет, что программы существенно отличаются по величине — бывают программы большие и маленькие. Удивительным является то, насколько велики эти различия: от сотен строк кода (и менее) до сотен миллионов строк (и более). Столь большие количественные различия не могут не проявляться и на качественном уровне. Действительно, для маленьких программ структура кода практически не имеет значения, для больших — наоборот, имеет едва ли не решающее значение. Поскольку UML не является языком программирования, модель не определяет структуру кода непосредственно, однако косвенным образом структура модели существенно влияет на структуру кода. Большинство инструментов поддерживает полуавтоматическую генерацию кода для одного или нескольких объектно-ориентированных языков программирования. В большинстве случаев классы модели транслируются в классы (или эквивалентные им конструкции) целевого языка. Кроме того, многие инструменты учитывают структуру пакетов в модели и транслируют ее в соответствующие "надклассовые"

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

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

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

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

4.1.3. Классификаторы

Классификатор— это описатель множества однотипных объектов. В UML используются следующие классификаторы:

класс; интерфейс; тип данных; узел; компонент;

действующее лицо; вариант использования; подсистема.

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

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