Рабочее место архитектора проекта, основные функции и возможности, связь с разработчиками проекта

Сущность и роль архитектора в разработке программного обеспечения

Архитектор — это член команды, который формирует структуру системы, будь то сеть, центр данных или прикладной программный комплекс. Архитектор обязательно должен быть экспертом в вопросах поддержки, функционирования, совместимости и защищенности продукта, поскольку результаты его работы отражаются на всех перечисленных областях. Кроме того, он должен уметь представить систему с использованием нотации, понятной всем пользователям его проектов – менеджеру, разработчикам, заказчику [1].

В последнее время средства проектирования архитектуры, разработанные в 1980-90-х годах и используемые сейчас, не удовлетворяют потребностям пользователей [1]. Если модель давала возможность генерировать код, то при внесении в него разработчиком изменений он переставал соответствовать модели архитектора, и модель становилась непригодной для базирования кода и подготовки документации по проекту. Модели, способные производить обратную конвертацию кода в модель, являются слишком сложными - генерируется огромный объем кода, и задача соединения кода, сгенерированного и написанного вручную, еще более усложняется. Очевидно, что если CASE -модели не соответствуют программному коду и другим артефактам реализации, применять их никто не станет.

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

Роль архитектора в среде VSTS

Создатели Team System сумели добиться того, что моделирование стало неотъемлемой частью общего процесса разработки. Теперь программистам стало возможным сосредоточиться на написании нестандартного кода, определяемого требованиями конкретного приложения. Реализация шаблонных частей программы стала возможной при помощи внедрения кода, генерируемого средством проектирования.

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

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

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

В Microsoft Visual Studio 2005 Team System определены две роли архитекторов: архитектор инфраструктуры, и архитектор приложений. В команде обе эти роли может выполнять один человек, но в Team System предусмотрена возможность разделения соответствующих функций. Любая роль архитектора обслуживается одним изданием — Visual Studio 2005 Team Edition for Software Architects.

Архитектор инфраструктуры

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

Хотя модели инфраструктуры не связаны непосредственно с разработкой программного обеспечения, от них в значительной мере зависит успех приложения: его необходимо проверить на соответствие указанным ограничениям, дабы убедиться, что это приложение будет должным образом функционировать в целевом окружении. Такая стратегия называется проектированием с учетом последующего развертывания (design for deployment).

Для моделирования среды развертывания архитектор инфраструктуры (который привлекает к этой работе и специалистов из отдела эксплуатации), использует конструктор логического центра данных. Но сначала он должен составить себе четкое представление о целевом центре данных, в частности получить сведения о:

• типах хостов приложений (веб-сервер, сервер базы данных, произвольный сервер);
• версиях операционной системы и .NET на каждом сервере;
• наличии брандмауэров и ограничений коммуникационного потока между серверами ( HTTP, TDS, универсальный сервер);
• входном и выходном протоколах каждого сервера и зоны;
• любых ограничениях, связанных с отдельными серверами и зонами.

Архитектор приложений

Архитектор приложений проектирует взаимосвязанные системы приложений, которые в результирующей системе будут представлены как комплексы взаимосвязанных веб-сервисов, веб-приложений, приложений Microsoft Windows, внешних баз данных и прочих компонентов.

Прежде чем приступить к проектированию, архитектор приложений должен составить себе общее представление о таких параметрах архитектуры будущей системы, как:

• количество и типы приложений (веб-сервисов, приложений баз данных, Windows -приложений);
• версии операционных систем и .NET ;
• ограничения коммуникационных потоков между сервисами ( HTTP, TDS и прочих);
• другие параметры всех сервисов и зон (включая пользовательские).

Конструктор распределенных систем

Конструкторы распределенных систем — это инструменты проектирования, входящие в состав Visual Studio 2008 Team System Edition for Software Architects и предназначенные для понижения степени сложности процесса разработки и развертывания сервисно-ориентированных приложений.

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

Конструктор логического центра данных (Logical Data-center Designer). Здесь создаются диаграммы взаимосвязанных хостов приложений. Все вместе взятые представления эти хостов и их соединений составляют логический центр данных. В его диаграмме архитектор отражает те аспекты хост-среды, которые так или иначе влияют на конфигурацию приложений.

Конструктор приложений (Application Designer). Этот конструктор позволяет разработчикам и архитекторам определять приложения, которые затем будут объединены в системы.

Конструктор систем (System Designer). Здесь производится объединение приложений в системы для облегчения развертывания продукта и повторного использования кода.

Конструктор развертывания (Deployment Designer). Данный конструктор используется последним: в нем путем привязки приложений к логическим серверам формируется схема развертывания продукта или отдельной его системы в логическом центре данных.

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