Тема.2. Системный ( структурный ) уровень компьютерного

Проектирования сложных обьектов

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

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

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

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

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

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

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

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

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

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

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

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

Чертить ПО.

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

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

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

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

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

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

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

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

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

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

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

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

⇐ Предыдущая 1 2 3 4 567 8 9 10 Следующая ⇒