УРОВЕНЬ ПРЕДСТАВЛЕНИЯ
— способ организации и рассмотрения модели на одном уровне абстракции, который представляет горизонтальный срез архитектуры модели, в то время как разбиение представляет её вертикальный срез.
26
Рисунок 1. Общая схема взаимосвязей и представлений сложной системы в
процессе ООАП
Концептуальная модель строится на начальном этапе проектирования.
Последующие модели конкретизируют концептуальную модель, дополняя ее представлениями логического и физического уровня. При этом на каждом этапе ООАП данные модели последовательно дополняются все большим количеством деталей, что позволяет им более адекватно отражать различные аспекты конкретной реализации сложной системы.
ПАКЕТ
- основной способ организации элементов модели в языке UML.
Каждый пакет владеет всеми своими элементами, т.е. теми элементами, которые включены в него. При этом каждый элемент может принадлежать только одному пакету. В свою очередь, одни пакеты могут быть вложены в другие.
ПОДПАКЕТ
- пакет, который является составной частью другого пакета.
27
Рисунок 2. а) УГО пакета; б) УГО пакета с дополнительной информацией о
пакете
Рисунок 3. УГО пакетов, вложенных в другой пакет
28
Рисунок 4. УГО принадлежности пакетов
МОДЕЛЬ
– это подкласс пакета и представляет собой абстракцию физической системы, которая предназначена для вполне определенной цели
(например, логическая модель, модель проектирования и др.), при этом каждая такая модель имеет собственную точку зрения на физическую систему и свой уровень абстракции
Модели могут быть вложены друг в друга. Пакет может содержать несколько моделей одной и той же системы. Общая модель системы в контексте языка
UML содержит в себе модель анализа и модель проектирования.
29
Рисунок 5. Модель системы в виде пакетов моделей анализа и
проектирования
ПОДСИСТЕМА
– это группировка элементов модели, которые специфицируют простейшее поведение физической системы. При этом элементы подсистемы делятся на две части – спецификацию поведения и его реализацию.
Рисунок 6. УГО подсистемы в языке UML
12.
*ПАКЕТЫ В ЯЗЫКЕ UML. ГРАФИЧЕСКОЕ ИЗОБРА ЖЕНИЕ
СИСТЕМЫ И ПОДСИСТЕМЫ В ЯЗЫКЕ UML
30
ПАКЕТ
- основной способ организации элементов модели в языке UML.
Каждый пакет владеет всеми своими элементами, т.е. теми элементами, которые включены в него. При этом каждый элемент может принадлежать только одному пакету. В свою очередь, одни пакеты могут быть вложены в другие.
ПОДПАКЕТ
- пакет, который является составной частью другого пакета.
Рисунок 7. а) УГО пакета; б) УГО пакета с дополнительной информацией о
пакете
Рисунок 8. УГО пакетов, вложенных в другой пакет
31
Рисунок 9. УГО принадлежности пакетов
МОДЕЛЬ
– это подкласс пакета и представляет собой абстракцию физической системы, которая предназначена для вполне определенной цели
(например, логическая модель, модель проектирования и др.), при этом каждая такая модель имеет собственную точку зрения на физическую систему и свой уровень абстракции
Модели могут быть вложены друг в друга. Пакет может содержать несколько моделей одной и той же системы. Общая модель системы в контексте языка
UML содержит в себе модель анализа и модель проектирования.
Рисунок 10. Модель системы в виде пакетов моделей анализа и
проектирования
32
ПОДСИСТЕМА
– это группировка элементов модели, которые специфицируют простейшее поведение физической системы. При этом элементы подсистемы делятся на две части – спецификацию поведения и его реализацию.
Рисунок 11. УГО подсистемы в языке UML
13.
*КАНОНИЧЕСКИЕ ДИАГРАММЫ ЯЗЫКА UML
ДИАГРАММА КЛАССОВ
(Class diagram) — статическая структурная диаграмма, описывающая структуру системы, демонстрирующая классы системы, их атрибуты, методы и зависимости между классами.
ДИАГРАММА КОМПОНЕНТОВ
(Component diagram) — статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи
(зависимости) между компонентами. В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.
ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ
(Use case diagram, диаграмма прецедентов) — диаграмма, на которой отражены отношения, существующие между актёрами и вариантами использования.
ДИАГРАММА РАЗВЁРТЫВАНИЯ
(Deployment diagram, диаграмма размещения) — служит для моделирования работающих узлов
(аппаратных средств, англ. node) и артефактов, развёрнутых на них.
33
Диаграммы компонентов и развертывания служат для представления физических компонентов сложной системы и поэтому относятся к ее физической модели.
ДИАГРАММА ДЕЯТЕЛЬНОСТИ (Activity diagram) — диаграмма, на которой показано разложение некоторой деятельности на её составные части.
ДИАГРАММА СОСТОЯНИЙ (statechart diagram)
Диаграммы состояний и деятельности предназначены для моделирования поведения системы.
ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТИ (Sequence diagram) — диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.
ДИАГРАММА КООПЕРАЦИИ (collaboration diagram)
Диаграммы кооперации и последовательностей представляют собой разновидности логической модели, которые отражают динамические аспекты функционирования сложной системы.
14.
*ДИАГРАММА
ВАРИАНТОВ
ИСПОЛЬЗОВАНИЯ
КАК
КОНЦЕПТУАЛЬНОЕ ПРЕДСТАВЛЕНИЕ СИСТЕМЫ В ПРОЦЕССЕ ЕЕ
РАЗРАБОТКИ
ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ (use case diagram) — диаграмма, на которой изображаются отношения между актёрами и
вариантами использования, то есть описывает функциональное назначение системы (что бизнес-система должна делать в процессе своего функционирования).
Диаграмма вариантов использования - это исходное концептуальное представление или концептуальная модель системы в процессе ее проектирования и разработки.
34
Поведение разрабатываемой системы (то есть функциональность, обеспечиваемая системой) описывается с помощью функциональной модели, которая отображает:
системные прецеденты (use cases),
системное окружение (действующих лиц или актёров - actors);
связи между прецедентами и актёрами (диаграммы прецедентов - use cases diagrams).
Назначение диаграммы вариантов использования - проектируемая программная система представляется в форме так называемых вариантов использования, с которыми взаимодействуют внешние сущности или актеры.
В каждой системе обычно есть главная диаграмма прецедентов, которая отображает границы системы (актеров) и основное функциональное поведение системы (прецеденты). Другие диаграммы прецедентов могут создаваться при необходимости, например:
диаграмма, показывающая все прецеденты для определенного актера;
диаграмма, показывающая все прецеденты, реализованные на данной итерации;
диаграмма, показывающая определенный прецедент и все его отношения.
ВАРИАНТ ИСПОЛЬЗОВАНИЯ служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой и собственно выполнение вариантов использования.
АКТЁР - любой объект, субъект или система, взаимодействующая с моделируемой бизнес-системой извне и не являющийся частью системы. Это может быть человек, техническое устройство, программа или любая другая система, которая служит источником воздействия на моделируемую систему так, как определит разработчик.
Актёры могут:
только снабжать информацией систему;
35
только получать информацию из системы;
снабжать информацией и получать информацию из системы.
Рисунок 12. УГО актёра
С помощью прецедентов (use cases) моделируется диалог между актером и системой. Другими словами, они определяют возможности, обеспечиваемые системой для актера. Набор всех прецедентов системы определяет способы ее использования.
Рисунок 13. УГО прецедента
ПОТОК СОБЫТИЙ
(flow of events) для прецедента - это последовательность событий, необходимых для обеспечения требуемого поведения. Поток событий описывается в терминах того, «что» система должна делать.
Между актёром и прецедентом может существовать ассоциативное отношение (двухсторонняя или односторонняя).
ОТНОШЕНИЕ
(relationship) — семантическая связь между отдельными элементами модели.
Направление связи показывает,
кто является её инициатором
(актер или прецедент). Такой тип отношений изображается в виде линии, соединяющей взаимодействующие элементы. Направление связи обозначается стрелками на линии связи.
15.
*ОТНОШЕНИЯ НА ДИАГРАММАХ ИСПОЛЬЗОВАНИЯ
36
ОТНОШЕНИЕ
(relationship) — семантическая связь между отдельными элементами модели.
Направление связи показывает,
кто является её инициатором
(актер или прецедент). Такой тип отношений изображается в виде линии, соединяющей взаимодействующие элементы. Направление связи обозначается стрелками на линии связи.
В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования:
АССОЦИАЦИИ
(association relationship) - служит для обозначения специфической роли актёра при его взаимодействии с отдельным вариантом использования,
обозначается сплошной линией
между актёром и вариантом использования и указывает на то, что актер инициирует соответствующий вариант использования;
ВКЛЮЧЕНИЯ
(include relationship) - это разновидность отношения зависимости между базовым вариантом использования и его специальным случаем, обозначается как отношение зависимости в форме
пунктирной линии со стрелкой, направленной от базового
варианта использования к включаемому варианту использования
При этом данная линия помечается стереотипом <>;
РАСШИРЕНИЯ
(extend relationship) определяет взаимосвязь базового варианта использования с другим вариантом использования, функциональное поведение которого задействуется базовым не всегда, а только при выполнении дополнительных условий, обозначается как отношение зависимости в форме
пунктирной линии
со стрелкой, направленной от того варианта использования,
который
является
расширением
для
базового
варианта
использования
. Данная линия со стрелкой должна быть помечена стереотипом <>;
ОБОБЩЕНИЯ
(generalization relationship) - два и более актера могут иметь общие свойства, т.е. взаимодействовать с одним и тем же множеством вариантов использования одинаковым образом, обозначается
сплошной линией со стрелкой
(стрелка-обобщение)
в
форме незакрашенного треугольника, которая указывает на
родительский вариант использования
37
Рисунок 14. Графическое представление отношения ассоциации между актёром и вариантом использования Рисунок 15. Графическое изображение отношение включения между вариантами использования Рисунок 16. Графическое изображение отношения обобщения между вариантами использования 16.
*ФОРМАЛИЗАЦИЯ ФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ К
СИСТЕМЕ И ОСОБЕННОСТИ СПЕЦИФИКАЦИИ НА ДИАГРАММЕ
ИСПОЛЬЗОВАНИЯ
ТРЕБОВАНИЕ (requirement) - желательное свойство,
характеристика или условие, которым должна удовлетворять система в процессе своей эксплуатации.
СЦЕНАРИЙ (scenario) - определенная последовательность действий, которая описывает действия актеров и поведение моделируемой системы в форме обычного текста. Текст сценария должен дополнять или уточнять диаграмму вариантов использования, но не заменять ее полностью
38
Построение диаграммы вариантов использования - самый первый этап процесса ООАП, цель которого - представить совокупность функциональных требований к поведению проектируемой системы.
ПРИМЕЧАНИЕ
(note) предназначено для включения в модель произвольной текстовой информации, имеющей непосредственное отношение к контексту разрабатываемого проекта.
Рисунок 17. Пример примечания
39
40 17.
*ОБЪЕКТЫ И КЛАССЫ
Объект (object) - это некая сущность реального мира или концептуальная сущность. Объектом называется концепция, абстракция или вещь с четко определенными границами и значением для системы.
Объекты характеризуются:
СОСТОЯНИЕМ
(одно из условий, в которых он может находиться.
Состояние обычно меняется во времени и определяется атрибутами);
ПОВЕДЕНИЕМ
(как объект реагирует на запросы других объектов и что может делать сам объект. Поведение характеризуется с помощью операций (в системе регистрации курсов объект учебный курс может иметь операции добавить студента и удалить студента));
ИНДИВИДУАЛЬНОСТЬЮ
(каждый объект уникален, даже если его состояние идентично состоянию другого объекта).
Рисунок 18. Изображение объекта
КЛАСС
(class) - это описание группы объектов с общими свойствами
(атрибутами), поведением (операциями), отношениями с другими объектами и семантикой. Это шаблон для создания объекта.
На диаграммах UML класс представляется прямоугольником, разделенным на 3 области.
41
Рисунок 19. Класс на диаграммах UML
Имя класса может быть составным (Имя пакета :: Имя класса)
Рисунок 20. Составное имя класса
Рисунок 21. Объект класса на диаграммах UML
Имя объекта также может быть составным (Имя объекта :: Имя класса).
Рисунок 22. Составное имя объекта
Объект может быть анонимным, если неизвестно его настоящее имя.
Рисунок 23. Анонимный объект
Если неизвестен класс этого объекта, то тогда объект называется «сиротой».
42
Рисунок 24. Объект-"сирота" 18.
*СТЕРЕОТИПЫ И КЛАССЫ
КЛАСС (class) - это описание группы объектов с общими свойствами
(атрибутами), поведением (операциями), отношениями с другими объектами и семантикой. Это шаблон для создания объекта.
На диаграммах UML класс представляется прямоугольником, разделенным на 3 области.
Рисунок 25. Класс на диаграммах UML Рисунок 26. Объект класса на диаграммах UML Классы тоже могут иметь
СТЕРЕОТИПЫ. Стереотипы используются для
создания нового типа элемента моделирования, в данном случае для создания новых типов классов.
Виды стереотипов классов:
43
КЛАСС-СУЩНОСТЬ
(entity class) (или класс предметной области) используется для моделирования данных и поведения с длинным жизненным циклом. Этот тип классов может представлять сущности реального мира или внутренние элементы системы. Например, это заказ на диаграмме классов, посвящённой оформлению заказа в интернет-магазине.
Рисунок 27. Обозначение класса-сущности
ГРАНИЧНЫЕ КЛАССЫ
(boundary class) обеспечивают взаимодействие между окружающей средой и внутренними элементами системы. Для каждого взаимодействия между актером и прецедентом нужно создать хотя бы один граничный класс.
Рисунок 28. Обозначение граничных классов
УПРАВЛЯЮЩИЙ КЛАСС
отвечает за координацию действий других классов. Они служат для моделирования последовательного поведения одного или нескольких прецедентов и координации событий, реализующих заложенное в них поведение.
44
Рисунок 29. Изображение управляющего класса
19.
*ЭЛЕМЕНТЫ
ГРАФИЧЕСКОЙ
НОТАЦИИ
ДИАГРАММЫ
КЛАССОВ
ДИАГРАММА КЛАССОВ
(class diagram) — диаграмма языка UML, на которой представлена совокупность декларативных или статических элементов модели, таких как классы с атрибутами и операциями, а также связывающие их отношения. Она предназначена для представления статической структуры модели системы в терминологии классов ООП. Она может содержать интерфейсы, пакеты, отношения, отдельные экземпляры классификаторов
(объекты и связи).
КЛАСС
(class) — абстрактное описание множества однородных объектов, имеющих одинаковые атрибуты, операции и отношения с объектами других классов.
Рисунок 30. Изображение класса на диаграммах UML
ИМЯ КЛАССА
должно быть уникальным в пределах пакета, который может содержать одну или несколько диаграмм классов. Записывается по центру
45 секции имени полужирным шрифтом и должно начинаться с заглавной буквы.
КОНКРЕТНЫЙ КЛАСС (concrete class) — класс, на основе которого могут быть непосредственно созданы экземпляры или объекты.
АБСТРАКТНЫЙ КЛАСС (abstract class) — класс, который не имеет экземпляров или объектов.
АТРИБУТ (attribute)— содержательная характеристика класса, описывающая множество значений, которые могут принимать отдельные объекты этого класса. Общий формат записи отдельного атрибута класса следующий:
<квантор видимости> <имя атрибута> [кратность] :
<тип атрибута> = <исходное значение> {строка-свойство}
ВИДИМОСТЬ (visibility) — качественная характеристика описания элементов класса, характеризующая потенциальную возможность других объектов модели оказывать влияние на отдельные аспекты поведения данного класса.
Видимость в языке UML специфицируется с помощью квантора видимости
(visibility), который может принимать одно из 4-х возможных значений и отображаться при помощи специальных символов:
Символ " + " – обозначает атрибут с областью видимости типа общедоступный (public);
Символ " # " – обозначает атрибут с областью видимости типа защищенный (protected);
Символ " - " – обозначает атрибут с областью видимости типа закрытый
(private);
Символ " " - обозначает атрибут с областью видимости типа пакетный
(package).
Квантор видимости может быть опущен. Его отсутствие означает, что видимость атрибута не указывается.
Скачать 2.02 Mb.