СОПРОВОЖДЕНИЕ И ОБСЛУЖИВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ КОМПЬЮТЕРНЫХ СИСТЕМ. Методические указания по выполнению практических и лабораторных работ по пм. 04
 Скачать 1.92 Mb.
|
|
Восстановление системы из образа системы Давайте рассмотрим ситуацию, когда у нас в результате действия вируса компьютер от- казывается загружаться. Под рукой соответственно нет ни диска аварийного восстановления, ни установочного диска с ОС. Но мы заранее подготовили образ диска с системой. 1. Перезагружаем компьютер, нажав на кнопку “Reset”, либо путем выключения и по- вторного включения питания компьютера. При загрузке жмем клавишу “F8” и захо- дим в меню “Дополнительные варианты загрузки”. 2. Выбираем пункт “Устранение неполадок компьютера” и жмем клавишу “Enter”. 3. После этого отобразится окно “Параметров восстановления системы” с выбором необходимо языка меню восстановления и параметрами клавиатуры. Как правило, здесь менять ничего не надо, просто жмем кнопку “Далее”. 4. Далее появится окно “Параметры восстановления системы”, в котором необходимо указать Имя пользователя и пароль. Укажите необходимое Имя пользователя, вве- дите пароль и нажмите кнопку “ОК”. 5. Откроется окошко, в котором необходимо будет выбрать вариант восстановления си- стемы. 40 6. Далее вставьте в привод записанный ранее DVD-диск с образом системы и кликните по пункту “Восстановление образа системы”. Через некоторое время система найдет образ на DVD-диске и запустит “Мастера восстановления компьютера из образа”. На следующих двух окнах Мастера нажмите последовательно кнопку “Далее”, оставив предложенные варианты настройки. И на последнем окне нажмите кнопку “Готово”. 7. Нажав кнопку “Готово”, появится последнее окошко с предупреждением о том, что все данные на системном диске будут заменены данными из образа системы. Под- твердите свое намерения произвести восстановление системы с образа нажатием кнопки “Да”. 8. После этого Мастер приступит к процессу восстановления системы, который займет немного времени. 9. По завершении процесса восстановления ПК автоматически перезагрузится. Опера- ционная система восстановлена из образа, все пользовательские данные сохранены, мы их не трогали. Вот мы и завершили изучение вопроса восстановление работы компьютера из образа системы. Практическая работа № 4.10. Разработка модулей программного средства Цель работы: получить практические навыки разработки модулей программной си- стемы и интеграции этих модулей Теоретический материал Термин «интеграция» относится к такой операции в процессе разработки ПО, при кото- рой вы объединяете отдельные программные компоненты в единую систему. В небольших про- ектах интеграция может занять одно утро и заключаться в объединении горстки классов. В больших — могут потребоваться недели или месяцы, чтобы связать воедино весь набор про- грамм. Независимо от размера задач в них применяются одни и те же принципы. Тема интеграции тесно переплетается с вопросом последовательности конструирования. Порядок, в котором вы создаете классы или компоненты, влияет на порядок их интеграции: вы не можете интегрировать то, что еще не было создано. Последовательности интеграции и кон- струирования имеют большое значение. Поскольку интеграция выполняется после того, как разработчик завершил модульное тестирование, и одновременно с системным тестированием, ее иногда считают операцией, от- носящейся к тестированию. Однако она достаточно сложна, и поэтому ее следует рассматри- вать как независимый вид деятельности. Аккуратная интеграция обеспечивает: упрощенную диагностику дефектов; меньшее число ошибок; меньшее количество «лесов»; раннее создание первой работающей версии продукта; уменьшение общего времени разработки; лучшие отношения с заказчиком; улучшение морального климата; увеличение шансов завершения проекта; более надежные оценки графика проекта; более аккуратные отчеты о состоянии; лучшее качество кода; меньшее количество документации. 41 При разработке программного модуля целесообразно придерживаться следующего по- рядка изучение и проверка спецификации модуля, выбор языка программирования; выбор алгоритма и структуры данных; программирование (кодирование) модуля; шлифовка текста модуля; проверка модуля; компиляция модуля. Первый шаг разработки программного модуля в значительной степени представляет со- бой смежный контроль структуры программы снизу: изучая спецификацию модуля, разработ- чик должен убедиться, что она ему понятна и достаточна для разработки этого модуля. В завер- шении этого шага выбирается язык программирования: хотя язык программирования может быть уже предопределен для всего ПС, все же в ряде случаев (если система программирования это допускает) может быть выбран другой язык, более подходящий для реализации данного модуля (например, язык ассемблера). На втором шаге разработки программного модуля необходимо выяснить, не известны ли уже какие-либо алгоритмы для решения поставленной и или близкой к ней задачи. И если найдется подходящий алгоритм, то целесообразно им воспользоваться. Выбор подходящих структур данных, которые будут использоваться при выполнении модулем своих функций, в значительной степени предопределяет логику и качественные показатели разрабатываемого модуля, поэтому его следует рассматривать как весьма ответственное решение. На третьем шаге осуществляется построение текста модуля на выбранном языке про- граммирования. Обилие всевозможных деталей, которые должны быть учтены при реализации функций, указанных в спецификации модуля, легко могут привести к созданию весьма запу- танного текста, содержащего массу ошибок и неточностей. Искать ошибки в таком модуле и вносить в него требуемые изменения может оказаться весьма трудоемкой задачей. Поэтому весьма важно для построения текста модуля пользоваться технологически обоснованной и практически проверенной дисциплиной программирования. Впервые на это обратил внимание Дейкстра сформулировав и обосновав основные принципы структурного программирования. На этих принципах базируются многие дисциплины программирования, широко применяемые на практике. Следующий шаг разработки модуля связан с приведением текста модуля к завершен- ному виду в соответствии со спецификацией качества ПС. При программировании модуля раз- работчик основное внимание уделяет правильности реализации функций модуля, оставляя недоработанными комментарии и допуская некоторые нарушения требований к стилю про- граммы. При шлифовке текста модуля он должен отредактировать имеющиеся в тексте ком- ментарии и, возможно, включить в него дополнительные комментарии с целью обеспечить тре- буемые примитивы качества. С этой же целью производится редактирование текста программы для выполнения стилистических требований. Шаг проверки модуля представляет собой ручную проверку внутренней логики модуля до начала его отладки (использующей выполнение его на компьютере), реализует общий прин- цип, сформулированный для обсуждаемой технологии программирования, о необходимости контроля принимаемых решений на каждом этапе разработки ПС. И наконец, последний шаг разработки модуля означает завершение проверки модуля (с помощью компилятора) и переход к процессу отладки модуля. Структурное программирование При программировании модуля следует иметь в виду, что программа должна быть по- нятной не только компьютеру, но и человеку: и разработчик модуля, и лица, проверяющие мо- дуль, и тестовики, готовящие тесты для отладки модуля, и сопроводители ПС, осуществляющие требуемые изменения модуля, вынуждены будут многократно разбирать логику работы мо- дуля. В современных языках программирования достаточно средств, чтобы запутать эту логику 42 сколь угодно сильно, тем самым, сделать модуль трудно понимаемым для человека и, как след- ствие этого, сделать его ненадежным или трудно сопровождаемым. Поэтому необходимо при- нимать меры для выбора подходящих языковых средств и следовать определенной дисциплине программирования. В связи с этим Дейкстра и предложил строить программу как композицию из нескольких типов управляющих конструкций (структур), которые позволяют сильно повы- сить понимаемость логики работы программы. Программирование с использованием только таких конструкций назвали структурным. Рис. 1. Основные управляющие конструкции структурного программирования. Основными конструкциями структурного программирования являются: следование, раз- ветвление и повторение (см. Рис. 1). Компонентами этих конструкций являются обобщенные операторы (узлы обработки) S, S1, S2 и условие (предикат) P. В качестве обобщенного опера- тора может быть либо простой оператор используемого языка программирования (операторы присваивания, ввода, вывода, обращения к процедуре), либо фрагмент программы, являющийся композицией основных управляющих конструкций структурного программирования. Суще- ственно, что каждая из этих конструкций имеет по управлению только один вход и один выход. Тем самым, и обобщенный оператор имеет только один вход и один выход. Весьма важно также, что эти конструкции являются уже математическими объектами (что, по существу, и объясняет причину успеха структурного программирования). Доказано, что для каждой неструктурированной программы можно построить функционально эквива- лентную (т.е. решающую ту же задачу) структурированную программу. Для структурирован- ных программ можно математически доказывать некоторые свойства, что позволяет обнаружи- вать в программе некоторые ошибки. Этому вопросу будет посвящена отдельная лекция. Структурное программирование иногда называют еще "программированием без GO TO". Однако дело здесь не в операторе GO TO, а в его беспорядочном использовании. Очень 43 часто при воплощении структурного программирования на некоторых языках программирова- ния (например, на ФОРТРАНе) оператор перехода (GO TO) используется для реализации струк- турных конструкций, что не нарушает принципов структурного программирования. Запуты- вают программу как раз "неструктурные" операторы перехода, особенно переход к оператору, расположенному в тексте модуля выше (раньше) выполняемого оператора перехода. Тем не менее, попытка избежать оператора перехода в некоторых простых случаях может привести к слишком громоздким структурированным программам, что не улучшает их ясность и содержит опасность появления в тексте модуля дополнительных ошибок. Поэтому можно рекомендовать избегать употребления оператора перехода всюду, где это возможно, но не ценой ясности про- граммы. К полезным случаям использования оператора перехода можно отнести выход из цикла или процедуры по особому условию, "досрочно" прекращающего работу данного цикла или данной процедуры, т.е. завершающего работу некоторой структурной единицы (обобщенного оператора) и тем самым лишь локально нарушающего структурированность программы. Боль- шие трудности (и усложнение структуры) вызывает структурная реализация реакции на возни- кающие исключительные (часто ошибочные) ситуации, так как при этом требуется не только осуществить досрочный выход из структурной единицы, но и произвести необходимую обра- ботку (исключение) этой ситуации (например, выдачу подходящей диагностической информа- ции). Обработчик исключительной ситуации может находиться на любом уровне структуры программы, а обращение к нему может производиться с разных нижних уровней. Вполне при- емлемой с технологической точки зрения является следующая "неструктурная" реализация ре- акции на исключительные ситуации [8.7]. Обработчики исключительных ситуаций помеща- ются в конце той или иной структурной единицы и каждый такой обработчик программируется таким образом, что после окончания своей работы производит выход из той структурной еди- ницы, в конце которой он помещен. Обращение к такому обработчику производится операто- ром перехода из данной структурной единицы (включая любую вложенную в нее структурную единицу). Пошаговая детализация и понятие о псевдокоде Структурное программирование дает рекомендации о том, каким должен быть текст мо- дуля. Возникает вопрос, как должен действовать программист, чтобы построить такой текст. Часто программирование модуля начинают с построения его блок-схемы, описывающей в об- щих чертах логику его работы. Однако современная технология программирования не рекомен- дует этого делать без подходящей компьютерной поддержки. Хотя блок-схемы позволяют весьма наглядно представить логику работы модуля, при их ручном кодировании на языке про- граммирования возникает весьма специфический источник ошибок: отображение существенно двумерных структур, какими являются блок-схемы, на линейный текст, представляющий мо- дуль, содержит опасность искажения логики работы модуля, тем более, что психологически довольно трудно сохранить высокий уровень внимания при повторном ее рассмотрении. Ис- ключением может быть случай, когда для построения блок-схем используется графический ре- дактор и они формализованы настолько, что по ним автоматически генерируется текст на языке программирования (как, например, это делается в Р-технологии). В качестве основного метода построения текста модуля современная технология про- граммирования рекомендует пошаговую детализацию. Сущность этого метода заключается в разбиении процесса разработки текста модуля на ряд шагов. На первом шаге описывается общая схема работы модуля в обозримой линейной текстовой форме (т.е. с использованием очень крупных понятий), причем это описание не является полностью формализованным и ориентировано на восприятие его человеком. На каждом следующем шаге производится уточнение и детализация одного из понятий (будем называть его уточняемым), в каком либо описании, разработанном на одном из предыдущих шагов. В результате такого шага создается описание выбранного уточняемого понятия либо в терминах базового языка программирования (т.е. выбранного для представления модуля), либо в такой же форме, что и на первом шаге с использованием новых уточняемых понятий. Этот процесс завершается, когда 44 все уточняемые понятия будут уточнения (т.е. в конечном счете будут выражены на базовом языке программирования). Последним шагом является получение текста модуля на базовом языке программирования путем замены всех вхождений уточняемых понятий заданными их описаниями и выражение всех вхождений конструкций структурного программирования сред- ствами этого языка программирования. Пошаговая детализация связана с использованием частично формализованного языка для представления указанных описаний, который получил название псевдокода. Этот язык поз- воляет использовать все конструкции структурного программирования, которые оформляются формализованно, вместе с неформальными фрагментами на естественном языке для представ- ления обобщенных операторов и условий. В качестве обобщенных операторов и условий могут задаваться и соответствующие фрагменты на базовом языке программирования. Головным описанием на псевдокоде можно считать внешнее оформление модуля на ба- зовом языке программирования, которое должно содержать: начало модуля на базовом языке, т.е. первое предложение или заголовок (специфика- цию) этого модуля; раздел (совокупность) описаний на базовом языке, причем вместо описаний процедур и функций - только их внешнее оформление; неформальное обозначение последовательности операторов тела модуля как одного обобщенного оператора (см. ниже), а также неформальное обозначение тела каждого описания процедуры или функции как одного обобщенного оператора; последнее предложение (конец) модуля на базовом языке. Внешнее оформление описания процедуры или функции представляется аналогично. Впрочем, если следовать Дейкстре, раздел описаний лучше также представить здесь нефор- мальным обозначением, произведя его детализацию в виде отдельного описания. Неформальное обозначение обобщенного оператора на псевдокоде производится на естественном языке произвольным предложением, раскрывающим в общих чертах его содер- жание. Единственным формальным требованием к оформлению такого обозначения является следующее: это предложение должно занимать целиком одно или несколько графических (пе- чатных) строк и завершаться точкой (или каким-либо другим знаком, специально выделен- ным для этого). 45 Рис. 2. Основные конструкции структурного программирования на псевдокоде. Для каждого неформального обобщенного оператора должно быть создано отдельное описание, выражающее логику его работы (детализирующее его содержание) с помощью ком- позиции основных конструкций структурного программирования и других обобщенных опера- торов. В качестве заголовка такого описания должно быть неформальное обозначение детали- зируемого обобщенного оператора. Основные конструкции структурного программирования могут быть представлены в следующем виде (см. рис. 2). Здесь условие может быть либо явно задано на базовом языке программирования в качестве булевского выражения, либо нефор- мально представлено на естественном языке некоторым фрагментом, раскрывающим в об- щих чертах смысл этого условия. В последнем случае должно быть создано отдельное описа- ние, детализирующее это условие, с указанием в качестве заголовка обозначения этого условия (фрагмента на естественном языке). 46 Рис. 3. Частные случаи оператора перехода в качестве обобщенного оператора. В качестве обобщенного оператора на псевдокоде можно использовать указанные выше частные случаи оператора перехода (см. рис. 8.3). Последовательность обработчиков исключи- тельных ситуаций (исключений) задается в конце модуля или описания процедуры (функции). Каждый такой обработчик имеет вид: ИСКЛЮЧЕНИЕ имя_исключения обобщенный_оператор ВСЕ ИСКЛЮЧЕНИЕ Отличие обработчика исключительной ситуации от процедуры без параметров заключа- ется в следующем: после выполнения процедуры управление возвращается к оператору, следу- ющему за обращением к ней, а после выполнения исключения управление возвращается к опе- ратору, следующему за обращением к модулю или процедуре (функции), в конце которого (ко- торой) помещено данное исключение. Рекомендуется на каждом шаге детализации создавать достаточно содержательное опи- сание, но легко обозримое (наглядное), так чтобы оно размещалось на одной странице текста. Как правило, это означает, что такое описание должно быть композицией пяти-шести конструк- ций структурного программирования. Рекомендуется также вложенные конструкции распола- гать со смещением вправо на несколько позиций (см. рис. 4). В результате можно получить описание логики работы по наглядности вполне конкурентное с блок-схемами, но обладающее существенным преимуществом - сохраняется линейность описания. 47 Рис. 4. Пример одного шага детализации на псевдокоде. Идею пошаговой детализации приписывают иногда Дейкстре. Однако Дейкстра предла- гал принципиально отличающийся метод построения текста модуля, который нам представля- ется более глубоким и перспективным. Во-первых, вместе с уточнением операторов он предла- гал постепенно (по шагам) уточнять (детализировать) и используемые структуры данных. Во- вторых, на каждом шаге он предлагал создавать некоторую виртуальную машину для детали- зации и в ее терминах производить детализацию всех уточняемых понятий, для которых эта машина позволяет это сделать. Таким образом, Дейкстра предлагал, по существу, детализиро- вать по горизонтальным слоям, что является перенесением его идеи о слоистых системах (см. лекцию 6) на уровень разработки модуля. Такой метод разработки модуля поддерживается в настоящее время пакетами языка АДА и средствами объектно-ориентированного программи- рования. |