.NET: Записки программиста или хлопок одной ладони

Выпуск шестой: Visual Studio Team System 2005 или командная ролевая игра ...

"Как сообщают разработчики, всего доступных для игрока фракций будет три:
так называемая The Realm, включающая в себя людей, эльфов и гномов,
некие Кланы, состоящие из орков, троллей и варваров,
и, наконец, тот самый Союз - темные эльфы, горгульи и тени."
(Spell Force 2: Возьмите меня в волшебники)

Как всегда, введение

И снова доброе утро! Вобще-то сейчас вечер, но, учитывая что сегодня воскресенье, думаю что встретимся мы с вами все таки завтра утром.

Как мы и договаривались, сегодняшний выпуск будет посвящен возможностям, которые предоставляет клиентская часть Team System - различные редакции Visual Studio 2005. Сразу хочу извиниться за некоторые несерьезные названия и сравнения, уж слишком сильно работа с новой Visual Studio вначале напоминала мне игрушку - помните то ощущение, когда, затаив дыхание, Вы вскрывали коробку, полную занятных подарков и сюрпризов? Но могу пообещать, что не смотря на некоторую легкость, каждая фраза будет иметь смысл, какой бы несерьезной она бы не выглядела.

Итак, если Вы хотите принять участие в этой увлекательной игре, в первую очередь Вам нужно будет выбрать один из игровых серверов. Если Вы помните, в качестве сервера Team System использует Team Foundation Server - именно они поддерживают игры, к одной из которых Вам и предстоит присоединиться. Выбирая подходящий сервер учтите, что правила игры могут отличаться от сервера к серверу - по большей части они определяются тем шаблоном (process template), который был использован администрацией игры (игроками с правами Namespace Administrator) при ее создании.

После того как сервер выбран, необходимо определить, персонажа какой расы Вы собираетесь отигрывать. Разработчики реализовали поддержку четырех различных рас: Менеджеры проектов, Архитекторы, Разработчики и Тестировщики. Каждая из них обладает своими уникальными умениями и артефактами. Чтобы облегчить Ваш выбор, я постараюсь описать возможности и преимущества каждой из рас. Но какую бы расу Вы не выбрали, помните, что Team System прежде всего коллективная игра. Чем более удачно подобрана Ваша группа, тем быстрее Вам удасться продвигаться вперед, совершенствуя и прокачивая своего персонажа. Конечно, играя за расу Разработчиков, у Вас есть шансы выжить и потихоньку накапливать опыт. Отыгрывать Менеджера-одиночку, Архитектора или Тестировщика вобще не имеет смысла. И только объединив усилия игроков всех четырех рас Вы сможете добиться лучших результатов!

Итак, первая раса -  Архитекторы

Наверное, это самая спорная раса в игре. Почему?- спросите Вы. Архитектор безусловно нужен команде, он позволяет определить изначально правильный путь прохождения. Если у вас хороший Архитектор - Вам не прийдется проходить один и тот же уровень вновь и вновь, используя различные способы и приемы. Но! Его заклинания достаточно сложны для обучения и применения. Вы можете потратить день или два на их изучение, но применив их, получите несколько картинок и диаграмм - красивых, но и только. Реальной пользы команде от них не будет. Скорее всего Архитектор, потративший на изучение своих заклинаний достаточно много очков мастерства, сможет применять их с пользой для команды. Еще вероятнее, в больших командах, выполняющих серьезные задания, эти заклинания действительно будут очень полезны. Но если Вы столкнулись с ними впервые и Вам предстоит несложный уровень - возможно проще будет не тратить на них свои силы.

В первой настоящей игре с Team System мне пришлось отыгрывать сразу три роли в нашей команде: Менеджера проекта, Архитектора и Разработчика. Так вот, по впечатлениям: проще всего было освоиться с ролью Разработчика, все его умения и заклинания были очень полезны и просты для понимания. Мало того, частично они были взяти из других ролевых игр и AddIn-ов. Если названия ReSharper или FxCorp что-нибудь вам говорят - Вы быстро разберетесь с заклинаниями этой роли. Роль Менеджера проекта оказалась более сложной, но и более интересной. Заклинания у нее были принципиально новые, овладеть ими было легко, а вот научиться применять с пользой - гораздо труднее. Вначале они переосмысливались где-то раз в неделю и только на четвертой неделе игры у меня сложилось впечатление, что правильная последовательность все-таки найдена. Потенциально - это самая перспективная роль, переходя с уровня на уровень, заклинания Архитектора будут открывать Вам все новые и новые стороны, еще больше облегчая прохождение Вам и Вашей команде. Я не смогу поделиться большим опытом использования магии Архитекторов - для выполнения его миссии я почти не применял доступные ему заклинания, предпочитая то, чем овладел в совершенстве - бумагу и карандаш. Поэтому, давайте просто посмотрим, какие возможности предоставили ему разработчики ...

Архитектор проходит уровни, гордо восседая на белой лошади (магия Архитекторов носит кодовое название "Whitehorse" :). В его арсенале находится заклятие "Class Designer", а так же группа из четырех тесно связанных заклинаний под общим названием "Distributed System Designers":

• Application Diagram - отображает проект в виде взаимосвязанных клиентских приложений, а так же серверных частей - Web-сервисов, Web-приложений, баз данных и т.д.

• Logical Datacenter Diagram - отображают сервера, которые будут использоваться для хостинга компонент вашего проекта, описанных в Application Diagram. Под сервером тут подразумеваются как сервера, на которых расположены IIS или SQL Servers, так и компьютеры, на которых будут выполняться клиентские приложения.

• System Diagram - основана на Application Diagram. Вы не сможете добавить к ней новый компонент, но можете переопределить настройки для уже существующего, созданного в Application Diagram. System Diagram используются для того, чтобы задать различные конфигурации одного и того же Вашего проекта, например если это решение нужно проинсталлировать нескольким заказчикам с различной инфраструктурой серверов.

• Deployment Diagram - представляют собой привязку элементов Application\System Diagrams к элементам Logical Datacenter Diagram. То есть, к примеру, Logical Datacenter Diagram описывает сервера заказчика, их конфигурацию и настройки. System Diagram описывает компоненты Вашего проекта с настройками под этого заказчика. Deployment Diagram позволяет осуществить привязку компонент Вашего проекта (описанных в System Diagram) к серверам заказчика (описанным в Logical Datacenter Diagram). После этого Вы сможете применить заклятие "Validate Diagram", которое проверит, насколько настройки серверов совместимы с потребностями компонент проекта.

Рассмотрим использование этих заклинаний более подробно, на примере прохождения учебного уровня. Представим, что нам нужно разработать типичное трехуровневое приложени, состоящее из:

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

• Web Service - уровень, реализующий бизнес-логику проекта. Он расположен на сервере в локальной сети заказчика, но доступен извне.

• SQL Server - содержит базу данных нашего приложения, реализует логику работы с данными при помощи хранимых процедур, доступен только в пределах локальной сети.

Приступим к созданию нашего проекта, применив комбинацию заклятий "File -> New -> Other Project Types -> Blank Solution" (создание пустого Solution) и "New -> New Distributed System Diagram" (создание новой диаграммы, расположенно в контекстном меню закладки "Solution Explorer"). В диалоговом окне (Рис. 1) выбираем "Application Diagram".

Рис. 1

Теперь Вы можете собрать наш проект из кубиков, расположенных в Toolbox (Рис. 2), таких как "Windows application", "ASP.NET Web Service", "External Database" и т.д. Кроме того, мы должны использовать элементы типа "Endpoint" и "Connection" для того чтобы задать связи между нашими компонентами. Обратите внимание, что "Endpoint" бывают разных типов, например "Web Service Consumer Endpoint" - точка связи, при помощи которой клиентское приложение может связаться с Web Service или "Deployed Database Provider Endpoint" - точка связи, принадлежащая серверу баз данных, к которой могут быть привязаны клиенты. Для того чтобы не задумываться, какой тип "Endpoint" нам нужен, проще всего просто соеденить объекты элементом типа "Connection" - тогда "Endpoint" нужного типа добавяться к объектам автоматически. В нашем случае мы помещаем в дизайнере три объекта типа Application: WindowsApplication, ASP.NETWebService и ExternalDatabase, а так же соединяем их связями, получив диаграмму, показанную на Рис. 3. Рис. 3 Обратите внимание, что когда мы будем устанавливать связь между объектами WebService и SqlDatabase, нас попросят указать параметры соединения с базой.

Рис. 2

Так же, мы можем (в принципе мы не обязаны это делать, но иначе заклятие не сработает в полную силу) задать объектам  свойства, настройки и ограничения. Зачем это нужно? Дело в том, что большая часть графических средств, которые раньше использовали Архитекторы и Разработчики, имела один большой недостаток - они очень быстро устаревали. Если Вы когда-нибудь использовали продукты Rational (или другие, позволяющие работать с UML диаграммами), то наверное помните, что там Вам предоставлялось две возможности:

• разработать различные диаграмы (в первую очередь диаграммы классов), а потом сгенерировать по ним код

• воспользоваться заклинанием "Reverse Engenering", создав диаграммы по уже существующему коду

Мне никогда не удавалось пройти первым путем (да и вобще, я не знаю никого, кому бы это удалось, по крайней мере для Visual Studio C++, с которой я работал) - средства генерации  кода были слишком общие и не учитывали возможностей конкретной системы и это не смотря на то, что существовал специальный Rational Rose PlagIn для Visual Studio C++ (да и сейчас UML не может предоставить аналогов таким понятиям как "internal" или "events" в .NET Framework). Второй путь (формирование диаграмм на основе кода) был более полезен,  с его помощью действительно можно было создать диаграммы, описывающие приложение. Однако и у него была большая проблема - эти диаграммы сразу же начинали устаревать. Конечно, теоретически необходимо было постоянно обновлять их вслед за изменением кода, но ... я думаю Вы сталкивались с такими ситуациями и сами прекрасно знаете, чем они обычно заканчиваются.

Так вот, в Team System эти проблемы решены, красиво и очень удобно.

Во-первых, Team System умеет генерировать как классы, так и приложения в целом по созданным диаграммам. Поскольку они являются частью Visual Studio (а не общим универсальным форматом для всех языков), то позволяют использовать любые конструкции и понятия языков, поддерживаемых .NET RunTime.

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

Вернемся к нашим объектам. Мы остановились на их свойствах, настройках и ограничениях. Дело в том, что у Архитектора есть мощное заклятье "Implement Application ...", позволяющее создавать проекты, соответствующие объектам Application Diagram. То есть, если мы применим заклятие "Implement All Applicaitions ..." для нашей диаграммы, Visual Studio 2005 создаст в нашем Solution два проекта: Windows application и ASP.NET Web Service. Так вот, свойства этих объектов (закладка "Properties") как раз и определяют характеристики создаваемых приложений. Вы можете указать язык, на котором оно будет создано, значения аттрибутов сборки, такие как "AssemblyTitle" или "AssemblyCompany", название проекта (кстати, учтите, что название объекта, которое Вы указали на диаграмме, будет использовано как название создаваемого проекта - именно поэтому система не даст вам использовать в нем пробелы или знаки пунктуации). Параметры, заданные для объектов "Endpoint", так же будут использованы для генерации кода: в проект Windows Application будет включена ссылка (Web reference) на используемый им Web Service, а в конфигурационный файл ASP.NET Web Service будет добавлен параметр, содержащий заданную строку соединения.

Настройки и ограничения нужны для другой цели. Они позволяют задать характеристики самого приложения и среды выполнения, которые необходимы приложению для нормальной работы. Например, Вы можете указать, что для выполнения приложения необходима версия .NET RunTime 2.0 или, что оно предназначено для выполнения только под Windows 2003. В дальнейшем, когда Вы создадите Deployment Diagram, у вас появиться заклятие "Validate Diagram", позволяющее определить, совместимы ли настройки и ограничения распространяемых (deployed) модулей с ограничениями и настройками серверов (которые Вы указываете на Logical Datacenter Diagram). В случае несоответствий, в окне Errors вы увидете сообщения об ошибках или предупреждения (совсем как при компиляции проекта). Об этом мы поговорим чуть подробнее немного позже, когда будем рассматривать остальные типы диаграмм.

Уф-ф, уже поздно и Шахерезаде пора заканчивать свои дозволенные речи. Так что до следующего выпуска, в котором мы продолжим рассматривать заклинания, доступные самым сложным и непонятным героям - расе Архитекторов.

Удачи и приятной работы!