Oprogramowanie i wykorzystanie stacji roboczych Wykład 2

Oprogramowanie i wykorzystanie
stacji roboczych
Wykład 2
Dr inż. Tomasz Olas
[email protected]
Instytut Informatyki Teoretycznej i Stosowanej
Politechnika Cz˛estochowska
Wykład 2 – p. 1/3
Kontrola wersji
Kod ewoluuje. W czasie gdy projekt zmienia sie˛ z prototypu w wersje˛
ostateczna˛ przechodzi przez wiele cykli, w których programiści
badaja˛ nowe trendy, usuwaja˛ błedy
˛ i stabilizuja˛ swoje osiagni
˛ ecia.
˛
Ewolucja kodu powoduje wiele problemów, które moga˛ być źródłem
konfliktów i dodatkowej pracy, zmniejszajac
˛ w ten sposób
efektywność.
Jednym z ważniejszych problemów jest możliwość powrotu do starej
wersji.
Równie ważna jest możliwość rejestracji zmian.
Kolejnym problemem jest śledzenie błedów.
˛
Cz˛esto otrzymywany
jest raport o błedzie
˛
w konkretnej wersji programu, podczas gdy jego
kod uległ już zmianie. Czasem można rozpoznać, że bład
˛ został już
usuniety,
˛ ale znacznie cz˛eściej nie ma takiej możliwości.
Wykład 2 – p. 2/3
Systemy kontroli wersji
Reczna
˛
kontrola wersji - polega na okresowym tworzeniu kopii
bezpieczeństwa całego projektu. Do plików źródłowych dopisywane
sa˛ komentarze z historia˛ zmian.
Automatyczna kontrola wersji - polega na stosowaniu systemu
kontroli wersji (ang. version control system - VCS).
SCCS (CSSC) - powstał w 1980 roku i w chwili obecnej jest już przestarzały.
RCS - obecnie najszerzej stosowany. Doskonale nadaje sie˛ dla pojedynczych
programistów i małych grup projektowych. Operuje na pojedynczych plikach.
CVS - powstał na poczatku
˛
lat 90 jako front end systemu RCS, ale stosowany przez
niego model kontroli wersji kwalifikował go jako zupełnie odrebny
˛
projekt. Nowe
implementacje nie korzystaja˛ już z RCS. Operuje w przeciwieństwie do RCS na
katalogach, czy też całych projektach.
Subversion - rozwiazuje
˛
problemy zwiazane
˛
z systemem CVS i ma najwieksze
˛
szanse
na jego zastapienie.
˛
Wykład 2 – p. 3/3
Mechanizm automatycznej kontroli wersji
Prace˛ z systemem kontroli wersji rozpoczyna sie˛ od rejestracji zbioru
plików źródłowych, to znaczy nakazania systemowi rozpocz˛ecia ich
archiwizacji wraz z historia˛ zmian.
Nastepnie
˛
chcac
˛ wprowadzić zmiany do któregoś z plików projektu
należy go wymeldować (ang. check out).
Po zakończeniu pracy należy plik z powrotem zameldować (ang.
check in), co powoduje dokonanie zmian w archiwum.
Wykład 2 – p. 4/3
CVS
W przypadku CVS archiwum nazywa sie˛ repozytorium (ang.
repository).
Projekt znajdujacy
˛ sie˛ w repozytorium to moduł (ang. module).
Każdy plik w repozytorium ma przypisany numer wersji (ang.
revision number ). Za każdym razem, kiedy plik jest modyfikowany
(czyli zatwierdzane sa˛ zmiany), CVS zmienia (zwieksza)
˛
numer jego
wersji. Podczas dodawania pliku do repozytorium nadawany jest mu
numer 1.1. Pierwsze zatwierdzenie modyfikacji to numer 1.2, kolejne
to 1.3 itd.
Numery rewizji ida˛ niezależnie dla każdego pliku. Istnieje możliwość
zaznaczenia, że zbiór plików w konkretnych rewizjach stanowi
wersje˛ pakietu jako całości poprzez symboliczne nazwy zwane
znacznikami (ang. tag).
Podstawowym programem systemu CVS jest program o nazwie cvs.
Wykład 2 – p. 5/3
CVS - tworzenie repozytorium
Aby utworzyć repozytorium należy:
Ustawić zmienna˛ CVSROOT na odpowiednia˛ wartość:
export CVSROOT=katalog
Zainicjować cvs:
cvs init
W katalogu, który podaliśmy zostanie utworzony katalog
CVSROOT zawierajacy
˛ pliki niezbedne
˛
do prawidłowego
funkcjonowania repozytorium.
Utworzenie modułu:
cvs import modulename vendorname release
Wykład 2 – p. 6/3
CVS - przykładowa sesja
Pobranie kopii modułu first:
cvs checkout first
Dokonanie zmian w plikach
Zatwierdzenie zamian komenda˛ comit:
cvs commit -R first
Wykład 2 – p. 7/3
Generowanie dokumentacji
Istnieje szereg narz˛edzi wspierajacych
˛
proces tworzenia
dokumentacji na podstawie komentarzy umieszczonych
bezpośrednio w plikach źródłowych:
javadoc
doc++
doxygen
Doxygen jest systemem dokumentowania kodu dla jezyków
˛
C++, C, Java, IDL (Corba, Microsoft i KDE-DCOP), PHP.
Doxygen został utworzony dla systemu Linux, ale jest
dostepny
˛
również na inne systemy Unix, jak również dla
systemów Windows 9x/NT i Mac OS.
Wykład 2 – p. 8/3
Doxygen
Doxygen wspiera tworzenie dokumentów poprzez:
Bezpośrednie generowanie dokumentacji z plików źródłowych.
Dzieki
˛ temu łatwiejsze jest utrzymywanie spójności
dokumentacji z plikami źródłowymi.
Umożliwia generowanie dokumentacji „on-line” (HTML), jak
również plików w formacie L A T E X ze zbioru
udokumentowanych plików źródłowych. Umożliwia również
generowanie plików z dokumentacja˛ w formatach RTF,
(MS-Word), PostScript, PDF, oraz plików pomocy systemu Unix
(man pages).
Doxygen może zostać tak skonfigurowany, że jest możliwe
tworzenie struktury z nieudokumentowanych plików źródłowych.
Relacje pomiedzy
˛
poszczególnymi elementami projektu moga˛
być automatycznie tworzone i wyświetlane w postaci grafu
zależności oraz diagramu dziedziczenia.
Doxygen może zostać również użyty do tworzenia „normalnych”
dokumentów.
Wykład 2 – p. 9/3
Doxygen - użycie
Doxygen używa pliku konfiguracyjnego do określenia swoich
ustawień. Każdy projekt powinien posiadać swój własny plik
konfiguracyjny.
Generowanie pliku konfiguracyjnego:
doxygen -g <config-file>
Format pliku konfiguracyjnego:
TAGNAME = VALUE or
TAGNAME = VALUE1 VALUE2 ...
Plik konfiguracyjny może być edytowany „recznie”,
˛
lub poprzez
graficzne narz˛edzie doxywizard.
Uruchamianie programu Doxygen:
doxygen <config-file>
Wykład 2 – p. 10/3
Doxygen - opcje pliku konfiguracyjnego
PROJECT NAME - nazwa projektu dla którego generowana jest
dokumentacja,
INPUT - katalogi gdzie znajduja˛ sie˛ pliki źródłowe i nagłówkowe dla
których bedzie
˛
generowana dokumentacja,
OUTPUT LANGUAGE - jezyk
˛
w jakim ma być wygenerowana
dokumentacja (polski - Polish).
OUTPUT DIRECTORY - katalog w którym zostanie umieszczona
dokumentacja,
HTML OUTPUT - generowana bedzie
˛
dokumentacja w formacie HTML
oraz analogiczne opcje - RTF OUTPUT, LATEX OUTPUT oraz
MAN OUTPUT.
Wykład 2 – p. 11/3
Doxygen - dokumentowanie kodu
Blok dokumentacji jest komentarzem w stylu jezyka
˛
C lub C++ z
dodatkowymi znacznikami.
Rozróżnia sie˛ dwa rodzaje opisów:
opis skrócony (brief description)
opis szczegółowy (detailed description)
Komentarz umieszczamy zazwyczaj przed opisywana˛ funkcja,
struktura˛ danych itp.
Pierwsze zdanie (do kropki), służacy
˛ jako krótki ogólny opis. Potem
można umieścić troche˛ szczegółów (jeżeli potrzeba). Dobrym
zwyczajem jest opisanie wszystkich parametrów np. funkcji używajac
˛
konstrukcji @param, a zwracana˛ wartość poprzez @return:
@param nazwa opis_parametru
@return opis
Wykład 2 – p. 12/3
Doxygen - opisy szczegółowe
Formaty opisów szczegółowych:
/**
* ... opis szczegółowy ...
*/
/*!
* ... opis szczegółowy ...
*/
/*!
... opis szczegółowy ...
*/
///
/// ... opis szczegółowy ...
///
//!
//!... opis szczegółowy ...
//!
/////////////////////////////////////////////////
/// ... opis szczegółowy ...
/////////////////////////////////////////////////
Wykład 2 – p. 13/3
Doxygen - opisy skrócone
Format opisu skróconego może być jednym z poniższych:
/*! \brief opis skrócony
* kontynuacja opisu skróconego
*
* opis szczegółowy
* kontynuacja opisu szczegółowego
*/
/// opis skrócony
/** opis szczegółowy */
Wykład 2 – p. 14/3
Doxygen - opis zmiennych
Opis do zmiennych może być umieszczony za deklaracja˛ zmiennej:
int var; /*!< opis szczegółowy */
int var; /**< opis szczegółowy */
int var; //!< opis szczegółowy
//!<
int var; ///< opis szczegółowy
///<
int var; //!< opis skrócony
int var; ///< opis skrócony
Wykład 2 – p. 15/3
Doxygen - przykład opisu funkcji
Przykład:
/**
* Funkcja nic nie robi (opis ogólny). Ta funkcja naprawd˛
e nic nie robi
* (opis szczegółowy).
* @param par1 naprawd˛
e wszystko jedno, co podasz
* @param par2 też nie ma znaczenia
* @return zawsze -18
* @see coś_robi
*/
int nic_nie_robi(int par1, char *par2)
{
return -18;
}
Opis funkcji może być umieszczony zarówno przy deklaracji, jak
również przy definicji funkcji.
Wykład 2 – p. 16/3
Doxygen - przykład
/// Opis dla pierwszej klasy
class First
{
};
/// Opis skrócony dla Second
/** Opis szczegółowy dla Second */
class Second: public First
{
public:
/// Opis zmiennej wartosc.
double wartosc;
Second();
};
/// Opis metody przy definicji.
Second::Second()
{
}
Wykład 2 – p. 17/3
Koszty błedów
˛
Szacunkowe koszty błedu
˛ w różnych fazach projektu:
Faza
Koszt
Analiza
$1
Projekt
$5
Kodowanie
$10
Testy jednostkowe
$15
Testy integracyjne
$22
Testy systemowe
$50
Po wdrożeniu
$100+
Wykład 2 – p. 18/3
Testy jednostkowe
Wyrażenie „test jednostkowy” należy rozumieć jako test pojedynczej
jednostki, poprzez która˛ bedziemy
˛
rozumieli: funkcje,
˛ metode˛ lub
klase.
˛
Zadaniem takiego testu jest sprawdzenie czy dana jednostka działa
poprawnie.
Testy jednostkowe pozwalaja˛ na wykrycie błedów
˛
(a przynajmniej ich
cz˛eści) „u źródła”, cz˛esto w bardzo prostym kodzie, a wiec
˛ ich
poprawienie może być znacznie szybsze i mniej kosztowne.
Testy jednostkowe powinny być wykonywane „cały czas” wraz ze
zmiana˛ kodu programu aby sprawdzić, czy zmiany wynikajace,
˛
np. z
poprawienia wykrytych błedów
˛
nie wprowadziły nowych usterek.
Aby było to możliwe, to testy powinny być łatwe do wykonania czyli
zautomatyzowane (może być dodatkowo zintegrowany z innymi
narz˛edziami programistycznymi).
Wykład 2 – p. 19/3
CppUnit - tworzenie testu
Dla każdej jednostki, która˛ chcemy testować budujemy tzw.
TestCase, czyli oddzielna˛ klase˛ grupujac
˛ a˛ wszystkie testy zwiazane
˛
z dana˛ jednostka.
˛
Testy tworzymy wykorzystujac
˛ makra CPPUNIT_ASSERT_....
Stworzenie pojedynczego testu polega na umieszczeniu w tej klasie
nowej metody. Jej nazw˛e rozpoczynamy fraza˛ test, np. testOblicz.
Z utworzonych metod budujemy jest zestaw testów - makra
CPPUNIT_TEST_....
Nastepnie
˛
uruchamiamy proces testowania. Wykonanie każdego
testu poprzedzone jest automatycznym wykonaniem standardowej
metody inicjalizujacej
˛ setUp, a po zakończeniu testu wykonywana
jest metoda tearDown.
Wykład 2 – p. 20/3
Debuger
Debugowanie jest procesem lokalizacji tych fragmentów programu,
które powoduja˛ jego nieprawidłowe działanie.
Najcz˛eściej w procesie tym wykorzystywane jest specjalne narz˛edzie
zwane debugerem.
W wiekszości
˛
przypadków debuger pozwala na:
uruchomienie programu, określajac
˛ warunki, które moga˛
wpłynać
˛ na jego działanie,
zatrzymanie programu w określonych okolicznościach (poprzez
ustawienie tzw. pułapek (breakpoints),
krokowe wykonanie programu (linia po linii),
sprawdzenie co sie˛ stało, w momencie zatrzymania (poprzez
wyświetlenie wartości poszczególnych zmiennych),
dokonywanie zmian w programie w czasie jego trwania.
Wykład 2 – p. 21/3
GDB
GNU Debuger (GDB) - debuger bed
˛ acy
˛ cz˛eścia˛ projektu GNU.
Został utworzony w 1988 r. przez Richarda Stallmana.
GDB działa w trybie tekstowym.
Zdecydowana wiekszość
˛
zintegrowanych środowisk
programistycznych posiadajacych
˛
interfejs graficzny potrafi
prezentować wyniki działania GDB.
stnieja˛ nakładki na GDB (front-end) pozwalajace
˛ wykorzystywać
jego funkcjonalność przy użyciu graficznego interfejsu użytkownika
(GNU Visual Debugger, Data Display Debugger).
Przy użyciu gdb możemy debugować:
program w czasie działania,
na podstawie zrzutu pamieci
˛ (plik core),
aktualnie działajacy
˛ proces (przez podanie PID).
Wykład 2 – p. 22/3
GDB - przykładowa sesja (I)
Kompilujemy program (lub debugowane pliki źródłowe) z opcja˛
kompilatora -g:
g++ -g -o test test.cpp
Uruchamiamy debuger z parametrem określajacym
˛
debugowany
program: gdb test
Ustawiamy breakpoint (pułapk˛e) w funkcji main:
(gdb) break main
Uruchamiamy program:
(gdb) run
Wyświetlamy linie˛ kodu otaczajacej
˛ miejsce zatrzymania:
(gdb) list
Wykład 2 – p. 23/3
GDB - przykładowa sesja (II)
Wykonujemy kolejna˛ linie˛ programu (bez rozwijania funkcji):
(gdb) next
Wyświetlamy wartość zmiennej a:
(gdb) print a
Wymuszamy śledzenie wartości zmiennej result:
(gdb) watch result
Wykonujemy kolejna˛ linie˛ programu (rozwijajac
˛ funkcje):
˛
(gdb) step
Ustawiamy wartość zmiennej result:
(gdb) set result = 1
Kończymy prace˛ z debugerem:
(gdb) quit
Wykład 2 – p. 24/3
DDD
Wykład 2 – p. 25/3
Eclipse
Eclipse to udostepniona
˛
na zasadzie open source platforma służaca
˛
do integracji różego typu narz˛edzi (głównie programistycznych, ale
nie tylko).
Działaja˛ one w ramach jednego środowiska, co sprawia, że
użytkownik przekonany jest, że ma doczynienia z zaawansowanym,
ale pojedynczym programem.
W prosty sposób środowisko Eclipse może być dostosowywane do
potrzeb użytkownika poprzez konfiguracje˛ polegajac
˛ a˛ w głównej
mierze na dodawaniu modułów (pluginów) dostosowanych do
realizacji poszczególnych zadań.
Pierwsza wersja środowiska Eclipse została zaprezentowana w
listopadzie 2001 roku przez IBM oraz Object Technology
International (OTI).
Wykład 2 – p. 26/3
Środowisko Eclipse
Po uruchomieniu Eclipse pojawia sie˛ okno bed
˛ ace
˛ obszarem
roboczym składajacym
˛
sie˛ z kilku paneli.
Służa˛ one do edycji poszczególnych plików projektu oraz do
prezentacji struktury projektu i jego elementów.
Projekty znajduja˛ sie˛ w tzw. przestrzeni projektów.
Podstawowymi elementami środowiska eclipse sa:
˛
edytor,
widok,
perspektywa.
Wykład 2 – p. 27/3
Edytor
Edytor (Editor ) jest to cz˛eść środowiska, która pozwala na edycje˛
zasobów (plików) określonego typu.
Wykład 2 – p. 28/3
Widok
Widok (View) służy zazwyczaj do nawigacji w ramach projektu badź
˛
do wyświetlania informacji o strukturze jego elementów lub różnych
komunikatów.
Wykład 2 – p. 29/3
Perspektywa
Perspektywa (Perspective) oznacza odpowiednia˛ zapamietan
˛
a˛
konfiguracje˛ edytorów i widoków, przywołana˛ w momencie, gdy ma
zostać wykonane określonego typu zadanie.
Wykład 2 – p. 30/3
Standardowe perspektywy
Bezpośrednio po zainstalowaniu środowiska Eclipse do dyspozycji
użytkownika sa˛ nastepuj
˛ ace
˛ perspektywy:
Java,
Debug,
Java Browsing,
Java Type Hierarchy,
CVS REpository Exploring,
Plug-in Development,
Resource,
Team Synchronizing.
Wykład 2 – p. 31/3
Projekty
Projekt jest podstawowa˛ jednostka˛ organizacyjna˛ w Eclipse w
stosunku do zawartych w nim elementów (plików).
Projekt odpowiada najcz˛eściej pojedynczej aplikacji.
Wszystkie pliki tworzace
˛ aplikacje musza˛ być zawarte w projekcie.
Projekt może składać sie˛ z jednego lub wielu folderów, które moga˛
być zagnieżdzone.
Projekt opisany jest zestawem parametrów, które dotycza˛ sposobu
kompilacji, dołaczonych
˛
bibliotek, ścieżek, itp.
Projekty zgrupowane sa˛ w tzw. przestrzeni projektów (workspace).
Wykład 2 – p. 32/3
Instalacja Eclipse
Instalacja Eclipse polega na rozkompresowaniu pojedynczego pliku,
który można pobrać ze strony www.eclipse.org (np.
eclipse-SDK-3.1.2-linux-gtk.tar.gz).
W powstałym katalogu eclipse bedzie
˛
znajdował sie˛ plik eclipse,
który należy uruchomić.
Do uruchomienia środowiska Eclipse niezbedna
˛
jest maszyna
wirtualna javy (JRE).
JRE firmy IBM można również pobrać ze strony Eclipse (np.
IBMJava2-SDK-142.tgz) - po rozkompresowaniu należy do ścieżki
przeszukiwań dla plików wykonywalnych dodać podkatalog jre/bin.
Wykład 2 – p. 33/3