Лаврищева Е.М., Петрухин В.А. Методы и средства инженерии программного обеспечения

Подождите немного. Документ загружается.

191

8.2.2. Формальное описание данных в ЯП и их преобразование

Основными ЯП, используемыми для описания компонентов для распределенной сети,

являются С++, Паскаль, JAVA и др.

При обращении разноязыковых компонентов устанавливается взаимно однозначное

соответствие между фактическими параметрами V= { v

,...v

} вызывающего

компонента и формальными параметрами F = { f

, f

, ..., f

к1

} вызываемого

компонента, а также строится отображение (mapping) типов данных одного ЯП в

соответствующие типы другого ЯП.

В общем случае задача отображения А: П

Ф для множеств параметров V и F

состоит в построении:

П = { V

, V

,..., V

} , Ф = { F

, F

,..., F

}

∪

= V , V

∩

′

∅

при t

≤

′

t=1

∪

= F , F

∩

′

∅

при t = t

′

t=1

Построение отображения выполняется за два этапа.

1) Построение операций преобразования типов данных T

= {T

} для множества

языков L = {l

}

=1, n

2) Построение отображения типов данных для каждой пары взаимодействующих

компонентов в ЯП l

и l

с применением операций селектора S и конструктора С.

Для проведения формализованного преобразования типов данных используется

алгебраический подход, при котором каждому типу данных T

ставиться в

соответствие алгебраическая система

= <X

где t – тип данных, X

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

переменные этого типа данных,

– множество операций над этими типами данных.

Для простых типов данных ЯП t = b (bool), c (char), i (int), r (real) и сложных типов

данных t = a (array), z (record), u (union), e (enum), как комбинация простых типов

данных, построены две алгебраические системы:

= { G

, G

}

= { G

, G

...}

(1)

Каждая из систем определяется на множестве значений типов данных и операций над

ними:

= <X

>, где t = b, c, i, r, a, z, u, e.

Операциям преобразования каждого t типа данных соответствует изоморфное

отображение двух алгебраических систем, построенных для совместимых типов

данных двух ЯП.

В классе систем (1) преобразование типов данных t

→

q для пары языков l

обладает такими свойствами отображений:

192

1) Системы G

и G

являются изоморфными (типы q, t определены на том же

множестве).

2) Между значениями X

и X

существует изоморфизм, если множества операций Ω

различны. Если множество операций

∩

не пусто, то имеем

изоморфизм двух систем G

′

= < X

> и G

′

= < X

> . Если тип t –

строка, а тип q – вещественный, то между множествами X

и X

не существует

изоморфного соответствия.

3) Мощности алгебраических систем должны быть равны

⎜

Алгебраические системы линейно упорядочены и поэтому любое отображение 1), 2)

сохраняет линейный порядок.

8.2.3. Средства стандарта ISO/IEC 11404–1996 для преобразования данных

Цель этого стандарта состоит в том, чтобы обеспечить не только описание типов

данных в языке LI (Language Independent), их генерацию, но и преобразование типов

данных ЯП в LI–язык и наоборот. Стандарт предлагает специальные правила и

характеристические операций генерации примитивных типов данных и их

объединений LI–языка в более простые структуры данных ЯП, а также при

определении параметров интерфейса, задаваемых в языках IDL, RPC и API.

Независимые от ЯП типы данных LI–языка разделены на примитивные, агрегатные,

сгенерированные типы данных (рис.1), семейство типов данных и генератор типов

данных.

Рис.8.1. Независимые от ЯП типы данных стандарта ISO/IEC 11404–1996

Типы данных в стандарте должны описываться в LI–языке, который в отличие от

средств описания типов данных в ЯП является более общим языком, содержащим все

существующие типы в ЯП и типы данных, ориентированные на генерацию других

типов данных. Средствами LI описываются параметры вызова, как элементы

Стандартные

типы данных

Примитивные

типы данных

Типы

Логический,

перечислимый

символьный,

целый,

рациональный,

действительн.

комплексный,

порядковый,

масштабный

Свойства

Равенство,

порядок,

кардиналь.

точные

приближен

числовой

Агрегатные типы

данных

Типы

Запись,

набор,

портфель,

массив,

таблица

Свойства

Однородные,

размерность,

уникальност,

упорядочен.

доступ,

рекурсивн.,

числовой

Сгенери

ованные

типы данных

Типы

Выбор,

указатель,

процедура

193

интерфейса, необходимые при обращении к стандартным сервисам и готовым

программным компонентам.

Стандарт имеет раздел объявления типов данных (рис.8.2), переименования

существующих; объявление новых генераторов, значений и результатов. Каждый тип

данных объявляется по шаблону, включающему описание и спецификатор типа

данных, значение в пространстве значений, синтаксическое описание и операции над

типами данных.

LI–язык предлагает следующие виды преобразования данных:

– внешнее преобразование из внутренних типов данных ЯП в LI–типы данных;

– внутреннее преобразование из LI–типы данных, в тип данных ЯП;

– обратное внутреннее преобразование.

Рис.8.2. Объявление типов данных в стандарте ISO/IEC 11404–1996

Суть внешнего преобразования типов данных и генераторов типов данных состоит в

следующем:

а) для каждого примитивного типа для сгенерированного внешнего типа данных

преобразование связывается с одним LI–типом данных;

в) для каждого внутреннего типа данных преобразование определяет связь между

допустимым значением внутреннего типа данных и эквивалентным значением

соответствующего LI–типа данных;

с)

для каждого значения LI–типа данных, участвующего в преобразовании,

определяется существование значения любого внутреннего типа данных,

преобразуемого в LI–тип данных со взятием этого значения.

Внешнее преобразование документирует аномалии при идентификации внутренних

типов и дает гарантию того, что интерфейс между программными компонентами

адекватно задается сервисным средством и игнорирует среду ЯП.

Внутреннее преобразование связывает примитивный тип данных или сгенерированный

в LI–тип данных с конкретным внутренним типом данных ЯП. Представители

отдельного семейства LI–типа данных могут преобразовываться в различные

Объявление

типов данных

Объявление

типов данных

Объявленные

типы данных

Объявленные

генераторы

Переименования,

новые типы

данных,

новые

генераторы

Натуральный,

модуль,

битовая строка

символьн. строка

октет,

строка октета.

приватный,

идентификатор

Стек,

Дерево,

Циклически

перечислимый,

необязательный

194

внутренние типы данных ЯП. Данное преобразование обладает следующими

свойствами:

а) для каждого LI–типа данных (примитивного или сгенерированного) преобразование

определяет наличие этого типа данных в ЯП;

в) для каждого LI–типа данных преобразование определяет отношение между

допустимым значением этого типа и эквивалентным значением соответствующего

внутреннего типа ЯП;

с) для каждого значения внутреннего типа

данных преобразование определяет является

ли это значение образом (после преобразования) какого–то значения LI–типа данных и

способ преобразования.

Обратное внутреннее преобразование для LI–типа данных состоит в преобразовании

значений внутреннего типа данных в соответствующее значение LI–типа при наличии

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

коллекцией обратных внутренних преобразований LI–

типа данных.

В стандарте приведен набор приложений. В приложении А приведен перечень

действующих стандартов (около 40), определяющих наборы символов. Для

обеспечения совместимости используемых и реализуемых типов данных в

приложении В содержатся рекомендации по идентификации типов данных и описанию

аннотаций для атрибутов, параметров и др. В приложении С даны рекомендации по

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

типы данных. В приложении D показано, что синтаксис LI–языка является

подмножеством стандарта IDM (Interface Definition Notation), предназначеного для

описания интерфейса в LI–языке, Приведен вариант внутреннего преобразования

LI–типов данных в типы данных ЯП Паскаль (ISO/IEC 7185–90). В нем рассмотрены

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

перечислимый, символьный, целый рациональный и др.) в типы данных языка Паскаль.

Предложенные в стандарте рекомендации, средства описания типов данных и методы

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

программной поддержки.

8.3. Преобразование данных БД и замена БД

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

различием логических структур данных, справочников и классификаторов,

используемых СУБД, а также изменениями, внесенными в БД [9,10]. Эти проблемы

объясняются поясняются следующим:

1. Многомодельность представления данных в различных БД (иерархические, сетевые,

реляционные модели) и СУБД;

2. Различия в логических структурах данных, в справочниках и классификаторах, в

системах кодирования информации;

3. Поддержка различных языков для представления текстовой информации;

4. Разные типы СУБД и постоянное развитие их БД в процессе эксплуатации.

Проблема 1 решается путем перехода к реляционной модели данных и СУБД,

поскольку они обладают более мощным математическим аппаратом, опирающимся на

теорию множеств и математическую логику. Реляционная модель данных состоит из

структурной, манипуляционной и целостной частей. В них соответственно фиксируется

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

195

Целостность не поддерживается в иерархических или сетевых моделей, поэтому при

переходе к реляционным БД целостности данных нарушается.

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

концептуальную схему БД, в которой описаны основные объекты БД и связи между

ними. Поэтому при изменении предметной области, переход на новую СУБД

предполагает проектирование новой структуры БД, проведение сопоставления на

соответствие данных в старой и новой БД, а также изменения справочной информация

и классификаторов.

Проблема 3 определяется разноязычными текстовыми представлениями информации в

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

несколько, поэтому необходимо организовать хранение данных с простым доступ к

текстовым данным и установлении соответствия текстовых данных, записанных на

разных языках.

Проблему 4 можно сформулировать как метод хранения и обработки разных данных,

вызванных спецификой СУБД иерархического, сетевого и реляционного типов.

Наличие явной несовместимости типов и структур моделей данных, различные языки

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

СУБД скрипты по переносу данных с последующим запусков этих скриптов в среде

другой СУБД. Каждая СУБД обеспечивает внесение изменений в БД, которые в

некоторой степени меняют и концептуальную модель данных, если в нее вносятся

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

классификаторах, которые обеспечивают перенос данных из старой БД с учетом

внесенных текущих изменений.

8.3.1. Основные этапы преобразования данных в БД

Учитывая приведенные проблемы, рассмотрим пути их решения. Отметим, что

промышленная эксплуатация систем, работающих с БД, может продолжаться достаточно

долго. При этом изменяются прикладные программы, работающие с БД, повторно

преобразуются данные, если в систему введена новая БД, а часть ранее определенных

данных уже перенесены в новую БД.. Это влечет за собой доработку прикладных

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

старой БД. Для переноса данных из старой БД в новую разрабатываются скрипты с

приведенной логической структурой БД или DBF–файлы, которые вначале размещаются в

транзитной БД, а затем с учетом особенностей новой основной БД переносятся в нею. Может

оказаться, что процесс приведения структур транзитной БД к новой окажется

нецелесообразным и разработку новой БД проводить "с нуля". При этом заполненные

справочники и классификаторы потребуется дополнить появившимися новыми

данными.

Проблемы преобразования данных при использовании разных СУБД возникают из–за

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

несовместимые типы данных, а также доступ к данным осуществляется разными

языками манипулирования данных, используемых СУБД.

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

скриптов и файлов с учетом ранее введенных данных, снятия дублирования данных и

корректного приведения несовместимых типов данных При этом могут возникнуть

196

ошибки, связанные с изменением форматов данных, дополнением старых справочников

новыми данными и т.п.

Этапы преобразования данных. Процесс преобразования данных состоит из трех

главных частей:

1. Перенос данных между СУБД (перенос данных из старой БД в транзитные файлы и затем

занесение данных из этих файлов в транзитную БД;

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

соответствие структур старой и новой баз данных, а также кодов справочников и

классификаторов;

3. Перенос данных из транзитной базы в основную базу данных и проверка преобразования

данных.

Первый метод замены представляет собой наиболее безболезненный для пользователей

и разработчиков.

Второй метод замены представляет собой создание нового проекта системы на основе

имеющейся модели данных. При третьем варианте создается система заново и в

новую БД заносятся унаследованные данные из старой БД. Поскольку структуры БД

различны, то создаются, как правило, временные приложения, осуществляющие

нужные преобразования данных в процессе их переноса в новую БД.

При применении первого и второго метода структура старой БД сохраняется и никакого

преобразования данных и соответствия справочников и классификаторов не требуется – они

используют единый формат хранения данных.

8.3.2. Унифицированные файлы для передачи данных между разными БД

Проблема преобразования и переноса данных между различными СУБД решается в основном

двумя методами, основанными соответственно на использовании:

1) специального драйвера (две СУБД соединяются друг с другом и напрямую передают

данные, используя интерфейс);

2) транзитных файлов, в которые копируются данные из старой БД и переносятся в новую

БД.

Процесс преобразования и переноса данных из разных БД в новую БД приведен на рис.8.3.

При первом методе две СУБД соединены напрямую и передают данные, используя

определенный интерфейс или драйвер. Иными словами,. они используют специальные

программы взаимодействия двух СУБД, при которых вторая СУБД понимает результаты

выполнения запросов на языке манипулирования данными первой СУБД, и наоборот. Данные

на выходе первой СУБД являются данными на входе второй СУБД в языке

манипулирования данными второй СУБД, такие данные могут быть внесены в транзитную

БД.

Метод сложный в реализации и требует поставки с СУБД программ переноса данных из других

СУБД, которые привязаны к старой и новой СУБД. Поэтому второй метод переноса данных

между различными СУБД является более предпочтительным..

197

Второй метод заключается в том, что из старой БД данные переносятся в транзитные

файлы, SGL–скрипты, DBF–файлы с заранее заданными форматами данных, которые

пересылаются через сеть в новую транзитную БД.

Данные из транзитных файлов с помощью специальных утилит или средств новой СУБД

затем переносятся в транзитную БД для дальнейшей обработки. Если вторая СУБД

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

табличному виду. Если первая СУБД не реляционна, то данные должны быть приведены к

табличному виду и первой нормальной форме.

Дальнейшая нормализация данных и приведение их к структуре новой БД осуществляется

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

используется 3–я или 4–я нормальная форма. Каждая высокая форма нормализации содержит в

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

скалярные значения.

Рис. 8.3. Процесс преобразования и формирования новой БД из старых БД

Иными словами, отношение находятся в первой нормальной форме, если они хранятся в

табличном виде (все ячейки в строке таблицы расположены в строго определенной

последовательности) и каждая ячейка таблицы содержит только атомарные значения

(каждый элемент не является множеством).

БД

Старые БД

Sql–

скипты

Транзитные

фа

DBF– файлы

Транзитная база данных

Преобразование данных,

приведение соответствия

со справочниками

Старые и новые

справочники

Основная, новая база данных

198

Отношение находится в третьей нормальной форме тогда и только тогда, когда каждый

кортеж состоит из значения первичного ключа, которое идентифицирует некоторую

сущность, и набора пустых значений или значений независимых атрибутов, описывающих эту

сущность. Т.е. отношение находится в третьей нормальной форме, когда неключевые

атрибуты являются взаимно независимыми и зависят от первичного ключа. Неключевой

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

отношения.

Два или несколько атрибутов являются взаимно независимыми, если ни один из них не

зависит функционально от какой–либо комбинации остальных атрибутов. Подобная

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

остальных.

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

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

целостности данных.

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

поэтому требуется, чтобы данные, находящиеся в транзитных файлах, существовали

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

В качестве унифицированного формата транзитных файлов используется формат DBF–

файлов, поскольку многие СУБД, такие как DB2, FохРго и некоторые другие хранят данные в

таких файлах, тем самым не требуется начальный перенос данных из старой СУБД в

транзитные файлы. Большинство СУБД, формат хранения данных которых отличается от

формата DBF–файлов, снабжены утилитами или драйверами, которые позволяют перенести

данные в такой формат.

8. 4. Методы внесения изменений в компоненты и в ПС

Активное использование созданных ПС проводится на процессе сопровождения. При

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

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

характеристик системы.

В отличие от технического обеспечения, которое с течением времени требует ремонта,

программное обеспечение не "снашивается" и поэтому процесс сопровождения нацелен

более всего на эволюцию системы, то есть не только на исправление ошибок, а и на

замену ее отдельных функций и возможностей.

Типичными причинами внесения изменений являются:

– выявление дефектов в системе во время эксплуатации, которые не были

обнаружены на этапе тестирования;

– выяснение несоответствия или невыполнения некоторых требований заказчика,

благодаря чему система не выполняет отдельные функции;

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

поставленных им требований.

Как утверждают эксперты, процесс внесения изменений в эксплуатируемую систему

достаточно дорогой, оценки его стоимости достигают от 60 % до 80 % от общей

стоимости разработки системы.

199

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

– корректировка – внесение изменений в ПС для устранения ошибок, которые были

найдены после передачи системы в эксплуатацию;

– адаптация продукта к измененным условиям (аппаратуре нового типа)

использования системы после ее передачи в эксплуатацию;

– предупредительное сопровождение – деятельность, ориентированная на

обеспечение

адаптации системы к новым техническим возможностям.

Одна из проблем, влияющая на процесс внесения изменений, – это степень подготовки

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

определенных условий.

В связи с тем, что почти каждые 8–10 лет происходит смена архитектур компьютеров,

ЯП и операционных сред, возникают проблемы сопровождения готовых ПС и их

компонентов в новой среде или архитектуре, решение которых приводит к изменению

либо обновлению отдельных элементов системы или системы полностью.

В общем, процесс изменения ПС проводятся путем:

– анализа исходного кода для внесения в него изменений;

– настройки компонентов и системы на новые платформы;

– кодирования и декодирование данных при переходе с одной платформы на другую;

– изменения функций системы или добавления новых;

– расширения возможностей (сервиса, мобильности и др.) компонентов;

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

Сущность всех видов изменений в один компонент и совокупности компонентов ПС

направлена на придание старой ПС нового назначения и определения условий

применения.

Методы изменения ПС служат способом продления жизни наследуемых и стареющих

программ. С теоретической точки зрения эти методы изучены недостаточно, а с

практической точки зрения многие программисты решают задачи внесения

изменений в ПС постоянно. Например, широкий круг специалистов охватила проблема

2000 года и ее решение мировым сообществом, а также создание современных

оффшорных зон (Индия, Россия, Украина и др

.) для систематической переделки

функционирующих программ к новым возможностям ОС, языков и платформ

современных компьютеров и т.п.

Процесс обновления компонента включает в себя [14–20]:

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

компонентов с учетом новых ЯП и условий новых платформ и сред, а также

расширение возможностей ПС;

– рефакторинг, в задачу которого

входит изменение существующего компонента или

его адаптация к новым условиям вместе с изменением его интерфейсов (добавление,

расширение и т.д.) или изменения механизмов управления экземплярами компонентов

(добавление новых функций) или системных сервисов;

– реверсная инженерия, цель которой – перестройки или полная переделки

компонентов, а иногда и перепрограммирование системы в новый ЯП.

200

8.4.1. Реинженерия программных систем

Реинженерия (reengineering) – это повторная реализация программы (системы) в целях

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

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

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

модернизация структуры и системы данных. При этом архитектура системы может

оставаться неизменной.

Метод реинженерии – целевое средство получения нового компонента благодаря

последовательности операций внесения изменений, модернизации или модификации, а

также перепрограммирования или адаптации компонентов.

Реинженерия компонентов – это совокупность моделей, методов и процессов

изменения структуры и возможностей компонентов с целью получения компонента с

новыми возможностями.

Новые компоненты необходимо идентифицировать по определенным действующим

правилам именования компонентов и методов их применения в системах из

компонентов. Решение проблемы идентификации связано с необходимостью создания

компонентных конфигураций и каркасов системы из компонентов.

С технической точки зрения реинженерия – это решение проблемы эволюции системы.

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

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

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

(Например, изменить язык программирования старой системы (Fortran, Сobol и др.) на

современные объектно–ориентированные языки Java или C++.

Однако с коммерческой точки зрения реинженерию принимают часто за единственный

способ сохранения наследуемых систем в эксплуатации. Подходы к эволюции системы,

при которых изменяется

все, являются дорогостоящими либо рискованными.

Так как ПС много, то полная замена или радикальная реструктуризация их в

большинстве затруднена. Методами реинженерии проще совершенствовать структуру,

документацию или отдельные компоненты системы. Сопровождение старых систем

действительно стоит дорого, однако реинженерия может продлить время их

существования.

По сравнению с более радикальными подходами к совершенствованию систем

реинженерия имеет следующие преимущества.

1. Снижение рисков. При повторной разработке ПО существует риск получения

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

системные спецификации, снижением надежности или изменением функционирования

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

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

2. Снижение затрат. Себестоимость реинженерии значительно ниже, чем разработка

нового ПО. Согласно данным различных коммерческих структур она в четыре раза

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