Oprogramowanie i wykorzystanie stacji roboczych. Wykład 11

Transkrypt

1 Wykład 11 p. 1/5 Oprogramowanie i wykorzystanie stacji roboczych Wykład 11 Dr inż. Tomasz Olas olas@icis.pcz.pl Instytut Informatyki Teoretycznej i Stosowanej Politechnika Częstochowska

2 Wykład 11 p. 2/5 Jam Jednym z ciekawszych projektów, które w przyszłości moga zastapić program make jest Jam. Zalety: Zwiększenie projektu nie prowadzi do tak drastycznego zwiększania się 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).

3 Wykład 11 p. 3/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 ;

4 Apache Ant (I) Wykład 11 p. 4/5 Apache Ant jest częścia projektu Apache Jakarta. Opiera się 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 języka 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 językach programowania (również w C++). Ant jest napisany całkowicie w Javie.

5 Wykład 11 p. 5/5 Apache Ant (II) Plik konfiguracyjny dla programu Ant jest plikiem w formacie XML. Zazwyczaj nosi nazwę build.xml. Składa się 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 się z dowolnej ilości wykonywanych zadań <task>. Jest to prosta czynność, która będzie 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ń.

6 Apache Ant - przykładowy plik build.xml Wykład 11 p. 6/5 <?xml version="1.0" encoding="iso "?> <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>

7 Kontrola wersji Wykład 11 p. 7/5 Kod ewoluuje. W czasie gdy projekt zmienia się z prototypu w wersję ostateczna przechodzi przez wiele cykli, w których programiści badaja nowe trendy, usuwaja błędy i stabilizuja swoje osiagnięcia. 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łędów. Często otrzymywany jest raport o błędzie w konkretnej wersji programu, podczas gdy jego kod uległ już zmianie. Czasem można rozpoznać, że bład został już usunięty, ale znacznie częściej nie ma takiej możliwości.

8 Systemy kontroli wersji Wykład 11 p. 8/5 Ręczna 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 się 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 odrębny 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 największe szanse na jego zastapienie.

9 Mechanizm automatycznej kontroli wersji Wykład 11 p. 9/5 Pracę z systemem kontroli wersji rozpoczyna się od rejestracji zbioru plików źródłowych, to znaczy nakazania systemowi rozpoczęcia ich archiwizacji wraz z historia zmian. Następnie 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.

10 Wykład 11 p. 10/5 CVS W przypadku CVS archiwum nazywa się repozytorium (ang. repository). Projekt znajdujacy się 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 (zwiększa) 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 wersję pakietu jako całości poprzez symboliczne nazwy zwane znacznikami (ang. tag). Podstawowym programem systemu CVS jest program o nazwie cvs.

11 CVS - tworzenie repozytorium Wykład 11 p. 11/5 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 niezbędne do prawidłowego funkcjonowania repozytorium. Utworzenie modułu: cvs import modulename vendorname release

12 CVS - przykładowa sesja Wykład 11 p. 12/5 Pobranie kopii modułu first: cvs checkout first Dokonanie zmian w plikach Zatwierdzenie zamian komenda comit: cvs commit -R first

13 Wykład 11 p. 13/5 Generowanie dokumentacji Istnieje szereg narzędzi wspierajacych proces tworzenia dokumentacji na podstawie komentarzy umieszczonych bezpośrednio w plikach źródłowych: javadoc doc++ doxygen Doxygen jest systemem dokumentowania kodu dla języków C++, C, Java, IDL (Corba, Microsoft i KDE-DCOP), PHP. Doxygen został utworzony dla systemu Linux, ale jest dostępny również na inne systemy Unix, jak również dla systemów Windows 9x/NT i Mac OS.

14 Wykład 11 p. 14/5 Koszty błędów Szacunkowe koszty błędu 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+

15 Testy jednostkowe Wykład 11 p. 15/5 Wyrażenie test jednostkowy należy rozumieć jako test pojedynczej jednostki, poprzez która będziemy rozumieli: funkcję, metodę lub klasę. Zadaniem takiego testu jest sprawdzenie czy dana jednostka działa poprawnie. Testy jednostkowe pozwalaja na wykrycie błędów (a przynajmniej ich części) u źródła, często w bardzo prostym kodzie, a więc 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łędó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ędziami programistycznymi).

16 CppUnit - tworzenie testu Wykład 11 p. 16/5 Dla każdej jednostki, która chcemy testować budujemy tzw. TestCase, czyli oddzielna klasę 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ę rozpoczynamy fraz a test, np. testoblicz. Z utworzonych metod budujemy jest zestaw testów - makra CPPUNIT_TEST_... Następnie uruchamiamy proces testowania. Wykonanie każdego testu poprzedzone jest automatycznym wykonaniem standardowej metody inicjalizujacej setup, a po zakończeniu testu wykonywana jest metoda teardown.

17 CppUnit - przykład (I) Wykład 11 p. 17/5 #ifndef OBLICZENIA_H #define OBLICZENIA_H class Obliczenia { public: int oblicz(int a, int b) { return a + b; } }; #endif /* OBLICZENIA_H */

18 CppUnit - przykład (II) Wykład 11 p. 18/5 #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);

19 CppUnit - przykład (III) Wykład 11 p. 19/5 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); }

20 CppUnit - przykład (IV) Wykład 11 p. 20/5 #include <cppunit/brieftestprogresslistener.h> #include <cppunit/compileroutputter.h> #include <cppunit/extensions/testfactoryregistry.h> #include <cppunit/testresult.h> #include <cppunit/testresultcollector.h> #include <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; }

21 Debuger Wykład 11 p. 21/5 Debugowanie jest procesem lokalizacji tych fragmentów programu, które powoduja jego nieprawidłowe działanie. Najczęściej w procesie tym wykorzystywane jest specjalne narzędzie zwane debugerem. W większoś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 się stało, w momencie zatrzymania (poprzez wyświetlenie wartości poszczególnych zmiennych), dokonywanie zmian w programie w czasie jego trwania.

22 Wykład 11 p. 22/5 GDB GNU Debuger (GDB) - debuger będacy częścia projektu GNU. Został utworzony w 1988 r. przez Richarda Stallmana. GDB działa w trybie tekstowym. Zdecydowana większość 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 pamięci (plik core), aktualnie działajacy proces (przez podanie PID).

23 GDB - przykładowa sesja (I) Wykład 11 p. 23/5 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ę) w funkcji main: (gdb) break main Uruchamiamy program: (gdb) run Wyświetlamy linię kodu otaczajacej miejsce zatrzymania: (gdb) list

24 GDB - przykładowa sesja (II) Wykład 11 p. 24/5 Wykonujemy kolejna linię 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 linię programu (rozwijajac funkcję): (gdb) step Ustawiamy wartość zmiennej result: (gdb) set result = 1 Kończymy pracę z debugerem: (gdb) quit

25 DDD Wykład 11 p. 25/5

26 Valgrind (I) Wykład 11 p. 26/5 Valgrind może służyć do sprawdzenia, czy program posiada poprawna liczbę odwołań przydzielajacych i zwalniajacych pamięć (new/delete, malloc/free). W tym celu uruchamiamy narzędzie Valgrind w następujacy 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)

27 Wykład 11 p. 27/5 Valgrind (II) Valgrind może służyć również do lokalizacji błędnych odwołań do pamięci. 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)

28 Wykład 11 p. 28/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)

29 Wykład 11 p. 29/5 Profiler Profilowanie jest w wielu wypadkach bardzo istotnym etapem tworzenia aplikacji. Zadaniem profilera jest zbadanie programu pod katem częstości i czasu wykonania poszczególnych funkcji, czy też linii kodu. Informacje uzyskane z etapu profilowania pozwalaja na wyodrębnienie fragmentów kodu programu, które powinny zostać zoptymalizowane. Dzięki temu moga zostać zlokalizowane i zlikwidowane tzw. waskie gardła oprogramowania (bottle neck).

30 gprof Wykład 11 p. 30/5 Jednym z narzędzi do profilowania aplikacji w systemach Linux jest narzędzie gprof (GNU GProf). W celu wykorzystania narzędzia 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 (utworzony zostanie plik gmon.out zawierajacy informacje dotyczace wykonania programu):./przyklad uruchomić narzędzie gprof w celu analizy wygenerowanego wcześniej pliku z profilem: gprof [opcje]./przyklad

31 gprof - tryby pracy Wykład 11 p. 31/5 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ędzia 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.

32 gprof - przykład Wykład 11 p. 32/5 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; }

33 gprof - profil płaski Wykład 11 p. 33/5 Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name f2(int, int) global constructors keyed to _Z f1() static_initialization_and_des

34 gprof - graf wywołań Wykład 11 p. 34/5 index % time self children called name <spontaneous> [1] main [1] /1 f1() [3] /1000 f1() [3] [2] f2(int, int) [2] /1 main [1] [3] f1() [3] /1000 f2(int, int) [2] /1 atexit [6] [8] global constructors keyed to _Z2f2ii [8] /1 static_initialization_and_destruct /1 global constructors keyed to _Z2f2ii [9] static_initialization_and_destruction_

35 gprof - wydruk kodu z komentarzem Wykład 11 p. 35/ > 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 -> }

36 KProf Wykład 11 p. 36/5

37 Doxygen Doxygen wspiera tworzenie dokumentów poprzez: Bezpośrednie generowanie dokumentacji z plików źródłowych. Dzięki 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 pomiędzy 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

38 Wykład 11 p. 38/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 ręcznie, lub poprzez graficzne narzędzie doxywizard. Uruchamianie programu Doxygen: doxygen <config-file>

39 Wykład 11 p. 39/5 Doxygen - opcje pliku konfiguracyjnego PROJECT NAME - nazwa projektu dla którego generowana jest dokumentacja, INPUT - katalogi gdzie znajduja się pliki źródłowe i nagłówkowe dla których będzie generowana dokumentacja, OUTPUT LANGUAGE - język w jakim ma być wygenerowana dokumentacja (polski - Polish). OUTPUT DIRECTORY - katalog w którym zostanie umieszczona dokumentacja, HTML OUTPUT - generowana będzie dokumentacja w formacie HTML oraz analogiczne opcje - RTF OUTPUT, LATEX OUTPUT oraz MAN OUTPUT.

40 Doxygen - dokumentowanie kodu Wykład 11 p. 40/5 Blok dokumentacji jest komentarzem w stylu języka C lub C++ z dodatkowymi znacznikami. Rozróżnia się 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ć trochę szczegółów (jeżeli potrzeba). Dobrym zwyczajem jest opisanie wszystkich parametrów np. funkcji używajac a zwracana nazwa opis

41 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

42 Wykład 11 p. 42/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 */

43 Wykład 11 p. 43/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

44 Doxygen - przykład opisu funkcji Wykład 11 p. 44/5 Przykład: /** * Funkcja nic nie robi (opis ogólny). Ta funkcja naprawdę nic nie robi * (opis szczegółowy). par1 naprawdę wszystko jedno, co podasz par2 też nie ma znaczenia zawsze -18 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.

45 Doxygen - przykład Wykład 11 p. 45/5 /// 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() { }

46 Eclipse Wykład 11 p. 46/5 Eclipse to udostępniona na zasadzie open source platforma służaca do integracji różego typu narzędzi (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 konfigurację 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).

47 Wykład 11 p. 47/5 Środowisko Eclipse Po uruchomieniu Eclipse pojawia się okno będace obszarem roboczym składajacym się 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 się w tzw. przestrzeni projektów. Podstawowymi elementami środowiska eclipse sa: edytor, widok, perspektywa.

48 Edytor Wykład 11 p. 48/5 Edytor (Editor) jest to część środowiska, która pozwala na edycję zasobów (plików) określonego typu.

49 Wykład 11 p. 49/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.

50 Perspektywa Wykład 11 p. 50/5 Perspektywa (Perspective) oznacza odpowiednia zapamiętana konfigurację edytorów i widoków, przywołana w momencie, gdy ma zostać wykonane określonego typu zadanie.

51 Standardowe perspektywy Wykład 11 p. 51/5 Bezpośrednio po zainstalowaniu środowiska Eclipse do dyspozycji użytkownika sa następujace perspektywy: Java, Debug, Java Browsing, Java Type Hierarchy, CVS REpository Exploring, Plug-in Development, Resource, Team Synchronizing.

52 Projekty Wykład 11 p. 52/5 Projekt jest podstawowa jednostka organizacyjna w Eclipse w stosunku do zawartych w nim elementów (plików). Projekt odpowiada najczęściej pojedynczej aplikacji. Wszystkie pliki tworzace aplikacje musza być zawarte w projekcie. Projekt może składać się 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).

53 Instalacja Eclipse Wykład 11 p. 53/5 Instalacja Eclipse polega na rozkompresowaniu pojedynczego pliku, który można pobrać ze strony (np. eclipse-sdk linux-gtk.tar.gz). W powstałym katalogu eclipse będzie znajdował się plik eclipse, który należy uruchomić. Do uruchomienia środowiska Eclipse niezbędna 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.