Механизм реализации атрибутов качества в архитектуре Luther

Все, кроме одного, требования по качеству предъявлены к архитектуре Luther заказчиками — они касаются беспроводного доступа, гибкости пользователь­ских интерфейсов и устройств, поддержки существующих процедур, бизнес- процессов и систем и распределенных вычислений. Сотрудники Inmedius сформулировали единственное требование — об удобстве конструирования приложений.

Задача	Стратегия	Тактики
Беспроводной	Применение стандартных беспроводных	Применение предписанных
доступ	протоколов	протоколов
Гибкий поль-­	Поддержка средствами HTTP интерфейсов	Семантическая связность;
зовательский	на основе браузера и специальных	отделение пользовательского
интерфейс	интерфейсов	интерфейса; пользовательская модель
Поддержка	Применение стандартных протоколов	Прогнозирование ожидаемых
разнородных		изменений
устройств
Интеграция с	Применение в качестве механизма	Общие абстрактные службы;
традиционными	интеграции спецификации J2EE	замена компонента
бизнес-
процессами
Оперативное	Базирование Luther на J2EE и конструиро­-	Общие абстрактные службы;
конструирование	вание повторно используемых компонентов обобщение модуля (в роли
приложений		обобщенного модуля в данном случае выступает J2EE)
Распределенная	Применение J2EE и стандартных	Обобщение модуля;
инфраструктура	протоколов_______________________	регистрация в период прогона

Относительно реализации этих требований было принято фундаментальное решение о применении архитектуры J2EE. Впрочем, задействовать ее предпола­галось строго определенным образом — четко и точно отделить пользовательский интерфейс от приложений, стараться придерживаться стандартов и по возмож­ности сформировать библиотеку повторно используемых компонентов. Страте­гии и тактики, применявшиеся для достижения поставленных задач, перечислены н табл. 17.1.

17.5. Заключение

Компания Inmedius специализируется на разработке решений для рабочих, об­служивающих технику на местах ее дислокации. Они выставляют к этим реше­ниям требования по высокой мобильности и легкому доступу к компьютерам. Что касается собственно компьютеров, то они обычно обладают высокой перено­симостью, а иногда даже предусматривают работу в бесконтактном режиме. Как бы то ни было, системы эти требуют интеграции с конторскими операциями.

Сконструированная в компании Inmedius архитектура Luther направлена на оперативное конструирование систем обслуживания заказчиков. Основывается она на спецификации J2EE. Значительное внимание разработчики уделили со­зданию повторно используемых компонентов и каркасов, которые упрощают введе­ние новых элементов. Пользовательский интерфейс спроектирован в расчете на удовлетворение потребностей заказчиков и создание решений на основе браузера.

Зависимость от J2EE, с одной стороны, стимулировала развитие коммерче­ских задач Inmedius, а с другой — обусловила необходимость в принятии допол­нительных проектных решений, связанных с пакетированием в виде тех или иных типов beans. В этом мы усматриваем пример обратного воздействия архитектур­но-экономического цикла, акцентирующего переход от единичных решений к уни­версальным решениям.

17.6. Дополнительная литература

Читателям, желающим подробнее изучить переносные компьютеры, мы рекомен­дуем ознакомиться с изданием [Barfield 01] и сдокладами на организуемом Институтом программной инженерии (SEI) ежегодном Международном симпозиу­ме по переносным компьютерам (http://iswc.gatech.edu/).

Описание применяемого в архитектуре Luther образца «бизнес-делегат» со­держится n работе [Alur 01]. О деятельности группы rio технологическому управ­лению (Workflow Management Coalition) можно узнать на сайте этой организа­ции по адресу http://www.wfmc.org

17.7. Дискуссионные вопросы

1. В большинстве рассматриваемых в этой книге конкретных примеров архи­тектура предусматривает отделение производителей данных в системе от их потребителей. Почему это так важно? Что можно сказать об этой такти­ке? Составьте список тактик или методик проектирования, с помощью ко­торых осуществляется такое разделение; начните с тех, что упоминаются в настоящей главе.

2. В архитектуре Luther и в других конкретных примерах серьезное внимание уделяется отделению пользовательского интерфейса от остальных элемен­тов приложения. С чем, по вашему мнению, связана чрезвычайная распро­страненность этой тактики?

Глава 18

Конструирование систем из коробочных компонентов

(в соавторстве с Робертом С. Сикордом и Мэтью Бассом) ^[10]

На блюде все это смотрится так красиво — чьи-то пальчики основательно потрудились!

Джулия Чайлд о повой французской кухне

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

Начиная с 1960-х годов принятие многих проектных решений в значительной степени зависит от конкретной операционной системы. Системы управления ба­зами данных сформировались как фактор влияния в начале 1970-x. Повсемест­ное распространение компьютеров привело к повышению возможностей исполь­зования для реализации системных задач компонентов, разработанных третьей стороной. Само по себе наличие компонентов не является принудительным стимулом к их использованию (и этом контексте см. врезку «Quack.com»), что, од­нако, не сокращает потребность в изучении механизмов их внедрения в систему Процесс отбора коробочных компонентов для системы предполагает поиск сборок (assemblies) совместимых компонентов, формулирование механизма реа­лизации с их помощью атрибутов качества и принятие решений относительно возможности их интеграции в конструируемую систему.

QUACK.COM

Дата добавления: 2015-04-25