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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чертить ПО…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О программных инструментах

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

Универсальные инструменты являются коробочными и многофункциональными пакетами, предназначенными для анализа и проектирования ПО "вообще", то есть без какой-либо специализированной ориентации. Как правило, сегодня такие пакеты строятся на базе языка UML и называются CASE-пакетами. Самыми известными CASE-пакетами являются IBM Rational Rose, Borland Together, Telelogic Tau, Microsoft Visio/UML Add-on. Эти средства поддерживают различные виды диаграмм, удобную среду их разработки с такими функциями, как печать и копирование диаграмм, различные способы редактирования графических символов, средства просмотра и поиска в визуальной модели, различные режимы отображения диаграмм и многое другое. Они также обеспечивают генерацию программного кода в разные целевые платформы программирования, версионный контроль визуальных моделей, часто являются кросс-платформенными (например, работают под управлением операционных систем Windows и Linux), обеспечивают интеграционные "мосты" с другими средствами разработки ПО, например, со средствами управления требованиями. Как правило, все современные CASE-пакеты имеют открытые программные интерфейсы и позволяют расширять свою базовую функциональность.

Предметно-ориентированные (domain-specific) программные инструменты поддержки визуального моделирования предназначены для определенных областей разработки ПО и тоже могут быть коробочными, как, например, пакет WebRatio для моделирования web-приложений. Однако предметно-ориентированные инструменты могут создаваться и отдельными компаниями для своих собственных проектов, особенно в рамках линеек программных продуктов (product lines). Это особенно удобно, поскольку во-первых, такие средства могут хорошо решать задачи именно того процесса, той компании, для которых они создаются. А во-вторых, сейчас на рынке имеются развитые среды для разработки средств визуального моделирования, самые известные из которых - Microsoft Visio, Microsoft DSL Tools и Eclipse/GMF. Эти и другие пакеты делают задачу создания собственного графического редактора посильной для обычных, рядовых компаний-разработчиков. Предметно-ориентированное визуальное моделирование будет подробно рассмотрено в следующих лекциях.

Визуальное моделирование на фоне эволюции средств программирования

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

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

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

Далее появились алгоритмические языки программирования - COBOL, Fortran, PL/1, Algol60, C, Pascal, C++, Java, C# и многие другие. По мере их развития программист получал возможность все меньше и меньше задумываться о деталях процесса выполнения программы на ЭВМ и все больше внимания уделять описанию логики задачи, которую реализовывала его программа. Соответственно, спектр задач, которые становилось способным решать ПО, существенно расширялся, сложность программ увеличивалась.

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

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

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

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

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

Однако оказалось, что визуальные модели, действительно удобные в работе, "склонны" терять исполняемую семантику. Другими словами, информация, которая в них содержится, оказывается недостаточно полной и детальной, чтобы по ней вычислитель мог бы выполнить свою работу. Ведь никакая "умная" генерация не может добавить то, что отсутствует изначально. Если же визуальные модели усложнять, чтобы они были пригодны для использования вычислителем, то очень часто они теряют наглядность и становятся бесполезными. Кому нужны непонятные, но полные описания программного обеспечения, выполненные с помощью визуальных моделей? Есть тексты на языках программирования, есть документы, есть возможность спросить, в конце концов, разобраться в коде самому…

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

Где выход?

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

Эти области и будут подробно рассмотрены в этом курсе лекций.

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

Контрольные вопросы