Что дадут проекту CRM и ClearQuest?
Как известно, знание - сила. А на сегодня нам известно, что чем больше проект, тем менее он управляем. Как видите, зависимость здесь обратно пропорциональная. Согласитесь, что сотрудник, тестирующий продукт, должен иметь инструмент, который позволит описать любую найденную в продукте ошибку, разработчик должен, используя сведения, полученные от группы тестирования, исправить модуль, где найдена ошибка, а руководитель, в свою очередь, должен знать, во-первых, кто чем в данный момент занят, а во-вторых, какое количество ошибок и какого рода сопровождают ту или иную версию проекта.
Проблема до боли знакомая, и каждая компания решает ее по-своему, изобретая порой то, что уже есть и работает… Давайте посмотрим, что предлагает Rational.
ClearQuest - это средство управления запросами на изменение (Change Request Management - CRM), специально разработанное с учетом динамической и сложной структуры процесса разработки ПО. ClearQuest предназначен для отслеживания и управления любым типом действий, приводящим к изменениям в течение всего жизненного цикла продукта, помогая тем самым создавать качественное ПО более предсказуемым образом.
ClearQuest представляет собой многомодульное приложение, которое собственными средствами создает базу данных проекта и заносит в нее все изменения. Он поддерживает СУБД ведущих производителей, в частности Oracle, Microsoft и Sybase.
Смысл работы продукта прост и прозаичен. Основная информационная единица - дефект - это найденная ошибка в продукте или описание какой-то его особенности. Дефект заносится в систему пользователем, обнаружившим его. У каждого дефекта есть определенный набор состояний, по которым руководство может как отследить историю проекта, так и оценить текущее положение дел.
Состояний у дефектов всего пять. "Подан" (Submitted) - описание дефекта только что внесено; "Назначен" (Assigned) - описание передано определенному сотруднику. Начало работы над запросом переводит его в "Открытое" состояние (Open), и вся команда может видеть, что кто-то обрабатывает запрос.
Наконец, когда запрос проверен и закрыт, он проходит соответственно стадии "Проверка" (Verify) и "Закрыт" (Resolved). Состояния способны указать только на статус того или иного дефекта, а вот дотошно описать его помогут лишь специализированные поля. Любой дефект содержит определенное количество описательных полей, причем если использовать ClearQuest совместно со средствами тестирования, то при обнаружении ошибки данные продукты сами заполняют все необходимые поля. Чтобы вы не посчитали автозаполнение недостатком системы, скажу, что наряду с автозаполнением в ClearQuest предусмотрено и ручное внесение описания дефектов в систему, при котором вся ответственность за поданную информацию лежит на операторе. Итак, дефект получает идентификационный номер и набор описательных данных. Вот краткий список того, что можно передать в качестве описания к дефекту.
State - текущий статус дефекта (закрыт, открыт, в работе...). ID - идентификационный код дефекта. Воздействовать на это значение пользователь не может, поскольку система присваивает номер автоматически. Headline - комментарий к дефекту. В случае ручного ввода дается пользователем самостоятельно. При автоматической интеграции заполняется автоматически программой, обнаружившей дефект. RA - ассоциация с проектом (репозитарием). Необходима для ассоциации дефекта с требованием к системе. Priority - приоритет исправления дефекта. Этот параметр можно изменять по ходу проекта. Severity - критичность дефекта. То есть на первом этапе дефект можно определить как некритичный и исправить в последнюю очередь либо в последующей версии. Этот параметр также можно изменять по ходу проекта. Owner - владелец дефекта. Здесь следует отметить такую особенность: ClearQuest имеет два контрольных поля - Submitter и Owner. Причем первое поле содержит имя пользователя, который активизировал ошибку, а второе - имя пользователя, который должен эту ошибку исправить. Keyword - набор ключевых слов для данного дефекта. Специальный механизм, позволяющий конкретной компании вводить в обиход свой набор ошибок и приводить их в состояние ассоциативной связи с ошибкой в ClearQuest. Symptoms - признак дефекта (Cosmetic Flaw, Data Corruption, Data Loss, Slow Performance...
и т.д.). Заранее предопределенные типы. Description - описание проблемы, комментарий. Resolution - способ разрешения проблемы (fixed/nofixed). Attachment - сюда можно присоединить любой документ (скажем, код программы). History - история внесения изменений в дефекте. TestData - определенный набор сопроводительных документов. Заполняется либо вручную, либо автоматически средствами тестирования. Environment - среда сопровождения. Здесь можно определить тип операционной системы, тип процессора, при которых проявляется дефект. Requirements - здесь можно задать связь дефекта с требованием из RequisitePro. ClearCase - связь дефекта с конкретной версией файла. Данный модуль появляется только при правильной настройке ClearQuest и ClearCase (см. ниже).
ClearCase и ClearQuest
Данный набор продуктов позволяет разработчикам не просто исправлять определенные версии файлов, выводя их для этого в состояние Check-out, но и ассоциировать то или иное исправление в соответствии с теми дефектами, которые описаны в системе. Кажущийся сам по себе простым, данный механизм поможет извлечь из проекта всю информацию по ошибкам и изменениям, приведшим к их исправлению либо к порождению новых. Всю информацию можно извлечь подобно поднятию виноградной грозди за верхушку, рассматривая ее с разных сторон!
Здесь скрывается первый подводный камень - Rational предлагает для решения проблем с "change set" две методики: UCM (Unified Code Management) и ClearCase Base. О достоинствах каждой из них мы поговорим в одной из следующих статей, а сейчас остановимся только вот на чем: UCM предлагает универсальный подход и содержит в себе правила быстрого построения проектов установленного образца. UCM уже предопределил все роли и действия, а также осуществил интеграцию ClеarCase с ClearQuest. UCM - это попытка Rational осуществить унифицированный подход к тестированию. Но в погоне за универсальностью UCM потерял ряд важных черт, главная из которых - гибкая настройка под конкретный процесс. Тем не менее UCM развивается, улучшается, но для больших компаний со сложной инфраструктурой пока не совсем пригоден. Поэтому мы рассмотрим вариант интеграции ClearCase Base с уже сконфигурированной базой в ClearQuest.
Сначала проведем интеграцию, а потом поговорим о концепции.
"Внедрение" продуктов друг в друга - процесс двусторонний. Сначала ClearCase настраивается с помощью модуля ClearCase ClearQuest Integration. В появившемся окне необходимо указать, с каким VOB будет проведена интеграция и какие операции будут попадать в базу. Например, можно сделать так, что в базу будут попадать только действия check-out, связанные с ветвью DEBUG, и так далее (рис. 2).
Рисунок 2. Диалог интеграции ClearCase. Слева изображен список вобов, а в центре типы запросов. Здесь можно отметить, что интеграция со стороны ClearCase проходит на уровне инсталляции в VOB триггеров, вызывающих ClearQuest
То есть здесь мы настраиваем реакцию ClearCase на то или иное событие.
Соответствующим образом для каждого события будет вызываться список дефектов из ClearQuest, с которыми нужно проводить ассоциацию. Но этой настройки мало. Теперь схему ClearQuest необходимо "научить понимать" события ClearCase. Делается это следующим образом. Запускается ClearQuest Designer. Загружается схема, по которой была сгенерирована база данных. Через меню Package подключается интеграция с ClearCase. Схема сохраняется. Делается обновление базы. Теперь, как только пользователь даст команду CheckOUT, ClearCase не только попросит прокомментировать действия, но и предложит указать ассоциацию с определенным дефектом в базе ClearQuest. Значит, можно узнать, какие версии в ClearCase были порождены той или иной ошибкой. Ассоциативные связи могут быть двух типов: Один файл, несколько проассоциированных дефектов. Несколько дефектов на основе одного файла. Диалоговое окно, содержащее ассоциации, отображено на рис. 3. Итак, мы получаем следующий алгоритм разработки программного обеспечения: Разработчик создает работающий код. Тестировщик (или разработчик) обнаруживает ошибку: заносит описание ошибки (defect) в базу данных; вносит тип ошибки и ее критичность; назначает ответственного. Разработчик исправляет ошибку: отыскивает в базе модуль и дефект; выводит соответствующий файл в состояние CheckOut и ассоциирует его с одним или несколькими дефектами; исправляет ошибку и помечает ее как исправленную (fixed). Руководитель проекта получает полную статистику о наличии ошибок в проекте, степени их локализации и критичности.
ClearCase - система конфигурационного и версионного контроля
Обзорная статья
Новичков Александр
,
Более подробно о ClearCase:
Аннотация: Представлено описание предметной области SCM (Source Code Management), дано общее введение в продукт ClearCase. Рассмотрены основные функциональные возможности и области применения. Приведены рекомендации по использованию.
Александр Новичков
технический специалист
преподователь
Опубликовано в КомпьютерПресс 5'2001
http://www.interface.ru, http://www.compress.ru, http://www.cmcons.com
ClearQuest и средства тестирования
Как говорилось в одной из моих предыдущих статей (см. КомпьютерПресс № 2'2001 "Средства тестирования"), Rational имеет два типа средств тестирования: для разработчиков и тестировщиков. Хотя зависимость здесь не жесткая, да и роли участников конкретного проекта могут варьироваться.
Со всеми средствами ClearQuest начинает работать, как только создана база данных. Различия от продукта к продукту заключаются только в способе заполнения полей. ClearQuest вызывается автоматически, при нажатии правой клавиши на описании той или иной ошибки.
Здесь хочется обратить ваше внимание вот на что: ClearQuest не может сам в автоматическом режиме занести все ошибки, обнаруженные средствами тестирования, - этим должен заниматься человек. Иными словами, разработчик может вносить, а может и не вносить описание дефекта. Обычно предполагается, что разработчик должен только исправлять ошибки и неточности, на которые ему указывают тестировщики. Естественно, с этим можно поспорить, но продукт позволит применить любой подход. За вами - выбор, соответствующий традициям, сложившимся в вашей компании.
Как уже говорилось выше, средства тестирования сами способны заполнить сопроводительные поля. Если такое средство, как Rational Purify, способно дать лишь заголовок ошибки, то Rational Robot может уже заполнять поля согласно тому, какой скрипт в какой версии нашел ту или иную ошибку. Тестировщику для получения полной картины тестирования останется только задокументировать тип процессора, тип системы и описать, с какими из сторонних программных средств проводилось совместное тестирование. Само собой разумеется, что все проблемы по хранению таких данных возьмет на себя ClearQuest.
Построить же график по ошибкам или сделать выборку по определенным операционным системам способен любой, кто хоть раз работал с базами данных.
Итак, тестировщики получают инструмент архивации сведений обо всех дефектах, способный провести анализ информации по заданным критериям.
Дополнительная информация
Средства тестирования Rational (VisualTest, Purify, PureCoverage, Quantify)
Адрес ()
|
Дополнительные возможности
Компания Rational посредством RUP регламентирует все этапы разработки программного обеспечения, объединяющего в себе все знания и опыт. Для каждого из приведенных в RUP этапов компанией Rational создано специальное програмное обеспечение, в частности ClearCase. Расширив его за счет некоторых программных продуктов или дополнительных модулей, можно получить некоторые дополнительные возможности.
Рассмотрим продукты и модули, которые можно использовать совместно с ClearCase. MultiSite - специальный модуль, позволяющий вести разработку между регионально удаленными группами разработчиков. Работа производится посредством передачи (репликации) текущего состояния проекта на указанный сайт (через Интернет). Обмен данными может осуществляться между двумя и более сайтами. Синхронизация проекта при использовании MultiSite осуществляется вручную или автоматически - на усмотрение администратора проекта. Важным преимуществом модуля является возможность реплицирования проекта не только на указанный IP-адрес, но и в простой файл, который также можно перенести на любую машину любым традиционным способом. SoDA - cистема генерации проектной документации. Данное средство генерирует определенный набор шаблонов, выбирая все нужные данные из VOB или из отдельных файлов. Оно встраивается в Word, где создает шаблон, основанный на определенных данных. Использование SoDA значительно упрощает ведение проектной документации, предоставляя техническому писателю или менеджеру проекта все необходимые данные в стандартном виде на основе выбранного шаблона, после чего остается только дополнить нужными комментариями сгенерированный документ (рис. 6).
Рис. 6.
ClearQuest - позволит создать специальную базу данных, куда будут вноситься все изменения, внесенные в проект за указанный промежуток времени. Система настраиваемых триггеров - одна из наиболее мощных возможностей ClearCase - позволяет настраивать (достраивать) продукт под соответствующие нужды пользователей. ClearCase имеет таблицу событий, в которые можно встраивать триггеры. В простом варианте можно заставить ClearCase отправить письмо менеджеру проекта, если кто-либо из разработчиков удалил из состава проекта свой файл либо внес новый. Для полноценной работы триггеров также предусмотрены переменные окружения, в которых можно почерпнуть сведения о состоянии как отдельного, так и группы элементов.
Компания Rational посредством RUP регламентирует все этапы разработки программного обеспечения, воплощая в себе все знания и опыт. Для каждого, из приведенных в RUP этапов, той же Rational создано специальное ПО - в частности ClearCase. Дополнив его еще некоторыми программными продуктами или дополнительными модулями, можно открыть абсолютно новые возможности.
Рассмотрим продукты и модули, которые можно использовать совместно с ClearCase:
MultiSite. Специальный модуль, позволяющий вести разработку между регионально удаленными группами разработчиков. Работа производится посредством передачи (репликации) текущего состояния проекта на указанный сайт (через Интернет). Обмен данными может осуществляться как между двумя сайтами, так и между любым количеством. Синхронизация проекта при использовании MultiSite осуществляется как вручную так и автоматически - по усмотрению администратора. Важным преимуществом модуля является возможность реплицирования проекта не только на указанный IP-адрес, но и в простой файл, который также можно перенести на любую машину любым традиционным способом.
SoDA. Система автоматизирования генерации проектной документации. Данная программа генерирует определенный набор шаблонов, выбирая все нужные данные из VOB или из отдельных файлов. Программа встраивается в Word, где создает шаблон, основанный на определенных данных. Использования программы значительно упрощает ведение проектной документации, давая техническому писателю или менеджеру проекта все необходимые данные в стандартном виде на основе выбранного шаблона. Пользователю останется только дополнить нужными комментариями сгенерированный документ.
ClearQuest. Позволит создать специальную базу данных, куда будут вноситься все изменения, которые были внесены в проект за указанный промежуток времени.
Отличительные черты ClearCase
Высокопроизводительное средство клиент-сервер масштаба предприятия Ведет полный учет всего относящегося к проекту Создает дерево версий для каждого элемента проекта Позволяет проводить параллельную работу над одним файлом нескольким участникам команды Позволяет каждому участнику проекта настраивать собственное рабочее пространство и видимый круг подконтрольных элементов Позволяет разработчику на время выходить из общего русла проекта При наличии MultiSite объединяет регионально удаленные команды разработчиков Хранит весь проект включая: исходные файлы, двоичные файлы, библиотеки, документацию, WEB приложения, модели и директории Имеет WEB интерфейс для удаленного доступа Конвертирует данные из PVCS в собственный формат Имеет дружественный интерфейс
Purfy
Исследуем поверхность и интегрируемся с VC++
Начать описание возможностей продукта Rational Purify хочется перефразированием одного очень известного изречения: "с точностью до миллиБАЙТА". И это не случайно, ведь именно на решение всех проблем, связанных с утечкой памяти и предназначен данный продукт.
Ни для кого не секрет, что многие приложения ведут себя "не слишком скромно", замыкая во время работы все системные ресурсы без большой на то необходимости. Данной болезни подвержены в основном крупные программные пакеты, и возникает подобная ситуация по причине нежелания программистов доводить созданный код "до ума", но чаще подобное происходит не из за лени, а из-за невнимательности. Это понятно - современные темпы разработки ПО в условиях жесточайшего прессинга со стороны конкурентов не позволяют уделять слишком много времени оптимизации кода, ведь для этого необходимы и высокая квалификация, и наличие достаточного количества проектного времени. Как правило квалификация есть, а вот времени и денег на детальное тестирование кода на наличие "глюков" и "багов" практически нет. И в большинстве случаев, идя на поводу у клиентов крупные компании выпускают сырой код и тут же принимаются "латать" его различными патчами:
Еще раз попробую повторить, что львиная доля всех ошибок приходится на неправильное распределение/использование памяти, а также несанкционированный доступ за границы собственного адресного пространства, для программистов на С/С++ дополнительная головная боль - это указатель - еще одна брешь в системе.
Так вот, как мне видится, имея в своем распоряжении надежный инструмент, который бы сам в процессе работы над проектом указывал бы на подобные ошибки, то разработчики начали бы его повсеместное внедрение, повысив надежность создаваемого ПО, поскольку, как известно, что проще ошибку не допустить, чем потом с гордостью исправлять.
В общих чертах работа Rational Purify сводится к детальному выводу статистики об использовании памяти приложением (список ошибок и примеры устранения во второй главке).
Получаемой статистики вполне достаточно для получения общей, а затем - и детальной информации обо всем, что имеет отношение к памяти: утечки, потерянные блоки, фиктивные ссылки.
Purify позволяет анализировать исполняемый модуль, содержащий отладочную информацию, либо работать на уровне исходников, но только в среде Visual Studio (C++, Basic, Java).
Работа программы начинается со сбора информации о загружаемых библиотеках.
То есть программа отыскивает ошибки не только внутренние но и внешние, разумеется, нельзя исправить ошибку в системной DLL, но если она там есть, то наверняка, можно написать дополнительный код в своей процедуре, отказавшись от вызова "некачественной" функции из DLL. Перво-наперво идет детальное инструментирование всех модулей. Инструментирование сводится к тому, что Purify вставляет свою отладочную информацию в тело программы и вызываемых библиотек (технология Object Code Insertion). Для эффективной работы все "пройденные" библиотеки хранятся в кеше, что позволяет сократить необходимое время не перезапуск исправленного приложения. Давайте рассмотрим возможности Purify в плане совместной работы с Microsoft Visual C++. Интеграция компонентов от Rational выражается в появлении новых инструментальных панелей на поверхности рабочего стола в Development Studio. Получив полный набор тестирующих и профилирующих средств, разработчик обращается к ним по мере необходимости, не покидая рабочего пространства, что позволяет сэкономить массу времени на различные вызовы сторонних программ. Рисунок 1 показывает примерный вид инструментальных панелей в Visual Studio, появляющихся после инсталляции Purify, Quantify, PureCoverage.
(вставить сюда из файла INTEGRATION.tif)
А учитывая давнюю дружбу Rational и Microsoft, становится понятно, почему поддерживаются в полной мере только среды разработчиков от MS. Собрав воедино всю перечисленную информацию, давайте попробуем на конкретном примере в Visual C++, создать приложение, внести в него ряд намеренных ошибок после чего, используя Purify попытаться отыскать их. Опустим за скобки то, каким образом создаются проекты в Visual Studio и из чего они состоят - это не самоцель. Исходим из того, что читатель уже работал с данной средой, или хотя бы знаком с ней - это - во-первых. Во-вторых, для чистоты эксперимента мы воспользуемся стандартным "Волшебником" из состава Visual Studio, сгенерировав, на его основе проект, в который внесем некоторый код, который будет неадекватно себя вести с памятью системы: Итак, у меня получилось 32-разрядное приложение для Windows с именем "PROJECTOID".
На рисунке 2 изображен скриншот окна Workspace после создания проекта. Для демонстрации преимуществ Purify не нужно заводить в примере тонны сложных классов, запутывая и себя, и программу, и статью: ограничимся лишь простыми вызовами на распределение памяти.
К приятной неожиданности можно отнести фразу "Memory leak of 60000", указывающую на то, сколько фактических байтов памяти программа не вернула системе, по завершении своей работы. Эта черта разительно отличает подходы к тестированию программы Rational Purify от подобных продуктов конкурирующих компаний, которые высчитывают не фактические утечки (полученные в результате нескольких вызовов при реальной работе приложения, а количество невозвращенных блоков, то есть ограничиваются лишь анализом (на уровне исходных текстов) программы с выявлением вызовов функций аллокирования памяти без последующего освобождения. Из этого и следует полученное число 60000 - фактически не освобожденных блоков (3 по 20000). После добавления функции free(alex) в конец обработчика OnAppAbout и перекомпиляции тестируемого приложения, Purify не обнаруживает никаких ошибок памяти, что и являлось нашей целью. Рисунок 4 отображает окно c ошибкой, в котором Purify, подсветила конкретный фрагмент текста листинга.
Purfy
Тонкие моменты
Из предыдущей главы нам стало известно, что Rational Purify направлена на поиск ошибок в программах написанных на Visual Studio. Мы также знаем, что продукт способен проанализировать эффективность кода программы, как с использованием исходных кодов, так и без них.
К достоинствам программы можно отнести не только вышесказанное. Purify способна работать (запускаться) на трех уровнях: из среды интеграции (Visual Studio), как отдельная программа и наконец из командной строки (если при инсталляции ей разрешили "прописаться" в путях). Любой разработчик, пишущий визуальные изощрения под "Окна", может отказаться от интерфейса командной строки за ненадобностью. И совершенно напрасно! Как известно корни доброй половины продуктов Rational уходят своими корнями в разные UNIX системы, для которых командная строка - вещь святая, и графическими средствами незаменяемая. Соответственно, все особенности продуктов перекочевали под Windows: где и прижились: в лучшей или худшей степени.
Давайте обратим наше внимание именно на командную строку и попробуем разобраться как и для чего она нужна в повседневной разработке. Из материала прошлой статьи известно, что для своей работы средства тестирования Rational используют патентованную (читай: засекреченную) технологию под названием OCI - Object Code Insertion. Соответственно, суть метода тестирования состоит в том, что в исполняемый код записываются специальные инструкции Purify. Здесь хочется еще раз акцентировать внимание на том, что код вставляется не только в пользовательский модуль, но и во все внешние библиотеки, что дает разработчику уникальную возможность по отладке программ, предоставляя полную статистику по всем модулям. А это позволит вовремя заменить/переписать/переделать некорректную DLL, а не ждать пока она сведет на "нет" все усилия по вылавливанию внутренних ошибок. К вопросу о скорости работы: код вставляется относительно долго, зато создается директория с кешем - DLL со вставленным OCI.
Так что, каждый новый запуск проходит быстрее предыдущего. Процесс записи объектного кода в приложения на языке Purify называется "инструментированием", соответственно подобная операция выполняется каждый раз перед исполнением написанного приложения. Если это касается совместной работы с пакетами из VS, то дело происходит так: сначала приложение компилируется (обычным способом, без вставки OCI), затем, после подачи команды "RUN" - запускается Purify и начинается процесс вставки кода. Только по его завершению, приложение начнет исполняться. Из самого же Purify дело обстоит еще проще: необходимо просто выбрать нужный EXE'шник. Естественно, и в том и в другом случае приложению (при необходимости) можно передать аргументы командной строки и настроить фильтры сообщений (об этом чуть ниже). Полное же управление над процессом инструментирования можно получить из командной строки. Здесь есть некоторые возможности, отсутствующие в версиях GUI. Например:
Инструментирование как самого файла приложения, так и его копии (последняя создается автоматически) Только вставка кода без запуска приложения Запись кеша в указанную директорию И многое другое: всего 38 ключей
Тестирование сервисов Windows NT
Конечно же командная строка во многом дублирует функции графической оболочки, что делает не совсем очевидным применения именно данной возможности. Для решения следующего примера нам нужно воспользоваться командной строкой поскольку, тестируемое приложение является сервисом Windows NT, который, разумеется, нельзя исполнить как простое приложение. В этом случае как нельзя кстати приходится функция записи OCI без исполнения файла, что позволит внести в него весь объектный код, а затем прописать данный сервис в реестре. Соответственно, при старте сервиса у вас появится возможность получения информации о работоспособности сервиса. Рецепт тестирования выглядит следующим образом:
1) Правильно настроить системные пути таким образом, чтобы из них были видны все директории Purify (особенно кеш: \Program Files\Rational\Purify), иначе процесс не пойдет на исполнение. 2) Откомпилированный сервис нужно запустить Purify из командной строки следующим образом: purify /Run=no /Out=service_pure.exe service.exe.Как видно из параметров, Purify инструментирует файл service.exe, помещая его копию вместе с OCI в service_pure.exe. Все происходит без запуска. 3) В ключе реестра \HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services необходимо поставить ссылку на кешированный файл (service_pure.exe) 4) Во вкладке сервисов активировать пункт Allow Service to Interact with Desktop, выбрать режим запуска "manual"
Далее - как обычно: после перезагрузки загрузить Purify и стартовать сервис. Программа подхватит его и начнет тестировать как это было бы при работе обычного приложения. Помимо системных сервисов, Rational Purify способна работать совместно с:
Компонентами Active X Дочерними процессами Совместно написанными программами (Visual С++ & Visual Basic) COM серверами (in-proc и out-proc) Internet Information Server
Интеграция
ClearCase относится к той группе инструментов, которые при очень богатых собственных возможностях, все же неспособны полностью раскрыть собственные функциональные возможности без интеграции со средствами разработки. ClearCase позволяет интегрироваться с таким популярным средством разработки как Visual Studio.
При совместном использовании двух продуктов появляется дополнительная возможность по управлению версиями не выходя из среды разработки. ClearCase встраивается в рабочее пространство VisualStudio, дополняя своими функциями меню программы.
Таким же образом интеграция происходит с Microsoft Word и Microsoft Front Page. В последних двух случаях появляется возможность слияния не только текстовых файлов, но и файлов с расширением DOC, XML, HTML.
В этих пакетах встраивание выглядит также как и в Visual Studio - все функции контроля версий доступны через верхнее меню.
Интеграция со средствами разработки
ClearCase относится к той группе инструментов, которые при своих весьма широких функциональных возможностях все же неспособны полностью раскрыть их без интеграции со средствами разработки. ClearCase может быть совместно использован с таким популярным средством разработки, как .
Совместное использование этих двух продуктов обеспечивает дополнительную возможность управления версиями непосредственно из среды разработки. ClearCase встраивается в рабочее пространство VisualStudio, дополняя своими функциями меню программы.
Таким же образом интеграция происходит с Microsoft Word и Microsoft Front Page. В последних двух случаях появляется возможность слияния не только текстовых файлов, но и файлов с расширением DOC, XML, HTML.
В этих пакетах встраивание выглядит так же, как и в Visual Studio, - все функции контроля версий доступны через их главное меню.
На чем основана программа
Для реализации полного контроля над версиями в специальную базу данных - VOB (Version Object Base) - заносятся все изменения данных проекта.
Репозитарии, хранящие всю промежуточную информацию о состоянии проекта, могут находиться в локальной сети как на одном компьютере, так и раздельно. Физически VOB представляет собой некую файловую структуру, закодированную особым образом. Основой VOB являются элементы, представляющие собой файлы или каталоги. Элемент должен и может иметь одну или несколько версий.
Все элементы VOB имеют свою уникальную версию. При создании VOB получает определенный набор характеристик, на основании которых в дальнейшем можно определить (при наличии соответствующих полномочий) историю его создания. Над VOB можно осуществлять операции монтирования/демонтирования, создания/удаления. Для работы с конкретным репозитарием каждый участник монтирует его на своем компьютере.
Создания одной только базы данных для полноценной работы в ClearCase недостаточно, необходим также клиент для доступа к ней. Для всех манипуляций над базой данных, в соответствии с правами пользователей, применяется механизм настраиваемых видов (VIEW), являющийся технологическим средством фильтрации находящейся в VOB информации и преобразующий все подмножество элементов со своими версиями в вид, понятный не только машине, но и человеку. Такой подход позволяет разработчику или техническому писателю видеть не все файлы, составляющие проект, а только необходимые для решения конкретной задачи. Таким образом, ClearCase позволяет достаточно легко абстрагироваться от текущего состояния и сосредоточиться на определенной части проекта.
Исключительно через систему видов возможны все операции, присущие не только ClearCase, но и любому другому средству версионного и конфигурационного контроля, такие как установка контроля файла (Add To Source Control), при котором для каждого элемента создается дерево версий, операции Check-in и Check-Out, позволяющие редактировать отдельный файл, создавая дерево версий, на котором отражена полная история развития отдельного элемента (рис. 5).
Рис. 5.
История редактирования файла.
Помимо этого ClearCase обеспечивает менеджеров проекта и разработчиков специальным модулем отчетности, с помощью которого можно получать справочную информацию об истории редактирования того или иного элемента в отдельности или группы элементов. Отчет может быть экспортирован в Microsoft Word (посредством инструмента ), выведен на экран или опубликован в Интернете. Виды в программе представлены двумя типами - Dynamic и Snapshot, имеющими свои достоинства и недостатки, но при совместном использовании способными открыть новые возможности в контроле над файлами. Специфика вида Dynamic заключается в том, что данный вид (Windows NT, UNIX) создает виртуальную файловую систему, на которой размещаются все подконтрольные данные. Сама файловая система размещается также на виртуальном диске, физически размещенном на сервере. Для конечного пользователя в этом случае работа с таким видом сведется к работе с новым сетевым диском. Данный способ позволяет осуществлять контроль над файлами в реальном масштабе времени. Основные преимущества данного способа представлены перенастраиваемыми видами. Эффективность использования особенно ярко проявляется Dynamic View в случаях, когда менеджерам необходимо одновременно контролировать несколько проектов, либо для настройки конфигураций, когда необходимо поддерживать одинаковые версии исходных файлов для разных операционных систем. Вид типа Snapshot оправдывает свое название, создавая "снимок" текущего состояния проекта на локальной машине. Разработчик получает на своем диске точную копию либо всего проекта, либо необходимой его части - файла, группы файлов: Важным моментом при такой работе является синхронизация локальных данных с общим проектом, которая в данном случае выполняется не автоматически, а по команде пользователя. Это делает возможной удаленную работу над проектом, позволяя любому разработчику взять материал "на дом", после чего вернуть новые версии файлов в проект. Имея мощный набор инструментов, настраивающих вид, можно добиться поразительных эффектов, недоступных для других программ версионного контроля.
Неоценимой является возможность параллельной разработки, когда программа допускает правку одного и того же файла несколькими разработчиками, создавая ответвление на дереве версий (одно или несколько - в зависимости от числа разработчиков, использующих данный файл). Как уже говорилось ранее, для каждого файла создается дерево версий. Дерево состоит из корня и версионных ответвлений. Здесь следует отметить две разновидности ответвлений: простое ответвление (Branch), создаваемое для отдельного файла и в любых количествах, и главное ответвление (Private Branch) - для всего проекта, когда создается новая ветвь (может быть только одна) для всех файлов, составляющих проект. Для объединения версий в ClearCase предусмотрена специальная утилита - MergeManager - менеджер слияний, который под контролем менеджера проекта собирает из двух предоставленных файлов один. Сборка осуществляется либо автоматически (тривиальная сборка), когда различия между файлами невелики, либо по выбранной менеджером проекта строке кода для слияния (нетривиальная сборка). По окончании слияния создается новая версия, которую далее также можно править, объединять с другими версиями, делать ответвления. Слияние файлов можно производить как из ClearCase, так и из командной строки. Допускается слияние только текстовых файлов. Из важных возможностей ClearCase следует также отметить создание видов на базе профилей, что может слегка усложнить и дерево версий, и понимание самой программы, зато позволяет особым образом настраивать систему видов для каждого участника проекта в отдельности: для разработчиков настройки могут быть одними, для сотрудников, ответственных за тестирование, - другими. Программа обладает развитым интерфейсом и полностью использует возможности современных операционных систем. Для обеспечения максимальной производительности ClearCase (помимо графического интерфейса) имеет широкий набор команд для работы из командной строки. Особо хочется отметить возможность сборки проекта. При помощи утилиты OMake возможна сборка проекта в исполняемый модуль.Утилита работает из командной строки и не зависит от типа используемого компилятора, главное - чтобы его можно было вызвать из командной строки. При этом сценарий сборки базируется на обычных make-файлах.
Начинаем работать с ClearQuest
Здесь мы опишем механизм, при помощи которого можно "заставить" работать ClearQuest. Естественно, что подробное описание выходит за рамки данной статьи, но попробуем сделать это кратко. Итак, наиболее простой способ подготовить проектную основу и сконфигурировать ее - использовать Rational Administartor, позволяющий посредством нескольких шагов мастера полностью подготовить проект. Здесь воедино связываются метаданные для тестирования, а также требования к системе, по которым потом тестировщики создадут низкоуровневый план тестирования, сгенерируют скрипт тестирования, базу ClearQuest и присоединят модель из Rational Rose.
На этапе создания базы необходимо указать тип формата базы данных и местоположение генерируемого файла (для примеров я использовал MS Access), а также тип схемы, по которой она будет строиться. Число доступных схем - примерно 7-8, но может варьироваться вместе с новыми версиями продукта. Из основных схем хочется отметить Enterprise и DefectTracing. Первая предусматривает набор правил, по которым схема будет работать со всеми продуктами, так или иначе описанными в RUP. Вторая предназначена только для использования возможностей документирования дефектов. Мы выбираем схему Enterprise, задаем логическое имя базы. На последнем шаге создаем пользователей и группы, а также описываем права доступа.
Теперь необходимо запустить ClearQuest и провести еще ряд действий, создать запрос Query (правила создания запросов одинаковы для всех баз данных, и здесь мы их не рассматриваем) и наконец, попытаться зарегистрировать дефект.
Мы выполнили только основные шаги по получению базы данных. Но их достаточно, чтобы создать работающий CRM.
Некоторые особенности ClearCase
Многое из вышеоописанного, возможно, уже знакомо читателям, применявшим сходные средства контроля и управления.
Хочется еще раз отметить особенность использования ClearCase в Windows NT: этот продукт обладает мощным графическим пользовательским интерфейсом и мощным интерфейсом командной строки. Соответственно каждая операция может быть выполнена двумя различными способами. Командная строка позволяет подстраивать продукт под конкретные нужды конкретной компании. Без помощи командной строки достаточно сложно произвести некоторые тонкие настройки, имеющие отношение к работе с данными.
Каждая операция, производимая над данными, предварительно описывается как значимая и неделимая. Набор таких описаний и правил носит название Configuration Management и является частью методологии RUP.
Configuration Management полностью регламентирует, что, как и кем должно делаться в проекте и как использовать для этих целей ClearCase. Согласитесь, мало иметь инструмент, нужно уметь им пользоваться.
Попытаемся рассмотреть (схематично), каким образом ClearCase позволяет контролировать проект. Для этого обратимся к настройке видов и осуществим слияние версий.
Описание возможностей
Рекомендованный как средство контроля версий при коллективной разработке проекта, ClearCase превосходно справляется с возложенной на него задачей. Являясь, по сути, масштабируемым приложением в архитектуре "клиент/сервер", ClearCase хранит всю возможную информацию, относящуюся к проекту, и позволяет получать последние версии редактируемых и архивных файлов (рис. 1).
Рис 1. Главное окно ClearCase. Одно из неоспоримых достоинств ClearCase - гибкость в настройке. Обратите внимание на русифицированные пункты меню - они созданы исключительно при помощи стандартных возможностей продукта.
С помощью уникального инвариантного подхода в этом продукте реализовано полное управление исходным текстом, включая контроль над версиями, управление рабочим пространством, конфигурацией среды и разрабатываемого ПО. Посредством ClearCase команда разработчиков совместно с руководителями подразделений и техническими писателями может сократить время поиска и анализа информации. Этот продукт позволяет убедиться в точности окончательных версий продукта, дорабатывать и поддерживать ранее реализованные продукты, организовывать эффективный процесс разработки - и все это без изменения среды, инструментальных средств и подхода к работе. Он обеспечивает управление версиями исходных текстов и библиотек на протяжении всего жизненного цикла проекта, позволяя разработчику вернуться к любой версии редактируемого файла и откорректировать его заново, создав новую версию.
Не секрет, что для многих компаний, выпускающих продукты для разных платформ, поддержание необходимого количества файлов для каждой платформы представляет серьезную проблему. Она усугубляется еще и необходимостью поддержки нескольких версий одного и того же продукта. В таких условиях любой существующий подход ведет к большим трудозатратам, существенно снижая производительность труда всего коллектива, поскольку большую часть времени в этом случае "съедают" различные согласования, отчеты, поиски нужных версий. Единственный правильный выход из сложившейся ситуации - это внедрение средства версионного и конфигурационного управления, способного разрешить данную проблему.
Имея в своем распоряжении ClearCase, каждый участник проекта получает доступ как ко всем файлам проекта, так и к определенной его части.
Проблема необходимости данного подхода вызывает столько же споров, что и вопрос множественного наследования в ООП. Конечно, общего рецепта не существует; в одних случаях такой подход оправдан, в других - нет. Однако на случай такой необходимости возможность ее реализации в ClearCase уже предусмотрена. Кроме того, ClearCase позволяет объединять географически удаленные команды разработчиков посредством дополнительного модуля MultiSite, осуществляющего репликацию (передачу) текущего состояния проекта на указанный сайт. То есть если команда очень разбросана географически, то MultiSite позволит синхронизировать проект через Интернет для всех команд разработчиков. В условиях бурно развивающейся и подверженной изменениям IT-индустрии становится все сложнее давать оценку программному продукту как чему-то независимому, вырванному из общего контекста разработки. Поэтому во внимание принимается степень поддержки данного продукта компаниями, создающими средства разработки. Так, продукт версионного контроля не может быть функционально полным без определенных механизмов интеграции со средствами разработки, с различными дополнительными генераторами отчетов и пр. (рис. 4).
Особенности создания видов
Итак, если вспомнить базовые возможности ClearCase в области хранения информации, то получается, что мы должны создать репозитарий (VOB), создать вид (один или несколько), затем любым известным способом копировать/сохранять файлы и директории на диск, созданный ClearCase, и установить за ними контроль (рис. 9).
Рис. 9. Здесь показан вид файла Alex.cpp, выведенного в состояние Check-Out. Скриншот сделан из текущего вида.
Здесь кроется определенная проблема: как организовать при этом совместный доступ к одному файлу и как будут поддерживаться разные версии и разные проекты? Это не праздные вопросы! Давайте посмотрим, что имеется в арсенале ClearCase для решения данных проблем. Но прежде хочу еще раз напомнить очень важный момент: ClearCase имеет свою особенную идеологию работы, которая не всегда понятна с первого взгляда, поскольку требует некоторого осмысления. Поэтому следует воздержаться от попыток "подмять" его под свои нужды. Скорее всего, это не получится, так как для получения наибольшей эффективности проще будет перестроить существующий подход - на тот, что предлагает ClearCase.
По умолчанию ClearCase создает простой вид и назначает ему букву (если это касается динамических видов). При этом если в проекте несколько участников, работающих в локальной сети, то каждый из них, создав подобный вид, будет "смотреть" на одну и ту же часть проекта, как если бы все имели один сетевой диск (рис. 10).
Рис. 10. Здесь показан вид файла , с другого компьютера.
Следует иметь в виду, что ClearCase имеет особую файловую систему - MVFS (MultiVersion File System), которая позволяет получать доступ к версии конкретного файла и производить его правку. Здесь необходимо учитывать, что при простом обращении к нужному файлу ClearCase предоставляет последнюю версию либо версию, находящуюся в состоянии Check-out (для разработчика, который взял файл на редактирование, ClearCase будет подставлять версию Check-out, для всех остальных участников - последнюю; рис. 9, рис. 10, рис. 11 и рис. 12 соответственно).
Рис 11.
Так выглядит дерево версий для файла в текущем виде.
Так происходит подстановка в виде файла с нужной версией в качестве файла по умолчанию. Необходимость правки данного правила появляется, когда команде разработчиков требуется воспользоваться главным преимуществом ClearCase - параллельной разработкой, при которой каждый участник может создать свое ответвление на дереве версий и дорабатывать файл независимо от состояния проекта, чтобы в итоге объединить свою версию с основной. Менеджеру проекта также доступны преимущества параллельной разработки: во-первых, можно вести одновременно две версии различающихся файлов - с целью дальнейшего включения в другой проект, а во-вторых, по технологии Rational, решение о том, какие файлы с какими объединять, в итоге принимает не разработчик, а именно менеджер проекта. В ClearCase есть две возможности изменения существующих правил: ручная правка (при этом требуется знание синтаксиса правил), автоматическая правка (построение профилей и видов на их основе либо ассоциация видов с соответствующими профилями). Рассмотрим сначала построение видов на базе профилей. Профили можно создавать сразу после инсталляции ClearCase в отдельно отведенный каталог, открытый для общего доступа. Здесь кроется основная проблема начинающих пользователей! ClearCase сам не создает каталоги и не настраивает свой доступ к ним - это приходится делать вручную. Путь к созданному каталогу (абсолютно пустому) прописывается на вкладке "Администрирование", как показано на рис. 14.
В результате операции будет создан новый вид (новый диск), в котором отсутствуют файлы проекта. Отсутствие это временное, поскольку создание вида по профилю подразумевает слияние одного или нескольких файлов из предыдущего вида в текущий. Иными словами, для параллельной разработки можно брать не весь проект, а только указанные его части (файлы, директории). Разумеется, все изменения будут отражены на дереве версий. Здесь необходимо акцентировать внимание на том, что методом профилей можно организовать не только параллельную разработку, но и разбивку проекта на несколько частей. Например, одна часть проекта - DEVELOPMENT - доступна всем и отображает все версии всех файлов, но с текущей версией только на ветви MAIN, а вторая часть - RELEASE - содержит только те файлы, которые подлежат компиляции. И наконец, DEBUG - часть, содержащая отладочные версии файлов. Все эти ветви можно сделать при помощи профилей либо с помощью ручной правки правил (рис. 16).
Так можно сравнить, а затем и объединить два каталога. Обратите внимание на красную стрелку и синие полосы - это отсутствующий файл, требующий объединения. Здесь необходимо помнить, что каталог также является элементом и ему присваивается новый номер версии каждый раз, когда в состав проекта вносится новый файл или подкаталог.
Нам требуется создать отдельный диск и поместить в него для сборки только работающие версии файлов. На основе правил проблема решается очень быстро! В процессе редактирования файлов каждый разработчик отмечал на дереве версий ту, которая считалась окончательной версией с соответствующим номером "REL1", "REL2", "REL3" и т.д. Для этого в ClearCase предусмотрен еще один механизм - механизм меток - простых, обыкновенных меток, знакомых всем с первых шагов в программировании. Разработчик вместе с менеджером проекта выбирают одну из версий на дереве и присваивают ей имя. В дальнейшем данная метка становится синонимом конкретной версии конкретного файла, то есть одну и ту же метку необходимо назначать разным файлам и разным подверсиям. В итоге мы можем по меткам собрать требующуюся нам окончательную версию (релиз) файла. Отметим, что ClearCase обладает очень хорошим механизмом защиты от удаления меток: удалить метку может только тот, кто ее создал, либо администратор. Подкорректировать вышеприведенное стандартное правило для того, чтобы ClearCase показывал только все версии с меткой , можно так, как это произведено на рис. 19.
Проблемы
C развитием аппаратной базы компьютерных систем - увеличением тактовой частоты до запредельных уровней (переваливших за гигагерц), ускорением обработки изображений в реальном масштабе времени при помощи супермощных видеоадаптеров многие разработчики не считают нужным (или возможным) оптимизировать написанные ими программные продукты, перенося весь неоптимизированный код на быструю подсистему, быстрый процессор, "умный" компилятор. Результат подобного злоупотребления мы наблюдаем ежедневно во время запуска программ на собственных компьютерах, отмечая странную тенденцию: чем новее программа, тем больше требует ресурсов, и тем медленнее работает. Но и это еще не все! Многие программы по окончании работы не освобождают все занимаемые ресурсы, что приводит к достаточно неприятным последствиям. Странно, не правда ли? Казалось бы, технологии программирования должны совершенствоваться и идти в ногу с аппаратными новинками, качественно используя все предоставляемые ими возможности, однако на деле все обстоит гораздо хуже. В погоне за новыми цифрами версий на коробках продуктов разработчики не считают нужным (возможным) проводить детальную оптимизацию написанного кода, тщательно отслеживая все вызовы и подсчитывая занимаемую системную память, поскольку занятие это трудоемкое и длительное, а получаемый результат не всегда оправдывает надежды: времени потрачено много, сил - еще больше, а производительность конечного продукта повысилась в лучшем случае на 9%, а то и меньше. Согласитесь, ситуация для нашего времени достаточно типичная, причем типична она для всех софтверных компаний, вне зависимости от ранга, размера, и, что немаловажно, от географического расположения. Лозунг: "время - деньги", применяемый всеми к месту и не к месту, в данной ситуации дает явный сбой! Получается количество версий - в ущерб качеству.
За примером далеко ходить не придется: у всех есть нерасторопные операционные системы и офисные пакеты, которые с каждой новой реализации повышают аппаратные требования, функционально оставаясь при этом на уровне 95 года.
Неужели все так страшно и бесперспективно? И "да" и "нет".
Все крупные компании, связанные с разработкой программного обеспечения, пытаются найти способы наиболее эффективного тестирования, не выходя при этом за рамки бюджета конкретной разработки. Но, к сожалению, то ли ищут не там, то ли применяют не то, поскольку оптимизированных продуктов на рынке не так много. Разработка качественных продуктов в отведенные сроки - вот задача, на решения которой направлены все продукты компании Rational. В частности, для этапа разработки высококачественного кода, компания, посредством RUP (Rational Unified Process - методологии разработки), компанией рекомендуется использование инструментов тестирования: Quantify, Purify, PureCoverage. Именно методике использования вышеперечисленных продуктов и посвящена данная статья - ведь их разумное применение позволит группам разработчиков найти и своевременно устранить узкие места в производительности создаваемого программного обеспечения.
- собирает полную статистику о количестве вызвов функций в тестируемой программе, позволяя тем самым узнавать временные характеристики отдельных частей приложения - отлавливает все ошибки, связанные с утечкой памяти - позволит быстро найти участки кода, пропущенные при тестировании
>>
PureCoerage
Все хорошее рано или поздно кончается. Хотя, исходя из личного опыта и опыта знакомых - все самое хорошее заканчивается гораздо раньше, чем того хотелось. Вот так и с продуктами тестирования, рассматриваемыми в данной статье: мы сначала уделили достаточно много сил и времени продукту Quantify, для получения представления о нем и о принципах тестирования по Rational'овски, затем углубились в область тестирования утечек памяти, поговорив о Purify в контексте интеграции с Development Studio.
Теперь настало время поговорить еще об одном продукте - Rational Pure Coverage, завершающим вереницу инструментов по тестированию. Он позволит разработчикам довести собственные программы до состояния абсолютной эффективности (божественной нирваны), освободив от ошибок и странностей.
Основное и единственное назначение продукта - выявление участков кода, пропущенного при тестировании приложения. Вполне очевидно, что при тестировании программы специалисту не удается оттестировать абсолютно все ее функции. Это невозможно по двум причинам: во-первых, разработчик не может сделать все абсолютно правильно с учетом всех возможных нюансов, во-вторых, даже учитывая все возможные реакции приложения на внешние "раздражители" невозможно на 100% быть уверенным в том, что все оттестировано. Согласитесь - достаточно обидно будет лицезреть на демонстрации собственной программы перед коллегами или (о, ужас!) клиентами сообщение об ошибке.
Рисунок 13
После такого провала уже никому не доказать, сколько бессонных ночей проведено в детальном всестороннем тестировании программы, и что как раз именно не прошедшая тестирование функция привела к фатальному сбою... Но если Вы, как разработчик, воспользуетесь средством Rational PureCoverage, то сможете раз и навсегда забыть о мучительном поиске невыполненного кода в собственной программе.
Pure Coverage собирает статистику о тех участках программы, которые во время тестирования не были выполнены (пройдены). Подобные строки Pure Coverage подсвечивает красным цветом, четко указывая на наличие черных дыр в программе в виде неоттестированного кода, и тем самым давая разработчику хорошую пищу для размышлений.
В работе данный инструмент так же прост, как и предыдущие. Вызывать его можно как из Visual Studio, так и независимым приложением, например, из командной строки. По принципу работы Pure Coverage слегка напоминает Quantify, поскольку также подсчитывает количество вызовов функций. Правда, получаемая статистика не столь исчерпывающая как в Quantify, но для целей проверки отдельных частей на предмет прохождения теста вполне пригодна. На рисунке 13 показана статистическая выкладка, собранная Coverage. Как можно видеть, программа способна предоставить отчет пользователю в двух уровнях детальности: на уровне модулей и на уровне файлов - каждый из них показывает практически одно и то же, но как бы "с разных сторон". Статистика, показанная справа от имени функции, описывает число вызовов, ее статус, а также дополнительную информацию по выполненным линиям в исходном тексте: "Lines Hits" - число строк в процедуре, "Lines Missed" - пропущено при тестировании. Анализ только данного окна статистики позволит и отыскать не оттестированные функции, и перейти к исходному тексту для детального рассмотрения. В целях демонстрации я внес некоторые изменения в диалог OnAppAbout, описанный выше, а для усиления эффекта - блок проверки значения указателя "alex". Как известно, функция malloc возвращает 0 при невозможности выделения блока памяти запрошенного размера. Соответственно, при совпадении условия (нехватка памяти!) на экран выведется диалоговое окно с устрашающим предупреждением об ошибке.
void All::OnAppAbout() { char *alex; alex=(char *)malloc(20000); if(!alex)MessageBox(0,"ERROR","ERROR",MB_OK); CAboutDlg aboutDlg; aboutDlg.DoModal(); free(alex); }
В результате изменений, внесенных в тело функции, мне пришлось перекомпилировать приложение и вновь воспользоваться тройным входом в диалог About (сообщений о нехватке памяти получено не было). Последний раз вернемся к 13-й иллюстрации, где точно показано число вызовов и число потерянных строк.
Находясь в данном окне, переходим на уровень просмотра исходных текстов ("Source Annotace").
Purfy
Начать описание возможностей продукта Rational Purify хочется перефразированием одного очень известного изречения: "с точностью до миллиБАЙТА". Данное сравнение не случайно, ведь именно этот продукт направлен на разрешение всех проблем, связанных с утечками памяти. Ни для кого не секрет, что многие программные продукты ведут себя "не слишком скромно", замыкая на себя во время работы все системные ресурсы без большой на то необходимости. Подобная ситуация может возникнуть вследствие нежелания программистов доводить созданный код "до ума", но чаще подобное происходит не из-за лени, а из-за невнимательности. Это понятно - современные темпы разработки ПО в условиях жесточайшего прессинга со стороны конкурентов не позволяют уделять слишком много времени оптимизации кода, ведь для этого необходимы и высокая квалификация, и наличие достаточного количества ресурсов проектного времени. Как мне видится, имея в своем распоряжении надежный инструмент, который бы сам в процессе работы над проектом указывал на все черные дыры в использовании памяти, разработчики начали бы его повсеместное внедрение, повысив надежность создаваемого ПО
В общих чертах работа программы сводится к детальному выводу статистики об использовании памяти приложением. Данных в выводимой статистике вполне достаточно для получения общей, а затем - и детальной информации обо всем, что имеет отношение к памяти: утечки, потерянные блоки, фиктивные ссылки.
Purify позволяет анализировать исполняемый модуль, содержащий отладочную информацию, либо работать на уровне исходников, но только в среде Visual C++.
Работа программы традиционно начинается со сбора информации о загружаемых библиотеках, любых внешних модулях. Так же, как и в Quantify, сначала идет детальный сбор информации и анализ загружаемых библиотек, затем анализ плавно перетекает на исполняемый модуль. В зависимости от производительности и количества оперативной памяти данный процесс может очень надолго затянуться:
Поскольку Purify тесно интегрируется с Microsoft Development Studio, мне хочется построить дальнейшее изложение материала в перспективе интеграции двух продуктов.
Интеграция компонентов от Rational выражается в появлении новых инструментальных панелей на поверхности рабочего стола в Development Studio.
Получив полный набор тестирующих и профилирующих средств, разработчик обращается к ним по мере необходимости, не покидая рабочего пространства, что позволяет сэкономить массу времени на различные вызовы сторонних программ.
Теперь завершим приложение, посмотрим статистику по памяти и под конец найдем "виновного" в полученной утечке памяти. Из фрагмента видно, что указатель "alex" смотрит в сторону блока длиной в 20Кб, который выделяется функцией MALLOC. Еще можно заметить, что: указатель нигде не используется; Блок памяти не освобождается.
Из этого и следует полученное число 60000 - фактически не освобожденных блоков (3 по 20000). После добавления функции free(alex) в конец обработчика OnAppAbout и перекомпиляции тестируемого приложения, Purify не обнаруживает никаких ошибок памяти, что и являлось нашей целью. Все вышеописанные возможности дают мощный инструментарий в руки разработчика, желающего знать, где в коде находится вызов на выделение памяти, сколько физически утеряно блоков в результате работы приложения и какая часть программы в этом виновата. Еще очень важным моментом работы Purify является возможность включения опции остановки на ошибке в подопытном приложении: так, если в приложении есть Runtime-ошибка, то повстречавшись с ней оно (приложение), не "вылетит" по дампу и не позовет "доктора Ватсона", а просто завершится с передачей управления Purify, который и сообщит программисту о том, где произошел сбой, по каким причинам и сколько при этом было использовано памяти. Описанные возможности продукта Rational Purify - основные, но не единственные. Просто рамки статьи не позволяют сконцентрироваться на всех мелочах и тонкостях, присущих данному продукту, что, впрочем, и неважно, так как для этого есть руководство пользователя, где по пунктам расписаны все супервозможности продукта. По сложившейся традиции, подведем итоги статьи описанием основных возможностей Purify: Отслеживание ошибок доступа к памяти Сбор и вывод статистики по использованию памяти Использование комплексного подхода к тщательному тестированию Технология OCI - Object Code Insertion позволяет детально отследить и выловить ошибку не только в контролируемом модуле, но и в модулях DLL сторонних разработчиков Тестирование ActiveX, COM/DCOM, ODBC, DLL Настраиваемый, двухуровневый способ тестирования (придирчивости) приложений Отслеживание API вызовов Интеграция с Visual Studio | |
Quantfy
Любой разработчик рано или поздно сталкивается с проблемой необходимости увеличения производительности собственного приложения, в сжатые сроки и с максимально возможной эффективностью. Проблема достаточно нетривиальна сама по себе, поскольку, не имея необходимого инструментария, вручную придется замерять скоростные характеристики разрабатываемых приложений, дописывая для этого килобайты отладочных функций и циклов вызова. А если недосуг набивать горы новых тест-функций, придется обзавестись таймером, замеряя фрагменты кода с точностью до секунды. Естественно, что при такой "продуктивной" работе не может быть и речи о каком бы то ни было приемлемом качественном уровне создаваемого программного продукта, поскольку составление списка вызовов функций превращается в рутину, отрицательно сказывающуюся на скорости разработки.
Такой уровень автоматизации можно сравнить с каменным веком - но к сожалению, подобная практика все еще имеет место быть, и никто ее не отменял.
Rational Quantify - позволяет решить описанные выше проблемы, как говорится, одним махом. Это простое, но в то же время мощное и гибкое средство учета производительности приложений - незаменимый инструмент для сбора и анализа информации о производительности созданного программного продукта.
Quantify генерирует в табличной форме список всех вызываемых в процессе работы приложения функций, указывая временные характеристики каждой из них.
Quantify предоставляет полную статистическую выкладку, невзирая на размеры тестируемого приложения и время тестирования. Сбор данных осуществляется посредством технологии OCI (Object Code Insertion). Суть способа состоит в подсчете всех машинных циклов путем вставки счетчиков в код для каждого функционального блока тестируемой программы (все циклы приложения просчитываются реально, а не при помощи произвольных выборок, как в большинстве пакетов тестирования). Уникальность данного подхода заключается в том, что, во-первых, тестируется не только сам исходный код, но и все используемые компоненты, (например: библиотеки DLL, системные вызовы), а во-вторых, для подобного анализа совсем необязательно иметь исходные тексты тестируемого приложения.
Последнюю функцию я хотел бы выделить особо, поскольку, пользуясь Quantify, любой разработчик может подвергнуть тестированию произвольное приложение, написанное в любой среде, с использованием любого известного компилятора!
В любой момент времени можно получить слепок состояния (snapshot), показывающий общий список вызовов на данный момент работы, который впоследствии можно проанализировать. Вся статистика во время работы приложения отображается в специальном окне (рис. 4), где в наглядной форме демонстрируется временная диаграмма исполнения приложения. Здесь отображается временная характеристика (сколько приложение работало), демонстрируется (разноцветными квадратами), чем оно было занято в определенный момент времени и, самое важное, как завершилось. В закладках можно найти более детализованное описание как тестируемой программы, так и компьютера в целом. Еще один любопытный момент: во время сбора разработчик может работать со своим продуктом как обычно: нажимать на кнопки, заходить в меню и пр. Естественно, при этом вызываются явным образом определенные функции в тестируемой программе, которые тут же попадают в статистику Quantify.
Здесь можно, отсортировав список по определенному признаку, выяснить какие функции сколько раз вызывались и сколько времени заняли. Табличное представление позволяет сравнивать временные интервалы и вызовы нескольких функций (вызовов) для более глубокого сравнительного анализа. Возвращаясь к рисунку 6, хочется обратить ваше внимание на то, какую детальную информацию представляет Quantify. Приглядевшись, можно заметить, что самая часто вызываемая функция это - "GetLocalTime", число вызовов составляет 5831. Соответственно, получив такую информацию, разработчик сам решит, стоит или нет заниматься ее оптимизацией.
Сообщения об ошибках и предупреждениях Настройка фильтра
Rational Purify по своей природе способна выловить не только ошибки, связанные с потерей памяти, но также ряд других не менее важных ошибок. Следует определить, что все сообщения делятся на две категории: ОШИБКИ и ПРЕДУПРЕЖДЕНИЯ. Во время запуска программа будет дотошно собирать все виды сообщений, и только настройка фильтра позволит отказаться от заведомо лишней, ненужной информации. Система фильтров Purify способна настроить не только уровень "придирчивости" к программе, но и количество исследуемых внешних модулей (чтобы разработчик мог концентрироваться только на собственных ошибках и не огорчался по поводу системных ошибок).
По умолчанию Purify выводит все сообщения и предупреждения, что может повергнуть разработчика в шок (даже в абсолютно правильной программе могут быть определенные предупреждения). Это связанно со спецификой поиска неточностей, так как некоторые предупреждения могут счиаться ошибкой, а могут и не быть таковыми - все зависит от конкретного алгоритма! Вот почему Purify и предлагает мощный фильтр
Как видно из рисунка, предполагается ставить фильтры либо по сообщениям (вручную) либо по категориям (при этом соответствующие сообщения выберутся автоматически). Обратите внимание на список сообщений: количество доходит до 41 и растет с каждой новой версией! Перед тем, как мы перейдем к рассмотрению всех сообщений, хочется отметить очень важный нюанс: Purify способен работать совместно с отладчиком (он прописывается отдельно). В этом случае возможна двойная работа по отладке программы с установкой брейкпоинтов:. итд.
Попробуем рассмотреть некоторые сообщения Purify c комментариями и примерами:
ABR: Array Bounds Read Выход за пределы массива при чтении #include <iostream.h> #include <windows.h> int main(int, char **) { int *ptr = new int[2]; //Определить число элементов ptr[0] = 0; ptr[1] = 1; for (int i=0; i <= 2; i++) { //ОШИБКА //ABR when i is 2 cerr << "ptr[" << i << "] == " << ptr[i] << '\n'; } delete[] ptr; return(0); }
ABW: Array Bounds Write Выход за пределы массива при записи #include <iostream.h> #include <windows.h> int main(int, char **) { int *ptr = new int[2]; //Определить число элементов for (int i=0; i <= 2; i++) { //ОШИБКА ptr[i] = i; cerr << "ptr[" << i << "] == " << ptr[i] << '\n'; //ABW + ABR when i is 2 } delete[] ptr; return(0); }
ABWL: Late Detect Array Bounds Write Cообщение указывает, что программа записала значение перед началом или после конца распределенного блока памяти #include <iostream.h> #include <windows.h> int main(int, char **) { int *ptr = new int[2]; //Определить число элементов for (int i=0; i <= 2; i++) { //ОШИБКА ptr[i] = i; cerr << "ptr[" << i << "] == " << ptr[i] << '\n'; } delete[] ptr; //ABWL: ОШИБКА return(0); }
BSR: Beyond Stack Read сообщение указывает, что функция в программе собирается читать вне текущего указателя вершины стека #include <windows.h> #include <iostream.h> #define A_LOT 256 int * setup_values(void) { int values[A_LOT]; //ОШИБКА: должен быть статичным for (int i=0; i < A_LOT; i++) { values[i] = i; } return(values); //ОШИБКА: неизвестно, что возвращать } int main(int, char **) { int *values; values = setup_values(); for (int i=0; i < A_LOT; i++) { //BSR: значения из "setup_values" больше не находятся в стеке cerr << "element #" << i << " is " << values[i] << '\n'; } return(0); }
BSW: Beyond Stack Write сообщение указывает, что функция в программе собирается писать вне текущего указателя вершины стека (пример см.
выше) FFM: Freeing Freed Memory Попытка освобождения свободного блока памяти
#include <iostream.h> #include <windows.h> int main(int, char **) { int *ptr1 = new int; // int int *ptr2 = ptr1; //ОШИБКА: должен дублировать объект, а не копировать указатель *ptr1 = 10; *ptr2 = 20; cerr << "ptr1" << " is " << *ptr1 << '\n'; cerr << "ptr2" << " is " << *ptr2 << '\n'; delete ptr1; delete ptr2; //FFM: ОШИБКА return(0); }
FIM: Freeing Invalid Memory Попытка освобождения некорректного блока памяти
#include <iostream.h>
int main(int, char **) { int i; delete[] &i; //FIM: не было операции new. Освобождать нечего! return(0); }
FMM: Freeing Mismatched Memory Сообщение указывает, что программа пробует освобождать память с неправильным ВЫЗОВОМ API для того типа памяти
#include <windows.h>
int main(int, char **) { HANDLE heap1, heap2; heap1 = HeapCreate(0, 1000, 0); heap2 = HeapCreate(0, 1000, 0); int *pointer = (int *) HeapAlloc(heap1, 0, sizeof(int)); HeapFree(heap2, 0, pointer); //ОШИБКА: неправильное освобождение памяти HeapDestroy(heap1); HeapDestroy(heap2); return(0); }
FMR: Free Memory Read Попытка чтения уже освобожденного блока памяти
#include <iostream.h> #include <windows.h> int main(int, char **) { int *ptr = new int[2]; ptr[0] = 0; ptr[1] = 1; delete[] ptr; //ОШИБКА: (специально сделано удаление) for (int i=0; i < 2; i++) { //FMR: ОШИБКА ДОСТУПА К ПАМЯТИ cerr << "element #" << i << " is " << ptr[i] << '\n'; } return(0); }
FMW: Free Memory Write Попытка записи уже освобожденного блока памяти
#include <iostream.h>
#include <windows.h> int main(int, char **) { int *ptr = new int[2]; ptr[0] = 0; ptr[1] = 1; delete[] ptr; //ОШИБКА: (специально сделано удаление) for (int i=0; i < 2; i++) { ptr[i] *= i; //FMR + FMW: потому что ptr уже удален cerr << "element #" << i << " is " << ptr[i] << '\n'; //FMR } return(0); }
HAN: Invalid Handle Операции над неправильным дескриптором
#include <iostream.h> #include <windows.h> #include <malloc.h> int main(int, char **) { (void) LocalUnlock((HLOCAL)3);//HAN: 3 - неправильный указатель return(0); }
HIU: Handle In Use Индикация утечки ресурсов.
Неправильная индикация дескриптора
#include <iostream.h> #include <windows.h> static long get_alignment(void) { SYSTEM_INFO sys_info; GetSystemInfo(&sys_info); return(sys_info.dwAllocationGranularity); } int main(int, char **) { const long align = get_alignment(); HANDLE file_handle = CreateFile("file.txt", GENERIC_READ|GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); if (file_handle == INVALID_HANDLE_VALUE) {
cerr << "ОШИБКА файла\n"; return(1); } HANDLE map_handle = CreateFileMapping(file_handle, NULL, PAGE_READWRITE, 0, align, "mymap"); if (map_handle == INVALID_HANDLE_VALUE) { cerr << "Unable to create actual mapping\n"; return(1); } char *pointer = (char *) MapViewOfFile(map_handle, FILE_MAP_WRITE, 0, 0, align);
if (pointer == NULL) { cerr << " Unable to map into address space\n"; return(1); } strcpy(pointer, "hello\n"); //HIU: map_handle все еще доступный и правильный //HIU: file_handle все еще доступный и правильный return(0); }
ILK: COM Interface Leak Утечка COM интерфейса
#include <windows.h>
int main(int, char **) { LPMALLOC lpIm; CoGetMalloc( MEMCTX_TASK, (LPMALLOC*)&lpIm); IMalloc_Release(lpIm); //НЕВЕРНЫЙ ЗАПРОС return(0); }
IPR: Invalid Pointer Read Ошибка обращения к памяти, когда программа пытается произвести чтение из недоступной области
#include <iostream.h>
#include <windows.h> int main(int, char **) { int *ptr = (int *) 0x80000000; //ОШИБКА: Указатель на зарезервированную часть адресного пространства for (int i=0; i < 2; i++) { //IPR: Попытка обращения к недопустимому указателю cerr << "ptr[" << i << "] == " << ptr[i] << '\n'; } return(0); }
IPW: Invalid Pointer Write Ошибка обращения к памяти, когда программа пытается произвести запись из недоступной области
#include <iostream.h> #include <windows.h> int main(int, char **) { int *ptr = (int *) 0x80000000; //ОШИБКА: Указатель на зарезервированную часть адресного пространства for (int i=0; i < 2; i++) { //IPW + IPR: Попытка обращения к недопустимому указателю ptr[i] = i; cerr << "ptr[" << i << "] == " << ptr[i] << '\n'; } return(0); }
MAF: Memory Allocation Failure Ошибка в запросе на распределение памяти
#include <iostream.h> #include <windows.h> #define VERY_LARGE 3000000000 //Больше, чем можем получить int main(int, char **) { int *ptr = new int[VERY_LARGE / sizeof(int)]; //MAF: нельзя так много if (ptr == 0) { cerr << "Failed to alloc, as expected\n"; return (1); } else { cerr << "Got " << VERY_LARGE << " bytes @" << (unsigned long)ptr << '\n'; delete[] ptr; return(0); } }
MLK: Memory Leak Утечка памяти
#include <windows.h> #include <iostream.h> int main(int, char **) { (void) new char[1000]; (void) new char[1000]; (void) new char[1000]; (void) new char[1000]; (void) new char[1000]; //5 килобайт потерь return(0); }
ИЛИ
void All::OnAppAbout() { char *alex; //Указатель alex=(char *)malloc(20000); //MLK: берем, но не отдаем CAboutDlg aboutDlg; aboutDlg.DoModal(); }
MPK: Potential Memory Leak Потенциальная утечка памяти (возникает когда производится операция над массивом не с нулевого элемента)
#include <iostream.h> #include <windows.h> int main(int, char **) { static char *ptr = new char[500000]; ptr += 100; //MPK: обнаружится, как потенциально пропущенное return(0); }
NPR: Null Pointer Read Попытка чтения с нулевого адреса
#include <iostream.h> #include <windows.h> int main(int, char **) { int *ptr = (int *) 0x0; //ОШИБКА for (int i=0; i < 2; i++) { //NPR: ошибка доступа cerr << "ptr[" << i << "] == " << ptr[i] << '\n'; } return(0); }
NPW: Null Pointer Write Попытка записи в нулевой адрес
#include <iostream.h> #include <windows.h> int main(int, char **) { int *ptr = (int *) 0x0; //ОШИБКА for (int i=0; i < 2; i++) { //NPW: ошибка доступа ptr[i] = i; cerr << "ptr[" << i << "] == " << ptr[i] << '\n'; } return(0); }
UMC: Uninitialized Memory Copy Попытка копирования непроинициализированного блока памяти
#include <iostream.h> #include <windows.h> #include <string.h>
int main(int, char **) { char *ptr = new char[10]; char var[10];
memcpy(var, ptr, 10); //UMC предупреждение
delete[] ptr; return(0); }
UMR: Uninitialized Memory Read Попытка чтения непроинициализированного блока памяти
#include <iostream.h> #include <windows.h> int main(int, char **) { int *ptr = new int; cerr << "*ptr is " << *ptr << '\n'; //UMR: нет значения в ptr delete[] ptr; return(0); }
Подведем итоги статьи описанием основных возможностей Purify:
Отслеживание ошибок доступа к памяти Сбор и вывод статистики по использованию памяти Использование комплексного подхода к тщательному тестированию Технология OCI - Object Code Insertion позволяет детально отследить и выловить ошибку не только в контролируемом модуле, но и в модулях DLL сторонних разработчиков Тестирование ActiveX, COM/DCOM, ODBC, DLL Настраиваемый, двухуровневый способ тестирования (придирчивости) приложений Интеграция с Visual Studio Открытое API.Позволяет дописывать разработчикам собственные модули и присоединять их. Совместная работа с любым отладчиком Тестирование системных вызовов
Связаться с автором и получить дополнительную информацию можно по e-mail:
См. также:
Спецификации
Требования для клиента:
Минимум: 64MB ОЗУ, 35MB Дискового пространства
Требования для сервера:
Минимум: 128MB ОЗУ, 70MB Дискового пространства
Поддерживаемые Web-броузеры
Microsoft Internet Explorer
Netscape
Поддерживаемые Web Серверы Apache Microsoft IIS Netscape
Поддерживаемые операционные системы
Windows 2000, Windows NT,Windows 95/98 (client only)
Compaq Tru64 UNIX
Hewlett-Packard HP-UX
IBM, AIX, NCR MP-RAS
Red Hat Linux
SCO UnixWare
Siemens Reliant UNIX
Silicon Graphics IRIX
Sun Solaris SPARC
Solaris Intel
Интеграция:
IBM VisualAge for Java
Microsoft Visual Studio
Visual Basic
Visual C++
Visual J++
Visual InterDev
Adobe FrameMaker
Sybase PowerBuilder
IBM WebSphere Studio
Microsoft FrontPage
Microsoft Word
All SCC-compliant tools
Справочная информация
Отличительные черты ClearCase Является высокопроизводительным средством в архитектуре "клиент/сервер" масштаба предприятия Ведет полный учет всего относящегося к проекту Создает дерево версий для каждого элемента проекта Позволяет проводить параллельную работу над одним файлом нескольким участникам команды Позволяет каждому участнику проекта настраивать собственное рабочее пространство и видимый круг подконтрольных элементов Позволяет разработчику на время выходить из состава проекта При наличии MultiSite объединяет усилия регионально удаленных команд разработчиков Хранит все проектные данные, включая исходные файлы, двоичные файлы, библиотеки, документацию, Web-приложения, модели и каталоги Имеет Web-интерфейс для удаленного доступа Конвертирует данные из PVCS, SourceSave, CVS в собственный формат Имеет дружественный интерфейс
Спецификации
Требования для клиентской части: Минимум: 64 Mбайт ОЗУ, 35 Mбайт дискового пространства
Требования для серверной части: Минимум: 128 Mбайт ОЗУ, 70 Mбайт дискового пространства
Поддерживаемые Web-браузеры: Microsoft Internet Explorer Netscape Communicator
Поддерживаемые Web-cерверы Apache Microsoft Internet Information Server Web-серверы компании Netscape
Поддерживаемые операционные системы Windows 2000, Windows NT, Windows 95/98 (только клиентская часть) Compaq Tru64 UNIX Hewlett-Packard HP-UX IBM, AIX, NCR MP-RAS Red Hat Linux SCO UnixWare Siemens Reliant UNIX Silicon Graphics IRIX Sun Solaris SPARC Solaris Intel
Интеграция со средствами разработки:
IBM VisualAge for Java Microsoft Visual Studio Visual Basic Visual C++ Visual J++ Visual InterDev Adobe FrameMaker Sybase PowerBuilder IBM WebSphere Studio Microsoft FrontPage Microsoft Word All SCC-compliant tools
Средства тестирования от компании Ratonal
(оригинал напечатан в "Компьютер-пресс" #2'2001 и на сайте )
Новичков Александр Николаевич
http://www.interface.ru, http://www.compress.ru, http://www.cmcons.com
C развитием аппаратной базы компьютерных систем - увеличением тактовой частоты до запредельных уровней (переваливших за гигагерц), ускорением обработки изображений в реальном масштабе времени при помощи супермощных видеоадаптеров многие разработчики не считают нужным (или возможным) оптимизировать написанные ими программные продукты, перенося весь неоптимизированный код на быструю подсистему, быстрый процессор, "умный" компилятор. Результат подобного злоупотребления мы наблюдаем ежедневно во время запуска программ на собственных компьютерах, отмечая странную тенденцию: чем новее программа, тем больше требует ресурсов, и тем медленнее работает. Но и это еще не все! Многие программы по окончании работы не освобождают все занимаемые ресурсы, что приводит к достаточно неприятным последствиям. Странно, не правда ли? Казалось бы, технологии программирования должны совершенствоваться и идти в ногу с аппаратными новинками, качественно используя все предоставляемые ими возможности, однако на деле все обстоит гораздо хуже. В погоне за новыми цифрами версий на коробках продуктов разработчики не считают нужным (возможным) проводить детальную оптимизацию написанного кода, тщательно отслеживая все вызовы и подсчитывая занимаемую системную память, поскольку занятие это трудоемкое и длительное, а получаемый результат не всегда оправдывает надежды: времени потрачено много, сил - еще больше, а производительность конечного продукта повысилась в лучшем случае на 9%, а то и меньше. Согласитесь, ситуация для нашего времени достаточно типичная, причем типична она для всех софтверных компаний, вне зависимости от ранга, размера, и, что немаловажно, от географического расположения. Лозунг: "время - деньги", применяемый всеми к месту и не к месту, в данной ситуации дает явный сбой! Получается количество версий - в ущерб качеству.
За примером далеко ходить не придется: у всех есть нерасторопные операционные системы и офисные пакеты, которые с каждой новой реализации повышают аппаратные требования, функционально оставаясь при этом, на уровне 95 года.
Неужели все так страшно и бесперспективно? И "да" и "нет".
Все крупные компании, связанные с написанием программного обеспечения, пытаются найти способы наиболее эффективного тестирования, не выходя при этом за рамки бюджета конкретной разработки. Но, к сожалению, то ли ищут не там, то ли применяют не то, поскольку оптимизированных продуктов на рынке не так много. Разработка качественных продуктов в отведенные сроки сроки - вот задача, на решения которой направлены все продукты компании . В частности, для этапа разработки высококачественного кода, компанией рекомендуется использование, посредством . (Rational Unified Process - методологии разработки), инструментов тестирования: , , . Разумное применение этих продуктов позволит группам разработчиков найти узкие места в производительности создаваемого программного обеспечения и своевременно устранить их.
Quantify - собирает полную статистику о количестве вызовов функций в тестируемой программе, позволяя тем самым узнавать временные характеристики отдельных частей приложения Pure Coverage - позволит быстро найти участки кода, пропущенные при тестировании Purify - отлавливает все ошибки, связанные с утечкой памяти а также некоторые Run-time ошибки
Далее разговор пойдет о наиболее продвинутой программе, из вышеприведенного списка - Rational Purify, которая также поставляется компанией . Данный продукт является самым сложным и самым "интеллектуальным", в силу своей специфики, поскольку ей в обязанности вменяется нахождение ошибок, а не простая статистическая выкладка, которую выдают остальные пакеты.
Управление тестированием, разработкой и конфигурацией на основе Ratonal Change Request Management
Новичков Александр
http://www.interface.ru, http://www.compress.ru, http://www.cmcons.com
технический специалист, преподаватель УЦ Interface Ltd,
опубликовано в 8'2001
опубликовано на сайте
в голову после писем, пришедших
Идея написать данную статью в стиле "Follow Me" пришла в голову после писем, пришедших на мой адрес после публикации двух статей о технологиях Rational (см. КомпьютерПресс № 2'2001 и № 5'2001 ). Смысл писем сводился к тому, что построить по технологиям Rational базу по тестированию и конфигурации возможно, только вот связать все это воедино непросто, и уж тем более нельзя на основе описанных продуктов говорить о какой бы то ни было управляемости с точки зрения руководства компании. Конечно же, упрек верный, но технологии Rational Software хороши тем, что любой их сегмент можно рассматривать как по отдельности, так и как часть большой мозаики. Сложив такую мозаику, вы получите полностью управляемое производство, на входе которого можно подать идею, а на выходе получить современный программный продукт. Сам процесс разработки при этом будет похож на производственный конвейер, где все течет, работает и подчиняется строго установленным правилам, где каждый участник проекта знает, что ему делать, и задачи от участника к участнику передаются не на словах, а при помощи специальных средств; соответственно, при такой передаче должна создаваться определенная база данных, в которой и будет храниться история проектов, - эдакий репозиторий проекта. Все вышеописанные проблемы может решить Rational Unified Process - RUP - интерактивная энциклопедия по построению качественного процесса выпуска программного обеспечения. Рассмотрение RUP мы начали со средств тестирования для разработчиков, а продолжили конфигурационным управлением. Сегодня мы вкратце рассмотрим программный продукт, который сможет связать в единую цепочку разработчиков, специалистов по тестированию и их руководителей. Имя данного продукта - Rational ClearQuest.
Компания является лидером в области создания методологий и программных решений, ориентированных на программистов, аналитиков, специалистов по тестированию приложений. Спектр выпускаемого обеспечения охватывает потребности всех участников проекта - от аналитиков до разработчиков и сотрудников, занимающихся внедрением готового продукта. Все программно-методологические решения - результат многолетнего труда аналитиков и разработчиков как самой компании Rational, так и ее партнеров и клиентов. Все эти решения в совокупности составляют - методологическую энциклопедию, в которой описаны все этапы создания качественного программного продукта. Пользуясь подобной энциклопедией и применяя соответствующие инструменты, рекомендуемые Rational, можно создавать программные продукты качественно и в срок. Особое место в RUP занимает SCM (Source Code Management) - управление исходным текстом. SCM описывает способ контроля и сопровождения информации, составляющей программный проект. SCM - это методология, которую поддерживает продукт , предназначенный для отслеживания и детального протоколирования всего, что связано с хранением всех артефактов, сопровождающих проект (здесь и далее термин "артефакт" следует трактовать как "хранимый документ". Работая над проектом, каждый участник создает определенный набор файлов-артефактов: документов, исходных текстов, бинарных файлов и т.д.). При коллективной разработке проекта ClearCase рекомендован тем участникам проекта, которые должны обмениваться информацией с другими и точно знать, кто из коллег и когда вносил изменения. Ведь в современных условиях создания приложений большими командами разработчиков просто невозможно обойтись без надежного и мощного средства отслеживания изменений, позволяющего всем участникам команды представлять себе текущее положение дел в разработке проекта.
Компания Rational является лидирующей компанией в области создания методологий и программных решений, ориентированных на программистов, аналитиков, тестировщиков. Спектр выпускаемого обеспечения целиком покрывает потребность всех участников проекта: от аналитиков до разработчиков и внедренцев. Все программно-методологические решения - плод многолетнего труда аналитиков и разработчиков как самой Rational, так и ее партнеров. В итоге, все решения были собраны воедино. Так появился RUP - Rational Unified Process - методологическая энциклопедия, в которой описаны все шаги, необходимые для создания качественного программного продукта. Пользуясь подобной энциклопедией и применяя соответствующие инструменты, рекомендуемые Rational, команда будет создавать обеспечение качественно и в срок. "Строй быстрей и качественней!" - вот лозунг, выдвигаемый Rational.
Особое место в RUP занимает Source Code Management - управление исходным текстом. SCM описывает способ контроля и сопровождения информации и текущем состоянии каждого файла, составляющего программный проект. SCM - это методология, которую всецело поддерживает продукт ClearCase, чьей обязанностью и является отслеживание и детальное протоколирование всего, что связанно с разработкой проекта. В командной разработке регламентируется использование SCM отдельными участниками команды. Но если подойти к делу неформально, то рекомендация по использованию данного продукта и методологии может выглядеть так: ClearCase рекомендуется всем участникам проекта, кто должен обмениваться информацией с другими, и точно знать кто и когда из коллег внес изменения. Ведь в современных условиях скоростногой разработки кода большими командами просто необходимо иметь надежное и мощное средство по отслеживанию изменений и позволяющее всем участникам команды видеть текущее положение дел в разработке проекта.
Web-интерфейс
Все современные средства коллективной разработки Rational обладают Web-интерфейсом, что само по себе очень логично в условиях территориально разбросанной команды и удаленного доступа части сотрудников. Особая необходимость в использовании Web-интерфейса как раз и открывается при распределенной разработке (рис. 7).
Рис. 7. Здесь приведено начальное окно, где пользователь выбирает локально хранимые данные проекта и имя вида, к которому производится подключение клиента.
Интерфейс приложения прост и понятен, способ работы также не вызывает сложностей: все необходимые для работы файлы переносятся на локальный компьютер и модифицируются любым известным способом. Доступ к тем или иным файлам репозитария осуществляется посредством выбора соответствующего вида, предварительно физически созданного на сервере (например, отдельный вид для разработчиков, технических писателей и т.д.). Отредактированные файлы возвращаются обратно в систему. Web-доступ организуется c помощью Internet Information Server или Web-серверов Netscape (рис. 8).
Рис. 8. Так выглядит окно работы с проектами. В верхней части браузера - наименования доступных в данный момент операций.
при создании крупных проектов иметь
Итак, при создании крупных проектов иметь в своем распоряжении только инструменты тестирования и конфигурационного управления в нынешних условиях разработки программного обеспечения уже недостаточно. Необходимо использовать не только индивидуальные средства разработки, но и средства и технологии коллективной работы. Контролировать проект и объединять между собой тестировщиков и разработчиков поможет именно Rational ClearQuest.
ClearCase на сегодняшний день является самой продвинутой системой версионного и конфигурационного управления, снабженной новейшими достижениями в области SCM (Source Code/Configuration Management). Поскольку ClearCase является системой корпоративного уровня, рекомендовать ее можно всем предприятиям, число разработчиков в которых больше пяти. Продукт можно изучить . Все мощные возможности ClearCase раскрываются при использовании его на крупных предприятиях с большим количеством разработчиков. ClearCase - поистине незаменимый продукт, когда речь заходит об объединении регионально удаленных команд разработчиков. Более полная информация о продукте доступна на сайте www.interface.ru По вопросу получения ознакомительной версии обращайтесь по e-mail
См. также:
ClearCase на сегодняшний день является самой продвинутой системой версионного и конфигурационного управления, снабженной самыми последними достижениями в области SCM. Поскольку ClearCase является системой корпоративного уровня, то рекомендовать ее можно всем предприятиям, число разработчиков в которых более 5. Все свои мощные возможности программа раскрывает при использовании ее на крупных предприятиях с большим количеством разработчиков. ClearCase становится незаменимым продуктом когда речь заходит об объединении регионально удаленных команд разработчиков.
По обучению и продаже обращайтесь в компанию "Интерфейс"
Тел: (095) 795-3186, 135-5500, 135-2519
