Программная инженерия продолжение раздела 6. 6.2. Объектно-ориентированный подход
Программная инженерия продолжение раздела 6. 6.2. Объектно-ориентированный подход Расписание:
Содержание Предпосылки появления ООП к созданию ИС Язык UML История появления Структура стандарта UML Назначение UML Критика UML Структура UML Сущности, отношения, механизмы расширения, диаграммы 2
В основе ООП лежит объектная декомпозиция, при этом: статическая структура системы описывается в терминах объектов и связей между ними поведение системы описывается в терминах обмена сообщениями между объектами. Каждый объект системы обладает своим собственным поведением, моделирующим поведение объекта реального мира. 3
Предпосылки появления объектно-ориентированного подхода к созданию ИС
Проблемы, стимулировавшие развитие ООП: • необходимость повышения производительности и разработки за счет многократного (повторного) использования ПО • необходимость упрощения сопровождения и модификации разработанных систем (локализация вносимых изменений); • облегчение проектирования систем (за счет сокращения семантического разрыва между структурой решаемых задач и структурой ПО) 5 Объектная модель является наиболее естественным способом представления реального мира.
Понятие объект-ориентированного программирования Термин "объектно-ориентированное программирование" принят преимущественно в российской литературе: Объектно-ориентированное программирование (ООП, Object-Oriented Programming) - совокупность принципов, технологий, а также инструментальных средств для создания программных систем на основе архитектуры взаимодействия объектов. В западной литературе под этим термином понимается сразу три аспекта: 6 OOP OOD OOA
ООР (object-oriented programming) – это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования ООD (object-oriented design) – это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динамической моделей проектируемой системы. ООА (object-oriented analysis) – это методология, при использовании которой требования к проектируемой системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области.
Наиболее существенным обстоятельством в развитии методологии ООП явилось осознание того, что процесс написания программного кода может быть отделен от процесса проектирования структуры программы. До написания кода необходимо провести общий анализ требований к будущей программе анализ конкретной предметной области, для которой разрабатывается программа. Все это привело к появлению специальной методологии - методологии объектно-ориентированного анализа и проектирования (ООАП). 8
Язык UML История UML Назначение UML
Унифицированный язык моделирования (Unified Modelling Language, UML) является графическим языком для визуального представления, составления спецификаций, проектирования и документирования систем, в которых большая роль принадлежит программному обеспечению. Гради БУЧ. Время появления с 1989 по 1997 год.
История появления и развития 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
Унифицированный язык моделирования (UML) в настоящий момент является стандартом де-факто при описании (документирования) результатов проектирования и разработки объектно-ориентированных систем. Формальная спецификация последней версии UML 2.0 опубликована в августе 2005 года. Последняя версия UML 2.4.1 опубликована в августе 2011 года. UML 2.4.1 принят в качестве международного стандарта ISO/IEC 19505-1, 19505-2. 13
Интернет-ресурсы по UML Спецификации текущей версии 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 ) 14
Структура стандарта UML Весь текст описания UML каждой версии находится в свободно распространяемых документах, доступных по адресу www.omg.org. Ниже перечислены основные документы, входящие в комплект документации для версии UML 2.4.1 (август 2011). 15 http://book.uml3.ru/sec_1_3
Выводы UML является мощным, гибким средством моделирования, описание стандарта которого является открытым для последующего совершенствования. Неоднозначность как некоторых конструкций самого языка, так и подходов к его формальной семантике, наличие в спецификации неформальных описаний требует дальнейшего развития формальной основы для полной и непротиворечивой интерпретации языка. 16
Требования к UML Позволяет моделировать как программное обеспечение сложных систем, так и широкие классы самих систем и бизнес-приложений, с использованием объектно-ориентированных понятий и методов Обеспечивает взаимосвязь между базовыми понятиями моделей концептуального, программного и физического уровней Понятен системным аналитикам и программистам Поддерживается специальными инструментальными программными средствами, реализованными на различных компьютерных платформах
Термин “унифицированный” в названии UML имеет 2 аспекта: С одной стороны, он фактически устраняет многие из несущественных различий между известными ранее языками моделирования и методиками построения диаграмм. С другой стороны, создает предпосылки для унификации различных моделей и этапов их разработки для широкого класса систем, не только программного обеспечения, но и бизнес-процессов. Семантика языка UML определена таким образом, что она не является препятствием для последующих усовершенствований при появлении новых концепций моделирования. 18
Типичный процесс создания продукта, или "решения" 19
Проблемы программной инженерии Рисунок на предыдущем слайде иллюстрирует проблемы программной инженерии. В частности - проблемы с коммуникацией и пониманием, вызванные отсутствием четкой спецификации создаваемого продукта. Авторы UML определяют его как графический язык моделирования общего назначения (т. е. его можно применять для проектирования чего угодно - от простой качели, как на рисунке, до сложного аппаратно-программного комплекса или даже космического корабля), предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых в ходе разработки. 20
http://pvti.ru/lect1-lecture3.htm Cитуация, существовавшая в области технологий программирования до UML. 21 Основной недостаток: объединение текста программы (ее исходного кода) с характеристиками объекта автоматизации осуществляется только в сознании программиста, а документальная связь между ними отсутствует.
Наличие теоретической основы позволяет упростить операции преобразования UML диаграмм, нарисованных на экранах дисплеев, в память компьютеров и уменьшить объем памяти, необходимой для хранения диаграмм. 22 математическая основа UML – Теория множеств и Теория графов. Cитуация, после появления UML. Диаграммы и спецификации языка UML связали исходный текст программы с характеристиками объекта автоматизации. UML диаграммы могут преобразовываться в исходный код (прямое преобразование) и наоборот исходный код может преобразовываться в диаграммы (обратное преобразование). В некоторых случаях прямое преобразование может осуществляться автоматически с помощью программ конверторов. В наст. время группа OMG активно работает над решением проблемы прямого преобразования диаграмм UML. Обратное преобразование может выполнить только человек. Использование UML позволяет решить болезненную проблему увольнения программистов. После увольнения программиста другой программист, используя UML диаграммы и спецификации, может понять исходный код программы и заменить уволившегося. UML диаграммами и спецификациями создает единый язык общения между программистами, а также между программистами, системными аналитиками и заказчиками автоматизированной системы. Самое главное, что дал UML - это возможность широкой стандартизации языков программирования. Известно, что в разных языках программирования используются одинаковые операции и методы, но они имеют разные названия и символьные обозначения. Язык UML позволяет стандартизовать как сами операции и методы языков программирования так и их терминологию.
Назначение UML* Сами авторы UML определяют свое детище следующим образом. “Язык UML ‒ это графический язык моделирования общего назначения, предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых при разработке программных систем.” 23 * - по книге Моделирование на UML http://book.uml3.ru/sec_1_2 Графическое представление модели UML не тождественно самой модели. Это важное обстоятельство часто упускается из виду при первом знакомстве с UML.
Спецификация Основное назначение UML ‒ предоставить, с одной стороны, достаточно формальное, с другой стороны, достаточно удобное, и, с третьей стороны, достаточно универсальное средство, позволяющее до некоторой степени снизить риск расхождений в толковании спецификаций. 24
Визуализация Особенности человеческого восприятия таковы, что текст с картинками воспринимается легче, чем голый текст. А картинки с текстом ("комиксы") ‒ еще легче. Модели UML допускают представление в форме картинок, причем эти картинки наглядны, интуитивно понятны, практически однозначно интерпретируются и легко составляются. Таким образом, второе по важности назначение UML состоит в том, чтобы служить адекватным средством коммуникации между людьми. 25 лучше один раз увидеть, чем сто раз услышать. Мы добавим: тем паче тысячу раз прочитать пересказ.
Проектирование В оригинале данное назначение UML определено с помощью слова construct, которое мы передаем осторожным термином "проектирование". Речь идет о том, что UML предназначен не только для описания абстрактных моделей приложений, но и для непосредственного манипулирования артефактами, входящими в состав этих приложений, в том числе такими, как программный код. Другими словами, одним из назначений UML является, например, создание таких моделей, для которых возможна автоматическая генерация программного кода (или фрагментов кода) соответствующих приложений. Более того, природа моделей UML такова, что возможен и обратный процесс: автоматическое построение модели по коду готового приложения. 26 Это очень трудная задача, но не безнадежная. Инструменты, поддерживающие UML, все время совершенствуются, так что в перспективе третье предназначение UML может выйти и на первое место.
Документирование Модели UML являются артефактами, которые можно хранить и использовать как в форме электронных документов, так и в виде твердой копии. В последних версиях UML с целью достижения более полного соответствия этому назначению сделано довольно много. В частности, специфицировано представление моделей UML в форме документов в формате XMI, что обеспечивает практическую интероперабельность при работе с моделями. Другими словами, модели UML не являются вещью в себе, которой можно только любоваться ‒ это документы, которые можно использовать самыми разными способами, начиная с печати картинок и заканчивая автоматической генерацией человекочитаемых текстовых описаний. 27 XMI (XML Metadata Interchange) ‒ внешний формат данных, основанный на языке XML (схема и набор правил использования тэгов), предназначенное для сериализации моделей и обмена ими.
3 основных варианта использования UML (показаны на диаграмме использования UML) 28 http://book.uml3.ru/sec_1_2
Пояснения к рисунку (фрагмент учебника) Вариант использования drawing ("Рисование диаграмм") подразумевает изображение диаграмм UML с целью обдумывания, обмена идеями между людьми, документирования и тому подобного. Значимым для пользователя User результатом в этом случае является само изображение диаграмм. Вообще говоря, в этом варианте использования языка поддерживающий инструмент не очень нужен. Иногда рисование диаграмм от руки фломастером с последующим фотографированием цифровым аппаратом может оказаться практичнее. Вариант использования modeling ("Моделирование систем") подразумевает создание и изменение модели системы в терминах тех элементов моделирования, которые предусматриваются метамоделью UML. Значимым результатом в этом случае является машинно-читаемый артефакт с описанием модели. Мы будем для краткости называть такой артефакт просто моделью, деятельность по составлению модели называть моделированием, а субъекта моделирования называть архитектором Architect. 29
Пояснения к рисунку (фрагмент учебника) Вариант использования development ("Разработка приложений") подразумевает детальное моделирование, реализацию и тестирование приложения в терминах UML. Значимым для пользователя Developer результатом в этом случае является работающее приложение, которое может быть скомпилировано в язык, поддерживаемый конкретной системой программирования Programming System или сразу интерпретировано средой выполнения инструмента. Этот вариант использования наиболее сложен в реализации. Современные инструменты поддерживают указанные варианты использования далеко не в равной степени. 30
Модель с позиций ООАП С точки зрения методологии ООАП достаточно полная модель сложной системы представляет собой определенное число взаимосвязанных представлений (views), каждое из которых адекватно отражает аспект поведения или структуры системы. При этом наиболее общими представлениями сложной системы принято считать статическое и динамическое, которые в свою очередь могут подразделяться на другие более частные.
Критика UML (фрагмент статьи) Несмотря на то, что UML достаточно широко распространённый и используемый стандарт, его часто критикуют из-за следующих недостатков: Избыточность языка. UML часто критикуется, как неоправданно большой и сложный. Он включает много избыточных или практически неиспользуемых диаграмм и конструкций. Чаще это можно услышать в отношении UML 2.0, чем UML 1.0, так как более новые ревизии включают больше «разработанных-комитетом» компромиссов. Неточная семантика. Так как UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений — формальной проверки правильности) и Английского (подробная семантика), то он лишен скованности присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и Английский противоречат друг другу, в других случаях они неполные. Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций. 32 http://www.mykiev.kiev.ua/nauka/uml.php Объектный язык ограничений (Object Constraint Language) - эта текстовый язык, который служит для определения ограничений и запросов. Он не предназначен для написания действий или выполнимого кода.
Критика UML Проблемы при изучении и внедрении. Вышеописанные проблемы делают проблематичным изучение и внедрение UML, особенно когда руководство насильно заставляет использовать UML инженеров при отсутствии у них предварительных навыков. Только код отражает код. Ещё одно мнение — что важны рабочие системы, а не красивые модели. Как лаконично выразился Джек Ривс, «The code is the design» («Код и есть проект»). В соответствии с этим мнением, существует потребность в лучшем способе написания ПО; UML ценится при подходах, которые компилируют модели для генерирования исходного или выполнимого кода. Однако этого всё же может быть недостаточно, так как UML не имеет свойств полноты по Тьюрингу и любой сгенерированный код будет ограничен тем, что может разглядеть или предположить интерпретирующий UML инструмент. 33 http://www.mykiev.kiev.ua/nauka/uml.php
Критика UML Кумулятивная нагрузка/Рассогласование нагрузки (Cumulative Impedance/Impedance mismatch). Рассогласование нагрузки — термин из теории системного анализа для обозначения неспособности входа системы воспринять выход другой. Как в любой системе обозначений UML может представить одни системы более кратко и эффективно, чем другие. Таким образом, разработчик склоняется к решениям, которые более комфортно подходят к переплетению сильных сторон UML и языков программирования. Проблема становится более очевидной, если язык разработки не придерживается принципов ортодоксальной объектно-ориентированной доктрины (не старается соответствовать традиционным принципам ООП). Пытается быть всем для всех. UML — это язык моделирования общего назначения, который пытается достигнуть совместимости со всеми возможными языками разработки. В контексте конкретного проекта, для достижения командой проектировщиков определённой цели, должны быть выбраны применимые возможности UML. Кроме того, пути ограничения области применения UML в конкретной области проходят через формализм, который не полностью сформулирован, и который сам является объектом критики. 34 http://www.mykiev.kiev.ua/nauka/uml.php
Структура UML
Общая структура UML 36 ОСНОВЫ УНИФИЦИРОВАННОГО ЯЗЫКА МОДЕЛИРОВАНИЯ http://edu.dvgups.ru/METDOC/GDTRAN/YAT/ITIS/PROEK_INF_SIS/METOD/UMK_DO/frame/UMK_DO/M6/L11.htm#11_1 Синтаксис (syntax) - определение правил составления конструкций языка. Семантика (semantics) - определение правил приписывания смысла конструкциям языка.
Графические элементы Авторы исходили из того, что UML будет использоваться по-разному: начиная от не очень аккуратного рисования от руки на листке бумаги, печати черно-белых изображений в книгах и заканчивая созданием сложных диаграмм с помощью компьютера. Поэтому в качестве основных графических элементов были выбраны такие, которые было бы легко использовать во всех случаях. Типов элементов нотации пять: фигура (shape); линия (line); значок (icon); текст (text); рамка (frame). 37
Использование цвета нотация UML довольно свободная: рисовать можно как угодно, лишь бы не возникало недоразумений. Поставщики инструментов, поддерживающих UML, пользуются этой свободой кто во что горазд. Использование цветов для заливки фигур и раскрашивания линий, тени у значков и фигур, разные шрифты в текстах, наконец, анимация изображений ‒ все это, конечно, полезные вещи, поскольку повышают наглядность картинок. Важно при этом знать меру, а мера очень проста и даже имеет название ‒ каноническая нотация (canonical notation). Согласно ей любая модель может быть описана монохромными рисунками с текстовыми пояснениями. При этом рисунки должны оставаться вразумительными после печати на черно-белом принтере. 38
Классов Объектов Прецендентов Последовательностей Коопераций Состояний Действий Компонентов Развертывания Структурные Поведенческие Группирующие Аннотационные Включения Ассоциаций Обобщений Расширения Структура UML (три разновидности строительных блоков) Сущности являются основными объектно-ориентированными элементами языка. С их помощью можно создавать корректные модели. Структурные сущности - это имена существительные в моделях на языке UML. Как правило, они представляют собой статические части модели, соответствующие концептуальным или физическим элементам системы
Типы сущностей(иногда называют - предметы) Структурные - существительные в UML-моделях. Это статические части модели — понятийные или физические элементы. Поведенческие В некоторых источниках выделяют также поведенческие сущности взаимодействия и конечные автоматы, но с логической точки зрения их следует отнести к диаграммам. Группирующие - организационные части UML-моделей. Это ящики, по которым может быть разложена модель. Аннотационные (или поясняющие) -разъясняющие части UML-моделей. Они являются замечаниями, применяемыми для описания, объяснения и комментирования любого элемента модели. 40
Отношения Отношения связывают предметы. (изображаются графически в виде различных линий) 41
Диаграммы Диаграмма представляет собой группировку элементов нотации для отображения некоторого аспекта разрабатываемой информационной системы. Диаграммы представляют собой, как правило, связный граф, в котором сущности являются вершинами, а отношения – дугами. 42
Структурные сущности Классы Объекты Интерфейсы Актер Кооперации Преценденты Активные классы Компоненты Узлы
Класс (class) Класс (class) - это описание совокупности объектов с общими атрибутами, операциями отношениями и семантикой Множество объектов, имеющих общую структуру и поведение Класс человек Класс круг Класс реализует один или несколько интерфейсов.
Объект (object) Объект (object) ‒ сущность, обладающая уникальностью и инкапсулирующая в себе состояние и поведение. абстракция реальной или воображаемой сущности с четко выраженными концептуальными границами, индивидуальностью (идентичностью), состоянием и поведением. С точки зрения UML объекты являются экземплярами класса (экземплярами сущности) 45 Объект (object)
Интерфейс (interface) Интерфейс (interface) - это совокупность операций, определяющая сервис (набор услуг), предоставляемый классом или компонентом. На диаграммах интерфейс изображается в виде круга, под которым указывается его имя. Интерфейс очень редко, практически никогда, существует сам по себе - обычно он присоединяется к реализующему его классу или компоненту. iРасчет
Актер (actor) — набор согласованных ролей, которые играют пользователи при взаимодействии с системой (ее элементами Use Case). Каждая роль требует от системы определенного поведения. внешняя по отношению к системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. Таким образом актер – это внешний источник или приемник информации. 47 Инженер службы пути
Кооперация (collaboration) Кооперация (collaboration) определяет взаимодействие, она представляет собой совокупность ролей и других элементов, которые, работая вместе, производят некоторый кооперативный эффект, не сводящийся к обычно сумме слагаемых. описание совокупности экземпляров актеров, объектов и их взаимодействия в процессе решения некоторой задачи Конкретный класс может участвовать в нескольких кооперациях. Кооперации представляют реализацию паттернов (образцов), которые формируют систему.
Прецедент (use case) Use Case (Прецедент/Вариант использования) - это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера (actor). Обработка заказа
Активный класс (active class) Активным классом (active class) называется класс, объекты которого вовлечены в один или несколько процессов, или нитей (threads), и поэтому могут инициировать управляющее воздействие.
Компонент (component) - это физическая заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию. В систему включаются компоненты: результаты процесса разработки (файлы исходного кода); разновидности компонентов (СОМ+-компоненты, Java Beans). Компонент — это физическая упаковка различных логических элементов (классов, интерфейсов и коопераций).
Узел (node) Узел (node) - это элемент реальной (физической) системы, который существует во время функционирования программного продукта и представляет собой некоторый вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти, а часто еще и возможностью обработки. физическая часть системы (компьютер, принтер и т. д.), предоставляющая ресурсы для решения задачи
Выше перечислены только базовые элементы, которые являются основными структурными сущностями, использующиеся в модели UML. Есть и другие разновидности сущностей: состояния, сигналы, утилиты (виды классов), процессы и нити (виды активных классов), приложения, документы, файлы, библиотеки, страницы и таблицы (виды компонентов).
Группирующие сущности организационные части UML-моделей
Пакет(packages) Это ящики, по которым может быть разложена модель. Предусмотрена одна разновидность группирующего предмета — пакет. Пакет — общий механизм для распределения элементов по группам. В пакет помещаются структурные предметы, предметы поведения и другие группировки предметов. В отличие от компонента, существующего в период выполнения, пакет — концептуальное понятие. Т.о. пакет существует только в период разработки. 55 UML позволяет сгруппировать в пакеты: UseCase; Class; Components.
Способы изображения пакетов 56
Аннотационная (поясняющая) сущность разъясняющие части UML-моделей
Примечание(comment) Комментарий к элементу Они являются замечаниями, применяемыми для описания, объяснения и комментирования любого элемента модели. Предусмотрена одна разновидность поясняющего предмета — примечание. Примечание — символ для отображения ограничений и замечаний, присоединяемых к элементу или совокупности элементов. 58
Поведенческие сущности (Behavioral things) динамические составляющие UML- модели
Поведенческие сущности — динамические части UML-моделей — глаголы моделей, представление поведения во времени и пространстве. Описывают поведение модели во времени и пространстве. Поведенческие сущности: взаимодействия и конечные автоматы. С логической точки зрения их следует отнести к диаграммам 60 Семантически эти элементы ассоциируются со структурными элементами (с классами, кооперациями и объектами).
Взаимодействие(Interaction) — поведение, заключающее в себе набор сообщений (Messages), которыми обменивается набор объектов в конкретном контексте для достижения определенной цели. При помощи взаимодействия можно описать либо отдельную операцию, либо поведение совокупности объектов. Элементы взаимодействия: сообщения, последовательность действий (поведение, вызываемое сообщением) и связи (соединения между объектами). 61 Над стрелкой пишется имя операции
Пример использования взаимодействия Взаимодействие 62 Использование взаимодействия на диаграмме последовательности
Конечные автоматы (State machine) — поведение, определяющее последовательность состояний объекта или взаимодействия, выполняемые в ходе его существования в ответ на события (и с учетом обязанностей по этим событиям). С помощью конечного автомата может определяться поведение индивидуального класса или кооперации классов. Элементы конечного автомата: состояния, переходы (от состояния к состоянию), события (предметы, вызывающие переходы) и действия (реакции на переход) 63 Состояние (state) ‒ период в жизненном цикле объекта, находясь в котором объект удовлетворяет некоторому условию и осуществляет собственную деятельность или ожидает наступления некоторого события.
Пример конечного автомата Состояния конечного автомата 64 диаграмма конечного автомата
Отношения Связывают сущности
Основные: Виды отношений UML, используемых на диаграммах для указания связей м-ду сущностями 66 Зависимость (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
68
Для ассоциации, агрегации и композиции может указываться кратность (multiplicity), характеризующая общее количество экземпляров сущностей, участвующих в отношении. Указывается с каждой стороны отношения около соответствующей сущности. Способы указания кратности: * – любое количество экземпляров, в том числе и ни одного; целое неотрицательное число – кратность строго фиксирована и равна указанному числу (н-р: 1, 2 или 5); диапазон целых неотрицательных чисел «первое число .. второе число» (н-р: 1..5, 2..10 или 0..5); диапазон чисел от конкретного начального значения до произвольного конечного «первое число .. *» (н-р: 1..*, 5..* или 0..*); перечисление целых неотрицательных чисел и диапазонов через запятую (н-р: 1, 3..5, 10, 15..*). Если кратность не указана, то она =1. Кратность экземпляров сущностей, участвующих в зависимости, обобщении и реализации, всегда принимается =1. 69
Отношения: 70
Примеры использования отношений в диаграммах
В данном случае: Отношение зависимости говорит о том, что внесение изменений в исходные тексты программ или динамические библиотеки приводит к изменениям самого компонента(main.exe). Характер изменений может быть отмечен дополнительно. Зависимость(кратность всегда 1) - указывает на то, что изменение независимой сущности каким-то образом влияет на зависимую сущность. 72 Отношения зависимости на диаграмме компонентов Со стороны стрелки – независимая сущность С обратной стороны – зависимая сущность
Зависимость 73 На диаграмме показаны отношения зависимости между узлом и развернутыми на нем компонентами Отношения зависимости на диаграмме развертывания независимые сущности (компоненты) зависимая сущность Кратность (multiplicity) для отношения зависимость всегда =1
Реализация(кратность всегда 1) 74 Отношения реализации и зависимости на диаграмме пакетов Отношение реализации на данной диаграмме говорит о том, что пакет с именем “Database Gateway" реализуется тремя пакетами. зависимая сущность (пакет) Отношение реализации независимая сущность (пакет) Отношение зависимости
Реализация интерфейса 75 Отношение реализации на диаграмме классов В данном случае отношение реализации говорит о том, что класс Каталог должен реализовать интерфейс Обработчик каталога, то есть: Обработчик каталога рассматривается как источник, а Каталог — как приемник. Интерфейс Обработчик каталога позволяет клиентам взаимодействовать с объектами класса Каталог без знания той дисциплины доступа, которая здесь реализована. Отношение реализации Интерфейс Класс
Ассоциация описывает значимую связь между двумя и более сущностями. 76 Отношения ассоциации на диаграмме вариантов ипользования (или диаграмме прецендентов) Отношение ассоциации
Ассоциация может объединять три и более класса. В этом случае она называется n-арной и изображается ромбом на пересечении линий 77 Отношения ассоциации Отношения ассоциации на диаграмме классов
Ассоциация, реализация и зависимость Вопрос: Какие здесь есть структурные сущности? О чем говорят указанные отношения в данном случае? 78 Отношения ассоциация реализация и зависимость на диаграмме вариантов ипользования
Обобщение(кратность всегда 1) 79 Отношения обобщение на диаграмме классов Отношение обобщения
Обобщение 80 Отношение обобщение и ассоциации на диаграмме вариантов использования Отношение обобщения Отношение ассоциации Отношение обобщения в данном случае говорит о том, что общим словом Analyst, Architect, Tester можно назвать - User
Агрегация отношение агрегации означает включение нескольких классов в другой класс 81 Отношение агрегации говорит о том, что в состав класса Сервиз в качестве самостоятельных единиц могут входить тарелки и чашки и чайник Отношение агрегация на диаграмме классов Отношение агрегация Ромбик у главного класса
Композиция отношение композиции показывает, что компонент состоит из нескольких частей, которые в отличие от отношения агрегации не могут использоваться отдельно. 82 Отношение композиции на диаграмме классов Составными частями класса Газета являются редакционные статьи, фотоиллюстрации, реклама, которые не могут существовать отдельно от самой газеты, если под газетой понимать лист бумаги Ромбик у главного класса
Композиция и агрегация могут иметь кратность отличную от 1 83
Механизмы расширения Не во всех учебниках механизмы расширения рассматриваются как отдельный элемент. И действительно, механизм расширения - используется лишь для уточнения семантики сущностей и отношений – это всего лишь подписи
Механизмы расширения - применяются для уточнения семантики сущностей и отношений. В общем случае, механизм расширения представляет собой строку текста, заключенную в скобки или кавычки. 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
Примеры диаграмм (повторение)
Диаграмма, описывающая предметную область сказки о Курочке Рябе (взята с сайта конкурса шуток на UML (http://www.umljokes.com/) 99 диаграмма объектов Стереотип “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 Какие сущности и отношения показаны на диаграмме?
Скачать презентацию Программная инженерия продолжение раздела 6. 6.2. Объектно-ориентированный подход
16218-pr_ingh_4_lek_oop_uml.ppt
- Количество слайдов: 106