Продолжается подписка на наши издания! Вы не забыли подписаться?

Моделирование в Visual Studio 2005 Team System – часто задаваемые вопросы

Опубликовано: 26.02.2006

Зачем нужно моделирование?

По заявлениям пользователей, многие из CASE-средств, приобретенных в 80-х и начале 90-х, не слишком помогли процессу разработки. Выгоды, которые они обещали, так и не материализовались, и даже хорошие продукты были скомпрометированы завышенными обещаниями технологии.

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

Несмотря на все это, жива еще надежда, что моделирование как-нибудь можно использовать для упрощения жизни программистов. Наше видение этого таково – нужно изменить восприятие ценности моделирования программистами. Нужно изменить восприятие моделирования как минимально полезной деятельности, предшествующей реальной разработке, на важную первостепенную задачу разработки, вовсе не сосредоточенную в первую очереди на документировании. Если модели рассматриваются как первоклассные артефакты разработки, разработчики пишут менее традиционный код, поскольку могут задействовать более мощные абстракции приложения. Поэтому разработка, управляемая моделью (model-driven development, MDD), быстрее и продуктивнее. Более того, остальные участники процесса разработки, от бизнес-аналитиков, архитекторов, дизайнеров до сетевиков и системных администраторов, будут рассматривать моделирование как ценную возможность для их предметной области.

Такойподход к MDD – это часть инициативы, получившей в Microsoft название Software Factories.

Как DSL используется в MDD?

Microsoft извлек уроки из опыта индустрии, и планирует избежать подводных камней CASE, основывая свой подход к MDD на следующем:

Языки моделирования мы называем языками предметной области (Domain Specific Languages или DSL). DSL можно рассматривать, как небольшой язык, сфокусированный на решении некоторых четко формулируемых проблем, с которыми сталкивается аналитик, архитектор, разработчик, тестер или системный администратор. Разработчикам уже известны примеры DSL: SQL для работы с данными, XSD для определения схем XML-документов и так далее. Другим примером из Visual Studio Team Edition for Software Architects может служить DSL для моделирования логической структуры оборудования центров данных и конфигурирования ПО хостов. Этот DSL и связанный с ним графический дизайнер могут использоваться в процессе разработки для проверки того, что приложения сконфигурированы соответственно целевым устройствам, и для заблаговременного решения возможных проблем.

Хорошие способы найти кандидата в DSL – определить паттерны, используемые разработчиками, а затем инкапсулировать их в язык моделирования, или вывести концепции программного фреймворка как абстракции языка моделирования, который затем сможет генерировать небольшие объемы кода, расширяющие этот фреймворк. Эти методики позволяют управлять количеством и сложностью генерируемого кода, предлагая разработчикам реальную ценность без трудностей, характерных для CASE-средств.

Microsoft недавно объявила о выходе DSL Tools, которые позволят покупателям и партнерам создавать DSL, используя в Visual Studio 2005 ту же технологию, что используется для создания средств моделирования, которые будут поставляться с Visual Studio Team Edition for Software Architects. Эта технология, которую можно назвать "инструментом для создания инструментов", упрощает определение DSL и снижает объем работы и навыков, нужных для создания графических редакторов и компиляторов для этих языков.

Как насчет UML?

Многие, читавшие наши рассуждения о MDD, предполагают, что наш акцент на DSL как-то ставит нас в анти-UML позицию. Нужно сказать, что это не так. До UML царило непродуктивное разнообразие подходов к моделированию, и их конвергенция в UML 1.0 была существенным шагом вперед в использовании моделей при разработке ПО.

Но, независимо от причин, наличие UML и основанных на нем средств несущественно изменило способы создания приложений разработчиками. Не слишком повлияло это и на продуктивность разработки. Поскольку Microsoft выпускает одно из наиболее используемых UML-средств – основанный на Visio инструмент, появившийся в поставке Visual Studio Enterprise Architect – мы анонимно исследовали использование таких инструментов разработчиками (не только наших клиентами). Мы обнаружили, что очень немногие заявляют об использовании UML-средств в процессе работы, и это использование в основном сводится к диаграммам классов. Когда же мы стали опрашивать тех, кто использовал диаграммы классов, обнаружилось, что совсем мало тех, кто реально применяет их для генерации кода.

Это была одна из движущих сил в создании MDD-средств в Visual Studio Team Edition for Software Architects. Мы хотели взять задачи, которые разработчики и архитекторы находят трудными, и найти пути, которыми моделирование инструментальных средств могло помочь им. Мы с энтузиазмом поддерживаем UML-нотацию и диаграммы. Если пройтись по любому коридору в Microsoft, встретишь немало досок, исписанных UML-диаграммами классов и последовательностей. Мы используем UML-нотацию в спецификациях и многих других диаграммах для презентаций или в скетчах, набросанных на салфетках в кафетериях. Чтобы удовлетворять потребности наших клиентов по созданию документации и концептуальных эскизов, мы продолжим поставки комплекта UML-средств с Visual Studio 2005. Фактически, в Microsoft мы используем UML во многих целях, типа документации или совместного использования концептуальных идей, но почти никогда там, где документы – это реальные артефакты разработки программного обеспечения.

Упомянутые доски в коридорах и офисах также исписаны корявым кодом. Но, опять же, это наброски, а не законченный компилируемый исходный текст. Для разработчиков это разные вещи. Любой артефакт, участвующий в реальной разработке ПО, должен обрабатываться в цифровой форме. Исходные тексты имеют хорошо определенный синтаксис и понятную семантику – часто определяемую поведенчески ее трансформацией компилятором в код более низкого уровня или IL – и могут обрабатываться компиляторами, отладчиками, программами для рефакторинга и т.д. Чтобы быть полезной разработчикам, модель должна иметь тот же статус, что и исходный код. Она также должна иметь точный синтаксис, понятную семантику и хорошо определенное отображение на исходный код или другие модели. Она должна быть большим, чем просто документация.

Возьмем, к примеру, Visual Studio Team Edition for Software Architects' Application Designer. Это не просто документация, хотя может служить и в этих целях. Он, скорее, позволяет разработчику (или архитектору) сосредоточиться на одном аспекте системы – связям между сервисами в основанной на сервисах архитектуре. Разработчик может проработать этот аспект до создания проектов, WSDL-файлов, кода и схем, или заставить средство документировать связи между сервисами, если эти артефакты уже существуют. Поскольку информация о связях рассредоточена по множеству артефактов разработки, целостный взгляд, предоставляемый диаграммой, весьма полезен, несмотря на то, что вся содержащаяся в ней информация может быть получена тщательным изучением артефактов реализации. Application Designer (его метамодель) имеет хорошо проработанный синтаксис и предсказуемое, всегда синхронизированное отображение на различные артефакты реализации. Нижележащий фреймворк играет роль компилятора диаграмм Application Designer, очень похожую на роль, которую традиционный компилятор играет для файлов с исходным кодом.

Но почему мы не создали просто новый "язык" для связей между сервисами как расширение UML – особенно учитывая усовершенствования в UML 2.0?

Что ж, когда мы посмотрели на UML 2.0...

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

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

Copyright © 1994-2016 ООО "К-Пресс"