к сведению

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

Проектирование процесса тестирования

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

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

Разработка стратегии тестирования

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

автономные тесты (тесты модулей);

тесты связей (проверка стыковки двух и более взаимосвязанных модулей);

системный тест,

приемо-сдаточные испытания (часто выполняются пользователем),

регрессивные тесты (серия старых тестов, позволяющих проверить, не привели ли ваши усовершенствования к появлению неожиданных проблем);

тесты производительности или нагрузочные тесты.

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

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

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

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

Использование CASE-cpedcme

Что можно сказать об использовании CASE-средств в проектировании приложений? Давайте рассмотрим, какой уровень функционального описания должен быть введен в CASE-продукт и насколько полезны генераторы кода. Мы также попытаемся сравнить объем работ по обеспечению такой детализации в CASE-средствах и выгоды, которые можно получить от их использования.

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

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

Эта критика в меньшей степени относится к пакету Oracle Designer/2000. Несмотря на название, он обеспечивает явную поддержку аналитической деятельности, которая должна предварять проектирование. Кроме того, этот продукт предназначался для обеспечения генерации кода и поэтому силен в определении модулей и создании перекрестных ссылок между модулями и атрибутами.

Оценивая возможность использования технологии CASE в своем проекте, обязательно определитесь с тем, как вы собираетесь ее применять;

Хотите ли вы использовать ее просто как репозитарии определений данных?

Хотите ли вы распространить ее и на хранение определений модулей?

Хотите ли вы генерировать из определений модулей код? Выбирая репозитарии, нужно ответить на следующие вопросы;

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

Какой объем рутинной работы можно реализовать с помощью шаблонов и библиотек кода?

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

Используете ли вы методы ускоренной разработки приложений (УРП), и окажет ли генератор помощь в поэтапном макетировании?

Генераторы становятся все более и более мощными, и Oracle ставит целью обеспечить 100%-ную генерацию 100% кода в основных приложениях. Это великая цель, но в мире полной генерации достижение, например, уровня 99,95% означает полный провал (даже если это может оказаться исключительно полезным для запуска проекта). Oracle и ее конкуренты пока далеки от достижения показателя 100% - отчасти из-за крайней сложности получения соответствующей функциональным требованиям модели данных. Вернемся, однако, к реальности... Если вам требуется создать большое число простых модулей, то генератор вполне может сэкономить время и дать более согласованный код. Если же перед вами стоит задача создания небольшого числа сложных модулей, то генератор будет тормозом, поскольку первой работой при этом, несомненно, будет изъятие ненужного сгенерированного кода.

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