Предпосылки появления ООП к созданию ИС презентация

Содержание

Содержание Предпосылки появления ООП к созданию ИС Язык UML История появления Структура стандарта UML Назначение UML Критика UML Структура UML Сущности, отношения, механизмы расширения, диаграммы

Слайд 1Программная инженерия продолжение раздела 6. 6.2. Объектно-ориентированный подход
Расписание:

Слайд 2Содержание
Предпосылки появления ООП к созданию ИС
Язык UML История появления
Структура стандарта UML
Назначение

UML
Критика UML
Структура UML
Сущности, отношения, механизмы расширения, диаграммы



Слайд 3В основе ООП
лежит объектная декомпозиция, при этом:
статическая структура системы описывается

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

Слайд 4Предпосылки появления объектно-ориентированного подхода к созданию ИС

Слайд 5Проблемы, стимулировавшие развитие ООП:
• необходимость повышения производительности и разработки за счет

многократного (повторного) использования ПО
• необходимость упрощения сопровождения и модификации разработанных систем (локализация вносимых изменений);
• облегчение проектирования систем (за счет сокращения семантического разрыва между структурой решаемых задач и структурой ПО)

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

Слайд 6Понятие объект-ориентированного программирования
Термин "объектно-ориентированное программирование" принят преимущественно в российской литературе:
Объектно-ориентированное программирование

(ООП, Object-Oriented Programming) - совокупность принципов, технологий, а также инструментальных средств для создания программных систем на основе архитектуры взаимодействия объектов.
В западной литературе под этим термином понимается сразу три аспекта:

OOP

OOD

OOA

Слайд 7


ООР (object-oriented programming) – это методология программирования, основанная на представлении программы

в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования
ООD (object-oriented design) – это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динамической моделей проектируемой системы.
ООА (object-oriented analysis) – это методология, при использовании которой требования к проектируемой системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области.


Слайд 8Наиболее существенным обстоятельством в развитии методологии ООП явилось осознание того, что

процесс написания программного кода может быть отделен от процесса проектирования структуры программы.
До написания кода необходимо провести
общий анализ требований к будущей программе
анализ конкретной предметной области, для которой разрабатывается программа.
Все это привело к появлению специальной методологии - методологии объектно-ориентированного анализа и проектирования (ООАП).

Слайд 9Язык UML
История UML
Назначение UML

Слайд 10Унифицированный язык моделирования (Unified Modelling Language, UML)
является графическим языком для визуального

представления, составления спецификаций, проектирования и документирования систем, в которых большая роль принадлежит программному обеспечению.
Гради БУЧ.

Время появления с 1989 по 1997 год.

Слайд 11История появления и развития UML
консорциум OMG
(Object Management Group) - консорциум (рабочая

группа), занимающаяся разработкой и продвижением объектно-ориентированных технологий и стандартов
(создан еще в 1989)

Компания Rational Software вместе с
несколькими организациями,
учредила консорциум партнеров UML,
в который первоначально вошли:
как Digital Equipment Corp., HP, i-Logix,
Intellicorp, IBM, ICON Computing,
MCI Systemhouse, Microsoft, Oracle,
Rational Software, TI и Unisys.
Эти компании обеспечили поддержку
последующей работы по более
точному определению нотации.



Слайд 12Начиная работу по унификации своих методов, Г. Буч, Дж. Румбах и

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

Слайд 13Унифицированный язык моделирования (UML) в настоящий момент является стандартом де-факто при

описании (документирования) результатов проектирования и разработки объектно-ориентированных систем.
Формальная спецификация последней версии UML 2.0 опубликована в августе 2005 года.
Последняя версия UML 2.4.1 опубликована в августе 2011 года.
UML 2.4.1 принят в качестве международного стандарта ISOUML 2.4.1 принят в качестве международного стандарта ISO/IEC 19505-1, 19505-2.

Слайд 14Интернет-ресурсы по UML
Спецификации текущей версии UML - http://www.omg.org/Спецификации текущей версии UML

- http://www.omg.org/ и http://www.uml.org/
UML 2.2 — заготовки и шаблоны для MS Visio http://www.softwarestencils.com/uml/index.html
Учебник(на русском языке) Моделирование на UML. Ф.Новиков, Д.Иванов (http://book.uml3.ru/sec_1_2 )


Слайд 15Структура стандарта UML
Весь текст описания UML каждой версии находится в свободно

распространяемых документах, доступных по адресу www.omg.org. Ниже перечислены основные документы, входящие в комплект документации для версии UML 2.4.1 (август 2011).

http://book.uml3.ru/sec_1_3

Слайд 16Выводы
UML является мощным, гибким средством моделирования, описание стандарта которого является открытым

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

Слайд 17Требования к UML
Позволяет моделировать как программное обеспечение сложных систем, так и

широкие классы самих систем и бизнес-приложений, с использованием объектно-ориентированных понятий и методов

Обеспечивает взаимосвязь между базовыми понятиями моделей концептуального, программного и физического уровней

Понятен системным аналитикам и программистам

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

Слайд 18
Термин “унифицированный” в названии UML имеет 2 аспекта:
С одной стороны, он

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

Семантика языка UML определена таким образом, что она не является препятствием для последующих усовершенствований при появлении новых концепций моделирования.

Слайд 19Типичный процесс создания продукта, или "решения"

Слайд 20Проблемы программной инженерии
Рисунок на предыдущем слайде иллюстрирует проблемы программной инженерии.
В частности

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

Слайд 21http://pvti.ru/lect1-lecture3.htm
Cитуация, существовавшая в области технологий программирования до UML.
Основной недостаток:
объединение текста программы

(ее исходного кода) с характеристиками объекта автоматизации осуществляется только в сознании программиста, а документальная связь между ними отсутствует.

Слайд 22Наличие теоретической основы позволяет упростить операции преобразования UML диаграмм, нарисованных на

экранах дисплеев, в память компьютеров и уменьшить объем памяти, необходимой для хранения диаграмм.


математическая основа UML –
Теория множеств и
Теория графов.


Cитуация, после появления UML.

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

Слайд 23Назначение UML*
Сами авторы UML определяют свое детище следующим образом.
“Язык UML ‒ это

графический язык моделирования общего назначения, предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых при разработке программных систем.”

* - по книге Моделирование на UML http://book.uml3.ru/sec_1_2

Графическое представление модели UML не тождественно самой модели. Это важное обстоятельство часто упускается из виду при первом знакомстве с UML.

Слайд 24Спецификация
Основное назначение UML ‒ предоставить, с одной стороны, достаточно формальное, с другой

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

Слайд 25Визуализация
Особенности человеческого восприятия таковы, что текст с картинками воспринимается легче, чем

голый текст. А картинки с текстом ("комиксы") ‒ еще легче. Модели UML допускают представление в форме картинок, причем эти картинки наглядны, интуитивно понятны, практически однозначно интерпретируются и легко составляются.
Таким образом, второе по важности назначение UML состоит в том, чтобы служить адекватным средством коммуникации между людьми.

лучше один раз увидеть, чем сто раз услышать. Мы добавим: тем паче тысячу раз прочитать пересказ.

Слайд 26Проектирование
В оригинале данное назначение UML определено с помощью слова construct, которое

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

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

Слайд 27Документирование
Модели UML являются артефактами, которые можно хранить и использовать как в

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

XMI (XML Metadata Interchange) ‒ внешний формат данных, основанный на языке XML (схема и набор правил использования тэгов), предназначенное для сериализации моделей и обмена ими.

Слайд 283 основных варианта использования UML (показаны на диаграмме использования UML)

http://book.uml3.ru/sec_1_2

Слайд 29Пояснения к рисунку (фрагмент учебника)
Вариант использования drawing ("Рисование диаграмм") подразумевает изображение

диаграмм UML с целью обдумывания, обмена идеями между людьми, документирования и тому подобного. Значимым для пользователя User результатом в этом случае является само изображение диаграмм. Вообще говоря, в этом варианте использования языка поддерживающий инструмент не очень нужен. Иногда рисование диаграмм от руки фломастером с последующим фотографированием цифровым аппаратом может оказаться практичнее.
Вариант использования modeling ("Моделирование систем") подразумевает создание и изменение модели системы в терминах тех элементов моделирования, которые предусматриваются метамоделью UML. Значимым результатом в этом случае является машинно-читаемый артефакт с описанием модели. Мы будем для краткости называть такой артефакт просто моделью, деятельность по составлению модели называть моделированием, а субъекта моделирования называть архитектором Architect.

Слайд 30Пояснения к рисунку (фрагмент учебника)
Вариант использования development ("Разработка приложений") подразумевает детальное

моделирование, реализацию и тестирование приложения в терминах UML. Значимым для пользователя Developer результатом в этом случае является работающее приложение, которое может быть скомпилировано в язык, поддерживаемый конкретной системой программирования Programming System или сразу интерпретировано средой выполнения инструмента. Этот вариант использования наиболее сложен в реализации.
Современные инструменты поддерживают указанные варианты использования далеко не в равной степени.

Слайд 31Модель с позиций ООАП
С точки зрения методологии ООАП достаточно полная модель

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

Слайд 32Критика UML (фрагмент статьи)
Несмотря на то, что UML достаточно широко распространённый

и используемый стандарт, его часто критикуют из-за следующих недостатков:
Избыточность языка. UML часто критикуется, как неоправданно большой и сложный. Он включает много избыточных или практически неиспользуемых диаграмм и конструкций. Чаще это можно услышать в отношении UML 2.0, чем UML 1.0, так как более новые ревизии включают больше «разработанных-комитетом» компромиссов.
Неточная семантика. Так как UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений — формальной проверки правильности) и Английского (подробная семантика), то он лишен скованности присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и Английский противоречат друг другу, в других случаях они неполные. Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций.

http://www.mykiev.kiev.ua/nauka/uml.php

Объектный язык ограничений (Object Constraint Language) - эта текстовый язык, который служит для определения ограничений и запросов. Он не предназначен для написания действий или выполнимого кода.

Слайд 33Критика UML
Проблемы при изучении и внедрении. Вышеописанные проблемы делают проблематичным изучение

и внедрение UML, особенно когда руководство насильно заставляет использовать UML инженеров при отсутствии у них предварительных навыков.
Только код отражает код. Ещё одно мнение — что важны рабочие системы, а не красивые модели. Как лаконично выразился Джек Ривс, «The code is the design» («Код и есть проект»). В соответствии с этим мнением, существует потребность в лучшем способе написания ПО; UML ценится при подходах, которые компилируют модели для генерирования исходного или выполнимого кода. Однако этого всё же может быть недостаточно, так как UML не имеет свойств полноты по Тьюрингу и любой сгенерированный код будет ограничен тем, что может разглядеть или предположить интерпретирующий UML инструмент.

http://www.mykiev.kiev.ua/nauka/uml.php

Слайд 34Критика UML
Кумулятивная нагрузка/Рассогласование нагрузки (Cumulative Impedance/Impedance mismatch). Рассогласование нагрузки — термин из

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

http://www.mykiev.kiev.ua/nauka/uml.php

Слайд 35Структура UML

Слайд 36Общая структура UML
ОСНОВЫ УНИФИЦИРОВАННОГО ЯЗЫКА МОДЕЛИРОВАНИЯ
http://edu.dvgups.ru/METDOC/GDTRAN/YAT/ITIS/PROEK_INF_SIS/METOD/UMK_DO/frame/UMK_DO/M6/L11.htm#11_1
Синтаксис (syntax) - определение правил составления

конструкций языка.
Семантика (semantics) - определение правил приписывания смысла конструкциям языка.

Слайд 37Графические элементы
Авторы исходили из того, что UML будет использоваться по-разному: начиная

от не очень аккуратного рисования от руки на листке бумаги, печати черно-белых изображений в книгах и заканчивая созданием сложных диаграмм с помощью компьютера. Поэтому в качестве основных графических элементов были выбраны такие, которые было бы легко использовать во всех случаях.
Типов элементов нотации пять:
фигура (shape);
линия (line);
значок (icon);
текст (text);
рамка (frame).

Слайд 38Использование цвета
нотация UML довольно свободная: рисовать можно как угодно, лишь бы

не возникало недоразумений. Поставщики инструментов, поддерживающих UML, пользуются этой свободой кто во что горазд. Использование цветов для заливки фигур и раскрашивания линий, тени у значков и фигур, разные шрифты в текстах, наконец, анимация изображений ‒ все это, конечно, полезные вещи, поскольку повышают наглядность картинок. Важно при этом знать меру, а мера очень проста и даже имеет название ‒ каноническая нотация (canonical notation). Согласно ей любая модель может быть описана монохромными рисунками с текстовыми пояснениями. При этом рисунки должны оставаться вразумительными после печати на черно-белом принтере.

Слайд 39Классов
Объектов
Прецендентов
Последовательностей
Коопераций
Состояний
Действий
Компонентов
Развертывания
Структурные
Поведенческие
Группирующие
Аннотационные
Включения
Ассоциаций
Обобщений
Расширения
Структура UML (три разновидности строительных блоков)
Сущности являются основными объектно-ориентированными элементами языка.

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

Слайд 40Типы сущностей(иногда называют - предметы)
Структурные
- существительные в UML-моделях.
Это статические

части модели — понятийные или физические элементы.

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

Группирующие
- организационные части UML-моделей.
Это ящики, по которым может быть разложена модель.

Аннотационные
(или поясняющие) -разъясняющие части UML-моделей.
Они являются замечаниями, применяемыми для описания, объяснения и комментирования любого элемента модели.

Слайд 41Отношения
Отношения связывают предметы. (изображаются графически в виде различных линий)

Слайд 42Диаграммы
Диаграмма представляет собой группировку элементов нотации для отображения некоторого аспекта разрабатываемой

информационной системы. Диаграммы представляют собой, как правило, связный граф, в котором сущности являются вершинами, а отношения – дугами.

Слайд 43Структурные сущности
Классы Объекты
Интерфейсы Актер
Кооперации Преценденты
Активные классы Компоненты
Узлы






Слайд 44Класс (class)
Класс (class) - это описание совокупности объектов с общими

атрибутами, операциями отношениями и семантикой
Множество объектов, имеющих общую структуру и поведение


Класс человек

Класс круг

Класс реализует один или несколько интерфейсов.

Слайд 45Объект (object)
Объект (object)  ‒ сущность, обладающая уникальностью и инкапсулирующая в

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


Объект
(object)

Слайд 46Интерфейс (interface)
Интерфейс (interface) - это совокупность операций, определяющая сервис (набор

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

iРасчет

Слайд 47Актер (actor)
— набор согласованных ролей, которые играют пользователи при взаимодействии с

системой (ее элементами Use Case). Каждая роль требует от системы определенного поведения.
Внешняя по отношению к системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. Таким образом актер – это внешний источник или приемник информации.

Инженер службы пути

Слайд 48Кооперация (collaboration)
Кооперация (collaboration) определяет взаимодействие, она представляет собой совокупность ролей

и других элементов, которые, работая вместе, производят некоторый кооперативный эффект, не сводящийся к обычно сумме слагаемых.

Описание совокупности экземпляров актеров, объектов и их взаимодействия в процессе решения некоторой задачи

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

Слайд 49Прецедент (use case)
Use Case (Прецедент/Вариант использования) - это описание последовательности

выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера (actor).

Обработка заказа

Слайд 50Активный класс (active class)
Активным классом (active class) называется класс, объекты

которого вовлечены в один или несколько процессов, или нитей (threads), и поэтому могут инициировать управляющее воздействие.

Слайд 51Компонент (component)
- это физическая заменяемая часть системы, которая соответствует некоторому

набору интерфейсов и обеспечивает его реализацию.

В систему включаются компоненты:
результаты процесса разработки (файлы исходного кода);
разновидности компонентов (СОМ+-компоненты, Java Beans).
Компонент — это физическая упаковка различных логических элементов (классов, интерфейсов и коопераций).

Слайд 52Узел (node)
Узел (node) - это элемент реальной (физической) системы, который

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

Физическая часть системы (компьютер, принтер и т. д.), предоставляющая ресурсы для решения задачи

Слайд 53Выше перечислены только базовые элементы, которые являются основными структурными сущностями, использующиеся

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

Слайд 54Группирующие сущности
организационные части UML-моделей

Слайд 55Пакет(packages)
Это ящики, по которым может быть разложена модель. Предусмотрена одна разновидность

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

UML позволяет сгруппировать в пакеты:
UseCase; Class; Components.

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

Слайд 57Аннотационная (поясняющая) сущность
разъясняющие части UML-моделей

Слайд 58Примечание(comment)
Комментарий к элементу
Они являются замечаниями, применяемыми для описания, объяснения и комментирования

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

Слайд 59Поведенческие сущности (Behavioral things)
динамические составляющие UML-
модели

Слайд 60Поведенческие сущности
— динамические части UML-моделей — глаголы моделей, представление поведения

во времени и пространстве.
Описывают поведение модели во времени и пространстве.
Поведенческие сущности:
взаимодействия и
конечные автоматы.
С логической точки зрения их следует отнести к диаграммам

Семантически эти элементы ассоциируются со структурными элементами (с классами, кооперациями и объектами).

Слайд 61Взаимодействие(Interaction)
— поведение, заключающее в себе набор сообщений (Messages), которыми обменивается набор

объектов в конкретном контексте для достижения определенной цели. При помощи взаимодействия можно описать либо отдельную операцию, либо поведение совокупности объектов.
Элементы взаимодействия: сообщения, последовательность действий (поведение, вызываемое сообщением) и связи (соединения между объектами).


Над стрелкой пишется
имя операции

Слайд 62Пример использования взаимодействия
Взаимодействие
Использование взаимодействия на диаграмме последовательности

Слайд 63Конечные автоматы (State machine)
— поведение, определяющее последовательность состояний объекта или взаимодействия,

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

Состояние (state)  ‒ период в жизненном цикле объекта, находясь в котором объект удовлетворяет некоторому условию и осуществляет собственную деятельность или ожидает наступления некоторого события.

Слайд 64Пример конечного автомата
Состояния конечного автомата
диаграмма конечного автомата

Слайд 65Отношения
Связывают сущности

Слайд 66Основные:
Виды отношений UML, используемых на диаграммах для указания связей м-ду сущностями 
Зависимость

(dependency)

Ассоциация (association)

Обобщение (generalization)

Реализация (realization)

Агрегация (aggregation) – подвид ассоциации

Композиция (composition) – подвид агрегации

Слайд 67Отношения
http://edu.dvgups.ru/METDOC/GDTRAN/YAT/ITIS/PROEK_INF_SIS/METOD/UMK_DO/frame/UMK_DO/M6/L11.htm#11_1

Слайд 69Для ассоциации, агрегации и композиции может указываться кратность (multiplicity), характеризующая общее

количество экземпляров сущностей, участвующих в отношении.
Указывается с каждой стороны отношения около соответствующей сущности. Способы указания кратности:
* – любое количество экземпляров, в том числе и ни одного;
целое неотрицательное число – кратность строго фиксирована и равна указанному числу (н-р: 1, 2 или 5);
диапазон целых неотрицательных чисел «первое число .. второе число» (н-р: 1..5, 2..10 или 0..5);
диапазон чисел от конкретного начального значения до произвольного конечного «первое число .. *» (н-р: 1..*, 5..* или 0..*);
перечисление целых неотрицательных чисел и диапазонов через запятую (н-р: 1, 3..5, 10, 15..*).
Если кратность не указана, то она =1. Кратность экземпляров сущностей, участвующих в зависимости, обобщении и реализации, всегда принимается =1.

Слайд 70Отношения:

Слайд 71Примеры использования отношений в диаграммах

Слайд 72В данном случае:
Отношение зависимости
говорит о том, что внесение изменений

в исходные тексты программ или динамические библиотеки приводит к изменениям самого компонента(main.exe).
Характер изменений может быть отмечен дополнительно.

Зависимость(кратность всегда 1)

- указывает на то, что изменение независимой сущности каким-то образом влияет на зависимую сущность.

Отношения
зависимости
на диаграмме компонентов

Со стороны стрелки – независимая сущность

С обратной стороны – зависимая сущность


Слайд 73Зависимость
На диаграмме показаны отношения зависимости между узлом и развернутыми на нем

компонентами

Отношения
зависимости
на диаграмме развертывания


независимые сущности
(компоненты)

зависимая сущность

Кратность (multiplicity)
для отношения зависимость
всегда =1

Слайд 74Реализация(кратность всегда 1)
Отношения
реализации и зависимости
на диаграмме пакетов

Отношение реализации на

данной диаграмме говорит о том, что пакет с именем “Database Gateway" реализуется тремя пакетами.

зависимая сущность
(пакет)

Отношение реализации

независимая сущность
(пакет)

Отношение зависимости

Слайд 75Реализация интерфейса
Отношение
реализации на диаграмме классов

В данном случае отношение реализации говорит

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

Отношение реализации

Интерфейс

Класс

Слайд 76Ассоциация
описывает значимую связь между двумя
и более сущностями.
Отношения
ассоциации
на

диаграмме вариантов ипользования
(или диаграмме прецендентов)


Отношение ассоциации


Слайд 77Ассоциация может
объединять три и более класса. В этом случае она называется

n-арной и изображается ромбом на пересечении линий

Отношения ассоциации

Отношения
ассоциации
на диаграмме классов


Слайд 78Ассоциация, реализация и зависимость
Вопрос: Какие здесь есть структурные сущности? О чем

говорят указанные отношения в данном случае?

Отношения
ассоциация реализация и зависимость
на диаграмме вариантов ипользования


Слайд 79Обобщение(кратность всегда 1)
Отношения
обобщение
на диаграмме классов
Отношение обобщения

Слайд 80Обобщение
Отношение
обобщение и ассоциации
на диаграмме вариантов использования
Отношение обобщения
Отношение ассоциации

Отношение обобщения

в данном случае говорит о том, что общим словом
Analyst, Architect, Tester
можно назвать - User

Слайд 81Агрегация
отношение агрегации означает включение нескольких классов в другой класс

Отношение агрегации говорит

о том, что в состав класса Сервиз в качестве самостоятельных единиц могут входить тарелки и чашки и чайник

Отношение
агрегация
на диаграмме классов

Отношение агрегация

Ромбик у главного класса


Слайд 82Композиция
отношение композиции показывает, что компонент состоит из нескольких частей, которые в отличие

от отношения агрегации не могут использоваться отдельно.

Отношение
композиции
на диаграмме классов

Составными частями класса Газета являются редакционные статьи, фотоиллюстрации, реклама, которые не могут существовать отдельно от самой газеты, если под газетой понимать лист бумаги

Ромбик у главного класса


Слайд 83Композиция и агрегация могут иметь кратность отличную от 1

Слайд 84Механизмы расширения
Не во всех учебниках механизмы расширения рассматриваются как отдельный элемент.
И

действительно, механизм расширения - используется лишь для уточнения семантики сущностей и отношений – это всего лишь подписи

Слайд 85Механизмы расширения
- применяются для уточнения семантики сущностей и отношений. В общем

случае, механизм расширения представляет собой строку текста, заключенную в скобки или кавычки.

Слайд 86Механизмы расширения
http://edu.dvgups.ru/METDOC/GDTRAN/YAT/ITIS/PROEK_INF_SIS/METOD/UMK_DO/frame/UMK_DO/M6/L11.htm#11_1

Слайд 87Пример: стандартные стереотипы классов

Слайд 88Примеры предопределенных стереотипов отношений

Слайд 89Пример использования предопределенных стереотипов
Стереотип “include” в данном случае говорит, что прецедент

ОПОВЕЩЕНИЕ РОДСТВЕННИКОВ включает прецедент СОГЛАСИЕ НА ТРАНСПЛАНТАЦИЮ ОРГАНОВ

ЗС

НЗС

Слайд 90Пример использования предопределенных стереотипов
Скидка
Клиент
Имя
Фамилия
Кол-во заказов
……
Срок действия
Размер(%)
……
“derive”
Стереотип “derive” в данном случае

говорит, что свойства класса СКИДКА вычисляются исходя из свойств класса КЛИЕНТ
(н-р, кол-во заказов)

Слайд 91Пример использования стереотипов на фрагменте диаграммы развертывания
Примечание, определяет рекомендации по технологии

физической реализации соединений в форме примечания

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

Слайд 92Помимо стереотипов, указываемых в виде строки текста в кавычках, на диаграммах

могут использоваться графические стереотипы. На рис. приведены примеры стандартного и стереотипного отображения класса-сущности.

a – стандартное обозначение;
б – стандартное обозначение с текстовым стереотипом;
в – графический стереотип

a б в

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

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

визуального идентификатора (хотя злоупотреблять этой возможностью не следует).

Слайд 94Примеры графических стереотипов
Например, рабочую станцию можно изобразить в виде ресурсоемкого узла,

или в форме рисунка внешнего вида компьютера.
Мобильный телефон, cканер или принтер и т.д. также может быть изображен в виде рисунка или фотографии данного устройства.

Диаграмма развертывания


Слайд 95Сторожевое условие на диаграмме деятельности
Диаграмма деятельности

Слайд 96Вариант физического представления модели мобильного доступа к корпоративной базе данных на

диаграмме развертывания

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

Слайд 97Пример использования механизмов расширения на диаграмме развертывания

Слайд 98Примеры диаграмм (повторение)

Слайд 99Диаграмма, описывающая предметную область сказки о Курочке Рябе (взята с сайта

конкурса шуток на UML (http://www.umljokes.com/)


диаграмма объектов

Стереотип “enumeration” - определяет перечислимый тип, включая его возможные значения как набор идентификаторов

Какие сущности
и отношения
показаны на
диаграмме?

Слайд 100Диаграмма последовательности

Слайд 101Какого типа диаграмма?
Какие сущности
и отношения
показаны на
диаграмме?

Слайд 102Диаграмма вариантов использования: Какие сущности и отношения показаны на ней?

Какие сущности


и отношения
показаны на
диаграмме?

Сумма сделки

Слайд 103Диаграмма использования
http://www.intuit.ru/studies/courses
/1007/229/lecture/5954?page=1
Какие сущности
и отношения
показаны на
диаграмме?

Слайд 104Диаграмма классов
Какие сущности
и отношения
показаны на
диаграмме?

Слайд 105Диаграмма классов
Какие сущности
и отношения
показаны на
диаграмме?

Слайд 106Диаграмма использования: Прием пациента в больницу.

http://do.gendocs.ru/docs/index-104443.html?page=11
Какие сущности
и отношения
показаны

на
диаграмме?

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

Основы информационной безопасности. Политика безопасности, регламентирующие документы. (Тема 2.3) 248
Об’єкти, функції і події в JavaScript. (Лекція 7) 380
Общее введение в компьютерную графику 364
Моделирования бизнес-процесса 246
Сенсоры роботов 406
Программные средства информатизации 512

Обратная связь

Если не удалось найти и скачать презентацию, Вы можете заказать его на нашем сайте. Мы постараемся найти нужный Вам материал и отправим по электронной почте. Не стесняйтесь обращаться к нам, если у вас возникли вопросы или пожелания:

Email: Нажмите что бы посмотреть 

Что такое ThePresentation.ru?

Это сайт презентаций, докладов, проектов, шаблонов в формате PowerPoint. Мы помогаем школьникам, студентам, учителям, преподавателям хранить и обмениваться учебными материалами с другими пользователями.

Для правообладателей

Яндекс.Метрика