Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

Учебник по ТООМ - файл УП_ООМ_5.doc


Учебник по ТООМ
скачать (4180 kb.)

Доступные файлы (1):

УП_ООМ_5.doc7283kb.30.03.2006 01:55скачать

содержание
Загрузка...

УП_ООМ_5.doc

1   2   3   4   5   6   7   8   9   10   ...   13
Реклама MarketGid:
Загрузка...
^

2.3. Разработка диаграммы Вариантов Использования в Rational Rose


Порядок разработки Use Case диаграммы в Rational Rose:

Browse>Use Case View>New>Use Case Diagram

Рассмотрим пример разработки диаграммы Вариантов Использования для системы записи студентов на элективные курсы.. Требуемые для этого действия подробно перечислены далее. Готовая диаграмма Вариантов Использования должна выглядеть как на рисунке *.

Этапы разработки диаграммы

1. Дважды щелкните на Главной диаграмме Вариантов Использования (Main) в броузере, чтобы открыть ее.

2. С помощью кнопки Use Case (Вариант Использования) панели инструментов поместите на диаграмму новый вариант использования.

3. Назовите этот новый вариант использования «Запись на элективный курс»

4. Повторите этапы 2 и 3, чтобы поместить на диаграмму остальные варианты использования: Выбор курса для преподавания, Запрос расписания курса и так далее.

5. С помощью кнопки Actor (Действующее лицо) панели инструментов поместите на диаграмму новое действующее лицо.

6. Назовите его «Студент»

7. Повторите шаги 5 и 6, поместив на диаграмму остальных действующих лиц::Преподаватель, Методист.

Добавить ассоциации


1. С помощью кнопки Unidirectional Association (Однонаправленная ассоциация) панели инструментов нарисуйте ассоциацию между действующим лицом Студент и вариантом использования Запись на элективный курс.

2. Повторите этот этап, чтобы поместить на диаграмму остальные ассоциации.


^ Добавить связь расширения


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

2. Щелкните правой кнопкой мыши на новой связи между вариантами использования " Завершение регистрации на курс " и " Запись на элективный курс ".

3. В открывшемся меню выберите пункт Open Specification (Открыть спецификацию).

4. В раскрывающемся списке стереотипов введите слово extends (расширение), затем нажмите ОК.

5. Слово <<extends>> появится на линии данной связи.


Добавить описания к вариантам использования


1. Выделите в броузере вариант использования Запись на элективный курс

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

3. С помощью окна документации введите описания ко всем остальным вариантам использования.


Добавить описания к действующему лицу


1. Выделите в броузере действующее лицо Преподаватель

2. В окне документации введите для этого действующего лица следующее описание: Преподаватель – человек, осуществляющий обучение студентов

3. С помощью окна документации введите описания к оставшимся действующим лицам.


^

2.4 Анализ требования в Requisite Pro



Создание требований в RequisitePro из модели прецедентов Rose


Цель

Как известно, средства Rational могут быть использованы в большинстве софтверных проектов программных систем в компаниях с собственными стандартами и подходами к созданию программного обеспечения.

Согласно RUP модель прецедентов является стержнем, который связывает воедино многие артефакты, возникающие в большинстве современных софтверных проектов: планы работ, архитектура системы, программные коды, скрипты сценарии для автоматизированного тестирования и т.д. Также в этот список можно добавить и функциональные требования на создаваемую систему, речь о которых пойдет ниже. Интегрированное использование Rose и RequisitePro позволяет решить две очень важные задачи:

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

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

• создание необходимых групп (типов) требований и типов документов в проекте RequisitePro;

• интеграция модели Rose и проекта RequisitePro;

• экспорт прецедентов из модели Rose в группу "Прецеденты" проекта RequisitePro;

• создание требований в группе "Функциональные требования" проекта RequisitePro на основании сценариев прецедентов;

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


^ Создание необходимых типов требований и типов документов

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

• возможность создания дополнительных метрик для прецедентов (например, дата ожидаемой реализации, приоритет, исполнитель и т.д.);

• возможность сортировки и фильтрации прецедентов по названиям или атрибутам;

• возможность связывания прецедентов с требованиями различных типов (с требованиями планирования, тестирования, нефункциональными и т.д.);

• сохранение истории изменений прецедентов;

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

Для создания указанного типа требований на дереве узлов открытого проекта RequisitePro необходимо активизировать самый верхний узел и в его контекстном меню выбрать пункт "Properties" (рис. 1).



Рис. I

В открывшемся окне "Project Properties" следует активизировать страницу "Requirement Types". Она позволяет добавить в проект новые типы требований. После добавления типов требований "Прецеденты" и "Функциональные требования" окно "Project Properties" примет вид согласно рис. 2.



Рис 2.

На страничке "Attributes" окна "Project Properties" следует определить необходимые атрибуты для сформированных типов требований. Хотя, конечно же, можно использовать и те атрибуты, которые создаются по умолчанию для новых типов требований.

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

"Приоритет" (список значений; возможные значения: "Высочайший", "Высокий", "Средний", "Низкий") - приоритет реализации функционального требования или прецедента;

"Состояние" (список значений; возможные значения: "Предложено", "Одобрено", "Реализовано", "Протестировано") - состояние, в котором на данный момент находится процесс реализации функционального требования или прецедента;

"Трудность" (список значений; возможные значения: "Высокая", "Средняя", "Низкая") – оценочная сложность реализации функционального требования или прецедента;

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

Совместное использование Rose и RequisitePro позволяет связывать документы проекта RequisitePro с любыми прецедентами модели Rose. Процесс интеграции модели Rose с проектом RequisitePro требует предварительного создания хотя бы одного типа документа, который будет связан с требованиями типа "Прецеденты". Сформируем некоторый обобщенный тип документов "Общие документы" (рис. 3).



Рис. 3 Интеграция модели Rose и проекта RequisitePro

Для использования Rose совместно с RequisitePro необходимо, чтобы в первом был активизирован соответствующий "Add-In". Для этого необходимо выбрать пункт меню "Add-Ins/Add-In Manager...". Это приводит к появлению окна "Add-In Manager". Здесь следует проконтролировать, чтобы был активен пункт "RequisitePro" (рис. 4). В результате появляются дополнительные пункты главного и различных контекстных меню, позволяющих работать с RequisitePro из Rose.

Теперь следует связать текущий файл модели Rose с проектом RequisitePro. Для этого требуется выбрать пункт меню "Tools/Rational RequisitePro/Associate Model To Project". В открывшемся окне "Associate Model To RequisitePro Project" следует указать проект RequisitePro, в который будут экспортированы прецеденты (Рис. 5). Кроме того, необходимо указать тип требований и тип документов по умолчанию, с которыми автоматически будут связаны экспортированные прецеденты. В дальнейшем указанные типы могут быть заменены на любые другие с помощью этого же окна.

Нажатие кнопки <ОК> приведет к интеграции модели Rose и проекта RequisitePro. Экспорт прецедентов из Rose в RequisitePro Рассмотрим экспорт прецедента на простейшем примере. Пусть имеется некоторая модель прецедентов (рис. 6).



Рис. 4



Рис. 5




Рис.6

Для экспорта прецедентов следует для каждого из них выбрать пункт контекстного меню "Requirement Properties/New...". При этом появляется форма добавления требований "Requirement Properties..." из RequisitePro (рис. 7).




Рис.7

Данная форма позволяет установить значения дополнительных атрибутов прецедентов (страничка "Attributes"), создать связи с существующими требованиями любых типов ("Traceability") и сформировать иерархию прецедентов ("Hierarchy"). Нажатие <ОК> приведет к физическому созданию требования типа "Прецеденты" в базе RequisitePro. Таким образом экспортируем все прецеденты в проект RequisitePro. Созданные требования в RequisitePro следует перенести в папку, предназначенную для их хранения. После этого требуется создать матрицу атрибутов (Attribute Matrix") для работы с ними (рис. 8)



Рис. 8 Создание функциональных требований

Функциональные требования создаются аналитиком на основе анализа сценариев прецедентов в модели Rose. Как и прежде, рассмотрим этот процесс на кратком примере.

Для добавления функциональных требований создадим матрицу атрибутов (Attribute Matrix) "Функциональные требования". После внимательной проработки указанного сценария прецедента сформируем список характеристик (Feachures), используя эту матрицу (рис. 9).

Рис. 9

На приведенном выше рисунке показан внешний вид проекта RequisitePro после создания необходимых требований и характеристик. Для удобства работы требования и характеристики находятся в своих папках. Нами определены следующие требования для прецедента Запись на элективный курс.


^ Создание трассировочной матрицы и отслеживание изменений в модели прецедентов


Далее следует позаботиться об удобстве отслеживания характеристик в функциональных требованиях после возникновения изменений в модели прецедентов. Для этого в папке "Трассировочные матрицы" создадим трассировочную матрицу (Traceability Matrix) "Требования -Характеристики". С помощью нее будет легко определить, какие характеристики необходимо просмотреть на предмет возможных изменений, если изменились любые прецеденты модели прецедентов (рис. 10).



Рис. 10


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

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

Для создания термов в глоссарии в проекте Requisite Pro необходимо открыть в этом проекте вордовский файл Glossary:




На странице 4 этого документа (в разделе Glossary) нужно выбрать пункт 2.3 <aGroupOfTerms>. Перед знакосочетанием <aGroupOfTerms> отработать Enter и вписать термины, которые мы собираемся включить в словарь проекта. Выделяем вписанный термин и отрабатываем на панели управления окна MS Word иконку “RequisitePro”, с помощью модуля New wizard отправляем наши термины в проект:

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

Заключение

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

^

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



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

3.1. Определение объектов и классов предметной области



В соответствии с определением, данным в первом разделе, под объектом (object) в UML понимается некоторое абстрактное представление конкретного объекта предметной области. Объект– это некоторая сущность реального мира или концептуальная сущность. Объектом называется концепция, абстракция или вещь с четко определенными границами и значением для системы [4].

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

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

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

Концептуальную модель следует создавать согласно принципам картографии:

  • Использовать применяемые на данной территории названия.

  • Исключать несущественные детали.

  • Не добавлять объекты, которые отсутствуют на данной территории.


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

Если операция или свойство объекта не отвечают целям системы, то они и не включаются в состав класса, хотя и могут представлять интерес для других целей. Понятие Человек может включать такие компоненты, как «рост» и «вес», но для информационной системы университета для описания класса Студент они не нужны.


Каждый класс может иметь атрибуты (свойства). Так, на рис. 3.* класс ^ Студент имеет атрибуты фио,пол, дата рождения и др. .

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

Классы могут иметь взаимосвязи, называемые отношениями. В нотации UML имеются несколько типов отношений (см. табл. 3.1).

Отношение

Функция

Нотация

Ассоциация

(Association)

Описание связей между экземплярами классов



Зависимость

(Dependency)

Отношение, существующее между двумя элементами модели



Обобщение

(Generalization)

Отношение между общим описанием и более специфическими его разновидностями; используется при наследовании и для объявления полиморфных типов



Реализация

(Realization)

Отношение между спецификацией и ее реализацией



Использование

(Usage)

Ситуация, когда для корректной работы одному элементу системы необходим другой элемент




“kind”





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

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

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

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


^

3.6. Определение отношений


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

Ассоциация (association) – это двунаправленная семантическая связь между классами.




Агрегационное отношение – это специальная форма ассоциации между целым и его частью или частями, то есть отношение типа «часть от» или «содержит».





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

0

0..1

0..n

1

1..n

n

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



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






^ Пример иерархии классов: транспортное средство, (судно, автомобиль, троллейбус), Титаник.

Пример множеств. Наследования: окно, окно с рамкой, окно с заголовком, окно с рамкой и заголовком.


4. На рис.4.3 подклассы Студент и Преподаватель наследуют свойства и поведение класса Пользователь.



^

3.2. Построение концептуальной модели





В UML существует несколько разновидностей класса: сущность, интерфейс и др. Для указания вида класса в UML введено понятие стереотипа (stereotype). Существует стандартный набор стереотипов, который, при необходимости, можно расширять.

Основные стереотипы класса – это сущность, граничный элемент, элемент управления, сервисный элемент и исключение. Соответственно, классы-интерфейсы имеют стереотип "boundary", классы-сущности - "entity", элемент управления – “control”, сервисный элемент - service”, исключение - exception.


К
ласс- сущность (entity class) используется для моделирования данных и поведения с длинным жизненным циклом. Этот тип классов может представлять сущности реального мира или внутренние элементы системы.

Граничные классы (boundary class) обеспечивают взаимодействие между окружающей средой и внутренними элементами системы. Такие классы представляют интерфейс для пользователя или другой системы (то есть для актера).

^ Управляющие классы (control class) служат для моделирования последовательного поведения одного или нескольких прецедентов и координации событий, реализующих заложенное в них поведение.

Атрибут - это значение, характеризующее объект в его классе. Примеры атрибутов: категория, баланс, кредит (атрибуты объектов класса счет); имя, возраст, вес (атрибуты объектов класса человек) и т.д. Среди атрибутов различаются постоянные атрибуты (константы) и переменные атрибуты. Постоянные атрибуты характеризуют объект в его классе (например, номер счета, категория, имя человека и т.п.). Текущие значения переменных атрибутов характеризуют текущее состояние объекта (например, баланс счета, возраст человека и т.п.); изменяя значения этих атрибутов, мы изменяем состояние объекта.

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





Следует отметить, что, говоря об объектах и их классах, мы не подразумеваем никакого объектно-ориентированного языка программирования. Это, в частности, выражается в том, что на данном этапе разработки программной системы следует рассматривать только такие атрибуты, которые имеют смысл в реальности (все атрибуты объектов класса счет - рисунок 2.1 - обладают этим свойством). Атрибуты связаны с особенностями общей реализации. Например, если известно, что будет использоваться база данных, в которой каждый объект имеет уникальный идентификатор, то включать этот идентификатор в число атрибутов объекта на данном этапе не следует. Дело в том, что, вводя такие атрибуты, мы ограничиваем возможности реализации системы. Так, вводя в качестве атрибута уникальный идентификатор объекта в базе данных, мы уже в самом начале проектирования отказываемся от использования СУБД, которые такой идентификатор не поддерживают.
^

3.3. Операции и методы


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



Рис. 2.2. Пример класса Файл


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

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

Каждой операции соответствует метод - реализация этой операции для объектов данного класса. Таким образом, операция - это спецификация метода, метод - реализация операции. Например, в классе файл может быть определена операция печать (print). Эта операция может быть реализована разными методами: (а) печать двоичного файла; (б) печать текстового файла и др. Логически эти методы выполняют одну и ту же операцию, хотя реализуются они разными фрагментами кода.

Каждая операция имеет один неявный аргумент - объект к которому она применяется. Кроме того, операция может иметь и другие аргументы (параметры). Эти дополнительные аргументы параметризуют операцию, но не связаны с выбором метода. Метод связан только с классом и объектом (некоторые объектно-ориентированные языки, например C++, допускают одну и ту же операцию с разным числом аргументов, причем используя то или иное число аргументов, мы практически выбираем один из методов, связанных с такой операцией; на этапе предварительного проектирования системы удобнее считать эти операции различными, давая им разные имена, чтобы не усложнять проектирование).

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

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

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

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



^ Рис 2.3. Открытые и закрытые атрибуты и операции

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

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

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

ИМЯ_КЛАССА

имя_атрибута 1: тип_1 = значение_по_умолчанию_1
имя_атрибута 2: тип_2 = значение_по_умолчанию_2
. . . . . . . . . . . . . . .


имя_операции_1 (список_аргументов_1): тип_результата
сигнатура_операции_2
сигнатура_операции_3
. . . . . . . . . . . . . . . .


Рис. 2.4. Полное представление объекта в OMT


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

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

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

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




Рис. 2.5. Возможные классы для системы AMT (банковское обслуживание)
^

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


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

^ Диаграммы статической структуры.
Классификаторы. Видимость атрибутов и операций.






+ public (открытая)
# protected (защищенная)
package (пакетная)
- private (cкрытая)


 ^ Видимость атрибутов

 Видимость операций




Диаграммы статической структуры.
Область действия атрибутов и операций классификатора.



 Область действия атрибутов


 Область действия операций

  • Для всех экземпляров классификатора {classifier}
    (подчеркнуто).



Если система содержит большое количество классов, они могут быть объединены в пакеты (рис. 4.1).





Рис. Архитектура системы «Учебный процесс»

^

3.4. Пример концептуальной модели информационной системы





3.5. Дальнейшее исследование и усовершенствование модели


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

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

Признаки пропущенного объекта (класса):

  • несимметричности связей и обобщений (наследований); для исправления ошибки необходимо добавить пропущенные классы;

  • несоответствие атрибутов и операций у класса; для исправления ошибки необходимо расщепить класс на несколько других классов, так чтобы атрибуты и операции новых классов соответствовали друг другу;

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

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

Признаки ненужного (лишнего) класса:

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

Признаки пропущенных зависимостей:

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

Признаки ненужных (лишних) зависимостей:

  • избыточная информация в зависимостях; для исправления ошибки необходимо исключить зависимости, не добавляющие новой информации, или пометить их как производные зависимости;

  • не хватает операций, пересекающих зависимость; для исправления ошибки необходимо подумать, не следует ли исключить такую зависимость.

Признаки неправильного размещения зависимостей:

  • имена ролей слишком широки или слишком узки для их классов; для исправления ошибки необходимо переместить зависимость вверх или вниз по иерархии классов.

Признаки неправильного размещения атрибутов:

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



^

4. Моделирование динамики поведения СППР.



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




Рис. 4.1. Диаграммы поведения системы


Для описания динамики используются диаграммы поведения (behavior diagrams), которые подразделяются на:

  • диаграммы состояний (statechart diagrams),

  • диаграммы активностей (activity diagrams) и

  • диаграммы взаимодействия (interaction diagrams), состоящие из:

  • диаграмм последовательности (sequence diagrams)

  • диаграмм взаимодействий (collaboration diagrams)


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

4.1. Представление конечных автоматов. Диаграмма активности. Диаграмма состояний.


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

Диаграммы состояний определяют модель конечного автомата, описывающего поведение класса. Состоянием (state) называется множество значений объекта одного класса, при которых объект реагирует на события одинаковым образом. Другими словами, все объекты в одном состоянии одинаково реагируют на какое-либо событие и производят в этом случае один и тот же эффект (effect), который может представлять собой действие (action) или деятельность (activity). Конечный автомат описывает небольшое количество состояний, в которых может находиться объект. Для каждого из состояний задаются последствия прихода каждого вида событий – производимый эффект и новое состояние объекта.

Каждое состояние класса задается своей вершиной, для которой определены входные и выходные состояния, а также условия перехода из состояния в состояние (guard condition). Условие – булево выражение значений атрибутов, которое допускает переход, только если оно верно. И действие, и проверка условия представляют собой поведение объекта и обычно реализуются в виде операций.

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

Автоматы, состояния и переходы.

Формализм машины конечных состояний (FSM, Final State Machine) представляет собой следующий кортеж:

FSM = (Q,,,,q0),

Qмножество символов, представляющих состояние,

- множество входных символов,

- множество выходных символов,

- функция перехода (трансформация состояния, transition):

QQ,

q0Qначальное состояние.

FSM может быть представлена в виде ориентированного графа состояний и переходов из одного состояния в другое. Вершины графа представляют собой состояния моделей, в дуги – переходы. Каждая дуга маркирована парой «условие - действие», где первое представляет условие перехода, а второе – результат.

На рис. приведен в качестве примера граф модели, у которой Q-{α, β}, Σ={a,b},

 ={ε,u,v}, q0=α и σ(α, b)=(β,v), σ(β,α)=(α,u). Выходной символ ε означает отсутствие действия, он обычно вводится для придания общности и используется для представления автопереходов: σ(α,а)=(α,ε), σ(β,b)=(β,ε). Входной символ b переводит модель в состояние β и на выходе появляется символ v. Последовательность символов входного алфавита вызывает последовательную смену состояний и производит последовательности символов выходного алфавита.




Рис.

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

Построение диаграммы состояний.

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




Рис. Пиктограммы для диаграмм состояний


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

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

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





Рис. Внутренние переходы и действия при входе и выходе

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



Рис. ***. Диаграмма состояний класса «Учебный курс»


Рис.



Рис. 2.30. Фрагмент диаграммы состояний ИСПП

при обработке сигналов тревоги


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

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

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

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

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

Деление композитного состояния на ортогональные области описывает процесс независимых параллельных вычислений. При входе в ортогональное состояние количество потоков управления увеличивается, так как в каждой из ортогональных областей активизируется одно прямое подсостояние. При выходе из ортогонального состояния количество потоков управления уменьшается. Часто параллельность реализуется в каждом из подсостояний с помощью отдельного объекта, но ортогональные состояния могут также представлять логический параллелизм внутри одного объекта. На рис. *** изображено разбиение композитного состоя­ния «занятие в университете» на параллельные составляющие. Часто бывает удобно использовать фрагмент одного конечного автомата в другом. Автомату можно дать имя и ссылаться на него из состояний других автоматов. Целевой автомат называется вложенным автоматом, а состояние, которое на него ссылается, - ссылкой на вложенный автомат (подавтомат). Это подразумевает (теоретически) подстановку копии того автомата, на который ссылаются (то есть описывающей его функции или процедуры), в место, откуда дела­ется ссылка, - своего рода подпрограмма, реализованная в виде конечного автомата.

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


На рис. Показано составное состояние с последовательными подсостояниями, моделирующее … dialing.






^ Составное состояние с последовательными подсостояниями

Составное состояние в сжатом виде.

На рис. Приведен пример составного состояния “занятия в университете” с параллельными подсостояниями.




Параллельные переходы


.

Переход в составное состояние. Переходы во вложенные состояния составного состояния. На конце таких переходов изображаются заглушки (stabs).







Историческое состояние (history state).


Точки перехода.



^ Статические точки перехода.



Динамические точки перехода.

Состояния синхронизации.




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








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

4.2. Диаграммы деятельности (activity diagrams).


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

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

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

Узлы деятельности могут быть вложенными. Диаграмма деятельности может иметь ветвления (branches), а также разделения (forking) управления между параллельными потоками. Параллельные потоки представляют собой элементы деятельности, которые объекты или люди могут совершать одновременно. Часто параллельность возникает в результате агрегации, когда у каждого объекта появляется свой собственный поток управления. Параллельные элементы деятельности могут осуществляться как одновременно, так и в любой последовательности.

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

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

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

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

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

На рис. *** представлена диаграмма деятельности, моделирующая выбор курса для преподавания.

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

«Разделы». Иногда на диаграмме нужно соотносить элементы деятельности с ответственностью за них - например, сгруппировать вместе все элементы деятельности одной организации. Разделение ответственности можно изобразить, поделив всю диаграмму на части (называемые разделами) вертикальными линиями (рис. ***). Линии делят диаграмму действий на несколько участков, чтобы показать, кто отвечает за выполнение действий на каждом участке. После этого диаграмма напоминает бассейн с плавательными дорожками, отсюда и другое название раздела - плавательная дорожка.

Для обозначения начального и конечного состояний в потоке управления используются специальные символы Start State и End State.

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

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

Если результатом выполнения элемента деятельности является несколько выходных значений или если за ним следуют несколько потоков управления, то стрелки начинаются от знака разделения (fork). Точно так же, в случае наличия нескольких входных параметров, стрелки заканчиваются на знаке слияния (join).

На рис. *** показана диаграмма деятельности, в которой «плавательным дорожкам» приписаны как элементы деятельности, так и объектные потоки.





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

Действия

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

4.3. Диаграмма последовательности действий. Диаграммы кооперации



Представление взаимодействия является более общим взглядом на объекты.

Введение

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

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

Взаимодействие

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

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

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

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

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

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

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

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

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

На рис. *** показана типичная диаграмма последовательности с асинхронными сообщениями.



Спецификация выполнения

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

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

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

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

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


Рис. 9.2. Диаграмма последовательности со спецификациями выполнения

Активным называется объект, которому принадлежит верхний элемент стека выполнения. У каждого активного объекта есть свой событийный поток управления, выполняющийся параллельно с другими активными объектами. Шапка активного объекта обозначается прямоугольником с двойными вертикальными линиями. Часто графическим обозначением активного объекта пренебрегают, поскольку на практике в нем нет особого смысла. Объекты, вызываемые активными объектами, называются пассивными. Они получают управление только на время вызова, а потом возвращают его.

Структурированные управляющие конструкции

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

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

Цикл (ключевое слово loop) имеет один вложенный фрагмент, который выполняется до тех пор, пока остается верным первое сторожевое условие данного вложенного фрагмента.

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

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

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

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

Выше (см. рис. 9.3) показана диаграмма последовательности, содержащая цикл с вложенным условным фрагментом.

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

В основе диаграммы коммуникации (communication diagram) лежит контекст, предоставляемый структурированным классификатором (в том числе кооперацией). Роли и соединители описывают конфигурации объектов и связей, которые могут возникнуть в экземпляре контекста. Когда создается экземпляр контекста, объектам назначаются роли, а связям - соединители. Соединители могут также обозначать различного рода временные связи, например аргументы или локальные переменные процедур. Моделируются только те объекты, которые присутствуют в данном контексте, хотя система как таковая может содержать и другие объекты. Иными словами, диаграмма коммуникации моделирует те объекты и связи, которые участвуют в реализации кооперации, и игнорирует все остальные.

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

На рис. ** изображена диаграмма коммуникации.




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

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

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

Кооперация объединяет в себе три базовые структуры, необходимые при вычислениях: структуру данных, поток управления и поток данных.

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

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

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

Сообщение выглядит на диаграмме как стрелка, идущая от линии жизни одного объекта к линии жизни другого объекта. Стрелки организованы согласно временной последовательности сообщений (см. примеры диаграмм на рис. 5.1 – 5.3).


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



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





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





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



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

2.4.1. Описание времени жизни объекта.
2.4.2. Несколько линий жизни объекта.
2.4.3. Сообщение-процедурый вызов и сообщение-событие.
2.4.4. Посылка объектом сообщения самому себе. Рекурсия.
2.4.5. Условная посылка сообщений.
2.4.6. Синхронизация работы объектов.
2.4.7. Указание временных интервалов.
2.4.8. Пример: обновление графа на диаграмме.
2.4.9. Пример: использование диаграммы при описании шаблона проектирования.

Диаграмма последовательности взаимодействия объектов.
Описание времени жизни объектов.




^ Создание объекта в течение интервала времени описываемого диаграммой.



^ В момент посылки сообщения объект уже существует.



Удаление объекта в течение интервала времени описываемого диаграммой.

Диаграмма последовательности взаимодействия объектов.
Описание времени жизни объектов.




^ Несколько линий жизни для разных условий посылки сообщений.

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




^ Сообщение - процедурный вызов.



Сообщение - событие.
Процедурный вызов происходит после получения сообщения


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




^ Посылка объектом сообщения update() самому себе.

Рекурсивная посылка сообщения more().

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




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




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



^ Асинхронный вызов операции



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

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




^ Диаграмма последовательности взаимодействия объектов.
Пример: обновление графа на диаграмме.



1   2   3   4   5   6   7   8   9   10   ...   13



Скачать файл (4180 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации