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

Июль 26, 2022

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

Содержание

2. Содержание Предпосылки появления ООП к созданию ИС Язык UML История появления Структура стандарта UML Назначение UML
3. В основе ООП лежит объектная декомпозиция, при этом: статическая структура системы описывается в терминах объектов и
4. Предпосылки появления объектно-ориентированного подхода к созданию ИС
5. Проблемы, стимулировавшие развитие ООП: • необходимость повышения производительности и разработки за счет многократного (повторного) использования ПО
6. Понятие объект-ориентированного программирования Термин "объектно-ориентированное программирование" принят преимущественно в российской литературе: Объектно-ориентированное программирование (ООП, Object-Oriented Programming)
7. ООР (object-oriented programming) – это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый
8. Наиболее существенным обстоятельством в развитии методологии ООП явилось осознание того, что процесс написания программного кода может
9. Язык UML История UML Назначение UML
10. Унифицированный язык моделирования (Unified Modelling Language, UML) является графическим языком для визуального представления, составления спецификаций, проектирования
11. История появления и развития UML консорциум OMG (Object Management Group) - консорциум (рабочая группа), занимающаяся разработкой
12. Начиная работу по унификации своих методов, Г. Буч, Дж. Румбах и А. Джекобсон сформулировали следующие требования
13. Унифицированный язык моделирования (UML) в настоящий момент является стандартом де-факто при описании (документирования) результатов проектирования и
14. Интернет-ресурсы по UML Спецификации текущей версии UML - http://www.omg.org/Спецификации текущей версии UML - http://www.omg.org/ и http://www.uml.org/
15. Структура стандарта UML Весь текст описания UML каждой версии находится в свободно распространяемых документах, доступных по
16. Выводы UML является мощным, гибким средством моделирования, описание стандарта которого является открытым для последующего совершенствования. Неоднозначность
17. Требования к UML Позволяет моделировать как программное обеспечение сложных систем, так и широкие классы самих систем
18. Термин “унифицированный” в названии UML имеет 2 аспекта: С одной стороны, он фактически устраняет многие из
19. Типичный процесс создания продукта, или "решения"
20. Проблемы программной инженерии Рисунок на предыдущем слайде иллюстрирует проблемы программной инженерии. В частности - проблемы с
21. http://pvti.ru/lect1-lecture3.htm Cитуация, существовавшая в области технологий программирования до UML. Основной недостаток: объединение текста программы (ее исходного
22. Наличие теоретической основы позволяет упростить операции преобразования UML диаграмм, нарисованных на экранах дисплеев, в память компьютеров
23. Назначение UML* Сами авторы UML определяют свое детище следующим образом. “Язык UML ‒ это графический язык
24. Спецификация Основное назначение UML ‒ предоставить, с одной стороны, достаточно формальное, с другой стороны, достаточно удобное,
25. Визуализация Особенности человеческого восприятия таковы, что текст с картинками воспринимается легче, чем голый текст. А картинки
26. Проектирование В оригинале данное назначение UML определено с помощью слова construct, которое мы передаем осторожным термином
27. Документирование Модели UML являются артефактами, которые можно хранить и использовать как в форме электронных документов, так
28. 3 основных варианта использования UML (показаны на диаграмме использования UML) http://book.uml3.ru/sec_1_2
29. Пояснения к рисунку (фрагмент учебника) Вариант использования drawing ("Рисование диаграмм") подразумевает изображение диаграмм UML с целью
30. Пояснения к рисунку (фрагмент учебника) Вариант использования development ("Разработка приложений") подразумевает детальное моделирование, реализацию и тестирование
31. Модель с позиций ООАП С точки зрения методологии ООАП достаточно полная модель сложной системы представляет собой
32. Критика UML (фрагмент статьи) Несмотря на то, что UML достаточно широко распространённый и используемый стандарт, его
33. Критика UML Проблемы при изучении и внедрении. Вышеописанные проблемы делают проблематичным изучение и внедрение UML, особенно
34. Критика UML Кумулятивная нагрузка/Рассогласование нагрузки (Cumulative Impedance/Impedance mismatch). Рассогласование нагрузки — термин из теории системного анализа
35. Структура UML
36. Общая структура UML ОСНОВЫ УНИФИЦИРОВАННОГО ЯЗЫКА МОДЕЛИРОВАНИЯ http://edu.dvgups.ru/METDOC/GDTRAN/YAT/ITIS/PROEK_INF_SIS/METOD/UMK_DO/frame/UMK_DO/M6/L11.htm#11_1 Синтаксис (syntax) - определение правил составления конструкций языка.
37. Графические элементы Авторы исходили из того, что UML будет использоваться по-разному: начиная от не очень аккуратного
38. Использование цвета нотация UML довольно свободная: рисовать можно как угодно, лишь бы не возникало недоразумений. Поставщики
39. Классов Объектов Прецендентов Последовательностей Коопераций Состояний Действий Компонентов Развертывания Структурные Поведенческие Группирующие Аннотационные Включения Ассоциаций Обобщений
40. Типы сущностей(иногда называют - предметы) Структурные - существительные в UML-моделях. Это статические части модели — понятийные
41. Отношения Отношения связывают предметы. (изображаются графически в виде различных линий)
42. Диаграммы Диаграмма представляет собой группировку элементов нотации для отображения некоторого аспекта разрабатываемой информационной системы. Диаграммы представляют
43. Структурные сущности Классы Объекты Интерфейсы Актер Кооперации Преценденты Активные классы Компоненты Узлы
44. Класс (class) Класс (class) - это описание совокупности объектов с общими атрибутами, операциями отношениями и семантикой
45. Объект (object) Объект (object) ‒ сущность, обладающая уникальностью и инкапсулирующая в себе состояние и поведение. Абстракция
46. Интерфейс (interface) Интерфейс (interface) - это совокупность операций, определяющая сервис (набор услуг), предоставляемый классом или компонентом.
47. Актер (actor) — набор согласованных ролей, которые играют пользователи при взаимодействии с системой (ее элементами Use
48. Кооперация (collaboration) Кооперация (collaboration) определяет взаимодействие, она представляет собой совокупность ролей и других элементов, которые, работая
49. Прецедент (use case) Use Case (Прецедент/Вариант использования) - это описание последовательности выполняемых системой действий, которая производит
50. Активный класс (active class) Активным классом (active class) называется класс, объекты которого вовлечены в один или
51. Компонент (component) - это физическая заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его
52. Узел (node) Узел (node) - это элемент реальной (физической) системы, который существует во время функционирования программного
53. Выше перечислены только базовые элементы, которые являются основными структурными сущностями, использующиеся в модели UML. Есть и
54. Группирующие сущности организационные части UML-моделей
55. Пакет(packages) Это ящики, по которым может быть разложена модель. Предусмотрена одна разновидность группирующего предмета — пакет.
56. Способы изображения пакетов
57. Аннотационная (поясняющая) сущность разъясняющие части UML-моделей
58. Примечание(comment) Комментарий к элементу Они являются замечаниями, применяемыми для описания, объяснения и комментирования любого элемента модели.
59. Поведенческие сущности (Behavioral things) динамические составляющие UML- модели
60. Поведенческие сущности — динамические части UML-моделей — глаголы моделей, представление поведения во времени и пространстве. Описывают
61. Взаимодействие(Interaction) — поведение, заключающее в себе набор сообщений (Messages), которыми обменивается набор объектов в конкретном контексте
62. Пример использования взаимодействия Взаимодействие Использование взаимодействия на диаграмме последовательности
63. Конечные автоматы (State machine) — поведение, определяющее последовательность состояний объекта или взаимодействия, выполняемые в ходе его
64. Пример конечного автомата Состояния конечного автомата диаграмма конечного автомата
65. Отношения Связывают сущности
66. Основные: Виды отношений UML, используемых на диаграммах для указания связей м-ду сущностями Зависимость (dependency) Ассоциация (association)
67. Отношения http://edu.dvgups.ru/METDOC/GDTRAN/YAT/ITIS/PROEK_INF_SIS/METOD/UMK_DO/frame/UMK_DO/M6/L11.htm#11_1
69. Для ассоциации, агрегации и композиции может указываться кратность (multiplicity), характеризующая общее количество экземпляров сущностей, участвующих в
70. Отношения:
71. Примеры использования отношений в диаграммах
72. В данном случае: Отношение зависимости говорит о том, что внесение изменений в исходные тексты программ или
73. Зависимость На диаграмме показаны отношения зависимости между узлом и развернутыми на нем компонентами Отношения зависимости на
74. Реализация(кратность всегда 1) Отношения реализации и зависимости на диаграмме пакетов Отношение реализации на данной диаграмме говорит
75. Реализация интерфейса Отношение реализации на диаграмме классов В данном случае отношение реализации говорит о том, что
76. Ассоциация описывает значимую связь между двумя и более сущностями. Отношения ассоциации на диаграмме вариантов ипользования (или
77. Ассоциация может объединять три и более класса. В этом случае она называется n-арной и изображается ромбом
78. Ассоциация, реализация и зависимость Вопрос: Какие здесь есть структурные сущности? О чем говорят указанные отношения в
79. Обобщение(кратность всегда 1) Отношения обобщение на диаграмме классов Отношение обобщения
80. Обобщение Отношение обобщение и ассоциации на диаграмме вариантов использования Отношение обобщения Отношение ассоциации Отношение обобщения в
81. Агрегация отношение агрегации означает включение нескольких классов в другой класс Отношение агрегации говорит о том, что
82. Композиция отношение композиции показывает, что компонент состоит из нескольких частей, которые в отличие от отношения агрегации
83. Композиция и агрегация могут иметь кратность отличную от 1
84. Механизмы расширения Не во всех учебниках механизмы расширения рассматриваются как отдельный элемент. И действительно, механизм расширения
85. Механизмы расширения - применяются для уточнения семантики сущностей и отношений. В общем случае, механизм расширения представляет
86. Механизмы расширения http://edu.dvgups.ru/METDOC/GDTRAN/YAT/ITIS/PROEK_INF_SIS/METOD/UMK_DO/frame/UMK_DO/M6/L11.htm#11_1
87. Пример: стандартные стереотипы классов
88. Примеры предопределенных стереотипов отношений
89. Пример использования предопределенных стереотипов Стереотип “include” в данном случае говорит, что прецедент ОПОВЕЩЕНИЕ РОДСТВЕННИКОВ включает прецедент
90. Пример использования предопределенных стереотипов Скидка Клиент Имя Фамилия Кол-во заказов …… Срок действия Размер(%) …… “derive”
91. Пример использования стереотипов на фрагменте диаграммы развертывания Примечание, определяет рекомендации по технологии физической реализации соединений в
92. Помимо стереотипов, указываемых в виде строки текста в кавычках, на диаграммах могут использоваться графические стереотипы. На
93. Примеры различных стереотипов Создавая пиктограмму для стереотипа, используйте цвет в качестве удобного визуального идентификатора (хотя злоупотреблять
94. Примеры графических стереотипов Например, рабочую станцию можно изобразить в виде ресурсоемкого узла, или в форме рисунка
95. Сторожевое условие на диаграмме деятельности Диаграмма деятельности
96. Вариант физического представления модели мобильного доступа к корпоративной базе данных на диаграмме развертывания Примечание, определяет рекомендации
97. Пример использования механизмов расширения на диаграмме развертывания
98. Примеры диаграмм (повторение)
99. Диаграмма, описывающая предметную область сказки о Курочке Рябе (взята с сайта конкурса шуток на UML (http://www.umljokes.com/)
100. Диаграмма последовательности
101. Какого типа диаграмма? Какие сущности и отношения показаны на диаграмме?
102. Диаграмма вариантов использования: Какие сущности и отношения показаны на ней? Какие сущности и отношения показаны на
103. Диаграмма использования http://www.intuit.ru/studies/courses /1007/229/lecture/5954?page=1 Какие сущности и отношения показаны на диаграмме?
104. Диаграмма классов Какие сущности и отношения показаны на диаграмме?
105. Диаграмма классов Какие сущности и отношения показаны на диаграмме?
107. Скачать презентацию

Слайд 2

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

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

Слайд 3

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

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

Слайд 4

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

Слайд 5

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

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

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

Слайд 6

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

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

OOP

OOD

OOA

Слайд 7

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

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

Слайд 8

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

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

Слайд 9

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

Слайд 10

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

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

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

Слайд 11

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

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

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

Слайд 12

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

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

Слайд 13

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

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

Слайд 14

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

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

Слайд 15

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

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

http://book.uml3.ru/sec_1_3

Слайд 16

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

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

Слайд 17

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

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

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

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

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

Слайд 18

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

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

Слайд 19

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

Слайд 20

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

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

Слайд 21

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

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

Слайд 22

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

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

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

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

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

Слайд 23

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

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

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

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

Слайд 24

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

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

Слайд 25

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

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

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

Слайд 26

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

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

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

Слайд 27

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

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

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

Слайд 28

3 основных варианта использования UML (показаны на диаграмме использования UML)
http://book.uml3.ru/sec_1_2

Слайд 29

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

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

Слайд 30

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

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

Слайд 31

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

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

Слайд 32

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

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

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

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

Слайд 33

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

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

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

Слайд 34

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

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

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

Слайд 35

Структура UML

Слайд 36

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

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

Слайд 37

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

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

Слайд 38

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

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

Слайд 39

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

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

Слайд 40

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

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

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

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

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

Слайд 41

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

Слайд 42

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

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

Слайд 43

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

Слайд 44

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

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

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

Класс круг

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

Слайд 45

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

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

Объект
(object)

Слайд 46

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

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

iРасчет

Слайд 47

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

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

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

Слайд 48

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

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

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

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

Слайд 49

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

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

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

Слайд 50

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

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

Слайд 51

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

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

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

Слайд 52

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

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

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

Слайд 53

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

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

Слайд 54

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

Слайд 55

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

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

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

Слайд 56

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

Слайд 57

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

Слайд 58

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

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

Слайд 59

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

Слайд 60

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

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

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

Слайд 61

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

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

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

Слайд 62

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

Слайд 63

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

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

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

Слайд 64

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

Слайд 65

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

Слайд 66

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

(dependency)

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

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

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

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

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

Слайд 67

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

Слайд 68

Слайд 69

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

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

Слайд 70

Отношения:

Слайд 71

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

Слайд 72

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

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

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

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

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

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

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

Слайд 73

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

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

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

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

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

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

Слайд 74

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

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

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

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

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

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

Слайд 75

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

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

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

Интерфейс

Класс

Слайд 76

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

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

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

Слайд 77

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

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

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

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

Слайд 78

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

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

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

Слайд 79

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

Слайд 80

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

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

Слайд 81

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

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

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

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

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

Слайд 82

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

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

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

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

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

Слайд 83

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

Слайд 84

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

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

Слайд 85

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

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

Слайд 86

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

Слайд 87

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

Слайд 88

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

Слайд 89

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

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

ЗС

НЗС

Слайд 90

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

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

Слайд 91

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

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

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

Слайд 92

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

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

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

a б в

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

Слайд 93

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

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

Слайд 94

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

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

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

Слайд 95

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

Слайд 96

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

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

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

Слайд 97

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

Слайд 98

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

Слайд 99

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

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

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

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

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

Слайд 100

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

Слайд 101

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

Слайд 102

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

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

Сумма сделки

Слайд 103

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

Слайд 104

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

Слайд 105

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

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 основных варианта использования UML (показаны на диаграмме использования UML) http://book.uml3.ru/sec_1_2

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

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

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

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

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

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

Структура UML

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отношения:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 основных варианта использования UML (показаны на диаграмме использования UML)
http://book.uml3.ru/sec_1_2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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