Модернизация и реинжиниринг программного обеспечения

Лекция 8. Модернизация и реинжиниринг программного обеспечения Цели Настоящая лекция посвящена вопросам изменения программного обеспечения и описывает различные способы модификации программных систем. Прочитав эту лекцию, вы должны: • знать основные стратегии модернизации программных систем, а именно: сопровождение системы, эволюцию системной архитектуры и реинжиниринг программного обеспечения; • ориентироваться в принципах сопровождения ПО и понимать причины увеличения расходов на сопровождение систем; • знать, каким образом наследуемую систему можно преобразовать в распределенную систему клиент/сервер, чтобы продлить срок эксплуатации системы и обеспечить более эффективное ее использование на основе современных аппаратных средств; • знать, почему реинжиниринг часто является наиболее выгодным решением для развития компьютерных систем; • иметь представление о составляющих процесса реинжиниринга; • понимать различие между реинжинирингом программных систем и изменением системных данных, а также то, почему изменение данных является дорогостоящим процессом и требует много времени. Невозможно создать систему, которая не потребует изменений в будущем. Как только программное обеспечение вводится в эксплуатацию, возникают новые требования к системе, обусловленные непрерывным развитием бизнес-процессов и все возрастающими общими требованиями к программным системам. Иногда в системе следует изменить некоторые составляющие в целях повышения производительности или улучшения других характеристик, а также для исправления обнаруженных ошибок. Все это требует дальнейшего развития системы после ее ввода в эксплуатацию. Полная зависимость организаций от программного обеспечения, которое к тому же обходится в достаточно круглую сумму, объясняет исключительную важность серьезного отношения к ПО. Это предусматривает дополнительные вложения в эволюцию уже эксплуатируемой системы с тем, чтобы обеспечить прежний уровень ее производительности. Существует несколько стратегических подходов к процессу модернизации ПО. 1. Сопровождение программного обеспечения. Это наиболее часто используемый подход, который заключается в изменении отдельных частей ПО в ответ на растущие требования, но с сохранением основной системной структуры. Подробнее этот вопрос освещен в разделе 2. 2. Эволюция системной архитектуры. Этот подход более радикальный, чем сопровождение ПО, так как предполагает существенные изменения в программной системе. Эта стратегия модернизации ПО подробно раскрыта в разделе 3. 3. Реинжиниринг программного обеспечения. Кардинально отличается от других подходов, так как модернизация предусматривает не внесение каких-то новых компонентов, а наоборот, упрощение системы и удаление из нее всего лишнего. При этом возможны изменения в архитектуре, но без серьезных переделок. Этому вопросу посвящен раздел 4. Приведенные стратегии не исключают одна другую. Иногда для упрощения системы перед изменением архитектуры или для переделки некоторых ее компонентов применяется реинжиниринг. Некоторые части системы заменяются серийными, а более стабильные системные компоненты продолжают функционирование. Выбор стратегии модернизации системы основывается не только на технических характеристиках, но и на том, насколько хорошо система поддерживает деловую активность компании. Разные стратегии могут также применяться к отдельным частям системы или к отдельным программам наследуемой системы. Сопровождение приемлемо для программ со стабильной и четкой структурой, не требующей особого внимания. Для других программ, которые постоянно контактируют со многими пользователями, можно изменить архитектуру так, чтобы интерфейс пользователя запускался на машине клиента. Еще один компонент в этой же системе можно заменить аналогичной программой стороннего производителя. Однако при реинжиниринге обычно необходимо изменять все компоненты системы. Изменения в ПО служат причиной появления многочисленных версий системы и ее компонентов. Поэтому особенно важно внимательно следить за всеми этими изменениями, а также за тем, чтобы версия компонента соответствовала той версии системы, в которой он применяется. Управление изменениями системы называется управлением конфигурацией. В лекции 7 было дано описание наследуемых систем и различных стратегий развития программного обеспечения. Напомню, что наследуемой я называю старую систему, необходимую для поддержки текущей деловой активности организации, которая пока не может от нее отказаться. Организации во многом зависят от таких наследуемых систем, поэтому должны поддерживать их функционирование. В понятие эволюции наследуемой системы входят такие компоненты, как сопровождение, замена, архитектурная эволюция и реинжиниринг, изучением которого мы займемся в данной лекции. Реинжиниринг — это повторная реализация наследуемой системы в целях повышения удобства ее эксплуатации и сопровождения. В это понятие входят разные процессы, среди которых назовем повторное документирование системы, ее реорганизацию и реструктуризацию, перевод системы на один из более современных языков программирования, модификацию и модернизацию структуры и системных данных. При этом функциональность системы и ее архитектура остаются неизменными. С технической точки зрения реинжиниринг — это решение «второго сорта» проблемы системной эволюции. Если учесть, что архитектура системы не изменяется, то сделать централизованную систему распределенной представляется делом довольно сложным. Обычно нельзя изменить язык программирования старых систем на объектно-ориентированные языки (например, Java или C++). Эти ограничения вводятся для сохранения архитектуры системы. Однако с коммерческой точки зрения реинжиниринг часто принимается за единственный способ сохранения наследуемых систем в эксплуатации. Другие подходы к эволюции системы либо слишком дорогостоящие, либо рискованные. Чтобы понять причины такой позиции, следует рассмотреть проблемы, связанные с наследуемыми системами. Код эксплуатируемых в настоящее время программных систем чрезвычайно огромен. В 1990 году Улрич насчитал 120 млрд. строк исходного кода, эксплуатируемых в то время программ. При этом большинство программ были написаны на языке COBOL, который лучше всего подходит для обработки данных в деловой сфере, и на языке FORTRAN. У этих языков достаточно ограниченные возможности в плане структуризации программ, a FORTRAN к тому же отличается ограниченной поддержкой структурирования данных. Несмотря на постоянную замену подобных систем, многие из них все еще используются. С 1990 года отмечается резкое возрастание использования вычислительной техники в деловой сфере. При грубом подсчете можно говорить о многих сотнях млрд. строк исходного кода, которые нуждаются в сопровождении. Большинство создано отнюдь не с помощью объектно-ориентированных языков программирования. Программных систем настолько много, что говорить о полной замене или радикальной реструктуризации их в большинстве организаций не приходится. Сопровождение старых систем действительно стоит дорого, однако реинжиниринг может продлить время их существования. Как отмечалось в лекции 7, реинжиниринг систем выгоден в том случае, если система обладает определенной коммерческой ценностью, но дорога в сопровождении. С помощью реинжиниринга совершенствуется системная структура, создается новая документация и облегчается сопровождение системы. По сравнению с более радикальными подходами к совершенствованию систем реинжиниринг имеет два преимущества. 1. Снижение рисков. При повторной разработке ПО существуют большие риски - высока вероятность ошибок в системной спецификации и вероятность возникновения проблем во время разработки системы. Реинжиниринг снижает эти риски. 2. Снижение затрат. Себестоимость реинжиниринга значительно ниже, чем разработка нового программного обеспечения. Например, система, эксплуатируемая в коммерческой структуре, повторная разработка которой оценивалась в 50 млн. долларов может быть успешно подвергнута реинжинирингу всего за 12 млн. долларов. Приведенные цифры типичны: считается, что реинжиниринг в четыре раза дешевле, чем повторная разработка системы. Реинжиниринг ПО тесно связан с реинжинирингом деловых процессов. Последний означает преобразование бизнес-процессов для снижения количества излишних видов деятельности и повышения эффективности делового процесса. Обычно реинжиниринг бизнес-процессов предполагает внедрение новых программ для поддержки деловых процессов или модификацию существующих программ, при этом наследуемые системы существенно зависят от делового процесса. Такую зависимость следует выявлять как можно раньше и устранять, прежде чем начнется планирование каких-либо изменений в самом бизнес-процессе. Поэтому решение о реинжиниринге ПО может возникнуть, если наследуемую систему не удается адаптировать к новым деловым процессам путем изменений в обычном сопровождении системы. Основное различие между реинжинирингом и новой разработкой системы связано со стартовой точкой начала работы над системой. При реинжиниринге вместо написания системной спецификации «с нуля» старая система служит основой для разработки спецификации новой системы. Традиционная разработка ПО может быть названа разработкой вперед (forward engineering), чтобы подчеркнуть различие между ней и реинжинирингом. Это различие проиллюстрировано на рис. 1. Традиционная разработка начинается с этапа создания системной спецификации, за которой следует проектирование и реализация новой системы. Реинжиниринг основывается на существующей системе, которая разработчиками изучается и преобразуется в новую. Рис. 1. Традиционная разработка и реинжиниринг ПО На рис. 2 показан возможный процесс реинжиниринга. В начале этого процесса имеем наследуемую систему, а в результате - структурированную и заново скомпонованную версию той же системы. Перечислим основные этапы этого процесса. 1. Перевод исходного кода. Конвертирование программы со старого языка программирования на современную версию того же языка либо на другой язык. 2. Анализ программ. Документирование структуры и функциональных возможностей программ на основе их анализа. 3. Модификация структуры программ. Анализируется и модифицируется управляющая структура программ с целью сделать их более простыми и понятными. 4. Разбиение на модули. Взаимосвязанные части программ группируются в модули; там, где возможно, устраняется избыточность. В некоторых случаях изменяется структура системы. 5. Изменение системных данных. Данные, с которыми работает программа, изменяются с тем, чтобы соответствовать нововведениям. Рис. 2. Процесс реинжиниринга При реинжиниринге программ необязательно проходить все стадии, показанные на рис. 2. Например, не всегда нужно переводить исходный код, если язык программирования, на котором написана программа, все еще поддерживается разработчиком компилятора. Если реинжиниринг проводится с помощью автоматизированных средств, то не обязательно восстанавливать документацию на программу. Изменение системных данных необходимо, если в результате реинжиниринга изменяется их структура. Однако реструктуризация данных в процессе реинжиниринга требуется всегда. Стоимость реинжиниринга обычно определяется объемом выполненных работ. На рис. 3 показано несколько различных подходов к процессу реинжиниринга и динамика изменения стоимости работ для этих подходов. Рис. 3. Стоимость реинжиниринга Кроме объема выполняемых работ, есть и другие факторы, обусловливающие стоимость реинжиниринга. 1. Качество программного обеспечения, которое подвергается реинжинирингу. Чем ниже качество программ и их документации (если она есть в наличии), тем выше стоимость реинжиниринга. 2. Наличие средств поддержки процесса реинжиниринга. Обычно реинжиниринг экономически выгоден, если применяются CASE-средства для автоматизированного внесения изменений в программы. 3. Объем необходимого преобразования данных. Стоимость процесса реинжиниринга возрастет при увеличении объема преобразуемых данных. 4. Наличие необходимых специалистов. Если персонал, который занимается сопровождением системы, не может выполнить реинжиниринг, это также может стать причиной повышения стоимости процесса. Вновь привлеченные специалисты потратят много времени на изучение системы. Основным недостатком реинжиниринга принято считать то, что с его помощью систему можно улучшить только до определенной степени. Например, с помощью реинжиниринга невозможно функционально-ориентированную систему сделать объектно-ориентированной. Основные архитектурные изменения или полную реструктуризацию программ невозможно выполнить автоматически, что также увеличивает стоимость реинжиниринга. И, несмотря на то что реинжиниринг поможет улучшить сопровождение системы, все равно она будет намного хуже в сопровождении, чем новая, созданная с помощью современных методов инженерии ПО. 1. Динамика развития программ Под динамикой развития программ подразумевается исследование изменений в программной системе. Результатом исследований, изучавших развитие программ, стало появление ряда «законов» Лемана (Lehman), относящихся к модернизации систем. Считается, что эти законы неизменны и применимы практически во всех случаях. Они сформулированы после исследования процесса создания и эволюции ряда больших программных систем. Эти законы (в сущности, не законы, а гипотезы) приведены в табл. 1. Таблица 1. Законы Лемана Закон Описание Непрерывность модернизации Для программ, эксплуатируемых в реальных условиях, модернизация — это необходимость, иначе их полезность снижается Возрастающая сложность По мере развития программы становятся все более сложными. Для упрощения или сохранения их структуры необходимы дополнительные затраты Эволюция больших систем Процесс развития систем саморегулируемый. Такие характеристики системы, как размер, время между выпусками очередных версий и количество регистрируемых ошибок, для каждой версии программы остаются практически неизменными Организационная стабильность Жизненный цикл системы относительно стабилен, независимо от средств, выделяемых (или не выделяемых) на ее развитие Стабильность количества изменений За весь жизненный цикл системы количество изменений в каждой версии остается приблизительно одинаковым Из первого закона вытекает необходимость постоянного сопровождения системы. При изменении окружения, в котором работает система, появляются новые требования, и система должна неизбежно изменяться с тем, чтобы им соответствовать. Изменения системы носят циклический характер, когда новые требования порождают появление новой версии системы, что, в свою очередь, вызывает изменения системного окружения; это находит отражение в формировании новых требований к системе и т.д. Второй закон констатирует нарушение структуры системы после каждой модификации. Это в полной мере демонстрируют наследуемые системы. Единственным способом избежать этого, по всей видимости, является только профилактическое обслуживание, которое, однако, требует средств и времени. При этом совершенствуется структура программы без изменения ее функциональности. Поэтому в бюджете, предусмотренном на содержание системы, следует также учесть и эти дополнительные затраты. Самым спорным и, пожалуй, самым интересным законом Лемана является третий. Согласно этому закону, все большие системы имеют собственную динамику изменений, которая устанавливается на начальном этапе разработки системы. Этим определяются возможности сопровождения системы и ограничивается количество модификаций. Предполагается, что этот закон является результатом действия фундаментальных структурных и организационных факторов. Как только система превышает определенный размер, она начинает действовать подобно некой инерционной массе. Размер становится препятствием для новых изменений, поскольку эти изменения с большой вероятностью станут причиной ошибок в системе, которые снизят эффективность нововведений в новой версии программы. Четвертый закон Лемана утверждает, что крупные проекты по разработке программного обеспечения действуют в режиме «насыщения». Это означает, что изменения ресурсов или персонала оказывает незначительное влияние на долгосрочное развитие системы. Это, правда, уже указано в третьем законе, который утверждает, что развитие программы не зависит от решений менеджмента. Этим законом также утверждается, что крупные команды программистов неэффективны, так как время, потраченное на общение и связи внутри команд ы, превышает время непосредственной работы над системой. Пятый закон затрагивает проблему увеличения количества изменений с каждой новой версией программы. Расширение функциональных возможностей системы каждый раз сопровождается новыми ошибками в системе. Таким образом, масштабное расширение функциональных возможностей в одной версии означает необходимость последующих доработок и исправления ошибок. Поэтому в следующей версии уже будут проведены незначительные модификации. Таким образом, менеджер, формируя бюджет для внесения крупных изменений в версию системы, не должен забывать о необходимости разработки следующей версии с исправленными ошибками предыдущей версии. В основном законы Лемана выглядят весьма разумными и убедительными. При планировании сопровождения они обязательно должны учитываться. Случается, что по коммерческим соображениям законами следует пренебречь. Например, это может быть обусловлено маркетингом, если существует необходимость провести ряд модификаций системы в одной версии. В результате все равно получится так, что одна или несколько следующих версий будут связаны с исправлением ошибок. Может показаться, что большие различия между последовательными версиями одной и той же программы опровергнут законы Лемана. Например, Microsoft Word превратилась из простой программы текстовой обработки, требующей 25 Кбайт памяти, в огромную систему с множеством функций. Теперь, для того чтобы работать с этой программой, нужно много памяти и быстродействующий процессор. Эволюция этой программы противоречит четвертому и пятому законам Лемана. Однако я подозреваю, что это все-таки не одна и та же программа, которая просто подверглась ряду изменений. Думаю, программа была существенно переработана; по сути, была разработана новая программа, но в рекламных целях был сохранен единый логотип. 2. Сопровождение программного обеспечения Сопровождение — это обычный процесс изменения системы после ее поставки заказчику. Эти изменения могут быть как элементарно простыми (исправление ошибок программирования), так и более серьезными, связанными с корректировкой отдельных недоработок либо приведением в соответствие с новыми требованиями. Как упоминалось в вводной части главы, сопровождение не связано со значительным изменением архитектуры системы. При сопровождении тактика простая: изменение существующих компонентов системы либо добавление новых. Существует три вида сопровождения системы. 1. Сопровождение с целью исправления ошибок. Обычно ошибки в программировании достаточно легко устранимы, однако ошибки проектирования стоят дорого и требуют корректировки или перепрограммирования некоторых компонентов. Самые дорогие исправления связаны с ошибками в системных требованиях, так как здесь может понадобиться перепроектирование системы. 2. Сопровождение с целью адаптации ПО к специфическим условиям эксплуатации. Это может потребоваться при изменении определенных составляющих рабочего окружения системы, например аппаратных средств, операционной системы или программных средств поддержки. Чтобы адаптироваться к этим изменениям, система должна быть подвергнута определенным модификациям. 3. Сопровождение с целью изменения функциональных возможностей системы. В ответ на организационные или деловые изменения заказчик может изменить требования к программным средствам. В таких случаях применяется данный тип сопровождения. Наиболее существенные изменения при этом претерпевает именно программное обеспечение. На практике однозначно четкое разграничение между различными видами сопровождения провести достаточно сложно. Ошибки в системе могут быть выявлены в том случае, если, например, система использовалась непредсказуемым способом. Поэтому наилучший способ исправления ошибок - расширение функциональных возможностей программы с тем, чтобы сделать работу с ней как можно проще. При адаптации программного обеспечения к новому рабочему окружению расширение функциональных возможностей системы будет способствовать улучшению ее работы. Также добавление определенных функций в программу может оказаться полезным, если в случае ошибок был изменен шаблон использования системы и побочным действием при расширении функциональных возможностей будет удаление ошибок. Перечисленные типы сопровождения широко используются, хотя им подчас дают разные названия. Сопровождение с целью исправления ошибок обычно называют корректирующим. Название «адаптивное сопровождение» может относиться как к адаптации к новому рабочему окружению, так и к новым требованиям. Усовершенствование программного обеспечения может означать улучшение путем соответствия новым требованиям, а также усовершенствование структуры и производительности с сохранением функциональных возможностей. Я намеренно не употребляю здесь все эти названия, чтобы избежать излишней путаницы. Рис. 4. Распределение типов сопровождения Найти современные данные относительно того, как часто используется тот или иной тип сопровождения, будет нелегко. Согласно исследованиям, 65% сопровождения связано с выполнением новых требований, 18% отводится на изменения системы с целью адаптации к новому окружению и 17% связано с исправлением ошибок (рис. 4.). Из этого можно определить, что исправление ошибок не является самым распространенным видом сопровождения. Модернизация системы в соответствии с новым рабочим окружением либо в соответствии с новыми требованиями более эффективна. Поэтому сопровождение само по себе является естественным процессом продолжения разработки системы со своими процессами проектирования, реализации и тестирования. Таким образом, спиральная модель, показанная на рис. 5, лучше представляет процесс развития ПО, чем каскадная модель, где сопровождение рассматривается как отдельный процесс. Рис. 5. Спиральная модель развития ПО Значительная часть бюджета большинства организаций уходит на сопровождение ПО, а не на само использование программных систем. В 1980-х годах было обнаружено, что во многих организациях по меньшей мере 50% всех средств, потраченных на программирование, идет на развитие уже существующих систем. При этом от 65 до 75% средств общего бюджета расходуется на сопровождение. Так как предприятия заменяют старые системы коммерческим ПО, например программами планирования ресурсов, эти цифры никак не будут уменьшаться. Поэтому можно утверждать, что изменение ПО все еще остается доминирующим в статье затрат организаций на программное обеспечение. Соотношение между величинами средств на сопровождение и на разработку может быть разным в зависимости от предметной области, где эксплуатируется система. Для прикладных систем, работающих в деловой сфере, соотношение затрат на сопровождение в основном сравнимо со средствами, потраченными на разработку. Для встроенных систем реального времени затраты на сопровождение могут в четыре раза превышать стоимость самой разработки. Высокие требования в отношении производительности и надежности таких систем предполагают их жесткую структуру, которая труднее поддается модификации. Можно получить значительную общую экономию средств, если заранее потратить финансы и усилия на создание системы, не требующей дорогостоящего сопровождения. Весьма затратно проводить изменения в системе после ее поставки заказчику, поскольку для этого требуется хорошо знать систему и провести анализ реализации этих изменений. Поэтому усилия, потраченные во время разработки программы на снижение стоимости такого анализа, автоматически снизят и затраты на сопровождение. Такие технологии разработки ПО, как формирование четких требований, объектно-ориентированное программирование и управление конфигурацией, способствуют снижению стоимости сопровождения. На рис. 6 показано, как снижается стоимость сопровождения хорошо разработанных систем. Здесь при разработке системы 1 выделено дополнительно $25 000 для облегчения процесса сопровождения. В результате за время эксплуатации системы это помогло сэкономить около $100 000. Из сказанного следует, что увеличение средств на разработку системы пропорционально снизит затраты на ее сопровождение. Рис. 6. Расходы на разработку и сопровождение систем Причиной высоких затрат на сопровождение является сложность модернизации системы после ее внедрения, поскольку расширить функциональные возможности намного легче в процессе создания системы. Ниже приведены ключевые факторы, которые определяют стоимость разработки и сопровождения и могут привести к подорожанию сопровождения. 1. Стабильность команды разработчиков. Вполне естественно, что после внедрения системы команда разработчиков распадается, специалисты будут работать над другими проектами. Новым членам команды или же отдельным специалистам, которые возьмут на себя дальнейшее сопровождение системы, будет трудно понять все ее особенности. Поэтому на понимание системы перед внесением в нее изменений уходит много времени и средств. 2. Ответственность согласно контракту. Контракт на сопровождение обычно заключается отдельно от договора на разработку программы. Более того, часто контракт на сопровождение может получить фирма, сама не занимающаяся разработкой. Вместе с фактором нестабильности команды это может стать причиной отсутствия в команде стимула создать легко изменяемую, удобную в сопровождении систему. Если членам команды выгодно пойти кратчайшим путем с минимальными затратами усилий, то вряд ли они откажутся от этого даже с риском повышения последующих затрат на сопровождение. 3. Квалификация специалистов. Специалисты, занимающиеся сопровождением, часто не знакомы с предметной областью, где эксплуатируется система. Сопровождение не пользуется популярностью среди разработчиков. Это считается менее квалифицированной разработкой и часто поручается младшему персоналу. Более того, старые системы могут быть написаны на устаревших языках программирования, не знакомых молодым специалистам и требующих дополнительного изучения. 4. Возраст и структура программы. С возрастом структура программ нарушается вследствие частых изменений, поэтому их становится сложнее понимать и изменять. Кроме того, многие наследуемые системы были созданы без использования современных технологий. Они никогда не отличались хорошей качественной структурой; изменения, сделанные в них, были направлены скорее на повышение эффективности функционирования, чем на повышение удобства сопровождения. Документация на старые системы часто бывает неполной либо вообще отсутствует. Первые три проблемы объясняются тем, что многие организации все еще делают различие между разработкой системы и ее сопровождением. Сопровождение считается делом второстепенным, поэтому нет никакого желания инвестировать средства для снижения затрат на будущее сопровождение. Руководству организаций необходимо помнить, что у систем редко бывает четко определенный срок функционирования, наоборот, они могут находиться в эксплуатации в той либо иной форме неограниченное время. Дилемма заключается в следующем: или создавать системы и поддерживать их до тех пор, пока это возможно, и затем заменять их новыми, или разрабатывать постоянно эволюционирующие системы, которые могут изменяться в соответствии с новыми требованиями. Их можно создавать на основе наследуемых систем, улучшая структуру последних с помощью реинжиниринга, либо путем изменения архитектуры этих систем, что подробно рассматривается в разделе 3. Последняя проблема, а именно нарушение структуры, является самой простой из них. Технология реинжиниринга поможет усовершенствовать структуру и повысить понятность системы. В подходящих случаях адаптировать систему к новым аппаратным средствам может и преобразование архитектуры (см. далее). Профилактические меры при сопровождении будут полезны, если возникнет необходимость усовершенствовать систему и сделать ее более удобной для изменений. 2.1. Процесс сопровождения Процессы сопровождения могут быть самыми разными, что зависит от типа программного обеспечения, технологии его разработки, а также от специалистов, которые непосредственно занимались созданием системы. Во многих организациях сопровождение носит неформальный характер. В большинстве случаев разработчики получают информацию о проблемах системы от самих пользователей в устной форме. Другие же компании имеют формальный процесс сопровождения со структурированной документацией на каждый его этап. Но на самом общем уровне любые процессы сопровождения имеют общие этапы, а именно: анализ изменений, планирование версий, реализация новой версии системы и поставка системы заказчику. Процесс сопровождения начинается при наличии достаточного количества запросов на изменения от пользователей, менеджеров или покупателей. Далее оцениваются возможные изменения с тем, чтобы определить уровень модернизации системы, а также стоимость внедрения этих изменений. Если принимается решение о модернизации системы, начинается этап планирования новой версии системы. Во время планирования анализируется возможность реализации всех необходимых изменений, будь то исправление ошибок, адаптация или расширение функциональных возможностей системы. Только после этого принимается окончательное решение о том, какие именно изменения будут внесены в систему. Когда изменения реализованы, выходит очередная версия системы. На рис. 7 представлен весь процесс модернизации. Рис. 7. Схема процесса модернизации В идеале процесс модернизации должен привести к изменению системной спецификации, архитектуры и программной реализации (рис. 8). Новые требования должны отражать изменения, вносимые в систему. Ввод в систему новых компонентов требует ее перепроектирования, после чего необходимо повторное тестирование системы. Для анализа вносимых изменений при необходимости можно создать прототип системы. На этой стадии проводится подробный анализ изменений, при котором могут выявиться те последствия модернизации, которые не были замечены при начальном анализе изменений. Рис. 8. Выполнение модернизации Иногда в экстренных случаях требуется быстрое внесение изменений, например по следующим причинам. • Сбой в системе, вследствие чего возникла чрезвычайная ситуация, требующая экстренного вмешательства для продолжения нормальной работы системы. • Изменение рабочего окружения системы с непредусмотренным влиянием на систему. • Неожиданные изменения в деловой сфере организации (из-за действий конкурентов или из-за введения нового законодательства). В таких случаях быстрая реализация изменений имеет большую важность, чем четкое следование формальностям процесса модернизации системы. Вместо того чтобы изменять требования или структуру системы, лучше быстро внести коррективы в программный код (рис. 9). Однако этот подход опасен тем, что требования, системная архитектура и программный код постепенно теряют целостность. Этого трудно избежать, если принять во внимание необходимость быстрого выполнения задания, когда тщательная доработка системы откладывается на потом. Если разработчик, который изменил код, внезапно уходит из команды, то его коллеге будет сложно привести в соответствие сделанным изменениям спецификацию и структуру системы. Рис. 9. Процесс экстренной модернизации системы Еще одна проблема срочных изменений системы состоит в том, что из-за дефицита времени из двух возможных решений будет принято не самое лучшее (в аспекте сохранения структуры системы), а то, которое можно быстрее и эффективнее реализовать. В идеале после срочной коррекции кода системы запрос на изменения должен все еще оставаться в силе. Поэтому после тщательного анализа изменений можно отменить внесенные изменения и принять более оптимальное решение для модернизации системы. Однако на практике такая возможность используется крайне редко, чаще всего в силу субъективных причин. 2.2. Прогнозирование сопровождения Менеджеры терпеть не могут сюрпризов, особенно если они выливаются в непредсказуемо высокие затраты. Поэтому лучше предусмотреть заранее, какие изменения возможны в системе, с какими компонентами системы будет больше всего проблем при сопровождении, а также рассчитать общие затраты на сопровождение в течение определенного периода времени. На рис. 10 представлены различные типы прогнозов, связанные с сопровождением, и показано, на какие вопросы они должны ответить. Прогнозирование количества запросов на изменения системы зависит от понимания взаимосвязей между системой и ее окружением. Некоторые системы находятся в достаточно сложной взаимозависимости с внешним окружением и изменение окружения обязательно повлияет на систему. Для того чтобы правильно судить об этих взаимоотношениях, необходимо оценить следующие показатели. 1. Количество и сложность системных интерфейсов. Чем больше системных интерфейсов и чем более сложными они являются, тем выше вероятность изменений в будущем. 2. Количество изменяемых системных требований. Требования, отражающие деловую сферу или стандарты организации, чаще изменяются, чем требования, описывающие предметную область. 3. Бизнес-процессы, в которых используется данная система. По мере развития бизнес-процессы приводят к появлению новых требований к системе. Чтобы корректно спрогнозировать процесс сопровождения, нужно знать количество и типы взаимосвязей между разными компонентами системы, а также учитывать сложность этих компонентов. Исследования показали, что, чем выше сложность системы и ее компонентов, тем более дорогостоящим окажется сопровождение, чего и следовало ожидать. Рис. 10. Прогнозирование сопровождения Исследование ряда коммерческих программ, написанных на языке COBOL, с использованием разных методик измерения сложности, включая размер процедур, размер модулей и количество ветвлений, что определяет сложность системы, показало, что снижение сложности программирования значительно сокращает расходы на сопровождение системы. Измерение уровня сложности систем оказалось весьма полезным для выявления тех компонентов систем, которые будут особенно сложны для сопровождения. Результаты анализа ряда системных компонентов показали, что сопровождение часто сосредоточено на обслуживании небольшого количества частей системы, которые отличаются особой сложностью. Поэтому экономически выгодно заменить сложные системные компоненты более простыми их версиями. После введения системы в эксплуатацию появляются данные, позволяющие прогнозировать дальнейшее сопровождение системы. Перечисленные ниже показатели полезны для оценивания удобства сопровождения. 1. Количество запросов на корректировку системы. Возрастание количества отчетов о сбоях в системе означает увеличение количества ошибок, подлежащих исправлению при сопровождении. Это говорит об ухудшении удобства сопровождения. 2. Среднее время, потраченное на анализ причин системных сбоев и отказов. Этот показатель пропорционален количеству системных компонентов, в которые требуется внести изменения. Если этот показатель возрастает, система требует многочисленных изменений. 3. Среднее время, необходимое на реализацию изменений. Не следует путать этот показатель с предыдущим, хотя они тесно связаны. Здесь учитывается не время анализа системы по выявлению причин сбоев, а время реализации изменений и их документирования, которое зависит от сложности программного кода. Увеличение этого показателя означает сложность сопровождения. 4. Количество незавершенных запросов на изменения. С возрастанием количества таких запросов затрудняется сопровождение системы. Для определения стоимости сопровождения используется предварительная информация о запросах на изменения и прогнозирование относительно удобства сопровождения системы. В решении этого вопроса большинству менеджеров поможет также интуиция и опыт. В модели определения стоимости СОСОМО 2 предполагается, что для оценки стоимости сопровождения понадобятся сведения об усилиях, потраченных на понимание существующего кода системы и на разработку нового. 3. Эволюция системной архитектуры В процессе сопровождения большинство изменений проводится локализовано и не влияет на архитектуру системы. Однако начиная с 1980-х годов экономические показатели компьютерных систем изменились настолько, что стало более выгодно применять распределенные, а не централизованные, как раньше, системы. Поэтому многие компании были поставлены перед необходимостью преобразовать свои централизованные системы, реализованные на мэйнфреймах, в распределенные системы типа клиент/сервер. Перечислим основные причины перехода от централизованных к распределенным системам. 1. Стоимость аппаратных средств. Закупка и сопровождение распределенных систем клиент/сервер обойдется гораздо дешевле, чем покупка мэйнфрейма эквивалентной мощности. 2. Усовершенствование пользовательских интерфейсов. Многие из наследуемых систем, основанных на мэйнфреймах, имеют текстовые интерфейсы, основанные на формах. Сегодня пользователям привычнее графические интерфейсы и более простое взаимодействие с системами. Такого рода интерфейсы требуют большего количества локальных вычислений и более эффективно работают в системах типа клиент/сервер. 3. Распределенный доступ к системам. Сейчас все больше компаний стараются децентрализовать рабочие места, что требует децентрализации компьютерных систем. При этом необходимо, чтобы компьютерные системы были доступны из разных мест и с разного оборудования. Например, сотрудники могут получить доступ к системам из собственного дома с помощью гаджетов, и такую практику нужно поддерживать. С переходом на распределенную архитектуру компьютерных систем организации значительно снижают расходы на аппаратное обеспечение и способны создать систему с более удобным интерфейсом и более современным дизайном, а также могут поддерживать практику распределенной работы. В этом переходном периоде неизбежно должно произойти преобразование системы к объектно-ориентированной модели, что, в свою очередь, может снизить затраты на сопровождение системы в будущем. Однако нужно отметить, что преобразование архитектуры наследуемой системы является сложной задачей и требует больших расходов. Прежде чем приступить к этому процессу, необходимо провести тщательный анализ наследуемой системы, чтобы оценить реальную пользу от преобразования системной архитектуры. Основная трудность при децентрализации наследуемых систем заключается в том, что в их структуре не существует четкого разграничения между архитектурными компонентами. Идеальной (и желательной) считается структура системы, показанная на рис. 11. В этом случае есть четкое разделение интерфейса пользователя, сервисов, предоставляемых системой, и базы данных. При этом сервисы четко различимы. В системе с такой структурой легко определить распределяемые компоненты, которые можно перепрограммировать и запустить на машинах клиентов. Рис. 11. Идеальная и реальная структуры систем Но реальные наследуемые системы напоминают систему, представленную на рис. 11 справа, в которой интерфейс пользователя, сервисы и доступ к данным перемежаются. Интерфейс пользователя и сервисы реализованы с помощью одних и тех же компонентов, нет четкого разделения между сервисами и базой данных системы. В таких условия определение компонентов, подлежащих распределению, практически невозможно. В случаях, когда невозможно разделять наследуемую систему на распределяемые компоненты, следует применить альтернативный подход. Наследуемая система преобразуется в сервер, интерфейс пользователя реализуется на машине клиента, а промежуточное ПО обеспечивает взаимосвязь запросов, поступающих с машины клиента, с наследуемой системой. Этот подход показан на рис. 12. Рис. 12. Преобразование наследуемой системы в распределенную Несмотря на интеграцию интерфейса пользователя и предоставляемых наследуемой системой сервисов, все-таки при планировании децентрализации лучше рассматривать их в качестве отдельных логических уровней (рис. 13). 1. Уровень представления отвечает за организацию вывода на экран информации для конечных пользователей системы. 2. Уровень проверки данных связан с управлением вводом-выводом данных, осуществляемым конечными пользователями. 3. Уровень управления взаимодействием определяется последовательностью операций конечных пользователей и порядком смены экранов, отображающихся на машинах конечных пользователей. 4. Уровень сервисов приложения отвечает за выполнение основных вычислений приложением. 5. Уровень базы данных отвечает за хранение и управление данными приложения. Создавать распределенную базу данных для большинства наследуемых систем невыгодно, но для распределения других уровней существует целый ряд альтернатив, которые показаны на рис. 14. В простейшем случае компьютер клиента предоставляет только интерфейс пользователя, все другие уровни реализованы на сервере. Противоположный случай - сервер управляет только базой данных, все остальные операции выполняет машина клиента. Естественно, что эти варианты распределения не являются взаимоисключающими. Можно начать с распределения уровня представления, а при наличии ресурсов и времени можно распределить другие логические уровни. Рис. 14. Варианты распределенных систем Когда наследуемая система представлена в виде сервера и доступ к ней осуществляется посредством промежуточного ПО (см. рис. 12), распределение системы можно начинать с варианта, показанного на рис. 14 слева, а затем постепенно переходить к варианту, показанному справа. При реализации новых сервисов они принимают на себя функции наследуемой системы на сервере, передавая управление операциями по обработке данных машине клиента. В конце концов такая постепенная переадресация функций приводит к тому, что большая часть изначальной наследуемой системы не используется, она принимает на себя только функции канала обслуживания базы данных для распределенной системы. При достижении этого этапа уже можно будет решать, оставить ли наследуемую систему либо заменить ее системой управления данными. Распределение интерфейсов пользователя Многие наследуемые системы введены в эксплуатацию еще до того, как были изобретены графические интерфейсы пользователей. Такие системы имеют интерфейсы, основанные на текстовых формах, которые выполняются на терминалах, способных выводить на экран только символьные изображения. Вычислительные средства таких терминалов относительно слабые, поэтому все основные вычислительные функции принимает на себя центральная ЭВМ. При распределении интерфейсов пользователя применяются мощности локальных вычислительных устройств, обеспечивающие графический интерфейс, который в большей мере отвечает потребностям пользователей. Функции интерфейса (представление данных, управление взаимодействием и проверка данных) переводятся на локальное вычислительное устройство, а текстовый интерфейс заменяется графическим интерфейсом пользователя. Серверу остаются функции по обработке данных и реализации сервисов приложения. Если наследуемая система обладает четкой структурой, в которой легко выделить интерфейс пользователя, ее можно преобразовать в систему с распределенными интерфейсами пользователя. Для этого следует перенести на компьютер клиента те компоненты системы, которые отвечают за взаимодействие с пользователем. Связь этих компонентов с основной программой осуществляется с помощью интерфейса, подобного изначальному текстовому. Однако часто встречаются системы, в которых интерфейс и приложение интегрированы так, что невозможно вычленить код интерфейса. В этом случае можно прибегнуть к варианту распределения интерфейсов пользователя, который показан на рис. 15. Рис. 15. Распределение пользовательских интерфейсов Промежуточное ПО управления экранами (окнами), показанное на рис. 15, осуществляет связь с приложением и действует точно так же, как терминал пользователя. Это программное обеспечение использует описание каждого экрана для интерпретации и вывода данных на экран. В таком виде данные пересылаются на машину клиента, где они представляются с помощью графического интерфейса. В настоящее время процесс описания структуры интерфейса можно реализовать с помощью языка XML. В этом случае не обязательно изменять наследуемую систему. Нужно только создать промежуточное ПО управления экранами и программу поддержки интерфейса на машине клиента. Для реализации распределения пользовательских интерфейсов используются две стратегии. 1. Реализация интерфейса с помощью системы управления окнами, установленной на машине клиента и осуществляющей связь с сервером. 2. Реализация интерфейса пользователя с помощью Web-броузера. В первом случае интерфейс создается с помощью подходящего языка программирования, например Java, или с помощью языка сценариев Visual Basic. Для реализации интерфейса на машине пользователя выполняются запросы к функциям операционной системе. Во втором случае для создания интерфейса на основе Web-страниц применяется язык HTML и Web-броузеры. Каждый подход имеет свои преимущества и недостатки, которые представлены в табл. 2. Таблица 2. Преимущества и недостатки стратегий реализации распределенных пользовательских интерфейсов Стратегия Преимущества Недостатки Реализация с помощью системы управления окнами. Доступ ко всем функциям интерфейса пользователя. Улучшенная работа интерфейса пользователя Зависимость от аппаратной платформы. Трудности согласования интерфейсов Реализация с помощью Web-броузера Независимость от аппаратной платформы. Снижение затрат на обучение работе с интерфейсом (интерфейс Web-броузера знаком всем). Легче добиться согласования интерфейсов Более низкая производительность интерфейса. Возможности дизайна интерфейса ограничены возможностями Web-броузера Переход с обычных интерфейсов на интерфейсы Web-броузеров приобрел такую популярность благодаря независимости от аппаратной платформы и широким возможностям Web-броузеров. Приложения на языке Java применимы для локальных вычислений на машине клиента, что позволяет сравнить эти интерфейсы с теми, которые основаны на системе управления окнами. Большая трудность в преобразовании интерфейсов, основанных на текстовых формах, в графические состоит в том, что они различаются способами управления взаимодействием и проверки данных. В первом случае компьютерная система осуществляет управление взаимодействием и выполняет проверку данных сразу после поступления информации. Для этого необходимо, чтобы поля форм заполнялись в определенном порядке. В графическом интерфейсе пользователь произвольно выбирает интересующие его поля. Такое управление машина не может предсказать. Поэтому возникает дополнительный поток обмена данными между ПК пользователя и сервером. Проверка данных возможна лишь в случае полного заполнения всех полей, иначе работа системы замедляется за счет частых обменов данными между клиентом и сервером. 4. Преобразование исходного кода программ Самый простой способ реинжиниринга программ — это автоматический перевод исходного кода с одного языка программирования на другой, более современный. При этом структура и организация программ остаются неизменными. Программа может переводиться как на обновленную версию исходного языка (например, с языка COBOL-74 на язык COBOL-85), так и на другой «не родственный» язык (например, с языка FORTRAN на С). Причины перевода на другой язык могут быть следующие. 1. Обновление платформы аппаратных средств. В организации может быть принято решение по изменению аппаратной платформы. Новые аппаратные средства могут не поддерживать компиляторы исходного языка программ. 2. Недостаток квалифицированного персонала. Бывает, что для сопровождения программ на исходном языке невозможно найти достаточно квалифицированный персонал, особенно это касается программ, написанных на специфических языках, давно вышедших из употребления. 3. Изменения политики организации. Организация может принять решение о переходе на общий стандартный язык программирования, чтобы снизить затраты на сопровождение программных систем, поскольку сопровождение большого количества версий старых компиляторов невыгодно. 4. Недостаточно средств поддержки старого НО. Поставщик компиляторов для старого языка программирования может уйти с рынка программных продуктов или прекратить поддержку своего продукта. Процесс перевода исходного кода программ показан на рис. 16. Преобразование исходного кода будет эффективным только тогда, когда есть возможность выполнить основной перевод автоматически. Это может сделать либо специально созданная программа, либо коммерческая программа по конвертированию кода с одного языка в другой, либо система сопоставления с образцом. В последнем случае нужно создать список команд для описания перевода с одного языкового представления на другое. Параметризированные образцы исходного языка подвергаются сравнению и сопоставлению с такими же образцами в новом языке. Рис. 16. Процесс преобразования программ В некоторых случаях автоматизированный перевод становится невозможным. Структурные компоненты исходного кода могут не иметь соответствия в новом языке. Одна из причин этого в том, что исходный язык может содержать встроенные условные команды компиляции, которые не поддерживаются в новом языке. В такой ситуации придется настраивать и совершенствовать создаваемую систему вручную. 5. Анализ систем Цель такого анализа - восстановление структуры и спецификации системы. Этот процесс не подразумевает изменения программ. Входными данными процесса анализа обычно служит исходный код системы. Однако зачастую даже он недоступен, тогда процесс анализа начинается с исполняемой программы. Анализ систем не тождественен реинжинирингу систем. Целью анализа является определение архитектуры и спецификации системы на основе ее исходного кода. Целью реинжиниринга можно назвать создание усовершенствованной и удобной в сопровождении системы. Но, как показано на рис. 2, анализ системы может быть составной частью процесса реинжиниринга. Схема процесса анализа системы приведена на рис. 17. Вначале с помощью автоматизированных средств проводится анализ структуры системы. В большинстве случаев этого недостаточно для воссоздания системной архитектуры. Требуется дополнительная работа с исходным кодом системы и с моделью ее структуры. Эта дополнительная информация сравнивается с данными, собранными во время автоматического анализа системы, и представляется в виде ориентированного графа, отображающего связи в исходном коде программ. Рис. 17. Процесс анализа систем Репозиторий системной информации служит для сравнения структуры графа и кода. На основе ориентированного графа можно получить такие документы, как схемы структуры программ и данных, а также матрицы зависимостей. Матрицы зависимостей показывают места определения в программах системных объектов и ссылки на них. Процесс разработки документации повторяющийся, так как информация о системной структуре используется для дальнейшего уточнения информации, которая хранится в системном репозиторий. В процессе анализа полезны разные средства просмотра программ, которые предоставляют различные системы представления программ и позволяют легко перемещаться по исходному коду. Например, с их помощью можно найти определения данных, а затем переместиться по коду к месту их использования. После создания документации по системной архитектуре, в репозиторий вводится дополнительная информация, позволяющая восстановить системную спецификацию. Также обязательно ручное описание структуры системы. К сожалению, спецификацию невозможно создать автоматически из модели системы. 6. Совершенствование структуры программ Если в процессе эксплуатации наследуемой системы возникла необходимость оптимизировать использование памяти и имеются проблемы с пониманием того, как она работает, это означает, что система плохо структурирована. Управляющая структура наследуемых систем обычно значительно усложнена множеством безусловных переходов и нечеткой логикой программного кода. Регулярное сопровождение системы также не способствует сохранению системной структуры. После частых изменений некоторые фрагменты кода становятся неиспользуемыми, однако это можно обнаружить только после тщательного анализа программы. В листинге 1 показан пример того, как усложненная логика управления может сделать трудной для понимания достаточно простую программу. Программа написана на языке, подобном FORTRAN, который часто использовался для создания программ такого рода. Программа не стала понятнее даже после того, как я дал переменным осмысленные имена. Это программа управления обогревателем. Панельный переключатель имеет положения On (Включено), Off (Выключено) и Controlled (Регулирование). Если система находится в режиме регулирования, она включается или выключается в зависимости от термореле и установок таймера. Если обогреватель включен, переключатель Switch-heating выключает его, и наоборот. Как правило, такая сложная логическая структура, как в коде листинга 1, образуется после внесения изменений в процессе сопровождения. Реализуя новые условия или связанные с ними действия, забывают об изменении структуры программы. Не задумываясь о перспективе, этот путь можно назвать кратчайшим и менее рискованным, так как он снижает вероятность возникновения большого количества ошибок в системе. Если же подумать о будущем, это решение приведет к трудному для понимания коду. Сложная структура кода может также появиться от желания программистов избежать дублирования кода. Ранее, когда на программы накладывалось требование ограничения памяти, это было обязательным условием. Листинг 1. Программа с нечеткой логикой Start: Get (Time-on, Time-off, Time, Setting, Temp, Switch) if Switch = off goto off if Switch = on goto on goto Cntrld off: if Heating-status = on goto Sw-off goto loop on: if Heating-status = off goto Sw-on goto loop Cntrld: if Time = Time-on goto on if Time = Time-off goto off if Time < Time-on goto Start if Time > Time-off goto Start if Temp > Setting then goto off if Temp < Setting then goto on Sw-off: Heating-status:= off goto Switch Sw-on: Heating-status:= on Switch: Switch-heating loop: goto Start В листинге 2 приведена та же самая программа, переписанная мной с использованием структурированных управляющих конструкций. Три положения переключателя (On, Off и Controlled) четко определены и связаны с соответствующим кодом. Язык Java не был использован при написании этой программы потому, что исходная программа не являлась объектно-ориентированной. Листинг 2. Структурированная программа loop -- Get получает значения переменных из окружения системы Get (Time-on, Time-off, Time, Setting, Temp, Switch) ; case Switch of when On=> if Heating-status = off then Switch-heating; Heating-status:=on; end if; when Off=> if Heating-status = on then Switch-heating; Heating-status:=off; end if; when Controlled => if Time >= Time-on and Time <= Time-off then if Temp > Setting and Heating-status = on then Switch-heating; Heating-status = off; elsif Temp < Setting and Heating-status = off then Switch-heating; Heating-status:= on; end if ; end if; end case; end loop; В процессе реструктуризации программ можно также упрощать сложные условные операторы. В листинге 3 показан пример упрощения условного оператора, содержащего логический оператор отрицания not. Листинг 3. Упрощение условия -- Сложное условие if not (A > В and (С < D or not (E > F) ) )... -- Упрощенное условие if А <= В and (С <= D or Е > F)... Доказано, что любую программу можно переписать с помощью простых условных операторов if-then-else и циклов while-loop, при этом можно исключить все безусловные операторы перехода. Эта теорема является основой автоматической реструктуризации программ. Этапы такого преобразования программ показаны на рис. 18. Сначала программа представляется в виде ориентированного графа, после чего создается структурированная программа без использования операторов перехода. Рис. 18. Автоматическая реструктуризация программ Созданный ориентированный граф показывает поток передачи управления в программе. К этому графу применяются методы упрощения и преобразования, в результате чего находятся и устраняются неиспользуемые части кода. После этого генерируется новая программа, при этом операторы безусловного перехода заменяются циклами и условными операторами. Такая программа может быть написана как на исходном языке, так и на любом другом (например, программу на языке FORTRAN можно конвертировать в программу на С). Автоматизированный способ реструктуризации программ имеет свои проблемы. 1. Потеря комментариев. Если в программе есть встроенные комментарии, они будут утеряны в процессе реструктуризации. 2. Утрата документации. По той же причине обычно нарушается соответствие между новой программой и документацией на исходную программу. Однако в большинстве случаев это не так уж важно, поскольку документация и комментарии уже устарели. 3. Жесткие требования к компьютерной технике. Алгоритмы, встроенные в средства реструктуризации, отличаются высокой сложностью. Процесс реструктуризации больших программ, даже выполненный на современных быстродействующих компьютерах, будет занимать много времени. Если программа находится под управлением данных и программные компоненты тесно связаны с используемыми структурами данных, реструктуризация кода не обязательно значительно улучшит программу. Если программа была написана с помощью редкого варианта языка программирования, стандартные средства преобразования структуры могут выполняться некорректно, поэтому неизбежно ручное вмешательство. Иногда не стоит реструктуризировать все программы системы. Некоторые программы могут отличаться хорошим качеством, другие не подвергались большому количеству изменений, которые повредили бы их структуру. Для выявления тех программ, реструктуризация которых будет наиболее эффективной, можно использовать следующие показатели: • интенсивность сбоев в работе программы; • процентное соотношение кода, измененного на протяжении года; • сложность компонентов. При преобразовании структуры программ также следует учитывать степень соответствия программ или системных компонентов существующим стандартам. 7. Создание программных модулей Это процесс реорганизации программы в целях объединения ее взаимосвязанных частей в отдельном модуле. После этого легче удалить избыточность в соответствующих компонентах, оптимизировать взаимосвязи и упростить интерфейс всей программы. Например, в программе по обработке сейсмографических данных все операции по графическому представлению данных можно собрать в один модуль. Если система будет распределенной, модули можно инкапсулировать как объекты, доступ к которым будет осуществляться через общий интерфейс. В программной системе можно выделить различные типы модулей. 1. Абстракции данных. Это абстрактные типы данных, которые создаются путем объединения данных с компонентами их обработки. 2. Аппаратные модули. Тесно связаны с абстракцией данных и объединяют все функции, управляющие отдельными аппаратными устройствами. 3. Функциональные модули. Объединяют все функции, которые выполняют сходные или взаимосвязанные задачи. Например, в один модуль можно объединить все функции, выполняющие ввод данных и их проверку. Этот подход применяется там, где создание абстракций данных невыгодно. 4. Модули поддержки отдельных процессов. В них сгруппированы все функции и данные, отвечающие за поддержку отдельного бизнес-процесса. Например, в библиотечной системе присутствует модуль, объединяющий все функции, отвечающие за выдачу и возврат книг. Разбиение программы на модули обычно выполняется вручную путем проверки и правки кода. Для этого следует, прежде всего, определить взаимосвязи между компонентами и изучить способ их взаимодействия. Полностью автоматизировать этот процесс нельзя, даже если привлечь средства просмотра и визуализации программ. 8. Создание абстракций данных Чтобы сберечь дисковую память, многие из наследуемых систем работают на основе совместно используемых массивов и общих областей данных. Это значит, что информация в этих областях полностью доступна и различные части системы используют ее по-своему. Изменение общих областей данных экономически невыгодно из-за высокой стоимости анализа влияния этих изменений на использование данных. Именно для снижения стоимости таких изменений можно использовать разбиение программы на модули, построенные на основе абстракций данных. Абстракции данных (т.е. абстрактные типы данных) группируют сами данные и способы их обработки, что делает их более изменяемыми. Абстракции данных скрывают способ представления данных и обеспечивают доступ к ним. При хорошо разработанном интерфейсе модуля данных такие изменения типов данных не повлияют на другие части программы. Чтобы преобразовать общие используемые области данных в объекты или абстрактные типы данных, следует выполнить ряд действий. 1. Провести анализ общих областей данных для выявления логических структур данных. Случается, что одну область используют данные нескольких разных типов. Такие ситуации следует выявлять и реконструировать. 2. Создать абстрактный тип данных или объект для каждой абстракции. Если в языке программирования нет способов сокрытия данных, можно имитировать абстрактный тип данных путем написания соответствующих функций, обеспечивающих обновление и доступ ко всем полям записей данных. 3. Осуществить поиск всех ссылок на данные с использованием системы просмотра программ или генератора перекрестных ссылок. Заменить эти ссылки соответствующими функциями. На первый взгляд эти действия покажутся достаточно простыми, хотя и отнимающими много времени. Однако в действительности все гораздо сложнее из-за разных способов использования области совместных данных. В более старых версиях языков типа FORTRAN, у которых довольно ограниченный набор функций по структурированию данных, программисты могли разработать достаточно сложные стратегии управления данными с помощью совместно используемых массивов. Последующие проблемы вытекают из косвенной адресации совместно используемых структур, а также из адресации со смещением. Проблемы другого рода возникают, если вычислительная машина, на которой выполнялась исходная программа, имеет ограниченную память. В этом случае программисты в разных частях программы могли использовать одну область данных для хранения разных типов данных. Такие явления распознаются только после детального статического и динамического анализа программ. 9. Изменение данных До сих пор все обсуждаемые изменения касались в основном программ и систем. Однако в некоторых случаях придется столкнуться с проблемой изменения данных. Хранение, структура и формат данных, с которыми работает наследуемая система, должны измениться, чтобы соответствовать изменениям в программном обеспечении. Изменение данных — это процесс анализа и реорганизации структуры данных, а иногда еще и изменение значений системных данных. В принципе, если функциональность системы осталась прежней, изменения данных не требуется. Однако существует ряд причин, которые вынуждают изменять данные (так же, как и программы) наследуемой системы. 1. Нарушение данных. С течением времени качество данных снижается. Изменения данных становятся причиной новых ошибок, возможно дублирование значений, изменения во внешнем окружении системы могут не найти адекватного отражения в данных. Эти явления неизбежны, так как время существования данных бывает достаточно большим. Например, персональные данные в банковской системе появляются с созданием нового счета и существуют, по меньшей мере, в течение всей жизни клиента. При изменении обстоятельств у клиента банковские данные должны обновляться, что не всегда происходит корректно. Реинжиниринг системы уменьшает эти трудности, что лишний раз подтверждает его необходимость. 2. Программные ограничения. При разработке систем многие программисты включают в программы ограничения на количество обрабатываемых данных. Но согласно современным требованиям программы должны обрабатывать значительно больше данных, чем было предусмотрено изначально. Именно для устранения подобных ограничений может понадобиться изменение данных. Например, система управления ценными бумагами была способна обрабатывать до 100 транзакций за одну операцию. В компании, где эта система использовалась, осуществлялось управление 2000 транзакций, что вызвало необходимость в создании 20 копий системы. По этой причине впоследствии компания приняла решение о реинжиниринге системы и изменении данных. 3. Эволюция системной архитектуры. При переходе с централизованной системы на распределенную ядром архитектуры должна стать система управления данными с удаленным доступом. Для перемещения данных из отдельных файлов на сервер системы управления базой данных (СУБД) может потребоваться большая работа по изменению этих данных. Как и в случае с реинжинирингом программ, изменение данных имеет свои подходы и методы, которые перечислены в табл. 3. Таблица 3. Методы изменения данных Метод Описание Чистка данных Устраняется дублирование, стирается избыточная информация, ко всем записям применяется единый формат. Все это, как правило, не влечет за собой никаких изменений в программах Расширение возможностей обработки данных Данные и связанные с ними программы подвергаются реинжинирингу для устранения ограничений на обработку данных. Например, увеличивается длина полей, увеличиваются верхние границы массивов и т.п. Также вносятся соответствующие изменения в программы. После этого данные обычно перезаписываются и очищаются Миграция данных Данные переводятся под управление современной СУБД. Этот подход проиллюстрирован на рис. 19 Рис. 19. Миграция данных Некоторые проблемы с данными могут возникнуть в наследуемых системах, состоящих из нескольких программ коллективного пользования. 1. Проблема именования данных. Имена могут быть зашифрованы и трудны для восприятия. Одному и тому же логическому элементу в разных программах могут присваиваться разные имена. С другой стороны, одно и то же имя в разных программах используется для именования различных элементов. 2. Проблема длины полей. Возникает в тех случаях, когда длина поля определена непосредственно в программе. Одному и тому же элементу записи может быть определена разная длина в разных частях программы, либо длина поля слишком мала для представления текущих данных. 3. Проблема организации записей. Записи, относящиеся к одному и тому же элементу, в разных программах могут быть представлены по-разному. Обычно эта проблема возникает с такими языками программирования, как COBOL, где физическая организация записей определяется программистом. В языках типа C++ или Java такой проблемы не существует, так как физической организацией записей занимается компилятор. 4. Проблема констант. Константы (литеральные величины), например налоговые ставки, часто определены в программе, что затрудняет создание символьных ссылок на них. 5. Отсутствие словаря данных. Часто отсутствует словарь данных, в котором отображены применяемые имена, их представления и использование. Если определения данных несовместимы или противоречивы, их значения могут храниться и обрабатываться некорректно. Примеры несовместимости и противоречивости данных приведены в табл. 4. После изменения определений данных их значения преобразуются так, чтобы соответствовать новой структуре данных. Таблица 4. Примеры несовместимости и противоречивости значений данных Данные Описание Различные значения по умолчанию В различных программах одному и тому же логическому элементу данных могут быть присвоены разные значения по умолчанию. Это вызывает трудности в работе программ, которые обрабатывают эти данных. Особая проблема: недопустимое значение присваивается по умолчанию как допустимое Различные единицы измерения Разные программы представляют одинаковую информацию в разных единицах измерения. Например, в США и Великобритании вес может измеряться в фунтах (если взять более старую программу) и в килограммах (в современных системах). Проблема такого же рода возникла в Европе с введением единой валюты. Пришлось изменять системы, рассчитанные на работу с национальной валютой, для того чтобы они смогли работать с евро Несовместимость правил проверки данных В разных программах различные правила проверки данных. Данные, приемлемые для одной программы, могут не восприниматься другой. Особая проблема возникает с архивными данными, которые не обновлялись в соответствии с изменениями правил проверки Противоречия в семантике представлений Программы могут присваивать значения в зависимости от способа представления элементов. Например, в некоторых программах текст в верхнем регистре означает адрес. Программы используют различные соглашения о представлении данных и поэтому могут не воспринимать данные, хотя они и будут верными Несогласованность при обработке отрицательных величин В некоторых программах величинам, которые должны быть всегда положительными, не может быть присвоено отрицательное значение. Другие программы при предъявлении отрицательных величин могут конвертировать их в положительные и т.д. Перед изменением данных необходимо провести подробный анализ программ, которые работают с этими данными. Главная цель анализа - определение в программе деклараций функций, выявление литеральных величин, требующих заменены на именованные константы, поиск встроенных правил проверки данных. При анализе помогают такие средства, как анализаторы перекрестных ссылок и сопоставление с образцом. Для фиксации мест ссылок на элементы данных и изменений, которые там требуются, удобно создать набор таблиц регистрации изменений, которые содержат описание всех этапов изменения данных. Схема процесса изменения данных показана на рис. 20. Рис. 20. Процесс изменения данных На первом этапе процесса изменения данных модифицируются определения данных. На сами данные такая модификация не оказывает влияния. Чтобы автоматизировать этот процесс, можно использовать системы сопоставления с образцом, которые помогают находить и заменять определения, или же можно создать XML-определения данных и использовать их для управления средствами конвертирования данных. Несмотря на это, ручной работы над данными практически невозможно избежать. Если ставится цель улучшить понятность определений данных, то работу можно остановить на этой стадии. Если же имеются проблемы со значениями данных, описанные выше, следует начать второй этап процесса изменения данных. После второго этапа обязательно идет третий - преобразование данных. Обычно это очень дорогостоящий процесс. Для его реализации создаются программы, аккумулирующие информацию о старой и новой структурах данных. Здесь опять применяется система сопоставления с образцом.