Your SlideShare is downloading. ×
внедрении Wpf в сложных системах
внедрении Wpf в сложных системах
внедрении Wpf в сложных системах
внедрении Wpf в сложных системах
внедрении Wpf в сложных системах
внедрении Wpf в сложных системах
внедрении Wpf в сложных системах
внедрении Wpf в сложных системах
внедрении Wpf в сложных системах
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

внедрении Wpf в сложных системах

1,403

Published on

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

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

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,403
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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) Помните – архитектура главное, остальное по нескольку раз меняется (акцент)

×