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

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

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

При обращении разноязыковых компонентов устанавливается взаимно однозначное соответствие между фактическими параметрами V= { v1,v2 ,...vк} вызывающего компонента и формальными параметрами F = { f1, f2 , ..., fк1} вызываемого компонента, а также строится отображение (mapping) типов данных одного ЯП в соответствующие типы другого ЯП.

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

1) Построение операций преобразования типов данных T α = {Tαt} для множества языков L = {lα }α=1, n .

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

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

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

Gαt = <Xαt , Ωαt >, где t = b, c, i, r, a, z, u, e.

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

В классе систем (1) преобразование типов данных t→ q для пары языков lα и lb обладает такими свойствами отображений:

191

1)Системы Gαt и Gβq являются изоморфными (типы q, t определены на том же множестве).

2)Между значениями Xαt и Xβq существует изоморфизм, если множества операций Ωαt

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

3) Мощности алгебраических систем должны быть равны Gαt = Gβq . Алгебраические системы линейно упорядочены и поэтому любое отображение 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 описываются параметры вызова, как элементы

192

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

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

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

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

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

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

Объявление типов данных

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

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

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

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

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

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

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

193

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

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

в) для каждого LI–типа данных преобразование определяет отношение между допустимым значением этого типа и эквивалентным значением соответствующего внутреннего типа ЯП; с) для каждого значения внутреннего типа данных преобразование определяет является

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

Обратное внутреннее преобразование для LI–типа данных состоит в преобразовании значений внутреннего типа данных в соответствующее значение LI–типа при наличии соответствия и отсутствия двусмысленности. Это преобразование для ЯП является коллекцией обратных внутренних преобразований LI–типа данных.

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

LI–типов данных в типы данных ЯП Паскаль (ISO/IEC 7185–90). В нем рассмотрены примеры преобразования примитивных типов данных LI–языка (логический, перечислимый, символьный, целый рациональный и др.) в типы данных языка Паскаль.

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

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

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

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

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

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

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

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

194

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

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

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

Проблему 4 можно сформулировать как метод хранения и обработки разных данных, вызванных спецификой СУБД иерархического, сетевого и реляционного типов. Наличие явной несовместимости типов и структур моделей данных, различные языки манипулирования данными приводят к тому, что нельзя сгенерировать на языке старой СУБД скрипты по переносу данных с последующим запусков этих скриптов в среде другой СУБД. Каждая СУБД обеспечивает внесение изменений в БД, которые в некоторой степени меняют и концептуальную модель данных, если в нее вносятся новые объекты. Внесенные изменения должны отображаться в справочниках и классификаторах, которые обеспечивают перенос данных из старой БД с учетом внесенных текущих изменений.

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

Учитывая приведенные проблемы, рассмотрим пути их решения. Отметим, что промышленная эксплуатация систем, работающих с БД, может продолжаться достаточно долго. При этом изменяются прикладные программы, работающие с БД, повторно преобразуются данные, если в систему введена новая БД, а часть ранее определенных данных уже перенесены в новую БД.. Это влечет за собой доработку прикладных программдоступакданным, чтобыприспособитьих к измененнойструктуреновойБДили к старой БД. Для переноса данных из старой БД в новую разрабатываются скрипты с приведенной логической структурой БД или DBF–файлы, которые вначале размещаются в транзитнойБД, азатемсучетомособенностейновойосновнойБД переносятся внею. Может оказаться, что процесс приведения структур транзитной БД к новой окажется нецелесообразным и разработку новой БД проводить "с нуля". При этом заполненные

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

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

195

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

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

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

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

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

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

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

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

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

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

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

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

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

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

196

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

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

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

Старые БД

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

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

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

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

197

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

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

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

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

В качестве унифицированного формата транзитных файлов используется формат DBF– файлов, поскольку многиеСУБД, такиекакDB2, FохРгоинекоторыедругиехранятданные в таких файлах, тем самым не требуется начальный перенос данных из старой СУБД в транзитные файлы. Большинство СУБД, формат хранения данных которых отличается от форматаDBF–файлов, снабжены утилитами или драйверами, которые позволяют перенести данные в такой формат.

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

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

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

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

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

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

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

Как утверждают эксперты, процесс внесения изменений в эксплуатируемую систему достаточно дорогой, оценки его стоимости достигают от 60 % до 80 % от общей стоимости разработки системы.

198

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

199

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

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

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

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

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

С технической точки зрения реинженерия – это решение проблемы эволюции системы. Если предположить, что архитектура системы не изменяется, то преобразовать централизованную систему в распределенную, компоненты которой размещаются в операционной среде на разных компьютерах, является довольно сложным процессом. (Например, изменить язык программирования старой системы (Fortran, Сobol и др.) на современные объектно–ориентированные языки Java или C++.

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

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

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

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

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

200