Анализ требований и определение спецификаций при объектном подходе

Август 21, 2022

Главная
Информатика
Анализ требований и определение спецификаций при объектном подходе

Содержание

2. Модель — упрощенное представление реальности. С точки зрения программирования модель — это чертеж системы. Моделирование необходимо
3. UML объединяет несколько моделей: Модель использования содержит описание функций программного обеспечения с точки зрения пользователя. Логическая
4. UML предлагает дополняющие друг друга диаграммы: - диаграммы вариантов использования (прецедентов); - диаграммы классов; - диаграммы
5. CASE-средство Rational Rose формирует документы: диаграммы классов; диаграммы состояний; диаграммы сценариев; диаграммы модулей; диаграммы процессов; спецификации
6. Определение прецедентов (вариантов использования) Прецеденты (варианты использования — Use Cases) — это подробные процедурные описания вариантов
7. Пример 1 Анализ функциональных требований и пользователей системы тестирования (модуль обучающей системы). Система тестирования прежде всего
8. Пример 1 На начальном этапе создания системы можно ограничиться только двумя важными ролями действующих лиц (акторами):
9. Пример 1 Краткое описание варианта использования
10. Пример 1 Подробное описание варианта использования
11. Диаграммы вариантов использования а — актор; б — вариант использования; в — связь.
12. Диаграмма вариантов использования тестовой системы
13. Отношения прецедентов Между актером и прецедентом может существовать ассоциативное отношение. Такой тип связи часто называют коммуникативной
14. Отношения прецедентов
15. Поток событий Поток событий (flow of events) для прецедента — это последовательность событий, необходимых для обеспечения
16. Поток событий В каждом проекте должен использоваться стандартный шаблон для создания документа, описывающего поток событий, например:
17. Пример 2 Документ с описанием потока событий для прецедента выбор курсов для преподавания. 1. Поток событий
18. Пример 2 Если выбрана операция добавить, S-1: выполняется поток добавить учебный курс. Если выбрана операция удалить,
19. Пример 2 1.3. Под-потоки S-1: добавить учебный курс Система отображает диалоговое окно, содержащее поле для ввода
20. Пример 2 S-3: просмотреть расписание Система получает (Е-8) и отображает следующую информацию для всех учебных курсов,
21. Пример 2 1.4. Альтернативные потоки Е-1: введен неверный идентификационный номер преподавателя. Пользователь должен повторить ввод идентификационного
22. Пример 2 Е-5: преподаватель не может быть прикреплен к выбранному учебному курсу. Информация сохраняется, система осуществит
23. Пример 2 Главная диаграмма прецедентов для системы регистрации учебных курсов
24. Сценарий Сценарий (scenario) — это элемент прецедента. Он представляет собой одиночный проход по потоку событий для
25. Сценарий Сценарии описывают порядок того, как обязанности, возложенные на прецеденты, распределяются среди объектов и классов в
26. Поток событий для прецедента описывается словами, тогда как сценарии отображаются с помощью диаграмм взаимосвязи (interaction diagrams).
27. Диаграмма последовательностей системы Диаграмма последовательностей системы — графическая модель, которая для определенного сценария варианта использования показывает
28. Диаграмма последовательностей системы Наименования объектов на диаграмме последовательности действий
29. Диаграмма последовательностей системы Нотация языка UML для объектов и сообщений на диаграмме последовательности действий
30. Диаграмма последовательностей системы Диаграмма последовательности действий с объектом предмет, присвоенным классу предмет, для сценария создание учебного
31. Диаграмма последовательностей системы Фокус управления
32. Диаграмма последовательностей системы Диаграмма последовательности для моделирования процесса телефонного разговора с использованием обычной телефонной сети.
33. Диаграммы взаимодействия Диаграмма взаимодействий (collaboration diagram) — это альтернативный способ отображения сценариев. Такой тип диаграммы показывает
34. Диаграмма взаимодействия
35. Диаграммы деятельностей (действий) Нотация языка UML для элементов диаграммы действий
36. Фрагмент диаграммы деятельности для алгоритма нахождения корней квадратного уравнения
37. Диаграммы деятельностей (действий) Линия синхронизации
38. Диаграмма деятельности процесса приготовления напитка Линия синхронизации
39. Диаграмма деятельности процесса Линия синхронизации
40. Диаграммы состояний Выход из строя Ремонт Диаграмма состояний по существу является графом специального вида, который представляет
41. Диаграммы состояний Диаграмма состояний для моделирования почтовой программы-клиента
42. Диаграммы классов UML предлагает использовать три уровня диаграмм классов в зависимости от степени их детализации: -
43. Диаграммы классов Диаграмма классов может отражать различные взаимосвязи между отдельными сущностями предметной области, такими как объекты
44. Диаграммы классов Графическое изображение класса на диаграмме классов
45. Диаграммы классов Примеры графического изображения классов на диаграмме
46. Диаграммы классов Атрибуты класса Во второй секции прямоугольника — графического изображения класса — записываются его атрибуты
47. Диаграммы классов Квантор видимости: - общедоступный (public) — обозначается «+»; - защищенный (protected) — обозначается «#»;
48. Операции класса Операцией класса (.методом класса) называется именованный сервис, который предоставляется по требованию любым объектом данного
49. Операции класса Имя операции представляет собой строку текста, которая используется в качестве идентификатора соответствующей операции, и
50. Операции класса Строка-свойство служит для определения значений свойств данного элемента. Строка-свойство может отсутствовать, если никакие свойства
51. Стереотипы класса Классы со стереотипами
52. Документация Документация предназначена для описания назначения класса, а не его структуры. Например, класс студент может быть
53. Пакеты Пакет (package) — это набор классов и других связанных пакетов. Путем объединения классов в пакеты
54. Диаграммы классов Главная диаграмма классов в логическом представлении модели обычно отображает пакеты системы. Каждый пакет также
55. Диаграммы классов Главная диаграмма классов
56. Диаграммы классов Диаграмма классов, отражающая видимость пакетов
58. Скачать презентацию

Слайд 2

Модель — упрощенное представление реальности.
С точки зрения программирования модель —

это чертеж системы. Моделирование необходимо для решения следующих зада:
- визуализации системы;
- определения ее структуры и поведения;
- получения шаблона, позволяющего затем сконструировать систему;
- документирования принимаемых решений, используя полученные модели.
Для решения этих задач при описании поведения проектируемого программного обеспечения в настоящее время используется UML (Unified Modeling Language) — унифицированный язык моделирования.

Слайд 3

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

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

Слайд 4

UML предлагает дополняющие друг друга диаграммы:
- диаграммы вариантов использования (прецедентов);
- диаграммы

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

Слайд 5

CASE-средство Rational Rose формирует документы:
диаграммы классов;
диаграммы состояний;
диаграммы сценариев;
диаграммы модулей;
диаграммы процессов;
спецификации классов,

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

Слайд 6

Определение прецедентов (вариантов использования)
Прецеденты (варианты использования — Use Cases) — это

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

Слайд 7

Пример 1
Анализ функциональных требований и пользователей системы тестирования (модуль обучающей системы).
Система

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

Слайд 8

Пример 1
На начальном этапе создания системы можно ограничиться только двумя важными

ролями действующих лиц (акторами):
- студент (тестируемый);
- администратор (он же преподаватель, он же составитель тестов).
Соответственно основные прецеденты (варианты использования):
Прецедент для студента:
П1 — пройти тестирование.
Прецеденты для администратора:
П2 — создать/изменить тест;
ПЗ — просмотреть результаты тестирования;
П4 — добавить/изменить пользователей и др.

Слайд 9

Пример 1
Краткое описание варианта использования

Слайд 10

Пример 1
Подробное описание варианта использования

Слайд 11

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

связь.

Слайд 12

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

Слайд 13

Отношения прецедентов
Между актером и прецедентом может существовать ассоциативное отношение. Такой тип

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

Слайд 14

Отношения прецедентов

Слайд 15

Поток событий
Поток событий (flow of events) для прецедента — это последовательность событий,

необходимых для обеспечения требуемого поведения.
Поток событий должен определять:
□ когда и как прецедент начинается и заканчивается;
□ как он взаимодействует с актером;
□ какие данные ему нужны;
□ нормальную последовательность событий для прецедента;
□ описание потоков в альтернативных и исключительных ситуациях.

Слайд 16

Поток событий
В каждом проекте должен использоваться стандартный шаблон для создания документа,

описывающего поток событий, например:
X. Поток событий для прецедента <имя>.
Х.1. Предусловия.
Х.2. Главный поток.
Х.3. Под-потоки (если применимы).
Х.4. Альтернативные потоки.
Здесь X — число от единицы до количества прецедентов.

Слайд 17

Пример 2
Документ с описанием потока событий для прецедента выбор курсов для

преподавания.
1. Поток событий для прецедента «выбор курсов для преподавания»
1.1. Предусловия
Под-поток создание учебных курсов прецедента управление информацией о курсах должен быть выполнен перед его началом.
1.2. Главный поток
Прецедент начинает выполняться, когда преподаватель подключается к системе регистрации и вводит свой пароль. Система проверяет правильность пароля (Е-1) и просит преподавателя выбрать текущий или будущий семестр (Е-2). Преподаватель вводит нужный семестр. Система предлагает выбрать требуемую операцию: добавить (Add), удалить (Delete), просмотреть (Review), напечатать (Print) или выйти (Quit).

Слайд 18

Пример 2
Если выбрана операция добавить, S-1: выполняется поток добавить учебный курс.
Если

выбрана операция удалить, S-2: выполняется поток удалить учебный курс.
Если выбрана операция просмотреть, S-3: выполняется поток просмотреть расписание.
Если выбрана операция напечатать, S-4: выполняется поток напечатать расписание.
Если выбрана операция выйти: прецедент завершается.

Слайд 19

Пример 2
1.3. Под-потоки
S-1: добавить учебный курс
Система отображает диалоговое окно, содержащее поле

для ввода названия и номера предмета. Преподаватель вводит название и номер предмета (Е-3). Система отображает список учебных курсов для указанного предмета (Е-4). Преподаватель выбирает учебный курс. Система закрепляет за преподавателем выбранный учебный курс (Е-5). Затем прецедент начинается сначала.
S-2: удалить учебный курс
Система отображает диалоговое окно, содержащее поле для ввода названия и номера учебного курса. Преподаватель выбирает название и номер учебного курса (Е-6). Система удаляет взаимосвязь курса с преподавателем (Е-7). Затем прецедент начинается сначала.

Слайд 20

Пример 2
S-3: просмотреть расписание
Система получает (Е-8) и отображает следующую информацию для

всех учебных курсов, за которыми закреплен данный преподаватель: название предмета, номер предмета, номер учебного курса, день недели, время и место проведения занятий. Когда преподаватель отмечает, что просматривает список, прецедент начинается сначала.
S-4: напечатать расписание
Система распечатывает расписание преподавателя (Е-9). Прецедент начинается сначала.

Слайд 21

Пример 2
1.4. Альтернативные потоки
Е-1: введен неверный идентификационный номер преподавателя. Пользователь должен

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

Слайд 22

Пример 2
Е-5: преподаватель не может быть прикреплен к выбранному учебному курсу.

Информация сохраняется, система осуществит прикрепление позже. Выполнение прецедента продолжается.
Е-6: введено неверное название или номер учебного курса. Пользователь должен повторить ввод названия и номера учебного курса или завершить прецедент.
Е-7: система не может удалить связь курса с преподавателем. Информация сохраняется, система удалит связь позже. Выполнение прецедента продолжается.
Е-8: система не может получить информацию о расписании. Прецедент начинается сначала.
Е-9: расписание не может быть распечатано. Пользователю сообщается, что данная опция в данный момент недоступна. Прецедент начинается сначала.

Слайд 23

Пример 2
Главная диаграмма прецедентов для системы регистрации учебных курсов

Слайд 24

Сценарий
Сценарий (scenario) — это элемент прецедента. Он представляет собой одиночный проход по потоку

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

Слайд 25

Сценарий
Сценарии описывают порядок того, как обязанности, возложенные на прецеденты, распределяются среди

объектов и классов в системе.
Каждый прецедент — это сплетение первичных (нормальный поток для прецедента) и вторичных сценариев (логика ЧТО-ЕСЛИ в прецеденте).

Слайд 26

Поток событий для прецедента описывается словами, тогда как сценарии отображаются с

помощью диаграмм взаимосвязи (interaction diagrams). Существует два типа диаграмм взаимосвязи — диаграммы последовательности действий (sequence diagrams) и диаграммы взаимодействий (collaboration diagrams). Каждая диаграмма является графическим представлением сценария.

Слайд 27

Диаграмма последовательностей системы
Диаграмма последовательностей системы — графическая модель, которая для определенного

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

Слайд 28

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

Слайд 29

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

последовательности действий

Слайд 30

Диаграмма последовательностей системы
Диаграмма последовательности действий с объектом предмет, присвоенным классу предмет,

для сценария создание учебного предмета.

Слайд 31

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

Слайд 32

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

обычной телефонной сети.

Слайд 33

Диаграммы взаимодействия
Диаграмма взаимодействий (collaboration diagram) — это альтернативный способ отображения сценариев. Такой тип

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

Слайд 34

Диаграмма взаимодействия

Слайд 35

Диаграммы деятельностей (действий)
Нотация языка UML для элементов диаграммы действий

Слайд 36

Фрагмент диаграммы деятельности для алгоритма нахождения корней квадратного уравнения

Слайд 37

Диаграммы деятельностей (действий)
Линия синхронизации

Слайд 38

Диаграмма деятельности процесса приготовления напитка
Линия синхронизации

Слайд 39

Диаграмма деятельности процесса
Линия синхронизации

Слайд 40

Диаграммы состояний
Выход из строя
Ремонт
Диаграмма состояний по существу
является

графом специального вида,
который представляет некоторый
автомат.
Основными понятиями,
описывающими автомат,
являются состояние и переход.
Список внутренних действий:
<метка-действия> /<выражение-действия>

Слайд 41

Диаграммы состояний
Диаграмма состояний для моделирования почтовой программы-клиента

Слайд 42

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

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

Слайд 43

Диаграммы классов
Диаграмма классов может отражать различные взаимосвязи между отдельными сущностями предметной

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

Слайд 44

Диаграммы классов
Графическое изображение класса на диаграмме классов

Слайд 45

Диаграммы классов
Примеры графического изображения классов на диаграмме

Слайд 46

Диаграммы классов
Атрибуты класса
Во второй секции прямоугольника — графического изображения класса

— записываются его атрибуты (attributes) или свойства. Стандартная запись атрибута в языке UML выглядит следующим образом:
<квантор видимости> <имя атрибута> [кратность] <тип атрибута> <исходное значение>{строка-свойство}

Слайд 47

Диаграммы классов
Квантор видимости:
- общедоступный (public) — обозначается «+»;
- защищенный (protected) —

обозначается «#»;
- закрытый (private) — обозначается «-».
Кратность атрибута показывает количество конкретных атрибутов данного типа, входящих в состав класса, и обозначается следующим образом:
[нижняя_граница1.. верхняя_граница1, нижняя_граница2..верхняя_граница2,
нижняя_границак..верхняя_границак]
[0..1] , [0..*] , [1..*] , [1..5] , [ 1. .3,7.. 10] , [ 1..3,7..*]
Например:
Имя_студента [1..2] String = Иван.

Слайд 48

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

требованию любым объектом данного класса.
Описание операции имеет следующий вид:
<квантор видимости> <имя операции> (список параметров) <выражение типа возвращаемого значения>{строка-свойство}
Квантор видимости принимает такие же значения, как и в случае атрибутов класса, и может быть опущен. Вместо условных графических обозначений также можно записывать соответствующее ключевое слово: public, protected, private.

Слайд 49

Операции класса
Имя операции представляет собой строку текста, которая используется в качестве

идентификатора соответствующей операции, и поэтому должна быть уникальной в пределах данного класса. Имя является единственным обязательным элементом синтаксического обозначения операции.
Список параметров является перечнем разделенных запятой формальных параметров, каждый из которых может быть представлен в следующем виде:
<вид параметра> <имя параметра>: <выражение типа>=<значение параметра по умолчанию>.
Вид параметра — это одно из ключевых слов in, out или inout со значением in по умолчанию.

Слайд 50

Операции класса
Строка-свойство служит для определения значений свойств данного элемента. Строка-свойство может

отсутствовать, если никакие свойства не специфицированы.
Операция, которая не может изменять состояние системы, обозначается строкой-свойством {запрос} ({query}).
Если в некотором классе операция не выполняется, то такая операция может быть помечена как абстрактная ({abstract}).
Пример: +создать()

Слайд 51

Стереотипы класса
Классы со стереотипами

Слайд 52

Документация
Документация предназначена для описания назначения класса, а не его структуры. Например,

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

Слайд 53

Пакеты
Пакет (package) — это набор классов и других связанных пакетов. Путем объединения

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

Слайд 54

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

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

Слайд 55

Диаграммы классов
Главная диаграмма классов

Слайд 56

Анализ требований и определение спецификаций при объектном подходе

Содержание

Модель — упрощенное представление реальности. С точки зрения программирования модель —

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

UML предлагает дополняющие друг друга диаграммы:- диаграммы вариантов использования (прецедентов);- диаграммы

CASE-средство Rational Rose формирует документы:диаграммы классов;диаграммы состояний;диаграммы сценариев;диаграммы модулей;диаграммы процессов;спецификации классов,

Определение прецедентов (вариантов использования)Прецеденты (варианты использования — Use Cases) — это

Пример 1Анализ функциональных требований и пользователей системы тестирования (модуль обучающей системы).Система

Пример 1На начальном этапе создания системы можно ограничиться только двумя важными

Пример 1Краткое описание варианта использования

Пример 1Подробное описание варианта использования

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

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

Отношения прецедентовМежду актером и прецедентом может существовать ассоциативное отношение. Такой тип

Отношения прецедентов

Поток событий Поток событий (flow of events) для прецедента — это последовательность событий,

Поток событий В каждом проекте должен использоваться стандартный шаблон для создания документа,

Пример 2Документ с описанием потока событий для прецедента выбор курсов для

Пример 2Если выбрана операция добавить, S-1: выполняется поток добавить учебный курс.Если

Пример 21.3. Под-потокиS-1: добавить учебный курсСистема отображает диалоговое окно, содержащее поле

Пример 2S-3: просмотреть расписаниеСистема получает (Е-8) и отображает следующую информацию для

Пример 21.4. Альтернативные потокиЕ-1: введен неверный идентификационный номер преподавателя. Пользователь должен

Пример 2Е-5: преподаватель не может быть прикреплен к выбранному учебному курсу.

Пример 2Главная диаграмма прецедентов для системы регистрации учебных курсов

СценарийСценарий (scenario) — это элемент прецедента. Он представляет собой одиночный проход по потоку

СценарийСценарии описывают порядок того, как обязанности, возложенные на прецеденты, распределяются среди

Поток событий для прецедента описывается словами, тогда как сценарии отображаются с

Диаграмма последовательностей системыДиаграмма последовательностей системы — графическая модель, которая для определенного

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

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

Диаграмма последовательностей системыДиаграмма последовательности действий с объектом предмет, присвоенным классу предмет,

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

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

Диаграммы взаимодействияДиаграмма взаимодействий (collaboration diagram) — это альтернативный способ отображения сценариев. Такой тип

Диаграмма взаимодействия

Диаграммы деятельностей (действий)Нотация языка UML для элементов диаграммы действий

Фрагмент диаграммы деятельности для алгоритма нахождения корней квадратного уравнения

Диаграммы деятельностей (действий)Линия синхронизации

Диаграмма деятельности процесса приготовления напиткаЛиния синхронизации

Диаграмма деятельности процессаЛиния синхронизации

Диаграммы состояний Выход из строя Ремонт Диаграмма состояний по существу является

Диаграммы состоянийДиаграмма состояний для моделирования почтовой программы-клиента

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

Диаграммы классовДиаграмма классов может отражать различные взаимосвязи между отдельными сущностями предметной

Диаграммы классовГрафическое изображение класса на диаграмме классов

Диаграммы классовПримеры графического изображения классов на диаграмме

Диаграммы классовАтрибуты класса Во второй секции прямоугольника — графического изображения класса

Диаграммы классовКвантор видимости:- общедоступный (public) — обозначается «+»;- защищенный (protected) —

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

Операции классаИмя операции представляет собой строку текста, которая используется в качестве

Операции классаСтрока-свойство служит для определения значений свойств данного элемента. Строка-свойство может

Стереотипы классаКлассы со стереотипами

ДокументацияДокументация предназначена для описания назначения класса, а не его структуры. Например,

ПакетыПакет (package) — это набор классов и других связанных пакетов. Путем объединения

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

Диаграммы классовГлавная диаграмма классов

Диаграммы классовДиаграмма классов, отражающая видимость пакетов

Похожие презентации