70608

Диаграммы использования

Лекция

Информатика, кибернетика и программирование

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

Русский

2014-10-23

109.18 KB

0 чел.

Лекция 41

Диаграммы использования

Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. "Каждая функциональность" изображается в виде "прецедентов использования" (use case) или просто прецедентов. Прецедент — это типичное взаимодействие пользователя с системой, которое при этом:

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

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

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

На рис. 11.4 показано, что при исполнении прецедента " формирование заказа " возможно использование информации из предыдущего заказа, что позволит не вводить все необходимые данные. А при исполнении прецедентов " оценить риск сделки " и " согласовать цену " необходимо выполнить одно и то же действие — рассчитать стоимость заказа.


Рис. 11.4. Связи на диаграммах прецедентов

Динамические аспекты поведения системы отражаются приведенными ниже диаграммами.

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

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

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

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

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


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

  1.  вводятся строки заказа;
  2.  по каждой строке проверяется наличие товара;
  3.  если запас достаточен — инициируется поставка;
  4.  если запас недостаточен — инициируется дозаказ (повторный заказ).


Рис. 11.6. Кооперативная диаграмма прохождения заказа

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

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

Кооперативные диаграммы

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

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

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

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

Переходы имеют метки, которые синтаксически состоят из трех необязательных частей (см. рис. 11.7):


Рис. 11.7. Диаграмма состояний объекта «заказ»

<

Событие> <[Условие]> < / Действие>.

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

выполнить/< деятельность >.

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

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

Основными элементами диаграмм деятельности являются ( рис. 11.8):


Рис. 11.8. Диаграмма деятельности — обработка заказа

  1.  овалы, изображающие действия объекта;
  2.  линейки синхронизации, указывающие на необходимость завершить или начать несколько действий (модель логического условия "И");
  3.  ромбы, отражающие принятие решений по выбору одного из маршрутов выполнения процесса (модель логического условия "ИЛИ");
  4.  стрелки — отражают последовательность действий, могут иметь метки условий.

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

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

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

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

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

  1.  устройства — узлы системы, в которых данные не обрабатываются.
  2.  процессоры — узлы системы, осуществляющие обработку данных.

Для различных типов компонентов предусмотрены соответствующие стереотипы в языке UML.

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

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

На рис. 11.9 показана упрощенная схема элементов фрагмента корпоративной системы. "Коробки" представляют собой компоненты — приложения или внутренние подсистемы. Пунктирные линии отражают зависимости между компонентами.


Рис. 11.9. Диаграмма компонентов фрагмента КИС

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

Пакеты UML

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

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


 

А также другие работы, которые могут Вас заинтересовать

34738. Ревизские сказки как источник по генеалогии непривилегированных слоев населения 15.76 KB
  Это документы именной переписи податного населения Российской Империи XVIII середины XIX вв. Проведение реформы потребовало организации подушного учета населения. Ревизские сказки являлись поимёнными списками населения в которых указывались имя отчество и фамилия владельца двора его возраст имя и отчество членов семьи с указанием возраста отношение к главе семьи.
34739. Материалы всероссийской переписи населения 1897года как источник по генеалогии непривилегированных слоев населения 13.06 KB
  дают материалы Первой всероссийской переписи населения это прямой массовый статистический учет населения проводимый с целью определения его численности состава и размещения на определенный момент. Первый подробный проект переписи населения был представлен председателем Центрального статистического комитета П. Только почти через 20 лет этот проект был утвержден императором Николаем II согласно Положению о Первой всеобщей переписи населения Российской империи изданному в 1895 г.
34740. Церковные метрические книги как источник по генеалогии непривилегированных слоев населения 13.82 KB
  Метрические книги велись в России до революции в церковных приходах духовенством или особыми гражданскими чиновниками. Во второй части метрической книги также приводился порядковый номер и дата бракосочетания. Метрические книги велись в двух экземплярах: один направлялся на хранение в архив консистории учреждение с церковноадминистративными и судебными функциями которая подчинялась епархиальному архиерею второй оставался в церкви.
34741. Методика генеалогических исследований. Генеалогические таблицы и росписи 15.71 KB
  Поколенная роспись это нумерованное перечисление членов рода потомков родоначальника по мужской линии обоего пола по генеалогическому старшинству с выделением поколений и указанием при каждом члене рода номера его отца. Выделяются три наиболее употребительных: а все лица рода распределялись по коленам нумеровавшимся римскими цифрами перед представителем рода ставился порядковый номер арабскими цифрами а в конце строки ставился порядковый номер отца; как валовая нумерация б номер отца при сплошной нумерации переносится в начало...
34742. Историческая хронология. Предмет и задачи. Виды календарных систем. Основные понятия и термины 17.43 KB
  В этом календаре год состоял из 365 дней. по 30 дней каждый; в конце года добавлялось пять праздничных дней не входивших в состав месяцев. В течение каждых 19 лет считают 12 лет по 12 лунных месяцев по 29 30 дней и 7 лет по 13 лунных месяцев. лунносолнечный календарь является официальным в Израиле где начало года приходится на один из дней периода с 5 сентября по 5 октября.
34743. Древние календарные системы: Египет, Древняя Греция, Китай 18.83 KB
  Этот лунный календарь использовался на протяжении всей древнеегипетской истории как религиозный календарь фиксирующий время проведения праздников. Схематический гражданский календарь Новый календарь был построен по простой схеме. Поздний лунный календарь Хронологической единицей в нем как и в раннем лунном календаре служил лунный месяц начинавшийся в первый день невидимости Луны.
34744. Мусульманский календарь. Мусульманская система летоисчисления 13.08 KB
  Мусульманская система летоисчисления Мусульманский исламский календарь лунный календарь используемый в исламе для определения дат религиозных праздников а также как официальный календарь в некоторых мусульманских странах. Поэтому в мусульманских странах календарь называют календарём Хиджры. Такая система до сих пор используется в некоторых странах например в Пакистане и Бангладеш. В разных странах используются разные правила.
34745. Календарные системы в Древнем Риме. Реформа Юлия Цезаря 16.15 KB
  Последующие месяцы продолжали сохранять свои числовые обозначения: Квинтилис Quintilis пятый Секстилис Sextilis шестой Септембер September седьмой Октобер Oktober восьмой Новембер November девятый Децомбер December десятый Мартиус майус квинтилис и октобер имели по 31 дню а остальные месяцы состояли из 30 дней. Очень любопытна история распределения дней по месяцам. Первоначально год римского календаря как уже говорилось состоял из 304 дней. Чтобы...
34746. Григорианская реформа и григорианский календарь 14.62 KB
  Эта разница ежегодно накапливаясь привела через 128 лет к ошибке в одни сутки а через 1280 лет уже в 10 суток. Реформа должна была решить две основные задачи: вопервых ликвидировать накопившуюся разницу в 10 суток между календарным и тропическим годами вовторых максимально приблизить календарный год к тропическому чтобы в будущем разница между ними не была ощутимой. Григорианский календарь В григорианском календаре длительность года принимается равной 3652425 суток.