Проектирование ИС. Тема 11. Объектно-ориентированный подход к созданию ИС Унифицированный язык визуального моделирования (UML) - презентация

1 Проектирование ИС. Тема 11. Объектно-ориентированный подход к созданию ИС Унифицированный язык визуального моделирования (UML)

2 2 Тема 11. Объектно-ориентированный подход к созданию ИС. Содержание: Сравнение подходов Предпосылки появления объектно-ориентированного подхода к созданию ИС Основные понятия Unified Modeling Language: - Структура UML - Структурные сущности - Поведенческие сущности - Аннотационная сущность - Отношения - Механизмы расширения - Диаграммы – виды диаграмм

3 Сравнение подходов

4 Сравнение подходов к созданию ИС 4 (UML – Unified Modelling Language) Унифицированный язык объектного моделирования

5 Главное(определяющее) отличие в принципах декомпозиции(разбиения) и структурной организации элементов (компонентов, модулей) системы. При использовании СП (1-ый вид декомпозиции) - выполняется функциональная (процедурная, алгоритмическая) декомпозиция системы, т. е. она представляется в виде иерархии (дерева) взаимосвязанных функций. При ООП (2-ой вид декомпозиции). Система разбивается на набор объектов, соответствующих объектам реального мира, взаимодействующих между собой путем посылки сообщений. ООП - обеспечивает разбиение по автономным лицам объектам реального (или виртуального) мира. Лица (объекты) содержат в себе описания действий и описания данных. 5

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

7 Предпосылки появления объектно-ориентированного подхода к созданию ИС Технологии программирования; OOP; OOA; OOD;

8 Развитие технологий программирования Машинные коды 40-е – 50-е 1-е поколение ( ) 2-е поколение ( ) 3-е поколение ( ) Потерянное поколение ( ?) Языки высокого уровня 50-е – 80-е 90-е – настоящее время

9 Этапы развития: Программирование в машинных кодах программирование с использованием языков высокого уровня использование принципов структурного программирования объектное программирование визуальное программирование 9

10 10 R/INF_SIS/LEK/LEK6.HTM

11 Задание на семинар 1+1 студент Презентация: CASE-инструменты поддерживающие СП к проектированию 1+1 студент Презентация: CASE-инструменты поддерживающие ООП к проектированию Литература: 1. Консалтинг при автоматизации предприятия (Глава 4) (в ЕЭОС - html ) html 2.CASE-технологии. Современные методы и средства проектирования информационных систем А.М. Вендров, "Argussoft Co ( ) 11

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

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

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

15 Соотношение OOA, OOD и ООР ООD ООА ООАП ООР Методы ООАП и ООР базируются на стандартном (унифицированном) языке моделирования UML ООАП Object- Oriented Analysis/Design – объектно- ориентированный анализ и проектирование

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

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

18 Язык UML История UML Назначение UML

19 Основные понятия Унифицированный язык моделирования (Unified Modelling Language, UML) является графическим языком для визуального представления, составления спецификаций, проектирования и документирования систем, в которых большая роль принадлежит программному обеспечению. Гради БУЧ. Время появления с 1989 по 1997 год.

20 История появления и развития UML Гарди Буч, Метод Буча (Booch'93), ориентированный, в первую очередь, на моделирование программного обеспечения сложных систем Джеймс Рамбо, Метод Рамбо (ОМТ-2), ориентированный на анализ процессов обработки данных в информационных системах Айвар Джекобсон, Айвар Джекобсон, Метод Джекобсона (метод OOSE), ориентированный на анализ требований к бизнес- приложениям RSC консорциум OMG (Object Management Group) - консорциум (рабочая группа), занимающаяся разработкой и продвижением объектно- ориентированных технологий и стандартов (создан еще в 1989) RSC - Rational Software Corporation

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

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

23 Интернет-ресурсы по UML Спецификации текущей версии UML - и UML 2.2 заготовки и шаблоны для MS Visio ml ml Учебник(на русском языке) Моделирование на UML. Ф.Новиков, Д.Иванов ( ) 23

24 UML 2.2 Symbols для Visio

25 Структура стандарта UML Весь текст описания UML каждой версии находится в свободно распространяемых документах, доступных по адресу Ниже перечислены основные документы, входящие в комплект документации для версии UML (август 2011) Документ и его содержание Количество страниц UML Infrastructure Описание базовых механизмов, а также архитектуры, профилей, стереотипов 230 UML Superstructure Описание статических и динамических элементов языка 748 UML Diagram interchange Описание формата обмена дополнительными данными о диаграммах (форматирование, расположение элементов и т.д.) между различными инструментами 86 OCL Specifications Описание объектного языка ограничений OCL (Object Constraint Language)

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

27 Требования к UML Позволяет моделировать как программное обеспечение сложных систем, так и широкие классы самих систем и бизнес-приложений, с использованием объектно-ориентированных понятий и методов Обеспечивает взаимосвязь между базовыми понятиями моделей концептуального, программного и физического уровней Понятен системным аналитикам и программистам Поддерживается специальными инструментальными программными средствами, реализованными на различных компьютерных платформах

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

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

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

31 Назначение UML Без UML программист Объект автоматизации Исходный код программы Исполнимый код Воображаемая модель компьютерной программы

32 Назначение UML С UML программист Объект автоматизации Исходный код программы Исполнимый код Воображаемая модель компьютерной программы Теория графов и теория множеств UML диаграммы и спецификации

33 Назначение UML* Сами авторы UML определяют свое детище следующим образом. Язык UML это графический язык моделирования общего назначения, предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых при разработке программных систем. 33 * - по книге Моделирование на UML Графическое представление модели UML не тождественно самой модели. Это важное обстоятельство часто упускается из виду при первом знакомстве с UML.

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

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

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

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

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

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

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

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

42 Структура UML

43 Общая структура UML 43 ОСНОВЫ УНИФИЦИРОВАННОГО ЯЗЫКА МОДЕЛИРОВАНИЯ K_DO/frame/UMK_DO/M6/L11.htm#11_1 Синтаксис (syntax) - определение правил составления конструкций языка. Семантика (semantics) - определение правил приписывания смысла конструкциям языка.

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

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

46 1. Классов 2. Объектов 3. Прецендентов 4. Последовательностей 5. Коопераций 6. Состояний 7. Действий 8. Компонентов 9. Развертывания 1. Классы 2. Интерфейсы 3. Кооперации 4. Преценденты 5. Активные классы 6. Компоненты 7. Узлы Структурные 1. Взаимодействия 2. Автоматы Поведенческие 1. Пакет Группирующие 1. Примечания Аннотационные 1. Структурные 2. Поведенческие 3. Группирующие 4. Аннотационные 1. Включения 2. Ассоциаций 3. Обобщений 4. Расширения Сущности Отношения Диаграммы Структура UML (три разновидности строительных блоков) Сущности являются основными объектно- ориентированными элементами языка. С их помощью можно создавать корректные модели. Структурные сущности - это имена существительные в моделях на языке UML. Как правило, они представляют собой статические части модели, соответствующие концептуальным или физическим элементам системы

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

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

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

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

51 Класс (class) Класс (class) - это описание совокупности объектов с общими атрибутами, операциями отношениями и семантикой Множество объектов, имеющих общую структуру и поведение Класс человек Класс круг Класс реализует один или несколько интерфейсов.

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

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

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

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

56 Прецедент (use case) Use Case (Прецедент/Вариант использования) - это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера (actor). Обработка заказа

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

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

59 Узел (node) Узел (node) - это элемент реальной (физической) системы, который существует во время функционирования программного продукта и представляет собой некоторый вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти, а часто еще и возможностью обработки. Физическая часть системы (компьютер, принтер и т. д.), предоставляющая ресурсы для решения задачи

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

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

62 Пакет(packages) Это ящики, по которым может быть разложена модель. Предусмотрена одна разновидность группирующего предмета пакет. Пакет общий механизм для распределения элементов по группам. В пакет помещаются структурные предметы, предметы поведения и другие группировки предметов. В отличие от компонента, существующего в период выполнения, пакет концептуальное понятие. Т.о. пакет существует только в период разработки. 62 UML позволяет сгруппировать в пакеты: UseCase; Class; Components.

63 Способы изображения пакетов 63

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

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

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

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

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

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

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

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

72 Отношения Связывают сущности

73 Основные: Виды отношений UML, используемых на диаграммах для указания связей м-ду сущностями 73 Зависимость (dependency) Ассоциация (association) Обобщение (generalization) Реализация (realization) Агрегация (aggregation) – подвид ассоциации Композиция (composition) – подвид агрегации

74 Отношения Наименование ОбозначениеОпределение (семантика) Ассоциация (association) Отношение, описывающее значимую связь между двумя и более сущностями. Наиболее общий вид отношения Агрегация (aggregation) (подвид ассоциации) Подвид ассоциации, описывающей связь «часть»–«целое», в котором «часть» может существовать отдельно от «целого». Ромб указывается со стороны «целого». Отношение указывается только между сущностями одного типа Композиция (composition) (подвид агрегации) Подвид агрегации, в которой «части» не могут существовать отдельно от «целого». Как правило, «части» создаются и уничтожаются одновременно с «целым» 74 /UMK_DO/frame/UMK_DO/M6/L11.htm#11_1

75 Наименование ОбозначениеОпределение (семантика) Зависимость (dependency) Отношение между двумя сущностями, в котором изменение в одной сущности (независимой) может влиять на состояние или поведение другой сущности (зависимой). Со стороны стрелки указывается независимая сущность Обобщение (generalization) Отношение между обобщенной сущностью (предком, родителем) и специализированной сущностью (потомком, дочкой). Треугольник указывается со стороны родителя. Отношение указывается только между сущностями одного типа Реализация (realization) Отношение между сущностями, где одна сущность определяет действие, которое другая сущность обязуется выполнить. Отношения используются в основном в двух случаях: между интерфейсами и классами (или компонентами), между вариантами использования и кооперациями. Со стороны стрелки указывается сущность, определяющая действие (интерфейс или вариант использования) 75

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

77 Отношения: 77

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

79 В данном случае: Отношение зависимости говорит о том, что внесение изменений в исходные тексты программ или динамические библиотеки приводит к изменениям самого компонента(main.exe). Характер изменений может быть отмечен дополнительно. Зависимость(кратность всегда 1) - указывает на то, что изменение независимой сущности каким-то образом влияет на зависимую сущность. 79 Отношения зависимости на диаграмме компонентов Со стороны стрелки – независимая сущность С обратной стороны – зависимая сущность

80 Зависимость 80 На диаграмме показаны отношения зависимости между узлом и развернутыми на нем компонентами Отношения зависимости на диаграмме развертывания независимые сущности (компоненты) зависимая сущность Кратность (multiplicity) для отношения зависимость всегда =1

81 Реализация(кратность всегда 1) 81 Отношения реализации и зависимости на диаграмме пакетов Отношение реализации на данной диаграмме говорит о том, что пакет с именем Database Gateway" реализуется тремя пакетами. зависимая сущность (пакет) Отношение реализации независимая сущность (пакет) Отношение зависимости

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

83 Ассоциация - описывает значимую связь между двумя и более сущностями. 83 Отношения ассоциации на диаграмме вариантов ипользования (или диаграмме прецендентов) Отношение ассоциации

84 Ассоциация может объединять три и более класса. В этом случае она называется n-арной и изображается ромбом на пересечении линий 84 Отношения ассоциации Отношения ассоциации на диаграмме классов

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

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

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

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

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

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

91 Механизмы расширения Не во всех учебниках механизмы расширения рассматриваются как отдельный элемент. И действительно, механизм расширения - используется лишь для уточнения семантики сущностей и отношений – это всего лишь подписи

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

93 Механизмы расширения 93 Наименование ОбозначениеОпределение (семантика) Стереотип (stereotype) « » Обозначение, уточняющее семантику элемента нотации (например: зависимость со стереотипом «include» рассматривается, как отношение включения, а класс со стереотипом «boundary» – граничный класс) Сторожевое условие (guard condition) [ ] Логическое условие (например: [A > B] или [идентификация выполнена]) Ограничение (constraint) { } Правило, ограничивающее семантику элемента модели (например, {время выполнения менее 10 мс}) Помеченное значение (tagged value) { } Новое или уточняющее свойство элемента нотации (например: {version = 3.2}) OD/UMK_DO/frame/UMK_DO/M6/L11.htm#11_1

94 Пример: стандартные стереотипы классов Стереотип Описание «actor»Действующее лицо «auxiliary»Вспомогательный класс «enumeration»Перечислимый тип данных «exception»Исключение (только в UML 1) «focus»Основной класс «implementationClass»Реализация класса «interface»Все составляющие абстрактные «metaclass»Экземпляры являются классами «powertype» Метакласс, экземплярами которого являются все наследники данного класса (только в UML 1) «process»Активный класс «thread»Активный класс (только в UML 1) «signal»Класс, экземплярами которого являются сигналы «stereotype»Новый элемент на основе существующего «type»Тип данных «dataType»Тип данных «utility»Нет экземпляров, служба 94

95 Примеры предопределенных стереотипов отношений 95 СтереотипК чему применим Назначение extend Зависимость (dependency) Целевой вариант использования расширяет поведение исходного в данной точке расширения include Зависимость (dependency) Исходный прецедент явно включает поведение другого прецедента в точке, определяемой исходным derive Зависимость (dependency) Исходный объект может быть вычислен по целевому implementation Обобщение (generalization) Потомок наследует реализацию родителя, но не открывает и не поддерживает его интерфейсов, вследствие чего не может быть подставлен вместо родителя call Зависимость (dependency) Исходная операция вызывает целевую

96 Пример использования предопределенных стереотипов 96 СтереотипК чему применим Назначение extend (расширяет) Зависимость (dependency) Целевой вариант использования расширяет поведение исходного в данной точке расширения Какого типа диаграмма? Стереотип extend в данном случае говорит, что прецедент ПРОВЕДЕНИЕ АНАЛИЗОВ расширяет прецедент ОФОРМЛЕНИЕ ПРИЕМА ПАЦИЕНТА ЗС НЗС

97 Пример использования предопределенных стереотипов 97 СтереотипК чему применим Назначение include (включает) Зависимость (dependency) Исходный прецедент явно включает поведение другого прецедента в точке, определяемой исходным Стереотип include в данном случае говорит, что прецедент ОПОВЕЩЕНИЕ РОДСТВЕННИКОВ включает прецедент СОГЛАСИЕ НА ТРАНСПЛАНТАЦИЮ ОРГАНОВ ЗС НЗС

98 Пример использования предопределенных стереотипов 98 СтереотипК чему применим Назначение derive (извлекать) Зависимость (dependency) Исходный объект может быть вычислен по целевому Скидка Клиент Имя Фамилия Кол-во заказов …… Срок действия Размер(%) …… derive Стереотип derive в данном случае говорит, что свойства класса СКИДКА вычисляются исходя из свойств класса КЛИЕНТ (н-р, кол-во заказов)

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

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

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

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

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

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

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

106 Примеры диаграмм (повторение)

107 Диаграмма, описывающая предметную область сказки о Курочке Рябе (взята с сайта конкурса шуток на UML ( 107 диаграмма объектов Стереотип enumeration - определяет перечислимый тип, включая его возможные значения как набор идентификаторов Какие сущности и отношения показаны на диаграмме?

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

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

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

111 Диаграмма использования /1007/229/lecture/5954?page=1 Какие сущности и отношения показаны на диаграмме?

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

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

114 Диаграмма использования: Прием пациента в больницу html?page=11 Какие сущности и отношения показаны на диаграмме?

115 UML диаграммы

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

117 9 канонических типов диаграмм (UML1) Диаграмма использования (Use Case diagram) + Диаграмма классов (Class diagram) + Диаграмма объектов (Object diagram) + Диаграмма состояний (State chart diagram) + Диаграмма деятельности (Activity diagram) + Диаграмма последовательности (Sequence diagram) + Диаграмма кооперации (Collaboration diagram) Диаграмма компонентов (Component diagram) + Диаграмма размещения (Deployment diagram) + 117

118 Иерархия типов диаграмм для UML 1 условная классификация диаграмм В UML 1 всего определено 9 канонических типов диаграмм. Их названия, принятые в этой книге (в других источниках есть отличия). Диаграмма использования (Use Case diagram) Диаграмма классов (Class diagram) Диаграмма объектов (Object diagram) Диаграмма состояний (State chart diagram) Диаграмма деятельности (Activity diagram) Диаграмма последовательности (Sequence diagram) Диаграмма кооперации (Collaboration diagram) Диаграмма компонентов (Component diagram) Диаграмма размещения (Deployment diagram) Какие отношения показаны на диаграмме?

119 Используемые стереотипы: Refine – стереотип говорит, что исходный объект является более детальной абстракцией, чем целевой Derive – исходный объект может быть вычислен по целевому InstanceOf – исходный объект является экземпляром целевого классификатора 119

120 Краткая характеристика общих диаграмм UML Диаграмма Тип диаграммы (модели ИС) по степени физической реализации по отображению динамики по отображаемому аспекту Вариантов использования (use case) Логическая СтатическаяФункциональная Классов (class) Логическая или физическая Статическая Функционально- информационная Поведения (behavior) Состояний (statechart) Логическая ДинамическаяПоведенческая Деятельности (activity) Взаимодействия (interaction) Последова- тельности (sequence) Кооперации (collaboration) Реализации (implementation) Компонентов (component) Физическая Статическая Компонентная (структурная) Развертывания/размещения (deployment) иаграммы

121 Названия диаграмм в UML Классификация диаграмм в зависимости от того, на какой вопрос они отвечают: Что делает система? Диаграмма использования / Use case diagram + Из чего состоит система? Диаграмма классов / Class diagram + Диаграмма компонентов / Component diagram + Диаграмма размещения (развертывания) / Deployment diagram + Диаграмма объектов / Object diagram + Диаграмма внутренней структуры / Composite structure diagram Как работает система? Диаграмма деятельности / Activity diagram + Диаграмма коммуникации / Communication diagram + Диаграмма последовательности / Sequence diagram + Диаграмма автомата / State machine diagram + Обзорная диаграмма взаимодействия / Interaction overview diagram Диаграмма синхронизации / Timing diagram Как управлять сложностью самой модели? Диаграмма пакетов / Package diagram + Новые Поменяли наименование

122 Иерархия типов диаграмм для UML 2 Также См. на странице: 122

123 Шаблон представления диаграммы Возможные теги (типы) для некоторых диаграмм: Диаграмма использования - Use case Диаграмма классов - Class Диаграмма компонентов - Component Диаграмма размещения - Deployment Диаграмма объектов – Object ………………. 123 Ярлычок с названием диаграммы Рамка диаграммы

124 Примеры диаграмм 124 Обзорная диаграмма взаимодействия (Interaction overview diagram) 1 – ссылки на взаимодействия Диаграмма синхронизации (Timing diagram) 1 – состояния 2 – их временная синхронизация Сторожевое условие Начальное состояние Конечное состояние

125 Еще одна классификация диаграмм: Общие не зависят от предмета моделирования и могут применяться в любом программном проекте без оглядки на предметную область, область решений и т.д. Это диаграммы: - Использования - Классов - Деятельности - Автоматов - Последовательности - Коммуникации - Компонентов - Размещения Специальные диаграммы характеризуются тем, что чаще всего служат для дополнения какой-либо общей диаграммы, например, являются ее частным случаем или же просто играют вспомогательную роль, уточняя некоторые детали. Это диаграммы: - Объектов - Внутренней структуры - Обзорная диаграмма взаимодействия - Синхронизации - Пакетов 125

126 Интегрированная модель системы Диаграмма вариантов использования Диаграмма классов Диаграмма состояний Диаграмма компонентов Диаграмма последователь- ности Диаграмма развертывания Диаграмма кооперации Диаграмма деятельности UML НИКАК НЕ РЕГЛАМЕНТИРУЕТ ПОРЯДОК И СОСТАВ РАЗРАБОТКИ ДИАГРАММ. НАПИСАТЬ

127 UML НИКАК НЕ РЕГЛАМЕНТИРУЕТ ПОРЯДОК И СОСТАВ РАЗРАБОТКИ ДИАГРАММ. Порядок и состав разработки диаграмм определяет: 1. выбранная методология (RUP, MSF, OrCDM…); 2. специфика конкретного проекта. Отношения диаграмм ООАП ориентирован на итеративную разработку UML диаграмм. ВОПРОС: Какие модели ЖЦ ориентированы на итеративную разработку??? ВОПРОС: В каком порядке рисовать диаграммы??? Все ли виды диаграмм рисовать???

128 Отношения диаграмм потребности пользователей программная реализация выявлениеанализдизайнкодирование Sequence diagram Component diagram Statechart diagram Class diagram Deployment diagram Use Case Use Case diagram Colloboration diagram Кооперации Последовательности Размещения Состояний

129 Диаграммы использования (Use case diagram) Были предложены Иваром Якобсоном в их нынешней графической форме еще в 1986 году. Являются, безусловно, самым стабильным элементом UML они не менялись уже двадцать лет с лишним, фактически, приняли законченную форму задолго до появления языка.

130 Диаграммы использования (Use case diagram) 130 Отвечает на вопрос: Что делает система? Диаграмма Тип диаграммы (модели ИС) по степени физической реализации по отображению динамики по отображаемому аспекту Вариантов использования (use case) Логическая СтатическаяФункциональная Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. «Каждая функциональность» изображается в виде «прецедентов использования» (use case) или просто прецедентов: Делать заказ

131 Цели разработки диаграммы: 131 Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы. Сформулировать общие требования к функциональному поведению проектируемой системы. Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей. Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями. Источник: Самоучитель UML Александр Леоненков

132 Основной набор символов диаграммы использования ( Термин Изображение Описание Сценарий Вся диаграмма вариантов использования Сценарий (scenario) – это последовательность шагов, описывающих взаимодействие пользователя и системы. Актер Актер (actor) представляет собой некую роль, которую пользователь играет по отношению к системе. Прецедент Обозначает выполняемые системой действия (могут включать возможные варианты), приводящие к наблюдаемым актёрами результатам. include (включает) Сложный шаг в прецеденте можно представить другим прецедентом. В терминах языка UML мы говорим, что первый прецедент включает (includes) второй. Граница системы Позволяет обозначить границы систем или подсистем. 132

133 Также на диаграмме вариантов использования может использоваться интерфейс interface - для спецификации параметров модели, которые видимы извне без указания их внутренней структуры. На диаграмме Use case, интерфейсы определяют совокупность операций, которые обеспечивают необходимый набор сервисов или функциональности для актеров. Интерфейсы не могут содержать ни атрибутов, ни состояний, ни направленных ассоциаций. Они содержат только операции без указания особенностей их реализации. Формально интерфейс эквивалентен абстрактному классу без атрибутов и методов с наличием только абстрактных операций. 133 Графическое изображение интерфейсов на диаграммах вариантов использования

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

135 Диаграммы использования имеют самую простую нотацию: 2 основных типа сущностей: - действующие лица - варианты использования (прецеденты) 3 типа отношений: - зависимости - ассоциации - обобщения 135 Делать заказ Прецедент типичное взаимодействие пользователя с системой, которое: описывает видимую пользователем функцию, может представлять различные уровни детализации, обеспечивает достижение конкретной цели, важной для пользователя. Список всех прецедентов фактически определяет функциональные требования к ИС, которые лежат в основе разработки технического задания на создание системы.

136 Действующее лицо или актер(actor) - любая сущность, взаимодействующая с системой извне. Это может быть: - человек, - техническое устройство, - программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. 136 Продавец АСР (автоматизированная система расчетов) Служба технического обслуживания Бухгалтерская система

137 Отношения: ассоциация 137 Стереотип типа «расширение»(«extend») применяется, когда один прецедент подобен другому, но несет несколько большую функциональную нагрузку. Ее следует применять при описании изменений в нормальном поведении системы. Стереотип типа «использование» («include» - включение) позволяет выделить некий фрагмент поведения системы и включать его в различные прецеденты без повторного описания. При исполнении прецедентов «оценить риск сделки» и «согласовать цену» необходимо выполнить одно и то же действие рассчитать стоимость заказа. При исполнении прецедента «сформировать заказ» возможно использование информации из предыдущего заказа, что позволит не вводить все необходимые данные. Зависимость

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

139 Пример 1 139

140 Комментарии к диаграмме Как видно из разработанной диаграммы система рассчитана на три вида пользователей («актёров») с разными уровнями доступа: преподаватель, студент, модератор. Студент обладает правами просмотра, поиска и скачивания данных с сервера. Модератор назначается из числа студентов (обладает всеми их правами по принципу наследования) и получает возможность добавления, удаления книг, а также редактирования информации о них в разделе художественной литературы. Этот уровень доступа также позволяет делать запрос по всем данным художественной литературы. Преподаватель обладает всеми правами модератора и пользователя (используется вышеуказанный принцип наследования). Он обладает возможностью редактировать раздел специальной литературы: удалять, добавлять книги и при необходимости вносить изменения в сами учебные пособия. Ему доступна возможность запроса данных по специальной литературе. Следует отметить, что, по сути, все преподаватели являются администраторами системы. Разработка этой диаграммы решила следующие задачи: - определены общие границы и контекст моделируемой предметной области; - сформулированы общие требования к функциональному поведению проектируемой системы; - разработана исходная концептуальная модель системы для ее последующей детализации в форме логических и физических моделей; - подготовлена исходная документация для взаимодействия разработчиков системы с ее заказчиками и пользователями. `: 140

141 html?page=11 Пример 2 Диаграмма использования: Прием пациента в больницу.

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

143 Порядок создания диаграммы вариантов использования Определить актеров Определить прецеденты Определить отношения м-ду сущностями Определить интерфейсы если они есть 143

144 Почитать: Диаграммы вариантов использования s.html 144

145 Задания ИС для сотрудников детского сада и родителей 2. ИС для сотрудников зоопарка, предназначена для хранения информации о животных 3. ИС для туристического агентства. Предназначена для хранения информации о турах.

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

147 Диаграмма классов Отвечает на вопрос:Из чего состоит система? Это основной способ описания статической структуры системы. Обычно создаются после окончания процесса анализа и знаменуют начало процесса проектирования. Наиболее информационно насыщены по сравнению с другими типами канонических диаграмм UML, инструменты генерируют код в основном по описанию классов, структура классов точнее всего соответствует окончательной структуре кода приложения. 147 Диаграмма Тип диаграммы (модели ИС) по степени физической реализации по отображению динамики по отображаемому аспекту Классов (class) Логическая или физическая Статическая Функционально- информационная

148 Элементы диаграмм классов Основной тип сущностей: классы (включая многочисленные частные случаи классов: интерфейсы, примитивные типы, классы- ассоциации и т.д.), Между классами устанавливаются следующие основные типы отношений: - зависимости, - ассоциации, - обобщения, - реализации. 148 Кроме того, на диаграмме классов могут использоваться (как и везде) пакеты и комментарии.

149 Класс 149 Список описаний атрибутов класса В общем случае имеет следующий синтаксис: видимость ИМЯ кратность : тип = начальное_значение {свойства} Имя класса В общем случае имеет следующий синтаксис: «стереотип» ИМЯ {свойства} кратность Список описаний операции класса В общем случае имеет следующий синтаксис: видимость ИМЯ (параметры) : тип {свойства} параметры обозначает последовательность описаний параметров операции, каждое из которых имеет следующий формат: направление ПАРАМЕТР : тип = значение Имя класса Атрибуты класса Операции класса

150 Поле – имя класса Обязательное поле в нем как минимум содержится имя(максимум два слова) Имя класса может быть выделено курсивом и в этом случае данный класс является абстрактным, т.е. не имеющим непосредственных экземпляров. Перед именем может быть стереотип – значения предопределенных стереотипов для классов см. выше Кратность класса - ограничение на количество экземпляров класса, как множества. Задается обычно таким образом: 150 Если имя подчеркнуто, то это уже не имя класса, а имя объекта. Нижняя граница.. Верхняя граница

151 Основные стереотипы классов Boundary (граница); Entity (сущность); Control (управление). Граничными классами (boundary classes) называются такие классы, которые расположены на границе системы и всей окружающей среды. Это экранные формы, отчеты, интерфейсы с аппаратурой (такой как принтеры или сканеры) и интерфейсы с другими системами. Чтобы найти граничные классы, надо исследовать диаграммы вариантов использования. Каждому взаимодействию между действующим лицом и вариантом использования должен соответствовать, по крайней мере, один граничный класс. Именно такой класс позволяет действующему лицу взаимодействовать с системой. 151

152 Классы-сущности (entity classes) содержат хранимую информацию. Они имеют наибольшее значение для пользователя, и потому в их названиях часто используют термины из предметной области. Обычно для каждого класса-сущности создают таблицу в базе данных. Управляющие классы (control classes) отвечают за координацию действий других классов. Обычно у каждого варианта использован ия имеется один управляющий класс, контролирующий последовательность событий этого варианта использования. Управляющий класс отвечает за координацию, но сам не несет в себе никакой функциональности, так как остальные классы не посылают ему большого количества сообщений. Вместо этого он сам посылает множество сообщений. Управляющий класс просто делегирует ответственность другим классам, по этой причине его часто называют классом-менеджером. 152

153 Графические стереотипы класса 153

154 Атрибут (attribute) 154 Видимость имеет С++ семантику видимости членов класса: Символ области видимости может изображаться ключевым или может быть опущен. Основные: видимость ИМЯ кратность : тип = начальное_значение {свойства} Видимость (visibility) определяет, может ли составляющая одного классификатора (в том числе имя) использоваться в другом классификаторе. Символ Ключевое слово Название Что означает +publicоткрытыйлюбая сущность, имеющая доступ к объекту определяемого класса, имеет доступ и к этому атрибуту. #protectedзащищенныйозначает, что к атрибуту имеют доступ только методы данного класса и его потомков -privateзакрытыйозначает, что атрибут доступен только методам класса. Для видимости в UML нет значения по умолчанию. Н-р, если для атрибута не указано значение видимости, то это не значит, что атрибут по умолчанию открытый(или закрытый). Это означает, что видимость для данного атрибута в модели не указана и в этом аспекте модель не полна.

155 Атрибут (attribute) Имя - идентификатор, представляющий имя атрибута. Кратность - если она не обозначена, то предполагается, что атрибут может хранить ровно одно значение. Кратность задается т.о.: coords[3]: integer Тип - зависящее от языка реализации описание типа атрибута. Начальное_значение - зависящее от языка реализации выражение, задающее начальное значение для атрибута вновь созданного объекта (необязательная часть). Свойства - строка дополнительных свойств элемента (необязательная часть). Если свойства не указываются, скобки {} опускаются. Н-р, имя автора: {Author = Smith} По умолчанию атрибут является изменяемым. Если в свойствах пометка {frozen}, то атрибут объявлен неизменяемым. 155 видимость ИМЯ кратность : тип = начальное_значение {свойства}

156 Примеры описаний атрибутов Пример Пояснение name Минимальное возможное описание указано только имя атрибута +name Указаны имя и открытая видимость предполагается, что манипуляции с именем будут производиться непосредственно -name : String Указаны имя, тип и закрытая видимость манипуляции с именем будут производиться с помощью специальных операций -name[1..3] : String В дополнение к предыдущему указана кратность (для хранения трех составляющих; фамилии, имени и отчества) -name : String="Novikov"Дополнительно указано начальное значение +name : String{frozen} Атрибут объявлен не меняющим своего значения после начального присваивания и открытым 156

157 Операция (operation) - это сущность, определяющая некое действие, которое может быть выполнено представителем класса. Видимость, имя и свойства имеют тот же смысл, что и для атрибута. Параметры - список формальных параметров, разделенных запятыми: Направление* в посл. версии UML предусмотрена возможность указания вида параметра (вх., вых. или смешанного типа). Параметр - имя параметра. Тип - зависящее от языка реализации описание типа параметра. Значение - значение параметра по умолчанию. 157 видимость ИМЯ (параметры) : тип {свойства} направление ПАРАМЕТР : тип = значение * - направление передачи параметра в UML описывает семантическое назначение параметров, не конкретизируя конкретный механизм передачи. Как именно следует трактовать указанные в модели направления передачи параметров, зависит от используемой системы программирования.

158 Ключевые слова для описания направления передачи параметров Ключевое слово Назначение параметра In Входной параметр – аргумент должен быть значением, которое используется в операции, но не изменяется Out Выходной параметр – аргумент должен быть хранилищем, в которое операция помещает значение Inout Входной и выходной параметр – аргумент должен быть хранилищем, содержащим значение. Операция использует переданное значение аргумента и помещает в хранилище результат Return Значение, возвращаемое операцией. Никакого аргумента не требуется 158

159 Примеры описания операций Пример Пояснение move() Минимальное возможное описание указано только имя операции +move(in from, in to) Указаны видимость операции, направления передачи и имена параметров +move(in from:Department, in to:Department) Подробное описание сигнатуры*: указаны видимость операции, направления передачи, имена и типы параметров +getName():String{isQuery} Функция, возвращающая значение атрибута и не имеющая побочных эффектов 159 * - все вместе (имя операции, параметры и тип результата) обычно называют сигнатурой (signature) операции.

160 Отношения на диаграмме класса 160 Зависимость (dependency) Ассоциация (association) Обобщение (generalization) Реализация (realization) Агрегация (aggregation) – подвид ассоциации Композиция (composition) – подвид агрегации

161 Отношение зависимости на диаграммах классов используются сравнительно редко, потому что имеют более расплывчатую семантику по сравнению с ассоциациями и обобщением. Некоторые стереотипы для зависимости: "access" - служит для обозначения доступности открытых атрибутов и операций класса-источника для классов-клиентов; "bind" - класс-клиент может использовать некоторый шаблон для своей последующей параметризации; "derive" - атрибуты класса-клиента могут быть вычислены по атрибутам класса- источника; "import" - открытые атрибуты и операции класса-источника становятся частью класса-клиента, как если бы они были объявлены непосредственно в нем; "refine" - указывает, что класс-клиент служит уточнением класса-источника в силу причин исторического характера, когда появляется дополнительная информация в ходе работы над проектом. 161 ЗК НК ЗК – зависимый класс, НК – независимый класс

162 Предопределенные (стандартные) стереотипы отношения зависимости Всего в UML определено 17 стандартных стереотипов отношения зависимости, которые можно разделить на 6 групп: между классами и объектами на диаграмме классов (примеры приведены на предыд. слайде); между пакетами; между вариантами использования; между объектами на диаграмме взаимодействия; между состояниями автомата; между подсистемами и моделями. 162

163 Отношение зависимости Зависимость возникает тогда, когда реализация класса одного объекта зависит от спецификации операций класса другого объекта. И если изменится спецификация операций этого класса, нам неминуемо придется вносить изменения и в зависимый класс. Например: 163 Операция "Воспроизведение", реализуемая программой- медиаплеером, зависит от операции "Декомпрессия", реализуемой кодеком.

164 Отношение ассоциации Отношение ассоциации является наиболее используемым на диаграмме классов. В общем случае ассоциация, соединяющая классы, означает, что экземпляры одного класса связаны с экземплярами другого класса. 164 БИНАРНАЯ АССОЦИАЦИЯ Ассоциация выражает отношение между несколькими равноправными объектами и может иметь направление, роли и кратность, а также изображаться в виде класса ассоциации.

165 Тернарная ассоциация 165 Исключающая ассоциация между тремя классами

166 Композиция и агрегация - используются, если между объектами существуют отношения типа "часть-целое", причем композиция предполагает, что части не могут существовать отдельно от целого. 166 Агрегация на диаграмме классов

167 В отношении между двумя классами сама ассоциация тоже может иметь свойства и, следовательно, тоже может быть представлена в виде класса. 167

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

169 Ограничения используемые для обобщения {complete}(полнота) – означает, что в данном отношении обобщения специфицированы все классы-потомки, и других классов-потомков у данного класса-предка быть не может. Пример – класс Клиент_банка является предком для двух классов: Физическое_лицо и Компания, и других классов-потомков он не имеет {disjoint}(несовместность) – означает, что классы-потомки не могут содержать объектов, одновременно являющихся экземплярами двух или более классов. В приведенном выше примере это условие также выполняется, поскольку предполагается, что никакое конкретное физическое лицо не может являться одновременно и конкретной компанией {incomplete}(неполнота) – означает случай, противоположный первому. А именно, предполагается, что на диаграмме указаны не все классы-потомки {overlapping}(совместность) – означает, что отдельные экземпляры классов- потомков могут принадлежать одновременно нескольким классам. Пример – класс «Многоугольник» является классом-предком для класса «Прямоугольник» и класса «Ромб». Однако существует отдельный класс «Квадрат», экземпляры которого одновременно являются объектами первых двух классов. 169

170 Графическое изображение отношения обобщения классов с использованием строки-ограничения 170

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

172 Интерфейсы Интерфейсы являются элементами диаграммы вариантов использования. Однако при построении диаграммы классов отдельные интерфейсы могут уточняться и в этом случае для их изображения используется специальный графический символ – прямоугольник класса с ключевым словом или стереотипом "interface". Cекция атрибутов отсутствует, а указывается только секция операций. 172

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

174 Пример моделирования отношений между классами, позаимствованный из Zicom Mentor 174

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

176 Наиболее распространенные подходы к группировке Группировка по стереотипу: Группировка по их функциональности: Н-р, в пакете Security содержатся все классы, отвечающие за безопасность приложения. 176

177 Пример диаграммы классов Кадровый учет 177 Данный тип ограничения появился в UML 2. Он позволяет манипулировать множествами объектов на полюсах. Ограничение {subsets x} полюса ассоциации (composition) это указание на то, что множество объектов, соответствующих данному полюсу, является подмножеством множества объектов полюса x

178 Применение диаграмм классов Для моделирования данных. Анализ предметной области позволяет выявить основные характерные для нее сущности и связи между ними. Это удобно моделируется с помощью диаграмм классов. Эти диаграммы являются основой для построения концептуальной схемы базы данных. Для представления архитектуры программных систем(ПС). Можно выделить архитектурно значимые классы и показать их на диаграммах, описывающих архитектуру ПС. Для моделирования навигации экранов. На таких диаграммах показываются граничные классы и их логическая взаимосвязь. Информационные поля моделируются как атрибуты классов, а управляющие кнопки – как операции и отношения. Для моделирования логики программных компонент. Для моделирования логики обработки данных. 178

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

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

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