Презентация Обобщение на диаграмме классов UML онлайн
На нашем сайте вы можете скачать и просмотреть онлайн доклад-презентацию на тему Обобщение на диаграмме классов UML абсолютно бесплатно. Урок-презентация на эту тему содержит всего 45 слайдов. Все материалы созданы в программе PowerPoint и имеют формат ppt или же pptx. Материалы и темы для презентаций взяты из открытых источников и загружены их авторами, за качество и достоверность информации в них администрация сайта не отвечает, все права принадлежат их создателям. Если вы нашли то, что искали, отблагодарите авторов - поделитесь ссылкой в социальных сетях, а наш сайт добавьте в закладки.
Презентации » Образование » Обобщение на диаграмме классов UML
Оцените!
Оцените презентацию от 1 до 5 баллов!
- Тип файла:ppt / pptx (powerpoint)
- Всего слайдов:45 слайдов
- Для класса:1,2,3,4,5,6,7,8,9,10,11
- Размер файла:1.79 MB
- Просмотров:69
- Скачиваний:0
- Автор:неизвестен
Слайды и текст к этой презентации:
№3 слайд
![Обобщение на диаграмме](/documents_5/0423fea8fccbc5340cb52728a0309f71/img2.jpg)
Содержание слайда: Обобщение на диаграмме классов
Отношение обобщения часто применяется на диаграмме классов.
Действительно, трудно представить себе ситуацию, когда между объектами в одной системе нет ничего общего. Как правило, общее есть и это общее целесообразно выделить в отдельный класс.
При этом общие составляющие, собранные в суперклассе, автоматически наследуются подклассами. Таким образом, сокращается общее количество описаний, а значит, уменьшается вероятность допустить ошибку.
№4 слайд
![Обобщение на диаграмме](/documents_5/0423fea8fccbc5340cb52728a0309f71/img3.jpg)
Содержание слайда: Обобщение на диаграмме классов
Использование обобщений не ограничивает свободу проектировщика системы, поскольку унаследованные составляющие можно переопределить в подклассе, если нужно. При обобщении выполняется принцип подстановочности. Фактически это означает увеличение гибкости и универсальности программного кода при одновременном сохранении надежности, обеспечиваемой контролем типов.
Действительно, если, например, в качестве типа параметра некоторой процедуры указать суперкласс, то процедура будет с равным успехом работать в случае, когда в качестве аргумента ей передан объект любого подкласса данного суперкласса.
Суперкласс может быть конкретным, идентифицированным одним из методов, а может быть абстрактным, введенным именно для построения отношений обобщения.
№5 слайд
![Обобщение на диаграмме](/documents_5/0423fea8fccbc5340cb52728a0309f71/img4.jpg)
Содержание слайда: Обобщение на диаграмме классов
Рассмотрим пример. В информационной системе отдела кадров мы выделили классы Position, Department и Person.
Резонно предположить, что все эти классы имеют атрибут, содержащий собственное имя объекта, выделяющее его в ряду однородных. Для простоты положим, что такой атрибут имеет тип String. В таком случае можно определить суперкласс, ответственный за хранение данного атрибута и работу с ним, а прочие классы связать с суперклассом отношением обобщения.
Однако более пристальный анализ предметной области наводит на мысль, что работа с собственным именем для выделенных классов производится не совсем одинаково.
№6 слайд
![Обобщение на диаграмме](/documents_5/0423fea8fccbc5340cb52728a0309f71/img5.jpg)
Содержание слайда: Обобщение на диаграмме классов
Назначение и изменение собственных имен подразделениям и должностям находится в пределах ответственности информационной системы отдела кадров, но назначение собственного имени сотрудника явно выходит за эти пределы.
Исходя из этих соображений, мы приходим к следующей структуре обобщений.
Обратите внимание, что суперкласс Unit мы определили как абстрактный, т. е. не могущий иметь непосредственных экземпляров, поскольку не предполагаем иметь в системе объекты данного класса. Класс Unit в данном нужен только для того, чтобы свести описания одного атрибута и двух операций в одно место и не повторять их дважды.
№8 слайд
![Обобщение на диаграмме](/documents_5/0423fea8fccbc5340cb52728a0309f71/img7.jpg)
Содержание слайда: Обобщение на диаграмме классов
В UML допускается, чтобы класс был подклассом нескольких суперклассов (множественное наследование), не требуется, чтобы у базовых классов был общий суперкласс (несколько иерархий обобщения) и вообще не накладывается никаких ограничений, кроме частичной упорядоченности (т. е. отсутствия циклов в цепочках обобщений). Нарушение данного условия является синтаксической ошибкой. При множественном обобщении возможны конфликты: суперклассы содержат составляющие, которые невозможно включить в один подкласс, например, атрибуты с одинаковыми именами, но разными типами.
В UML конфликты при множественном обобщении считаются нарушением правил непротиворечивости модели
№9 слайд
![Интерфейс В UML имеется](/documents_5/0423fea8fccbc5340cb52728a0309f71/img8.jpg)
Содержание слайда: Интерфейс
В UML имеется несколько частных случаев классификаторов, которые, подобно классам, предназначены для моделирования структуры, но обладают рядом специфических особенностей. Наиболее важным из них являются интерфейсы.
Интерфейс — это именованный набор абстрактных операций.
Другими словами, интерфейс — это абстрактный класс, в котором нет атрибутов и все операции абстрактны. Поскольку интерфейс — это абстрактный класс, он не может иметь непосредственных экземпляров.
№10 слайд
![Интерфейс Между интерфейсами](/documents_5/0423fea8fccbc5340cb52728a0309f71/img9.jpg)
Содержание слайда: Интерфейс
Между интерфейсами и другими классификаторами, в частности классами, на диаграмме классов применяются два отношения:
классификатор (в частности, класс) использует интерфейс — это показывается с помощью зависимости со стереотипом «call»;
классификатор (в частности, класс) реализует интерфейс — это показывается с помощью отношения реализации.
№11 слайд
![Интерфейс Между интерфейсами](/documents_5/0423fea8fccbc5340cb52728a0309f71/img10.jpg)
Содержание слайда: Интерфейс
Между интерфейсами и другими классификаторами, в частности классами, на диаграмме классов применяются два отношения:
классификатор (в частности, класс) использует интерфейс — это показывается с помощью зависимости со стереотипом «call»;
классификатор (в частности, класс) реализует интерфейс — это показывается с помощью отношения реализации.
№15 слайд
![Типы данных Тип данных это](/documents_5/0423fea8fccbc5340cb52728a0309f71/img14.jpg)
Содержание слайда: Типы данных
Тип данных — это совокупность множества значений (может быть очень большого или даже потенциально бесконечного) и конечного множества операций, применимых к данным значениям.
UML не является сильно типизированным языком: например, в модели можно указывать типы атрибутов классов и параметров операций, но это не обязательно.
№19 слайд
![Типы данных Примитивные типы,](/documents_5/0423fea8fccbc5340cb52728a0309f71/img18.jpg)
Содержание слайда: Типы данных
Примитивные типы, которые считаются предопределенными в UML — таковых, как минимум, три: строка, целое число и значение даты/времени. Инструменты вправе расширять этот набор и использовать подходящие названия.
Типы данных, которые определены в языке программирования, поддерживаемым инструментом. Это могут быть как названия встроенных типов, так и сколь угодно сложные выражения, доставляющие тип, если таковые допускаются языком.
Типы данных, которые определены в модели. В стандарте UML предусмотрен только один конструктор типов данных: перечислимый тип, который определяется с помощью стереотипа «enumeration». Наряду со стандартным стереотипом «enumeration» многие инструменты допускают использование стереотипа «datatype», который означает построение типа данных с помощью не специфицированного конструктора типов.
№20 слайд
![Шаблон Еще одной сущностью,](/documents_5/0423fea8fccbc5340cb52728a0309f71/img19.jpg)
Содержание слайда: Шаблон
Еще одной сущностью, специфической для диаграмм классов, являются шаблоны.
Шаблон — это класс с параметрами. Параметром может быть любой элемент описания класса — тип составляющей, кратность атрибута и т. д. На диаграмме шаблон изображается с помощью прямоугольника класса, к которому в правом верхнем углу присоединен пунктирный прямоугольник с параметрами шаблона.
Описания параметров перечисляются в этом прямоугольнике через запятую. Описание каждого параметра имеет вид:
ИМЯ : тип
№21 слайд
![Шаблон Сам по себе шаблон не](/documents_5/0423fea8fccbc5340cb52728a0309f71/img20.jpg)
Содержание слайда: Шаблон
Сам по себе шаблон не может непосредственно использоваться в модели. Для того, чтобы на основе шаблона получить конкретный класс, который может использоваться в модели, нужно указать явные значения аргументов. Такое указание называется связыванием. В UML применяются два способа связывания:
явное связывание — зависимость со стереотипом «bind», в которой указаны значения аргументов;
неявное связывание — определение класса, имя которого имеет формат имя_шаблона < аргументы >
№22 слайд
![Шаблон Назначение и область](/documents_5/0423fea8fccbc5340cb52728a0309f71/img21.jpg)
Содержание слайда: Шаблон
Назначение и область применения шаблонов понятны — шаблоны нужны, чтобы определить некоторую общую параметрическую конструкцию класса один раз, и затем использовать ее многократно, подставляя конкретные значения аргументов.
Явное связывание более наглядно, неявное связывание менее наглядно, зато записывается короче.
№23 слайд
![Шаблон Здесь определен шаблон](/documents_5/0423fea8fccbc5340cb52728a0309f71/img22.jpg)
Содержание слайда: Шаблон
Здесь определен шаблон Array, имеющий два параметра: n типа Integer и T, тип которого не указан. Этот шаблон применяется для создания массивов определенной длины, содержащих элементы определенного типа. В данном случае с помощью явного связывания определен класс Triangle как массив из трех элементов типа Point. С помощью неявного связывания определен аналогичный по смыслу класс с именем Array<3,Point>.
№24 слайд
![Диаграммы классов Диаграммы](/documents_5/0423fea8fccbc5340cb52728a0309f71/img23.jpg)
Содержание слайда: Диаграммы классов
Диаграммы классов содержат множество деталей. Для практически значимых систем диаграммы классов в конечном итоге получаются довольно сложными. Пытаться прорисовать сложную диаграмму классов сразу "на всю глубину" нерационально — слишком велик риск "утонуть" в деталях.
Удачная модель структуры сложной системы создается за несколько (может быть даже за несколько десятков) итераций, в которых моделирование структуры перемежается моделированием поведения.
№25 слайд
![Диаграммы классов Описывать](/documents_5/0423fea8fccbc5340cb52728a0309f71/img24.jpg)
Содержание слайда: Диаграммы классов
Описывать структуру удобнее параллельно с описанием поведения. Каждая итерация должна быть небольшим уточнением как структуры, так и поведения.
Не обязательно включать в модель все классы сразу. На первых итерациях достаточно идентифицировать очень небольшую (10%) долю всех классов системы.
Не обязательно определять все свойства класса сразу. Начните с имени — операции и атрибуты постепенно выявятся в процессе моделирования поведения.
Не обязательно показывать на диаграмме все свойства класса. В процессе работы диаграмма должна легко охватываться одним взглядом.
Не обязательно определять все отношения между классами сразу. Пусть класс на диаграмме "висит в воздухе" — ничего с ним не случится.
№26 слайд
![Диаграммы реализации](/documents_5/0423fea8fccbc5340cb52728a0309f71/img25.jpg)
Содержание слайда: Диаграммы реализации
Диаграммы реализации — это обобщающее название для диаграмм компонентов и диаграмм размещения. Название объясняется тем, что данные диаграммы приобретают особую важность на позднейших фазах разработки — на фазах реализации и перехода. На ранних фазах разработки — анализа и проектирования — эти диаграммы либо вообще не используются, либо имеют самый общий, не детализированный вид.
№28 слайд
![Диаграммы компонентов](/documents_5/0423fea8fccbc5340cb52728a0309f71/img27.jpg)
Содержание слайда: Диаграммы компонентов
Диаграмма компонентов предназначена для перечисления и указания взаимосвязей артефактов моделируемой системы.
На диаграмме компонентов применяются следующие основные типы сущностей:
компоненты;
интерфейсы;
классы;
объекты.
На диаграмме компонентов обычно используются отношения следующих типов:
зависимость;
ассоциация (главным образом в форме композиции);
реализация.
№29 слайд
![Компонент Абсолютно](/documents_5/0423fea8fccbc5340cb52728a0309f71/img28.jpg)
Содержание слайда: Компонент
Абсолютно формальное определение компонента в UML дать невозможно.
Компонент — это физически существующий и заменяемый артефакт системы.
Прежде всего, это компонент в смысле сборочного программирования: особым образом оформленная часть программного кода, которая может работать в составе более сложной программы.
Компоненты понимаются в UML в наиболее общем смысле: это не только исполнимые файлы с кодами программы, но и исходные тексты программ, веб-страницы, справочные файлы, сопроводительные документы, файлы с данными и вообще любые артефакты, которые тем или иным способом используются при работе приложения и входят в его состав.
№30 слайд
![Компонент При выделении](/documents_5/0423fea8fccbc5340cb52728a0309f71/img29.jpg)
Содержание слайда: Компонент
При выделении компонентов применяются следующие неформальные критерии.
Компонент нетривиален. Это нечто более сложное и объемное, чем фрагмент кода или одиночный класс.
Компонент независим, но не самодостаточен. Он содержит все, что нужно для функционирования, но предназначен для работы во взаимодействии с другими компонентами.
Компонент однороден. Он выполняет несколько взаимосвязанных функций, которые могут быть естественным образом охарактеризованы как единое целое в контексте более сложной системы.
Компонент заменяем. Он поддерживает строго определенный набор интерфейсов и может быть без ущерба для функционирования системы заменен другим компонентом, поддерживающим те же интерфейсы.
№31 слайд
![Диаграмма компонентов В](/documents_5/0423fea8fccbc5340cb52728a0309f71/img30.jpg)
Содержание слайда: Диаграмма компонентов
В случае разработки "монолитного" настольного приложения диаграмма компонентов не нужна — она оказывается тривиальной и никакой полезной информации не содержит.
Таким образом, диаграммы компонентов применяются только при моделировании многокомпонентных приложений.
№32 слайд
![Диаграмма компонентов Если](/documents_5/0423fea8fccbc5340cb52728a0309f71/img31.jpg)
Содержание слайда: Диаграмма компонентов
Если приложение поставляется в виде "конструктора" (набора "кубиков" — компонентов) из которого при установке собирается конкретный уникальный экземпляр приложения, то диаграммы компонентов оказываются просто незаменимым средством.
Многие современные приложения поставляются в виде большого (десятки и сотни) набора компонентов, из которых "на месте" собирается нужная пользователю, часто уникальная конфигурация.
Рекомендуют использовать диаграммы компонентов для управления конфигурацией не только на фазе поставки и установки программного обеспечения, но и в процессе разработки: для отслеживания версий компонентов, вариантов сборки и т. п.
№37 слайд
![Диаграмма размещения](/documents_5/0423fea8fccbc5340cb52728a0309f71/img36.jpg)
Содержание слайда: Диаграмма размещения
Последним структурным аспектом, который необходимо обсудить, является описание размещения компонентов относительно участвующих в работе вычислительных ресурсов.
В UML для этой цели предназначены диаграммы размещения. В UML 2.0 эти диаграммы переименованы в диаграммы развертывания.
Если речь идет о настольном приложении, которое целиком хранится и выполняется на одном компьютере, то отдельная диаграмма размещения не нужна.
При моделировании распределенных приложений значение диаграмм размещения резко возрастает.
№38 слайд
![Диаграмма размещения На](/documents_5/0423fea8fccbc5340cb52728a0309f71/img37.jpg)
Содержание слайда: Диаграмма размещения
На диаграмме размещения, по сравнению с диаграммами компонентов, применяются только один дополнительный тип сущности — узел и два дополнительных отношения: ассоциация между узлами и размещение компонента на узле.
В остальном диаграммы размещения наследуют возможности диаграмм компонентов.
№39 слайд
![Диаграмма размещения Узел это](/documents_5/0423fea8fccbc5340cb52728a0309f71/img38.jpg)
Содержание слайда: Диаграмма размещения
Узел — это физический вычислительный ресурс, участвующий в работе системы.
Компоненты системы во время ее работы размещаются на узлах. В UML узел является классификатором, т. е. мы можем (и должны!) различать описание типа вычислительного ресурса (например, рабочая станция, последовательный порт) и описание экземпляра вычислительного устройства (например, устройство COM1 типа последовательный порт).
Это различие моделируется согласно общему механизму UML: имя экземпляра узла подчеркивается, а имя типа узла — нет.
№41 слайд
![Диаграмма размещения](/documents_5/0423fea8fccbc5340cb52728a0309f71/img40.jpg)
Содержание слайда: Диаграмма размещения
Ассоциация между узлами означает то же, что и в других контекстах: возможность обмена сообщениями.
Применительно к вычислительным сетям ассоциация означает наличие канала связи. Если нужно указать дополнительную информацию о свойствах канала, то это можно сделать используя общие механизмы: стереотипы, ограничения и именованные значения, приписанные ассоциации.
№44 слайд
![Выводы Диаграммы классов](/documents_5/0423fea8fccbc5340cb52728a0309f71/img43.jpg)
Содержание слайда: Выводы
Диаграммы классов моделируют структуру объектов и связей между ними.
Классы выбираются на основе анализа предметной области, взаимного согласования элементов модели и общих теоретических соображений.
Сущности на диаграммах классов связываются главным образом отношениями ассоциации (в том числе агрегирования и композиции) и обобщения.
Базовая нотация ассоциации позволяет указать, что объекты ассоциированных классов могут взаимодействовать во время выполнения. Для ассоциации в UML предусмотрено наибольшее количество различных дополнений.
Скачать все slide презентации Обобщение на диаграмме классов UML одним архивом:
Похожие презентации
-
UML-Диаграммы классов
-
Диаграммы UML Диаграмма классов (Class Diagram)
-
Обобщение педагогического опыта учителя начальных классов Сухоруковой А. А. по теме: «Развитие познавательной активности на уро
-
Обобщение опыта работы. Подготовка учащихся . 9-х классов к итоговой аттестации в новой . форме.
-
Обобщение опыта учителя начальных классов «Активизация познавательной деятельности через духовно-нравственное воспитание» Учи
-
Business object model Диаграммы классов
-
Технология построения диаграммы Варианты использования в UML
-
UML-диаграммы. Диаграмма последовательности
-
UML-диаграммы. Диаграмма развертывания и прочие
-
Диаграммы UML Диаграмма вариантов использования