Файл: Отчет по учебной (ознакомительной) практике Лексина А. О направление 09. 03. 02 Информационные системы и технологии.docx

ВУЗ: Не указан

Категория: Отчет по практике

Дисциплина: Не указана

Добавлен: 11.01.2024

Просмотров: 119

Скачиваний: 1

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Продолжение таблицы 2

1

2

3

4




Вариант использования
(use case)



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

Состояние
(state)



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

Кооперация
(collaboration)



Описание совокупности экземпляров актеров, объектов и их взаимодействия в процессе решения некоторой задачи

Компонент
(component)



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

Интерфейс
(interface)


iРасчет

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

Узел
(node)



Физическая часть системы (компьютер, принтер и т. д.), предоставляющая ресурсы для решения задачи

Группирующая

Пакет
(package)



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

Фрагмент
(fragment)



Область специфического взаимодействия экземпляров актеров и объектов.
Любая диаграмма в UML также является фрагментом – фрагментом (частью) проекта.

Раздел деятельности
(activity partition)



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


Окончание таблицы

1

2

3

4




Прерываемый регион
(interruptible activity region)



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

Поясняющая

Примечание
(comment)



Комментарий к элементу. Присоединяется к комментируемому элементу штриховой линией

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

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

Таблица 1.2. Декомпозируемые сущности

Наименование

Обозначение

Диаграмма

Скрытое составное состояние



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

Скрытый фрагмент взаимодействия



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

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



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


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

Таблица 1.3. Отношения

Наименование

Обозначение

Определение (семантика)

Ассоциация (association)



Отношение, описывающее значимую связь между двумя и более сущностями. Наиболее общий вид отношения

Агрегация (aggregation)



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

Композиция (composition)



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

Зависимость (dependency)



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

Обобщение (generalization)



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

Реализация (realization)



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


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

- любое количество экземпляров, в том числе и ни одного

- целое неотрицательное число – кратность строго фиксирована и равна указанному числу (например: 1, 2 или 5);

- диапазон целых неотрицательных чисел "первое число .. второе число" (например: 1..5, 2..10 или 0..5);

- диапазон чисел от конкретного начального значения до произвольного конечного "первое число .. *" (например: 1..*, 5..* или 0..*);

- перечисление целых неотрицательных чисел и диапазонов через запятую (например: 1, 3..5, 10, 15..*).

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

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

Таблица 1.4. Механизмы расширения

Наименование

Обозначение

Определение (семантика)

Стереотип
(stereotype)

« »

Обозначение, уточняющее семантику элемента нотации (например: зависимость со стереотипом «include» рассматривается, как отношение включения, а класс со стереотипом «boundary» – граничный класс)

Сторожевое условие
(guard condition)

[ ]

Логическое условие (например: [A > B] или [идентификация выполнена])

Ограничение
(constraint)

{ }

Правило, ограничивающее семантику элемента модели (например, {время выполнения менее 10 мс})

Помеченное значение
(tagged value)

{ }

Новое или уточняющее свойство элемента нотации (например: {version = 3.2})


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



     



     



a) стандартное обозначение

     

б) стандартное обозначение
с текстовым стереотипом

     

в) графический стереотип

Рис. 1.1. - Примеры стандартного и стереотипного отображения класса

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

Диаграмма

Назначение

Тип диаграммы (модели ПС)

по степени физической реализации

по отображению динамики


по отображаемому аспекту

1

2

3

4

5

Вариантов использования

Отображает функции системы, взаимодействие между актерами и функциями

Логическая

Статическая

Статическая

Классов

Отображает набор классов, интерфейсов и отношений между ними

Логическая или физическая


Статическая

Функционально-информационная

Поведения

Состояний

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

Логическая

Динамическая

Поведенческая

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

Отображает бизнес-процессы в системе (описание алгоритмов поведения)

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

Последова-тельности

Отображает последовательность передачи сообщений между объектами и актерами

Последова-тельности

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

Реализации

Компонентов

Отображает компоненты системы (программы, библиотеки, таблицы и т.д.) и связи между ними

Физическая

Статическая

Компонентная

Развертывания

Отображает размещение компонентов по узлам сети, а также ее конфигурацию