Советы

Как определить аппаратную конфигурацию компьютера. Программная конфигурация вычислительной системы

03.05.2019
Как определить аппаратную конфигурацию компьютера. Программная конфигурация вычислительной системы

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

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

Способы установки и конфигурирования программного обеспечения известны . Эти способы реализованы в современных цифровых вычислительных машинах в виде программ инсталляции, которые выполняют копирование файлов программного обеспечения на компьютер назначения, а также запись параметров конфигурации и другие действия по настройке программного обеспечения. Последовательность технологических операций в известных способах установки и конфигурации программного обеспечения должна строго выполняться в порядке, заданном разработчиком программы инсталляции. Наиболее современной программой инсталляции является Windows Installer - составная часть технологии IntelliMirror, используемая для работы с приложениями Windows 200 . С ее помощью упрощается установка приложений и их обновление, устраняется возможность "конфликта версий", появляются дополнительные возможности по управлению программами, установленными в системе. Программа инсталляции состоит из главного установочного пакета и связанных с ним установочных пакетов. В свою очередь каждый установочный пакет состоит из одной или нескольких операций, объединенных согласно логике функционирования установочного пакета. Установочный пакет может содержать ссылки на другие установочные пакеты. При этом при выполнении установки и конфигурирования программного обеспечения могут быть использованы не все операции каждого установочного пакета, а только их произвольная выборка, определяемая целями и составом программного обеспечения, а также конфигурацией технических средств. Способ установки и конфигурирования программного обеспечения требует выполнения установочных операций в составе этих пакетов в строгой последовательности, заданной разработчиком. С целью оптимизации инсталляционных процессов внутри каждого установочного продукта к каждому параметру установки может быть назначен весовой коэффициент . Каждый весовой коэффициент в комбинации с состоянием параметров инсталляции, информацией о разбиении потенциальных компьютеров назначения используется в процедуре выбора для каждой потенциально возможной компьютерной системы назначения соответствующего пакета установочных пакетов.

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

Цель данного предложения состоит в обеспечении возможности объективного контроля над процессом выполнения инсталляции программного продукта в установочных пакетах, что повышает надежность инсталляции и обеспечивает безотказность процесса установки сложных программных систем.

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

Сущность способа установки и конфигурирования программного обеспечения состоит в следующем. Вначале осуществляется выделение и загрузка установочных пакетов, начиная с главного установочного пакета. В каждом из загруженных установочных пакетов согласно логике функционирования установочного пакета выделяется одна или несколько операций, которым присваивается один или несколько атрибутов. Кроме того, в каждом установочном пакете одному или нескольким значениям одного или нескольких параметров установки присваивается вес. Эти параметры установки должны быть связаны с процессом установки и конфигурирования установочного пакета. Затем определяется множество компьютеров назначения, на которых может быть осуществлена установка данного установочного пакета. После чего задается процедура вычисления каждого установочного параметра и осуществляется разбиение множества компьютеров назначения на подмножества. При разбиении используются заданные веса в комбинации с состоянием параметров установки и вычисляется критерий соответствия каждого параметра установки для каждой из потенциальных систем компьютеров назначения с целью их дальнейшего конфигурирования. В процессе загрузки главного установочного пакета методом последовательного перебора обрабатываются все его фазы, начиная с начальной. После окончания обработки каждой фазы, то есть после окончания выполнения логически объединенных одной или нескольких операций, эта фаза помечается как обработанная. Факт обработки данной фазы может быть отображен визуально на мониторе. Одновременно с постановкой метки на обработанной фазе во всех остальных установочных пакетах, связанных с главным, осуществляется поиск фазы с атрибутами, соответствующими атрибутам данной обработанной фазы. Если в одном из установочных пакетов фаза с такими атрибутами обнаружена, то начинают обрабатываться фазы этого установочного пакета, которые, во-первых, не помечены; во-вторых, предшествуют найденной в этом установочном пакете фазе. Обработка фаз этого установочного пакета заканчивается на первоначально обнаруженной фазе с идентичными атрибутами. После возвращения в исходную фазу все обработанные фазы помечаются как обработанные. При этом обработка каждой фазы в каждом установочном пакете обязательно включает поиск фаз с аналогичными атрибутами во всех установочных пакетах. После завершения перебора фаз главного установочного пакета последовательно перебираются непомеченные фазы каждого из остальных установочных пакетов. Благодаря тому, что все обработанные фазы наряду с атрибутами имеют проставленные метки, заявляемый способ установки и конфигурирования программного обеспечения представляет возможность контролировать ход инсталляции программного продукта и наблюдать за его ходом с помощью любого устройства отображения. Группирование серии идентичных, одной или нескольких, операций вокруг фазы с общим для всех них набором атрибутов позволяет повысить надежность инсталляции программного продукта, что способно обеспечить безотказность процесса установки и конфигурирования сложных программных систем.

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

1. Андреев А.Г. и др. Microsoft Windows 2000 Server и Professional / Под общим редактированием Чекмарева А.Н. и Вишнякова Д.Б. - СПб: БХВ - Санкт-Петербург, 2000 - 992 с.: стр 145, 373.

2. Integrates with Microsoft. Visual Studio. Net Help. 1992-2003. Microsoft Corporation. 0103 Part № X 09-19409, 19410, 19411.

3. Патент США №2003/0163807, М.Кл. G 06 F 009/445, зарегистрирован 27 февраля 2002 г., опубликован 28 августа 2003 г.

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

Синтаксис

Синтаксис конфигурационного файла однозначно определяется в терминах:

  • Конфигурация — последовательность параметров
  • Параметр — имя без пробельных символов со следующим за ним значением, отделенным хотя бы одним пробельным символом
  • Значение — строка без пробельных символов / строка, заключенная в кавычки / вложенная конфигурация, заключенная в фигурные скобки

Конфигурация

Дополнительные ограничения / соглашения:

  • Значения всех временны х параметров задаются как целые числа, единица измерения — миллисекунды — не указывается

Все FastCGI-приложения, которыми должен управлять Пускач, должны быть либо явно описаны в конфигурационном файле, либо должна быть определена конфигурация по умолчанию. Приложение описывается параметром fcgi со вложенной конфигурацией:

  1. req_pool_size 256
  2. # Команда запуска PHP-скриптов
  3. start_cmd
  4. mask *.php
  5. mask *.phtml
  6. cmd "/usr/local/bin/php-cgi -f $script_filename"
  7. # Конфигурация по умолчанию
  8. default_fcgi
  9. unix_socket_prefix "/tmp/puskach/site_user_fcgi_"
  10. io_timeout 10000
  11. max_processes 5
  12. sleep_timeout 30000
  13. requests_per_process 1000
  14. path "/usr/home/site_user/www/myscript.fcgi"
  15. unix_socket_prefix "/tmp/puskach/site_user_myscript_fcgi_"
  16. io_timeout 10000
  17. max_processes 1
  18. sleep_timeout 15000
  19. request_processing_timeout 10000
  20. requests_per_process 100
  21. on_abort_request_behaviour 1

req_pool_size — глобальный параметр, устанавливает размер пула запросов, находящихся в обработке, либо ждущих в очереди. При исчерпании пула запросов новые запросы от web-сервера отклоняются. Значение по умолчаню 128.

Параметры FastCGI-приложения

path — путь к FastCGI-приложению, служит для двух целей: (1) запуск приложения и (2) поиск приложения при входящем запросе от web-сервера (во входящем запросе должен передаваться FastCGI-параметр SCRIPT_FILENAME с тем же значением). Может задаваться как абсолютно, так и относительно текущей директории рабочего процесса Пускача (текущую директорию можно установить при старте Пускача в стартовом скрипте).

unix_socket_prefix — префикс имени Unix сокета, используемого для связи Пускача с копиями FastCGI-приложения. Для обеспечения неблокирующей обработки запросов Пускач поддерживает параллельную работу с несколькими процессами одного приложения, именуемыми копиями . Каждая копия слушает свой Unix-сокет, имя которого состоит из префикса и номера копии.

req_queue_len — максимальная длина очереди запросов. Если на момент прихода запроса от web-сервера не находится свободных обработчиков, запрос ставится в очередь; если очередь переполнена, запрос отклоняется. Значение по умолчанию 10.

io_timeout — таймаут ввода-вывода — максимально допустимое время между двумя операциями ВВ. Если по истечении этого времени следующей операции ВВ не последовало, обработка запроса web-сервера будет прервана, а обрабатывающая запрос копия FastCGI-приложения остановлена.

max_processes — максимальное число процессов (копий), которые могут быть параллельно запущены для данного приложения (размер пула процессов).

sleep_timeout — таймаут бездействия — максимальное время простоя копии FastCGI приложения, по истечении которого копия останавливается. Используется для освобождения ресурсов, занятых процессами, длительное время не выполняющими обработку запросов.

request_processing_timeout — таймаут обработки запроса — максимально допустимое время между запросом web-сервера и ответом приложения об окончании обработки запроса. В случае превышения таймаута обработка запроса прерывается, а копия приложения останавливается.

requests_per_process — максимальное число запросов, которое может последовательно обработать копия данного FastCGI-приложения. В случае достижения лимита копия завершается. Полезно для профилактики утечки ресурсов.

on_abort_request_behaviour — выбор поведения при прерывании обработки запроса web-сервером: 0 — корректно завершить обработку запроса, если это возможно, 1 — прервать обработку запроса копией FastCGI приложения. По умолчанию 0. Обратите внимание, что для использования значения 1 необходимо, чтобы возможность прерывания обработки запроса при получении соответсвующего сигнала была реализована в логике FastCGI приложения.

Конфигурация по умолчанию

Конфигурация по умолчанию описывается параметром default_fcgi , аналогично fcgi . В случае, если конфигурация по умолчанию не определена, Пускач будет обрабатывать только запросы, адресованные явно описанным в конфигурационном файле FastCGI-приложениям. Иначе при запросе к любому существующему приложению Пускач будет динамически описывать его, использую конфигурацию по умолчанию. Имеет смысл задавать в конфигурации по умолчанию более строгие ограничения и переопределять их для отдельных скриптов в зависимости от их специфики.

Стартовая команда

Стартовая команда определяет исполняемую программу (как правило, интерпретатор) с набором аргументов командной строки, которая может быть использована для запуска FastCGI-приложений. Путь к исполняемому файлу и аргументы задаются в обязательном параметре cmd . Сложные аргументы, содержащие пробельные символы, необходимо заключать в двойные кавычки. По умолчанию путь к запускаемому скрипту будет передан последним аргументом, для явного указания аргумента необходимо использовать макрос $script_filename .

Для ассоциации стартовой команды со скриптами используется один или более параметров mask . Маска — любая комбинация из значащих символов и служебного символа * , совпадающего в любым колическом любых символов. Для поиска стартовой команды Пускач последовательно сравнивает все маски всех стартовых команд с путем к скрипту до первого совпадения. Если в результате поиска стартовая команда не найдена, будет выполнен прямой запуск скрипта по path .

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

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

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

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

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

Что именно стоит настраивать.

Вот типичные примеры данных, которые часто стоит вынести в настройки:

  • Всевозможные каталоги. Например - пути до файлов данных, каталоги импорта/экспорта.
  • Сетевые настройки. Имена серверов, IP-адреса, порты, имена и пароли для автоматического доступа.
  • Настройки баз данных. Имена JDBC-драйверов, URL базы данных, SQL-запросы, зависимые от используемой БД.
  • Настройки внешнего вида. Настройки Swing-овского Look & Feel-а, используемые шрифты, размеры, цвета, настройки горячих клавиш.
  • Прочее... Любые другие вещи, которые могут менятся от пользователя к пользователю.

Например, довольно часто встречаемая ситуация - настройка соединения с БД. Начинающие программисты часто пишут нечто подобное:

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); Connection con = DriverManager.getConnection("jdbc:odbc:MyDatabase",user,password);

Таким образом программа привязывается к конкретному JDBC драйверу. Использовать другой драйвер, например заменить мост на RMI-прокси или, в случае Oracle, OCI на Thin без перекомпиляции уже нельзя.

В объектном программировании всё представляется в виде объектов. Настройки лучше всего при этом рассматривать как свойства определённых объектов, которые хранятся в файлах конфигураций. То, каким образом эти настройки считываются и записываются тесно взаимосвязано с форматом файлов и выбраной стратегией администрирования. Рассмотрим идеальный вариант:

  1. Настраиваемый объект не должен содержать знаний о формате файлов и способе чтения/записи. Это позволило бы, в случае необходимости, заменить один способ другим.
  2. Большинство настроек должны выполняться при помощи программы (подпункт меню или отдельная программа настройки). Это сильно облегчает жизнь человека, который занимается администрированием. У большинства "юниксоидов" это может вызвать непонимание:-), но редактированием текстовых файлов в современном мире во многих случаях не обойтись.
  3. Должно быть установлено разумное умолчание для отсутствующих параметров. Другими словами - необходимо, чтобы большинству пользователей для запуска программы нужно было бы сделать минимум настроек. Как правило это оставляет благоприятное первое впечатление о программе, а часто именно оно - самое важное.

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

Второе требование подразумевает, что для каждого объекта пишется своя панель (или диалог) для редактирования настроек. В случае большого количества объектов стоит попробовать использовать универсальные механизмы. Один из вариантов - использование стандарта JavaBeans. Этот стандарт разрабатывался для визуальных систем программирования, но, из-за сходства решаемых задач, также хорошо подходит для универсального конфигурирования. Но это тоже не самая простая задача, поэтому часто разумно предусмотреть возможность альтернативного варианта конфигурирования для пожарных случаев - например, при помощи обычных текстовых редакторов в случае использования текстовых форматов файлов.

Разумное же умолчание для параметров часто просто невозможно представить. Например, что поставить в качестве имени SMTP-сервера? В случае Unix-систем можно попробовать поставить localhost, но для Windows-мира это редко кому подойдёт.

Рассмотрим наиболее распространённые варианты:

Ini-файлы.

Ini-файлы - это был самый распространённый вариант в эпоху Windows 3.x. Сейчас в виндовых программах он стал вытесняться хранением настроек в реестре. Тем не менее ini - это один из простейших вариантов хранения настроек. К сожалению довольно часто эта простота заставляет прибегать к различно рода ухищрениям. Пример типичного ini-файла:

InputDir=INPUT OutputDir=OUTPUT ArchDir=ARHIV TransferPath = a:\cour NoReceived=No Numb = 3 MenuName1 = ~N~orton ProgName1 = mousesav c:\command.com /c nc MenuName2 = Win - ~Б~локнот ProgName2 = notepad MenuName3 = Импорт из формата АБ "Инкомбанк" ProgName3 = incom.bat

В Java нет стандартного класса для чтения ini-файлов, но это не проблема. Т.к. формат очень прост, его легко сделать самому:

Файлы Properties.

Этот формат распространён в Unix-мире. Он ещё проще ini-файлов, т.к. в нём отсутствует понятие секций - всё состоит из ключей и значений. Пример типичного файла:

# Database configuration Database.Driver=sun.jdbc.odbc.JdbcOdbcDriver Database.DataURL=jdbc:odbc:MyDatabase Database.Prop.user=user Database.Prop.password=password

В Java есть готовый класс для чтения/записи таких файлов (java.util.Properties), но с ним есть некоторые проблемы. Во первых для чтения невозможно задать кодировку файла, а это означает проблемы с русскими буквами. Во вторых стандартная функция записи сохраняет данные в порядке следования хэш-значений ключей, что значит - как ей больше понравится. Но это тоже легко разрешимо - достаточно написать свою читалку/писалку.

XML-файлы.

Этот формат подходит для многих целей, в том числе и для хранения настроек. XML-формат ориентирован на древовидные структуры, что довольно естественым образом отображается на объекты. Пример типичного файла:

user password

Для чтения и записи таких файлов предназначены специальные библиотеки - так называемые XML-парсеры. Таких парсеров уже сделано довольно много, так что писать его самому нет большого смысла - достаточно лишь подобрать подходящий. Для парсеров было разработано два стандартных программных интерфейса - событийный (SAX) и иерархический (DOM). Есть также и парсеры со своим интерфейсом. Размер jar-а с парсером может варьироваться от нескольких килобайт до мегабайта - в зависимости от поддерживаемых интерфейсов и возможностей.

Для XML также написано несколько библиотек для универсального сохранения (сериализации) объектов в файлах XML. Такие библиотеки позволяют отделить алгоритм сохранения от самого объекта, а это, как уже упоминалось, имеет много плюсов.

Сериализация.

Под термином "сериализация" понимают запись содержимого объекта в поток двоичных данных. Обычно имеется в виду универсальный алгоритм, реализуемый классами java.io.ObjectOutputStream и java.io.ObjectInputStream . Пользоваться ими просто настолько, насколько это вообще возможно - обычно достаточно лишь отметить в классе поддержку при помощи интерфейса Serializable и отметить ключевым словом transient те поля объекта, которые сохранять не нужно. Собсно и всё. :-) Пример:

public class SerialObject implements java.io.Serializable { private String name; private transient int state; public SerialObject() {} public SerialObject(String n) { name = n; } public String getName() { return name; } public void setState(int s) { state = s; } }
Запись объектов:
SerialObject o = ...; OutputStream os = ...; ObjectOutputStream oos = new ObjectOutputStream(os); oos.writeObject(o);
Чтение объектов:
InputStream is = ...; ObjectInputStream ois = new ObjectInputStream(is); SerialObject o = (SerialObject)ois.readObject();
Использование сериализации - это один из самых простых вариантов по реализации, но и у него есть свои недостатки. Получаемые файлы являются двоичными, а значит в текстовом редакторе их уже не подправить - придётся делать редактирование параметров из программы. Кроме того, необходимо следить за изменением сохраняемых объектов, дабы не нарушить совместимость при изменении и развитии программы.

Базы данных.

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

  • Настройки связаны весьма сложным образом и древовидные структуры типа XML подходят плохо.
  • Доступ к настройкам должен быть только у авторизованых пользователей.
  • Доступ к этим данным должен быть и из других программ, например из генератора отчётов типа Crystal Reports.
БД могут применятся объектные или реляционные. Другие типы сейчас широкого распространения не имеют. Использовать хорошую объектную БД часто так же просто, как и сериализацию. Для реляционых баз можно применить объектную надстройку, которая также позволяет сильно упростить жизнь. Ну а можно делать обычные SELECT-ы.

Скрипты.

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

Но часто без скриптов действительно тяжело. Типичные примеры - алгоритмы импорта/экспорта, алгоритмы проверок данных. Вы можете подготовить стандартный набор, а дальше настраивать скриптами под конкретные требования заказчика.

Для программ на Java в качестве скрипт-языка хорошо использовать язык Pyton в его Java-инкарнации под названием JPyton. Там легко организовать двусторонюю связь между программой и скриптом. Если не будет хватать скорости интерпретации, то код на Pyton-е можно скомпилировать в байт-код - получится обычный Java-класс. Про JPyton можно почитать на сайте http://www.jpyton.org/ или в новой книжке Брюса Эккеля Thinking In Patterns with Java (доступна на http://www.bruceeckel.com/).

Пример программы с конфигурацией в XML.

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

Пример содержимого конфигурационного файла:

Просто строчка Вторая строчка

В качестве XML-парсера используется Sun-овский парсер в режиме DOM. На таком простом примере не видно особых преимуществ формата XML над теми же файлами properties. Они становятся заметны только в достаточно сложных программах, где становится необходимо хранить списки однотипных параметров или же содержимое объектов с уровнем вложенности два или более.

Управление конфигурацией ПО — это один из вспомогательных процессов, поддерживающих основные процессы ЖЦ ПО, прежде всего процессы разработки и сопровождения ПО.

Под конфигурацией ПО понимается совокупность его функциональных и физических ха­рактеристик , установленных в технической документации и реали­зованных в ПО.

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

Управление конфигурацией позволяет организовать, системати­чески учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ.

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

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

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

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

- вести полный и достоверный архив всех версий всех объектов системы;

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

- проводить оценку конфигурации — оценивать функциональную пол­ноту компонентов ПО, а также соответствие их физического состо­яния текущему техническому описанию.

- изготавливать эталон­ные копии ПО и документации, хранить и поставлять их пользо­вателям в соответствии с порядком, принятым в организации. Это упрощает выпуск и поставку ПО;

- обеспечивать развитие всей системы, ограничивая усложнение проекта.

Рассмотрим, как пример, управление исходным кодом .

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

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

Прикладные программисты должны придерживаться установленных правил групповой разработки.

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

Формат комментария к правке может быть таким:

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


Часто ведущие исполнители проектов не доверяют системам контроля исходного кода сливать правки в исходных текстах автоматически и частично или полностью контролируют этот процесс. Эта перестраховка во многих случаях себя оправдывает.

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

Функции, структуры, наиболее важные переменные должны сопровождаться комментариями. Необходимо избегать непонятных названий вида K1, Function10.

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

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

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

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

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

Рынок систем конфигурационного управления

Без хорошего инструментария невозможно оперативно управлять конфигура­циями ПО.

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

Можно выделить четыре группы таких продуктов :

1) обеспечивающие контроль версий (Rational ClearCase, Merant PVCS, Microsoft Visual SourceSafe);

2) обеспечивающие контроль версий и изменений (Rational ClearCase/ClearQuest, PVCS Professional);

3) обеспечивающие параллельную разработку, контроль версий, изменений и рабочих процессов (PVCS Dimensions, CCC:Harvest фирмы Computer Associates);

4) обеспечивающие все вышеуказанные возможности при взаимодействии нес­кольких географически удаленных команд (Rational MultiSite, PVCS Replicator).

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

В числе недостатков ClearCase — необходимость серьезного администриро­вания, т.е. нагрузка при работе с продуктом перекладывается с конечных пользователей на администратора.

Продукт PVCS , встроен во многие системы разработки, предлагает более простой версионный контроль. Он хуже автоматизирует работу пользователей и сложнее в применении, но зато не требует отдельного сотрудника-администратора для поддержки небольших групп разработчиков. Существуют проблемы переходов от одного продукта PVCS к другому. Имеет меньшую стоимость. Может оказаться хорошим решением, если разработка идет под разными платформами (аппаратная платформа и ОС).

Продукт Microsoft Visual Source Safe осуществляет простой контроль исходных текстов и подходит для индивидуальной работы или для проектов, объединяющих нескольких человек. В нем нельзя организовать связь между участниками проекта, но он значительно дешевле и проще. Используется для ОС Windows 98, NT, 2000.

В ноябре 2002 г. компания Merantвыпустилановую версию популярного инструмента для управления конфигурациями ПО PVCS Professional 7.5 .

В состав пакета входят:

PVCS Version Manager 7.5 — система контроля версий;

PVCS Tracker Manager 7.5 — утилита формирования журнала изменений и задач;

Configuration Builder 7.5 — утилита обеспечения стандартизованной и надежной компоновки готовых приложений.

Конфигурация программы. Программа разработана на базе комплексной конфигурации для 1С Предприятие 7.7 . Таким образом, если приобретается типовой продукт, необходимо наличие 1С Предприятие 7.7 Комплексная Торголя Бухгалтерия Расчет. При необходимости программа может быть внедрена в любую другую конфигурацию буквально за 1-3 дня. Конфигурация может быть как разработки 1С, так и разработки дилеров, а также разработана самостоятельно.

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

Важно, чтобы конфигурация в этом случае была сохранена в 1С Предприятие 7.7 . Допускается, если она была разработана в 1С Предприятие 7.5 и затем просто сохранена в новом формате. 8,12,21,22,24

Конец работы -

Эта тема принадлежит разделу:

Бюджетное управление предприятием

Это система, которая ведется в формате бюджетов по центрам ответственности. Бюджет - это точный расчет всех ресурсов предприятия для достижения.. Почему компании переходят на бюджетное управление? В условиях жесткой конкуренции, руководители компаний задумываются..

Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ:

Что будем делать с полученным материалом:

Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:

Все темы данного раздела:

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

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

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

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

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

Место бюджетирования в системе финансового управления и его внедрение на предприятии
Место бюджетирования в системе финансового управления и его внедрение на предприятии. Сопоставление инструментов финансового управления Таблица 1 показывает характерные особенности бюджетирования,

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

Этапы внедрения системного решения
Этапы внедрения системного решения. Методология разбивает процесс внедрения на 8 этапов? Выяснение потребностей организации? Описание системного решения? Адаптация системы к нуждам пользователей

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

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

Первый запуск программы
Первый запуск программы. Если в конце установки программы она не может запустить 1С Предприятие это связано с особенностями установки 1С, поэтому запустите ее через меню Программы. 2. После нормал

Работа с программой
Работа с программой. После того, как программа установлена и запущена в первый раз в монопольном режиме, ею можно полноценно пользоваться. 2. Если происходит первый запуск с компьютера, на который

Демонстрация программы
Демонстрация программы. Рекомендуется демонстрацию программы проводить через показ презентации в MS PowerPoint. Если зритель требует показа нюансов, то возможно параллельно разъяснять отдельные асп

Приобретение программы
Приобретение программы. Лицензируются и приобретаются только рабочие места модуля планирования. То есть нужно покупать программу на то количество мест, которые будут планировать вводить доку



Возможно вас заинтересует