Oprogramowanie i wykorzystanie stacji roboczych. Wykład 2

Transkrypt

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

2 Kontrola wersji Wykład 2 p. 2/3 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.

3 Systemy kontroli wersji Wykład 2 p. 3/3 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.

4 Mechanizm automatycznej kontroli wersji Wykład 2 p. 4/3 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.

5 Wykład 2 p. 5/3 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.

6 CVS - tworzenie repozytorium Wykład 2 p. 6/3 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

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

8 Wykład 2 p. 8/3 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.

9 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 2 p. 9/3

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

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

12 Doxygen - dokumentowanie kodu Wykład 2 p. 12/3 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

13 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

14 Wykład 2 p. 14/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 */

15 Wykład 2 p. 15/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

16 Doxygen - przykład opisu funkcji Wykład 2 p. 16/3 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.

17 Doxygen - przykład Wykład 2 p. 17/3 /// 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() { }

18 Wykład 2 p. 18/3 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+

19 Testy jednostkowe Wykład 2 p. 19/3 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).

20 CppUnit - tworzenie testu Wykład 2 p. 20/3 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.

21 Debuger Wykład 2 p. 21/3 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 2 p. 22/3 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 2 p. 23/3 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 2 p. 24/3 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 2 p. 25/3

26 Eclipse Wykład 2 p. 26/3 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).

27 Wykład 2 p. 27/3 Ś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.

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

29 Wykład 2 p. 29/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.

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

31 Standardowe perspektywy Wykład 2 p. 31/3 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.

32 Projekty Wykład 2 p. 32/3 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).

33 Instalacja Eclipse Wykład 2 p. 33/3 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.