Применение генераторов кода

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

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

Генерация пользовательского интерфейса

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

Что дает нам генерация пользовательского интерфейса? Рассмотрим те преимущества, которые дает нам генерация пользовательского интерфейса:

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

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

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

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

Интеграция с существующими инструментами

Многие производители сред разработки интенсивно используют генерацию кода пользовательского интерфейса. Эти среды разработки уже содержат инструменты для создания пользовательского интерфейса. Примерами являются Microsoft Visual Studio и Borland Delphi.

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

Как лучше генерировать интерфейс?

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

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

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

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

Улучшение структуры кода. Код пользовательского интерфейса необходимо делать максимально структурированным и организованным в модули, блоки, компоненты и т.п. Это улучшит качество и единообразие пользовательского интерфейса.

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

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

Выводы по генерации интерфейса

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

Генерация документации

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

Основной причиной этого является то, что разработка полной и актуальной документации является весьма трудоемким мероприятием и занимает сопоставимое (если не больше) время по сравнению с разработкой самого программного кода время.

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

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

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

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

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

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

Генератор документации применяется двумя способами:

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

Пример генерации документации совместно с кодом

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

Рассмотрим пример. Пусть мы имеем следующий файл метаданных:

<?xml-stylesheet type="text/xsl" href="packagecomments.xsl"?>
<packages>
  <package name="pkg_book">
    <comment>
      <![CDATA[ Пакет для выполнения операций над таблицей tbl_book.
        Он делает много хороших вещей.]]>
    </comment>
    <procedure name="SetValues" type="procedure">
      <comment>
        <![CDATA[ Служит для установки значений по идентификатору.]]>
      </comment>
      <parameters>
        <param name="ID" type="number"/>
        <param name="title" type="varchar2"/>
        <param name="author" type="varchar2"/>
      </parameters>
    </procedure>
    <procedure name="GetTitle" type="function">
      <comment>
        <![CDATA[ Служит для извлечения названия книги по идентификатору.]]>
      </comment>
      <parameters>
        <param name="ID" type="number"/>
      </parameters>
    </procedure>
    <procedure name="GetAuthor" type="function">
      <comment>
        <![CDATA[ Служит для извлечения имени автора по идентификатору.]]>
      </comment>
      <parameters>
        <param name="ID" type="number"/>
      </parameters>
    </procedure>
  </package>
</packages>
    

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

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="html"/>
  <xsl:template match="packages/package">
    --<xsl:value-of select="comment"/><br/>
    create or replace package <xsl:value-of select="@name"/>
    <br/><br/>
    <xsl:for-each select="procedure">
      --<xsl:value-of select="comment"/><br/>
      <xsl:choose>
        <xsl:when test ="@type='procedure'">procedure </xsl:when>
        <xsl:otherwise>function </xsl:otherwise>
      </xsl:choose> 
      <xsl:value-of select="@name"/>
      (<xsl:for-each select="parameters/param">
        <xsl:value-of select="@name"/>
        <xsl:text> </xsl:text>
        <xsl:value-of select="@type"/>
        <xsl:if test="not(position()=last())">, </xsl:if>
      </xsl:for-each>);
      <br/>
    </xsl:for-each>
    <br/>
    end <xsl:value-of select="@name"/>
  </xsl:template>
</xsl:stylesheet>
    

Данный стиль XSLT предназначен для генерации кода совместно с комментариями. Так как вывод будет осуществляться в формате HTML, то ставим инструкцию xsl:output в значение html. Далее для каждого пакета выполняется шаблон, включенный в xsl:template. Выполняется проход по каждой процедуре и функции, осуществляется вывод сигнатуры и комментариев. Результат будет следующим:

-- Пакет для выполнения операций над таблицей tbl_book. Он делает много хороших вещей. 
create or replace package pkg_book

-- Служит для установки значений по идентификатору. 
function SetValues (ID number, title varchar2, author varchar2); 
-- Служит для извлечения названия книги по идентификатору. 
function GetTitle (ID number); 
-- Служит для извлечения имени автора по идентификатору. 
function GetAuthor (ID number); 

end pkg_book
    

Теперь рассмотрим шаблон для генерации самой документации:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="html"/>
  <xsl:template match="packages/package">
    Пакет <xsl:value-of select="@name"/>
    <br/>
    <xsl:value-of select="comment"/><br/>
    Содержит следующие процедуры и функции:<br/><br/>
    <xsl:for-each select="procedure">
      <xsl:choose>
        <xsl:when test ="@type='procedure'">Процедура </xsl:when>
        <xsl:otherwise>Функция </xsl:otherwise>
      </xsl:choose>
      <xsl:value-of select="@name"/><br/>
      <xsl:value-of select="comment"/><br/>
      имеет следующие параметры:
      <xsl:for-each select="parameters/param">
        Название: <xsl:value-of select="@name"/>;
        <xsl:text> </xsl:text>
        Тип: <xsl:value-of select="@type"/>;
        <br/>
      </xsl:for-each>
      <br/>
    </xsl:for-each>
  </xsl:template>
</xsl:stylesheet>
    

Он работает аналогично предыдущему стилю. Предлагаю читателю самостоятельно разобраться в его работе. Результатом будет следующий текст:

Пакет pkg_book
Пакет для выполнения операций над таблицей tbl_book. Он делает много хороших вещей. 
Содержит следующие процедуры и функции:

Функция SetValues
Служит для установки значений по идентификатору. 
имеет следующие параметры: Название: ID; Тип: number; 
Название: title; Тип: varchar2; 
Название: author; Тип: varchar2; 

Функция GetTitle
Служит для извлечения названия книги по идентификатору. 
имеет следующие параметры: Название: ID; Тип: number; 

Функция GetAuthor
Служит для извлечения имени автора по идентификатору. 
имеет следующие параметры: Название: ID; Тип: number;
    

А теперь напишем код на языке C#, который запускает трансформацию и позволит сгенерировать оба файла:

string styledoc = "packagecomments.xsl";
string styleprog = "package.xsl";
string document = "package.xml";
string outputdoc = "package.txt";
string outputprog = "package.html";
XslCompiledTransform xt = new XslCompiledTransform();
xt.Load(styledoc);
xt.Transform(document, outputdoc);
xt.Load(styleprog);
xt.Transform(document, outputprog);
Console.Read();
    

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

Генерация разбором кода

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

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

Преимущества генерации документации

Преимущества генерации документации следующие:

Существующие генераторы документации

Практически для каждого популярного языка созданы программы, документирующие код. Для C#, VB и других языков платформы .Net имеется программа NDoc, позволяющая составлять документацию. Имеется приложение Doxygen, используемое в основном для C++, но можно генерировать документацию также для Си, Java, C#, PHP и других языков. Есть Javadoc для Java, PHPDoc для PHP и множество других.

Применение генераторов документации

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

При генерации документации необходимо:

Манипуляция данными

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

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

Преимуществами применения генераторов кода для манипуляции данными являются:

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

Генерация в тестировании

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

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

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

Таким образом:

Возможные применения генерации в тестировании

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

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

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

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

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

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

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

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

Выводы

Таким образом, применение генерации в тестировании позволяет: