Шпоры по ТООМ

1-АБСЭБ- 11

Диаграммы реализации моделируемой системы. Диаграммы компонент (Component diagram) и  диаграммы размещения компонент (Deployment diagram). Компоненты и модули моделируемой системы, их стереотипы. 

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

Компонента – исходный код, бинарный код или run-time объект.

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

Главная диаграмма компонентов обычно представляет определенные для системы пакеты.

Компоненты исходного кода – это программные файлы, содержащиеся внутри пакетов. Классы в логическом представлении отображаются на компоненты в представлении компонентов

Диаграмма развертывания

Бывает в форме описания (описание типов) и в форме инстанциации (описание объектов).

Узел может иметь следующую семантику:

Компьютерный ресурс

Механическое устройство

Человеческий ресурс

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

Распределение процессов по узлам сети производится с учетом следующих факторов 

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

время отклика;

минимизация сетевого трафика;

мощность узла;

надежность оборудования и коммуникаций.

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

Основные стереотипы класса – это сущность, граничный элемент, элемент управления, сервисный элемент и исключение.

Отношения ассоциации, их атрибуты, роли, мощность и стереотипы. Примеры отношений.

Классы могут иметь взаимосвязи, называемые отношениями.

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

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

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

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

Стереотипы

<<association>>	Объекты вступают в отношение ассоциации. Один объект содержит ссылку на другой объект.
<<parameter>>	Один объект является параметром одной из операций другого объекта.
<<local>>	Один объект является локальной переменной в одной из операций другого объекта.
<<global>>	Один объект является глобальным по отношению к другому объекту.
<<self>>	Объект посылает сообщение самому себе.

Квалификатор

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

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

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

1-АБСЭБ- 12

1. Диаграммы деятельности (Activity diagram): простые и составные состояния деятельности, узлы принятия решений, распределение между классами объектов ответственности за деятельности.  Диаграммы деятельности Определение деятельности изображается в виде диаграммы деятельности. Диаграммы действий отражают динамику проекта и представляют собой схемы потоков управления в системе от действия к действию, а также параллельные действия и альтернативные потоки. В представлении деятельности используются конструкции, задающие синхронизацию. Выполнение этапов вычислений может быть как параллельным, так и последовательным. Состояния деятельности могут быть подвергнуты дальнейшей декомпозиции, вследствие чего выполняемую деятельность можно представить с помощью других диаграмм деятельности. Состояния деятельности не являются атомарными, то есть могут быть прерваны В определении деятельности задаются узлы деятельности. Узел деятельности представляет выполнение оператора в процедуре или шага в потоке работ. Узлы соединяются между собой потоками управления и потоками данных. Выполнение узла деятельности обычно начинается, когда на каждом из его входных потоков появляются маркеры управления. Далее узел ожидает завершения своих вычислений. Когда выполнение узла завершается, управление передается узлам, связанным с выходными потоками данного узла. Потоки деятельности аналогичны переходам по завершению: переход управления происходит, когда завершается выполнение, но можно определить действия, которые будут происходить при наступлении конкретных событий. Узлы деятельности могут быть вложенными. Диаграмма деятельности может иметь ветвления (branches), а также разделения (forking) управления между параллельными потоками. Параллельные потоки представляют собой элементы деятельности, которые объекты или люди могут совершать одновременно. Часто параллельность возникает в результате агрегации, когда у каждого объекта появляется свой собственный поток управления. Параллельные элементы деятельности могут осуществляться как одновременно, так и в любой последовательности. В конечном счете, листами графа деятельности являются действия. Действием называется примитивная, предопределенная деятельность - например, чтение или изменение значения атрибута или ссылки, создание или разрушение объекта, отправка сигнала. «Разделы». Иногда на диаграмме нужно соотносить элементы деятельности с ответственностью за них - например, сгруппировать вместе все элементы деятельности одной организации. Разделение ответственности можно изобразить, поделив всю диаграмму вна части (называемые разделами) вертикальными линиями. Линии делят диаграмму действий на несколько участков, чтобы показать, кто отвечает за выполнение действий на каждом участке.

2. Средства нотации языка UML для описания статической структуры модели системы. Структурирование модели системы на пакеты, модели и подсистемы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. – диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними. На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами. Стереотипы – это механизм, позволяющий разделять классы на категории. В языке UML определены три основных стереотипа классов: Boundary (граница), Entity (сущность) и Control (управление). Структурирование модели системы на пакеты Пакеты применяют, чтобы сгруппировать классы, обладающие некоторой общностью. Существует несколько наиболее распространенных подходов к группировке. Во-первых, можно группировать их по стереотипу. В таком случае получается один пакет с классами-сущностями, один с граничными классами, один с управляющими классами и т.д. Этот подход может быть полезен с точки зрения размещения готовой системы, поскольку все находящиеся на клиентских машинах пограничные классы уже оказываются в одном пакете. Другой подход заключается в объединении классов по их функциональности. Например, в пакете Security (безопасность) содержатся все классы, отвечающие за безопасность приложения. В таком случае другие пакеты могут называться Employee Maintenance (Работа с сотрудниками), Reporting (Подготовка отчетов) и Error Handling (Обработка ошибок). Преимущество этого подхода заключается в возможности повторного использования. Таким образом, диаграмма пакетов представляет собой диаграмму, содержащую пакеты классов и зависимости между ними. Строго говоря, пакеты и зависимости являются элементами диаграммы классов

1-АБСЭБ- 13

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

2. Примеры использования UML для построения визуальных моделей. Модель системы электронной торговли [ смотри в приложении ]

1-АБСЭБ- 14

1. Диаграммы классов и объектов. Стереотипы как средства расширения языка UML В UML существует несколько разновидностей класса: сущность, интерфейс и др. Для указания вида класса в UML введено понятие стереотипа (stereotype). Существует стандартный набор стереотипов, который, при необходимости, можно расширять. Основные стереотипы класса – это сущность, граничный элемент, элемент управления, сервисный элемент и исключение. Соответственно, классы-интерфейсы имеют стереотип "boundary", классы-сущности - "entity", элемент управления – “control”, сервисный элемент - ”service”, исключение - ” exception”. Класс- сущность (entity class) используется для моделирования данных и поведения с длинным жизненным циклом. Этот тип классов может представлять сущности реального мира или внутренние элементы системы. Граничные классы (boundary class) обеспечивают взаимодействие между окружающей средой и внутренними элементами системы. Такие классы представляют интерфейс для пользователя или другой системы (то есть для актера). Управляющие классы (control class) служат для моделирования последовательного поведения одного или нескольких прецедентов и координации событий, реализующих заложенное в них поведение.

2. Диаграммы последовательности взаимодействия (Sequence diagram): описание временной последовательности посылки сообщений между диаграммами На диаграммах последовательностей внимание акцентируется прежде всего на временной упорядоченности сообщений. Для создания такой диаграммы надо прежде всего расположить объекты, участвующие во взаимодействии, в верхней ее части вдоль оси X. Обычно инициирующий взаимодействие объект размещают слева, а остальные - правее (тем дальше, чем более подчиненным является объект). Затем вдоль оси Y размещаются сообщения, которые объекты посылают и принимают, причем более поздние оказываются ниже. Это дает читателю наглядную картину, позволяющую понять развитие потока управления во времени. Диаграммы последовательностей характеризуются двумя особенностями, отличающими их от диаграмм кооперации. Во-первых, на них показана линия жизни объекта. Это вертикальная пунктирная линия, отражающая существование объекта во времени. Большая часть объектов, представленных на диаграмме взаимодействий, существует на протяжении всего взаимодействия, поэтому их изображают в верхней части диаграммы, а их линии жизни прорисованы сверху донизу. Объекты могут создаваться и во время взаимодействий. Линии жизни таких объектов начинаются с получения сообщения со стереотипом create. Объекты могут также уничтожаться во время взаимодействий; в таком случае их линии жизни заканчиваются получением сообщения со стереотипом destroy, а в качестве визуального образа используется большая буква X, обозначающая конец жизни объекта. Если объект на протяжении своей жизни изменяет значения атрибутов, состояние или роль, это можно показать, поместив копию его пиктограммы на линии жизни в точке изменения. Вторая особенность этих диаграмм - фокус управления. Он изображается в виде вытянутого прямоугольника, показывающего промежуток времени, в течение которого объект выполняет какое-либо действие, непосредственно или с помощью подчиненной процедуры. Верхняя грань прямоугольника выравнивается по временной оси с моментом начала действия, нижняя - с моментом его завершения (и может быть помечена сообщением о возврате). Вложенность фокуса управления, вызванную рекурсией (то есть обращением к собственной операции) или обратным вызовом со стороны другого объекта, можно показать, расположив другой фокус управления чуть правее своего родителя (допускается вложенность произвольной глубины). Если место расположения фокуса управления требуется указать с максимальной точностью, можно заштриховать область прямоугольника, соответствующую времени, в течение которого метод действительно работает и не передает управление другому объекту. Сообщения (message) связывают объекты между собой и передают информацию о выполняемом действии. Каждое сообщение представляется на диаграмме сплошной линией со стрелкой на конце, проведенной от линии жизни одного объекта к линии жизни другого объекта. Возможна посылка сообщения объектом самому себе - самоделегирование. В этом случае линия может начинаться и заканчиваться около символа объекта. Линия помечается именем сообщения (операция или сигнал) и значениями его аргументов. Сообщения могут быть помечены условием перехода, которое располагается в квадратных скобках. Сообщения могут быть следующих типов. Асинхронные:сообщения рисуются линией с половинкой стрелки на конце. Асинхронное сообщение не блокирует работу вызывающего объекта..Асинхронные сообщения можно использовать для создания нового объекта или для установления связи с уже выполняемой ветвью процесса. Вызов процедуры:рисуется как заполненная стрелка. Возвращение из процедуры подразумевается неявно и на диаграмме не отображается. Возврат ставиться явно в том случае, если это необходимо для большей ясности и представляется меткой (короткая поперечная линия), расположенной около адресата возврата. Обычно стрелка с сообщением рисуется горизонтально. Это символизирует, что сообщение передается мгновенно и ничего не может произойти в момент передачи. Если на передачу сообщения необходимо какое-то время, в течение которого может что-нибудь произойти, то линия со стрелкой может быть ломаной.

1-АБСЭБ- 15

1. Диаграммы деятельности (Activity diagram): простые и составные состояния деятельности, узлы принятия решений, распределение между классами объектов ответственности за деятельности.  Диаграммы деятельности Определение деятельности изображается в виде диаграммы деятельности. Диаграммы действий отражают динамику проекта и представляют собой схемы потоков управления в системе от действия к действию, а также параллельные действия и альтернативные потоки. В представлении деятельности используются конструкции, задающие синхронизацию. Выполнение этапов вычислений может быть как параллельным, так и последовательным. Состояния деятельности могут быть подвергнуты дальнейшей декомпозиции, вследствие чего выполняемую деятельность можно представить с помощью других диаграмм деятельности. Состояния деятельности не являются атомарными, то есть могут быть прерваны В определении деятельности задаются узлы деятельности. Узел деятельности представляет выполнение оператора в процедуре или шага в потоке работ. Узлы соединяются между собой потоками управления и потоками данных. Выполнение узла деятельности обычно начинается, когда на каждом из его входных потоков появляются маркеры управления. Далее узел ожидает завершения своих вычислений. Когда выполнение узла завершается, управление передается узлам, связанным с выходными потоками данного узла. Потоки деятельности аналогичны переходам по завершению: переход управления происходит, когда завершается выполнение, но можно определить действия, которые будут происходить при наступлении конкретных событий. Узлы деятельности могут быть вложенными. Диаграмма деятельности может иметь ветвления (branches), а также разделения (forking) управления между параллельными потоками. Параллельные потоки представляют собой элементы деятельности, которые объекты или люди могут совершать одновременно. Часто параллельность возникает в результате агрегации, когда у каждого объекта появляется свой собственный поток управления. Параллельные элементы деятельности могут осуществляться как одновременно, так и в любой последовательности. В конечном счете, листами графа деятельности являются действия. Действием называется примитивная, предопределенная деятельность - например, чтение или изменение значения атрибута или ссылки, создание или разрушение объекта, отправка сигнала. «Разделы». Иногда на диаграмме нужно соотносить элементы деятельности с ответственностью за них - например, сгруппировать вместе все элементы деятельности одной организации. Разделение ответственности можно изобразить, поделив всю диаграмму вна части (называемые разделами) вертикальными линиями. Линии делят диаграмму действий на несколько участков, чтобы показать, кто отвечает за выполнение действий на каждом участке.

2. Сравнительный анализ Case – средств моделирования информационных систем Rational ROSE способен решить задачи, связанные с объектным моделированием и проектированием: от общей модели процессов (абстрактной) предприятия до конкретной (физической) модели класса в создаваемом программном обеспечении. Работа в Rational Rose заключается в проектировании определенного вида диаграмм. Разработчик может задавать при этом все свойства объектов, отношения и взаимодействие друг с другом Проектировщик (аналитик) всегда может показать заказчику не абстрактное словесное описание процесса, а его конкретную модель на экране ПК (или в печатном виде), что позволяет быстрее согласовать с заказчиком все детали планируемой системы. Возможности: кодогенерация, возможность обратного проектирования – реинжениринга, Round-trip engineering – сочетает возможности первых двух подходов, когда создается система, а по прохождении некоторого времени эволюционного периода (доработок) подвергается вновь реинженирингу и вновь кодогенерации. SoDA является инструментом автоматизации документооборота моделирования и проектрования RequisitePro – это удобный инструмент для ввода и управления требованиями, который может использоваться всеми участниками команды. Продукт позволяет в наглядной форме получать, выводить, структурировать наборы вводимых требований. Для каждого требования поддерживается набор атрибутов, позволяющий эффективно управлять проектом на основе задания иерархий требований, установки их приоритетов, сортировки, назначения требований конкретным исполнителям. Для требований предусмотрен, предопределен набор атрибутов, который может быть расширен пользователем по своему усмотрению, что позволяет характеризовать требования в соответствии с представлениями пользователя. ClearQuest является мощным средством управления запросами на изменение (change request management – CRM), специально разработанным с учетом динамической и сложной структуры процесса разработки ПО. ClearQuest отслеживает и управляет любым типом действий, приводящих к изменениям в течение всего жизненного цикла продукта, помогая, тем самым, организациям более предсказуемым (правильным) образом создавать качественное ПО. Основные задачи, решаемые посредством ClearQuest: Управлять изменениями, возникающими в ходе процесса разработки ПО. Оптимизировать путь прохождения запросов на изменения, а также связанные с ним формы и процедуры. Через World Wide Web поддерживать связь внутри команд, разделенных территориально. Внедрить надежный и проверенный процесс CRM, либо изменить уже существующий процесс для удовлетворения специфическим требованиям. С помощью богатых возможностей графического представления информации и отчетов визуально анализировать полученный прогресс проекта. Интегрироваться со средствами конфигурационного управления, такими как Rational’s ClearCase, позволяя создавать связи между запросами на изменение и развитие кода.

1-АБСЭБ- 16

1. Отношения зависимости, их стереотипы. Примеры отношений. Зависимостью (Dependency) называется отношение использования, определяющее, что изменение в спецификации одной может повлиять на другую сущность, которая ее использует , причем обратное в общем случае неверно. Графически зависимости изображают в виде пунктирной линии со стрелкой, направленной в сторону той сущности, от которой зависит еще одна. Применяйте зависимости, если хотите показать, что одна сущность использует другую. Для большинства отношений использования вполне достаточно обычной зависимости без каких-либо дополнений. Но если необходимо передать некий смысловой нюанс, то стоит учесть, что в UML определен целый ряд стереотипов, применимых к зависимостям. Всего существует 17 таких стереотипов, объединенных в шесть групп. Прежде всего, это восемь стереотипов, применимых к отношениям зависимости между классами и объектами на диаграмме классов. bind- определяет, что источник инстанцирует целевой шаблон с заданными фактическими параметрами. Этот стереотип используют при моделировании деталей шаблонов классов. Например, отношения между шаблоном класса- контейнера и экземпляром этого класса моделируются как зависимость bind. Стереотип bind должен содержать список фактических аргументов, соответствующих формальным аргументам шаблона; derive- показывает, что источник может быть вычислен по целевому элементу. С помощью этого стереотипа моделируют отношения между двумя атрибутами или ассоциациями, причем один из соотносимых элементов является конкретным, а другой - концептуальным. Пример: класс Человек имеет атрибут ДатаРождения(конкретный) и атрибут Возраст. Отношения между ними можно определить с помощью зависимости типа derive, при этом Возраст будет производным от ДатаРождения; friend- указывает, что источнику даются специальные права видимости свойств цели . Используйтся этот стереотип для моделирования отношений, подобных отношениям между классом и его друзьями в языке C++; instanceOf - говорит, что исходный объект является экземпляром целевого классификатора; instantiate- показывает, что источник создает экземпляры целевого элемента. powertype- означает, что все объекты целевого классификатора являются потомками заданного родителя refine- свидетельствует, что источник находится на более низком уровне абстракции, чем цель. Данный стереотип используется для моделирования концептуально одинаковых классов, рассматриваемых на различных уровнях абстракции. Пример: класс Клиент, возникший на стадии анализа, будет уточнен в фазе проектирования, в результате чего появится более детальный класс Клиент вместе со своей реализацией; use- показывает, что семантика исходного элемента зависит от семантики открытой части целевого. Этот стереотип позволяет явно указать, что зависимость по своему типу принадлежит к отношениям использования, в отличие от отношений зависимости, обозначаемых другими стереотипами. Следующая группа, применяется для описания отношений зависимости между пакетами: access- показывает, что исходный пакет имеет право ссылаться на элементы целевого пакета; import- вид доступа, определяющий, что открытое содержание целевого пакета входит в простое пространство имен источника, как если бы оно было там объявлено. Пример:что целевой пакет Тсодержит класс С. Если определить зависимость типа access от S к Т, то элементы S могут ссылаться на С, используя его полностью квалифицированное имя Т::С. Если же от пакета S к Топределена зависимость типа import, то элементы S могут ссылаться на класс С, используя простые имена, то есть не квалифицируя имя целиком. Стереотипы применимые к отношениям зависимости между прецедентами: extend- показывает, что целевой прецедент расширяет поведение исходного; include- говорит о том, что исходный прецедент явным образом включает в себя поведение целевого. При моделировании взаимодействий между объектами используют следующие три стереотипа: become- сообщает, что целевой объект - тот же исходный, но в более поздний момент времени и, возможно, с другими значениями, состоянием или ролями; call- указывает, что исходная операция вызывает целевую; сору- говорит, что целевой объект является точной, но независимой копией исходного. В контексте автоматов применяют только один стереотип. send- определяет, что исходная операция посылает событие целевому объекту. Его используют для моделирования операций (например, входящей в состав действия, ассоциированного с изменением состояния), которые отправляют заданное событие целевому объекту (с ним, в свою очередь, может быть ассоциирован автомат). Фактически зависимости типа send позволяют связать вместе независимые автоматы. Наконец, последний стереотип встречается в контексте организации элементов системы в подсистемы и модели: trace- показывает, что целевой объект является историческим предшественником исходного. Его применяют при моделировании отношений между элементами различных моделей.

2. Диаграммы переходов и состояний (Statechart diagram): простые и составные состояния, события, простые и сложные переходы. Последовательности посылки сообщений между диаграммами. Диаграммы состояний используются для моделирования динамических аспектов системы. По большей части под этим подразумевается моделирование поведения реактивных объектов. Реактивным называется объект, поведение которого лучше всего характеризуется его реакцией на события, произошедшие вне его собственного контекста. У реактивного объекта есть четко выраженный жизненный цикл, когда текущее поведение обусловлено прошлым. Диаграммы состояний можно присоединять к классам, прецедентам или системе в целом для визуализации, специфицирования, конструирования и документирования динамики отдельного объекта. Диаграмма состояний (Statechart diagram) показывает автомат, фокусируя внимание на потоке управления от состояния к состоянию. Автомат (State machine) -это описание последовательности состояний, через которые проходит объект на протяжении своего жизненного цикла, реагируя на события, - в том числе описание реакций на эти события. Состояние (State) - это ситуация в жизни объекта, на протяжении которой он удовлетворяет некоторому условию, осуществляет определенную деятельность или ожидает какого-то события.Событие (Event) - это спецификация существенного факта, который происходит во времени и пространстве. В контексте автоматов событие - это стимул, способный вызвать срабатывание перехода. Переход (Transition) - это отношение между Двумя состояниями, показывающее, что объект, находящийся в первом состоянии, должен выполнить некоторые действия и перейти во второе состояние, как только произойдет определенное событие и будут выполнены заданные условия. Деятельность (Activity) -это продолжающееся неатомарное вычисление внутри автомата. Действие (Action) - это атомарное вычисление, которое приводит к смене состояния или возврату значения. Диаграмма состояний изображается в виде графа с вершинами и ребрами. Обычно диаграмма состояний включает в себя: -простые и составные состояния -переходы вместе с ассоциированными событиями и действиями. У простого состояния нет внутренней структуры, только набор переходов и, возможно, действия при входе и выходе Cоставным называется состояние, которое можно разложить на области, содержащие одно или несколько прямых подсостояний. Переход, исходящий из внешнего составного состояния, относится ко всем вложенным состояниям. Внешнее состояние разбивается на несколько внутренних состояний, каждое из которых наследует его переходы. В каждый момент времени активным может быть только одно из прямых подсостояний. Когда объект находится во внешнем состоянии, он может находиться в любом из его внутренних состояний. Простой переход (simple transition) представляет собой связь между двумя объектами, показывающую когда объект может перейти из первого состояния во второе и выполняющую определенное действие, если произошло определенное событие. Событие может иметь параметры, которые доступны для действий, определенных на переходе или для действий, инициирующих последующее событие. События обрабатываются мгновенно. Если событие не вызывает никакого перехода, то оно просто игнорируется. Если вызывается сразу несколько переходов, то инициируется только один из них. Сложный переход представляется на диаграмме состояний коротким вертикальным закрашенным прямоугольником. От прямоугольника может исходить одна или несколько линий со стрелками на конце, проведенных к конечным состояниям. К символу сложного перехода могут быть проведены одна или несколько линий со стрелками на конце, проведенных от исходных состояний. Строка перехода располагается около данного символа. Конкретные линии, проведенные к определенным состояниям не могут иметь своих строк перехода. Сообщения посылаются выполняемым в объекте действием множеству объектов-адресатов. Множество объектов-адресатов может содержать в себе от одного объекта до всей системы. Посылка сообщения на диаграмме представляется сплошной линией со стрелкой на конце, проведенной от данного объекта к объекту-адресату. Стрелка помечается именем события, списком его аргументов. Посылка сообщений между диаграммами состояний представляется пунктирной линией со стрелкой на конце, проведенной от отправителя к адресату.