Внедрении WPF в сложных системах (доклад)

1. Докладчик: Павлов Михаил Борисович
e-mail: pavmb2001@mail.ru
Тема доклада: Первый опыт внедрения WPF в сложной системе (С++ и
COM).
В данном докладе я хочу поделиться опытом внедрения WPF, в сложный проект, реализованный с
использованием технологии COM большей частью на языке C++.
На первый взгляд, очевидный процесс освоения новых технологий, таил в себе массу подводных
камней, от интеграции существующих компонент до реорганизации взаимодействия членов
команды.
Надеюсь, данный опыт будет полезен кому-нибудь из слушателей.
План доклада:
1. Введение
2. Краткое описание системы до начала внедрения
• общая структура;
• задачи системы;
• использованные технологии.
3. Цели внедрения WPF
• проблемы, которые хотели решить;
• ожидаемый (оптимистический) результат от внедрения.
4. Возникшие трудности и способы их решения
• технологические трудности перехода к использованию WPF, интеграция
существующих COM объектов и С++ кода;
• изменение стереотипов разработки UI (переход на Binding);
• проблемы организации взаимодействия программист-дизайнер;
• проблемы интеграции OpenGL рендеринга (кратко).
5. Текущее положение вещей
• что удалось достичь;
• решенные и нерешенные проблемы;
• сравнение прогнозов в начале и реальных результатов.

2. 6. Рекомендации

3. 1. Введение
Здравствуйте уважаемые коллеги!
Я – Павлов Михаил, инженер-программист одной из кампаний группы кампаний «Транзас».
Тема моего доклада – «Первый опыт внедрения WPF в сложной системе». Основные цели
доклада:
• рассказать о проблемах, возникающих на начальных этапах внедрения WPF;
• на основе полученного опыта, сформулировать рекомендации организации более
эффективного рабочего процесса.
Несмотря на некоторую субъективность изложения, надеюсь, данный доклад будет полезен
кому-нибудь из слушателей.
2. Краткое описание системы до начала внедрения
Группа кампаний «Транзас» занимается морской тематикой, одним из направлений которой
является разработка полнофункциональных тренажеров управления кораблем. Тренажер
представляет собой максимально полную, имитацию мостика корабля, включая панорамные
экраны и систему имитации качки.
Продукт, о котором пойдет речь, является дизайнером сцен. Параллельно с ним
разрабатывается движок 3D визуализации, отображающий сцены в тренажере.
Задачами продукта являются:
• создание сцены района на базе каталога морских карт;
• загрузка дополнительных данных из различных источников: карты высот и глубин, гео-
текстуры, прототипы, планы, дополнительная картографическая информация и т.п.;
• выборочное редактирование и детализация дизайнером;
• экспорт данных в формате понятном движку 3D визуализации.
Основным требованием является максимальный реализм итоговой сцены.
Обобщенно можно выделить следующие основные части:
• хранилище данных;
• логика;
• модули импорта;
• модуль экспорта;
• движок редактора с инструментами редактирования;

4. • UI – основное окно + окна редактирования свойств объектов;
• Сопутствующие утилиты: библиотеки прототипов и материалов, редактор моделей
кораблей, утилиты предварительного просмотра компонент сцены.
Изначально продукт разрабатывался на Visual C++ со всем набором сопутствующих
технологий:
• алгоритмы и логика – С++, COM;
• UI и движок редактора – С++, MFC, ATL, WTL, C#(WF);
• модули импорта-экспорта – C++, COM;
• визуализация – С++, COM, OpenGL;
• библиотеки материалов и прототипов – С++, COM, ATL, WTL;
• редактор моделей кораблей – C++, C#, COM.
Использование .Net носит «лоскутный» характер. Взаимодействие с такими компонентами
идет через COM.
3. Цели внедрения WPF
Исторически сложился проектный подход расширения функционала, в рамках которого
функционал, реализованный для одного заказчика, переносился в основную ветку.
Подобный «рваный» ритм разработки, без кардинальной переработки базовых компонент
системы с определенного момента стал тупиком.
Потребовалась переработка системы с максимально полным учетом требований разработки
под отдельные заказы. Главным требованием для системы является легкая расширяемость.
На момент начала разработки новой версии продукта существовал выбор между двумя
альтернативами: WPF и WF. От разработки интерфейса на С++ решили отказаться как от
устаревшей и бесперспективной.
Сошлись на том, что имея под собой одну основу (.Net) WPF позволит более эффективно
решить все наши проблемы:
• устаревший дизайн;
• падение скорости интеграции в UI функционала;
• ограничения в расширяемости ( .Net);
• отставание в технологиях.
Если судить по рекламе и циркулирующим в интернете примерам, WPF мог дать нам:
• переход на новейшие технологии;
• отделение программиста от разработки дизайна;

5. • дизайном занимаются дизайнеры;
• улучшение внешнего вида;
• повышение функциональности интерфейса с помощью сложных проблемно-
ориентированных компонент UI;
• ускорение разработки UI за счет использования Expression Blend;
• использование скинов.
Конечно, существовали риски, присущие любому новшеству, но плюсов было значительно
больше.
4. Возникшие трудности и способы их решения
Начальным этапом разработки стала поддержка использования .Net на уровне ядра системы.
Взаимодействие через COM интерфейсы решено было не использовать, в силу следующих
причин:
• большой объем сопутствующего кода, не связанного напрямую с функционалом;
• часть COM компонент требует написания Interop оберток, поддержка актуальности
которых довольно затратна;
• потери быстродействия при взаимодействии через COM;
• хочется максимально использовать поиск ошибок во время компиляции.
Было решено писать ядро продукта на Managed C++.
Интеграция C++ кода в данном случае перестает быть проблемой. Остаются только трудности
использования существующих COM объектов на уровне интерфейса. Для этого был написан
ряд managed оберток, через которые транслировались вызовы.
Таким способом удалось полностью изолировать C++ код и COM в ядре. Будущий интерфейс
мог общаться с ядром только через managed код.
Первично было решено реализовать UI на более знакомой технологии WF. С последующим, по
мере освоения WPF, замещением. Это давало возможность безболезненной замены WPF на
альтернативную технологию, если было бы решено отказаться от его использования.
Тестирование возможностей WPF было решено проводить на отдельной, полностью
независимой утилите – менеджере материалов.
Данная утилита является интерфейсной оберткой ряда COM объектов, что дает возможность
сосредоточиться только на написании UI.
Тестирование пригодности WPF было поручено программисту с опытом разработки под WF.
Считая WPF следующим этапом развития WF, он произвел разработку приложения в таком же
стиле, попутно используя возможности WPF для украшения интерфейса.

6. Дизайн программы был разработан дизайнером в графическом редакторе в виде набора
картинок.
Параллельно с программированием осуществлялось изучение WPF по книгам и статьям.
К концу разработки выяснились следующие моменты:
• Разработка интерфейса в стиле WF менее эффективна, чем на WF. Причиной является
большая сложность и ориентация на другой стиль разработки.
• Легкости модификации системы при внесении изменений, нет и в помине.
• Дизайн окон вручную съедает неоправданно много времени.
Не смотря на это, был получен довольно привлекательный дизайн, добиться которого
другими технологиями, за разумное время, было практически невозможно.
Было решено начать использование WPF в основном продукте.
Такое решение довольно безопасно, т.к. основной частью UI системы является множество
малосвязанных между собой окон редактирования свойств разнотипных объектов ( ~50
типов). Однако, требовалось внести изменения в процесс разработки исходя из предыдущего
опыта.
Было решено:
• Использовать Binding совместно с моделью Data-Model-View;
• Expression Blend в качестве редактора дизайна UI;
• Разделить обязанности между дизайнером и программистом: дизайнер рисует,
программист пишет код;
• Увеличить количество разработчиков UI до двух человек.
Скорость разработки UI упала до рекордной величины.
Причины были как организационного, так и технического характера.
1) Использование binding требует переосмысление архитектуры, и определения их места в
ней.
2) Повышение потенциальных возможностей UI вызвало множество корректур дизайна, на
этапе разработки.
3) Expression Blend как сложный инструмент требует времени освоения. Главным его
недостатком является замусоренность получающегося кода. Программист тратит
значительное время на чистку кода.
4) Разработка нескольких окон предполагает формирование библиотеки стилей и базового
функционала для всех окон.
5) Требуется переход на векторную графику, что ведет за собой полную или частичную
переработку ресурсов.

7. 6) Тонкости использования WPF.
7) Недоработки в самой библиотеке WPF. Проблемы хостинга WF компонент.
Последний пункт потребовал отдельного внимания, т.к. из-за него не удалось «по-простому»
подключить компонент предварительного просмотра 3D моделей.
Для предварительного просмотра моделей используется движок 3D визуализации. Для его
работы требуется handle окна, событие перерисовки, трансляция управления через ввод
пользователя. С такими ограничениями подключить визуализацию в окне WPF пока не
представляется возможным. Однако подключить его к элементу на WF, а сам элемент
интегрировать в окно на WPF – довольно тривиальная задача.
Данный подход был реализован и успешно работал до тех пор, пока в дизайне окна не
появилась прозрачность. С этого момента по неизвестной причине между WPF и
визуализацией началась драка за контекст окна. Единственным, пока, способом решения
данной проблемы является рисование в буфер и вывод результата работы визуализации как
обычной картинки.
5. Текущее положение вещей
В настоящее время разработка диалоговых окон поставлена практически на поток.
Организационными мероприятиями и накоплением базы типовых архитектурных решений
удалось разрешить большинство проблем.
Программисты и дизайнер приобрели практический опыт использования WPF. Библиотека
перестала быть «чужой», что как следствие сократило время поиска решений новых проблем.
Требования к архитектуре стали интуитивно понятны.
Оформление документально процесса разработки интерфейса позволило упорядочить поток
изменений, расходовавший значительный объем времени на переделки. Дело даже не в том,
что требования документа выполнялись буквально. Главное было достигнуто понимание
заинтересованными в разработке сторонами сути происходящих процессов, и цены внесения
модификаций на каждом этапе.
Экспериментально был найден баланс обязанностей между дизайнером и программистом.
Это позволило максимально использовать Expression Blend в разработке, без траты
значительного времени на подчистку мусора.
На базе нескольких первых окон создана библиотека стилей и компонент ускоряющая
разработку за счет повторного использования кода.
Сформулированы пожелания заказчика к оформлению интерфейса.
Найден баланс между переделкой растровых графических ресурсов в векторный формат.
Сформулированы ограничения использования растрового формата, выход за которые ведет к
переделке ресурса.
Все это позволяет утверждать, что мы перешли на использование WPF в нашем продукте.
К сожалению нельзя сказать, что мы решили все проблемы связанные с переходом.

8. В основном эти проблемы связаны с разработкой на начальных этапах внедрения библиотеки.
Требуется переработка архитектуры ряда диалоговых окон, разработанных на начальном
этапе. Менеджер материалов требует, чуть ли не полной переделки архитектуры.
Отдельным, до сих пор открытым, вопросом остается интеграция 3D визуализации в WPF.
Остается открытым вопрос о переводе всего приложения на WPF и полном отказе от
использования WF в UI.
Если сравнивать ожидаемый эффект от внедрения WPF и реально полученный, можно
утверждать: выполнены все ожидания, но с некоторыми оговорками.
Переход на новейшие технологии произведен, но не до конца. Больших проблем при
завершении перехода вроде не предвидится.
Отделение программиста от разработки дизайна, а дизайнера от программирования
выполнено в небольшом объеме. Это не означает, что такой подход к разработке утопия.
Скорее это вопрос квалификации дизайнера и совершенства инструментов разработки
дизайна. Expression Blend все более совершенствуется, и уже скоро перекроет функционалом
потребности разработчиков полностью. С обучением дизайнеров все гораздо сложнее,
требования к их компетенции довольно высоки.
Улучшение внешнего вида – однозначно да.
Повышение функциональности интерфейса с помощью сложных проблемно-ориентированных
компонент UI – да, но все-таки с некоторыми оговорками. Разработка сложного
специализированного компонента на WPF не создает особой сложности. Проблема скорее в
методологии проектирования. Просто разработать сложный, очень сложный UI компонент не
означает автоматического повышения юзабилити. Это сложный итерационный процесс, но не
имеющий к WPF особого отношения.
Скины на WPF получаются практически без усилий, нужно просто продублировать библиотеку
стилей и внести в копию изменения. До реализации скинов мы пока не добрались, но
проблем пока не предвидится.
Ускорение разработки UI тоже нельзя оценить однозначно.
Если сравнивать технологии между собой получаем примерно следующую картину:
WTL < MFC < WPF< WF
В данном случае сравнение WPF и WF несколько не корректно. Если убрать временные
затраты на разработку дизайна и стилей (считаем что дизайн есть, а стили надо просто
назначить) то получим скорость разработки:
• для окон средней сложности WPF= WF;
• для окон большой сложности WF < WPF
Самое главное – не нужно забывать, что при разработке UI на WPF большая часть времени
тратится именно на дизайн. Учитывая то, что WPF дает возможность получить результат

9. практически недостижимый другими технологиями, то время разработки отходит на второй
план.
6. Рекомендации
В конце я хочу попробовать дать рекомендации, основанные на опыте нашей разработки,
которые могли бы сократить потери времени:
1) Внедрять WPF должны программисты .Net (квалификация)
2) Внедрять должны минимум два программиста (совещательность)
3) Для одного из программистов желателен опыт работы WPF (центр кристаллизации
знаний)
4) Для дизайнера желателен опыт верстки HTML (подобие)
5) Структурируйте разработку UI с целью упорядочивания внесения изменений и понимания
остальными происходящего (экономия времени и нервов)
6) Начинайте разработку с простой задачи с акцентом на библиотеку стилей (задел в ширину)
7) Продолжайте разработку с самой сложной, но локальной задачи (задел архитектуры)
8) Помните – архитектура главное, остальное по нескольку раз меняется (акцент)