Требования и атрибуты качества. Принципы коммерческой деятельности

Принципы коммерческой деятельности

Опыт разработчиков программного обеспечения

Еще до начала работы над архитектурой Luther в компании Inmedius работали опытные и квалифицированные разработчики программных продуктов. Тем не менее, когда речь зашла о создании Luther, им пришлось приспособиться к ряду новых критериев, в частности:

♦ изучить язык программирования Java;

♦ получить сертификаты Sun Java Programmer;

♦ изучить архитектуру приложений J2EE;

♦ изучить механизмы пакетирования возможностей в рамках спецификаций J2EE и EJB;

♦ научиться пользоваться Java-сервлетами и JavaServer Pages;

♦ обучиться применению различных cлyжб J2EE, предусмотренных в реали­зации этой спецификации.

Архитектура Luther оказала на ведение компанией Inmedius коммерческой деятельности очень заметное влияние. Как мы уже говорили (см. главу 14), для разработки единичных решений требуются обширные ресурсы. Неоптимальное расходование ресурсов и ограниченное восприятие, характерные для процесса разработки единичных систем, препятствуют складыванию глобального мышле­ния. Переход к линейке продуктов на основе архитектуры Luther позволил ком­пании Inmedius сосредоточиться на построении линеек, отказавшись от ориента­ции на индивидуальные системы. Более того, равно как и в случае с CelsiusTech, Inmedius удалось выйти на новые рынки, которые оказались своеобразным обоб­щением — как в коммерческом, так и в техническом смысле — тех сегментов рынка, на которых компания присутствовала ранее.

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

Обобщенно, требования можно разделить на шесть категорий:

♦ беспроводной доступ;

♦ пользовательский интерфейс;

♦ типы устройств;

♦ существующие процедуры, бизнес-процессы и системы;

♦ конструирование приложений;

♦ распределенные вычисления.

Беспроводной доступ

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

Пользовательский интерфейс

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

Разнообразие устройств

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

♦ персональных информационных устройств (personal data assistant, PDA): Palm Pilot, Handspring Visor, vTech Helio, IBM WorkPad, Apple’s Ne\vton и MessagePad 2000;

♦ карманных компьютеров (Pocket PC) наподобие Compaq iPAQ, Casio EM500, HP Jornada и Phillips Nino;

♦ ручных перьевых планшетов на основе операционной системы Windows СЕ: Fujitsu Stylistic, PenCentra и Siemens SIMpad SL4;

♦ ручных компыотеров на основе Windows СЕ с пером и клавиатурой: Vadem Clio, IIP Jornada 700 series, NEC MobilePro, Intermec 6651 Pen Tablet Computer, Melard Sidearm и др.;

♦ переносных компьютеров наподобие Xybcrnaut MA-IV, семейства продук­тов Via и устройства Spot от компании Pittsburgh Digital Greenhouse.

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

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

Существующие процедуры, бизнес-процессы и системы

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

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

Конструирование приложений

Стремление к ускорению процесса конструирования приложений было одной из основных предпосылок к созданию архитектуры Luther. Эта задача состоит из нескольких аспектов, включая следующие:

♦ Поощрение повторного использования программных продуктов и упроще­ние взаимодействия приложений. Эти аспекты позволяют экономить огра­ниченные ресурсы и не изобретать колесо заново.

♦ Внедрение в корпоративные функции (например, в последовательность технологических операций) стратегии «лучше построить, чем покупать».

♦ Предоставление стабильной платформы для внедрения новых характерис­тик и инновационных технологий в масштабах приложений — в частности,

♦ механизма определения местоположения (location sensing), автоматического обнаружения и идентификации близлежащих физических объектов и служб, усложненных характеристик пользовательского интерфейса наподобие син­тетических опросов.

Распределенные вычисления

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

♦ Масштабируемость. Серверный каркас Luther обеспечивает масштабируе­мость, не оказывая при этом негативного воздействия на производитель­ность. Иначе говоря, введение предметно-ориентированных компонентов, вне зависимости от их количества, никоим образом не влияет на произво­дительность прикладных приложений и не приводит к необходимости ре­конструкции клиентских приложений. Кроме того, от клиентских прило­жений требуется удобство реконфигурирования, направленного на освоение новых возможностей. Каркас позволяет приложениям обнаруживать но­вые возможности и путем динамической автореконфигурации вводить их в действие.

♦ Выравнивание нагрузки. В распределенной среде архитектура Luther обес­печивает выравнивание нагрузки. Большая часть вычислительных опера­ций в приложениях на ее основе выполняется на стороне сервера, после чего результаты отправляются клиентам. Если клиентских обращений к кон­кретному серверу становится слишком много, инфраструктура сервера при­ложений обнаруживает увеличение нагрузки и переводит операции обра­ботки на компоненты сервера приложений, расположенные на других серверных узлах предприятия. Корпоративная среда приложений анало­гичным образом обнаруживает отказы узлов и с целью возобновления ис­полнения переводит операции в другие приложения. Выравнивание нагрузки в обоих случаях должно проходить незаметно для пользователя. В первом случае также требуется прозрачность операции по отношению к клиент­скому приложению.

♦ Независимость от местоположения. Для того чтобы выравнивание нагруз­ки стало возможным, требуется распределение предметно-ориентированных прикладных средств. Инструменты, направленные на реализацию этой задачи, заложены в архитектуре Luther. Для динамического изменения местоположения приложения должны быть независимыми от него.

♦ Переносимость. Среды корпоративных приложений, по определению, со­держат в своем составе разнородные серверные аппаратные платформы. Каркас архитектуры Luther предусматривает исполнение программных средств на самых разных платформах, обеспечивая тем самым работоспо­собность корпоративных приложений.

17.3. Архитектурное решение

В ответ на предъявленные требования было принято принципиальное архитек­турное решение, согласно которому архитектуру Luther следовало сконструиро­вать поверх архитектуры J2EE. У этого решения есть ряд преимуществ.

♦ Архитектура J2EE существует во множестве коммерческих версий от раз­ных производителей. Компоненты, которые потенциально могли оказаться полезными для архитектуры Luther, разрабатывались повсеместно (в част­ности, речь идет о компонентах технологического управления).

♦ Протокол HTTP, расположенный на верхнем уровне стека TCP/IP, стано­вился основным средством передачи данных. Сам же стек TCP/IP поддер­живался различными коммерческими беспроводными стандартами, в том числе IEEE 802.11b. В рамках инфраструктуры беспроводной локальной сети любого веб-клиента можно сделать мобильным. Кроме того, большин­ство устройств, которые архитектура Luther должна была поддерживать, в свою очередь поддерживают HTTP.

♦ Принятое решение предусматривает отделение пользовательского интер­фейса и позволяет реализовать парадигму пользовательского опыта (user experience paradigm). Парадигма эта предполагает, что компьютер станет для рабочего одним из инструментов, причем инструмент этот будет но­сить ненавязчивый характер. Компьютер, согласно упомянутой парадигме, должен стать естественным расширением инструментов рабочего. При этом он приносит выгоды по части производительности — как самому рабочему, так и компании, в которой тот работает.

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

К примеру, если клавиатурный ввод в конкретном случае не подходит, его можно заменить речевым вводом. Если условия работы слишком шумные, имеет смысл обратиться к специализированному устройству ввода — на­пример, диску управления (dial). Поворачивая диск (который закрепляется на униформе рабочего — см. рис. 17.2), пользователь переходит по ссыл­кам, нажимает кнопки, выбирает положения переключателей и манипулирует другими средствами пользовательского интерфейса, предусмотренными в клиентском приложении, тем самым активизируя их. В средней части диска находится клавиша Enter, предназначенная для нажатия кнопок, пе­реходу по ссылкам и тому подобных действий. Диск применяется и в са­мых трудных условиях — с ним можно работать даже и толстых перчатках.

В главе 5 мы рассматривали тактику реализации практичности под назва­нием «отделение пользовательского интерфейса». В рамках архитектуры Luther эта тактика обеспечивает гибкость, позволяющую менять пользова­тельский интерфейс, адаптировать его к различным устройствам и потреб­ностям. Здесь, между прочим, проявляется другой атрибут качества — мо­дифицируемость. Это очередное подтверждение нашего постулата о том, что некоторые тактики позволяют реализовывать сразу несколько атрибу­тов качества.

♦ Рассматриваемое решение позволяет разделять и абстрагировать источни­ки данных. В зависимости от конкретной ситуации использования устрой­ства пользователю могут потребоваться фильтрация, объединение, синтез и отображение данных, исходящих из разнородных источников. Среди этих источников — системы управления базами данных, а также унаследован­ные приложения, сконструированные на основе корпоративных систем планирования ресурсов с инкапсуляцией корпоративных данных. Сотруд­ники Inmedius поняли, что при условии абстрагирования и отделения ис­точников данных от приложений, которые к ним обращаются, а также при предоставлении для них четко очерченных стандартных интерфейсов при­ложения гарантированно придерживаются заданных абстракций и, таким образом, предусматривают возможность повторного использования. Кроме того, некоторые интерфейсы приняты в качестве стандартных (к таким интерфейсам, в частности, относится JDBC/ODBC). Они позволяют трак­товать источники данных как абстрактные компоненты, которые при жела­нии можно ввести или извлечь из корпоративного приложения.

Рис. 17.3. Представление размещения приложения Luther

На рис. 17.3 изображена схема взаимодействия приложения Luther со средой (элементы J2EE на ней не показаны — отображение приложения на J2EE мы еще обсудим). Во-первых, обратите внимание на отношение (n:1:m) между пользова­тельскими интерфейсами, приложениями и тем, что сотрудники Inmedius назы­вают компонентами, — иначе говоря, стандартными блоками конструирования функциональности приложения. Приложение Luther является топким; значитель­ная часть его бизнес-логики собрана из существующих компонентой и не привязана к какому-либо конкретному пользовательскому интерфейсу. Обобщенно, прикладной код состоит из следующих элементов:

♦ определение состояния сеанса и управление этим состоянием;

♦ прикладная (то есть не предусматривающая повторного использования) бизнес-логика;

♦ логика, которая делегирует бизнес-запросы соответствующей последова­тельности вызовов компонентных методов.

В этом приложении нет основного метода — зато в нем есть интерфейс при­кладного программирования (application programming interface, AP1), выражающий характеристики и функции, которые приложение представляет пользовательс­ким интерфейсам. Пользовательский интерфейс независим от приложения. Он может включать любое подмножество характеристик, применимое к целевому интерфейсу устройства. К примеру, при создании интерфейса для устройства с микрофоном и динамиками, но без дисплея, интерфейс не предлагает средств графики.

Теперь попробуем провести углубленный анализ трех основных элементов, показанных на рис. 17.3: пользовательского интерфейса, приложения и компо­нентов.

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