Рабочее место архитектора проекта, основные функции и возможности, связь с разработчиками проекта
Параметры и ограничения
Любой элемент диаграмм проектирования имеет набор свойств, которые представляют собой основные настройки, такие как имя элемента, язык программирования данного элемента, пространство имен классов, используемых в элементе, версия элемента и т.д.
Для большинства типов помещаемых в диаграммы хостов и приложений помимо свойств можно настраивать параметры и ограничения. Ограничениями называют требования, которые должны соблюдаться при развертывании. Например, можно задать для приложения ограничение, определяющее, на какой логический сервер его разрешено устанавливать. На серверы также можно налагать ограничения, позволяющие максимально точно отразить действующие в центре данных политики. В частности, такими ограничениями могут предписываться или, наоборот, запрещаться какие-то типы взаимодействия, задаваться те или иные аспекты защиты, исключаться из употребления конкретные типы приложений.
В Team System определено три базовых типа ограничений.
- Неявное. Назначается элементу по умолчанию. Например, для серверов IIS разрешены только заданные расширения имен файлов. Если удалить из таблицы веб-сервера расширение файлов сценариев .soap, соответствующий веб-сервис, связанный с этим сайтом, перестанет поддерживаться. Неявные ограничения можно считать встроенными, поскольку для их активизации вмешательство пользователя не требуется. Еще одним примером такого ограничения является защита приложений ASP.NET, устанавливаемая с целью сделать их совместимыми с установками IIS.
- Предопределенное. Задается путем выбора из предлагаемых конструктором вариантов. Примером может служить ограничение, согласно которому приложение ASP.NET устанавливается только на конкретном хосте.
- Определяемое пользователем. Создается путем настройки одного или нескольких параметров, значения которых и составляют ограничение.
По ограничениям логического сервера нередко судят о его возможностях. Посредством предопределенных ограничений можно задавать версии используемого на сервере программного обеспечения операционной системы и .NET Framework. Вы можете задать ограничения, запрещающие устанавливать на сервер приложения определенных типов, или же указать, что инсталлируемое приложение должно обладать заданными характеристиками (скажем, при управлении ролями и членством для приложения ASP.NET обязательно должен использоваться провайдер SqlProvider ). Все это важно с точки зрения документирования, причем как для членов команды, так и для конструкторов Team System. В частности, информация об ограничениях необходима архитекторам, разработчикам и ИТ-профессионалам, отвечающим за развертывание приложений. Для двух последних ролей архитектор при помощи ограничений задает единственно возможные варианты разработки приложения и инфраструктуры. Если же вариантов должно быть нескол ько, то архитектор создает соответственно несколько вариантов системы. Язык программирования, настройки безопасности, строка соединения с базой данных, установки в файле web.config и другие настройки устанавливаются архитектором (нередко единожды) и доставляются до следующего этапа разработки в виде предопределенных настроек, недоступных для изменения. Изменить их можно лишь при согласовании с архитектором.
Для определения атрибутов различных элементов диаграмм используется редактор параметров и ограничений (Settings and Constraints Editor). Обычно оно расположено у нижней границы конструктора, но если это не так, его можно вывести на экран с помощью соответствующей команды контекстного меню любого элемента диаграммы.
Безопасность
Конструкторы распределенных систем позволяют проектировать архитектуру продукта в рамках требуемой модели безопасности, причем поддерживается целый ряд таких моделей, причем не только от Microsoft. К их числу относятся и две следующие:
- Internet Information Server (IIS) Security;
- ASP.NET Security.
Кроме того, для каждого соответствия между хостом и сервисом Team System позволяет определять так называемые предварительные ограничения сборки (pre-built constraints). Подобное ограничение может, например, гарантировать, что компонент приложения, требующий аутентификации в Windows, будет устанавливаться только на IIS -сервер, поддерживающий данный вид аутентификации. Можно также определить пользовательские ограничения и установки, отвечающие требованиям, которые выдвигаются к безопасности на данном предприятии. Все заданные ограничения, как стандартные, так и пользовательские, однозначно определяют задание для разработчика, и могут быть проверены конструкторами распределенных систем.
Реализация классов
Реализация класса означает его разработку. Веб-сервис реализует разработчик, хотя проектирует его архитектор приложений.
В указанной системе существует особая функция реализации, которую использует архитектор, поскольку она доступна только в Team Edition for Software Architects – Implement (Реализовать) при выполнении которой Team System генерирует код заглушки.
Этого достаточно для того, чтобы архитектор приложения мог бегло просмотреть результаты, сменить некоторые пространства имен, добавить ссылки на кое-какие готовые сборки, ввести комментарий, сохранить код в системе управления версиями и передать его разработчикам.
Этот код помещается в систему управления версиями и создается один или несколько рабочих элементов "задача", видимая как на портале проекта, так и через Team Explorer. Таким образом, разработчики узнают, что заготовки кода созданы, и можно приступать к реализации.
Но, прежде чем выполнить команду реализации, архитектор приложений должен ввести некоторую информацию о приложениях и сервисах, поскольку некоторые его свойства, не подлежат изменению:
- используемое по умолчанию пространство имен класса;
- язык;
- имя;
- проект (местоположение);
- шаблон.
Реализуя приложение, Team System кроме его каркаса создаст SDM -документ и свяжет его с новым проектом Visual Studio. В этом документе, который будет сохранен на диске в отдельном файле, описывается веб-приложение ASP.NET и содержатся сведения из диаграммы приложений.