Самоучитель UML
Добавить в закладки К обложке
- ГЛАВА 1 Введение - Страница 1
- 1.1. Методология процедурно-ориентированного программирования - Страница 2
- 1.2. Методология объектно-ориентированного программирования - Страница 4
- 1.3. Методология объектно-ориентированного анализа и проектирования - Страница 8
- 1.4. Методология системного анализа и системного моделирования - Страница 10
- ГЛАВА 2 Исторический обзор развития методологии объектно-ориентированного анализа и проектирования сложных систем - Страница 12
- Теория множеств - Страница 13
- Теория графов - Страница 16
- Семантические сети - Страница 18
- 2.2. Диаграммы структурного системного анализа - Страница 19
- Диаграммы «сущность-связь» - Страница 20
- Диаграммы функционального моделирования - Страница 22
- Диаграммы потоков данных - Страница 24
- 2.3. Основные этапы развития UML - Страница 26
- ГЛАВА 3 Основные компоненты языка UML - Страница 29
- 3.1. Назначение языка UML - Страница 30
- 3.2. Общая структура языка UML - Страница 32
- 3.3. Пакеты в языке UML - Страница 34
- 3.4. Основные пакеты метамодели языка UML - Страница 36
- Пакет Основные элементы - Страница 37
- Пакет Элементы ядра - Страница 38
- Пакет Вспомогательные элементы - Страница 39
- Пакет Механизмы расширения - Страница 40
- Пакет Типы данных - Страница 41
- Пакет Элементы поведения - Страница 42
- Пакет Общее поведение - Страница 43
- Пакет Кооперации - Страница 44
- Пакет Варианты использования - Страница 45
- Пакет Автоматы - Страница 46
- Пакет Общие механизмы - Страница 47
- Пакет Управление моделями - Страница 48
- 3.5. Специфика описания метамодели языка UML - Страница 49
- 3.6. Особенности изображения диаграмм языка UML - Страница 52
- ГЛАВА 4 Диаграмма вариантов использования (use case diagram) - Страница 54
- 4.1. Вариант использования - Страница 55
- 4.2. Актеры - Страница 56
- 4.3. Интерфейсы - Страница 57
- 4.4. Примечания - Страница 58
- 4.5. Отношения на диаграмме вариантов использования - Страница 59
- Отношение ассоциации - Страница 60
- Отношение расширения - Страница 62
- Отношение обобщения - Страница 63
- Отношение включения - Страница 64
- 4.6. Пример построения диаграммы вариантов использования - Страница 65
- 4.7. Рекомендации по разработке диаграмм вариантов использования - Страница 67
- ГЛАВА 5 Диаграмма классов (class diagram) - Страница 69
- 5.1. Класс - Страница 70
- Имя класса - Страница 71
- Атрибуты класса - Страница 72
- Операция - Страница 75
- 5.2. Отношения между классами - Страница 77
- Отношение зависимости - Страница 78
- Отношение ассоциации - Страница 79
- Отношение агрегации - Страница 81
- Отношение композиции - Страница 82
- Отношение обобщения - Страница 83
- 5.3. Интерфейсы . - Страница 85
- 5.4. Объекты - Страница 86
- 5.5. Шаблоны или параметризованные классы - Страница 87
- 5.6. Рекомендации по построению диаграмм классов - Страница 88
- ГЛАВА 6 Диаграмма состояний (statechart diagram) - Страница 89
- 6.1. Автоматы - Страница 90
- 6.2. Состояние - Страница 92
- Имя состояния - Страница 93
- Список внутренних действий - Страница 94
- Начальное состояние - Страница 95
- Конечное состояние - Страница 96
- 6.3. Переход - Страница 97
- Событие - Страница 98
- Сторожевое условие - Страница 99
- Выражение действия - Страница 101
- 6.4. Составное состояние и подсостояние - Страница 102
- Последовательные подсостояния - Страница 103
- Параллельные подсостояния - Страница 104
- 6.5. Историческое состояние - Страница 105
- 6.6. Сложные переходы - Страница 106
- Переходы между параллельными состояниями - Страница 107
- Переходы между составными состояниями - Страница 108
- Синхронизирующие состояния - Страница 109
- 6.7. Заключительные рекомендации по построению диаграмм состояний - Страница 111
- ГЛАВА 7 Диаграмма деятельности (activity diagram) - Страница 112
- 7.1. Состояние действия - Страница 113
- 7.2. Переходы - Страница 114
- 7.3. Дорожки - Страница 116
- 7.4. Объекты - Страница 117
- 7.5. Рекомендации по построению диаграмм деятельности - Страница 118
- ГЛАВА 8 Диаграмма последовательности (sequence diagram) - Страница 119
- 8.1. Объекты - Страница 120
- Линия жизни объекта - Страница 121
- Фокус управления - Страница 122
- 8.2. Сообщения - Страница 123
- Ветвление потока управления - Страница 125
- Стереотипы сообщений - Страница 126
- Временные ограничения на диаграммах последовательности - Страница 127
- Комментарии или примечания - Страница 128
- 8.3. Пример построения диаграммы последовательности - Страница 129
- 8.4. Заключительные рекомендации по построению диаграмм последовательности - Страница 130
- ГЛАВА 9 Диаграмма кооперации (collaboration diagram) - Страница 131
- 9.1. Кооперация - Страница 132
- Диаграмма кооперации уровня спецификации - Страница 133
- 9.2. Объекты - Страница 134
- Мультиобъект - Страница 135
- Активный объект - Страница 136
- Составной объект - Страница 137
- 9.3. Связи - Страница 138
- Стереотипы связей - Страница 139
- 9.4. Сообщения - Страница 140
- Формат записи сообщений - Страница 141
- 9.5. Пример построения диаграммы кооперации - Страница 143
- 9.6. Заключительные рекомендации по построению диаграмм кооперации - Страница 144
- ГЛАВА 10 Диаграмма компонентов (component diagram) - Страница 145
- 10.1. Компоненты - Страница 146
- Имя компонента - Страница 147
- Виды компонентов - Страница 148
- 10.2. Интерфейсы - Страница 149
- 10.3. Зависимости - Страница 150
- 10.4. Рекомендации по построению диаграммы компонентов - Страница 152
- ГЛАВА 11 Диаграмма развертывания (deployment diagram) - Страница 153
- 11.1. Узел - Страница 154
- 11.2. Соединения - Страница 155
- 11.3. Рекомендации по построению диаграммы развертывания - Страница 156
- ГЛАВА 12 Особенности реализации языка UML в CASE-инструментарии Rational Rose 98/2000 - Страница 157
- 12.1. Общая характеристика CASE-средства Rational Rose 98/2000 - Страница 158
- 12.2. Особенности рабочего интерфейса Rational Rose - Страница 159
- Главное меню программы - Страница 160
- Стандартная панель инструментов - Страница 161
- Окно браузера - Страница 162
- Специальная панель инструментов - Страница 163
- Окно диаграммы - Страница 164
- Окно документации - Страница 165
- Окно журнала - Страница 166
- 12.3. Начало работы над проектом в среде Rational Rose - Страница 167
- 12.4. Разработка диаграммы вариантов использования в среде Rational Rose - Страница 168
- 12.5. Разработка диаграммы классов в среде Rational Rose - Страница 169
- 12.6. Разработка диаграммы состояний в среде Rational Rose - Страница 170
- 12.7. Разработка диаграммы последовательности в среде Rational Rose - Страница 171
- 12.8. Разработка диаграммы кооперации в среде Rational Rose - Страница 172
- 12.9. Разработка диаграммы компонентов в среде Rational Rose - Страница 173
- 12.10. Разработка диаграммы развертывания в среде Rational Rose - Страница 174
- Заключение - Страница 175
5.6. Рекомендации по построению диаграмм классов
Процесс разработки диаграммы классов занимает центральное место в ООАП сложных систем. От умения правильно выбрать классы и установить между ними взаимосвязи часто зависит не только успех процесса проектирования, но и производительность выполнения программы. Как показывает практика ООП, каждый программист в своей работе стремится в той или иной степени использовать уже накопленный личный опыт при разработке новых проектов. Это обусловлено желанием свести новую задачу к уже решенным, чтобы иметь возможность использовать не только проверенные фрагменты программного кода, но и отдельные компоненты в целом (библиотеки компонентов).
Такой стереотипный подход позволяет существенно сократить сроки реализации проекта, однако приемлем лишь в том случае, когда новый проект концептуально и технологически не слишком отличается от предыдущих. В противном случае платой за сокращение сроков проекта может стать его реализация на устаревшей технологической базе. Что касается собственно объектной структуризации предметной области, то здесь уместно придерживаться тех рекомендаций, которые накоплены в ООП. Они широко освещены в литературе [1, 2, 4, 10, 13, 18, 20] и поэтому здесь не рассматриваются.
При определении классов, атрибутов и операций и задании их имен и типов перед отечественными разработчиками всегда встает невольный вопрос: какой из языков использовать в качестве естественного, русский или английский? С одной стороны, использование родного языка для описания модели является наиболее естественным способом ее представления и в наибольшей степени отражает коммуникативную функцию модели системы. С другой стороны, разработка модели является лишь одним из этапов разработки соответствующей системы, а применение инструментальных средств для ее реализации в абсолютном большинстве случаев требует использования англоязычных терминов. Именно поэтому возникает характерная неоднозначность, с которой, по-видимому, совершенно незнакома англоязычная аудитория.
Отвечая на поставленный выше вопрос, следует отметить, что наиболее целесообразно придерживаться следующих рекомендаций. При построении диаграммы вариантов использования, являющейся наиболее общей концептуальной моделью проектируемой системы, применение русскоязычных терминов является не только оправданным с точки зрения описания структуры предметной области, но и эффективным с точки зрения коммуникативного взаимодействия с заказчиком и пользователями. При построении остальных типов диаграмм следует придерживаться разумного компромисса.
В частности, на начальных этапах разработки диаграмм целесообразность использования русскоязычных терминов вполне очевидна и оправдана. Однако, по мере готовности графической модели для реализации в виде программной системы и передачи ее для дальнейшей работы программистам, акцент может смещаться в сторону использования англоязычных терминов, которые в той или иной степени отражают особенности языка программирования, на котором предполагается реализация данной модели.
Более того, использование CASE-инструментариев для автоматизации ООАП, чаще всего, накладывает свои собственные требования на язык спецификации моделей. Именно по этой причине большинство примеров в литературе даются в англоязычном представлении, а при их переводе на русский может быть утрачена не только точность формулировок, но и семантика соответствующих понятий.
После разработки диаграммы классов процесс ООАП может быть продолжен в двух направлениях. С одной стороны, если поведение системы тривиально, то можно приступить к разработке диаграмм кооперации и компонентов. Однако для сложных динамических систем поведение представляет важнейший аспект их функционирования. Детализация поведения осуществляется последовательно при разработке диаграмм состояний, последовательности и деятельности. К изучению первой из них мы и приступим в главе 6.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
- 138
- 139
- 140
- 141
- 142
- 143
- 144
- 145
- 146
- 147
- 148
- 149
- 150
- 151
- 152
- 153
- 154
- 155
- 156
- 157
- 158
- 159
- 160
- 161
- 162
- 163
- 164
- 165
- 166
- 167
- 168
- 169
- 170
- 171
- 172
- 173
- 174
- 175
- 176