Способ установки и конфигурирования программного обеспечения. Конфигурационный файл

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Функции, структуры, наиболее важные переменные должны сопровождаться комментариями. Необходимо избегать непонятных названий вида 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 — утилита обеспечения стандартизованной и надежной компоновки готовых приложений.

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

Хорошо, если вы знаете свою конфигурацию назубок. А если нет? Тогда для сбора информации о конфигурации компьютера требуется пара минут и минимум усилий. Ниже я рассакжу о том, как это сделать средствами ОС Windows или сторонними программами, умеющими создавать отчет, который можно опубликовать на форуме.

Сведения о системе (msinfo32)

Как это ни тривиально звучит, но сведения об аппаратной конфигурации компьютера можно собрать, не устанавливая сторонние программы. В состав ОС Windows входит утилита Сведения о системе , которая обладает возможностью экспорта собранных данных в текстовый файл. Запустить программу можно из меню Пуск — Программы — Стандартные — Служебные или из окна Пуск — Выполнить (или поля Поиск в Vista), введя msinfo32 и нажав ОК .

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

В Windows XP и Vista того же результата можно достичь из командной строки, выполнив команду

Msinfo32 /report "<путь к папке>\config.txt"

Файл с отчетом будет создан в папке, путь к которой вы укажете в приведенной выше команде.

Программы сторонних разработчиков

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

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

Winaudit

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

После этого нужно заново нажать кнопку Аудит на панели инструментов для создания отчета. Для сохранения отчета нажмите кнопку Сохранить , и программа предложит на выбор десяток различных форматов. Лучше сохранять отчет в виде веб-страницы (HTML) или текстового файла. При сохранении в виде веб-страницы программа создает три HTML-файла, которые можно запаковать в архив и прикрепить к сообщению в форуме.

System Information for Windows (SIW)

Программа SIW имеет размер около 2.2 Мб, не требует установки (правда, без установщика предлагается только английская версия), обладает продуманным интерфейсом, да и наглядность выводимой ею информации заслуживает очень высокой оценки. В многоязычной версии русский язык интерфейса при необходимости можно задать в окне Tools -> Options . Нас, однако, интересует создание отчета, эта опция есть в меню Файл , как показано на рисунке ниже.

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

Базовый уровень – самый низкий уровень программного обеспечения представляет базовое программное обеспечение. Оно отвечает за взаимодействие с базовыми аппаратными средствами и, как правило, программные средства входят непосредственно в состав базового оборудования и хранятся в специальных микросхемах ПЗУ. Программы и данные записываются в микросхемы ПЗУ на этапе производства и не могут быть изменены в процессе эксплуатации.

Системный уровень – переходной. Программы, работающие на этом уровне, обеспечивают взаимодействие прочих программ компьютерной системы с программами базового уровня и непосредственно с аппаратным обеспечением, то есть выполняют “посреднические” функции. Конкретные программы, отвечающие за взаимодействие с конкретными устройствами, называются драйверами устройств. Они входят в состав программного обеспечения системного уровня. Программы, отвечающие за взаимодействие с пользователем, называют средствами обеспечения пользовательского интерфейса. Совокупность программного обеспечения системного уровня образует ядро операционной системы компьютера. Если компьютер оснащён программным обеспечением системного уровня, то он уже подготовлен к установке программ более высоких уровней, к взаимодействию программных средств с оборудованием и с пользователем. Наличие ядра операционной системы – непременное условие для возможности практической работы человека с вычислительной системой.

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

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

5. Универсальные и специализированные инструментальные среды. В чем разница между универсальными и специализированными ИС?

(при желании сократить)

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

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

Инструментальная среда не обязательно должна функционировать на том компьютере, на котором должно будет применяться разрабатываемое с помощью ее ПС.

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

• ориентированность на конкретный язык программирования,
• специализированность,
• комплексность,
• ориентированность на конкретную технологию программирования,
• ориентированность на коллективную разработку,
• интегрированность.

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

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

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

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

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

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

• интегрированность по пользовательскому интерфейсу,
• интегрированность по данным,
• интегрированность по действиям (функциям),

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

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

СО старой шпоры: (Инструментальные средства: -универсальный и не универсальный для программирования определенного класса контроля в целом. Пример: IsaGRAF и ултра логик. Как правило такие среды имеют стройные редакторы нескольких языков стандартов возможность выгр.готовый вход приложения ПЛК. Конфигурировать оборудования управлять целевой задачей. Недостатки: необходимость загрузки на конроллер доп.рпрог.обеспечение в рамках который вып.ся целевая задача. Специолизированный предназна для прог.конкретной конроллеров классоконтр.пример: лого или степ 7. Отличается от универсальной строго привязкой. Возможности таких сред шире или универсальных и могут включать адменистрированной сети.)

6. Что такое модули расширения при аппаратном конфигурировании ПЛК на примере ПЛК фирмы SIEMENS

Соглашения языка ST < boolean_expression > Соглашения языка LD Соглашения языка IL <инструкция><инструкция> <>

Projects : Управление проектомLibraries : Управление библиотекойBook : Справочная система ISaGRAFDiagnosis Read Me Report

Нижний Средний Верхний

7. Варианты порядка создания проекта в инструментальной среде Step 7

Начнем работу со средой, щелкнув на пиктограмму «SIMATIC Manager» на Рабочем столе ПК, либо, выбрав пункты меню ПУСК\SIMATIC\SIMATIC Manager.В среде Step7 существует два способа создания проекта: ---при помощи мастера создания проектов «STEP 7 Wizard»;--в ручном режиме.Первый способ – это создание проекта при помощи мастера. При запуске программы, первое загружаемое окно, называется «STEP 7 Wizard», в нем предлагается создать проект посредством нескольких простых действий. Если же у нас уже имеется готовый проект, то данное окно необходимо закрыть и воспользоваться меню Fail\Open.Создадим новый проект, для этого в окне Wizard нажмем кнопку «Next». Дальнейшим действием программа предлагает выбрать, из списка тип CPU который будет использоваться в проекте. Модуль центрального процессора «Мозг» машины, выполняет все вычислительные процессы, связанные с обработкой событий автоматизируемого технологического процесса или объекта. Из широкого спектра предложенных в списке модулей необходимо выбрать тот, который наиболее экономично и полно соответствует требованиям, предъявляемым к автоматизации ТП. Характеристики модулей приведены в этом же окне. Необходимо помнить, что выбранное оборудование должно строго соответствовать физическим устройствам, для которых разрабатывается ПО.Выберем контроллер SIMATIC 300\CPU-300\CPU-313C\6ES7-313-5BE01-0AB0. Адрес сети MPI, предлагаемый по умолчанию программой – 2. Это обусловлено тем, что первый адрес всегда резервируется для машины, чаще всего ПК, которая выступает в качестве рабочей станции для конфигурирования, настройки, программирования и управления ПЛК подключенных к сети. Каждому новому ПЛК подключаемому к сети, должен быть присвоен уникальный индивидуальный адрес. Оставим адрес без изменения. Щелкнем кнопку «Next».В предложенном окне программа предлагает уточнить метод выполнения программы, путем установки соответствующей галочки напротив обозначения функционального модуля. Оставим галочку на модуле ОВ1, что позволит работать программе по циклу, с опросом входов и перезаписью выходов с каждым исполненным циклом.Ниже выберем язык, используемый для создания логики проекта. Step 7 поддерживает три языка стандарта IEC1131-3 FBD, LD, STL. Для нашего проекта выберем любой из языков, к примеруFBD. Щелкнем кнопку «Next».В соответствующем поле введем имя проекта, к примеру «MineProject». Щелкнем кнопку «Finish», работу мастера по созданию проекта можно считать завершенной.Для создания нового проекта в ручном режиме нужно в меню File выбрать пункт New. На экране появится диалоговое окноВ данном окне указываются имя проекта и его размещение. Далее в меню Insert необходимо выбрать пункт рабочей станции, к примеруStation\SIMATIC 300 Station. Для конфигурации оборудования выберем станцию SIMATIC 300(1) и дважды щелкнем на иконке Hardware. Это позволит войти в окно программного конфигурирования оборудования.

8. Действия внутри переходов языка SFC ISaGRAF, соглашения, примеры К каждому переходу может присоединяться логическое выражение, кото-рое является условием прохождения этого перехода. Условие обычно записы-вается на языке ST или LD. Это Уровень 2 перехода. Однако могут быть ис-пользованы и другие структуры: --оглашения языка ST; --Соглашения языка LD; --Соглашения языка IL; --Вызовы функций из переходов. Если к переходу не присоединено выражение, то по умолчанию условие - TRUE.Соглашения языка ST Язык ST можно использовать для описания условий, присоединенных к переходам. Выражение должно иметь логический тип и заканчиваться точкой с запятой: < boolean_expression > ; Выражение может быть константой TRUE или FALSE, входом или внут-ренней логической переменной, или комбинацией переменных, которые дают логическое значение. Соглашения языка LD Язык Релейных Диаграмм (LD) можно использовать для описания усло-вий, присоединенных к переходам. Диаграмма состоит из штанги с витком. Значение витка представляет значение переходаСоглашения языка IL Язык Список Инструкций (IL) можно использовать для описания SFC пе-реходов, согласно следующему синтаксису: #info=IL <инструкция><инструкция> .... #endinfo Значение, которое содержит текущий результат (IL регистр) в конце IL последовательности, будет являться условием присоединенным к переходу: result = 0 условие перехода – FALSE; result <> 0 условие перехода – TRUE. Специальные ключевые слова #info=IL и #endinfo должны быть введены именно так, прописными буквами. До или после ключевых слов нельзя вво-дить пробелы и символы табуляции.

9. Действия внутри шагов языка SFC ISaGRAF, соглашения, примеры Уровень 2 шага SFC представляет собой детальное описание действий в период активности шага. Это описание может использовать текстовые допол-нения языка SFC, структурный текст ST, язык инструкций IL. Основные типы действий: булевские действия; импульсные действия; не сохраняемые действия; действия SFC. В одном шаге могут быть описаны несколько действий одинаковых или разных типов (см. АСУ водоотливной установкой шаг номер 2). Использова-ние любого языка возможно посредством вызова подпрограм, функций или функциональных блоков, написанных на любом языке, включая С. Это можно реализовать с помощью языков ST или IL.

10. Из каких рабочих окон состоит среда IsaGRAF? Их назначение и краткое описание. Вот главные пиктограммы ISaGRAF:Projects : Управление проектомLibraries : Управление библиотекойBook : Справочная система ISaGRAFDiagnosis : Система диагностики для пользователяRead Me : Информация о новой версии ISaGRAFReport : Стандартный отчёт об ошибках

11. Из каких технических средств состоит нижний уровень иерархической си­стемы дистанционного контроля и управления? Из каких технических средств состоит нижний уровень иерархической си­стемы дистанционного контроля и управления?Нижний уровень. Здесь выполняются функции по сбору, обработке, приему и передаче информации, функции локального управления технологиче-ским процессом, максимально приближенного к реальному времени. Уровень включает в себя следующие группы устройств:1.1. Датчики – выполняют нормированное преобразование физических ве-личин (как электрических, так и не электрических) в электрические. Выбор параметров и типа датчика определяются требованиями техно-логического процесса, а также возможностями проектируемой системы управления (здесь прежде всего определяют диапазоны измеряемых сигналов, их быстродействие, форматы получаемых электрических сигналов). 1.2. Исполнительные устройства (ИУ) – выполняют управляемое преобра-зование энергии источника питания в энергию необходимую для реа-лизации конкретной технологической операции. Энергия источника питания как правило электрическая, а энергия используемая для пере-мещения регулирующего органа – механическая. В таком случае ИУ – это электромеханический преобразователь. ИУ предусматривает воз-можность управления процессом преобразования энергии, для чего ис-пользуются управляемые преобразователи амплитуды, частоты, фазы электрической энергии источника (чаще всего, релейные или тири-сторные). 1.3. Управляемые преобразователи (УП) – устройства различной сложно-сти, обеспечивающие возможность изменения характеристик переда-ваемой исполнительным элементом энергии, проще говоря, регули-рующие выходной параметр исполнительного элемента (например ско-рость двигателя). Вид энергии зависит от типа ИУ и от места установ-ки УП – до или после ИУ по отношению к потоку энергии. К устройст-вам устанавливаемым до ИУ относятся тиристорные преобразователи, Входными параметрами УП может быть как один сигнал, так и совокуп-ность сигналов. Которые на выходе УП приобретают форму необходимую для регулирования ИУ. 1.4. Нормализаторы сигналов и согласующие устройства – выполняют пре-образование немасштабированного электрического сигнала некоторой формы, в нормированный унифицированный электрический сигнал и наоборот, кроме того могут обеспечивать гальваническую развязку. Как правило, датчик (собственно чувствительный элемент датчика) выдает ненормированный сигнал малой мощности, помехонезащищен-ный, что требует в соответствии с нормами международных стандартов приведения сигнала в некий унифицированный формат. Формат этот зависит от организации сети связи технических систем на соответст-вующем уровне АСУП. 1.5. Контроллеры – обеспечивают заданную последовательность работы, взаимодействие технологического оборудования. Это может выражать-ся в виде инициации процессов пуска и торможения двигателей, стаби-лизации и слежения за технологическими параметрами, простейшего анализа аварийных ситуаций и др. Наличие тех или иных функций мо-жет варьироваться в зависимости от сложности технологического про-цесса, типа контроллера и его места в иерархической АСУП. Контрол-лер может как включать функции связи с верхними уровнями системы автоматизации, так и работать автономно без связи с верхним уровнем АСУП.

12. Из каких уровней может состоять система дистанционного контроля и управления? В общем виде она может быть представлена в виде трехуровневой схемы:

Нижний уровень. Здесь выполняются функции по сбору, обработке, приему и передаче информации, функции локального управления технологиче-ским процессом, максимально приближенного к реальному времени. Средний уровень (микро-SCADA – Supervisory control and data acquisition – система диспетчерского контроля и сбора данных) . Этот уровень также можно назвать цеховым. Он выполняет функции сбора, обработки сигналов агрегата (цеха), передачу управляющих воздействий общего ха-рактера (переключение режимов работы оборудования, изменение мощ-ности и др.). Кроме традиционных функций, в последнее время наблю-даются тенденции внедрения подсистем прогнозирования аварийных си-туаций технологической линии. Понятно, что этот уровень целесообразно включать при разделении предприятия на цеха, в более простом варианте его внедрение не будет оправдано. Локальная станция цехового уровня обеспечивает интерфейс (взаимодействие) между диспетчером-оператором цеха и технологическим процессом, а также связь с верхним уровнем. Верхний уровень супервизорного контроля и управления (операторские станции SCADA, расчетные станции). Предназначен для отображения и обработки данных, формирования баз данных, посылки управляющих сигналов на нижние уровни системы, конфигурирования системы, проверки данных на достоверность, обеспечения поддержки выполнения ра-бот, связанных с поверкой измерительных каналов и другие работы.

Организационные блоки в инструментальной среде Step 7. Их разновидности, назначение и порядок запуска Организационные блоки образуют интерфейс между операционной системойCPU и программой пользователя. В организационных блоках определяется последовательность обработки программы пользователя. OB используются для исполненияопределенных разделов программы:o при запуске CPUo при циклическом или зависящем от времени исполнении программыo при возникновении ошибокo при возникновении аппаратных прерываний.Организационные блоки исполняются в соответствии с присвоенными им приоритетами. Организационный блок циклического выполнения программы (OB1)Операционная система CPU S7 исполняет OB1 непрерывно. Когда OB1 исполнен, операционная система начинает его обработку вновь. Циклическая обработка OB начинается по окончании стадии запуска. Вы можете вызывать в OB1 функциональные блоки (FB, SFB) или функции (FC, SFC).Принцип действия OB1OB1 имеет самый низкий приоритет среди всех OB, время выполнения которых контролируется, иными словами, все остальные OB, кроме OB90, могут прерывать выполнение OB1. Операционная система вызывает OB1 при следующих событиях:o Завершение запуска.o Конец обработки OB 1 (предыдущего цикла).Организационные блоки прерываний по времени (OB10 ? OB17)STEP 7 предоставляет в распоряжение до восьми прерываний по времени (OB 10 - OB 17), которые могут запускаться однократно или периодически. Вы можете так параметрировать Ваше CPU при помощи SFC или STEP 7, что эти OB будут обрабатываться со следующими интервалами:o Однократноo Ежеминутноo Ежечасноo Ежедневноo Еженедельноo Ежемесячноo В конце каждого месяцаПринцип действия OB прерываний по времениЧтобы запустить прерывание по времени, его необходимо вначале установить, а потом активировать. Существует три следующих способа запуска:Организационные блоки прерываний с задержкой(OB20 ? OB23)S7 предоставляет в распоряжение до четырех OB (OB 20 ? OB 23), которые исполняются после заданной задержки. Каждый OB прерывания с задержкой запускается посредством вызова SFC32 (SRT_DINT). Время задержки является входным параметром SFC.Когда Ваша программа вызывает функцию SFC32 (SRT_DINT), то ей передается номер OB, время задержки и индивидуальный код пользователя.Принцип действия OB прерываний с задержкойПо истечении времени задержки (его значение в миллисекундах передается блоку SFC32 вместе с номером OB) операционная система запускает соответствующий.Организационные блоки циклических прерываний(OB30 ? OB38)S7 представляет в распоряжение до девяти OB циклических прерываний (OB 30 ? OB38), которые прерывают Вашу программу через фиксированные интервалы времени. Следующая таблица показывает установленные по умолчанию интервалы времени и классы приоритета для OB циклических прерываний.Принцип действия OB циклических прерыванийЭквидистантные моменты запуска OB циклических прерываний определяются интервалом и фазовым сдвигом. Как связаны друг с другом момент запуска, периодичность и фазовый сдвиг, описано в /234/.OB ошибок резервирования CPU (OB72)Операционная система H CPU вызывает OB72, когда происходит одно из следующих событий:o Потеря резервирования CPUo Переключение на резервное ведущее устройствоo Ошибка синхронизацииo Ошибка в модуле синхронизацииo Прерывание обновленияo Ошибка сравнения (например, RAM, PIQ)OB72 выполняется всеми CPU, которые находятся в режиме RUN или STARTUP, после соответствующего стартового события.блок ошибок времени (OB80)Операционная система CPU S7-300 вызывает OB80, когда при обработке какого-либо OB возникает одна из следующих ошибок: превышение времени цикла, ошибка квитирования при исполнении OB, перевод часов вперед, так что пропускается время запуска OB. Если, например, стартовое событие для OB циклических прерываний возникает до того, как была закончена обработка предыдущего вызова, то операционная система вызывает OB80.

Если OB 80 не был запрограммирован, то CPU переходит в состояние STOP.

ОВ ошибок времени можно запретить или отложить и вновь разрешить с помощью SFC 39 ? 42.

Примечание

Если OB 80 в одном и том же цикле вызывается дважды из-за превышения времени цикла, то CPU переходит в состояние STOP. Вы можете этому воспрепятствовать вызовом SFC43 .RE_TRIGR. в подходящей точке программы.

Организационный блок неисправностей источника

питания (OB81)

Описание

Операционная система CPU S7-300 вызывает OB81, когда происходит событие, вызванное ошибкой или сбоем, связанным с источником питания (только для S7-400) или буферной батареей (при наступающем и при уходящем событии).

В отличие от ОВ для других асинхронных ошибок CPU в данном случае не переходит в режим STOP, если OB 81 не был запрограммирован.

OB неисправностей источника питания можно запретить или отложить и вновь разрешить с помощью SFC 39 ? 42.

Организационный блок диагностических прерываний

Описание

Если модуль, обладающий диагностическими свойствами, которому Вы разрешили диагностические прерывания, распознает ошибку, он выдает на CPU запрос на диагностическое прерывание (как при наступающем, так и при уходящем событии). Затем операционная система вызывает OB82.

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

Если OB 82 не был запрограммирован, то CPU переходит в состояние STOP.

OB диагностических прерываний можно запретить или отложить и вновь разрешить с помощью SFC 39 ? 42.

Организационный блок снятия/установки модулей

Описание

Установка и снятие модулей контролируется внутри системы каждую секунду.

Чтобы установка или снятие модуля распознавались CPU, необходимо чтобы между установкой и снятием прошло как минимум две секунды.

Каждая установка или снятие сконфигурированного модуля в режимах RUN, STOP и STARTUP (не разрешено удаление в этих режимах для блоков питания, CPU, адаптерных модулей и IM) приводит к прерыванию снятия/установки. Это прерывание вызывает у соответствующего CPU запись в диагностический буфер и в список состояний системы. Кроме того, в режиме RUN осуществляется запуск OB снятия/установки. Если этот OB не был запрограммирован, то CPU переходит в состояние STOP.

OB снятия/установки можно запретить или отложить и вновь разрешить с помощью SFC 39 ? 42.

Основные технические характеристики ПЛК фирмы SIEMENS линейки SIMATIC S7-300 (строение, разновидности CPU) Simatic S7-300 - семейство контроллеров средней производительности фирмы Siemens AG из семейства устройств автоматизации Simatic S7. В линейке контроллеров этого семейства по своей производительности занимает промежуточное положение между семействами S7-200 и S7-400. Количество поддерживаемых входов и выходов до 65536 дискретных/4096 аналоговых каналов. Конструкция контроллера модульная, модули монтируются на профильной шине (рельсе).

естественное охлаждение;

Основные технические характеристики ПЛК фирмы SIEMENS линейки SIMATIC S7-300 (строение, память, ее виды) Simatic S7-300 - семейство контроллеров средней производительности фирмы Siemens AG из семейства устройств автоматизации Simatic S7. В линейке контроллеров этого семейства по своей производительности занимает промежуточное положение между семействами S7-200 и S7-400. Количество поддерживаемых входов и выходов до 65536 дискретных/4096 аналоговых каналов. Конструкция контроллера модульная, модули монтируются на профильной шине (рельсе).

Simatic S7-300 - программируемый контроллер, предназначенный для построения систем автоматизации низкой и средней степени сложности. Основные особенности контроллера:

модульная конструкция, монтаж модулей на профильной шине (рельсе);

естественное охлаждение;

применение локального и распределенного ввода -вывода;

возможности коммуникаций по сетям MPI, Profibus Industrial Ethernet/PROFInet, AS-i, BACnet, MODBUS TCP;

поддержка на уровне операционной системы функций, обеспечивающих работу в реальном времени;

поддержка на уровне операционной системы аппаратных прерываний;

поддержка на уровне операционной системы обработки аппаратных и программных ошибок;

Свободное наращивание возможностей при модернизации системы;

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

Основные технические характеристики ПЛК фирмы SIEMENS линейки SIMATIC S7-300 (строение, интерфейсы взаимодействия) o Модульный программируемый контроллер для решения задач автоматизации низкого и среднего уровня сложности.

o Широкий спектр модулей для максимальной адаптации к требованиям решаемой задачи.

o Использование распределенных структур ввода-вывода и простое включение в сетевые конфигурации.

o Удобная конструкция и работа с естественным охлаждением.

o Свободное наращивание функциональных возможностей при модернизации системы управления.

o Высокая мощность благодаря наличию большого количества встроенных функций.

Программируемые контроллеры SIMATIC S7-300 имеют:

o сертификат соответствия и метрологический сертификат Госстандарта России;

o разрешение на применение федеральной службы по экологическому, технологическому и атомному надзору

o свидетельство Главного Управления Государственного Энергетического Надзора о взрывозащите IIC модулей SIMATIC S7 Ex исполнения;

o экспертное заключение о соответствии функциональных показателей интегрированной системы автоматизации SIMATIC S7 отраслевым требованиям и условиям эксплуатации энергопредприятий РАО "ЕЭС России";

o сертификат о типовом одобрении Российского Морского Регистра Судоходства.

o морские сертификаты ABS, BV, DNV, GLS, LRS, PRS, RINA;

o cертификаты DIN, UL, CSA, FM, CE;

Области применения

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

Конструктивные особенности

Программируемые контроллеры S7-300 могут включать в свой состав:

o Модуль центрального процессора (CPU). В зависимости от степени сложности решаемых задач в программируемом контроллере могут использоваться более 20 типов центральных процессоров.

o Блоки питания (PS) для питания контроллера от сети переменного или постоянного тока.

o Сигнальные модули (SM), предназначенные для ввода и вывода дискретных и аналоговых сигналов, в том числе FailSafe и модули со встроенными Ex-барьерами. Поддерживаются отечественные ГОСТ градуировки термометров сопротивления и термопар.

o Коммуникационные процессоры (CP) - интеллектуальные модули, выполняющие автономную обработку коммуникационных задач в промышленных сетях AS-Interface, PROFIBUS, Industrial Ethernet, PROFINET и системах PtP связи. Применение загружаемых драйверов для CP 341 позволяет расширить коммуникационные возможности контроллера поддержкой обмена данными в сетях MODBUS RTU и Data Highway. Для организации модемной связи в составе S7-300 могут использоваться коммуникационные модули семейства SINAUT ST7.

o Функциональные модули (FM) - интеллектуальные модули, оснащенные встроенным микропроцессором и способные выполнять задачи автоматического регулирования, взвешивания, позиционирования, скоростного счета, управления перемещением и т.д. Целый ряд функциональных модулей способен продолжать выполнение возложенных на них задач даже в случае остановки центрального процессора.

o Интерфейсные модули (IM) для подключения стоек расширения к базовому блоку контроллера, что позволяет использовать в системе локального ввода-вывода до 32 модулей различного назначения. Модули IM 365 позволяют создавать 2-, модули IM 360 и IM 361 - 2-, 3- и 4-рядные конфигурации.

3.Типовой набор встроенных технологических функций позволяет решать задачи скоростного счета, измерения частоты или длительности периода, ПИД-регулирования, позиционирования, перевода части дискретных выходов в импульсный режим. Все центральные процессоры S7-300 оснащены встроенным интерфейсом MPI, который используется для программирования, диагностики и построения простейших сетевых структур. В CPU 317 первый встроенный интерфейс имеет двойное назначение и может использоваться для подключения либо к сети MPI, либо к сети PROFIBUS DP.

Целый ряд центральных процессоров имеет второй встроенный интерфейс:

o CPU 31…-2 DP имеют интерфейс ведущего/ ведомого устройства PROFIBUS DP;

o CPU 31…C-2 PtP имеют интерфейс для организации PtP связи;

o CPU 31…-… PN/DP оснащены интерфейсом Industrial Ethernet, обеспечивающим поддержку стандарта PROFInet;

o CPU 31…T-2 DP оснащены интерфейсом PROFIBUS DP/Drive, предназначенным для обмена данными и синхронизации работы преобразователей частоты, выполняющих функции ведомых DP устройств.

Система команд центральных процессоров включает в свой состав более 350 инструкций и позволяет выполнять:

o Логические операции, операции сдвига, вращения, дополнения, операции сравнения, преобразования типов данных, операции с таймерами и счетчиками.

o Арифметические операции с фиксированной и плавающей точкой, извлечение квадратного корня, логарифмические операции, тригонометрические функции, операции со скобками.

o Операции загрузки, сохранения и перемещения данных, операции переходов, вызова блоков, и другие операции.

Для программирования и конфигурирования S7-300 используется пакет STEP 7.

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

Основными техническими требованиями при проектировании распределенных АСУ ТП Основными техническими требованиями при проектировании распреде-ленных АСУ ТП являются:

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

беспечение аппаратного и программного аварийного останова техно-логического комплекса при аварийных ситуациях;

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

беспечение высокоэффективного ЧМИ в системе визуализации и мо-ниторинга;

эффективная, с точки зрения скорости обнаружения неисправности, и надежная диагностика программно-аппаратных средств;

распределенная система электропитания;

обеспечение обмена данными по информационным каналом в реальном масштабе времени;

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

обеспечение широкого температурного диапазона работы техниче-ских средств локальных систем автоматического управления (САУ);

выбор оптимального, с точки зрения пылевлагонепроницаемости, а также защиты от электромагнитного излучения, коррозии и др. факто-ров, удовлетворяющего международным стандартам конструктива шкафа цехового контроллера, шкафов автоматики локальных САУ и автоматизированного рабочего места системного инженера (АРМ);

обеспечение надежного контура заземлений на каждой отдельной площадке объекта автоматизации;

защита контрольно-измерительных и информационных каналов от внешних воздействий, а также усиление передаваемых сигналов;

обеспечение обслуживающего персонала качественной эксплуатаци-онной документацией, а также инструментом для монтажа и диагно-стики.

Особенности языка FBD. Его достоинства и недостатки. Особенности редактора FBD:

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

" Редактор FBD можно использовать и с системой команд SIMATIC, и с системой команд МЭК 1131-3.

" Для отображения программы, созданной при помощи редактора SIMATIC FBD, всегда можно использовать редактор STL.

Язык FBD (Functional Block Diagram, Диаграмма Функциональных Блоков) является языком графического программирования, так же, как и LD, использующий аналогию с электрической (электронной) схемой. Программа на языке FBD представляет собой совокупность функциональных блоков (functional flocks, FBs), входа и выхода которых соединены линиями связи (connections). Эти связи, соединяющие выхода одних блоков с входами других, являются по сути дела переменными программы и служат для пересылки данных между блоками. Каждый блок представляет собой математическую операцию (сложение, умножение, триггер, логическое "или" и т.д.) и может иметь, в общем случае, произвольное количество входов и выходов. Начальные значения переменных задаются с помощью специальных блоков - входов или констант, выходные цепи могут быть связаны либо с физическими выходами контроллера, либо с глобальными переменными программы. Пример фрагмента программы на языке FBD приведен на рис. 2.

Практика показывает, что FBD является наиболее распространенным языком стандарта IEC. Графическая форма представления алгоритма, простота в использовании, повторное использование функциональных диаграмм и библиотеки функциональных блоков делают язык FBD незаменимым при разработке программного обеспечения ПЛК. Вместе с тем, нельзя не заметить и некоторые недостатки FBD. Хотя FBD обеспечивает легкое представление функций обработки как "непрерывных" сигналов, в частности, функций регулирования, так и логических функций, в нем неудобным и неочевидным образом реализуются те участки программы, которые было бы удобно представить в виде конечного автомата.

Прикладное программное обеспечение систем управления (6)

7. Особенности языка IL. Его достоинства и недостатки.

Список инструкций или IL - это язык низкого уровня. Инструкции всегда относятся к текущему результату (или IL регистру).

Оператор определяет операцию, которая должна быть выполнена с текущим результатом и операндом. Результат операции снова запоминается в текущем результате.

IL программа - это список инструкций. Каждая инструкция должна начи-наться с новой строки и должна содержать оператор, с дополнительным моди-фикаторами, если нужно, для специфических операций, один или несколько операндов, разделенных запятой (,). Инструкции может предшествовать метка с двоеточием (:). Если к инструкции присоединен комментарий, то он должен находиться в конце строки. Комментарий всегда начинается с (* и заканчива-ется *). Между инструкциями может быть введена пустая строка.

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

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

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

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

• Всевозможные каталоги. Например - пути до файлов данных, каталоги импорта/экспорта.
• Сетевые настройки. Имена серверов, 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.

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

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

Для программ на 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. Они становятся заметны только в достаточно сложных программах, где становится необходимо хранить списки однотипных параметров или же содержимое объектов с уровнем вложенности два или более.