Лет десять назад разработкой более-менее крупных программных проектов занимались, по понятным причинам, только государственные структуры. В силу глобальности замыслов и относительной неторопливости (или неповоротливости) госорганизаций, что, впрочем, чаще всего шло проекту на пользу, ибо он создавался без спешки. Первоначально писалось подробное Техническое задание. Правда, не столько из-за любви к системному анализу, сколько из-за необходимости отчитываться перед вышестоящим начальством, поэтому и выходило оно подчас на уровне отписки. Наверняка многие из читателей помнят, что обычно шло первым пунктом. Как правило, это были "информационные потоки".
Собственно, в продумывании потоков информации между объектами моделируемой системы нет и не может быть ничего плохого. Дело лишь в том, что красиво смотрящиеся на диаграммах стрелочки в реальном компьютерном воплощении оказывались по существу фикцией, не привязанной ни к какому коду.
Одна из хорошо известных в США фирм, занимающаяся производством сетевой аппаратуры и ПО для нее, создала программный продукт для управления сетями, основанный на очень оригинальной идеологии. Каждому физическому объекту сети соответствует свой компьютерный аналог, обладающий элементами интеллектуальности, т. е. способный "общаться" как с другими объектами сети, так и с главным управляющим сервером. При этом само устройство - "железо" со всеми техническими нюансами функционирования, скрыто в своей виртуальной модели, обладающей неким стандартным интерфейсом. Реализация подобной идеологии позволяет объединять в виртуальную сеть физические устройства с любыми характеристиками от любых поставщиков и управлять ими стандартным образом. Преимущества очевидны. Прежде всего, это масштабируемость и независимость от оборудования, а кроме того, легкие расширяемость, управление и администрирование, интеллектуальное (на программном уровне) выявление и устранение сбоев, простое переконфигурирование и еще ряд вытекающих из такой стройной идеологии следствий.
Но самое интересное в данной системе - это уровень моделирования, или степень детализации на аппаратном уровне. Оказывается, отдельным объектом представлен даже такой элемент сети, как участок кабеля! Собственно, если вдуматься, то так и должно быть. Ведь если происходит столь привычный нам обрыв кабеля в процессе трехнедельной "профилактики водопроводной сети", то без наличия его виртуального, компьютерного, аналога невозможно будет быстро локализовать возникший сбой. Когда же сервер получил от виртуальной модели поврежденного участка сообщение о том, что физический кабель перестал работать, то он самостоятельно произведет перемаршрутизацию пакетов, учитывая в будущем, что некая часть сети вышла из строя. Как только кабель будет восстановлен, сервер снова включит его в работу.
Отсюда для разработчиков больших систем вытекают два интересных следствия. Во-первых, во многих ситуациях лучше всего моделировать схему функционирования, описывающую реальный объект как можно точнее, детальнее и ближе к оригиналу. Может показаться, что объектное проектирование именно этим и занимается, однако достаточно посмотреть книги по ООП, чтобы убедиться, что, по крайней мере, теоретики этого направления исходят из других посылок. В частности, процесс декомпозиции обычно приводит к получению компьютерных объектов, совершенно непохожих на реальные. Взять хотя бы бухгалтерские программы, которые, будучи реализованными в Windows, предоставляюшей в первую очередь богатые графические возможности, тем не менее практически не отходят от уровня текстовых электронных таблиц. А ведь метафора папок и листочков-пустографок на рабочем столе хоть и сложнее в реализации, но значительно перспективнее в плане модульности и расширяемости. Достаточно продумать событийно-ориентированное ядро программы и виртуальную интерфейсную библиотеку, и можно получить легко переносимый на другие платформы алгоритм.
Во-вторых, и это, пожалуй, самое главное, очень полезным может оказаться выделение самих информационных потоков (вспомним участок кабеля!) в отдельный объект. Помимо решения вспомогательных задач, связанных, например, с промежуточной буферизацией и интеллектуальным управлением потоками данных, снимается головная боль при реализации стрелочек, имитирующих пресловутые потоки. Чем их выражать? Методами объектов, генерацией событий или чем-то еще?
Когда же каждому потоку ставится в соответствие свой объект, появляется возможность реализовать оригинальную физическую модель "один к одному" в виде ее копии - виртуального образа, без выдумывания искусственных и неестественных связей. А ведь сами по себе такие объекты могут выполнять еще и ряд других полезных функций, допустим, по отладке или сбору информации о динамических процессах функционирования моделируемой системы.
Нередко оригинальные идеи, заложенные в известные продукты, оказываются родоначальниками целых направлений в программировании. Так было с первыми графическими интерфейсами, с электронными таблицами, с персональными менеджерами. С появлением высоконадежных систем архитектуры клиент - сервер, наиболее близких по идеологии к большим программным комплексам, тоже весьма полезно поближе познакомиться с их внутренней структурой.
Сергей Бобровский
