3.3 Завдання на лабораторну роботу

3.3.1 Ознайомитися з теоретичними відомостями та довідковою інформацією, наданою Rational Performance Tester.

3.3.2 Виконати навантажувальне тестування власного сайту.

3.3.3 Створити наступні звіти: Performance Report (Отчет о производительности); Page Element Report (Отчет по элементам страниц); Percentile Report (Отчет по процентилям); Verification Report (Верификационный отчет); Response Time Breakdown.

3.3.4 Виконати аналіз отриманих результатів.

3.4 Зміст звіту

3.4.1 Тема та мета роботи.

3.4.2 Результати роботи.

3.4.3 Висновки, що містять відповіді на контрольні запитання, а також відображують результати виконання роботи та їх критичний аналіз.

3.5 Контрольні запитання

Лабораторна робота №4 Контроль версій проекта Microsoft Visual Studio в IBM Rational ClearCase

4.1 Мета роботи

Вивчити основні можливості IBM Rational ClearCase, ознайомитись з архітектурою системи та виконати контроль версій проекта Microsoft Visual Studio.

4.2 Основні теоретичні відомості

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

− «взятие» пользователем файла из хранилища под редактирование (check out);

− «сдача» редактируемого файла в хранилище (check in);

− блокировка редактирования файла, взятого другим пользователем;

− комментирование сделанного изменения;

− просмотр дерева версий и загрузка необходимых версий;

− откат к предыдущей версии.

Основные общие термины, используемые в системах контроля версий – это проект и версия проекта.

Проект − под проектом понимается вся совокупность файлов исходных текстов различных языков программирования, ресурсных и других файлов, необходимых для сборки программного продукта (одного или более исполняемых файлов, библиотек DLL и так далее). Часто к проекту добавляются исходные тексты файлов справки (Help files), сценарии программ инсталляции, а также сопроводительная документация проекта и так далее. Хранение составляющих проекта осуществляется таким образом, чтобы обеспечить доступ к любой из зафиксированных версий проекта.

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

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

В эволюции сред разработки все более явственно проявляется процесс интеграции средств, используемых для программирования (Microsoft Visual Studio, Borland Enterprise Studio, пакет Oracle), вплоть до того, что среда разработки становиться единой (Visual Studio. NET). Соответственно, также успешно интегрируются в среды разработки и системы контроля версий. В настоящее время среди разработчиков программного обеспечения очень популярен пакет Rational Suite или его отдельные компоненты, предоставляющий средства для проектирования, разработки, тестирования и сопровождения программного обеспечения. В этот же пакет входит очень мощная система контроля версий Rational ClearCase.

ClearCase имеет богатые возможность по интеграции со средством разработки Visual Studio. Интеграция позволяет проводить операции по работе с элементами репозитория не покидая среды разработки. При установленной интеграции с утилитой сборки Omake, возможна компиляция проекта непосредственно из среды (для этого создается специальный пункт в меню Tools).

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

Из Visual Studio возможно работать с обоими типами видов, имеющихся в ClearCase. Из среды Visual Studio можно как открывать существующие проекты из репозиториев, так и создавать новые. В обоих случаях проекты находятся под управлением ClearCase.

Создание VOB. Для реализации полного контроля над версиями в специальную базу данных – VOB (Version Object Base) – заносятся все изменения данных проекта. Репозитарии, хранящие всю промежуточную информацию о состоянии проекта, могут находиться в локальной сети как на одном компьютере, так и раздельно. Физически VOB представляет собой некую файловую структуру, закодированную особым образом. Основой VOB являются элементы, представляющие собой файлы или каталоги. Элемент должен и может иметь одну или несколько версий.

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

Майстр створення VOB. Для виклику майстра створення VOB натискаємо: Start Programs Rational Software Rational ClearCase  Administration  Create VOB.

Рисунок 4.1 – Створення VOB. Крок 1

Після заповнення полів подібним чином як показано на рис.4.1, необхідно вказати місце зберігання VOB. Приклад відображено на рис.4.2. Каталог, в якому повинен зберігатися VOB, має бути каталогом із загальним доступом.

Потім заповнюємо форму як вказано на рис.4.3.

Процес створення VOB завершено (рис.4.4).

Рисунок 4.2 – Створення VOB (Крок 2)

Рисунок 4.3 – Створення VOB(Крок 3)

Рисунок 4.4 – Вікно виводу зведеної інформації про VOB

Створення View. View надає доступ до версії кожного елементу проекту. У ClearCase Explorer, View відображає елементи в деревоподібній формі у вікні Folders Pane.

Запускаємо StartProgramsRational SoftwareRational ClearCase ClearCase Explorer.

На рис. 4.5 показано основне вікно ClearCase Explorer з відкритим розділом ClearCase Tutorial. Також відображені назва панелі інструментів з яких складається головне вікно ClearCase Explorer.

Рисунок 4.5 – Основне вікно ClearCase Explorer

Отже, для створення View, на вкладці Toolbox, панелі Shortcut pane обираємо «Base ClearCase». Потім натискаємо на Create View(рис.4.6). Виконуємо наступні дії (рис. 4.7-4.11).

Рисунок 4.6 – Вікно вибору Base ClearCase

Рисунок 4.7 – Cтворення View (Крок 1)

Рисунок 4.8 – Вибір типу View

Рисунок 4.9 – Cтворення View (Крок 2)

Після введення місця розташування View натискаємо на «Advanced Options». Потім вводимо шлях, вказуючи місце розташування в каталозі з загальним доступом.

Рисунок 4.10 – Cтворення View (Крок 3)

Потім натискаємо OK FinishOK. ClearCase creates the view and then opens the Available Elements dialog box which lists the available VOBs. Із запропонованих варіантів, в лівій частині вікна, необхідно вибрати створений нами раніше VOB і натиснути Add.

Рисунок 4.11 – Створення View (Крок 4)

Процес створення View завершено.

Додавання файлів в систему контролю версій.

Рисунок 4.12 – Структура елементів версійність сховища ClearCase Explorer

Щоб додати файл необхідно виділити його в провіднику Windows і перетягнути на панель Details. Нагадаємо, що назви панелей зазначено на рис.4.5 (Основне вікно ClearCase Explorer).

Перед тим, як ми зможемо зробити «check out» файлу, його необхідно додати до ClearCase source control.

Для цього необхідно виділити цей файл в «Details pane» і провести на ньому Right-click. З розкрився меню вибрати «Add to source control».

У вікні вибрати необхідні опції і натиснути «ОК». В рамках даної роботи рекомендується залишити опції як показано на рис. 4.13.

Рисунок 4.13 – Додавання файлу в версійність сховище

Создание проекта Visual Studio c постановкой под версионное управление. Проект создается обычным образом. Отличие заключается лишь в месте хранения проекта. Проект необходимо поместить на сетевой диск в репозиторий (если это динамический вид), либо в локальную директорию (если это статический вид). Рис.4.14 показывает диалог создания нового проекта. Проект сохраняется в репозитории «seminar» на логическом диске «Z» (динамический вид).

Рисунок 4.14 – Для того, чтобы проект стал храниться в ClearCase, достаточно его создать на одном из виртуальных дисков

В результате на виртуальном диске, в репозитории создается поддиректория с именем проекта, в которой размещены все созданные файлы (рис.4.15).

Все файлы являются личными (view-private) для созданного вида и не являются частью проекта. С ними можно работать только локально (в проекте их не видно).

Рисунок 4.15 – Так выглядят файлы только что созданные, но не еще не поставленные под конфигурационное управление

Для постановки проекта под контроль можно перейти в ClearCase Details и поставить вручную, либо из среды.

Из среды под контроль проект ставится по контекстному меню из окна «File View» (рис.4.16) командой «Add to Source Control».

Рисунок 4.16 – Постановка файлов под конфигурационное управление из среды разработки

При постановке под контроль необходимо выбрать список подконтрольных файлов и ввести комментарий (рис. 4.17).

Рисунок 4.17 – Все файлы выделяются и при первоначальной постановке комментарий дается один на всех

Рисунок 4.18 –

В результате все выделенные элементы попадут под контроль, в состоянии Check-out (обратите внимание пункт «keep checked out» на рис.4.18).

Рисунок 4.19 – Доступ ко всем данным ClearCase возможен непосредственно из верхнего меню (ClearCase при инсталляции замещает собой Visual SourceSafe)

Рисунок 4.20 – Простая и привычная компиляция, которая работает в ClearCase так же как и с обычной файловой системой

4.3 Завдання на лабораторну роботу

4.4 Зміст звіту

4.5 Контрольні запитання

Лабораторна робота №5 Автоматизація збірок складних проектів в IBM Rational ClearCase

5.1 Мета роботи

Навчитися виконувати автоматизацію збірок складних проектів в IBM Rational ClearCase.

5.2 Основні теоретичні відомості

Компиляция через Omake. ClearCase обладает богатыми возможностями по сборке проекта. Одна из них – использование специальных сборочных утилит. Используя утилиты на выходе получаются не просто бинарные файлы, а – объекты компиляции (derived objects).

Результаты автоматической сборки все участники проекта:

– сборка проекта может быть распределена между несколькими серверами;

– посредством сборки формируются специальные объекты, которые детально хранят информацию о том:

– кто, когда и скакой машины производил сборку;

– какие ключи компилятора при этом были выставлены в среде разработки (классическая проблема: билд не работает, а прошлый работал… выясняется, что предыдущий был откомпилирован в debug, а текущий в release);

– какие конкретно версии участвовали в сборке данного EXE или DLL (либо любого бинарника;

– сборки можно сравнивать друг с другом (узнать чем один билд отличается от другого становится очень просто);

– объекты компиляции, в отличии от View-private объектов, могут являться частью репозитория и о их наличие может быть известно всем участникам проектам, а не только тому, кто проводил сборку;

– объекты компиляции хранят в себе историю о каждой перекомпиляции (каждая перекомпиляции является билдом; каждый билд имеет уникальный номер; история билдов сохраняется).

Разработчик может откыть для остальных участников стабильный билд (сделать разделяемым).

Для включения интеграции необходимо вызвать специальное приложение. В появившемся окне (рис.5.1) выбрать «add…» для создания интеграции, либо отказаться от уже имеющейся посредством пункта «Remove…».

Рисунок 5.1 – Включение и выключение модуля расширенной компиляции – OMAKE

В результате интеграции, в верхнем меню Visual Studio, в пункте Tools появится подпункт вызова сборки – Omake. Omake проводит компиляцию только на основе имеющегося MakeFile.

Перед вызовом Omake необходимо провести операцию экспортирования MakeFile (и поддерживать его в актуальном состоянии). Экспорт проводится посредством вызова команды ProjectaExport MakeFile

Рисунок 5.2 – Теперь все откомпилированные объекты хранят всю инфраструктуру сборки

Рисунок 5.2 демонстрирует список объектов компиляции после вызова Omake. Более подробную информацию о числе объектов и их состоянии можно получить из командной строки по команде lsdo

Рисунок 5.3 – Командной строка по команде lsdo

5.3 Завдання на лабораторну роботу

5.4 Зміст звіту

5.5 Контрольні запитання

Лабораторна робота №6 Обчислення метрик розміру та складності програм з використанням IBM Rational ClearCase

6.1 Мета роботи

Вивчити основні метрики програмних систем та реалізувати їх в IBM Rational ClearCase.

6.2 Основні теоретичні відомості

Виконання скрипта обчислення метрик. Скрипт обчислення метрик запускається з контекстного меню елементів версійного сховища. Для цього в меню слід додати пункт його запуску. Отже, для запуску редактора Context Menu Editor виконуємо: Start Programs Rational Software Rational ClearCase Context Menu Editor(рис.6.1).

Рисунок 6.1 – ClearCase Context Menu Editor

У верхній панелі вікна вибираємо Application  ClearCase Explorer. В деревоподібному списку «Object Type» Вибираємо "Snapshot View"  "VOB".

У списку Object State вибираємо «Checked In».

Потім натискаємо «New». Далі у вікні, приклад якого показано на малюнку, призначаємо значення полям так, як показано на малюнку.

Слід звернути увагу на поля «Сommand». У першому полі вибираємо «Executable», а в другому вказуємо шлях до *.bat файл в якому міститься Perl-скрипт. Текст Perl-скрипта буде розглянуто далі. Рекомендується, щоб цей файл знаходився в каталозі з загальним доступом.

Рисунок 6.2 – Вікно властивостей елемента меню

Після того, як значення полів задані, натискаємо «ОК». Назва створеного нами пункту меню повинне з'явитися в списку «Available Menu Choices». Вибираємо його і натискаємо на «Add». Тепер назва цього пункту меню з'явилося у списку «The Menu Contents».

Далі натискаємо Configuration -> Apply. Потім - Configuration -> Save to File ... і вибираємо каталог, в якому буде зберігатися дана конфігурація меню. Ця конфігурація буде мати вигляд. Reg файлу.

Далі слід застосувати це меню. Для в Windows провіднику переходимо в каталог, у якому тільки що зберегли *.reg файл. Натискаємо на нього правою кнопкою, і вибираємо «Злиття». Ймовірно, дану дія слід здійснювати з правами адміністратора.

Тепер створений пункт меню з'явився в контекстному меню елемента. Приклад його виклику відображений на рис.6.3.

Рисунок 6.3 – Виклик меню елемента VOB

Perl-скрипт для розрахунку метрик. Скрипт виконується за допомогою ccperl.exe. який знаходиться «Program Files \ ... \ ClearCase \ bin», тому слід додати цей каталог до змінної оточення «Path».

Аналіз метрик виконується за допомогою утиліти CCCC, шлях до неї також необхідно додати до змінної оточення «Path».

Текст скрипта:

@rem= 'PERL for Windows NT -- ccperl must be in search path

@echo off

@echo %0 %1

ccperl %0 %1 %2 %3 %4 %5 %6 %7 %8 %9

pause

goto endofperl

@rem ';

use Win32;

use Cwd;

$cwdir = cwd();

print "Current directory: $cwdir \n";

DoCommand("cleartool find -all -name \"*.cpp\" -print");

sub DoCommand

{

my $cmd = shift;

$count=0;

my $line;

open(CMD, "$cmd 2>&1 |");

foreach $line (<CMD>)

# Ми виконали пошук, і перехоплюємо результат з консолі в змінну $ line. Обробляємо отримане значення: {

chop($line);

print "execution result: \"$line\" \n";

$end = substr ($line, length($line)-2, length($line));

if ($end ne "\\0")

# Перевіряємо закінчення рядка. Ми не будемо враховувати нульові версії, так як вони не містять інформації. Решта версій піддаються аналізу.

{

$tmpname = substr ($line, 0, index($line, "@@"));

print "$tmpname\n";

# У змінній $ tmpname ми сформували стандартне ім'я файлу, тобто завершується розширенням. Використовувана в прикладі утиліта розрахунку метрик не може оперувати назвами файлів, що містять повний шлях ClearCase, тобто назвами версій.

system("cleartool co -unr -nc -version \"$tmpname\" ");

system ("\"C:\\Program Files\\CCCC\\cccc.exe\" \"$tmpname\" --xml_outfile=c:\\temp\\cccc\\tmp.xm --outdir=c:\\temp\\cccc");

# Далі скасовуємо CheckOut, створюємо на версії атрибути, що містять відповідні значення метрик і додаємо прирощення до змінної покажчика рядка таблиці.

system("cleartool unco -rm \"$tmpname\" ");

# system("cleartool mkattr LOC $LOC \"$line \"");

# system("cleartool mkattr MVG $MVG \"$line \"");

# system("cleartool mkattr L_C $L_C \"$line \"");

};

}

close CMD;

}

Результат роботи скрипта збережеться в каталозі зазначеному в скрипті. В даному випадку це «c:\\temp\\cccc»