
- •Оглавление
- •1.1. Основные понятия
- •1.2. Жизненный цикл по
- •1.3. Модели жизненного цикла по
- •Каскадная модель жц:
- •Спиральная модель жц:
- •2. Методологии и технологии проектирования ис
- •2.1. Общие требования к методологии и технологии
- •2.2. Структура комплекта документов
- •2.3. Наиболее перспективные и приемлемые технологии разработки по
- •2.3.1. Технологии, базирующиеся на case–средствах Computer Associates
- •2.3.2. Технологии, базирующиеся на case–средствах ibm Rational
- •2.3.2.1. Краткая характеристика основных технологических программных продуктов ibm Rational
- •3. Методология функционального моделирования idef0
- •3.1. Концепция методологии функционального моделирования idef0
- •3.2. Основные определения (понятия) методологии и языка idef0
- •3.3. Синтаксис графического языка idef0
- •3.4. Семантика языка idef0
- •3.5. Имена и метки
- •3.6. Отношения блоков на диаграммах
- •3.7. Диаграммы idef0
- •3.8. Дочерняя диаграмма
- •3.9. Родительская диаграмма
- •3.10. Свойства диаграмм
- •3.10.1. Стрелки как ограничения
- •3.10.2. Параллельное функционирование
- •3.10.3. Ветвление и слияние сегментов стрелок
- •3.11. Создание диаграмм idef0 в среде AllFusionProcess Modeler
- •3.12. Диаграммы dfd
- •3.13. Пример проектирования функций подсистемы обработки и хранения данных
- •4. Idef3 – методология описания и моделирования процессов
- •4.1. Функциональный элемент
- •4.2. Элемент связи
- •4.2.1. Связи старшинства
- •4.2.2. Сдерживаемые связи старшинства
- •4.2.3. Относительные связи
- •4.2.4. Связь поток объектов
- •4.3. Перекресток
- •4.3.1. Типы перекрестков
- •4.3.2. Значения комбинаций перекрестков
- •4.4. Декомпозиция описания процесса
- •4.5. Примеры
- •5. Язык моделирования баз данных idef1x
- •5.1. Сущности
- •5.2. Связи и отношения
- •5.2.1. Мощность связей
- •5.3. Ключи
- •5.3.1 Внутренние и внешние ключи
- •5.3.2. Ссылочная целостность
- •5.4. Домены
- •5.5. Представления
- •5.6. Нормализация данных
- •5.7. Примеры построения диаграмм
- •5.8. Общие сведения о среде проектирования AllFusion Erwin Data Modeler
- •5.8.1. Построение логической модели
- •5.8.1.1. Диаграмма сущность – связь
- •5.8.1.2. Модель данных на основе ключа
- •5.8.1.3. Полная атрибутивная модель
- •5.8.2. Создание новой модели
- •5.8.3. Создание физического уровня базы данных на основе логического
- •5.8.4. Редактирование таблиц
- •5.8.5. Редактирование столбцов таблицы
- •5.8.6. Редактирование ключей и индексов таблицы
- •5.8.7. Редактирование связей таблиц
- •5.8.8. Сохранение модели базы данных
- •5.8.9. Генерация операторов для создания базы данных
- •5.8.10. Подготовка исходных данных для разработки новой версии бд
- •6. ЯзыкUml, модели по, объектно–ориентированный анализ и проектирование по.
- •6.1. Основные элементы языка uml
- •6.1.1. Сущности
- •6.1.2. Отношения
- •6.1.3. Диаграммы
- •6.2. Диаграмма вариантов использования как концептуальное представление бизнес–системы в процессе ее разработки
- •6.2.1. Базовые элементы диаграммы вариантов использования
- •6.2.2. Отношения на диаграмме вариантов использования
- •6.2.2.1. Отношение ассоциации
- •6.2.2.2. Отношение включения
- •6.2.2.3. Отношение расширения
- •6.2.2.4. Отношение обобщения
- •6.2.3. Дополнительные обозначения языка uml для бизнес–моделирования
- •6.2.4. Примеры use case и их реализация
- •6.3. Диаграммы последовательности
- •6.3.1. Сообщения на диаграмме последовательности
- •6.3.2. Ветвление потока управления
- •6.3.3. Пример диаграммы последовательности
- •6.4. Диаграмма кооперации
- •6.4.1. Объекты диаграммы кооперации и их графическое изображение
- •6.4.2. Кооперация объектов
- •6.4.3. Пример совместного использования диаграмм кооперации и последовательности
- •6.5. Сравнение диаграммы последовательности и диаграммы кооперации
- •6.6. Диаграммы состояний
- •6.6.1. Составное состояние и подсостояние
- •6.6.1.1. Последовательные подсостояния
- •6.6.1.2. Параллельные подсостояния
- •6.6.1.3. Несовместимые подсостояния
- •6.6.2. Исторические состояния
- •6.6.3. Сложные переходы и псевдосостояния
- •6.6.4. Состояние синхронизации
- •6.6.5. Рекомендации по построению диаграмм состояний
- •6.6.6. Примеры диаграмм состояний
- •6.7. Диаграммы деятельностей
- •6.7.1. Примеры диаграмм деятельностей
- •6.8. Классы
- •6.8.1. Области видимости и действия, кратность и иерархия классов
- •6.8.2. Отношения между классами
- •6.8.2.1. Отношение ассоциации
- •6.8.2.2. Отношение обобщения
- •6.8.2.3. Отношение агрегации
- •6.8.2.4. Отношение композиции
- •6.8.3. Примеры диаграмм классов
- •6.9. Компоненты
- •6.9.1. Виды компонентов
- •6.9.2. Отношения между компонентами
- •6.9.3. Компоненты и классы
- •6.9.4. Компоненты и интерфейсы
- •6.9.5. Варианты графического изображения компонентов
- •6.9.6. Пример диаграммы компонентов
- •6.10. Диаграмма развертывания
- •6.10.1. Узел диаграммы развертывания
- •6.10.2. Отношения между узлами диаграммы
- •6.10.3. Пример диаграммы развертывания
- •Литература
6.8.2.2. Отношение обобщения
Отношение обобщения является обычным таксономическим отношением или отношением классификации между более общим элементом (родителем или предком) и более частным или специальным элементом (дочерним или потомком).
Обобщение (Generalization) – таксономическое отношение между более общим понятием и менее общим понятием.
Менее общий элемент модели должен быть согласован с более общим элементом и может содержать дополнительную информацию. Данное отношение используется для представления иерархических взаимосвязей между различными элементами языка UML, такими как пакеты, классы, варианты использования.
Применительно к диаграмме классов данное отношение описывает иерархическое строение классов и наследование их свойств и поведения.
Наследование (Inheritance) – специальный концептуальный механизм, посредством которого более специальные элементы включают в себя структуру и поведение более общих элементов.
Согласно одному из главных принципов методологии ООАП – наследованию, класс–потомок обладает всеми свойствами и поведением класса–предка, а также имеет собственные свойства и поведение, которые могут отсутствовать у класса–предка.
Родитель, предок (Parent) – в отношении обобщения более общий элемент. Потомок (Child) – специализация одного из элементов отношения обобщения, называемого в этом случае родителем.
На диаграммах отношение обобщения обозначается сплошной линией с треугольной стрелкой на одном из концов (рис. 6.88.). Стрелка указывает на более общий класс (класс–предок или суперкласс), а ее начало – на более специальный класс (класс–потомок или подкласс).
Рис. 6.88. Графическое изображение отношения обобщения в языке UML
От одного класса–предка одновременно могут наследовать несколько классов–потомков, что отражает таксономический характер данного отношения. В этом случае на диаграмме классов для подобного отношения обобщения указывается несколько линий со стрелками.
Например, класс Транспортное средство (курсив обозначает абстрактный класс) может выступать в качестве суперкласса для подклассов, соответствующих конкретным транспортным средствам, таким как: Автомобиль, Автобус, Трактор и другим. Это может быть представлено графически в форме диаграммы классов следующего вида (рис. 6.89.).
Рис. 6.89. Пример графического изображения отношения обобщения для нескольких классов–потомков
С целью упрощения обозначений на диаграмме классов и уменьшения числа стрелок–треугольников и совокупности линий, обозначающих одно и то же отношение обобщения, может быть просто изображена стрелка. В этом случае отдельные линии сходятся к стрелке, которая имеет с этими линиями единственную точку пересечения (рис. 6.90.).
Рис. 6.90. Альтернативный вариант графического изображения отношения обобщения классов для случая объединения отдельных линий
Графическое изображение отношения обобщения по форме соответствует графу специального вида, а именно – иерархическому дереву. Как нетрудно заметить, в этом случае класс–предок является корнем дерева, а классы–потомки – его листьями. Отличие заключается в возможности указания на диаграмме классов дополнительной семантической информации, которая может отражать различные теоретико–множественные характеристики данного отношения. При этом класс–предок на диаграмме может занимать произвольное положение относительно своих классов–потомков, определяемое лишь соображениями удобства.
В дополнение к простой стрелке обобщения может быть присоединена строка текста, указывающая на специальные свойства этого отношения в форме ограничения. Этот текст будет относиться ко всем линиям обобщения, которые идут к классам–потомкам. Поскольку отмеченное свойство касается всех подклассов данного отношения, именно поэтому спецификация этого свойства осуществляется в форме ограничения, которое должно быть записано в фигурных скобках.
В качестве ограничений могут быть использованы следующие ключевые слова языка UML:
{complete} – означает, что в данном отношении обобщения специфицированы все классы–потомки, и других классов–потомков у данного класса–предка быть не может.
{incomplete} – означает случай, противоположный первому. А именно, предполагается, что на диаграмме указаны не все классы–потомки. В последующем возможно разработчик восполнит их перечень, не изменяя уже построенную диаграмму.
{disjoint} – означает, что классы–потомки не могут содержать объектов, одновременно являющихся экземплярами двух или более классов.
{overlapping} – случай, противоположный предыдущему. А именно, предполагается, что отдельные экземпляры классов–потомков могут принадлежать одновременно нескольким классам.
С учетом дополнительного использования стандартного ограничения диаграмма классов (рис. 6.90.) может быть уточнена (рис. 6.91.).
Рис. 6.91. Вариант уточненного графического изображения отношения обобщения классов с использованием строки–ограничения