Основы визуального моделирования

Визуальное моделирование: теория и практика

2-е издание, исправленное

Кознов Д.В.

Национальный Открытый Университет “ИНТУИТ”
2016

2

УДК [004.41‘22+004.438UML](075.8)
ББК 24
К59
Основы визуального моделирования / Кознов Д.В. - M.: Национальный Открытый Университет
“ИНТУИТ”, 2016 (Основы информационных технологий)
ISBN 978-5-94774-823-9

Данный курс посвящен визуальному моделированию - графическим языкам, методам и программным
инструментам. Подробно обсуждаются особенности визуального моделирования программного
обеспечения по сравнению с чертежным проектированием в других инженерных областях (например,
машиностроении, электротехнике, строительстве).
Рассматривается главный стандарт в этой области - язык UML 2.0, а также новый стандарт комитета
OMG для моделирования бизнес-процессов - язык BPMN (Business Process Modeling Notation).
Подробно освещается использование визуального моделирования при разработке баз данных, систем
реального времени и бизнес-процессов, рассказывается о психологических аспектах применения
визуальных моделей при работе с информацией. При этом многие базовые аспекты визуального
моделирования даются не сухой выжимкой, а проводятся исподволь и демонстрируются на
многочисленных примерах. Особо обсуждаются вопросы, которым традиционно не уделяется
должного внимания, но которые чрезвычайно важны для практики - проблема семантического
разрыва между кодом и диаграммами, концепция точки зрения моделирования, граф модели и
диаграммы и т. д.

(c) ООО “ИНТУИТ.РУ”, 2008-2016
(c) Кознов Д.В., 2008-2016

3

Определение визуального моделирования

Здесь рассказывается о роли чертежей в стандартизации промышленного производства
в классических, инженерных областях (строительстве, машиностроении,
электротехнике и т. д.). Обсуждается причины, препятствующие использованию
чертежного проектирования при разработке программных систем “as is”. Вводится
понятие метафоры визуализации, обосновывается практическая значимость графовой
метафоры при визуализации ПО. Дается определение визуального моделирования и
средств визуального моделирования - языков, методов, программных инструментов.
Рассказывается о семантическом разрыве между визуальными моделями и
программным кодом, препятствующим автоматической генерации кода по моделям

О пользе чертежей

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

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

В конце 60-х годов прошлого века исследователи в поисках способов упорядочивания
и стандартизации процесса создания ПО обратились к другим, уже устоявшимся
промышленным областям. Было замечено, что в строительстве, машиностроении,
электротехнике и т. д. работы по созданию новых систем разбиваются на два основных
этапа - проектирование и реализацию. Проектирование осуществляют архитекторы,
конструкторы, инженеры, а изготовляют систему рабочие, строители, монтеры.
Результаты проектирования фиксируются с помощью чертежей - схематичных
изображений создаваемой системы. Эти чертежи служат хорошим интерфейсом между
проектировщиками и теми, кто, собственно, создает, делает саму систему. Чертежи
обязывают последних строго следовать принятым решениям, избавляя от
необходимости думать над принципиальными вопросами. Главное уже продумано и
решено, и все, что нужно - это разобраться в чертежах системы, понять, как и что
нужно сделать, и сделать это. Ситуации, когда по ходу разработки приходится менять
проектные решения, как правило, случаются крайне редко. Таким образом, чертежи
сыграли важную роль в становлении современной промышленности, позволяя
эффективно разделить труд между квалифицированными инженерами и обычными

4

рабочими.

Аналогичным образом хотелось бы применять чертежи и в программировании. Однако
здесь существуют некоторые особенности, которые не позволили использовать
чертежное проектирование “as is”.

ПО и другие инженерные объекты

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

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

Таким образом, можно выделить психический мир человека, где происходит эта не
вполне понятная психологам деятельность человеческого сознания, а также
физический мир воспринимаемый нами через органы чувств и где процессы более
понятны и научно обоснованы. Эти миры человека сильно переплетены, связаны друг с
другом. Например, абстрактные научные теории (несомненно, явления психического
мира) приводят к созданию новых машин и механизмов (явлений физического мира).
Доктор Бэйтс использовал воображение (психический инструмент) для улучшение
зрения (физический эффект) [1.10]. В медицине и психологии известно большое
количество “связок” физического и психического.

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

Фредерик Брукс в своей знаменитой статье “Серебряной пули нет” [1.1] выделил
следующие характеристические признаки ПО, отличающие его от других инженерных
объектов: невидимость, изменчивость, согласуемость (в основном с людьми заказчиками и разработчиками, а также между различными категориями
задействованных в его создании лиц), а также огромную сложность (другими словами трудности концептуализации программных систем). Можно сказать, что ПО - это

5

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

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

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

Чертежи хорошо “работают” в промышленности, так как позволяют схематично
нарисовать то, что можно будет потом увидеть глазами. Ведь сечение здания или
механической детали, принципиальная схема электроснабжения квартиры или завода все это можно увидеть или правдоподобно представить, убрав лишнее, изменив
масштаб, упростив изображение несущественных деталей. Имея такой чертеж системы,
можно пояснить на нем основные решения, создав тем самым хорошее предписание
для тех, кто будет эту систему создавать. Участникам проекта легче понять друг друга,
поскольку они вместе видят одни и те же чертежи, которые вызывают в их памяти
одни и те же визуальные образы других подобных объектов. А если еще добавить к
этому, что до 90% информации современный человек получает именно через зрение, то
понятно, почему чертежи так облегчают жизнь при создании искусственных систем. И
понятно, почему хочется их использовать в программировании.

Чертить ПО…

Итак, программное обеспечение, находится более в психическом, чем в физическом
мире человека и оказывается невидимым. Поэтому его чертежи не привносят в проект
той магической ясности, как чертежи (пусть даже очень сложные) строящегося здания,
конструируемого самолета, монтируемой электроустановки. Не имея очевидных,
зримых образов ПО, мы не можем однозначно сказать, как его изображать. Каждый
склонен “видеть” и, соответственно, изображать ПО как-то по-своему или вовсе
обходиться без этого. Среди программистов много скептиков в отношении визуального
моделирования, и UML используется далеко не в каждом проекте.

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

6

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

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

Метафора визуализации

В силу невидимости ПО центральным аспектом при его визуализации является поиск
подходящей метафоры. У нас нет геометрических форм объекта, которые в
классическом черчении являются основой всех его схематичных изображений.
Поэтому нам нужно чему-то уподобить зрительный образ ПО. Программная система
выглядит как … что?

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

Существует большое количество различных метафор для изображения ПО. На рис. 1.1
представлен пример, изображающий условное предложение if B then S1 else S2; S3
с использованием графического языка VIPR (VIsual Imperative Programming) [1.11].
Однако очевидно, что большие программы так изображать неудобно…

7

Рис. 1.1.  Условное предложение в нотации языка VIPR

Графовая метафора

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

Рис. 1.2.  Примеры разных графов,используемых в визуальном моделировании

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

Однако не все виды диаграмм, применяемые в рамках визуального моделирования,
являются графами, например, диаграммы последовательностей (sequence diagrams) или
временные диаграммы (timing diagrams) UML. Однако из тринадцати видов этих
диаграмм UML 2.0 только два не являются графами.

Более детальную информацию по визуализации ПО, метафорам и методам его
визуализации можно найти в работах [1.4], [5].

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

Определение визуального моделирования

Итак, визуальное моделирование (visual modeling) является методом, применяемым в

8

разработке ПО, который:

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

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

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

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

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

Визуальное моделирование применяется на практике с помощью методов, языков и
соответствующих программных инструментов (см. рис. 1.3).

9

Рис. 1.3.  Визуальное моделирование: языки, методы, программные средства

Языки визуального моделирования (или визуальные языки) - это формализованные
наборы графических символов и правила построения из них визуальных моделей.
Сейчас известны и активно используются на практике такие языки визуального
моделирования, как UML и BPMN. Однако существуют и более старые языки: SDL и MSC
для моделирования телекоммуникационных систем, SADT/IDEF0 для моделирования
бизнес-процессов, IDEF1x для моделирования баз данных и некоторые другие. Кроме
того, в исследовательской среде создано множество других визуальных языков,
например, язык WebML для моделирования web-приложений.

Методы использования визуального моделирования предписывают правила
применения визуальных языков для решения тех или иных задач процесса разработки
ПО.

В качестве примера кратко рассмотрим метод SADT (Structured Analysis and Design
Technique) [1.2], [1.13], к которому мы неоднократно будем обращаться в дальнейшем.
Этот метод предназначен для структурного анализа создаваемой или модифицируемой
системы и является способом уменьшить количество дорогостоящих ошибок за счет
структуризации знаний о системе на ранних этапах ее разработки, улучшения
взаимодействия разработчиков и пользователей/заказчиков, а также сглаживания
перехода от анализа к проектированию. Он включает в себя визуальный язык, а также
подробно описанные принципы и технологию использования этого языка. Термин
“структурный анализ” был введен в обиход Дугласом Россом (Douglas Ross) - главным
автором SADT - в конце 60-х годов.

Коротко историю развития SADT можно представить следующим образом:

60-е годы - группа ученых из MIT (Massachusetts Institute of Technology) под
руководством Дугласа Росса создала метод иерархической модульной
декомпозиции программных систем под названием SADT ;
в 1969 авторы SADT основали компанию SoftTech, которая стала развивать и
коммерциализировать этот метод;

10