Oprogramowanie i wykorzystanie stacji roboczych Wykład 11

Oprogramowanie i wykorzystanie
stacji roboczych
Wykład 11
Dr inż. Tomasz Olas
[email protected]
Instytut Informatyki Teoretycznej i Stosowanej
Politechnika Cz˛estochowska
Wykład 11 – p. 1/5
Jam
Jednym z ciekawszych projektów, które w przyszłości moga˛ zastapić
˛
program make jest Jam.
Zalety:
Zwiekszenie
˛
projektu nie prowadzi do tak drastycznego zwiekszania
˛
sie˛ pliku
konfiguracyjnego jak ma to miejsce w przypadku programu make.
Automatycznie generowane sa˛ zależności od plików nagłówkowych.
Jam buduje duże projekty rozmieszczone w wielu katalogach za jednym podejściem,
bez rekursywnego nawracania jak to robi make, śledzac
˛ wszystkie pliki jednocześnie.
Może pracować na wielu procesorach.
Jam jest mały (np. 92 kB), praktycznie nie obciaża
˛ procesora, i nie tworzy dodatkowych
plików (jak np. nmake, SunOS make).
Może być dowolnie konfigurowany poprzez tzw. reguły (Jamrules).
Wykład 11 – p. 2/5
Jam kontra Make
Plik konfiguracyjny dla programu Make:
progam: data.o main.o io.o
gcc data.o main.o io.o -o progam
data.o: data.c
gcc -c data.c
main.o: main.c
gcc -c main.c
io.o: io.c
gcc -c io.c
io.o: io.h
main.o: io.h data.h
data.o: data.h io.h
Plik konfiguracyjny dla programu Jam:
Main progam : data.c main.c io.c ;
Wykład 11 – p. 3/5
Apache Ant (I)
Apache Ant jest cz˛eścia˛ projektu Apache Jakarta.
Opiera sie˛ na podobnym założeniu co make jeżeli chodzi o
zależności i reguły, ale nie zakłada że sa˛ to pliki i że głównym celem
reguł jest uaktualnienie zadań.
Używa jezyka
˛
XML.
Jest w pełni niezależny od platformy.
Został napisany z myśla˛ o Javie, ale posiada również wsparcie do
tworzenia projektu w innych jezykach
˛
programowania (również w
C++).
Ant jest napisany całkowicie w Javie.
Wykład 11 – p. 4/5
Apache Ant (II)
Plik konfiguracyjny dla programu Ant jest plikiem w formacie XML.
Zazwyczaj nosi nazw˛e build.xml.
Składa sie˛ on z różnej ilości różnych tagów, zwanych <target> (cel).
Może to być np. kompilacja, utworzenie archiwum, utworzenie
dokumentacji czy też wysłanie poczty elektronicznej.
Każdy cel składa sie˛ z dowolnej ilości wykonywanych zadań <task>.
Jest to prosta czynność, która bedzie
˛
wykonywana, np. tworzenie
katalogu, kopiowanie pliku, kompilacja kodu źródłowego. Każde
zadanie może posiadać parametry i być zależne od innych zadań.
Wykład 11 – p. 5/5
Apache Ant - przykładowy plik build.xml
<?xml version="1.0" encoding="iso-8859-2"?>
<project name="first" basedir="." default="compile">
<path id="log4jclasspath">
<pathelement location="${basedir}"/>
<pathelement location="/../wspolne.jar"/>
</path>
<target name="compile">
<javac srcdir="."
classpathref="classpath"
/>
</target>
<target name="run">
<java
classpathref=""
classname="org.gridwise.Simple"
/>
</target>
</project>
Wykład 11 – p. 6/5
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 11 – p. 7/5
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 11 – p. 8/5
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 11 – p. 9/5
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 11 – p. 10/5
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 11 – p. 11/5
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 11 – p. 12/5
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 11 – p. 13/5
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 11 – p. 14/5
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 11 – p. 15/5
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 11 – p. 16/5
CppUnit - przykład (I)
#ifndef OBLICZENIA_H
#define OBLICZENIA_H
class Obliczenia
{
public:
int oblicz(int a, int b) {
return a + b;
}
};
#endif /* OBLICZENIA_H */
Wykład 11 – p. 17/5
CppUnit - przykład (II)
#include "obliczenia.h"
#include <cppunit/TestCase.h>
#include <cppunit/extensions/HelperMacros.h>
class ObliczeniaTest : public CppUnit::TestCase
{
private:
CPPUNIT_TEST_SUITE( ObliczeniaTest );
CPPUNIT_TEST( testOblicz );
CPPUNIT_TEST_SUITE_END();
public:
void testOblicz();
};
CPPUNIT_TEST_SUITE_REGISTRATION(ObliczeniaTest);
Wykład 11 – p. 18/5
CppUnit - przykład (III)
void ObliczeniaTest::testOblicz()
{
Obliczenia obl;
CPPUNIT_ASSERT(obl.oblicz(1, 1) == 2);
CPPUNIT_ASSERT(obl.oblicz(0, 0) == 0);
CPPUNIT_ASSERT(obl.oblicz(-1, -1) == -2);
}
Wykład 11 – p. 19/5
CppUnit - przykład (IV)
#include
#include
#include
#include
#include
#include
<cppunit/BriefTestProgressListener.h>
<cppunit/CompilerOutputter.h>
<cppunit/extensions/TestFactoryRegistry.h>
<cppunit/TestResult.h>
<cppunit/TestResultCollector.h>
<cppunit/TestRunner.h>
int main( int argc, char* argv[] ) {
CPPUNIT_NS::TestResult controller;
CPPUNIT_NS::TestResultCollector result;
controller.addListener( &result );
CPPUNIT_NS::BriefTestProgressListener progress;
controller.addListener( &progress );
CPPUNIT_NS::TestRunner runner;
runner.addTest( CPPUNIT_NS::TestFactoryRegistry::getRegistry().makeTest() );
runner.run( controller );
CPPUNIT_NS::CompilerOutputter outputter( &result, std::cerr );
outputter.write();
return result.wasSuccessful() ? 0 : 1;
}
Wykład 11 – p. 20/5
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 11 – p. 21/5
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 11 – p. 22/5
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 11 – p. 23/5
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 11 – p. 24/5
DDD
Wykład 11 – p. 25/5
Valgrind (I)
Valgrind może służyć do sprawdzenia, czy program posiada
poprawna˛ liczbe˛ odwołań przydzielajacych
˛
i zwalniajacych
˛
pamieć
˛
(new/delete, malloc/free).
W tym celu uruchamiamy narz˛edzie Valgrind w nastepuj
˛ acy
˛ sposób:
valgrind --tool=memcheck --leak-check=yes przyklad1
Dla przykładu:
int main()
{
char *x = new char[10];
return 0;
}
Otrzymamy:
==20871== 10 bytes in 1 blocks are definitely lost in loss record 1 of 1
==20871==
at 0x4C214F7: operator new[](unsigned long) (in /usr/lib64/valgrin
==20871==
by 0x400629: main (przyklad1.cpp:3)
Wykład 11 – p. 26/5
Valgrind (II)
Valgrind może służyć również do lokalizacji błednych
˛
odwołań do
pamieci.
˛
Dla przykładu:
int main()
{
char *x = new char[10];
x[10] = ’a’;
return 0;
}
Otrzymamy:
==21196== Invalid write of size 1
==21196==
at 0x400676: main (przyklad2.cpp:4)
==21196== Address 0x58f703a is 0 bytes after a block of size 10 alloc’d
==21196==
at 0x4C214F7: operator new[](unsigned long) (in /usr/lib64/valgrin
==21196==
by 0x400669: main (przyklad2.cpp:3)
Wykład 11 – p. 27/5
Valgrind (III)
Valgrind może służyć również do wykrywania przypadków użycia
niezainicjowanych zmiennych.
Dla przykładu:
int main()
{
int x;
if(x == 0)
std::cout << "x jest rowne zero" << std::endl;
return 0;
}
Otrzymamy:
==21246== Conditional jump or move depends on uninitialised value(s)
==21246==
at 0x4008F0: main (przyklad3.cpp:6)
Wykład 11 – p. 28/5
Profiler
Profilowanie jest w wielu wypadkach bardzo istotnym etapem
tworzenia aplikacji.
Zadaniem profilera jest zbadanie programu pod katem
˛
cz˛estości i
czasu wykonania poszczególnych funkcji, czy też linii kodu.
Informacje uzyskane z etapu profilowania pozwalaja˛ na
wyodrebnienie
˛
fragmentów kodu programu, które powinny zostać
zoptymalizowane.
Dzieki
˛ temu moga˛ zostać zlokalizowane i zlikwidowane tzw. waskie
˛
gardła oprogramowania (bottle neck).
Wykład 11 – p. 29/5
gprof
Jednym z narz˛edzi do profilowania aplikacji w systemach Linux jest
narz˛edzie gprof (GNU GProf).
W celu wykorzystania narz˛edzia gprof należy:
skompilować program w taki sposób, aby dodane zostały
informacje dla profilera:
g++ -pg -g przyklad.cpp -o przyklad
uruchomić wcześniej odpowiednio skompilowany program
˛ informacje
(utworzony zostanie plik gmon.out zawierajacy
dotyczace
˛ wykonania programu):
./przyklad
uruchomić narz˛edzie gprof w celu analizy wygenerowanego
wcześniej pliku z profilem:
gprof [opcje] ./przyklad
Wykład 11 – p. 30/5
gprof - tryby pracy
GNU Gprof może pracować w jednym z trzech trybów:
profil płaski,
graf wywołań,
wydruk kodu wraz z „komentarzem” (profilowanie pojedynczych
linii).
Główne opcje narz˛edzia gprof:
-A - włacza
˛
wydruk kodu z komentarzem,
-J - wyłacza
˛
wydruk kodu z komentarzem,
-p - włacza płaski profil,
-P - wyłacza płaski profil,
-q - włacza graf wywołań,
-Q - wyłacza graf wywołań.
Domyślnym zestawem opcji jest -p -q.
Wykład 11 – p. 31/5
gprof - przykład
double f2(int a, int b) {
double r = 0.0;
for (int i = 0; i < 10000; ++i)
r += b/a + sin(0.5) + cos(0.7);
return r;
}
double f1() {
double res = 0.0;
for (int i = 1; i <= 100; ++i)
for (int j = 1; j <= 10; ++j)
res += f2(i, j);
return res;
}
int main() {
std::cout << f1() << std::endl;
return 0;
}
Wykład 11 – p. 32/5
gprof - profil płaski
Each sample counts as 0.01 seconds.
%
cumulative
self
self
time
seconds
seconds
calls ms/call
100.83
0.26
0.26
1000
0.26
0.00
0.26
0.00
1
0.00
0.00
0.26
0.00
1
0.00
0.00
0.26
0.00
1
0.00
total
ms/call
0.26
0.00
262.15
0.00
name
f2(int, int)
global constructors keyed to _Z
f1()
__static_initialization_and_des
Wykład 11 – p. 33/5
gprof - graf wywołań
index % time
self
children
called
name
<spontaneous>
[1]
100.0
0.00
0.26
main [1]
0.00
0.26
1/1
f1() [3]
----------------------------------------------0.26
0.00
1000/1000
f1() [3]
[2]
100.0
0.26
0.00
1000
f2(int, int) [2]
----------------------------------------------0.00
0.26
1/1
main [1]
[3]
100.0
0.00
0.26
1
f1() [3]
0.26
0.00
1000/1000
f2(int, int) [2]
----------------------------------------------0.00
0.00
1/1
atexit [6]
[8]
0.0
0.00
0.00
1
global constructors keyed to _Z2f2ii [8]
0.00
0.00
1/1
__static_initialization_and_destruct
----------------------------------------------0.00
0.00
1/1
global constructors keyed to _Z2f2ii
[9]
0.0
0.00
0.00
1
__static_initialization_and_destruction_
-----------------------------------------------
Wykład 11 – p. 34/5
gprof - wydruk kodu z komentarzem
1000 -> double f2(int a, int b){
double r = 0.0;
for (int i = 0; i < 10000; ++i)
r += b/a + sin(0.5) + cos(0.7);
return r;
}
1 -> double f1(){
double res = 0.0;
for (int i = 1; i <= 100; ++i)
for (int j = 1; j <= 10; ++j)
res += f2(i, j);
return res;
}
##### -> int main(){
std::cout << f1() << std::endl;
return 0;
1 -> }
Wykład 11 – p. 35/5
KProf
Wykład 11 – p. 36/5
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 11 – p. 37/5
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 11 – p. 38/5
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 11 – p. 39/5
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 11 – p. 40/5
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 11 – p. 41/5
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 11 – p. 42/5
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 11 – p. 43/5
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 11 – p. 44/5
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 11 – p. 45/5
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 11 – p. 46/5
Ś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 11 – p. 47/5
Edytor
Edytor (Editor ) jest to cz˛eść środowiska, która pozwala na edycje˛
zasobów (plików) określonego typu.
Wykład 11 – p. 48/5
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 11 – p. 49/5
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 11 – p. 50/5
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 11 – p. 51/5
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 11 – p. 52/5
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 11 – p. 53/5