Обобщение на диаграмме классов UML - презентация, доклад, проект скачать

Нажмите для полного просмотра!

Обобщение на диаграмме классов UML, слайд №1

Обобщение на диаграмме классов UML, слайд №2

Обобщение на диаграмме классов UML, слайд №3

Обобщение на диаграмме классов UML, слайд №4

Обобщение на диаграмме классов UML, слайд №5

Обобщение на диаграмме классов UML, слайд №6

Обобщение на диаграмме классов UML, слайд №7

Обобщение на диаграмме классов UML, слайд №8

Обобщение на диаграмме классов UML, слайд №9

Обобщение на диаграмме классов UML, слайд №10

Обобщение на диаграмме классов UML, слайд №11

Обобщение на диаграмме классов UML, слайд №12

Обобщение на диаграмме классов UML, слайд №13

Обобщение на диаграмме классов UML, слайд №14

Обобщение на диаграмме классов UML, слайд №15

Обобщение на диаграмме классов UML, слайд №16

Обобщение на диаграмме классов UML, слайд №17

Обобщение на диаграмме классов UML, слайд №18

Обобщение на диаграмме классов UML, слайд №19

Обобщение на диаграмме классов UML, слайд №20

Обобщение на диаграмме классов UML, слайд №21

Обобщение на диаграмме классов UML, слайд №22

Обобщение на диаграмме классов UML, слайд №23

Обобщение на диаграмме классов UML, слайд №24

Обобщение на диаграмме классов UML, слайд №25

Обобщение на диаграмме классов UML, слайд №26

Обобщение на диаграмме классов UML, слайд №27

Обобщение на диаграмме классов UML, слайд №28

Обобщение на диаграмме классов UML, слайд №29

Обобщение на диаграмме классов UML, слайд №30

Обобщение на диаграмме классов UML, слайд №31

Обобщение на диаграмме классов UML, слайд №32

Обобщение на диаграмме классов UML, слайд №33

Обобщение на диаграмме классов UML, слайд №34

Обобщение на диаграмме классов UML, слайд №35

Обобщение на диаграмме классов UML, слайд №36

Обобщение на диаграмме классов UML, слайд №37

Обобщение на диаграмме классов UML, слайд №38

Обобщение на диаграмме классов UML, слайд №39

Обобщение на диаграмме классов UML, слайд №40

Обобщение на диаграмме классов UML, слайд №41

Обобщение на диаграмме классов UML, слайд №42

Обобщение на диаграмме классов UML, слайд №43

Обобщение на диаграмме классов UML, слайд №44

Обобщение на диаграмме классов UML, слайд №45

Содержание ▲

Вы можете ознакомиться и скачать презентацию на тему Обобщение на диаграмме классов UML. Доклад-сообщение содержит 45 слайдов. Презентации для любого класса можно скачать бесплатно. Если материал и наш сайт презентаций Mypresentation Вам понравились – поделитесь им с друзьями с помощью социальных кнопок и добавьте в закладки в своем браузере.

Слайды и текст этой презентации

Слайд 1

Описание слайда:

Слайд 2

Описание слайда:

Слайд 3

Описание слайда:

Обобщение на диаграмме классов Отношение обобщения часто применяется на диаграмме классов. Действительно, трудно представить себе ситуацию, когда между объектами в одной системе нет ничего общего. Как правило, общее есть и это общее целесообразно выделить в отдельный класс. При этом общие составляющие, собранные в суперклассе, автоматически наследуются подклассами. Таким образом, сокращается общее количество описаний, а значит, уменьшается вероятность допустить ошибку.

Слайд 4

Описание слайда:

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

Слайд 5

Описание слайда:

Обобщение на диаграмме классов Рассмотрим пример. В информационной системе отдела кадров мы выделили классы Position, Department и Person. Резонно предположить, что все эти классы имеют атрибут, содержащий собственное имя объекта, выделяющее его в ряду однородных. Для простоты положим, что такой атрибут имеет тип String. В таком случае можно определить суперкласс, ответственный за хранение данного атрибута и работу с ним, а прочие классы связать с суперклассом отношением обобщения. Однако более пристальный анализ предметной области наводит на мысль, что работа с собственным именем для выделенных классов производится не совсем одинаково.

Слайд 6

Описание слайда:

Обобщение на диаграмме классов Назначение и изменение собственных имен подразделениям и должностям находится в пределах ответственности информационной системы отдела кадров, но назначение собственного имени сотрудника явно выходит за эти пределы. Исходя из этих соображений, мы приходим к следующей структуре обобщений. Обратите внимание, что суперкласс Unit мы определили как абстрактный, т. е. не могущий иметь непосредственных экземпляров, поскольку не предполагаем иметь в системе объекты данного класса. Класс Unit в данном нужен только для того, чтобы свести описания одного атрибута и двух операций в одно место и не повторять их дважды.

Слайд 7

Описание слайда:

Обобщение на диаграмме классов

Слайд 8

Описание слайда:

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

Слайд 9

Описание слайда:

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

Слайд 10

Описание слайда:

Интерфейс Между интерфейсами и другими классификаторами, в частности классами, на диаграмме классов применяются два отношения: классификатор (в частности, класс) использует интерфейс — это показывается с помощью зависимости со стереотипом «call»; классификатор (в частности, класс) реализует интерфейс — это показывается с помощью отношения реализации.

Слайд 11

Описание слайда:

Слайд 12

Описание слайда:

Интерфейс Роль — это интерфейс, который предоставляет классификатор в данной ассоциации.

Слайд 13

Описание слайда:

Интерфейс

Слайд 14

Описание слайда:

Интерфейс

Слайд 15

Описание слайда:

Типы данных Тип данных — это совокупность множества значений (может быть очень большого или даже потенциально бесконечного) и конечного множества операций, применимых к данным значениям. UML не является сильно типизированным языком: например, в модели можно указывать типы атрибутов классов и параметров операций, но это не обязательно.

Слайд 16

Описание слайда:

Типы данных Для каких элементов модели можно указать тип? Что можно использовать в качестве указания типа?

Слайд 17

Описание слайда:

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

Слайд 18

Описание слайда:

Типы данных В модели UML можно использовать три вида типов данных: Примитивные типы, которые считаются предопределенными в UML Типы данных, которые определены в языке программирования, поддерживаемым инструментом Типы данных, которые определены в модели

Слайд 19

Описание слайда:

Типы данных Примитивные типы, которые считаются предопределенными в UML — таковых, как минимум, три: строка, целое число и значение даты/времени. Инструменты вправе расширять этот набор и использовать подходящие названия. Типы данных, которые определены в языке программирования, поддерживаемым инструментом. Это могут быть как названия встроенных типов, так и сколь угодно сложные выражения, доставляющие тип, если таковые допускаются языком. Типы данных, которые определены в модели. В стандарте UML предусмотрен только один конструктор типов данных: перечислимый тип, который определяется с помощью стереотипа «enumeration». Наряду со стандартным стереотипом «enumeration» многие инструменты допускают использование стереотипа «datatype», который означает построение типа данных с помощью не специфицированного конструктора типов.

Слайд 20

Описание слайда:

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

Слайд 21

Описание слайда:

Шаблон Сам по себе шаблон не может непосредственно использоваться в модели. Для того, чтобы на основе шаблона получить конкретный класс, который может использоваться в модели, нужно указать явные значения аргументов. Такое указание называется связыванием. В UML применяются два способа связывания: явное связывание — зависимость со стереотипом «bind», в которой указаны значения аргументов; неявное связывание — определение класса, имя которого имеет формат имя_шаблона < аргументы >

Слайд 22

Описание слайда:

Шаблон Назначение и область применения шаблонов понятны — шаблоны нужны, чтобы определить некоторую общую параметрическую конструкцию класса один раз, и затем использовать ее многократно, подставляя конкретные значения аргументов. Явное связывание более наглядно, неявное связывание менее наглядно, зато записывается короче.

Слайд 23

Описание слайда:

Шаблон Здесь определен шаблон Array, имеющий два параметра: n типа Integer и T, тип которого не указан. Этот шаблон применяется для создания массивов определенной длины, содержащих элементы определенного типа. В данном случае с помощью явного связывания определен класс Triangle как массив из трех элементов типа Point. С помощью неявного связывания определен аналогичный по смыслу класс с именем Array.

Слайд 24

Описание слайда:

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

Слайд 25

Описание слайда:

Диаграммы классов Описывать структуру удобнее параллельно с описанием поведения. Каждая итерация должна быть небольшим уточнением как структуры, так и поведения. Не обязательно включать в модель все классы сразу. На первых итерациях достаточно идентифицировать очень небольшую (10%) долю всех классов системы. Не обязательно определять все свойства класса сразу. Начните с имени — операции и атрибуты постепенно выявятся в процессе моделирования поведения. Не обязательно показывать на диаграмме все свойства класса. В процессе работы диаграмма должна легко охватываться одним взглядом. Не обязательно определять все отношения между классами сразу. Пусть класс на диаграмме "висит в воздухе" — ничего с ним не случится.

Слайд 26

Описание слайда:

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

Слайд 27

Описание слайда:

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

Слайд 28

Описание слайда:

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

Слайд 29

Описание слайда:

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

Слайд 30

Описание слайда:

Компонент При выделении компонентов применяются следующие неформальные критерии. Компонент нетривиален. Это нечто более сложное и объемное, чем фрагмент кода или одиночный класс. Компонент независим, но не самодостаточен. Он содержит все, что нужно для функционирования, но предназначен для работы во взаимодействии с другими компонентами. Компонент однороден. Он выполняет несколько взаимосвязанных функций, которые могут быть естественным образом охарактеризованы как единое целое в контексте более сложной системы. Компонент заменяем. Он поддерживает строго определенный набор интерфейсов и может быть без ущерба для функционирования системы заменен другим компонентом, поддерживающим те же интерфейсы.

Слайд 31

Описание слайда:

Диаграмма компонентов В случае разработки "монолитного" настольного приложения диаграмма компонентов не нужна — она оказывается тривиальной и никакой полезной информации не содержит. Таким образом, диаграммы компонентов применяются только при моделировании многокомпонентных приложений.

Слайд 32

Описание слайда:

Диаграмма компонентов Если приложение поставляется в виде "конструктора" (набора "кубиков" — компонентов) из которого при установке собирается конкретный уникальный экземпляр приложения, то диаграммы компонентов оказываются просто незаменимым средством. Многие современные приложения поставляются в виде большого (десятки и сотни) набора компонентов, из которых "на месте" собирается нужная пользователю, часто уникальная конфигурация. Рекомендуют использовать диаграммы компонентов для управления конфигурацией не только на фазе поставки и установки программного обеспечения, но и в процессе разработки: для отслеживания версий компонентов, вариантов сборки и т. п.

Слайд 33

Описание слайда:

Диаграмма компонентов

Слайд 34

Описание слайда:

Стереотипы компонентов

Слайд 35

Описание слайда:

Зависимость компонентов

Слайд 36

Описание слайда:

Диаграмма компонентов

Слайд 37

Описание слайда:

Диаграмма размещения Последним структурным аспектом, который необходимо обсудить, является описание размещения компонентов относительно участвующих в работе вычислительных ресурсов. В UML для этой цели предназначены диаграммы размещения. В UML 2.0 эти диаграммы переименованы в диаграммы развертывания. Если речь идет о настольном приложении, которое целиком хранится и выполняется на одном компьютере, то отдельная диаграмма размещения не нужна. При моделировании распределенных приложений значение диаграмм размещения резко возрастает.

Слайд 38

Описание слайда:

Диаграмма размещения На диаграмме размещения, по сравнению с диаграммами компонентов, применяются только один дополнительный тип сущности — узел и два дополнительных отношения: ассоциация между узлами и размещение компонента на узле. В остальном диаграммы размещения наследуют возможности диаграмм компонентов.

Слайд 39

Описание слайда:

Диаграмма размещения Узел — это физический вычислительный ресурс, участвующий в работе системы. Компоненты системы во время ее работы размещаются на узлах. В UML узел является классификатором, т. е. мы можем (и должны!) различать описание типа вычислительного ресурса (например, рабочая станция, последовательный порт) и описание экземпляра вычислительного устройства (например, устройство COM1 типа последовательный порт). Это различие моделируется согласно общему механизму UML: имя экземпляра узла подчеркивается, а имя типа узла — нет.

Слайд 40

Описание слайда:

Диаграмма размещения На диаграмме узел представляется фигурой, изображающей прямоугольный параллелепипед. На примере (а) - имя типа узла, (б) – имя экземпляра узла .

Слайд 41

Описание слайда:

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

Слайд 42

Описание слайда:

Диаграмма размещения Размещение компонента на узле, как правило, изображают, помещая фигуру компонента внутрь фигуры узла.

Слайд 43

Описание слайда:

Диаграмма размещения Если это по каким-либо причинам неудобно, то отношение размещения можно передать отношением зависимости от узла к компоненту.

Слайд 44

Описание слайда:

Выводы Диаграммы классов моделируют структуру объектов и связей между ними. Классы выбираются на основе анализа предметной области, взаимного согласования элементов модели и общих теоретических соображений. Сущности на диаграммах классов связываются главным образом отношениями ассоциации (в том числе агрегирования и композиции) и обобщения. Базовая нотация ассоциации позволяет указать, что объекты ассоциированных классов могут взаимодействовать во время выполнения. Для ассоциации в UML предусмотрено наибольшее количество различных дополнений.

Слайд 45

Описание слайда:

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