Моделирование - это важный этап процесса анализа существующего кода для принятия решений о его повторном использовании. Понимание общей архитектуры кода значительно облегчает создание и поддержку продуктов в полном цикле разработки линейки продуктов (product line engineering - PLE). Необходимо понимать, как устроен исходный код, как максимально эффективно использовать его в будущем и какие участки кода могут потребовать модификации. Главными целями анализа кода являются документирование, повторное использование, модификация и поддержка. В данной статье рассматриваются ключевые аспекты успешного повторного использования кода посредством кодоориентированной разработки и моделирования.
Новые проекты часто используют существующий исходный код. Понимание этого кода является существенным для повторного использования, но все не так просто, как кажется. Например, разработчик кода мог перейти на другую работу или уволиться. Код могла писать группа разработчиков или его могли собрать из нескольких источников. Это может быть код вашей компании, внешний код (например, готовый код или открытый код) или код в виде библиотек. Возможно, он развивался и модифицировался многие годы. Какова бы ни была история кода, необходимо знать, как код взаимодействует и что в нем содержится. Необходимо понимать, как код устроен код, как максимально эффективно использовать его в будущем и какие участки кода могут потребовать модификации.
Основные цели анализа кода можно свести к документированию, повторному использованию, модификации и поддержке. В зависимости от ситуации мотивами для анализа кода могут быть:
- Документирование кода для улучшения его понимания и подготовки к последующему использованию после увольнения (или перехода на другую работу) его разработчика (документирование подразумевает наличие диаграмм, поясняющих код).
- Создание линейки продуктов, в которой функциональность одного из продуктов может не понадобиться в другом.
- Выпуск новой версии приложения с исправлениями или обновлениями.
- Поддержка существующего кода.
Все эти ситуации обосновывают необходимость лучшего понимания существующего кода. Данная статья посвящена мотивам для повторного использования и анализа кода.
Риски повторного использования
Повторное использование кода сопряжено с рисками; существуют ситуации, когда оно может быть невыполнимо. Одна из проблем обоснования инвестиций состоит в том, что некоторые менеджеры не дают времени на освоение старого кода. Другим потенциальным риском является отсутствие понимания области применения и компонентов кода. Невозможность проведения анализа - еще один потенциальный риск.
Стремление понять весь код может оказаться неподъемной задачей, поэтому важно разделить код на составляющие и выделить ключевые для повторного использования части. Потратьте время на определение компонентов кода, которые следует использовать повторно. В некоторых случаях может понадобиться полное документирование кода (например, по регулятивным требованиям), но попытки повторного использования и документирования всего кода обычно не эффективны. Главным образом целью должно быть определение фрагментов кода для документирования и повторного использования.
Четыре ключевых аспекта успеха
Ключевыми аспектами достижения успеха являются:
- Понимание архитектуры первоначального кода для идентификации компонентов, границ и интерфейсов.
- Определение потенциальной возможности повторного использования.
- Оценка затрат времени на повторное использование по сравнению с повторным созданием компонентов.
- Принятие решения по каждому компоненту: что повторно использовать и как (без изменений, с небольшими или значительными изменениями).
Уточнение структуры кода при помощи унифицированного языка моделирования
Отличным способом понимания структуры кода является применение унифицированного языка моделирования (Unified Modeling language - UML). UML - это стандартный графический язык для представления кода. Он позволяет проиллюстрировать работу кода, что в свою очередь позволяет увидеть общий дизайн компонентов. Он помогает понять архитектуру оригинального кода для идентификации компонентов, границ и интерфейсов. UML дает возможность понять взаимодействие фрагментов кода. Используйте UML для анализа кода. Анализ - это первый шаг перед документированием имеющихся программных активов.
Комбинирование кодоориентированной разработки и UML-моделирования
Одним из четырех перечисленных ранее ключевых аспектов успеха является принятие решения по каждому компоненту, а именно: что использовать повторно и как это сделать. Если вы хотите поддерживать существующий код и документировать его, следует продолжать обычную кодоориентированную разработку, скомбинировав ее с моделированием. Даже если нет необходимости преобразовывать код в модель, возможно, вы захотите лучше понять, как устроен существующий код. Этого можно добиться, комбинируя кодоориентированную разработку с моделированием.
Если вы хотите разобраться, можно ли повторно использовать существующий код или нужно создавать новый продукт, либо хотите обслуживать несколько существующих продуктов, управляемая моделями разработка будет наилучшим решением. Объединив кодоориентированную разработку с управляемой моделями разработкой, вы можете определить фрагменты кода для поддержки и повторного использования.
- Ориентация на модель
- Модель определяет не только архитектуру, но и окончательный код приложения.
- Ориентация на код
- Код импортируется в модель в виде ссылки для визуализации. Это означает, что модель используется для демонстрации архитектуры, но не для изменения кода. Для обновления дизайна необходимо обновить код и перенести его обратно в модель.
- Dynamic Model Code Associativity (DMCA)
- В программном обеспечении для моделирования IBM Rational Rhapsody этот подход относится к направлению обновлений. Можно переходить от модели к коду или от кода к модели, либо применять автоматические двунаправленные обновления. Процесс переноса обновлений кода в модель называется round-tripping .
Разные пользователи предпочитают разные сценарии разработки. Пользователи, которым нравится работать с моделями, называются моделеориентированными, в то время как кодоориентированные пользователи предпочитают делать все в коде. Есть и те, кто придерживается промежуточного подхода. Вы можете приспособить выбранный вами тип моделирования и повторного использования кода под разные типы пользователей. Различные типы пользователей могут взаимодействовать и работать совместно, сочетая традиционное кодирование и управляемую моделями разработку.
Эти технологические определения можно отобразить на три разных сценария, описанных в следующих разделах.
Примечание.
Возможен и покомпонентный подход, когда один компонент может быть моделеориентированным, а другой - кодоориентированным.
Сценарии, сочетающие моделеориентированную и кодоориентированную разработки
Существует несколько путей комбинирования традиционного повторного использования кода и моделирования. Разнообразие вариантов описывается четырьмя сценариями:
- Визуализация внешнего кода (только визуализация) - это кодоориентированный процесс. Внешний код остается внешним для вашего инструмента визуального моделирования. В этом инструменте моделирования вы ссылаетесь на внешний код для его использования и тестирования.
- Непрерывное кодирование с обновлением документации - это кодоориентированный процесс с поддержкой отправки обновлений в модель. Вы можете визуализировать код в модели, но не можете менять модель.
- Кодоориентированная разработка, когда в модель переносятся изменения, сделанные в коде. Главную роль играет код.
- Модернизация кода с использованием управляемой моделями разработки, при которой модель является главной. Часть внешнего кода идентифицируется для повторного использования и переносится непосредственно в модель.
Визуализация подразумевает наличие диаграмм, помогающих понять дизайн, структуру кода и взаимосвязи между объектами (например, классы и файлы). Пользователь может создавать новые диаграммы, основанные на элементах модели, добавлять в диаграммы комментарии и связывать элементы модели с требованиями. Описания элементов, поступившие из кода, хранятся в модели и могут быть преобразованы в отчет. Существуют изменения, которые легче выполнить в модели, например, добавление элементов на диаграмму, копирование элементов диаграммы, наследование и многое другое.
При визуализации кода обновления в нем выполняются вне инструмента моделирования. Визуализация внешнего кода выполняется для демонстрации взаимосвязей кода и модели. Например, можно сослаться на внешнюю С-библиотеку и показать эту ссылку на диаграмме. Таким же способом визуализируются и документируются взаимосвязи библиотеки с другими частями модели. В рамках модели можно выполнить управляемое моделями тестирование библиотеки. Управляемая моделями разработка позволяет не только визуализировать код, но и использовать модель для его проверки и тестирования.
Непрерывное кодирование с обновлением документации
Во втором сценарии по мере изменения внешнего кода можно выполнять двунаправленный обмен (round-tripping) для отправки изменений кода в модель. При этом изменения внешнего кода приводят к изменению кода в модели и, тем самым, к обновлению документации. Если выбран вариант визуализации и обновления кода, можно продолжать разработку кода в модели или во внешнем коде и поддерживать их синхронизацию.
Кодоориентированная разработка
Как упоминалось в сценарии 3, при использовании управляемой моделями разработки можно модернизировать код путем генерирования кода в Rational Rhapsody и обновления внешнего кода. Генерирование кода можно выполнить в инструменте моделирования при сохранении инструкций существующего кода в оригинальных исходных файлах. Вариант генерирования кода в модели полезен для получения изменений модели обратно в код. Для демонстрации поведения кода может использоваться анимация модели. В этом сценарии главную роль играет код.
Модернизация кода с использованием управляемой моделями разработки
Можно выбрать поддержку кода в модели. Это основа сценария 4. Чтобы определить, визуализировать ли код (как это делается в сценариях 1-3) или поддерживать его напрямую в модели для реализации управляемой моделями разработки, нужно ответить на ключевой вопрос, хотите ли вы генерировать код именно в модели. Если вы поддерживаете код в модели, можно более эффективно вносить дополнительные изменения и улучшения дизайна. Главную роль играет модель.
Rational Rhapsody демонстрирует простой пример того, как UML позволяет повторно использовать существующий код. Это пример пользователя, создающего новое приложение кассового аппарата на существующем оборудовании. Первая диаграмма называется диаграммой пакетов (Package diagram). Это общее представление пакетов системы. Имеются пакеты CashRegister, Hardware и связывающий их пакет Interfaces. Пакет Interface позволяет повторно использовать Hardware, а также поменять при необходимости существующее оборудование на более новое.
Рисунок 1. Диаграмма пакетов
На диаграмме классов, приведенной ниже, показан класс Cash Register, унаследованный из интерфейса IBarcodeReader. Это позволяет классу CashRegister реализовать интерфейс и принимать данные из класса BarcodeReader, который является внешним пакетом Hardware. Класс BarcodeReader не обязательно показывать на диаграмме, хотя интерфейс Barcode Reader отображается (рисунок 2), поскольку CashRegister для получения соответствующего поведения должен реализовывать только интерфейс.
На диаграмме классов (см. рисунок 3) показан класс Tester, подключающий исходный файл на языке C из внешнего источника. Внешний источник визуализируется для отображения операций и переменных из файла point_of_sale, поэтому класс Tester может определить, что вызывать.
Рисунок 3. Класс Tester, подключающий исходный файл на C из внешнего источника
На анимированной диаграмме последовательности (см. рисунок 4) показан класс CashRegister, сканирующий штрихкоды на товарах и добавляющий товары в счет клиента.
Рисунок 4. Анимированная диаграмма последовательности
Анимация позволяет выполнять приложение либо на хост-машине, либо на целевой машине, а затем просматривать результаты в проекте при помощи Rational Rhapsody. Это важный инструмент для просмотра поведения и отладки кода, что особенно нужно при повторном использовании кода. При просмотре статического кода видны только потенциальные пути по коду. Диаграмма последовательности (такая как на рисунке 4) демонстрирует пути при реальной реакции приложения на внешние воздействия. Таким образом, вы видите пути по приложению в реальном жизненном цикле. Поэтому анимация модели является способом тестирования и проверки поведения повторно используемого кода.
Повторное использование и разработка линейки продуктов
Священным Граалем повторного использования является так называемая разработка линейки продуктов (product line engineering - PLE). Это определение функциональных возможностей приложения, которые будут меняться от продукта к продукту, и отображение этих возможностей на конкретные варианты каждого продукта, чтобы в конечном итоге иметь один набор исходных кодов для нескольких продуктов. Священным Граалем эту работу называют потому, что главной целью повторного использования является повторное использование в продукте, готовящемся к выпуску. В этом заключается также и цель PLE.
Другие варианты создания нескольких продуктов: клонирование и владение или использование конструкций ifdef.
- Клонирование и владение имеет массу проблем. Например, при обнаружении ошибки в одном продукте появится ли она в других? Что произойдет, если вы захотите распространить функциональную возможность на несколько продуктов? Поиск изменений в клонах становится кошмаром.
- Конструкции ifdef делают код нечитабельным и трудным для навигации при работе с конкретным продуктом.
Моделирование помогает решить эту дилемму, добавляя уровень абстракции поверх кода. Можно идентифицировать конкретный элемент модели (класс, функцию или что-нибудь еще) как отображение на функциональность, а затем добавить теги для указания специфичных для продукта отличий. Поскольку используется графический режим, теги могут быть связями, которые можно исследовать по мере необходимости. Кроме того, при генерировании кода из модели используются только теги для конкретного продукта, поэтому вы получаете специализированный код для каждого продукта. Затем выполняются изменения в модели, и каждый продукт, имеющий данную функциональность, получает эти изменения. Нет необходимости распространять изменения от продукта к продукту.
При сжатых сроках очень важным фактором своевременного завершения проекта является повторное использование кода. Сложность заключается в реализации эффективного повторного использования. Прежде всего, разберитесь с архитектурой и проанализируйте компоненты, которые хотите использовать повторно. В этом процессе важное место занимает моделирование, которое помогает проанализировать код и принять решение о том, что подлежит повторному использованию. Понимание общей архитектуры значительно облегчает создание и поддержку продуктов в полном цикле PLE.