Модели и их представления в UML

1.

ПРОЕКТИРОВАНИЕ ПО ИС
Тема № 7 «Модели и их представления в UML»

2.

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

3.

Модели и их представления
Еще одна составляющая успеха UML состоит в том, что в последнее
десятилетие в компьютерном мире наметилась тенденция моделирования
сложных систем визуальными (наглядными) моделями. Причем в UML наглядные
модели как раз представляют собой «взгляды», направленные на сложную систему
с различных точек зрения. Набор из нескольких наглядных моделей (модельных
взглядов) создает в сознании специалистов интегральный образ сложной
компьютерной системы, которую они совместно проектируют. Вместе с тем,
наглядные
модели
служат
эффективным
средством
документирования
компьютерных систем и их программных обеспечений, а также языком общения
между программистами, системными аналитиками и заказчиками систем.
Возникает естественный вопрос. Почему 300 ведущих компьютерных
фирм, объединенных в консорциуме OMG, придают такое большое значение
работам по созданию версий языка UML, в чем причины революционных перемен в
области технологий программирования, вызванных появлением языка UML?
Чтобы ответить на этот вопрос, обратимся к следующему рисунку.

4.

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

5.

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

6.

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

7.

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

8.

Классификация моделей по назначению
Концептуальная модель (conceptual model). Один из самых важных типов
моделей, так как они получаются в результате анализа предметной области.
Их
также
часто
называют
моделями
анализа
(analysis
model)
или аналитическими моделями. Концептуальные модели довольно стабильны:
если не меняется предметная область, то нет нужды менять и модель.
Главное требования к модели - концептуальная целостность (consistency).
Модель проектирования (design model). Модель проектирования представляет
собой высокоуровневое (на уровне подсистем) и низкоуровневое (на уровне
классов)
описание
программной
системы.
Модель
проектирования
предназначена для разработки программного кода приложения. Как правило,
архитектура (высокоуровневое описание) и код разрабатываются итеративно,
и разработчикам в процессе разработки необходимо модифицировать модель
проектирования, чтобы она соответствовала принимаемым решениям.
Главное требование к модели проектирования - понятность (usability).

9.

Классификация моделей по назначению
Модель реализации (implementation model). Модель реализации предназначена
для автоматического преобразования в существенно другой вид, например, в
исполнимый код. Такое предназначение требует указания необходимых деталей
реализации в модели, поскольку «от себя» компьютер их добавить не сможет.
Главное требование к моделям реализации - полнота(completeness).
Между моделями имеются стилистические различия. На следующем
слайде приведен пример отношений между авторами Author и книгой Book. С
концептуальной точки зрения книга (1) ‒ это тип издания, который имеет
авторов (2), причем соавторов у книги может быть несколько и каждый
может быть автором нескольких книг. Важно учесть, что в создание книги
каждый соавтор внес определенный вклад (3). В модели проектирования
необходимо уточнить, что абстрактный творческий вклад измеряется в
конкретных процентах (4), а в модели реализации добавить, что необходимо
проверять инвариантное соотношение (5), состоящее в том, что для каждой
книги сумма вкладов всех ее авторов должна быть равна 100%.

10.

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

11.

Классификация моделей по назначению
В качестве дополнения к модели реализации можно привести
поясняющую диаграмму объектов, где указать конкретную книгу
(1),
конкретных авторов (2) и конкретный вклад каждого из авторов (3).
Классификация по назначению ‒ не единственная классификация
моделей. Еще одним примером классификации, важным с теоретической
точки зрения, является классификация моделей по уровням абстракции.

12.

Классификация моделей по уровням абстракции
В UML 1 эта классификация в явном виде присутствовала в
стандартах. В UML 2 из текста стандарта ее исключили, но влияние данной
классификации все равно ощущается. Речь идет об весьма важной и
перспективной, хотя и не очень широко используемой возможности UML ‒ о
метамоделировании.
Метамодель (metamodel) ‒ модель языка описания моделей.
В соответствии со стандартом UML 1 используются 4 уровня:
• M0 ‒ уровень объектов
• M1 ‒ уровень моделей
• M2 ‒ уровень метамодели
• M3 ‒ уровень мета-метамодели
Поскольку мета-метамодели и метамодели описываются с применением тех
же средств ‒ то есть диаграмм классов, дальнейшее прибавление приставки
"мета" не имеет смысла, так как не даст ничего нового.

13.

Классификация моделей по уровням абстракции
В UML в качестве мета-метамодели применяется стандарт
MOF (Meta Object Facility), специально разработанный OMG для
спецификации метамоделей различных языков моделирования, таких
как UML и CWM (Common Warehouse Metamodel).
В лекциях подавляющее большинство примеров относится к
уровню M1, но встречается буквально несколько примеров на уровнях
M0. Важно понять, что на всех уровнях используются одни и те же
языковые средства ‒ различия не синтаксические, а семантические.
Упрощенно говоря, уровень модели ‒ это число шагов по
созданию экземпляров (instantiation), которые нужно сделать, чтобы
спуститься с данного уровня абстракции на уровень моделируемой
реальности. Пояснение к сказанному на следующем слайде, в котором
продолжается рассмотрение примера с книгой.

14.

Классификация моделей по уровням абстракции

15.

Классические представления из UML 1 и 2
Набор используемых представлений модели является еще менее
формальным
и
догматическим,
чем
набор
канонических
диаграмм
и
классификация назначения и уровня моделей.
Одним
из
самых
популярных
является
набор
представлений,
описанных авторами языка в UML 1 и показанных на следующем рисунке. Этот
рисунок заимствован из книги Буча, Рамбо и Якобсона "UML. Руководство
пользователя" с соответствующим изменением терминологии.

16.

Классические представления из UML 1 и 2
Представление использования (Use Case View) ‒ это описание
поведения системы в терминах вариантов использования с точки зрения
внешних по отношению к системе действующих лиц. Данное представление
описывает не то, как организована система, а те функциональные
требования, которым она должна удовлетворять. При этом структурные
аспекты передаются диаграммами использования, а поведенческие аспекты ‒
диаграммами взаимодействия, состояний и деятельности.
Представление проектирования (Design View) предназначено для
описания словаря предметной области, то есть, в парадигме объектно-
ориентированного
программирования,
классов,
а
также
таких
вспомогательных сущностей как, например, интерфейсы или кооперации.
Структурные аспекты передаются диаграммами классов и объектов, а
поведенческие аспекты ‒ диаграммами взаимодействия, состояний и
деятельности.

17.

Классические представления из UML 1 и 2
Представление
процессов
(Process
view)
‒
это
описание
взаимодействия элементов управления (процессов, потоков) в системе. Оно
отражает такие нефункциональные требования, как, например, обеспечение
параллелизма. Структурные аспекты передаются с помощью концепции
активных классов, представляющих процессы и потоки, а поведенческие
аспекты ‒ диаграммами взаимодействия, состояний и деятельности.
Представление компонентов (Component view) ‒ это описание
системы на уровне артефактов (компонентов, файлов и т.д.), используемых
для сборки, выпуска, конфигурации программного продукта. Структурные
аспекты передаются диаграммами компонентов, а поведенческие аспекты ‒
диаграммами взаимодействия, состояний и деятельности.
Представление
размещения
(Deployment
view)
отражает
топологию связей аппаратных средств и размещения на них компонентов.
Структурные
аспекты
передаются
диаграммами
размещения,
поведенческие ‒ диаграммами взаимодействия, состояний и деятельности.
а

18.

Классические представления из UML 1 и 2
Первоначальные пять представлений, ассоциирующиеся с UML 1, при
переходе к UML 2 были дополнены и в результате образовали набор уже из
восьми представлений.
Представления
Статическое
представление
Диаграммы
Диаграмма
классов
(Static view)
Диаграмма
внутренней
Представление
структуры
проектирования
Диаграмма
(Design view)
кооперации
Диаграмма
компонентов
Комментарий
В UML 1 ‒ часть
представления
проектирования (Design view)
В UML 1 частично
отображается в
представлении процессов
(Process view) и
представлении компонентов
(Component view)

19.

Классические представления из UML 1 и 2
В UML 1 описывается
Представление
использования
Диаграмма
использования
(Use Case view)
одноименным представлением,
однако были также добавлены
диаграммы взаимодействия,
состояний и деятельности.
Представление
автоматов
В UML 1 представление не
Диаграмма
обособленно, а используется
автомата
всеми представлениями по мере
(State machine view)
необходимости.
Диаграмма
В UML 1 данное представление
Представление
деятельности
не является обособленной
деятельности
Обзорная
частью, а используется всеми
(Activity view)
диаграмма
представлениями по мере
взаимодействия
необходимости.

20.

Классические представления из UML 1 и 2
Диаграмма
Представление
взаимодействия
(Interaction view)
последовательности
В UML 1 данное представление
Диаграмма
не обособленно, а используется
коммуникации
всеми представлениями по
Диаграмма
мере необходимости.
синхронизации
В UML 1 описывается
Представление
одноименным представлением,
развертывания/
Диаграмма
однако в список диаграмм
размещения
развертывания
также добавлены диаграммы
взаимодействия, состояний и
(Deployment view)
деятельности.
Представление
управления моделью
(Model Management view)
Диаграмма пакетов
Отсутствует в UML 1

21.

Классические представления из UML 1 и 2
Статическое представление (Static view) отражает статическую
структуру системы и не описывает динамику в любом ее проявлении.
Чаще всего, оно отражает логические концепции приложения, основой
которого служат классы и их отношения.
Представление
проектирования
(Design
view)
является
более
детализированным вариантов статического представления, выделяя
аспекты, обеспечивающие необходимую функциональность системы.
Представление
использования
(Use
Case
view)
описывает
функционирование системы в терминах вариантов использования и
рассматривает их с точки зрения заинтересованных действующих лиц.
Представление автоматов (State machine view) специфицирует
поведение элементов, для которых можно ввести понятие жизненного
цикла, описываемого набором состояний и переходов между ними.

22.

Классические представления из UML 1 и 2
Представление
деятельности
(Activity
view)
описывает
функционирование системы с точки зрения различных элементов
деятельности, соединенных потоками управления и потоками данных.
Представление
взаимодействия
(Interaction
view)
отражает
последовательность обмена сообщениями между элементами системы
во время выполнения приложения.
Представление
развертывания
(Deployment
view)
описывает
размещение артефактов на вычислительных узлах во время выполнения
приложения, а также компоненты и другие элементы.
Представление управления моделью (Model Management view)
отражает внутреннюю организацию модели, описывая ее разбиение на
пакеты и указывая отношения между ними.

23.

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

24.

Модель процесса моделирования
Процесс моделирования не последовательный, а итеративный и параллельный.

25.

Прагматика представлений

26.

Прагматика представлений на примере

27.

Прагматика представлений на примере

28.

Прагматика представлений на примере

29.

Прагматика представлений на примере

30.

Прагматика представлений на примере