1. Визуальное моделирование и UML,метафоры визуализации программного обеспечения

• кооперации (collaboration diagram);
• последовательности (sequence diagram);
• состояний (statechart diagram);
• деятельности (activity diagram);
• компонентов (component diagram);
• развертывания (deployment diagram).

Построения этих диаграмм достаточно для полного моделирования системы.

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

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

Некоторые примеры моделей:

• Варианты для однозначного определения поведения
• Диаграммы классов и диаграммы моделирования данных для фиксации эскиза
• Диаграммы переходов состояний для моделирования динамического поведения

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

Прогаммное обеспечение, находится более в психическом, чем в физическом мире человека и оказывается невидимым. Поэтому его чертежи не привносят в проект той магической ясности, как чертежи (пусть даже очень сложные) строящегося здания, конструируемого самолета, монтируемой электроустановки. Не имея очевидных, зримых образов ПО, мы не можем однозначно сказать, как его изображать. Каждый склонен «видеть» и, соответственно, изображать ПО как-то по-своему или вовсе обходиться без этого. Среди программистов много скептиков в отношении визуального моделирования, и UML используется далеко не в каждом проекте. Не все понятно и с тем, какую часть ПО имеет смысл изображать. Скорее всего, его архитектуру… Но в литературе по программной инженерии на настоящий момент существует более ста различных определений этого термина (вспомним о концептуальной сложности ПО, на которую указывал Брукс). То есть однозначности нет и в этом вопросе. Кроме того, в программировании не удается построить столь же четкое разделение труда, как в других промышленных областях, выделив умных архитекторов и трудолюбивых и послушных разработчиков. Автор архитектурного решения, как правило, участвует в его реализации, потому что зачастую только он один до конца понимает все хитросплетения своего замысла и варианты его дальнейшего развития. Архитектор должен постоянно участвовать в проекте (возможно, с разной степенью интенсивности), так как разработка ПО итеративна и проектирование не может быть окончательно завершено перед разработкой, а его результаты – зафиксированы чертежами. Архитектор – это лишь опытный разработчик. А инженер от рабочего отличается радикально… Однако все эти обстоятельства не являются непреодолимым барьером в использовании чертежей при создании ПО. Об этом говорит сайт https://intellect.icu . Ситуация не безнадежная, а всего лишь иная.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Универсальные инструменты являются коробочными и многофункциональными пакетами, предназначенными для анализа и проектирования ПО «вообще», то есть без какой-либо специализированной ориентации. Как правило, сегодня такие пакеты строятся на базе языка UML и называются CASE-пакетами. Самыми известными CASE-пакетами (Computer Aided Software Engineering) являются 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.6. Этот разрыв препятствует автоматической генерации программного кода по визуальным моделям в общем случае, не позволяя визуальному моделированию стать следующим шагом в развитии средств программирования, вслед за алгоритмическими языками высокого уровня.

Рис. 1.6. Семантический разрыв между визуальными моделями и программами

Где решение этой проблемы?

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

• • в разработке схем реляционных баз данных;
• • при создании событийно-ориентированных систем реального времени;
• • при формализации бизнес-процессов компаний.

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

В следующих статьях рассматриваются элементы нотации диаграмм и принципы их построения.

Вау!! 😲 Ты еще не читал? Это зря!

• uml диаграммы ,
• диаграмма состояний , statechart diagram ,
• диаграмма классов , class diagram ,
• uml , диаграммы классов ,
• типовые ошибки в use case диаграммах , разница между include и extend ,
• диаграмма вариантов использования , use case diagram ,
• отношения между прецедентами и актерами ,
• моделирование