Конфигурирование – это настройка ОС на реальное оборудование (hardware), (материнскую плату, видеоадаптеры, нестандартные устройства) и требования пользователя.
Способы конфигурирования ОС:
1) Командные файлы. Первый файл, который запускается – это autoexec.bat. Далее — config.sys, в котором прописываются драйверы нестандартных внешних устройств. Долгое время в config.sys прописывался драйвер компакт-диска:devise=C:mscdex.exe. Затем стал прописываться драйвер, подходящий для всех компакт-дисков.
В настоящее время это еще сохранилось в ОС.
2) С появлением Win 3.11 Microsoft ввела новый механизм конфигурирования ОС: INI – файлы. Главный из них – Win.INI, также program.INI, system.INI. В этих файлах прописаны параметры системы, которые настраиваются на конкретную среду конкретного пользователя.
Все INI – файлы разбиты на секции, выделенные квадратными скобками. В каждой секции есть своя структура. В Win.INI самой первой является секция [boot] с параметрами
Основы конфигурирования пульта С2000М в Pprog
Если в данной секции вписана какая-либо программа, то это значит, что в ОС есть вирус.
В system.INI первая секция – Windows.
3) Данный способ конфигурации касается ОС, сделанных на технологии Win NT, Win98, в них включено такое понятие как реестр.
Реестр – это иерархическая база данных, в которой хранятся параметры ОС, запуска программ, настройки всех программ.
Замечание: реестр – это постоянно используемая часть ОС. Т.е. любая программа может обратиться к нему и изменить его, читать значения и т.д., поэтому алгоритм работы с ним следующий:
3.1) при установке любой программы в ОС желательно сохранить реестр.
С реестром работают regedit – Win98, regedt32 – Win XP.
В XP реестр сохраняется самостоятельно и формирует точку восстановления. При запуске ОС загружается реестр и создается его копия. Копия нужна, для того чтобы если ОС правильно загрузилась, то копия фиксирует, что это правильная копия, и с нее в следующий раз будет загружаться ОС.
3.2) Если какая-либо программа испортила реестр, то ОС попытается загрузиться с предыдущей копии реестра.
3.3) Если испортилась и копия реестра, то ОС переходит в режим безопасной загрузки, отключая максимум драйверов, и пытается восстановить свои параметры, в том числе реестр.
Для безопасности можно создать папку, куда скопировать копию реестра. Также установленные программы нужно обязательно убирать через деинсталляцию, иначе останутся неиспользуемые ветви реестра, что приводит к тому, что реестр «разбухает». Это объясняется следующим фактом: при удалении данных из реестра они на самом деле остаются и занимают память, а только лишь не отображаются при просмотре реестра, что является значительным недостатком.
К программам чистки реестра относятся следующие:
regclean – находит некорректности и спрашивает: удалить их или нет;
twiuk up – программы конфигурирования компьютера для повышения его производительности, которые можно изменить до 200 внутренних настроек и norton utilites, однако качественную чистку реестра данные программы не обеспечивают..
Изучаем компьютер — Конфигурация системы MSconfig
Дата добавления: 2016-07-18 ; просмотров: 5233 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ
Источник: poznayka.org
Конфигурирование приложений
Прежде чем можно будет развернуть приложение на сервере приложений, необходимо запустить сервер приложений и затем сконфигурировать или собрать приложение. Это — процесс, посредством которого Вы указываете источники данных, отображения базы данных, ресурсы JNDI, и т.д.
Вы конфигурируете приложения J2EE путем изменения XML-файлов в META-INF и WEB-INF каталоги в архивах приложения. Выполнение этой задачи вручную утомительно и подвержено ошибкам. Инструмент развертывания JBoss позволяет Вам конфигурировать приложения, не имея необходимость разархивировать файлы EAR, файлы WAR или файлы JAR, поскольку инструмент позволяет Вам сконфигурировать эти файлы непосредственно.
Эта глава объясняет, как запустить сервер приложений и сконфигурировать и развернуть Ваше приложение.
Запуск сервера приложений
Для конфигурирования приложения с помощью инструмента развертывания необходимо соединиться с сервером запущенного приложения. Выполните эти шаги для запуска сервера приложений на компьютере.
- Администратор Сервера запуска, расположенный в /Applications/Server .
- В списке Компьютеров и Служб выберите Application Server.
- В области конфигурации нажмите Settings. От всплывающего меню Имени Конфигурации выберите надлежащую конфигурацию.
- Нажмите кнопку на панели инструментов Start Service. После нескольких секунд должен работать сервер приложений. Можно подтвердить, что JBoss работает путем доступа http://localhost:8080 в Вашем веб-браузере. Необходимо видеть, что названная веб-страница Добро пожаловать в JBoss/Tomcat.
Можно также запустить JBoss в Терминале со следующей командой:
$ /Library/JBoss/3.2/bin/run.sh -c deploy-standalone
Для получения подробной информации о действиях JBoss используйте develop конфигурация . Это полезно, когда необходимо удостовериться уведомления JBoss, когда Вы развертываете или не развертываете модуль, или когда необходимо определить, выдаются ли исключения, поскольку JBoss запускает развертываемое приложение. develop конфигурация производит подробный журнал действий JBoss. Более полезно при запуске сервера приложений из командной строки, потому что Вы видите результаты действий сразу в Окне терминала, из которого Вы запускаете сервер приложений.
Конфигурирование Вашего приложения
Следующие разделы учат Вас, как запустить инструмент развертывания и сконфигурировать Ваше приложение.
Запуск инструмента развертывания JBoss
Для запуска инструмента развертывания дважды щелкнуть DeploymentTool.woa в /Library/JBoss/Applications или введите следующую команду в Терминал:
$ /Library/JBoss/Applications/DeploymentTool.woa/DeploymentTool
С момента появляется Окно приложения Загрузки.
Примечание: Выполнение Инструмента Развертывания JBoss требует веб-браузера, поддерживающего Frames и Javascript. Некоторые веб-браузеры, возможно, должны иметь раскрывающееся отключенное блокирование.
Загрузка Вашего приложения
Окно приложения Загрузки — то, где Вы указываете расположение приложения или компонента, Вы хотите сконфигурировать. Несмотря на то, что окно названо Приложение Загрузки, можно также использовать инструмент развертывания для конфигурирования файлов EAR, файлов WAR и файлов JAR.
Рисунок 2-1 показывает Окно приложения Загрузки.
-
Введите полный путь в файл в текстовом поле в Окне приложения Загрузки и нажмите Load Application.
Примечание: Путь к файлу, который Вы вводите в текстовое поле, с точки зрения сервера, на котором работает инструмент развертывания. Т.е. если Вы получаете доступ к инструменту развертывания от веб-браузера, работающего на различном компьютере, архив, который Вы конфигурируете, должен находиться на сервере, не компьютере, на котором работает веб-браузер.
Обычно, Вы не можете сохранить приложение с недопустимыми XML-файлами. Т.е. необходимо сконфигурировать все элементы, обнаруживающиеся в красном в главном окне. Можно переопределить, это отменой выбора Проверяет XML-файлы в Окне приложения Загрузки. Однако Вы не можете быть в состоянии перезагрузить приложение, сохраненное в этом состоянии. После того, как инструмент развертывания загружает приложение, он выводит на экран Загруженное Окно приложения, показанное на рисунке 2-2 .
Рисунок 2-3 показывает компоненты petstore.ear архив . Следующий список описывает некоторые элементы в главном окне:
- PetStoreEAR (Приложение) Представляет архив корпоративного приложения Зоомагазина.
- Параметры настройки приложения , Нажимающие на эту ссылку, позволяют Вам конфигурировать настройки, влияющие на все модули в архиве, когда развертывается приложение.
- AsyncSenderEJB (EJB) Представляет архив (файл JAR), который содержит файлы, определяющие компонент уровня предприятия AsyncSender ( asyncsender-ejb.jar файл). Щелчок на ссылку Module Settings позволяет Вам сконфигурировать настройки всего модуля и установить значения по умолчанию для некоторых настроек для всех компонентов уровня предприятия, определенных в модуле. Посмотрите Конфигурируют Модуль Клиента для примера.
- PetStoreWAR (Веб-приложение) Представляет архив (файл WAR), который содержит файлы, определяющие веб-модуль корпоративного приложения Зоомагазина.
Конфигурирование компонентов приложения
Для конфигурирования компонента Вы выбираете его из главного окна путем щелчка на надлежащую ссылку. Это заставляет инструмент развертывания отображать окно конфигурации для компонента. Как Вы видите на рисунке 2-4 , это — снабженное вкладками окно, содержащее одну или более областей, которые Вы используете для конфигурирования определенных аспектов компонента.
Окно конфигурации также содержит область Quick Config , содержащую элементы компонента, который необходимо сконфигурировать для приложения, чтобы быть развертываемыми. Рисунок 2-4 показывает область Quick Config модуля CatalogEJB . Это указывает, что должны быть сконфигурированы ссылки ресурса JBoss. Ссылки ресурса JBoss также появляются в области JNDI Resource Refs. Однако необходимо сконфигурировать их в только одной из двух областей.
Примечание: Для приложений со многими компонентами можно хотеть сконфигурировать страницы Quick Config недопустимых компонентов и сохранить приложение. Тогда можно сконфигурировать каждый компонент далее постепенным способом.
Некоторые настройки применяются ко всему модулю, например, ролям безопасности. Кроме того, некоторые настройки модуля служат значениями по умолчанию для настроек отдельных компонентов в модуле. Рисунок 2-5 показывает некоторые настройки модуля модуля CustomerJAR petstore.ear приложение. Конфигурирование настроек модулей может помочь ускорить конфигурацию модуля. Посмотрите Конфигурируют Настройки Всего модуля для примера.
После конфигурирования элементов в области Вы нажимаете Update для подтверждения изменений. Следует иметь в виду, что изменения не сохраняются, пока Вы не сохраняете приложение.
Сохранение сконфигурированного приложения
Для сохранения сконфигурированного приложения, т.е. когда никакие компоненты не показаны в красном в главном окне, нажимают Save в вершине главного окна. Окно приложения Сохранения (рисунок 2-6) появляется.
Введите место назначения сконфигурированного приложения в текстовом поле Окна приложения Сохранения и нажмите Save Application.
Развертывание Вашего приложения
Для развертывания сконфигурированного приложения от инструмента развертывания просто сохраните приложение к /Library/JBoss/3.2/deploy в единственном развертывании серверов или /Library/JBoss/3.2/farm в кластерном развертывании .
Источник: spec-zone.ru
5.7. Управление конфигурацией программного обеспечения
Управление конфигурацией ПО — это один из вспомогательных процессов, поддерживающих основные процессы ЖЦ ПО, прежде всего процессы разработки и сопровождения ПО.
Под конфигурацией ПО понимается совокупность его функциональных и физических характеристик, установленных в технической документации и реализованных в ПО.
В крупном проекте большие объемы информации меняются очень быстро и неконтролируемые изменения могут быстро ввергнуть проект в хаос. Работая над программным проектом, группа программистов, тестеров и менеджеров сталкивается с проблемой отслеживания версий программ, внесения в них изменений. Чем больше проект, тем больше времени разработчики тратят на согласования изменений в исходных текстах и получения работающих версий программного продукта. Данная задача может усугубиться наличием в компании регионально удаленных групп-разработчиков.
Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ.
При групповой разработке сложных ПО, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, необходимо:
— выделить набор объектов, определяющих структуру будущей системы, чтобы затем контролировать их состояния и ход работ по каждому из них. Такими объектами могут быть функционально-логическая модель системы, реляционная модель базы данных, модули прототипов системы (экраны, меню, отчеты, тексты процедур или классов), системные и программные спецификации, документация, планы проведения тестирования, спецификации тестовых процедур;
— контролировать запросы на доработку модуля, сообщения о найденной ошибке или неисправности оборудования, запросы на модификацию оборудования или ПО, задания на установку рабочего места, задания разработчику, аналитику и т.п., так как эти объекты влияют на состояние текущих версий других объектов и относятся к сфере управления изменениями;
— вести журнал всех изменений, внесенных в систему в процессе разработки или сопровождения (это касается состояния создаваемой системы, бюджета, сроков, интерфейса, контрольных отчетов и т.д.);
— вести полный и достоверный архив всех версий всех объектов системы;
— контролировать состояние и развитие коллективно используемых компонентов ПО и их версий, учитывая связи компонентов системы для согласования между собой измененных частей; обеспечивать адекватность реально изменяющихся компонентов и их комплектной документации;
— проводить оценку конфигурации — оценивать функциональную полноту компонентов ПО, а также соответствие их физического состояния текущему техническому описанию.
— изготавливать эталонные копии ПО и документации, хранить и поставлять их пользователям в соответствии с порядком, принятым в организации. Это упрощает выпуск и поставку ПО;
— обеспечивать развитие всей системы, ограничивая усложнение проекта.
Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2.
Рассмотрим, как пример, управление исходным кодом.
Для групповой разработки важны системы контроля исходного кода. Такие системы решают, по крайней мере, две задачи: хранение всех версий каждого экземпляра исходного кода (версии файлов) и разрешение конфликтов одновременного доступа разработчиков к одному экземпляру исходного кода (слияние исходных текстов, согласованность группы файлов проекта и т.п.).
Контролю подвергается не только собственно код модулей, но и код скриптов генерации схемы базы данных, а также собственно схема базы данных, которая может храниться в виде версий бинарных файлов, экспортированных во внутренний формат СУБД схем баз данных.
Прикладные программисты должны придерживаться установленных правил групповой разработки.
После того как основной код модуля будет создан и зарегистрирован в системе контроля исходных текстов, каждая правка в нем должна быть помечена датой и именем автора правки. Правки должны сопровождаться ясными комментариями, которые располагаются в начале файла исходного кода.
Формат комментария к правке может быть таким:
10.01.2004 Ivanov: authorization bug fixed (found by Petrov)
Это делается для того, чтобы через некоторое время можно было понять, кто и зачем внес данную правку. Также это помогает корректировать слияние исходного кода, если система контроля обнаружила несовместность правок и не может разрешить ее сама.
Часто ведущие исполнители проектов не доверяют системам контроля исходного кода сливать правки в исходных текстах автоматически и частично или полностью контролируют этот процесс. Эта перестраховка во многих случаях себя оправдывает.
Также в начале исходного кода (в комментариях) описывается: для чего данный файл исходного кода создан, основные его функции, к какой части информационной системы он относится, кто автор.
Функции, структуры, наиболее важные переменные должны сопровождаться комментариями. Необходимо избегать непонятных названий вида 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 — утилита обеспечения стандартизованной и надежной компоновки готовых приложений.
Источник: libraryno.ru