Главная | Обратная связь | Поможем написать вашу работу!

Создание абстракций данных

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

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

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

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

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

3. Осуществить поиск всех ссылок на данные с использованием системы просмотра программ или генератора перекрестных ссылок. Заменить эти ссылки соответствующими функциями.

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

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

Изменение данных

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

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

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

2. Программные ограничения. При разработке систем многие программисты включают в программы ограничения на количество обрабатываемых данных. Но согласно современным требованиям программы должны обрабатывать значительно больше данных, чем было предусмотрено изначально. Именно для устранения подобных ограничений может понадобиться изменение данных. В книге [296] приведен пример системы управления ценными бумагами, которая была способна обрабатывать до 99 транзакций за одну операцию. В компании, где эта система использовалась, осуществлялось управление 2000 транзакций, что вызвало необходимость в создании 23 копий системы. По этой причине впоследствии компания приняла решение о реинжениринге системы и изменении данных.

3. Эволюция системной архитектуры. При переходе с централизованной системы на распределенную ядром архитектуры должна стать система управления данными с удаленным доступом. Для перемещения данных из отдельных файлов на сервер системы управления базой данных (СУБД) может потребоваться большая работа по изменению этих данных.

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

Таблица 28.1. Методы изменения данных

Метод	Описание
Чистка данных	Устраняется дублирование, стирается избыточная информация, ко всем записям применяется единый формат. Все это, как правило, не влечет за собой никаких изменений в программах
Расширение возможностей обработки данных	Данные и связанные с ними программы подвергаются реинженирингу для устранения ограничений на обработку данных. Например, увеличивается длина полей, увеличиваются верхние границы массивов и т.п. Также вносятся соответствующие изменения в программы. После этого данные обычно перезаписываются и очищаются
Миграция данных	Данные переводятся под управление современной СУБД. Этот подход проиллюстрирован на рис. 28.7

Рис. 28.7. Миграция данных

В статье [293] описаны некоторые проблемы с данными, возникающие в наследуемых системах, состоящих из нескольких программ коллективного пользования.

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

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

3. Проблема организации записей. Записи, относящиеся к одному и тому же элементу, в разных программах могут быть представлены по-разному. Обычно эта проблема возникает с такими языками программирования, как COBOL, где физическая организация записей определяется программистом. В языках типа C++ или Java такой проблемы не существует, так как физической организацией записей занимается компилятор.

4. Проблема констант. Константы (литеральные величины), например налоговые ставки, часто определены в программе, что затрудняет создание символьных ссылок на них.

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

Если определения данных несовместимы или противоречивы, их значения могут храниться и обрабатываться некорректно. Примеры несовместимости и противоречивости данных приведены в табл. 28.2, взятой из [293]. После изменения определений данных их значения преобразуются так, чтобы соответствовать новой структуре данных.

Таблица 28.2. Примеры несовместимости и противоречивости значений данных

Данные	Описание
Различные значения по умолчанию	В различных программах одному и тому же логическому элементу данных могут быть присвоены разные значения по умолчанию. Это вызывает трудности в работе программ, которые обрабатывают эти данных. Особая проблема: недопустимое значение присваивается по умолчанию как допустимое
Различные единицы измерения	Разные программы представляют одинаковую информацию в разных единицах измерения. Например, в США и Великобритании вес может измеряться в фунтах (если взять более старую программу) и в килограммах (в современных системах). Проблема такого же рода возникла в Европе с введением единой валюты. Пришлось изменять системы, рассчитанные на работу с национальной валютой, для того чтобы они смогли работать с евро
Несовместимость правил проверки данных	В разных программах различные правила проверки данных. Данные, приемлемые для одной программы, могут не восприниматься другой. Особая проблема возникает с архивными данными, которые не обновлялись в соответствии с изменениями правил проверки
Противоречия в семантике представлений	Программы могут присваивать значения в зависимости от способа представления элементов. Например, в некоторых программах текст в верхнем регистре означает адрес. Программы используют различные соглашения о представлении данных и поэтому могут не воспринимать данные, хотя они и будут верными
Несогласованность при обработке отрицательных величин	В некоторых программах величинам, которые должны быть всегда положительными, не может быть присвоено отрицательное значение. Другие программы при предъявлении отрицательных величин могут конвертировать их в положительные и т.д.

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

Рис. 28.8. Процесс изменения данных

На первом этапе процесса изменения данных модифицируются определения данных. На сами данные такая модификация не оказывает влияния. Чтобы автоматизировать этот процесс, можно использовать системы сопоставления с образцом, например awk [5], которые помогают находить и заменять определения, или же можно создать XML-определения данных [326] и использовать их для управления средствами конвертирования данных. Несмотря на это, ручной работы над данными практически невозможно избежать. Если ставится цель улучшить понимаемость определений данных, то работу можно остановить на этой стадии. Если же имеются проблемы со значениями данных, описанные выше, следует начать второй этап процесса изменения данных.

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

КЛЮЧЕВЫЕ ПОНЯТИЯ

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

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

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

• В процессе анализа системы на основе исходного кода восстанавливаются системные архитектура и спецификация. Для поддержки процесса анализа используются средства просмотра программ.

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

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

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

• Если данные нужно преобразовать в новый формат, стоимость замены данных резко возрастает.

Упражнения

28.1. В каких случаях необходимо заменить старое ПО новым вместо его реинжениринга?

28.2. Сравните управляющие структуры (циклы и условные операторы) в двух любых известных вам языках программирования. Кратко опишите процесс перевода управляющих структур с одного языка на другой.

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

28.4. Напишите ряд указаний по определению модулей в неструктурированной программе.

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

28.6. Какие трудности возникнут при переносе данных из СУБД одного типа в СУБД другого типа (например, из иерархической базы данных в реляционную или из реляционной в объектно-ориентированную)?

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

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

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

Листинг 28.4. Неструктурированная программа

routine BS (К, Т, S, Ё)

В:= 1

NXT: if S >= В goto CON

L = -1

goto STP

CON: L:= INTEGER(B / S)

L:= INTEGER((B + S) /2)

If Т (L) = К then return

If Т (L) > К then goto GRT

В:= L + 1

goto NXT

GRT: S:= L-l

goto NXT

STP: end

⇐ Предыдущая 191 192 193 194 195196197 198 199 200 Следующая ⇒