Поддержка эксплуатации связана с рутинными задачами сопровождения, когда надо поддерживать состояние готовности программной системы. - umotnas.ru o_O
Главная
Поиск по ключевым словам:
страница 1
Похожие работы
Название работы Кол-во страниц Размер
Доклад/Технические науки Информатика, вычислительная техника и автоматизация 1 160.01kb.
Метод сопровождения и наблюдения классным руководителем за социализацией... 1 121.34kb.
Учебная программа по дисциплине Программная инженерия (Отделение... 1 146.23kb.
Директор гбоу «Психологический центр» 1 69.38kb.
F70-F79/ Умственная отсталость 1 88.6kb.
Руководство по установке и эксплуатации Copyright 2010 lg-ericsson 11 1381.05kb.
Диагнозы /F70 F79/ Умственная отсталость 1 277.7kb.
Психолого – педагогическое сопровождение школьников 1 72.74kb.
1. Что такое промышленный программный продукт. Дать определения пакета... 2 508.35kb.
Педагогическая поддержка формирования речевой готовности детей к... 2 425.93kb.
Конкурсное произведение может исполняться в любом вокальном жанре... 1 59.95kb.
Тема Построение модели средствами uml и ее реализация в case-инструментах 1 158.34kb.
Викторина для любознательных: «Занимательная биология» 1 9.92kb.

Поддержка эксплуатации связана с рутинными задачами сопровождения, когда надо поддерживать - страница №1/1

Сопровождение
Этап сопровождения наступает после успешной передачи заказчику каждого последующего программного модуля и а конечном счете всего программного продукта. Сопровождение – не только неотъемлемая чать жизненного цикла ПО; оно составляет его большую часть, составляющую по некоторым оценкам около 70% ЖЦ. Сопровождение состоит из трех параллельных процессов:

  1. Поддержка эксплуатации.

  2. Адаптивное сопровождение.

  3. Улучшающее сопровождение.

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

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



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

  2. Система постепенно усложняется, но процесс сопровождения не поддерживает на должном уровне ее архитектуру. В конце концов проект “заваливается”, выходит из-под контроля служб сопровождения. Происходит нечто аналогичное росту энтропии в термодинамике и в результате – тепловая смерть (деструктуризация)

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

  4. Аппаратная и/или программная платформы, на которых реализована система, подлежат замене, а видимых путей для миграции нет.

Фирма-разработчик программного обеспечения часто заинтересована в продлении жизненного цикла программы. Но для этого она должна предпринимать определенные усилия. Если с факторами 1, 4 бороться невозможно, то факторы 2 и 3 в какой-то степени контролируемы.



Поэтому будем считать, что основная постоянная деятельность разработчиков ПО на этапе сопровождения преследует две цели:

  1. Улучшение структурированности программы.

  2. Сохранение и улучшение ее документированности.


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

Замена магического числа на именованную константу. Если вы используете численный или строковый литерал, скажем, 3.14, замените его именованной константой, такой как PL

Присвоение переменной более ясного или информативного имени. Если имя переменной неясно, присвойте ей лучшее имя.

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

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

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

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

Преобразование элементарного типа данных в класс. Если элементарный тип данных нужно расширить дополнительными формами поведения (например, более строгим контролем типа) или дополнительными данными, преобразуйте его в класс и реализуйте нужное поведение. Это относится и к простым численным типам вроде Money и Temperature, и к перечислениям, таким как Color, Shape, Country или OutputType.

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

И т.д
Рефакторинг на уровне отдельных операторов

Декомпозиция логического выражения. Упростите логическое выражение, введя грамотно названные промежуточные переменные, документирующие суть выражения.

Вынесение сложного логического выражения в грамотно названную булеву

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

Использование оператора break или return вместо управляющей переменной цикла. Если для управления циклом используется такая переменная, как done, удалите ее и выполняйте выход из цикла при помощи оператора break или return.

Возврат из метода сразу после получения ответа вместо установки возвращаемого значения внутри вложенных операторов if-then-else. Выход из метода сразу же после нахождения возвращаемого значения часто помогает облегчить чтение кода и снизить вероятность ошибок. Альтернативный вариант — установка возвращаемого значения и следование к выходу из метода через заторы операторов — может оказаться более сложным.

И т.д
Рефакторинг на уровне отдельных методов

Извлечение метода из другого метода. Превратите фрагмент метода в отдельный метод.

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

Преобразование объемного метода в класс. Если метод слишком велик, попробуйте превратить его в класс и разбить на несколько методов. Иногда это повышает удобочитаемость кода.

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

Отделение операций запроса данных от операций изменения данных. Как правило, операции запроса данных не должны изменять состояние объекта. Если операция вроде GetTotalsQ (получение итоговой суммы) изменяет состояние объекта, разделите функциональность запроса и функциональность изменения состояния объекта, создав два отдельных метода.

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

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

И т.д
Рефакторинг реализации классов

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

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

-перемещение метода в суперкласс;

-перемещение поля в суперкласс;

-перемещение тела конструктора в суперкласс.

-используйте деструкторы:

class TWaitCursor

{

private:

TCursor oldc;

public:

TWaitCursor(){oldc=Screen->Cursor;Screen->Cursor=crHourGlass;}

~TWaitCursor(){Screen->Cursor = oldc; }

};
И т.д


Рефакторинг интерфейсов классов

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

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

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

Замена делегирования на наследование. Если класс предоставляет доступ ко всем открытым методам класса-делегата (класса-члена), выполните наследование от класса-делегата, а не просто используйте его.

Инкапсуляция открытой переменной-члена. Если данные-члены открыты, сделайте их закрытыми и реализуйте доступ к ним при помощи методов.

Сокрытие методов, которые не следует вызывать извне класса. Если без метода интерфейс класса будет более согласованным, скройте метод.

И т.д


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

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

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

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

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

И т.д