Динамическая конфигурация


Прежде всего мы хотим сделать системы гибкими при настройке. Это касается не только цвета экрана и текста, но и более глубоких вещей, таких как выбор алгоритмов, программ баз данных, технологии связующего программного обеспечения и стиля пользовательского интерфейса. Эти пункты должны реализовываться в виде вариантов конфигурации, а не за счет интеграции или технологии.
Подсказка 37: Осуществляйте настройку, а не интеграцию
Используйте метаданные для спецификации вариантов настройки приложения: подгонки параметров, глобальных параметров пользователя, каталога, в который производится установка приложения, и т. д.
Так что же такое метаданные? Строго говоря, метаданные – это данные о данных. Наиболее распространенным примером, вероятно, является схема базы данных или словарь данных. Схема содержит данные, которые описывают поля (столбцы) в терминах имен, длины и других атрибутов. Вы должны иметь возможность доступа к этой информации и ее обработки так, как если бы это были любые другие данные в этой базе.
Мы используем этот термин в самом широком смысле. Метаданные – это любые данные, которые описывают приложение – как оно выполняется, какие ресурсы обязано использовать и т. д. Обычно доступ к данным и их использование осуществляется на этапе выполнения, а не компиляции. Вы используете метаданные все время, по крайней мере, это делают ваши программы. Предположим, вы щелкаете мышью для того, чтобы скрыть панель инструментов в интернет-браузере. Браузер будет сохранять эти глобальные параметры как метаданные в своего рода внутренней базе данных.
Эта база данных может быть сформирована в собственном формате или может воспользоваться стандартным механизмом. При работе в операционной системе Windows таким механизмом является либо файл инициализации (используется суффикс .ini), либо записи в системном реестре. При работе с Unix подобная функциональная возможность обеспечивается системой X Window с помощью файлов Application Default. Java использует файлы Property. Во всех этих средах для извлечения значения вы указываете ключ. В других, более мощных и гибких реализациях метаданных используется встроенный язык сценариев (см. "Языки, отражающие специфику предметной области").
При реализации этих глобальных параметров в браузере Netscape фактически использованы обе эти технологии. В версии 3 параметры сохранялись в виде пар "ключ-значение":
SHOWTOOLBAR: False
В версии 4 параметры больше напоминали JavaScript:
user_pref("custtoolbar.Browser.Navigation_Toolbar.open", false);
Приложения, управляемые метаданными
Но мы хотим большего, нежели использовать метаданные для простых глобальных параметров. Мы хотим настраивать и управлять приложением через метаданные – насколько это возможно. Наша цель – думать описательно (обозначая, что должно быть сделано, а не как это должно быть сделано) и создавать высокодинамичные и адаптируемые программы. Это можно сделать, придерживаясь общего правила: программировать для общего случая и помещать всю специфику в другое место – за пределы компилируемого ядра программы.
Подсказка 38: Помещайте абстракции в текст программы, а подробности – в область метаданных
Этот подход характеризуется несколькими преимуществами:
• Он вынуждает вас делать конструкцию несвязанной, что приводит к созданию более гибкой и адаптируемой программы.
• Он заставляет вас создавать более устойчивую, абстрактную конструкцию за счет отнесения подробностей, выводя все подробности за пределы программы.
• Вы можете настроить приложение, не прибегая к его перекомпиляции. Вы также можете использовать этот уровень настройки для обеспечения обходных путей при критических дефектах систем, находящихся в эксплуатации.
• Метаданные могут быть выражены способом, который находится намного ближе к предметной области, по сравнению с универсальным языком программирования (см. "Языки, отражающие специфику конкретной области").
• Вы даже сможете реализовывать несколько различных проектов, используя то же самое ядро приложения, но с различными метаданными.
Как правило, нам хочется отложить определение большинства подробностей на последний момент и оставить их как можно менее сложными для изменения. Создавая решение, позволяющее нам вносить изменения быстро, мы можем лучше справляться с потоком направленных сдвигов, которые погубили многие проекты (см. "Обратимость").
Бизнес-логика
Итак, мы выбрали механизм базы данных в качестве опции настройки и предусмотрели метаданные для определения стиля пользовательского интерфейса. Можем ли мы сделать большее? Несомненно.
Поскольку стратегия и бизнес-правила подвергнутся изменениям скорее, нежели любые другие аспекты проекта, есть смысл поддерживать их в очень гибком формате.
Например, приложение, автоматизирующее процесс закупок, может включать в себя различные корпоративные стратегии. Может быть, вы производите оплату небольшим фирмам-поставщикам через 45 дней, а большим – через 90 дней. Сделайте настраиваемыми определения типов поставщиков, а также самих периодов времени. Используйте возможность обобщения.
Возможно, вы создаете систему с ужасающими требованиями к последовательности операций. Действия начинаются и заканчиваются согласно сложным (и изменяющимся) бизнес-правилам. Подумайте об их реализации в виде некой системы на основе правил (или экспертной системы), встроенных в ваше приложение. Тем самым вы осуществите его настройку за счет написания правил, а не программы.
Менее сложная логика может быть выражена при помощи мини-языка, что делает необязательным повторную компиляцию и развертывание при изменении среды. Пример приведен в разделе "Языки, отражающие специфику предметной области".
Когда осуществлять настройку
Как было упомянуто в разделе "Преимущество простого текста", рекомендуется представлять метаданные о настройке в формате простого текста – это делает жизнь проще.
Но когда программа должна осуществлять считывание этой настройки? Многие программы осуществляют просмотр только при неудачном запуске. Если вам необходимо изменить настройку, это вынуждает вас перезапускать приложение. Более гибким подходом является написание программ, которые могут перезагружать свои настройки во время выполнения. Но эта гибкость обходится недешево: она более сложна в реализации.
Рассмотрим, как будет использоваться приложение: если это продолжительный серверный процесс, то вам понадобится некий механизм для повторного считывания и применения метаданных в ходе выполнения программы.
Для небольшого клиентского приложения с графическим интерфейсом, которое перезапускается достаточно быстро, это может и не понадобиться.
Данное явление не ограничивается прикладными программами. Все мы раздражаемся, если операционные системы заставляют нас проводить перезагрузку при установке простых приложений или изменении совершенно безвредного параметра.
Пример: пакет Enterprise Java Beans
Пакет EJB (Enterprise Java Beans) является интегрированной средой, предназначенной для упрощения программирования в распределенной среде, основанной на транзакциях. Этот пакет упоминается в связи с тем, что он иллюстрирует использование метаданных для настройки приложений и упрощения процедуры написания программы.
Предположим, что вы хотите создать некоторую программу на языке Java, которая будет принимать участие в транзакциях на различных машинах, с базами данных от различных производителей и с разными моделями потоков и распределения нагрузки.
Хорошая новость: вам не нужно беспокоиться обо всем этом. Вы пишете так называемый bean-элемент – отдельный объект, который следует определенным соглашениям, и помещаете его в контейнер bean-элементов, управляющий многими низкоуровневыми средствами от вашего имени. Вы можете писать программу для bean-элемента, не включая какие-либо транзакционные операции или управление потоками; пакет EJB использует метаданные для указания способа обработки транзакций.
Назначение потока и распределение нагрузки указываются как метаданные для основной службы транзакций, используемой контейнером. Это разделение допускает большую гибкость при динамической настройке среды во время работы.
Контейнер bean-элемента может управлять транзакциями от имени bean-элемента одним из нескольких различных способов (включая вариант управления собственными обновлениями и отменой транзакций). Все параметры, воздействующие на поведение bean-элемента, указаны в описателе развертывания последнего – объекте, преобразованном в последовательную форму и содержащем нужные метаданные.
Распределенные системы, подобные EJB, прокладывают путь в новый мир – мир настраиваемых, динамичных систем.
Совместная настройка
Выше уже говорилось о пользователях и разработчиках, настраивающих динамические приложения. Но что происходит, если вы позволяете приложениям настраивать друг друга? Речь идет о программах, которые адаптируются к операционной среде. Незапланированная, импровизированная настройка существующего программного обеспечения является мощной концепцией.
Операционные системы уже способны подстраивать себя при загрузке под аппаратное обеспечение, a web-браузеры автоматически обновляются, инсталлируя новые компоненты.
Большие приложения, с которыми вы работаете, имеют проблемы с управлением различными версиями данных и различными версиями библиотек и операционных систем. Возможно, здесь будет полезен более динамичный подход.
Не пишите нежизнеспособных программ
В отсутствие метаданных ваша программа не является столь адаптируемой или гибкой, какой она могла бы стать в противном случае. Плохо ли это? В реальном мире виды, которые не могут адаптироваться, умирают.
Птицы додо не смогли приспособиться к присутствию людей и домашних животных на острове Маврикий и быстро вымерли
[29]. Это было первое документально подтвержденное исчезновение вида от рук человека.
Не дайте вашему проекту (или карьере) повторить судьбу птицы додо.
Другие разделы, относящиеся к данной теме:
• Ортогональность
• Обратимость
• Языки, отражающие специфику предметной области
• Преимущества простого текста
Вопросы для обсуждения
• Работая над текущим проектом, подумайте о следующем: какая часть программы может быть убрана из нее и перемещена в область метаданных. Как в итоге будет выглядеть «ядро» программы? Сможете ли вы повторно использовать это ядро в контексте иного приложения?
Упражнения
28. Что из нижеследующего лучше представить в виде фрагмента программы, а что вывести за ее пределы в область метаданных?
1. Назначения коммуникационных портов
2. Поддержка выделения синтаксиса различных языков в программе редактирования
3. Поддержка редактора для различных графических устройств
4. Конечный автомат для программы синтаксического анализа или сканера
5. Типовые значения и результаты, используемые в тестировании модулей
28
Временное связывание
Временное связывание – о чем это? – спросите вы. Это – о времени.
Время – аспект, который часто игнорируется в архитектуре программного обеспечения. Единственный временной параметр, который занимает наш ум – это время выполнения проекта, время, оставшееся до отправки продукта заказчику, но здесь разговор не об этом, а о роли временного фактора как элемента проектирования самого программного обеспечения. Существует два временных аспекта, представляющих для нас важность: параллелизм (события, происходящие в одно и то же время) и упорядочивание (относительное положение событий во времени).
Обычно мы не приступаем к программированию, держа в голове тот или иной аспект. Когда люди садятся за проектирование, разработку архитектуры или написание программы, события стремятся к линейности. Это и есть способ мышления большинства людей – сначала сделать «это», а потом всегда сделать «то». Но этот способ мышления приводит к связыванию во времени. Метод А всегда вызывается перед методом В; одновременно должен формироваться только один отчет; необходимо подождать перерисовки экрана до получения отклика на щелчок мыши. «Тик» обязан происходить раньше, чем "так".
Этот подход не отличается большой гибкостью и реализмом.
Нам приходится учитывать параллелизм
[30]и думать о несвязанности любых временных или упорядоченных зависимостей. При этом мы выигрываем в гибкости и уменьшаем любые зависимости, основанные на времени во многих областях разработки: анализе последовательности операций, архитектуре, проектировании и развертывании.
<< | >>
Источник: Эндрю Хант. Программист-прагматик. Путь от подмастерья к мастеру. 2004

Еще по теме Динамическая конфигурация:

  1. 2.1. Открытие конфигурации
  2. 2.3Закрытие конфигурации
  3. 2.2. Сохранение конфигурации
  4. 2.4Загрузка конфигурации из файла
  5. 2.5Дерево объектов конфигурации
  6. Глава 2. Работа с конфигураци
  7. 5.1. Свойства конфигурации
  8. 2.12. Работа с конфигурацией базы данных
  9. Динамический баланс
  10. ДИНАМИЧЕСКИЕ И ВЕРОЯТНОСТНО - СТАТИСТИЧЕСКИЕ ЗАКОНЫ
  11. 2.7. Создание и удаление объекта конфигурации
  12. Объединение статического и динамического балансов
  13. Динамическое хеджирование