ТРПО_теория / Lect_trpo / lavrishcheva_petrukhin

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

Основное различие между реинженерией и новой разработкой системы состоит в том, что написание системной спецификации начинается не с «нуля», а с учета возможностей старой наследуемой системы при разработке спецификации новой системы. К основным этапам этого процесса относятся:

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

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

–разбиение на модули для группирования и устранения избыточности, что приводит к изменению структуры системы;

–изменение системных данных, с которыми работает программа для согласования с проведенным изменениями в программе.

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

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

2.Недостаток квалифицированного персонала для программ, написанных в специфических ЯП, вышедших из употребления.

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

К операциям реинженерии относятся:

–именование компонентов и их идентификацию;

–расширение функций существующей реализации компонента;

–перевод языка компонента на новый современный язык программирования;

–реструктуризация структуры компонента;

–модификация описания компонента и его данных.

8.4.2. Рефакторинг компонентов

Рефакторинг получил развитие в объектно–ориентированном программировании [2] в связи с применением шаблонов проектирования, методов улучшения кода и структуры объектно–ориентированных программ. Были разработаны целые библиотеки типичных трансформаций искомых объектов (классов), которые улучшают те или другие характеристики. Он вошел в компонентное программирование и базируется на типичной структуре, модели компонента и ориентирован на изменении не только компонентов, а и их интерфейсов.

201

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

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

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

–добавление новой реализации для существующего и нового интерфейса;

–замена существующей реализации новой с эквивалентной функциональностью;

–добавление нового интерфейса (при условии наличия соответствующей реализации);

–расширение существующего интерфейса;

–расширение интерфейса для новых системных сервисов в компонентной среде.

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

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

Операции над компонентами должны удовлетворять следующим условиям:

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

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

–перестройки или переделки компонентов, а иногда и перепрограммирования в случае реверсной инженерии [4, 5].

8.4.3. Реверсная инжеиерия

Методы реверсной инженерии разработаны в среде объектно–ориентированного программирования [1]. Они базируется на выполнении базовых операций визуализации (visual) и измерения метрик (metric) программных систем в рамках модели, которая предлагает следующие цели:

– обеспечение высокого качества системы и переосвидетельствование ее размера, сложности и структуры;

202

– поиск иерархии классов и атритутов программных объектов с целью наследования их в ядре системы;

системы.

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

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

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

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

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

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

203

Контрольные вопросы и задания

1.Определите цели и задачи метода интеграции в программной инженерии.

2.Назовите системы, которые поддерживают процессы интеграции и преобразования данных.

3.Охарактеризуйте кратко современные системы взаимосвязи объектов – COM, CORBA, JAVA и др.

4.Назовите методы вызова компонентов в распределенных средах.

5.Какую роль выполняет брокер объектных запросов

6.Определите проблему преобразования данных в ЯП.

7.Какие требуется провести преобразования передаваемых по сети данных от объекта JAVA в к объекту в С++ и обратною

8.Определите проблемы преобразования данных, связанные с заменой одной БД на другую.

9.Какие методы переноса данных существуют?

10.Определите цели и задачи изменения ПС при проведении сопровождения.

11.Какие выполняются работы при сопровождении, когда вносятся изменения?

12.Дайте краткую характеристику проблем, возникающих при сопровождении системы.

13.Определите основные задачи реинженерии ПО.

14.Определите основные операции рефакторинга компонентов.

15.Определите основные операции реинженерии программных систем.

Литература к теме 8.

1.Open Software Foundation. Inroduce to Open Software Foundation. Disributed Computed Environments.– Englewood Cliffs: Prentice Hall, 1993.– 437p.

2.Corbin J. The art of Distributed Application. Programming Techn. For Remote Procedure Calls.– Berlin: Springer Verlag, 1992.– 305p.

3.Роджерсон Д. Основы СОМ. Руск..пер.– Microsoft Press.– 361c.

4.CORBA. The Common Object Request Broker: Architecture and Specification. Revision

2.0.Copyright 1991, 1992, 1995 by Sun Microsystems, Inc.–1995.–621 p.

5.Монсон–Хейфел Р. Enterprise JavaBeans. – СПб: Символ–Плюс, 2002. – 672 с.

6.Барлет Н., Лесли А., Симкин С. Программирование на JAVA. Путеводитель.– Киев.– 1996.– 736с.

7.Иванников В.П., Дышлевый К.В., Мажелей С.Г., Содовская Д.Б., Шебуняев А.Б.Распределенные объектно–ориентированные среды.– Москва // РАН.ИСП. Труды ИСП,.–2000.– с.84–100.

8.Гост 30664 (ИСО/МЭК 11404:1996). Информационные технологии. Языки программирования, их среда и системный интерфейс. Зависимые от языков типы данных/ Межгосударственный стандарт.–Межгосударственный совет по стандартизации, метрологии и сертификации, 2000. – 112 с.

9.Джордан Д. Обработка объектных бах данных в С++. Программирование по стандарту ODMG: Пер.с англ. – М.: Издательский дом “Вильямс”, 2001. – 384 с.

10.Дунаев С. Б. Доступ к базам данных и техника работы в сети. – М.: Диалог–Мифи, 1999. – 416 с.

11.Эммерих В. Конструирование распределенных объектов. Методы и средства программирования интероперабельных объектов в архитектурах OMG/CORBA, Microsoft COM и Java RMI. – М.: Мир, 2002. – 510с.

12.Лаврищева Е.М., Грищенко В.М. Сборочное программирование .–Киев.– Наукова думка.– 1991. –213с.

204

13.Лаврищева Е.М. Парадигма интеграции в программной инженерии// Программирование, 2000.– №1–2 (Труды второй междун.науч..конф. УкПрог–2000, 23– 26мая 2000г. –Киев).– с.351–360.

14.Lanza M., Ducasse S. Polimetric Views –A lightweight Visual Approach to Reverse

Engineering //IEEET Transaction on Software Engineering.– 2003.– Sept., №3 (ISSN 0098–5589).– P.782–796.

15.Фаулер М. Рефакторинг: улучшение соответствующего кода. – СПб.: Символ–Плюс, 2003. – 432 с.

16.Пантелеймонов А.А. Аспекты реинженерии приложений с графическим интерфейсом пользователя//Проблемы программирования .–2001.–№1–2.– С.53–62.

17.Бабенко Л.П., Лаврищева Е.М. Основы программной инженерии «Знание».–2001. – 269с.

18.Соммервилл И. Инженерия программного обеспечения.– Изд. Дом «Вильямс», Москва

19.Игнатенко П.П., Неумоин В.Н., Бистров В.М. Об обеспеченни эффективного реинжинеринга прикладних програмних систем // Пробл. программирования. – 2001. –

№1–2. – с. 42–52.

20.Гласс Г., Нуазо Р. Сопровождение программного обеспечения. Пер.с анг. // Под ред. Ю.А.Чернышова.– М.:.Мир.– 1983.–256 с.

205

Тема 9 МОДЕЛИ КАЧЕСТВА И НАДЕЖНОСТИ В ПРОГРАММНОЙ ИНЖЕНЕРИИ

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

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

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

Качество ПО было предметом стандартизации, создан стандарт ГОСТ 2844–94, в котором дано определение качества ПО, как совокупность свойств (показателей качества) ПО, которые обеспечивают его способность удовлетворять потребности заказчика, в соответствии с назначением. Этот стандарт регламентирует базовую модель качества и его показатели, главным среди них является надежность. Стандарт ISO/IEC 12207 определил не только основные процессы ЖЦ разработки ПС, но и организационные и дополнительные процессы, которые регламентирую инженерию, планирование и управление качеством ПС.

На этапах ЖЦ проводится анализ качества ПО, ориентированные на:

– достижение качества ПО в соответствии с требованиями и критериями;

– верификацию и аттестацию (валидацию) промежуточных результатов ПО на этапах ЖЦ и измерение степени достижения отдельных его показателей;

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

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

9.1. Модель качества ПО

Качество ПО является относительным понятием, которое имеет смысл только при учете реальных условий его применения, поэтому требования, предъявляемые к качеству, ставятся в соответствии с условиями и конкретной областью их применения.

Качество ПО характеризуется тремя главными аспектами: качество программного продукта, качество процессов ЖЦ и качество сопровождения или внедрения (рис. 9.1).

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

206

Рис. 9.1 Основные аспекты качества ПО

Качество продукта целиком и полностью определяется процессами ЖЦ. Эффект от внедрения полученного программного продукта в значительной степени зависит от качества сопровождения и знаний обслуживающего персонала.

Модель качества ПО имеет следующие четыре уровня детализации.

Первый уровень соответствует определению характеристик (показателей) качества для ПО, каждая из них отражает отдельную точку зрения пользователя на качество. Согласно стандартов [1–4] определено шесть характеристик или шесть показателей качества в стандартной модели качества:

1.функциональность (functionality),

2.надежность (realibility),

3.удобство (usability),

4.эффективность (efficiency),

5.сопровождаемость (maitainnability),

6.переносимость (portability).

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

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

Четвертый уровень задает оценочный элемент метрики для оценки количественного или качественного значения отдельного атрибута показателя ПО с учетом его веса.

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

207

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

1). Функциональность – совокупность свойств, определяющих способность ПО выполнять в заданной среде перечень функций в соответствии с требованиями к обработке и общесистемным средствам.

Под функцией понимается некоторая упорядоченная последовательность действий для удовлетворения некоторых потребительских свойств. Функции бывают целевые (основные и вспомогательные).

достаточности основных функций для решения задач в соответствии с назначением

взаимодействовать ПО со специальными системами и средами (ОС, сеть);

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

2). Надежность – совокупность атрибутов, которые определяют способность ПО преобразовывать исходные данные в результаты при условиях, зависящих от периода времени жизни (износ и его старение не учитывается). Снижение надежности ПО происходит из–за ошибок в требованиях, проектировании и выполнении. Отказы и

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

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

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

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

208

Адаптируемость Переносимость Простота установки

Сосуществование

Заменяемость

Согласованность

Рис. 9.2. Модель характеристик качества

209

К факторам, влияющим на надежность ПО, относятся:

– риск как совокупность угроз, приводящих к неблагоприятным последствиям и ущербу системы или среды ее функционирования;

–угроза как проявление нарушения безопасности системы;

–целостность как способность системы сохранять устойчивость работы и не иметь риска.

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

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

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

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

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

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

К подхарактеристикам эффективности ПО относятся:

–реактивность – атрибут, который показывает время отклика, обработки и выполнения функций;

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

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

5). Сопровождаемость

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