Технологии программирования. 
Решение задач по программированию

В процессе разработки программных систем используются различные технологии программирования. В соответствии с обычным значением слова «технология» под технологией программирования (programming technology) понимается совокупность производственных процессов, приводящая к созданию требуемой ПС, а также описание этой совокупности процессов. Другими словами, технология программирования понимается здесь в широком смысле как технология разработки программных средств, включая в нее все процессы, начиная с момента зарождения идеи этого средства до создания необходимой программной документации. Каждый процесс этой совокупности базируется на использовании каких-либо методов и средств, например, компьютера (в этом случае речь идет о компьютерной технологии программирования).

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

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

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

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

1. Первый этап: «стихийное» программирование — отсутствие сформулированной технологии, когда программирование было, по сути, искусством. Этап охватывает период от появления первых ЭВМ до середины 60-х годов 20-го века. Развитие программирования шло по пути замены машинных языков ассемблерами, а затем алгоритмическими языками (Fortran, Algol) и повторного использования подпрограмм, что повысило производительность труда программиста.

Стихийно использовалась разработка «снизу вверх» — подход, при котором вначале проектировали и реализовали сравнительно простые подпрограммы, из которых потом пытались построить сложную программу [6]. В начале 60-х годов 20-го века разразился кризис программирования [1, 3]. Он выражался в том, что фирмы превышали все сроки завершения программных проектов и их стоимость. В результате многие проекты так и не были завершены.

2. Второй этап — структурный подход к программированию. Этот подход сложился в 60−70-е годы 20-го века и представлял собой совокупность рекомендуемых технологических приемов, охватывающих все этапы разработки программного обеспечения. В основе структурного подхода лежит декомпозиция сложных систем с целью последующей реализации в виде отдельных небольших подпрограмм. В отличие от используемого ранее процедурного подхода к декомпозиции, структурный подход требовал представления задачи в виде иерархии подзадач простейшей структуры.

Проектирование осуществлялось «сверху вниз» и подразумевало реализацию общей идеи, обеспечивая проработку интерфейсов подпрограмм. Вводились ограничения на конструкции алгоритмов, рекомендовались формальные модели их описания, а также специальный метод проектирования алгоритмов — метод пошаговой детализации. Поддержка принципов структурного программирования была заложена в основу процедурных языков программирования (PL/1, Algol-68, Pascal, C).

Появилась и начала развиваться технология модульного программирования, которая предполагает выделение групп подпрограмм, использующих одни и те же глобальные данные, в отдельно компилируемые модули. Практика показала, что структурный подход в сочетании с модульным программированием позволяет получить достаточно надежные программы, размер которых не превышает 100 000 операторов [3]. Узким местом модульного программирования стали межмодульные интерфейсы, ошибки в которых трудно обнаружить по причине раздельной компиляции модулей (ошибки выявляются только при выполнении программы).

3. Третий этап — объектный подход к программированию. Сложился с середины 80-х до конца 90-х годов 20-го века. Объектно-ориентированное программирование (ООП) определяется как технология создания сложного программного обеспечения, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного типа (класса), а классы образуют иерархию с наследованием свойств. Взаимодействие программных объектов осуществляется путем передачи сообщений.

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

Развитие объектного подхода в технологии программирования привело к созданию сред визуального программирования. Появились языки визуального объектно-ориентированного программирования, такие как Delphi, C++ Builder, Visual C++, C# и т. д. Однако технология ООП имеет и недостатки. Главный из них — зависимость модулей программного обеспечения от адресов экспортируемых полей и методов, структур и форматов данных. Эта зависимость объективна, так как модули должны взаимодействовать между собой, обращаясь к ресурсам друг друга.

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

Основы компонентного подхода были разработаны компанией Microsoft, начиная с технологии OLE (Object Linking and Embedding — связывание и внедрение объектов), которая применялась в ранних версиях Windows для создания составных документов. Ее развитием стало появление COM-технологии (Component Object Model — компонентная модель объектов), а затем ее распределенной версии — DCOM, на основе которых были разработаны компонентные технологии, решаются различные задачи разработки программного обеспечения.

Среди них следуют отметить OLE-automation — технологию создания программируемых приложений, обеспечивающую доступ к внутренним службам этих приложений. На основе OLE-automation создана технология ActiveX, предназначенная для создания программного обеспечения, как сосредоточенного на одном компьютере, так и распределенного. Безопасность и стабильная работа распределенных приложений обеспечивается еще двумя технологиями, заложенными в COM. Это MDS (Multitier Distributed Application Sever) — сервер многозвенных распределенных приложений, и MTS (Microsoft Transaction Server) — сервер управления транзакциями.

Компонентный подход лежит также в основе технологии CORBA (Common Object Request Bracer Architecture — общая архитектура с посредником обработки запросов объектов). Эта технология, которая реализует подход, аналогичный COM, разработана группой компаний OMC (Object Management Group — группа внедрения объектной технологии программирования). Программное ядро CORBA реализовано для всех основных аппаратных и программных платформ и обеспечивает создание программного обеспечения в гетерогенной вычислительной среде.

Важнейшая особенность современного этапа технологии программирования — широкое использование компьютерных технологий создания и сопровождения программных систем на всех этапах их жизненного цикла. Эти технологии получили название CASE-технологий (ComputerAided Software/System engineering — разработка программного обеспечения/программных систем с использованием компьютерной поддержки). Сегодня существуют CASE-технологии, поддерживающие как структурный, так и объектный, в том числе компонентный, подходы к программированию.

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

Во-первых, программное обеспечение перестало быть прерогативой нескольких компаний и стало частью повседневной жизни практически каждого жителя нашей планеты: ПК, Internet и мобильные телефоны — свидетельства этой грандиозной эволюции. Журналы и интернет-ресурсы за последние 25 лет кардинально изменились. До 1980 года для практиков основным источником сведений о программных технологиях был Datamation, сейчас существует несколько таких источников, например, IEEE Software, а также онлайновые ресурсы вроде Slashdot, которые тоже дают представление о последних шагах в эволюции технологий. Собран материал из множества отдельных источников данных, которые найдены в различных обзорах иwiki в программном мире. Для объективности К. Эберт обратился к своим коллегам из советов IEEESoftware и поинтересовался их представлением о технологиях, появившихся за последние 25 лет. На самом деле, точно определить время перехода на новый этап просто невозможно. Это относится, например, к объектноориентированной разработке, которая активно используется с 1990;х годов, но до сих пор не нашла своего применения в некоторых отраслях.

На рис. 1.1 показаны три основные группы программных технологий. Базовые технологии по мере своего развития влияют на массовые тенденции и дисциплины, и они применяются во всех областях и направлениях программной разработки. Большинство из известных сейчас таких технологий существуют последние 25 лет. Технологические концепции и методологии объединяют базовые методики, которые используются во многих различных отраслях и продуктах. Консолидированные технологии опираются на концепции и предоставляют готовые технические решения. В тех случаях, когда технологии принадлежат к двум таким группам, они отнесены к более общей группе.

Что имеют в виду, когда говорят, что программная технология «оказывает влияние»? Задавая этот вопрос разным людям, можно получить множество ответов, отражающих точку зрения конкретного собеседника. Профессор будет оценивать репутацию и исследовательские гранты и то, как технология поможет добиться этих целей. Ученый сформулирует свой ответ, учитывая инновационный потенциал. Менеджеров производства в первую очередь интересуют рентабельность, воплощение и инновационные продукты. Программный инженер будет иметь в виду полезность и эффективность при решении той проблемы, которой он занимается.

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

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

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

Каждая из этих тенденций оказывает серьезное влияние на инженерные продукты и на формирование программной отрасли. Microsoft с Windows или Sun с Java — пример того, как отдельная компания определяет развитие технологии, но технологии от этих производителей добились успеха благодаря тому, что они создавались и широко распространялись в отраслях. Невозможно даже представить себе Windows без Intel и всей экосистемы поставщиков и провайдеров сервисов. Точно так же банки создали банкоматы и разработали множество связанных с ними программных технологий, таких как распределенная и защищенная обработка транзакций. Компании розничной торговли стимулировали разработку кассовых аппаратов и необходимого программного обеспечения для поддержки цепочки поставки, в том числе штрих-коды и средства радиочастотной идентификации (RFID).

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

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

Безопасность впервые была признана ключевой технологией в ИТ инфраструктурах в конце 1980;х годов, когда вирус Jerusalem и червь Morris, по существу, парализовали Internet-трафик. Инциденты продолжались в 1990;х годах, поскольку технология применялась только как особая мера и без тщательного архитектурного анализа. Сейчас, по прошествии двадцати лет, вместе с новыми ИТ-продуктами наконец стали реализовать базовые принципы обеспечения безопасности. То же самое повторяется в отрасли телекоммуникаций — как показывают атаки в сфере IP-телефонии, здесь опять пока лишь создаются заплатки на особый случай, но без реального контроля. Промышленная автоматизация и другие предметные области еще больше отстают с внедрением инженерии обеспечения безопасности, как это продемонстрировал червь Slammer.

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

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

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

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

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

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

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

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

• 1. функциональность — способность ПС выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей. Набор указанных функций определяется во внешнем описании ПС;
• 2. надежность — устойчивость, точность выполнения предписанных функций обработки, возможность диагностики возникающих ошибок. Надежность (reliability) ПС — это ее способность безотказно выполнять определенные функции при заданных условиях в течение заданного периода времени с достаточно большой вероятностью. При этом под отказом в ПС понимают проявление в ней ошибки. Таким образом, надежная ПС не исключает наличия в ней ошибок — важно лишь, чтобы эти ошибки при практическом применении этого ПС в заданных условиях проявлялись достаточно редко. Убедиться, что ПС обладает таким свойством, можно при ее испытании путем тестирования, а также при практическом применении;
• 3. легкость применения — это характеристики ПС, которые позволяют минимизировать усилия пользователя по подготовке исходных данных, применению ПС и оценке полученных результатов, а также вызывать положительные эмоции определенного или подразумеваемого пользователя. Сюда следует также отнести дружественный интерфейс, контекстно-зависимую подсказку, хорошую документацию;
• 4. эффективность — это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов;
• 5. сопровождаемость, модифицируемость — это характеристики ПС, которые позволяют минимизировать усилия по внесению изменений для устранения в ней ошибок и по ее модификации в соответствии с изменяющимися потребностями пользователей, переходу на новые версии и т. п.;
• 6. мобильность (многоплатформенность) — независимость от технического комплекса вычислительных средств, операционной системы, сетевых возможностей, специфики предметной области задачи и т. д.;
• 7. коммуникативность — степень возможной интеграции с другими программами, обеспечение обмена данными между программами.

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

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

• 1. метрики размера программ;
• 2. метрики сложности потока управления программ;
• 3. метрики сложности потока данных программ.

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

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

К группе оценок размера программ можно отнести также и метрику Холстеда. Основу метрики Холстеда составляют четыре измеряемых характеристики программы:

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

n2- число уникальных операндов программы (словарь операндов);

N1 — общее число операторов в программе;

N2- общее число операндов в программе.

Опираясь на эти характеристики, получаемые непосредственно при анализе исходных текстов программ, М. Холстед вводит следующие оценки:

словарь программы.

`n=n1+n2` ,.

длину программы.

`N=N1+N2`.

объем программы.

`V=N*log2(n)(bit)`.

Под битом подразумевается логическая единица информации — символ, оператор, операнд.

Далее М. Холстед вводит n*- теоретический словарь программы, т. е. словарный запас, необходимый для написания программы, с учетом того, что необходимая функция уже реализована в данном языке и, следовательно, программа сводится к вызову этой функции. Используя n*, Холстед вводит оценку: V*.

V*=n* *log2n*.

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

Вторая наиболее представительная группа оценок сложности программ — метрики сложности потока управления программ. Как правило, с помощью этих оценок оперируют либо плотностью управляющих переходов внутри программ, либо взаимосвязями этих переходов. И в том, и в другом случае стало традиционным представление программ в виде управляющего ориентированного графа G=(V, E), где V — вершины, соответствующие операторам, а E — дуги, соответствующие переходам.

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

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

`Z (G)=e-v+2p`.

где e — число дуг ориентированного графа G ;

v — число вершин;

p — число компонентов связности графа.

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

Одной из наиболее простых, но, как показывает практика, достаточно эффективных оценок сложности программ является метрика Т. Джилба, в которой логическая сложность программы определяется как насыщенность программы выражениями типа IF-THEN-ELSE. При этом вводятся две характеристики:`GL` - абсолютная сложность программы, характеризующаяся количеством операторов условия; `cl` - относительная сложность программы, характеризующаяся насыщенностью программы операторами условия, т. е. `cl` определяется как отношение `CL` к общему числу операторов.

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

Пара «модуль, глобальная переменная» обозначается как `(p, r)`, где `P` - модуль, имеющий доступ к глобальной переменной `r`. В зависимости от наличия в программе реального обращения к переменнойформируются два типа пар «модуль, глобальная переменная»: фактические и возможные. Возможное обращение к с помощью p показывает, что область существования включает в себя .

Характеристика `Aup` говорит о том, сколько раз модули up действительно получали доступ к глобальным переменным, а число `Pup` - сколько раз они могли бы получить доступ. Отношение числа фактических обращений к возможным определяется как `Rup=Aup / Pup`. Эта формула показывает приближенную вероятность ссылки произвольного модуля на произвольную глобальную переменную. Очевидно, чем выше эта вероятность, тем выше вероятность «несанкционированного» изменения какой-либо переменной, что может существенно осложнить работы, связанные с модификацией программы.

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

`F` :`F=N (kom)/N (ctr)`.

где N (com) — количество комментариев в программе; N (ctr) — количество строк или операторов исходного текста.

Таким образом, метрика F отражает насыщенность программы комментариями. Исходя из практического опыта, принято считать, что F>=0.1, т. е. на каждые десять строк программы должен приходиться минимум один комментарий. Как показывают исследования, комментарии распределяются по тексту программы неравномерно: в начале программы их избыток, а в середине или в конце — недостаток. Причина в том, что в начале программы, как правило, расположены операторы описания идентификаторов, требующие более «плотного» комментирования. Кроме того, в начале программы также расположены «шапки», содержащие общие сведения об исполнителе, характере, функциональном назначении программы и т. п. Такая насыщенность компенсирует недостаток комментариев в теле программы, и поэтому формула (4) недостаточно точно отражает комментированность функциональной части текста программы.

К другим характеристикам программ следует отнести:

• *состав функций обработки информации, определенный функциональными требованиями к программной системе;
• *объем файлов, используемых программной системой;
• *требования к операционной системе и компьютерной технике и др.
• *Все программы по характеру использования и категориям пользователей можно разделить на два класса — утилитарные программы и программные продукты. Первые предназначены для удовлетворения нужд их разработчиков (программы для себя), но не для широкого распространения. Вторые (программные продукты) используются для удовлетворения потребностей пользователей, широкого распространения и продажи.
• *Существует большое количество различных компаний, занимающиеся разработкой проприетарного программного обеспечения (proprietary software). Этим термином обозначают программное обеспечение, которое имеет собственника, осуществляющего контроль над этим программным обеспечением и определяющего собственные лицензионные соглашения по использованию программного продукта. Наиболее типичными ограничениями проприетарного ПО являются:
• *1. ограничение на коммерческое использование. Существует большое количество проприетарных программных продуктов, которое можно использовать бесплатно в некоммерческих целях для частных лиц, медицинских и учебных заведений, для некоммерческих организаций и т. д. Такое программное обеспечение очень популярно и широко используется, а за счет своей бесплатности имеет хорошую техническую поддержку со стороны специалистов, у которых отсутствует необходимость дополнительных затрат на обучение;
• *2. ограничение на распространение. Этот вид ограничений сопровождает обычно крупные программные проекты, когда правообладатель требует оплаты за каждую копию программы. Обычно с таким ограничением применяются программные продукты, ориентированные на узкий «профессиональный» сегмент рынка, или программное обеспечение, требующееся большому числу пользователей. Примером может служить пакет программ Adobe CS3 или операционная система Microsoft Windows XP;
• *3. ограничение на модификацию. Этот вид ограничения используется только в программных пакетах с закрытыми исходными кодами и может запрещать или ограничивать любую модификацию программного кода, дизассемблирование и декомпиляцию.
• *В настоящее время существуют и другие варианты легального распространения программных продуктов, которые появились с развитием Интернета:
• *1. freeware — бесплатные, свободно распространяемые программы. Очень много серьезных компаний писали, пишут и будут писать freeware-программы. Дело в том, что freeware — прекрасный инструмент в продвижении новых технологий и продуктов. Например, всем известна программа общения ICQ. Это популярный бесплатный продукт, который имеет очень сильные позиции в сравнении с платными программами. Некоторые shareware-программы становятся бесплатными. Всем известный мультимедиа-проигрыватель Winamp первоначально был shareware-программой стоимостью в $ 10. Однако, после того как сайт winamp.com стал привлекать большое количество посетителей, разработчики, получая солидные доходы от рекламы, решили сделать свой продукт бесплатным, еще надежнее увеличив рост его популярности и своих доходов;
• *2. shareware — условно-бесплатные программы. Употребляется и еще одно наименование этого типа ПО — «пробное» (trial). Основное достоинство shareware — «попробуй, прежде чем купить» (try before you buy). Пользователю предоставляется продукт с некоторыми ограничениями, «на пробу», пока он его не приобретет. Ограничения могут быть функциональными и/или временными (чаще всего программа работает 30 дней или определенное количество запусков). Если пользовать решает, что это программа ему нужна, он должен зарегистрироваться, заплатив автору определенную сумму, в противном же случае обязан прекратить использование программы и удалить ее со своего компьютера;
• *3. public domain software — очень похожие на freeware программы. Распространяются бесплатно. Однако, в отличие от freeware, где автор программы имеет все права на программу, в случае с public domain у него эти права отсутствуют. Программа распространяется вместе с исходным кодом, и автор отказывается от своих прав. Главной идеей было развитие программы в дальнейшем. Однако в силу того, что программа была «ничья», кто угодно мог слегка модифицировать код, откомпилировать и распространять ее как платную. По этой причине таких программ в настоящее время просто не найти;
• *4. open source. Представляет собой развитие концепции public domain software, в которой учтены ошибки этого варианта. Программа, как и раньше, распространяется на бесплатной основе вместе с исходным кодом. Однако автор уже не отказывается от своих прав. Существует система требований к лицензии на программный продукт, который называется The Open Source Definition (OSD), которая представлена на сайте. К программе обязательно должен быть приложен исходный код. Модифицированное ПО должно распространяться на тех же условиях, что и исходный продукт. Автор исходного продукта даже имеет право требовать, чтобы исходный код его программы распространялся без изменений, но в комплекте с соответствующими модифицирующими исправлениями.
• *Существуют и другие, можно сказать, экзотические варианты распространения программ. Например:
• *1. adware. К этой категории относятся программы, которые во время своей работы демонстрируют пользователю рекламу, обычно графические баннеры размером 468×60 точек. Adware сочетает в себе freeware и shareware. С одной стороны, пользователь не обязан оплачивать программу и может ею пользоваться сколь угодно долго; с другой — у него есть стимул оплатить программу, ведь в этом случае он избавится от баннера, который так долго его нервирует. Наибольшее развитие этот тип получил в программах, которые работают в Интернете, ведь именно оттуда скачивается новая реклама. Например: браузеры, download-менеджеры и программы дозвона;
• *2. donationware. Такое ПО также распространяются бесплатно, однако разработчик программы в лицензионном соглашении указывает, что если пользователю программа нравится, то он может (а не обязан) выслать денежное вознаграждение. К сожалению, как показывает практика, пользователи очень вяло реагируют на такие просьбы и очень редко высылают деньги.
• *Ряд производителей использует OEM-программы (Original Equipment Manu-facturer), т. е. встроенные программы, устанавливаемые на компьютеры или поставляемые вместе с компьютером.
• *Программный продукт должен быть соответствующим образом подготовлен к эксплуатации (отлажен), иметь необходимую техническую документацию, предоставлять сервис и гарантию надежной работы программы, иметь товарный знак изготовителя, а также код государственной регистрации.

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

По умолчанию Windows® 7 и Windows Server® 2008 R2 предоставляют три схемы управления питанием: сбалансированная, энергосберегающая и с высокой производительностью. Эти схемы можно настроить для имеющихся систем или создать новые на основе существующих. Чтобы создать схему управления питанием, наилучшим образом подходящую для определенной системы, поэкспериментируйте с различными параметрами, а затем протестируйте итоговую производительность.

Общие настраиваемые параметры, влияющие на срок службы батареи Параметры могут зависеть от варианта работы компьютера: от электросети (AC) или от батарей (DC). Можно настроить следующие параметры.

*Яркость экрана Уменьшение яркости экрана является самым эффективным способом сокращения энергопотребления мобильным компьютером при включенном экране. Дисплей портативного компьютера потребляет наибольшее количество энергии — для него требуется до 40 процентов общего объема электроэнергии, предназначенного для системы. По умолчанию Windows значительно уменьшает яркость экрана, когда мобильный компьютер работает от батареи. В зависимости от оборудования и потребностей пользователей можно установить более низкое значение параметра яркости экрана по умолчанию, чтобы продлить срок работы батареи, или задать более высокое значение, чтобы облегчить чтение с экрана.

*Уменьшение яркости экрана По умолчанию портативные компьютеры, работающие под управлением Windows® 7 и Windows Server® 2008 R2, настроены на уменьшение яркости экрана после определенного периода бездействия. Этот процесс предшествует действию, называемому Время ожидания выключения экрана, когда экран выключается полностью. Таким образом можно сэкономить немалое количество электроэнергии для периодически используемого портативного компьютера.

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

*Время ожидания выключения жесткого диска Хотя жесткий диск (HDD) не является основным потребителем электроэнергии в обычных мобильных ПК, для экономии энергии можно увеличить время ожидания выключения жесткого диска. Если жесткий диск некоторое время находится в состоянии простоя, его двигатель остановится. При следующем доступе компьютера к жесткому диску время отклика системы может увеличиться, поскольку жесткий диск снова начинает набирать скорость.

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

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

*Режимы экономии энергии беспроводного адаптера По умолчанию Windows устанавливает для режима энергосбережения 802.11 значение «Максимальная производительность» при работе как от сети, так и от аккумулятора. В такой конфигурации беспроводной адаптер остается активным даже при отсутствии передачи данных. Это позволяет избежать проблем совместимости между некоторыми беспроводными адаптерами и точками доступа, которые несовместимы с режимами энергосбережения 802.11.

Если для дополнительной экономии электроэнергии и продления срока работы батарей создаются настраиваемые политики энергопотребления, проконсультируйтесь с производителем беспроводного оборудования по поводу результатов изменения значения политики энергопотребления наМаксимальное энергосбережение или Среднее энергосбережение. Параметры питания для каждой встроенной конфигурации питания можно изменить вручную. Дополнительные сведения об этих параметрах и других общих настраиваемых параметрах питания см. в статье Мобильные решения в области срока службы батареи. Руководство для профессионалов по разработке мобильных платформ (может быть на английском языке). Оптимизация использования памяти может преследовать две цели — увеличение объема памяти, доступной приложениям, и повышение быстродействия обращений к памяти. На старых машинах, когда объем установленной физической памяти не превышал единиц мегабайт, зачастую приходилось чем-то жертвовать; в современных системах достижение обеих целей уже не противоречит друг другу. Нет сомнений в том, что, чем больше установленный объем ОЗУ, тем лучше — компьютер будет мощнее: он позволит загружать приложения, особо «жадные» до памяти; увеличить число одновременно работающих приложений (в многозадачной ОС); ускорить работу. Однако для обеспечения возможности использования памяти в ряде случаев требуются некоторые дополнительные действия по конфигурированию компьютера.

В системах с размером установленной памяти более 640 Кбайт возможны различные варианты использования последних 384 Кбайт из первого мегабайта физической памяти:

• *память не используется;
• *область (или часть ее) перемещается в конец дополнительной памяти;
• *область (или часть ее) используется в качестве теневой (Shadow) памяти адаптеров и ROM BIOS.

Перемещение неиспользуемого остатка первого мегабайта в конец дополнительной памяти (разрешается установкой параметра Memory Relocation в CMOS Setup) возможно не всегда. Обычно такое перемещение становится невозможным, если хоть часть из этого кусочка используется в качестве теневой памяти.

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

Иногда BIOS предлагает такое распределение памяти, при котором под стандартную память выделяются 512 Кбайт, а остальная память идет как расширенная. Пользу такого распределения оценить трудно. При этом вышесказанное про верхние 384 Кбайт становится справедливым для оставшихся 512 Кбайт, правда, на возможность их перемещения в конец дополнительной памяти ограничения будут мягче.

Острее всего проблема обеспечения доступности памяти стоит для приложений MS-DOS, исполняемых в среде этой системы. Обычно «битва» идет за килобайты стандартной памяти (conventional memory), доступной приложениям. Из 640 Кбайт после загрузки ОС и необходимых резидентных драйверов на долю приложений может остаться около 500 Кбайт, а то и меньше, что для ряда приложений неприемлемо. Несмотря на повсеместное внедрения ОС типа Windows 9х, интерес к запуску больших приложений MS-DOS (например, бухгалтерских программ, в том числе и принудительно распространяемых налоговыми органами, а также игр) сохраняется и поныне. Сообщение о нехватке памяти на компьютере с ОЗУ размером, например, 32 Мбайт для приложения, скромно просящего всего 590 Кбайт, неприятно удивляет неискушенных пользователей. Однако эта нехватка не фатальна, если правильно выбрать версию и способ загрузки ОС. Все программные настройки, влияющие на объем доступной памяти, кроются в файлах CONFIG. SYS и AUTOEXEC. BAT, размещенных в корневом каталоге загрузочного диска.

Понимая проблемы, возникающие в связи с использованием памяти различными процессорами, для DOS-приложений можно рекомендовать следующие версии MS-DOS, оптимальные по размеру свободной стандартной памяти:

• *для компьютеров класса XT на процессорах 8086/88 — MS-DOS 3.30;
• *для компьютеров класса AT на процессорах 80 286 — MS-DOS 5. x;
• *для компьютеров класса AT на процессорах 80 386 и выше — MS-DOS 6.2x (правда, одно время встречались некачественные системные платы для 80 386, на которых MS-DOS 6.2x отказывалась загружаться в НМА, хотя MS-DOS 5. x работала нормально).

Кроме MS-DOS, существуют и другие операционные системы реального режима, совместимые с MS-DOS (например, PC DOS, DR DOS, COMPAQ DOS). Каждая из них имеет свои преимущества и недостатки по сравнению с соответствующим поколением MS-DOS, но их обсуждение выходит за рамки данного пособия. Операционные системы (и оболочки) защищенного режима на компьютеры с процессором класса ниже 386 пытаться устанавливать почти бессмысленно. Система MS-DOS 3.3 (более ранние рассматривать не будем) загружалась целиком в стандартную память, но была довольно компактной и оставляла приемлемое место для приложений своего времени. Когда вышла MS-DOS версии 4 с более развитыми возможностями, появившимися ценой ее разрастания, многие приложения отказывались работать в ее среде именно из-за нехватки памяти, и эта версия ОС широкого распространения не получила. Более удачной стала версия 5, которая «научилась» использовать «высокую память» (НМЛ) на компьютерах с процессором 286 и выше, если таковая присутствовала. Для этого был введен специальный драйвер высокой памяти, и в файле CONFIG. SYS должны присутствовать строки:

DEVICE=[]HIMEM.SYS (загрузка драйвера высокой памяти).

DOS=HIGH (указание на загрузку ОС в высокую память) Конечно, в верхнюю память загружается не вся ОС — часть все-таки попадает и в стандартную память. Кроме того, в стандартную память загружаются и резидентные драйверы — например, русификаторы клавиатуры и экрана, драйвер мыши и т. п. Все они отрывают свой кусок от памяти, которую могли бы использовать приложения. На компьютерах с 32-разрядными процессорами (386 и выше), имеющих механизм страничной переадресации, появилась возможность использования «верхней памяти» (UMA) с помощью драйвера EMM386.EXE. Этот драйвер отыскивает в области UMA (A0000-FFFFFh) регионы, не занятые памятью устройств, и отображает их на области доступной дополнительной памяти. В эти регионы, нормально адресуемые процессором в реальном режиме, можно помещать модули операционной системы и загружаемые драйверы; их же могут использовать и приложения.

Для наиболее компактной загрузки MS-DOS версий 5 и выше (а также Windows 9х, которая может представляться как MS-DOS 7) в файле CONFIG. SYS должны быть следующие директивы:

DEVICE=[]HIMEM.SYS (загрузка драйвера высокой памяти);

DEVICE=[]EMM386.EXE (загрузка диспетчера расширенной памяти);

DOS=HIGH. UMB (указание на загрузку ОС в высокую и верхнюю память).

Резидентные драйверы (русификаторы клавиатуры, экрана и принтера, драйвер мыши) по умолчанию обычно загружаются в стандартную память. Если приложениям MS-DOS не хватает свободной памяти, то, по крайней мере, часть резидентных драйверов можно загрузить в верхнюю память UMA. Для драйверов, загружаемых из файла CONFIG. SYS, вместо команды DEVICE" следует использовать команду DEVICEHIGH [/L:n[, m]]=, которая попытается загрузить драйвер в n-регион UMB. Необязательный параметр m задает требуемый объем памяти (он может отличаться от размера файла с драйвером). Ключ загрузки /L вместе с параметрами n, m используется для ручной оптимизации памяти. Если драйверу требуется выделить несколько областей памяти, то они перечисляются в списке вида /L:nl[, ml]: n2[, m2][;…]. Для резидентных программ, загружаемых из файла AUTOEXEC. BAT, тем же целям служит команда LOADHIGH (LH) с аналогичными необязательными параметрами, задающими размер одной или нескольких областей UMA. Строка запуска будет иметь вид:

LH[/L:n[, m]] [].

Посмотреть текущее положение свободных блоков памяти можно командой MEM/F из командной строки DOS/Windows. Чтобы не заниматься ручной оптимизацией памяти, в состав DOS/Windows введена диалоговая утилита MEMMAKER. EXE, которая за несколько этапов расставит требуемые команды в файлах CONFIG. SYS и AUTOEXEC.BAT. До ее запуска в этих файлах должны присутствовать ссылки на все необходимые драйверы и программы. Файл CONFIG. SYS должен начинаться с вышеприведенных трех строк (если не указать DOS=HIGH, утилита может «постесняться» использовать высокую память для загрузки DOS). Запуск нерезидентных приложений, а также оболочки типа Norton Commander из файла AUTOEXEC. BAT на время работы MEMMAKER следует отменить (MEMMAKER несколько раз перезагружает компьютер и автоматически запускается после отработки файла AUTOEXEC. BAT). При начальном запуске MEMMAKER спрашивает, требуется ли память EMS для приложений, и, если нет, то установит ключ NOEMS в строке запуска EMM386.

Для того чтобы в верхнюю память поместилось как можно больше модулей, ее следует оптимизировать. Оптимизация UMA подразумевает такое конфигурирование базовых адресов буферной и постоянной памяти адаптеров, при котором свободные области UMA получались бы максимально возможного размера. Нужно стремиться к плотному соединению областей UMA, занимаемых адаптерами. Тогда максимальный размер блоков UMB увеличится, и драйвер типа EMM386 сможет разместить в нем более крупные модули, что, в свою очередь, позволит освободить дополнительное место в остродефицитной стандартной памяти. Если на конфигурирование адаптеров не обращать внимания, то может оказаться, что два компьютера с одинаковым составом аппаратных средств и программным обеспечением будут после загрузки ОС иметь значительно различающиеся размеры стандартной памяти.

Многие адаптеры (контроллеры SCSI, адаптеры локальных сетей и др.) позволяют задавать адреса областей встроенных RAM и ROM, отображаемых в пространство памяти компьютера. Это позволяет разрешать (или, наоборот, создавать) конфликты использования UMA, а также оптимизировать использование ее блоков. При конфигурировании устанавливаемых адаптеров необходимо исключить перекрытия занимаемых адресов, поскольку из-за этого, скорее всего, ни одно из конфликтующих устройств работать не будет. Самый неприятный (трудно устранимый) конфликт возникает, если при конфигурировании какого-либо адаптера его память перекрывает буфер или BIOS графического адаптера. Если конфигурирование осуществляется джамперами, то вернуть нормальную конфигурацию труда не составит. А если адаптер конфигурируется только с помощью специальной утилиты, изменяющей содержимое его энергонезависимой памяти, то изменить его конфигурацию можно, лишь загрузив и выполнив соответствующую утилиту. Но при конфликте с графическим адаптером это сделать не так-то просто — в лучшем случае удастся загрузить компьютер со «слепым» экраном, а в худшем — POST откажется продолжать тестирование и загрузку, обнаружив ошибку графического адаптера и сообщив об этом попискиванием динамика. Но эта ситуация не так безнадежна: есть еще в природе графический адаптер MDA, у которого видеобуфер не совпадает по адресам с распространенными адаптерами EGA и VGA, а расширение BIOS у него отсутствует. Вставив неудачно сконфигурированную плату в компьютер с адаптером MDA (и, конечно, соответствующим монитором), можно утилитой задать правильную конфигурацию. Однако этот способ для новых компьютеров, не имеющих слотов шины ISA, уже непригоден.

Кроме занимаемого пространства, оптимизация использования UMA касается, как ни странно, и быстродействия. Для областей памяти адаптеров часто бывает полезным применение теневой памяти. Управление теневой памятью осуществляется через CMOS Setup для определенных областей. Поэтому, размещая конфигурируемые области памяти, иногда следует учитывать возможности задания границ теневой памяти в CMOS Setup. Необходимо помнить, что Shadow ROM блокирует запись, a Shadow RAM игнорирует возможность изменения со стороны адаптера затеняемой области памяти, что приведет к ошибкам при некорректном использовании теневой памяти. Для процессоров 386 и выше теневую память может организовать и драйвер EMM386, но этой его функцией пользуются редко.

Работу приложений в среде MS-DOS, в которой активно используется программный код BIOS, значительно ускоряет затенение ROM BIOS, как системной, так и BIOS графического адаптера и дискового контроллера. Для многозадачных ОС защищенного режима (Windows и др.) затенение ROM BIOS ускоряет только начальный процесс загрузки ОС, поскольку в рабочем режиме здесь в основном используются драйверы, загружаемые в ОЗУ.

Приложения ОС Windows пользуются виртуальной памятью, и никакие старые спецификации EMS и XMS им не нужны. Суммарный объем виртуальной памяти, доступной всем приложениям, определяется размером ОЗУ и файлов подкачки (их может быть и несколько). В Windows 9x размер файла подкачки изменяется динамически, по мере потребностей системы. Для того чтобы приложениям хватало памяти, на диске, несущем файл подкачки, должно быть достаточно свободного пространства (десятки и сотни мегабайт). Конечно же, важен и объем установленной физической памяти — ее малый объем может быть принципиальным ограничением на запуск ряда приложений или установку операционных систем. При малом объеме ОЗУ свопинг (подкачка страниц) будет слишком интенсивным, в результате чего скорость работы приложений существенно снижается (обращения к диску выполняются на несколько порядков медленнее, чем к ОЗУ). Приложения реального времени (например, аудиои видеопроигрыватели и тем более кодеры) могут стать неработоспособными именно из-за малого объема ОЗУ. Поскольку файл подкачки изменяет свой размер в процессе работы, важно следить за фрагментацией диска, несущего этот файл — обращение к фрагментированному файлу выполняется медленнее, чем к нефрагментированному. При выборе диска для размещения файла подкачки следует учитывать его быстродействие — время доступа и скорость передачи данных. При использовании приложений реального времени, интенсивно обменивающихся с дисками (те же проигрыватели и кодеры, а также программы, записывающие компакт-диски), по возможности файл подкачки следует размещать на других дисках.

Если на компьютере под управлением ОС защищенного режима (Windows, Unix, OS/2…) перестают запускаться приложения с сообщениями о недостаточном объеме оперативной памяти — проверьте наличие свободного места на жестких дисках, используемых для подкачки. Если памяти не хватает приложениям MS-DOS — проверьте файлы AUTOEXEC. BAT и CONFIG. SYS и запустите утилиту MEMMAKER или выполните ручную оптимизацию памяти.

Увеличение физического объема оперативной памяти в ряде случаев может привести к неожиданному снижению производительности компьютера. Это возможно, когда системная плата (или процессор со вторичным кэшем) не способна кэшировать весь объем ОЗУ. У многих системных плат для процессоров Pentium кэшируются только первые 64 Мбайт ОЗУ; у первых процессоров Pentium II кэшировались только 512 Мбайт. Память, выходящая за размеры кэшируемой области, конечно же, доступна, но ее производительность гораздо ниже кэшируемой. ОС Windows 9x распределяет память, начиная с верхней границы доступной памяти, причем наверх попадает ее ядро, скорость работы которого существенна для работы многих приложений. Если после увеличения ОЗУ ядро попадает в некэшируемую область, можно наблюдать снижение производительности. Для лечения этого недуга можно воспользоваться условно-бесплатной программой W2CACHE.COM, которая запускается в начале загрузки Windows и, оставаясь резидентной, «съедает» верхнюю часть памяти, заставляя ядро Windows загружаться в нижнюю, кэшируемую область. После окончания загрузки Windows программа освобождает занимаемую память, и ОС отдает ее в распоряжение приложений.

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

Программа «Просмотр событий» представляет собой оснастку консоли управления Microsoft (MMC) и предназначена для просмотра и управления журналами событий. Это незаменимый инструмент для наблюдения за работоспособностью системы и устранения возникших неполадок. Служба Windows, которая управляет протоколированием событий, называется «Журнал событий». В том случае, если она запущена, Windows записывает важные данные в журналы. При помощи программы «Просмотр событий» вы можете выполнять следующие действия:

Просматривать события определенных журналов;

Применять фильтры событий и сохранять их для последующего использования в виде настраиваемых представлений;

Создавать подписки на события и управлять ими;

Назначать выполнение конкретных действий на возникновение определенного события.

Запуск приложения «Просмотр событий» .

Приложение «Просмотр событий» можно открыть следующими способами:

Нажмите на кнопку «Пуск» для открытия меню, откройте «Панель управления», из списка компонентов панели управления выберите «Администрирование» и из списка административных компонентов стоит выбрать «Просмотр событий» ;

Откройте «Консоль управления MMC». Для этого нажмите на кнопку «Пуск», в поле поиска введите mmc, а затем нажмите на кнопку «Enter». Откроется пустая консоль MMC. В меню «Консоль» выберите команду «Добавить или удалить оснастку» или воспользуйтесь комбинацией клавиш Ctrl+M. В диалоге «Добавление и удаление оснасток» выберите оснастку «Просмотр событий» и нажмите на кнопку «Добавить». Затем нажмите на кнопку «Готово», а после этого — кнопку «ОК» ;

Воспользоваться комбинацией клавиш WIN +R для открытия диалога «Выполнить». В диалоговом окне «Выполнить», в поле «Открыть» введите eventvwr. msc и нажмите на кнопку «ОК.

Журналы событий в Windows 7.

В операционной системе Windows 7, существуют две категории журналов событий: журналы Windows и журналы приложений и служб. Журналы Windows — используются операционной системой для регистрации общесистемных событий, связанных с работой приложений, системных компонентов, безопасностью и запуском. А журналы приложений и служб — используются приложениями и службами для регистрации событий, связанных с их работой. Для управления журналами событий можно использовать оснастку «Просмотр событий» или программу командной строки wevtutil.

Приложение — хранит важные события, связанные с конкретным приложением. Например, Exchange Server сохраняет события, относящиеся к пересылке почты, в том числе события информационного хранилища, почтовых ящиков и запущенных служб. По умолчанию помещается в%SystemRoot%System32WinevtLogsApplication.Evtx.

Безопасность — хранит события, связанные с безопасностью, такие как вход/выход из системы, использование привилегий и обращение к ресурсам. По умолчанию помещается в %SystemRoot%System32WinevtLogsSecurity.Evtx.

Установка — в этот журнал записываются события, возникающие при установке и настройке операционной системы и ее компонентов. По умолчанию размещается в %SystemRoot%System32WinevtLogsSetup.Evtx.

Система — хранит события операционной системы или ее компонентов, например неудачи при запусках служб или инициализации драйверов, общесистемные сообщения и прочие сообщения, относящиеся к системе в целом. По умолчанию помещается в %SystemRoot%System32WinevtLogsSystem.Evtx.

Пересылаемые события — если настроена пересылка событий, в этот журнал попадают события, пересылаемые с других серверов. По умолчанию помещается в %SystemRoot%System32WinevtLogsForwardedEvents.Evtx.

Internet Explorer — в этот журнал записываются события, возникающие при настройке и работе с браузером Internet Explorer. По умолчанию помещается в %SystemRoot%System32WinevtLogsInternetExplorer.Evtx.

Windows PowerShell — в этом журнале регистрируются события, связанные с использованием оболочки PowerShell. По умолчанию размещается в %SystemRoot%System32WinevtLogsWindowsPowerShwll.Evtx.

События оборудования — если настроена регистрация событий оборудования, в этот журнал записываются события, генерируемые устройствами. По умолчанию помещается в %SystemRoot%System32WinevtLogsHardwareEvent.Evtx.

В Windows 7 инфраструктура, обеспечивающая регистрацию событий, основана также как и в Windows Vista на XML. Данные о каждом событии соответствуют XML-схеме, что позволяет получить доступ к XML-коду любого события. Кроме того, можно создавать основанные на XML запросы для получения данных из журналов. Для использования этих новых возможностей не требуются знания об XML. Оснастка «Просмотр событий» предоставляет простой графический интерфейс для доступа к этим возможностям.

Свойства событий Существует несколько свойств событий оснастки «Просмотр событий», которые подробно описаны немного ниже:

Источник — это программа, зарегистрировавшая событие в журнале. Это может быть как имя программы (например, «Exchange Server»), так и название компонента системы или большого приложения (например, имя драйвера). Например, «Elnkii» означает драйвер EtherLink II.

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

Уровень — это уровень важности события. В журналах системы и приложений события могут иметь следующие уровни важности:

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

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

Ошибка — обозначает, что возникла проблема, которая может повлиять на функции, внешние по отношению к приложению или компоненту, вызвавшим событие;

Критическая ошибка — обозначает, что произошел сбой, после которого приложение или компонент, инициировавшие событие, не могут восстановиться автоматически;

Аудит успехов — успешное выполнение действий, которые вы отслеживаете через аудит, например использование какой-либо привилегии;

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

Пользователь — определяет учетную запись пользователя, от имени которого возникло данное событие. К пользователям относятся особые сущности, например Local Service, Network Service и Anonymous Logon, а также учетные записи реальных пользователей. Это имя представляет собой идентификатор клиента, если событие фактически было вызвано серверным процессом, или основной идентификатор, если олицетворение не производится. В некоторых случаях запись журнала безопасности содержит оба идентификатора. А также в этом поле может стоять N/A (Н/Д), если в данной ситуации учетная запись неприменима. Олицетворение происходит в случаях, когда сервер позволяет одному процессу присвоить атрибуты безопасности другого процесса.

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

Журнал — имя журнала, в который было записано данное событие.

Категория и задачи — определяет категорию события, иногда используемую для последующего описания допустимого действия. У каждого источника событий свои категории. Например следующие категории: вход/выход, использование привилегий, изменение политики и управление учетной записью.

Ключевые слова — это набор категорий или меток, которые могут использоваться для фильтрации или поиска событий. Например: «Сеть», «Безопасность» или «Ресурс не найден» .

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

Дата и время — определяет дату и время возникновения данного события в журнале.

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

Код сеанса — это идентификационный номер сеанса на сервере терминалов, в котором произошло событие.

Время работы в режиме ядра — определяет время, потраченное на выполнение инструкций режима ядра, в единицах времени ЦП. Режим ядра имеет неограниченный доступ к системной памяти и внешним устройствам. Ядро системы NT называют гибридным ядром или макроядром.

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

Загруженность процессора — это время, потраченное на выполнение инструкций пользовательского режима, в тиках ЦП.

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

ИД относительной корреляции — определяет относительное действие в процессе, для которого используется событие Работа с журналами событий:

Просмотр событий Для того чтобы просмотреть события журнала приложений, выполните следующие действия: В дереве консоли выберите «Журналы Windows»; Выберите журнал «Приложения» .

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

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

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

• *В дереве консоли выберите журнал событий, который нужно сохранить;
• *Выберите команду «Сохранить события как» из меню «Действие» или из контекстного меню журнала выберите команду «Сохранить все события как» ;
• *В появившемся диалоге «Сохранить как» выберите папку, в которую должен быть сохранен файл. Если требуется сохранить файл в новой папке, то ее можно создать непосредственно из этого диалога, используя контекстное меню или кнопку «Новая папка» на панели действий. В поле «Тип файла» нужно выбрать желаемый формат файла из доступных: файлы событий — *.evtx, xml-файл — *.xml, текст с разделением табуляции — *.txt, csv с разделением запятыми — *.csv. В поле «Имя файла» введите имя и нажмите на кнопку «Сохранить». Для отмены сохранения нажмите на кнопку «Отмена» ;
• *В том случае, если журнал событий не предназначен для просмотра на другом компьютере, в диалоговом окне «Отображать сведения» оставьте заданный по умолчанию вариант «Не отображать сведения», а если журнал предназначается для просмотра на другом компьютере, то в диалоговом окне «Отображать сведения» выберите вариант «Отображать сведения для следующих языков» и нажмите на кнопку «ОК» .

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

В дереве консоли выберите журнал событий, который требуется очистить;

Очистите журнал одним из следующих способов:

В меню «Действие» выберите команду «Очистить журнал» .

На выбранном журнале нажмите правой кнопкой для открытия контекстного меню. В контекстном меню выберите команду «Очистить журнал» Далее можно либо очистить журнал, либо заархивировать его в том случае, если это не было сделано ранее:

Чтобы очистить журнал событий без сохранения нажмите нажать на кнопку «Очистить» ;

Чтобы очистить журнал событий после его сохранения нажмите на кнопку «Сохранить и очистить». В появившемся диалоге «Сохранить как» выберите папку, в которую должен быть сохранен файл. Если требуется сохранить файл в новой папке, то ее можно создать непосредственно из этого диалога используя контекстное меню или кнопку «Новая папка» на панели действий. В поле «Имя файла» введите имя и нажмите на кнопку «Сохранить». Для отмены сохранения нужно нажать на кнопку «Отмена» .

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

В дереве консоли выберите журнал событий, для которого следует изменить размер; Выберите команду «Свойства» из меню «Действие» или из контекстного меню выбранного журнала В поле «Максимальный размер журнала (КБ)» установите требуемое значение при помощи счетчика или установите вручную без использования счетчика. В этом случае значение будет округлено до ближайшего числа, кратного 64 КБ так как размер файла журнала должен быть кратен 64 КБ и не может быть меньше 1024 КБ.

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

Переписывать события при необходимости (сначала старые файлы) — в этом случае новые записи продолжают заноситься в журнал после его заполнения. Каждое новое событие заменяет в журнале наиболее старое;

Архивировать журнал при заполнении; не переписывать события — в этом случае файл журнала автоматически архивируется при необходимости. Перезапись устаревших событий не выполняется.

Не переписывать события (очистить журнал вручную) — в этом случае журнал очищается вручную, а не автоматически.

Для того чтобы выбрать нужную политику сохранения журналов выполните следующие действия:

В дереве консоли выберите журнал событий, для которого следует изменить размер;

Выберите команду «Свойства» из меню «Действие» или из контекстного меню выбранного журнала;

На вкладке «Общие», в разделе «При достижении максимального размера» выберите требуемый параметр и нажмите на кнопку «ОК» .

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

В дереве консоли найдите и выберите аналитический или отладочный журнал, который необходимо активировать;

Выберите команду «Свойства» из меню «Действие» или из контекстного меню выбранного аналитического или отладочного журнала;

На вкладке «Общие» установите флажок на опции «Включить ведение журнала» .

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

Выберите команду «Открыть сохраненный журнал» в меню «Действие» или из контекстного меню в дереве консоли;

В диалоговом окне «Открыть сохраненный журнал», передвигаясь по дереву каталогов, откройте папку, содержащую нужный файл. По умолчанию в диалоговом окне будут выведены все файлы журналов событий. Также при открытии можно выбрать тип файлов, которые нужно отображать в диалоге открытия. Доступные типы файлов: файлы журнала событий (*.evtx, *.evt, *.etl), а также файлы событий (*.evtx), старые файлы событий (*.evt) или файлы журнала трассировки (*.etl). После того, как нужный файл журнала будет найден, выделите его, щелкнув на нем левой кнопкой мыши, что поместит его имя в строку для ввода имени файла и нажмите на кнопку «Открыть» .

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

Для создания папки, в которой будет расположен сохраненный журнал, нажмите на кнопку «Создать папку». В поле «Имя» введите имя папки, в которой будет находиться открытый журнал, а затем нажмите кнопку «ОК». Если родительская папка не выбрана, новая папка будет расположена в папке «Сохраненные журналы» .

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

Для открытия журнала, нажмите на кнопку «ОК» .

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

В дереве консоли выберите журнал, который следует удалить;

Выберите команду «Удалить» из меню «Действие» или из контекстного меню выбранного журнала В диалоге «Просмотр событий» нажмите на кнопку «Да» .

Задание: Выпишите основные термины и понятия о журнале событий Windows.

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

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

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

Термином «общие файлы» обычно называют совместный доступ к файлам, преимущественно в контексте операционных систем или служб локальных компьютерных сетей, например, Microsoft Windows documentation. 1] C получением распространения BitTorrent и аналогичных протоколов в начале 2000;х годов, термин общий доступ к файлам всё больше стал применяться к передаче файлов в одноранговых сетях через Интернет.

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

Безопасность Сетевой общий доступ обычно делается пользователями путём пометки директории или файла или изменения разрешений файловой системы или прав доступа в свойствах каталога или файла. Эта процедура различна на разных платформах. В операционной системе Windows XP Home Edition для общего доступа файлы или папки должны размещаться в специальной папке «Общие документы», обычно имеющей путьC: Documents and SettingsAll usersShared documents.

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

Наименование и подключение ресурсов Общий ресурс доступен клиентским компьютерам посредством особого назначения имён, подобного UNC, используемого в персональных компьютерах с DOS и Windows. Это означает, что сетевой ресурс может быть доступен по следующему имени:

ИмяСерверногоКомпьютераИмяРесурса где ИмяСерверногоКомпьютера — это имя в WINS или DNS-имя, или IP-адрес серверного компьютера или путь к нему. Общая папка при этом может быть доступна под именем ИмяРесурса, которое может отличаться от локального имени папки на сервере. Например, serverc$ обычно обозначает устройство с буквой C: на Windows-машинах. Общее устройство или папка часто подключается к клиентскому персональному компьютеру, это означает, что ресурсу назначается буква диска на локальном компьютере. Например, буквой устройства H: обычно обозначается домашняя папка на центральном файловом сервере.

Раньше ИТ-специалисту приходилось мириться с тем, что у конечных пользователей не было возможности быстро и просто сделать запись последовательности своих действий, связанных с возникновением какой-то проблемы. В Windows 7 появилась новая утилита Problem Steps Recorder, которая представляет собой простой инструмент для захвата изображения с экрана монитора с возможностью аннотации изображений. После того, как вы нажмете «Record», приложение начинает отслеживать сигналы с вашей мыши и вашей клавиатуры и делать скриншоты, к которым вы можете прикреплять свои комментарии. Как только вы остановите запись, программа автоматически сохранит все полученные снимки в ZIP-файле, который содержит HTML-страницу в виде веб-архива (файла с расширением mht) с последовательностью ваших действий. Далее вам придется просто просмотреть в браузере файл для анализа ситуаций.

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

Составление отчета — это, пожалуй, сильное место утилиты. Утилита регистрирует каждое действие пользователя скриншотом, на котором подсвечены кнопки или объекты, с которыми взаимодействовал пользователь. Отчет можно просматривать и в виде веб-страницы, и в виде слайдшоу, а можно и в виде XML, чтобы определить, к примеру, координаты курсора мыши Новый инструмент Windows 7 `Problem Steps Recorder', как его использовать, и как он экономит ваше время. Инструмент `PSR' способен быстро и просто документировать любые проблемы в Windows 7, шаг за шагом, в письменной форме. Самое лучшее в PSR — это то, что даже конечный пользователь может его использовать для записи проблем, чтобы потом представить их администратору.

На что способен инструмент Windows 7 Problem Steps Recorder (PSR)?

Инструмент PSR (Problem Steps Recorder) может использоваться обычным пользователем или администратором. Список тех задач, которые пользователь или администратор может выполнить с помощью этого инструмента после его установки:

• 1. Записать ряд действий, выполненных на вашем компьютере, шаг за шагом
• 2. Записывает эти действия, чтобы их можно было выполнить, используя снимки текстов и экрана монитора в момент выполнения действия
• 3. Эта документация будет включать те опции, которые пользователь выбирал во время выполнения определенных задач
• 4. Документация НЕ БУДЕТ включать никакую вводимую пользователем информацию из соображений безопасности и конфиденциальности
• 5. PSR позволит пользователю создавать «Комментарии» на протяжении всего процесса. Эти комментарии будут включать текст, вводимый пользователем в разделе комментариев, А ТАКЖЕ ту область экрана, которую пользователь выбирает во время создания этих примечаний (я покажу вам это немного позже)
• 6. Отчет PSR покажет вам версию ОС и даже URL любой веб-страницы, на которую заходил пользователь во время процесса

Запуск Windows 7 Problem Steps Recorder (PSR).

Вы не найдете PSR ни в одном из разделов меню Пуск в Windows 7. Единственным способом запуска PSR является выполнение исполняемого файла ` PSR.exe.

PSR.exe файл можно найти в папке:

C:WindowsSystem32psr.exe.

Самым простым способом запуска PSR является переход в меню Пуск, и в поле Поиск (Search) просто вводим psr, а затем нажимаем ENTER.

Отслеживание событий — основа безопасности систем Когда на компьютере происходит какое-либо значимое событие, операционная система записывает это событие в журнал. Входом в журналы служит Event Viewer (eventvwr.exe). Большинство администраторов открывают Event Viewer, только когда пытаются решить какую-нибудь проблему, и многие знакомые администраторы говорят мне, что используют Event Viewer только на серверах. Оба подхода ошибочны, потому что периодическая проверка системных журналов часто позволяет выявлять неполадки на ранней стадии, до того как они превратятся в серьезную проблему. Уметь пользоваться Event Viewer очень важно, поэтому я хочу предложить читателям краткий обзор по этой теме и представить свои способы работы с Event Viewer.

Общие сведения.

Event Viewer открывается через меню Administrative Tools (если это меню добавлено в Programs) или через приложение Administrative Tools панели управления. Консоль программы Event Viewer содержит список доступных журналов. На компьютерах Windows по умолчанию имеются следующие журналы:

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

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

System (журнал системы) — содержит события, записываемые компонентами Windows.

В системах Windows Server 2003 и Windows 2000 Server в зависимости от роли сервера можно также использовать следующие журналы:

Directory Service — содержит события, имеющие отношение к Active Directory (AD), и доступен только на контроллерах домена (DC).

File Replication Service — содержит события, записываемые во время репликации между DC, и доступен только на DC.

DNS Server — содержит события, относящиеся к разрешению имен DNS, и доступен только на серверах DNS.

Event Viewer отображает типы событий, каждое из которых имеет собственный уровень важности и собственную пиктограмму в журнале. Например:

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

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

Success Audit (аудит успехов) — это событие, имеющее отношение к системе безопасности, которое произошло и записывается потому, что система или администратор включили аудит данного события.

Failure Audit (аудит отказов) — это событие, имеющее отношение к системе безопасности, которое не произошло, но запись о нем делается потому, что система или администратор включили аудит данного события.

Информация, отображаемая в Event Viewer, включает дату и время, когда произошло событие, источник события (то есть служба, драйвер устройства или приложение, записавшее событие в журнал), категорию события, ID события, имя пользователя, который был зарегистрирован в системе, когда событие произошло (не обязательно) и имя компьютера, на котором произошло событие. Для того чтобы просматривать журнал Security, необходимо иметь права администратора.

Настройка Event Viewer.

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

Менять конфигурацию следует в зависимости от ситуации. Если вы не вносите существенных изменений в конфигурацию журнала или не видите необходимости в аудите событий, то работа настроек по умолчанию должна вас устроить. Настройка по умолчанию для максимального размера файла журнала составляет 512 Кбайт, и когда журнал заполнен, система автоматически заменяет старые записи новыми через 7 дней. Однако, если в систему вносятся существенные изменения или вводится в действие подробный аудит, журналы, скорее всего, начнут заполняться многочисленными записями. Если журнал оказывается заполненным и не содержит записей, хранящихся более 7 дней, утилите Event Viewer будет нечего удалить, чтобы освободить место для новых записей, и система прекратит записывать события. В этой ситуации нужно увеличить размер журнального файла или выполнить настройку журнала на затирание старых записей по мере необходимости (вариант Overwrite events — as needed).

Фильтры Когда администратор исследует журнал, чтобы решить какую-либо проблему, или проверяет реакцию компьютера на существенное изменение конфигурации, он может ускорить этот процесс, избавившись от не имеющих отношения к делу записей в панели Details. Диалоговое окно Properties каждого журнала имеет вкладку Filter, с помощью которой выбираются типы отображаемых событий. Например, вы не хотите видеть информационные записи от определенных компьютеров или вы хотите видеть только события, произошедшие в течение недели после внесения системных изменений. Следует просто нужным образом выбрать фильтры (или отменить выбор). Помните, что фильтры влияют только на то, что отображается в окне; система продолжает записывать в журнал события тех типов, которые были отфильтрованы. Например, если есть основания полагать, что возникла угроза системе безопасности в виде вторжения извне, можно оставить для отображения события только тех типов, быстрый взгляд на которые позволяет обнаружить аномалии в регистрации, такие как события с ID 675 и 681, соответствующие неудачным попыткам аутентификации, или событие с ID 644, означающее блокировку учетной записи вследствие многократного некорректного ввода пароля.

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

Общее событие Userenv имеет ID 1000 в журнале приложений и его описание гласит, что Windows не смогла определить имя пользователя или компьютера. Это означает, что конфигурация TCP/IP компьютера для обращения к DNS-серверу установлена некорректно. Администраторы сплошь и рядом используют неправильные адреса при настройке DNS на клиентских компьютерах; я часто нахожу IP-адрес шлюза в поле для адреса DNS. Проверку журнала компьютера-«обидчика» со своей рабочей станции обычно выполнить проще, чем идти к клиентскому компьютеру и проверять настройки TCP/IP.

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

Очистка журнала Любой журнал можно очистить, чтобы освободить дополнительное место для записей. Если выбрана настройка Do not overwrite events (clear log manually) —"Не затирать события (очистка журнала вручную)", необходимо периодически чистить журнал.

Чтобы очистить журнал, следует щелкнуть правой кнопкой на названии журнала в списке консоли Event Viewer и выбрать пункт Clear all Events («Стереть все события»). Система спрашивает, нужно ли сохранить журнал перед тем, как очистить его. Если в журнале есть записи, которые могли бы пригодиться в будущем (например, при длительном отслеживании проблемы), можно выполнить архивацию содержимого журнала.

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

Чтобы создать архивную копию журнала, нужно щелкнуть правой кнопкой мыши по названию журнала в консоли и выбрать в меню Save Log File As («Сохранить файл журнала как…»). По умолчанию Windows сохраняет файл в папке Administrative Tools, расположенной в папке C: documentssettingsusernamestart menuprograms. Можно указать другую папку или создать отдельную папку для хранения архивных копий журналов. Я обычно присваиваю журналам имя в формате имя_журнала-дата (например, apps-dec012003). Windows добавляет расширение .evt.

Архивные копии журналов являются отдельными файлами на жестком диске, но открывать их можно только через программу просмотра событий Event Viewer. Для этого следует выбрать пункт Open Log File («Открыть файл журнала») в меню Action (или щелкнуть правой кнопкой по любому объекту в консоли и выбрать Open Log File). В диалоговом окне открытия файла требуется выбрать нужный архив, указать тип журнала (т. е. Application, Security) в меню со списком Log Type, затем щелкнуть Open.

Чтобы удалить архив из консоли, следует щелкнуть правой кнопкой по его названию в списке и выбрать Delete. Это действие не удаляет файл с жесткого диска — только из консоли. Удаление архивной копии журнала с жесткого диска выполняется так же, как и удаление любого другого файла.

Просмотр событий на удаленном компьютере Чтобы облегчить себе задачу, администратор может со своей рабочей станции просматривать журналы удаленных компьютеров, на которых у него есть административные привилегии. На удаленном компьютере должна быть установлена Windows 2003, Windows XP, Windows 2000 Professional, Windows 2000 Server, Windows NT Server или NT Workstation.

На локальной консоли просмотра событий нужно щелкнуть правой кнопкой Event Viewer (Local) и выбрать Connect to another computer («Подключиться к другому компьютеру»). Следует ввести имя удаленного компьютера, с которым предстоит работать, или щелкнуть Browse, чтобы открыть диалоговое окно, показанное на экране 2, затем выбрать компьютер. Кроме того, если имя удаленного компьютера известно, нет необходимости вводить его в виде имени UNC. Вид консоли Event Viewer меняется таким образом, что отображает имя UNC удаленного компьютера. На удаленном компьютере можно производить те же действия, что и на локальном Event Viewer. Чтобы вернуться на локальный компьютер, следует щелкнуть правой кнопкой Event Viewer (имя компьютера), выбрать Connect to another computer, а затем Local computer.

Платформа Windows Troubleshooting Platform представляет собой средство для выполнения специальных модулей (Troubleshooting Packages), которые создаются на языке PowerShell и призваны решать различные проблемы, касающиеся конфигурации операционной системы, ее отдельных компонентов, устройств, сервисов и приложений. Эти модули могут вызываться как пользователями, так и приложениями при возникновении определенных проблем и проводят пользователей через серию шагов для их решения: обнаружение проблемы, устранение проблемы, проверка отсутствия проблемы. Например, если Windows Internet Explorer не может открыть веб-сайт, пользователь нажимает кнопку Diagnose Connection Problems для запуска модуля Windows Network Diagnostics, реализованного на платформе Windows Troubleshooting Platform.

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

К основным характеристикам платформы Windows Troubleshooting Platform относятся возможность ее автоматизации, эффективность, повторяемость операций, стандартизация и безопасность. Расширяемость платформы означает, что в состав Windows Software Development Kit (SDK) входят средства, позволяющие разработчикам создавать новые модули для этой платформы, что дает возможность использовать ее в качестве унифицированного механизма для настройки необходимого окружения для приложений сторонних компаний (ISV).

Далее мы рассмотрим стандартные модули, включенные в состав операционной системы Windows 7, принципы их работы, архитектуру Windows Troubleshooting Platform, средства создания дополнительных модулей и приведем ряд примеров создания собственных модулей для платформы Windows Troubleshooting Platform.

Встроенные модули В состав операционной системы Windows 7 входит ряд модулей, которые соответствуют десяти наиболее частым категориям обращений в службу технической поддержки Microsoft, включая эффективное управление питанием, совместимость приложений, сетевые настройки и настройки звука. Модули платформы Windows Troubleshooting Platform доступны через панель управления: Control Panel > All Control Panel Items > Troubleshooting. Модули сгруппированы по категориям: Programs, Hardware and Sound, Network and Internet, Appearance and Personalization и System and Security.

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

В нижней части панели расположена опция, включение которой позволяет получать обновления модулей от специального сервиса — Windows Online Troubleshooting Service.

Модули — это специальные приложения, запускаемые под управлением платформы Windows Troubleshooting Platform. Модули, поставляемые в составе операционной системы Windows 7, располагаются в каталоге %windir%Diagnostics. Каталог %windir%DiagnosticsIndex содержит XML-манифесты модулей, а каталог %windir%DiagnosticsSystem — сами модули, находящиеся в соответствующих подкаталогах.

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

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

Индекс производительности Windows 7.

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

• *Процессор
• *Память (RAM)
• *Графика (производительность рабочего стола для Windows Aero)
• *3D-графика (производительность трехмерной графики и игр)
• *Основной жесткий диск

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

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

Базовый индекс производительности может помочь при покупке программ и другого программного обеспечения, соответствующего базовому индексу компьютера. Например, если базовый индекс компьютера равен 3,3, можно уверенно приобретать любое программное обеспечение, разработанное для этой версии Windows и требующее компьютер со значением базового индекса, равного 3 и ниже. Обычно это значение указывается на упаковке ПО в разделе системных требований.

В настоящее время значения общих оценок производительности компьютеров в Windows 7 варьируются от 1,0 до 7,9. Разработка индекса производительности Windows 7 вызвана прогрессом компьютерных технологий. По мере повышения производительности оборудования будет вводиться более высокий индекс производительности. Однако стандарты для каждого уровня индекса остаются, в целом, неизменными.

Важное замечание:

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

К плюсам индекса производительности Windows (WEI) можно отнести доступность (данная утилита встроена в Windows 7 изначально) и воспроизводимость (показания WEI для ПК с одинаковыми конфигурациями, как правило, совпадают).

Как посмотреть индекс производительности Windows.

Откройте раздел «Счетчики и средства производительности». Для этого нажмите кнопку Пуск и выберите компонент Панель управления. Затем выберете Система и безопасность — Проверка индекса производительности Windows — затем нажмите кнопку Оценить производительность.

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

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

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

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

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

Восстановление системы автоматически рекомендует самую последнюю точку восстановления, созданную перед внесением значительных изменений, например перед установкой программы. Можно также осуществить выбор из списка точек восстановления. Постарайтесь воспользоваться точкой восстановления, созданной незадолго до даты и времени, когда начали появляться проблемы. Описания автоматически созданных точек восстановления соответствуют имени события, например «Установка обновления Центром обновления Windows». Средство восстановления системы возвращает компьютер в состояние, существовавшее до выбранной точки восстановления.

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

Если восстановление системы не устранило проблему, можно отменить операцию восстановления или попытаться выбрать другую точку восстановления. Если средство восстановления системы не отображает никаких точек восстановления, убедитесь, что защита системы включена и что на жестком диске осталось не менее 300 МБ свободного дискового пространства, если его емкость равна 500 МБ и более, или не менее 50 МБ, если емкость жесткого диска не превышает 300 МБ. Если восстановление системы не устранило проблему, можно попробовать использовать расширенный метод восстановления.