Katedra InŜynierii Oprogramowania. InŜynieria Oprogramowania i Baz Danych. Systemy kontroli wersji i zarządzania konfiguracją

Transkrypt

1 Katedra InŜynierii Oprogramowania InŜynieria Oprogramowania i Baz Danych Konrad Bielik Nr albumu: 5898 Systemy kontroli wersji i zarządzania konfiguracją Praca magisterska napisana pod kierunkiem dr inŝ. Włodzimierza Dąbrowskiego Warszawa, styczeń 2010

2 Podpis promotora pracy Podpis kierownika katedry

3 Systemy kontroli wersji i zarządzania konfiguracją Streszczenie Praca dotyczy zagadnień związanych z tematyką zarządzania konfiguracją oprogramowania i kontroli wersji. Opisuje podejście do procesów kontroli zmiany na tle całego cyklu Ŝycia oprogramowania. Przestawione zostały najczęstsze problemy występujące w niemal kaŝdym projekcie informatycznym takie jak trudności natury komunikacyjnej, problem współdzielonych danych oraz nieodłączna potrzeba wprowadzania zmian podczas całego cyklu Ŝycia oprogramowania. W kontekście przedstawionych problemów ukazane zostało rozwiązanie wielu z nich, poprzez wprowadzenie procesów takich jak identyfikacja pozycji konfiguracji, kontrola wersji, kontrola zmiany oraz wprowadzenie przeglądów i audytów. Dzięki implementacji wprowadzeniu i propagacji dokumentu, jakim jest plan zarządzania konfiguracją moŝna osiągnąć takie korzyści płynące z zarządzania zmianą jak łatwiejsze radzenie sobie z komplikacją poszczególnych modyfikacji, zwiększona odporność na błędy i lepsza jakość produktu końcowego. PoniewaŜ nieodłącznym elementem solidnych mechanizmów kontroli konfiguracji, jest odpowiednie oprogramowanie, jeden z rozdziałów został poświęcony opisowi ich funkcji, istniejących systemów zarówno w ujęciu ogólnym, jak teŝ na przykładzie konkretnych rozwiązań. Mimo mnogości dostępnych pakietów zarówno w obszarze rynku komercyjnego, jak teŝ produktów darmowych nie istnieje rozwiązanie idealne łączące cechy kosztownych, drogich w utrzymaniu systemów z jednoczesną wydajnością i prostotą narzędzi udostępnianych na zasadach open-source. Przedstawiony prototyp systemu wspomagającego procesy zarządzania konfiguracją, jest próbą stworzenia narzędzia pozwalającego zaadoptować je do dowolnego modelu danych, przy jednoczesnej integracji z repozytorium kodu i jednoczesnym zachowaniu prostoty interfejsu uŝytkownika oraz braku konieczności tworzenia skomplikowanej infrastruktury takiej jak duŝa liczba serwerów hostujących dane usługi. Version control and configuration management systems Abstract This M.Cs. discusses issues concerning with software configuration management and version control. It describes processes of change control compared to software life cycle. Common problems related to almost every development project where introduced, including communication difficulties, shared data problem and change management in general. Many of these problems may be resolved by introducing several processes such as configuration items identification, code version control, peer reviews and audits. Creating and implementing configuration management plan, helps assuming complication of changes, reducing number of errors and delivering better quality of end product. Properly selected software is inseparable element of good configuration management processes. One of chapter describes common tools and gives detailed examples of most popular ones. Despite the large selection of commercial products as well as open source software there is no one ideal solution combining functionality of expensive systems and simplicity of freeware tools. 3

4 This paper also introduces simple configuration management system prototype which, can be adopted to almost every data model, additionally allowing integration with code repository. Installation and usage does not require complicated infrastructure and the user interface is relatively simple. 4

5 Spis treści 1. WSTĘP CEL PRACY REZULTATY PRACY ORGANIZACJA PRACY ZARZĄDZANIE KONFIGURACJĄ W KONTEKŚCIE PROCESU WYTWARZANIA OPROGRAMOWANIA INFORMACJE WSTĘPNE I RYS HISTORYCZNY OGÓLNA CHARAKTERYSTYKA PROCESU WYTWARZANIA OPROGRAMOWANIA Informacje wstępne Cykl Ŝycia oprogramowania Charakterystyka faz cyklu Ŝycia PROBLEMY ZWIĄZANE Z WYTWARZANIEM OPROGRAMOWANIA Problem komunikacyjny Problem współdzielonych danych i utrzymania wielu wersji Zmienność i złoŝoność procesu tworzenia oprogramowania KORZYŚCI WYNIKAJĄCE Z WPROWADZENIA ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA CHARAKTERYSTYKA PROCESÓW ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA INFORMACJE WSTĘPNE Wersja bazowa (baseline) Wprowadzanie i pobieranie komponentów (checkin, checkout) Warianty i wersje Gałęzie i programowanie współbieŝne Wersje źródłowe i ich pochodne Wydania (release) Przyrostowe przechowywanie informacji Repozytorium danych systemu zarządzania konfiguracją FAZY IMPLEMENTACJI ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA IDENTYFIKACJA POZYCJI KONFIGURACJI KONTROLA ZMIAN KONFIGURACJI OKREŚLANIE STATUSU KONFIGURACJI ZARZĄDZANIE KONFIGURACJĄ OPROGRAMOWANIA WEDŁUG METODYK I STANDARDÓW NARZĘDZIA WSPOMAGAJĄCE PROCESY ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA OGÓLNA CHARAKTERYSTYKA NARZĘDZI ZKO FUNKCJE NARZĘDZI ZKO ARCHITEKTURA SYSTEMÓW ZARZĄDZANIA WERSJAMI CHARAKTERYSTYKA WYBRANYCH NARZĘDZI Concurrent version system (CVS) Subversion (SVN) Git IBM Rational ClearCase / ClearQuest OPIS NARZĘDZI UśYTYCH DO REALIZACJI CZĘŚCI PRAKTYCZNEJ JAVA Język Java Środowisko programistyczne Eclipse TECHNOLOGIE MICROSOFT Język C# Środowisko programistyczne Microsoft Visual Studio Windows Presentation Foundation OBIEKTOWA BAZA DANYCH ODRA

6 5.4. INNE NARZĘDZIA I BIBLIOTEKI Biblioteka SVNKit Apache MINA Apache Commons PROTOTYP NARZĘDZIA ZKO ZAŁOśENIA I ZARYS ROZWIĄZANIA MODEL KOMUNIKACJI OPIS FUNKCJONALNOŚCI Przygotowanie nowego scenariusza Rozpoczęcie pracy z klientem GUI Przeglądanie i modyfikacja obiektów zmiany Repozytorium kodu SZCZEGÓŁY IMPLEMENTACYJNE Funkcje udostępniane przez serwer Połączenie z systemem Odra Połączenie z repozytorium kodu Protokół komunikacyjny i serializacja danych Klient GUI NAPOTKANE PROBLEMY I MOśLIWOŚCI ROZSZERZENIA PODSUMOWANIE BIBLIOGRAFIA DODATEK A SPIS RYSUNKÓW DODATEK B ZAWARTOŚĆ WERSJI ELEKTRONICZNEJ B.1 STRUKTURA KATALOGÓW B.2 INSTRUKCJA INSTALACJI I URUCHOMIENIA APLIKACJI ODRACMT

7 1. Wstęp Współcześnie wytwarzanie systemy teleinformatyczne, jak równieŝ wolnostojące oprogramowanie generyczne, staje się coraz bardziej skomplikowanym tworem. Wraz ze wzrostem zapotrzebowania na te systemy oraz oczekiwania, co do funkcji, jakie powinny ono spełniać, rośnie poziom komplikacji zmian. Zmiany w oprogramowaniu są bowiem rzeczą naturalną i stale towarzyszącą procesom wytwórczym. InŜynieria oprogramowania która jest specyficzną, stale zmieniającą się i rozwijającą dziedziną nauki, pozwala usystematyzować te procesy. Miejsce szczególne pełni w niej Zarządzanie Konfiguracją Oprogramowania (ZKO). Zgodnie z definicją, jej celem jest planowanie, organizacja, sterowanie i koordynowanie działań mających na celu identyfikację, przechowywanie i zmiany oprogramowania w trakcie jego rozwoju, integracji i przekazania do uŝycia [1]. Jak się okazuje zagadnienie to jest bardzo obszerne, a poza wprowadzeniem pewnych norm, standardów, systematyki i dodatkowej dokumentacji, istotna jest takŝe automatyzacja i kontrola zadań poprzez wykorzystanie do tego celu odpowiednich narzędzi Cel pracy Celem pracy jest szczegółowe omówienie procesów towarzyszących zarządzaniu zmianą, problemy i trudności w ich implementacji. Kolejnym elementem jest przegląd narzędzi wspomagających procesy zarządzania konfiguracją i wersjami oprogramowania. Została przedstawiona szczegółowa koncepcja i istota nowoczesnych rozwiązań stworzonych zarówno w architekturze klasycznej typu klient-serwer jak równieŝ rozwiązania stosunkowe młode, oparte o model rozproszony. Wykorzystanie tych narzędzi w rzeczywistych warunkach faktycznie pokazuje, Ŝe pewne czynności rutynowe moŝna wykonywać dokładniej i pewniej, a niektóre operacje takie jak efektywne i bezpieczne wersjonowanie kodu, jest bez ich wykorzystania wręcz niemoŝliwe. Nie zmienia to jednak faktu, Ŝe rozwiązania najprostsze bywają niedostatecznie funkcjonalne, zaś rozwiązania złoŝone wymagają znacznych nakładów finansowych, zarówno na licencje uŝytkowe pakietów, jak teŝ infrastrukturę potrzebną do ich wdroŝenia i utrzymania. Praca ma na celu podjęcie próby stworzenia narzędzia, stanowiącego kompromis pomiędzy moŝliwościami, które oferują komercyjne, zintegrowane pakiety narzędziowe, z szybkością działania i prostotą rozwiązań darmowych. Jak się okazuje, większość obecnie istniejących narzędzi udostępnionych na zasadach open-source pokrywa jedynie funkcjonalność wersjonowania kodu, pomijając istotę innych, nierozerwalnych zagadnień związanych z zarządzaniem konfiguracją, jakim są np. kontrola cyklu Ŝycia wniosków Rezultaty pracy Rezultatem pracy jest analiza procesów zarządzania konfiguracją oprogramowania, ze szczególnym naciskiem na narzędzia wspomagające te procesy, ich zestawienie, opis architektury a takŝe opisanie wad i zalet. W wyniku porównania tych narzędzi i stwierdzenia pewnej luki, jaka jest obecna w tej materii, podjęta została próba kompromisu, polegającego na stworzeniu narzędzia łączącego w sobie względną prostotę, przyzwoitą wydajność oraz pokrycie aspektów ZKO takich jak wspomaganie kontroli zmiany, przy dodatkowej moŝliwości powiązania go z istniejącym repozytorium kodu. 7

8 Część praktyczna niniejszej pracy obejmuje implementację nowego, w pełni funkcjonalnego systemu kontroli wersji z wykorzystaniem technologii opartego o architekturę scentralizowaną. DuŜy nacisk został połoŝony na moŝliwości dowolnego modelowania obiektów podlegających zmianie. Implementacja została wykonana przy uŝyciu technologii takich jak język obiektowy Java, obiektową bazę danych Odra, oraz szereg innych technologii m.in. platformy.net, uŝytej do zbudowania aplikacji klienckiej Organizacja pracy Tekst pracy jest podzielony na: I. Wstęp wraz ze streszczeniem opisuje kontekst pracy, zagadnienia które zostały omówione, obszary analizy oraz wykorzystane narzędzia uŝyte w rozwiązaniu II. Ogólną charakterystykę inŝynierii oprogramowania rozdział drugi opisuje podstawy procesów wytwarzania oprogramowania w projektach informatycznych, ukazując wstępnie zagadnienie Zarządzania Konfiguracją Oprogramowania III. Szczegółowa analiza procesów ZKO rozdział trzeci opisuje szerszy kontekst zagadnienia, wprowadzając w miarę szczegółowo problematykę zagadnienia IV. Opis narzędzi rozdział ten jest poświęcony szczegółowemu opisowi narzędzi uŝywanych w ZKO i ich funkcji oraz porównaniu i opisowi kilku popularnych rozwiązań a takŝe charakterystyka ich niedoskonałości V. Opis technologii wykorzystanych do realizacji części praktycznej rozwiązania VI. Opis i szczegóły implementacyjne prototypu nowego systemu ZKO rozdział ostatni jest poświęcony szczegółom rozwiązania autorskiego, jakim jest prototyp narzędzia wspomagającego ZKO VII. Praca kończy się podsumowaniem zagadnienia i wyciągniętymi wnioskami 8

9 2. Zarządzanie konfiguracją w kontekście procesu wytwarzania oprogramowania 2.1. Informacje wstępne i rys historyczny Zarządzanie konfiguracją wywodzi swoje korzenie z amerykańskiego z przemysłu, dokładniej rzecz biorąc z przemysłu obronnego Stanów Zjednoczonych. Wytwarzanie produktów o niewielkim stopniu skomplikowania i zarządzanie cyklem ich Ŝycia mogło być wykonywane całkowicie niezaleŝnie przez jedną osobę bądź niewielkie grono. Gdy poziom skomplikowania danego wyrobu był znaczący (tak było w przypadku planów budowy maszyn lotniczych, skomplikowanej broni palnej itp.), zarządzanie projektem zmian, planami czy dokumentacją przez jedną osobę bądź wąską grupę osób, nie spełniało swoich funkcji. Na przestrzeni lat proces rozwoju militariów był kontrolowany przez kolejne, coraz to nowe osoby, zaś informacja o specyfice wytwórczej, była przekazywana pomiędzy nimi i w konsekwencji tracona bądź zawierająca niepoŝądane zmiany. W roku 1962, siły powietrzne Stanów Zjednoczonych zdały sobie sprawę z powagi problemu i opublikowały specjalny standard poświęcony zarządzaniu zmianami jest on dziś uwaŝany za pierwszy, który został poświęcony szeroko pojętemu zarządzaniu konfiguracją. Informatyzacja przemysłu, przedsiębiorstw stawała się coraz bardziej popularna a nacisk na rozwój oprogramowania coraz bardziej znaczący. Rosnący rozmiar systemów, wzrost krytyczności zadań przed nimi postawionych i trudności w zarządzaniu nimi spowodowały wzrost zespołów projektowych, które stawały się coraz większe i były niejednokrotnie rozproszone w róŝnych lokalizacjach geograficznych. Bolączki, które były kiedyś domeną inŝynierów produkcji, takie jak trudności w zarządzaniu projektami, problemy komunikacyjne i przekazywanie wiedzy, stawały się realnymi problemami wytwórców oprogramowania. Departament obrony Stanów Zjednoczonych oraz kilka innych organizacji takich jak ANSI, IEEE czy ISO równieŝ wyraziły zainteresowanie problemem, jakim stało się zarządzanie zmianą. KaŜda z tych organizacji zaproponowała własny standard w tej dziedzinie (obecnie najpopularniejszymi są te zaproponowane przez IEEE/ANSI). Ogólna ekspansja nowych technologii i Internetu spowodowała naturalną zmianę specyfiki wytwarzania oprogramowania i kształtów zespołów projektowych. Dziś nie dziwi nikogo zespół składający się z tysiąca ludzi, rozproszonych geograficznie w wielu rejonach świata czy teŝ duŝe systemy, których pojedyncze moduły zostały stworzone przez róŝne firmy. Zdaniem autora, głównym nurtem dzisiejszego przełomu informatyczno-telekomunikacyjnego, jest oprogramowanie komputerowe. Pozwala ono uczynić pracowników bardziej produktywnymi, wspomaga zarówno naukę jak i nauczanie, jest podstawą instytucji takich jak banki, placówki medyczne czy instytucje publiczne. Wraz ze wzrostem znaczenia oprogramowania i poziomu jego uŝyteczności oraz komplikacji, wzrasta poziom trudności jego wytworzenia. W systemach o znaczeniu krytycznym nawet niewielkie błędu mogą mieć bardzo znaczące konsekwencje. Z drugiej strony metodyka wykrywania błędów równieŝ zyskała nowe oblicze w duŝej mierze dzięki Internetowi. Komunikacja za pomocą forów internetowych, otwarte listy tzw. Bugów czy wreszcie serwis szybkiego reagowania w produktach komercyjnych, jeszcze skuteczniej niŝ kiedyś pomagają rozwiązywać problemy związane z błędami w oprogramowaniu. Środowiska wytwarzania oprogramowania stały się zatem bardzo złoŝone. Zadanie zarządzania systemami składającymi się niejednokrotnie z milionów komponentów, w sposób przemyślany, z zachowaniem odpowiednich standardów jakościowych, jest zadaniem bardzo trudnym. Odpowiednio zbudowany mechanizm zarządzania konfiguracją znacznie je ułatwia. 9

10 Zarządzanie konfiguracją oprogramowania zapewnia, Ŝe rozwój i ewolucja róŝnych komponentów systemu jest kompletna i kontrolowana, tak aby pojedyncze komponenty tworzyły spójną całość.[6] Zarządzanie konfiguracją oprogramowania, jest zestawem czynności pozwalających spójnie rozwijać i zarządzać jego rozwojem. Cel ten moŝe zostać osiągnięty poprzez wdroŝenie takich procedur jak koordynacja działań czy podział odpowiedzialności. Podstawowe korzyści płynące z działań związanych z zarządzaniem konfiguracją obejmują zatem: Łatwiejsze radzenie sobie z komplikacją zmian Wzrost ponownego uŝycia komponentów Wzrost produktywności wytwarzania oprogramowania Większa odporność na błędy Większe bezpieczeństwo zmian Lepsza jakość produktu końcowego Mniejsze koszty administracji i zarządzania oprogramowaniem 2.2. Ogólna charakterystyka procesu wytwarzania oprogramowania Informacje wstępne Proces wytwórczy oprogramowania stanowi szereg czynności potrzebnych do przekształcenia (implementacji) wymagań uŝytkownika w samodzielny produkt końcowy. Proces ten musi być spójny i kompletny. Nie przyjęto jak dotąd uniwersalnej i w pełni akceptowalnej definicji inŝynierii oprogramowania. Definicja encyklopedyczna mówi, Ŝe jest to: Dziedzina inŝynierii systemów zajmująca się wszelkimi aspektami produkcji oprogramowania: od analizy i określenia wymagań, przez projektowanie i wdroŝenie, aŝ do ewolucji gotowego oprogramowania. Podczas gdy informatyka zajmuje się teoretycznymi aspektami produkcji oprogramowania, inŝynieria oprogramowania koncentruje się na stronie praktycznej.[i1] InŜynieria oprogramowania nie jest zatem tylko i wyłącznie programowaniem, lecz jest procesem wytwórczym produktu lub systemu. Wymaga ona od swego twórcy zdolności analitycznym, zarządczych i komunikacyjnych. Jej nieodłącznym elementem jest trzymanie się pewnych reguł i standardów oraz praca zespołowa. InŜynier jest ograniczony przez wymagania narzucone przez uŝytkownika bądź klienta, decyzje zarządcze czy zespołowe. Zakres inŝynierii oprogramowania wykracza daleko poza sam proces techniczny jego implementacji. Znaczenie ma tu budŝetowanie, planowanie, efektywne wsparcie po wdroŝeniu, marketing produktu oraz dystrybucja. MoŜna przyjąć, Ŝe za początek produktu uznajemy powstanie idei jego wytworzenia koncepcja potrzeby i uŝyteczności danego rozwiązania. Generalnie oprogramowanie moŝemy podzielić na dwa typy: Systemy spełniające specyficzne zadania określone przez uŝytkownika takie jak systemy bankowości elektronicznej, rezerwacje połączeń linii lotniczych, oprogramowanie dla placówek uŝyteczności publicznej, narzędzia billingowe sieci komórkowych Oprogramowanie wolnostojące sprzedawane przede wszystkim na wolnym rynku, realizujące takie zadania jak wspomaganie prac biurowych, systemy operacyjne, przeglądarki internetowe itd Cykl Ŝycia oprogramowania 10

11 Słownik terminologii inŝynierii oprogramowania standardu IEEE Std-610 definiuje cykl Ŝycia oprogramowania jako: Okres czasu rozpoczynający się stworzeniem koncepcji produktu a kończący, kiedy jest on wykluczony z uŝytkowania. Cykl Ŝycia oprogramowania składa się zazwyczaj z fazy koncepcji, wymagań, projektowania, implementacji, testowania, instalacji, uŝytkowania i konserwacji oraz czasem z fazy wycofania.[10] Warto wymienić w tym miejscu modele wytwórcze (podejścia) takie jak: Model kaskadowy Model przyrostowy Model spiralny Model współbieŝny KaŜdy z nich, niezaleŝnie od szczegółów metodyki, zawiera pewne dające się zdefiniować fazy oraz porządek ich występowania. W ciągu ostatnich kilku lat duŝego znaczenia nabrały tzw. metodyki lekkie, które opowiadają się za szybkością, prostotą i koncentracją jedynie na aktualnie potrzebnej i wykorzystywanej funkcjonalności. Ich twórcy mówią o zaletach takich jak duŝa elastyczność w szczególności w kontekście zmieniającego się biznesu i reagowania na jego potrzeby. Cykle wytwórcze są z załoŝenia bardzo krótkie a momenty kolejnych wydań (tzw. releasów) oprogramowania - bardzo częste. Jednymi z bardziej popularnych metodyk zwinnych są: Extreme programming Scrum Dynamic Systems Development Method Adaptive Software Development Crystal Clear Feature Driven Development Pragmatic Programming ChociaŜ spora część tychŝe metodologii posiada elementy zarządzania konfiguracją, Ŝadna z nich nie zajmuję się pełnym zakresem działań potrzebnych do implementacji wszystkich procedur z nią związanych Charakterystyka faz cyklu Ŝycia Modele cyklu Ŝycia pozwalają oprogramowania pozwalają uporządkować przebieg prac, ułatwiając planowanie zadań oraz monitorowanie przebiegu ich realizacji. [1] Szczegółowe ich opisanie wykracza daleko poza zakres tej pracy. Inicjalizacja projektu W fazie tej wybierany jest kierownik zespołu projektowego oraz kluczowe role i podział odpowiedzialności. Formowany jest skład poszczególnych podzespołów oraz definiowane są moduły funkcjonalne. Planowany są zasoby, budŝet projektowy oraz ustalane są ramy czasowe trwania projektu. Wynikiem zakończenia tej fazy powinny być między innymi: Definicja zakresu działań zespołu projektowego Określenie standardów projektowych, formatów dokumentów Plan i dokumentacja przewidywanych zasobów, budŝetu i czasu 11

12 Definicja głównych procedur operacyjnych Określenie parametrów infrastruktury ZałoŜenia dotyczące technicznego środowiska realizacji systemu Plan zarządzania konfiguracją Wiele przedsiębiorstw ma swoje dodatkowe standardy i procedury, według których przygotowywany jest plan zarządzania projektem. Plan taki jest równieŝ przedmiotem wielu standardów takich organizacji jak IEEE czy ANSI. Z punktu widzenia zarządzania konfiguracją etap ten jest niezwykle istotny. Dokładne określenie procedur i standardów w tym zakresie a niejednokrotnie nawet implementacja konkretnego systemu zarządzania konfiguracją przynosi wymierne korzyści. Analiza wymagań Podstawowym zadaniem tej fazy jest zebranie i udokumentowanie szczegółowych wymagań uŝytkowych oprogramowania. Etap ten wymaga juŝ zaangaŝowania poszczególnych zespołów projektowych i nie jest domeną jedynie kadry zarządzającej. Zasadniczo moŝna podzielić go na dwa etapy analiza stanu aktualnego i wymagań, co do stanu do którego projekt dąŝy. Dokument przedstawiający stan obecny i stan wymagań jest następnie propagowany wśród klienta, uŝytkowników i zespołu projektowego. Analiza systemowa W fazie tej następuję doprecyzowanie pierwszej wersji dokumentu wymagań. RozwaŜane są rozwiązania alternatywne mogące mieć znaczący wpływ na budŝet projektu czy mające mniejsze zaleŝności od zastosowanych technologii czy narzędzi. Wymagania uwzględniają w tej fazie równieŝ takie czynniki jak, wydajność, bezpieczeństwo czy kwestię przechowywania danych. Tworzenie projektu wysokiego poziomu - Faza projektowania wysoko-poziomowego ma za zadanie zaprojektowanie systemu jako całości, na podstawie wymagań szczegółowych z uwzględnieniem czynników i ograniczeń technicznych, standardów oraz interfejsów. Czasami wynikiem tej fazy jest zbudowanie prototypu bądź próbki przyszłego systemu. Na tym etapie naleŝy przede wszystkim dokładnie określić szczegóły architektoniczne przyszłego systemu, czynniki bezpieczeństwa, dokładnego wolumenu danych, sposobu ich przechowywania i zapisu oraz wydajności. Zostaje zbudowana hierarchia klas bądź procedur oraz podział na moduły i funkcje. Opisane są komponenty formaty interfejsów, scenariusze menu, podział bibliotek, itd. WaŜnym elementem jest opisanie modelu danych, które będą przechowywane. Projektowanie szczegółowe W fazie tej przygotowywane są projekty szczegółowe takich obiektów jak biblioteki czy szkielety programów. Analiza obiektów odbywa się na podstawie dokumentu projektu wysokiego poziomu, z uwzględnieniem architektury, podziału na komponenty i zaleŝności między nimi. Podstawą projektów niskiego poziomu są uprzednio zdefiniowane standardy projektowe takie jak szablony, szkielety programów czy specyfikacje bibliotek. Implementacja Na tym etapie wszystkie komponenty systemu takie jak biblioteki, funkcje i programy są kodowane w konkretnych językach programowania a następnie wykonywane są testy jednostkowe tych komponentów. Zespół zarządzania konfiguracją działa na tym etapie w pełnym zakresie i jest odpowiedzialny za nadzorowanie repozytorium kodu oraz wykrywaniem niepoŝądanych zmian i nieprawidłowości. Podczas prac nad tą fazą, kodowane są poszczególne obiekty na podstawie specyfikacji projektu niskiego poziomu. Stworzone komponenty są testowane jednostkowo a wyniki tych testów są logowane. Na podstawie wyników testów wprowadzane są ewentualne poprawki. Wynikiem zakończonego cyklu implementacji są działające i przetestowane komponenty. Testy integracyjne i akceptacyjne Testy integracyjne stanowią etap, w którym produkt testowany jest jako całość z uwzględnieniem zaleŝności pomiędzy modułami. Zadania jakie są wykonywane w 12

13 tym cyklu to przeprowadzanie pełnych testów produktu według odpowiedniego i zarejestrowanie ich wyników. KaŜdy błąd wykryty na tym etapie powinien stanowić przedmiot odpowiedniego zgłoszenia a błędy naleŝy zdiagnozować i naprawić. Niejednokrotnie wprowadzona poprawka wymaga testów regresji. WdroŜenie Gdy testy integracyjne oraz testy uŝytkownika zostaną zakończone, oprogramowanie jest instalowane w tzw. środowisku produkcyjnym po stronie klienta. Specjalnie do tego celu przydzielony zespół, zwykle nadzorowany zarówno przez osoby odpowiedzialne za implementację systemu, jak teŝ członkowie zespołu klienta kontrolują proces instalacji i wdroŝenia. Procedurze tej towarzyszy niejednokrotnie dodatkowe wsparcie w sytuacjach krytycznych, przerwanie operacyjności dotychczas działającego systemu, czy teŝ czasochłonna migracja lub konwersja danych produkcyjnych. Konserwacja Po okresie implementacji i instalacji systemu, staje się on regularnym oprogramowaniem operacyjnym. Na tym etapie rozpoczyna się jego konserwacja. Podczas uŝytkowania w środowisku produkcyjnym na pełnym wolumenie danych, w warunkach uŝytkowania róŝniących się od środowisk testowych mogą zostać wykryte nowe błędy. Dodatkowo, moŝe zajść potrzeba wprowadzenia nowych funkcjonalności, które nie były wcześniej uzgadniane. Zespół wsparcia zajmujący się konserwacją systemu, ma za zadanie rejestrowanie wszelkich zgłoszeń o nieprawidłowościach, diagnozowanie ich a następnie naprawę w trybie serwisowym. Na etapie wdroŝenia zauwaŝalne są korzyści z prawidłowego przebiegu procesów zarządzania konfiguracją. W razie potrzeby poprzednie wersje komponentów mogą zostać przywrócone, a dostęp do dokumentacja i jej ewentualnej historii jest ułatwiony. Wycofanie Ostatnim etapem w cyklu Ŝycia oprogramowania jest jego wycofanie z uŝytku. Po wielu, czasem nawet kilkunastu lub kilkudziesięciu latach, pewien etap zostaje osiągnięty a koszty utrzymania w stosunku do korzyści, jakie system oferuje stają się zbyt wysokie. Konieczność wycofania moŝe być spowodowana np. niemoŝliwością dodania potrzebnych funkcji ze względu na zbyt radykalne zmiany w architekturze całego systemu. Innym powodem moŝe być zbyt duŝe ryzyko operacyjne zmian w takim systemie spadkowym Problemy związane z wytwarzaniem oprogramowania Proces wytwarzania oprogramowania ma odmienną specyfikę od innych procesów wytwórczych. Metody, narzędzia i reguły klasycznej inŝynierii nie mają przełoŝenia na te, które towarzyszą tworzeniu oprogramowania. Procesom tym towarzyszą ponadto inne utrudnienia, które nie występują bądź nie mają istotnego wpływu na całość przedsięwzięcia. Do problemów takich naleŝą przede wszystkim problemy komunikacyjne, zarządzanie wieloma wersjami tych samych danych oraz ich współdzielenie i jednoczesne uaktualnianie Problem komunikacyjny Czasy w których jedna osoba wytwarzała oprogramowanie, dawno minęły. Dzisiejsze projekty programistyczne składają się z druŝyn kilkuset osobowych, podzielonych na róŝne moduły. Moduły lub podsystemy mogą być zlokalizowane w róŝnych obszarach geograficznych, a ich członkowie być zróŝnicowani pod względem społecznym, kulturowym i edukacyjnym.[3] Problem taki naturalnie nie występuje, jeśli nad danym przedsięwzięciem pracuje tylko jedna osoba. Wraz ze wzrostem liczby zaangaŝowanych w projekt osób, rośnie liczba moŝliwych powiązań komunikacyjnych oraz co jest naturalną tego konsekwencją, rośnie liczba potencjalnych problemów, błędów i nieporozumień. 13

14 Pierwszym problemem pojawiającym się podczas komunikacji dwóch lub większej ilości osób, są nieporozumienia i dwojakie interpretacje przekazywanych informacji. Nieraz konieczne jest wyjaśnienie pozostałym członkom zespołu pewnego problemu za pomocą takich przekaźników jak słowa lub rysunki. Procesy zarządzania konfiguracją oprogramowania, dzięki mechanizmom kontrolowania zmian stanowią remedium na utrudnienia komunikacyjne. Gdy dany obiekt jest przedmiotem zmiany, pozostała część zespołu jest o tym dokładnie poinformowana a odpowiedzialność za modyfikacje jest jasno określona. W systemach zarządzania konfiguracją, kaŝdy komponent ma bowiem swoją historię zmian wraz ze szczegółami, takimi jak autor czy powód zmiany. Repozytorium konfiguracji moŝe zostać odpytane, a kaŝdy z zainteresowanych członków moŝe uzyskać odpowiednie informacje równolegle, bez potrzeby specjalnego wyłuskiwania informacji Problem współdzielonych danych i utrzymania wielu wersji Problem współdzielonych danych, jest powszechny wszędzie tam gdzie dwóch lub więcej programistów dzieli pewien zasób. MoŜe to być funkcja lub biblioteka współdzielona przez dwa programy. Problem narasta wtedy, gdy programista zmienia zasób współdzielony bez informowania o tym innych.[3] Podczas wprowadzania zmian przez osobę, która nie jest w stanie bądź nie informuję pozostałych osób o przeprowadzonych przez nią zmianach, następuje dezorganizacja zadań związanych z tym obiektem. Pozostali członkowie nie wiedzą o naniesionych poprawkach przykładem moŝe być rozszerzenie pewnej biblioteki i brak rekompilacji obiektów z nią związanych co w konsekwencji moŝe doprowadzić do nieprawidłowej pracy całego modułu. Jako inny przykład, moŝe posłuŝyć praca nad dokumentem wymagań, przez zespół kilku osobowy. Brak informacji o zmianach prowadzi do nieprawidłowego ukierunkowania prac pozostałej części zespołu. Problem jednoczesnego uaktualniania danych występuje natomiast w sytuacji, gdy jeden z członków zespołu projektowego dokonuje zmian na rzecz pewnego komponentu, uaktualnia centralne repozytorium, nadpisując poprzednią wersję, nie informując o tym pozostałych. Inna osoba wykonująca zmiany w tym komponencie, nie będąc świadoma istnienia kolejnej wersji, moŝe pominąć istotne zmiany i zastąpić dany komponent kolejną wersją nieuwzględniająca np. istotnych poprawek. Procesy zarządzania konfiguracją oprogramowania rozwiązują powyŝszy problem wprowadzając kontrolę i formalne zarządzanie modyfikacjami. Obiekty przechowywane są w specjalnych bibliotekach o ograniczonym dostępie. Zmiany wykonywane na rzecz kaŝdego komponentu wprowadzane są w drodze wniosków o modyfikację. KaŜda modyfikacja musi następnie przejść przez weryfikację i proces zatwierdzania. PoniewaŜ osoby dokonujące zmian, nie mogą odwoływać się bezpośrednio do repozytorium oraz nadpisywać go bez ograniczeń problem współdzielonych danych, istnienia niespójnych kopii oraz niepoŝądanych współbieŝnych aktualizacji - zostają wyeliminowane Zmienność i złoŝoność procesu tworzenia oprogramowania Oprogramowanie moŝe składać się z wielu róŝnych komponentów i być oparte o rozmaite platformy sprzętowe. Poszczególne konfiguracje tych platform, są od siebie zaleŝne i brak sprawowania kontroli nad nimi, moŝe doprowadzić do uszkodzenia bądź utracenia informacji. Wymagania funkcjonalne, implementacja właściwa, środowisko instalacyjne wszystkie te czynniki mają charakter zmienny. 14

15 Programiści bardzo często wprowadzają nieuzgodnione wcześniej poprawki do wytworzonego kodu. Zmienna i niestabilna moŝe być równieŝ platforma programistyczna lub sprzętowa która w wyniku zmian technologicznych staję się przestarzała Korzyści wynikające z wprowadzenia Zarządzania Konfiguracją Oprogramowania Biorąc pod uwagę problemy wynikające z natury procesu, jakim jest wytwarzanie oprogramowania, wprowadzenie zarządzania konfiguracją jest warunkiem koniecznym ze względu na coraz większe rozmiary tworzonych systemów, zwiększone zapotrzebowanie na nie oraz zmienność wymagań stawianych przed oprogramowaniem. Implementacja dobrego i odpowiednio utrzymywanego systemu Zarządzania konfiguracją oprogramowania przynosi wymierne korzyści. Wśród nich są: Sprawniejsza reakcja na potrzeby klienta i bardziej niezawodne serwisowanie oprogramowania w fazie następującej po wdroŝeniu produktu, jaką jest jego konserwacja i utrzymanie, naleŝy połoŝyć duŝy nacisk na kwestię rozwiązywania problemów technicznych czy naprawę błędów. Zespół wsparcia powinien sprawnie identyfikować i diagnozować błędy. WdroŜenie systemu zarządzania konfiguracją we wczesnej fazie projektu znacznie ułatwia to zadanie. Zwrot poniesionych kosztów poniewaŝ systemy zarządzania konfiguracją wykonują automatycznie wiele zadań oszczędzając czas potrzebny na ich realizację. Mogą one zostać wykorzystane do koordynacji zmian, automatycznego rozsyłania komunikatów do członków zespołu projektowego, czy instalacji komponentów. Takie podejście skutkuje redukcją kosztów, zwiększeniem niezawodności wielu procesów i wzrostem produktywności zespołu projektowego. Kontrola odpowiedzialności - systemy zarządzania konfiguracją pełnią funkcję rejestrowania podziału odpowiedzialności a takŝe mogą słuŝyć pomiarowi bieŝącego stanu projektu (zaawansowania w stosunku do czasu) oraz innym pomiarom takim jak prowadzenie statystyk wykrytej liczby błędów. Kontrola złoŝoności oprogramowania wykorzystanie narzędzi przyczynia się do usystematyzowania procesów wytwórczych. Wszelkie produkty będące wynikiem prac są identyfikowane i opisywane. KaŜdy z nich jest przechowywany w specjalnym repozytorium zabezpieczającym je przed nieuprawnionymi zmianami. Zapobiega to dezintegracji środowiska, powielaniu kodu i braku sprawowania kontroli nad wprowadzanymi zmianami czy teŝ poprawkami. Bezpieczeństwo - systemy zarządzania konfiguracją chronią repozytorium przed nieuprawnionymi zmianami komponentów. KaŜdy komponent opatrzony jest historią modyfikacji jednoznacznie identyfikującą odpowiedzialną za daną zmianę osobę. Wzrost jakości wytwarzanego oprogramowania celem zapewnienia jakości oprogramowania jest podejście które zakłada jak najwcześniejsze wykrycie błędów na poprawek wykrywanych w późniejszej fazie. Narzędzia systemów zarządzania konfiguracją ułatwiają taką diagnozę, a konsekwencją zapewnienia jakości w drodze wczesnego wykrywania defektów jest minimalizacja ryzyk nimi spowodowanych. 15

16 Gwarancja spójności wytworzonego produktu od momentu rozpoczęcia cyklu Ŝycia oprogramowania, do jego zakończenia mija wielu czasu, a procesy zachodzące pomiędzy tymi zdarzeniami są bardzo złoŝone. Analizując gotowy system na podstawie historii dokumentacji, wymagań, czy wreszcie zmian na poziomie architektury modułów, istnieje moŝliwość stwierdzenia czy zbudowany system został wytworzony zgodnie z obowiązującymi normami i specyfikacjami. 16

17 3. Charakterystyka procesów Zarządzania Konfiguracją Oprogramowania 3.1. Informacje wstępne Zarządzanie konfiguracją jest zbiorem procesów i czynności wykonywanych podczas całego cyklu Ŝycia oprogramowania od fazy analizy i zbierania wymagań, na wdroŝeniu i konserwacji oprogramowania kończąc. Jest ono niezbędnym elementem inŝynierii oprogramowania ze względu na ciągłe zmiany w oprogramowaniu, jego wymaganiach, załoŝeniach, implementacji oraz instalacji. Zasadniczo moŝemy wyróŝnić następujące elementy będące produktami procesów wytwórczych oprogramowania: Dokumentacja w tym dokumenty wymagań funkcjonalnych, analizy i projektowania architektury systemu, plan testów i skrypty testowe, wytyczne dotyczące wdroŝenia, podręcznik uŝytkownika Komponenty programowe takie jak kod źródłowy i pośredni, skompilowane programy, biblioteki Dane testowe, migracyjne, konwersyjne itp. Systemy ZKO nadają tym elementom pewne właściwości, a takŝe określają relacje między nimi. PoniewaŜ zmiany są nieodzownym elementem inŝynierii oprogramowania, naleŝy je kontrolować i ewidencjonować. ZKO jest zatem zbiorem czynności mających na celu identyfikację pozycji konfiguracji, określania ich właściwości, wzajemnych powiązań oraz śledzenie, nadzorowanie, dokumentacja i raportowanie zmian. Pierwszym krokiem mającym na celu kontrolę zmian, jest identyfikacja tych elementów projektu które takim zmianom będą podlegać. Elementy takie nazywane są pozycjami konfiguracji. Standardy takie jak IEEE określają pozycje konfiguracji jako zbiór artefaktów programowych i sprzętowych które podlegają zarządzaniu zmianami w procesie ZKO. Mogą to być programy i biblioteki, dokumentacja projektowa, czy podręczniki uŝytkownika. Systemy ZKO nadają cechy tym obiektom takie jak funkcje, rozmiar, właściwości związane z wydajnością. Do pozycji konfiguracji występujących w danym projekcie moŝemy zaliczyć m.in.: Plan zarządzania projektem i plan zarządzania konfiguracją Dokument analizy wymagań funkcjonalnych Dokumenty projektu wysokiego i niskiego poziomu Prototypy systemów Kody źródłowe programów Obiekty wykonywalne Plan wykonania testów i skrypty testowe Dane testowe Kompilatory Specyfikacje modelu danych Prezentacje szkoleniowe i podręczniki uŝytkownika W zaleŝności od specyfiki projektu lista ta moŝe być bardzo zróŝnicowana. Projektanci systemów ZKO mają za zadanie określić które z nich będą ostatecznie pozycjami konfiguracji. Informacja taka 17

18 jest zazwyczaj przechowywana w specjalnej bazie danych konfiguracyjnych lub innego rodzaju repozytoriach. Do głównych procesów zarządzania konfiguracją oprogramowania naleŝą: Definicja konfiguracji jest to jedna z podstawowych czynności związanej z ZKO. Do jej zakresu naleŝy zdefiniowanie wersji bazowej produktu oraz identyfikacja pozycji konfiguracji. KaŜda z pozycji konfiguracji, musi posiadać schemat nazewnictwa i wersjonowania, a takŝe posiadać szereg innych charakterystyk, takich jak wydajność czy korelacje ze środowiskiem wykonania. Kontrola konfiguracji polega na koordynacji i zarządzaniem wnioskami o zmianę na rzecz pozycji konfiguracji. Określa sposób zatwierdzania komponentów jako wersji bazowych i sposób ich dodawania do biblioteki. Przechowywania historii zmian określa w jaki sposób zmiany będą rejestrowane, nadzorowane i raportowane. Weryfikacja polega na zapewnieniu spójności wszystkich komponentów w kontekście działania całego systemu spełniającego określone wymagania Wersja bazowa (baseline) Proces wytwarzania oprogramowania generuje pozycje konfiguracji, takie jak projekty techniczne komponentów, kody źródłowe programów itd. Informacja o kaŝdym zakończonym komponencie powinna trafić do zespołu zarządzania konfiguracją w celu jej identyfikacji. MoŜe ona zostać zweryfikowana na podstawie wytycznych zawartych w planie zarządzania konfiguracją, w celu sprawdzenia jej kompletności i spójności. W cyklu Ŝycia oprogramowania istnieją pewne momenty, w których ustanawiana jest wersja bazowa systemu zazwyczaj jest to zakończenie fazy zbierania i definicji wymagań, ukończenia projektu technicznego wysokiego i niskiego poziomu, zakodowaniu i przetestowaniu obiektów oraz wdroŝeniu. Wersja bazowa musi zatem zawierać wszystkie elementy które powinny być dostępne w repozytorium danych. Istnienie konkretnej wersji bazowej, jest podyktowane potrzebą jej utworzenia. Koncepcja wersji bazowych znacznie ułatwia kontrolowanie modyfikacji. Standard IEEE definiuje wersje bazowe jako artefakty które zostały formalnie zweryfikowane i zatwierdzone i słuŝą jako baza do dalszego rozwoju oprogramowania oraz mogą być modyfikowane w drodze formalnych procedur zmian. [11] Wersja bazowa jest fundamentem procesów zarządzania zmianami. ZałoŜenia ZKO identyfikują pozycje konfiguracji w pewnym punkcie procesu wytwórczego właśnie jako wersje bazowe. KaŜda wersja bazowa stanowi punkt odniesienia dla kolejnej fazy rozwoju oprogramowania. Bazowe wersje oprogramowania stanowią zbiór komponentów zatwierdzonych jako konkretny produkt. W wielu projektach ustanawiane są co najmniej trzy rodzaje wersji bazowych wymagania funkcjonalne, projekty techniczne oraz gotowa implementacja techniczna. KaŜdy z nich słuŝy jako punkt odniesienia do kolejnej cyklicznej fazy zmian wprowadzanych w drodze formalnych procedur. Decyzja o stworzeniu wersji bazowej zaleŝy od wielu czynników związanych z danym projektem i leŝy w gestii osób odpowiedzialnych za cały plan zarządzania konfiguracją. Prawidłowe ustanowienie wersji bazowej, stanowi kompromis pomiędzy bezpieczeństwem i koniecznością formalizacji zmian, a wydajnością prac projektowych które w pewnych przypadkach mogą ulec spowolnieniu. Dopóki programista jest w stanie wykonywać samodzielnie prace na rzecz danego komponentu - w szczególności nowego, dopóty dopuszczalne jest pominięcie procesu formalnej kontroli. Jeśli w grę wchodzi praca zespołowa nad tym samym komponentem, zastosowanie procedur ZKO w pełnym zakresie jest niezbędne. 18

19 Pomimo potrzeby tworzenia zazwyczaj trzech wersji bazowych dla wymagań, projektu oraz bazowej wersji produktu, mogą one być stworzone w zaleŝności od potrzeb danego przedsięwzięcia. Ilość potrzebnych wersji bazowych jest ustalana przez zespół zarządzający konfiguracją, na podstawie cech danego projektu oraz ewentualnych korzyści płynących z tego tytułu Wprowadzanie i pobieranie komponentów (checkin, checkout) KaŜdy komponent który został wytworzony a następnie zatwierdzony, jest przechowywany w specjalnym repozytorium. Czynności polegające na przeglądzie, zatwierdzaniu i umieszczaniu gotowych obiektów w repozytorium, moŝemy określić mianem wprowadzania (ang. Check-in). Od chwili kiedy dany obiekt staje się częścią biblioteki, podlega on formalnym procedurom kontroli i zatwierdzania zmian. W celu modyfikacji danego komponentu znajdującego się w repozytorium musi nastąpić jego formalne pobranie (ang. Checkout) z biblioteki. Po jej wprowadzeniu komponent jest testowany, przeglądany a następnie zatwierdzany bądź odrzucany. W przypadku zatwierdzenia trafia on ponownie, jako kolejna wersja obiektu, do repozytorium. Komponent który w drodze formalnego przeglądu nie został zaakceptowany, nie moŝe stać się częścią biblioteki. Schemat tego procesu został przedstawiony na poniŝszym rysunku. Rysunek 1. Schemat obiegu komponentów w repozytorium Nowoczesne systemy ZKO częściowo automatyzują ten proces umoŝliwiając między innymi, jednoczesną pracę nad danym komponentem przez wielu członków zespołu Warianty i wersje Komponenty które zostały zatwierdzone i stały się elementami produktu bazowego, w drodze formalnego procesu, mogą przechodzić dodatkowo przez szereg modyfikacji. Przyczyną tych zmian moŝe być np. wykrycie błędów lub poprawki wydajnościowe. KaŜda zmiana wprowadzona w drodze 19

20 formalnej, poprzez pobranie komponentu z repozytorium i jego późniejsze zatwierdzenia, moŝe wygenerować nową wersję tego komponentu. Wersją moŝe być pierwsze, bądź kolejne wydanie danej pozycji konfiguracji i charakteryzuje się róŝnicami (np. funkcjonalnymi) w stosunku do swego poprzednika. Szczególnym przypadkiem wersji są warianty danego obiektu, które mogą nie wykazywać Ŝadnych róŝnic funkcjonalnych a być jedynie zaleŝne od platformy sprzętowej. KaŜde stworzenie nowego wariantu i wersji musi być odzwierciedlone w historii zmian danego obiektu. Dzięki takiemu podejściu, moŝna dokonać analizy wprowadzonych poprawek lub teŝ zdiagnozować problemy które wystąpiły np. po pojawieniu się nowego wydania produktu. Konwencja nazewnictwa słuŝąca identyfikacji wersji moŝe uwzględniać róŝne warianty. NiezaleŜnie od tej konwencji uwzględnia ona zazwyczaj: Nazwę danego obiektu, mogąca składać się w szczególności z nazwy projektu, typu pozycji konfiguracji oraz szczegółów dodatkowych Parametr numeryczny identyfikujący wersję i zmieniający się wraz z pojawieniem się kolejnej Część stanowiąca opis alfanumeryczny, powinna nieść ze sobą moŝliwie duŝo informacji takich jak typ komponentu, kod modułu czy teŝ obszar funkcjonalny co pozwala na szybką identyfikację. Część numeryczna powinna wskazywać połoŝenie wersji komponentu w hierarchicznym układzie. Standardowym i bardzo często wykorzystywanym schematem, jest identyfikacja wersji nadrzędnej jako cyfry najbardziej znaczącej a następnie oddzielanie separatorem (zwykle jest to kropka) i rozwijanie kolejnych podwersji np oznacza pierwszą wersję bazową, 4 wydanie i drugą rewizję Gałęzie i programowanie współbieŝne Schemat działania polegający na prostym pobraniu danego obiektu z biblioteki, modyfikacji, zatwierdzeniu a następnie ponownemu wprowadzeniu go do repozytorium ma charakter liniowy. W zaleŝności od potrzeb danego projektu moŝe on okazać się niewystarczający. Aby umoŝliwić zrównoleglenie procesów tworzenia oprogramowania, zostało opracowane podejście oparte na tzw. gałęziach. Stanowią one alternatywę dla schematu liniowego, umoŝliwiając wielu osobom pracę nad tym samym obiektem. Typowym przykładem wykorzystania tego podejścia, jest rozwój nowej funkcjonalności danego modułu przez jedną osobę, przy jednoczesnej poprawie istniejących błędów przez inną osobę bądź zespół. Rysunek 2. Przykład wyodrębnienia kilku gałęzi z wersji Wydzielenie gałęzi z głównego nurtu prac ma jednak charakter tymczasowy. Takie podejście jest wprowadzane głównie na potrzeby moŝliwości równoległego rozwoju obiektów w ramach tego 20

21 samego komponentu. W odpowiednio ustalonym momencie czasowym, kaŝda z wyodrębnionych gałęzi musi zostać włączona do wersji nadrzędnej. Rodzi to problem sposobu uwzględnienia zmian. W przypadku gdy niezaleŝne gałęzie dokonywały modyfikacji tego samego miejsca komponentu, osoba odpowiedzialna za scalenie zmian musi podjąć decyzję dotycząca zachowania bądź odrzucenia jednej z nich. Niektóre z nowoczesnych narzędzi ZKO, posiadają funkcję automatycznego scalania zmian na podstawie predefiniowanych kryteriów Wersje źródłowe i ich pochodne Komponent który powstaje na podstawie innego komponentu, jest jego pochodną. Typowym przykładem jest kod wykonywalny programu, wygenerowany za pomocą kompilatora danego języka na podstawie kodu źródłowego. W przypadku komponentów pochodnych, istotne jest przechowywanie i dokumentacja powiązań pomiędzy komponentami źródłowymi, którymi są równieŝ narzędzia i środowisko uŝyte do wygenerowania pochodnych. Odpowiedni system ZKO wspierający zarządzania komponentami pochodnymi, powinien zatem przechowywać informację dotyczące: Referencji i wersji komponentu źródłowego uŝytego do wygenerowania komponentu pochodnego Narzędzi które zostały uŝyte przy tworzeniu pochodnej Informacje o środowisku w którym nastąpiło wygenerowanie obiektu i jego parametry Proces integracji całego systemu polega na połączeniu komponentów źródłowych z odpowiednim schematem konfiguracji docelowej. KaŜda zmiana obiektów źródłowych, wymaga ponownego wytworzenia związanych z nią komponentów pochodnych. Parametry budowy konkretnego systemu, takie jak skrypty wsadowe czy ustawienia środowiska równieŝ powinny stanowić pozycję konfiguracyjne a takŝe podlegać procesom formalnym. Wiele systemów ZKO posiada funkcje automatycznego generowania parametrów środowiska i badania zaleŝności pomiędzy obiektami źródłowymi a pochodnymi. Podejście takie zmniejsza ryzyko błędów które mogą zostać popełnione oraz znacznie upraszcza proces budowy Wydania (release) Wydanie, oprócz samego kodu wykonywalnego systemu, stanowi takŝe zbiór danych, plików instalacyjnych, programów uruchomieniowych oraz dokumentacji. Jest ono kompletnym system z punktu widzenia uŝytkowego. KaŜde wydanie wprowadza zazwyczaj nowe funkcje, uwzględnia sugestie klienta oraz poprawki. Podczas tworzenia wydania, istotnym jest zarejestrowanie parametrów środowiska w jakim zostało wytworzone. MoŜliwość ponownej weryfikacji tych parametrów, jest krytyczna z punktu widzenia ZKO, ze względu na konieczność odtworzenia pierwotnej konfiguracji wydania Przyrostowe przechowywanie informacji W modelu idealnego systemu ZKO, wszelkie zmiany na rzecz komponentów powinny być rejestrowane i przechowywane jako osobne jego wersje. Potrzeba analizy bądź wyłuskania pewnych informacji z wersji systemu sprzed wielu lat, moŝe wiązać się np. z istnieniem takiej wersji na rynku i zobowiązania danej firmy wobec klientów którzy jej uŝywają. 21

22 W praktyce bardzo rzadko historia zmian jest przechowywana w repozytorium jako kompletne obiekty, z kolejnymi numerami wersji. W celu minimalizacji rozmiarów repozytorium stosowane jest podejście przyrostowe. Rysunek 3. Schemat przyrostowego przechowywania danych w repozytorium Informacja przyrostowa zajmuje znacznie mniej miejsca od pełnej wersji obiektu. Mechanizm zapisywania nowej wersji w repozytorium jako informacji przyrostowej polega na przechowywaniu w pełnym zakresie obiektu pierwotnego. Podczas tworzenia nowej wersji, jest ona porównywana z wersją istniejącą, po czym tworzona jest informacja przyrostowa. Podczas pobierania z repozytorium konkretnej wersji komponentu, informacja przyrostowa jest ponownie uwzględniania i dołączana do pliku bazowego. Innym podejściem jest przechowywanie w pełnym zakresie tylko wersji najnowszej a kaŝde utworzenie nowej wersji wiąŝe się z wygenerowaniem informacji przyrostowej, skasowaniu wersji bieŝącej i zastąpienie jej nową. Decyzja o uŝyciu takiego sposobu przechowywania informacji w repozytorium jest podejmowana w drodze kompromisu, pomiędzy miejscem zajmowanym przez komponenty a czasem dostępu do nich. Jeśli dany projekt składa się z bardzo wielu wersji komponentów, czas potrzebny do wygenerowania Ŝądanej wersji na podstawie danych przyrostowych, moŝe znacząco się wydłuŝyć. Biorąc pod uwagę znaczny spadek cen nośników danych i specyfikę danego projektu, moŝna rozwaŝyć całkowitą rezygnację z przechowywania danych w repozytorium w sposób przyrostowy. Wiele narzędzi oferuje parametryzację sposobu przechowywania umoŝliwiając elastyczny wybór, w zaleŝności od podjętych przez zespół ZKO decyzji Repozytorium danych systemu zarządzania konfiguracją Repozytorium danych konfiguracyjnych jest uŝywane do przechowywania wszelkich informacji związanych z konfiguracją oprogramowania na danym projekcie. Głównymi zadaniami tego repozytorium jest analiza wpływu zmian na system, przechowywania zaleŝności pomiędzy obiektami oraz udostępnianie informacji na temat procesów ZKO. Baza zarządzania danymi konfiguracji, zawiera dodatkowo dane na temat wniosków o zmianę wraz z ich statusem oraz informacje o wykonanych procesach przeglądu i zatwierdzania. Repozytorium powinno być wyposaŝone w mechanizmy zabezpieczające dane przed uszkodzeniem i utratą spójności. Prawidłowo skonstruowana baza konfiguracji powinna zawierać dane na temat: 22

23 BieŜącej konfiguracji systemu Środowiska i platformy sprzętowej związanej z konkretną wersją system Sumarycznej liczba wersji systemu jakie zostały wygenerowane Historii zmian na kaŝdym pojedynczym komponencie wraz ze znacznikiem czasowym ich wykonania oraz osobą za nie odpowiedzialną Historii przeglądów formalnych Liczby błędów i poprawek związanych z konkretną wersją komponentu Wpływu danej zmiany na inne modyfikacje oraz na cały system Obecnie narzędzia słuŝące do zarządzania konfiguracją posiadają własne warianty repozytoriów danych, co zwalnia projektantów z potrzeby tworzenia ich od zera tylko i wyłącznie na potrzeby danego projektu Fazy implementacji Zarządzania Konfiguracją Oprogramowania Implementacja procedur zarządzania konfiguracją oprogramowania, moŝe nastąpić w kaŝdej fazie cyklu Ŝycia projektu, jednak uwzględnienie jej na wczesnym etapie rozwiązuje wiele problemów. ChociaŜ implementacja i utrzymanie dobrej jakości systemu ZKO jest trudnym zadaniem, przynosi ono wymierne korzyści. Implementacja procedur oraz systemu zarządzania konfiguracją wymaga indywidualnego podejścia oraz odpowiedniego nakładu pracy zaleŝnego od specyfiki projektu, jego metodologii czy teŝ oczekiwanych rezultatów. WdroŜenie kaŝdej z procedur związanych z zarządzaniem konfiguracją, wiąŝe się z uwzględnieniem pewnych czynników i wartości takich jak: Zakres którym objęta jest kontrola zmian przez system zarządzający konfiguracją Zasoby potrzebne do prowadzenia projektu takie jak zasoby ludzkie, programowe i sprzętowe Stopień skomplikowania jest on zaleŝny od rozmiaru projektu, uwarunkowań biznesowych oraz rodzaju organizacji która prowadzi dany projekt Korzyści stanowią wypadkową kosztu implementacji i utrzymania procedur ZKO, w stosunku do funkcjonalności jakie będą przez nie oferowane Zasadniczo moŝna wyróŝnić dwa podejścia do implementacji zarządzania konfiguracją podejście globalne stosowane w ramach danej organizacji oraz podejście projektowe. NiezaleŜnie jednak od zastosowanego podejścia, pewnie etapy implementacji muszą zostać wykonane a kaŝda implementacja procedur zarządzania konfiguracją jest niepowtarzalna i powinna zostać potraktowana indywidualnie w kontekście danego projektu. Fazami modelowymi, mogącymi występować w kaŝdym projekcie dla którego zostało zaimplementowane zarządzanie konfiguracją to: Projektowanie systemu ZKO Przygotowanie planu ZKO Przygotowanie infrastruktury Organizacja i szkolenia zespołu ZKO Implementacja systemu ZKO Szkolenia pozostałych członków projektu w zakresie ZKO UŜytkowanie systemu ZKO Konserwacja systemu ZKO 23

24 KaŜda z faz implementacji ZKO, moŝe składać się dodatkowo z faz pośrednich takich jak analiza wymagań projektowych, badanie moŝliwości infrastruktury sprzętowej, wybór narzędzi, zakup licencji itd. Przykładowy układ poszczególnych faz na tle innych czynności projektowych został przedstawiony na poniŝszym rysunku: Rysunek 4. Fazy implementacji ZKO a cykl Ŝycia projektu Projektowanie systemu ZKO Z chwilą gdy zarząd projektu decyduje się na wprowadzenie zarządzania konfiguracją, musi nastąpić faza wstępnego zaprojektowania systemu. W przypadku gdy dana organizacja ma doświadczenie w implementacji tego typu rozwiązań, zadanie takie jest znacznie uproszczone i zasadniczo polega na zastosowaniu pewnego szablonu i przełoŝenie go na realia projektowe. Do odpowiedzialności zespołu przygotowującego projekt systemu naleŝą: Przygotowanie planu zarządzania konfiguracją i jego modyfikacje Konfiguracja i dostosowywanie system ZKO do konkretnych zadań Organizacja przyszłego zespołu zarządzania konfiguracją i jego składu osobowego 24

25 Wybór konkretnych narzędzi poprzez analizę rozwiązań dostępnych na rynku i realizacja zamówień Gdy definicja wymagań postawionych przed systemem zostanie zakończona, musi ona zostać udokumentowana. Dokument taki jest planem zarządzania konfiguracją. Podczas trwania całego projektu dokument przechodzi szereg zmian. Zmiany te równieŝ podlegają procedurom formalnym takim jak przegląd i zatwierdzanie. Wersja bazowa planu jest zazwyczaj tworzona podczas fazy zbierania wymagań lub bezpośrednio przed nią. Przygotowanie infrastruktury Faza ta obejmuję implementację i instalację narzędzi oraz przydzielenie odpowiedzialności w zakresie ich administrowania i konserwacji. W przypadku rozbudowanych rozwiązań, moŝe zaistnieć konieczność konsultacji z przedstawicielem zewnętrznego dostawcy danego narzędzia. Konsultanci tacy, mogą równieŝ pełnić rolę osób prowadzących szkolenia z zakresu tych narzędzi. Administratorzy baz danych, repozytoriów i bibliotek, muszą dokonać podstawowej konfiguracji środowiska działania tych obiektów oraz pełnić funkcje nadzorcze w szczególności w początkowym okresie. Organizacja i szkolenia zespołu ZKO NiezaleŜnie czy skład zespołu tworzą osoby doświadczone czy teŝ zupełnie nieznające idei zarządzania konfiguracją, nieodłącznym elementem budowania zespołu jest organizacja szkoleń. Zakres przekazywanych informacji to między innymi omawianie odpowiedzialności kaŝdego z członków czy szkolenia związane z uŝytkowaniem konkretnych narzędzi. Konserwacja systemu ZKO w fazie następującej po wdroŝeniu danego systemu, część odpowiedzialności związanych z jego uŝytkowaniem jest przenoszona na uŝytkowników. Korzystanie z systemu poprzez standardowe czynności takie jak kontrola i śledzenie zmian, pobieranie i umieszczanie obiektów w repozytorium powodują ogólną eksploatację systemu. Administrator narzędzi powinien zadbać o moŝliwie bezawaryjne działanie, odpowiednią wydajność i kontrolę zasobów Identyfikacja pozycji konfiguracji Działania związane z identyfikowaniem pozycji konfiguracji stanowią podstawę idei zarządzania konfiguracją oprogramowania. Polegają one na m.in. na: WyróŜnieniu obiektów które mają podlegać kontroli Uzgodnieniu standardów ich nazewnictwa Uzgodnieniu sposobu wersjonowania Wprowadzeniu gotowych pozycji konfiguracji pod kontrolę narzędzi ZKO Procesy związane z identyfikacją PK uwzględniają podział oprogramowania na pewne elementy podlegające zarządzaniu zmianą. Z punktu widzenia ZKO oprogramowanie jest zbiorem pewnych pozycji konfiguracji, z których kaŝda stanowi pewną niepodzielną, atomową jednostkę. Proces identyfikacji pozycji konfiguracji powinien uwzględniać jak najwięcej informacji charakteryzujących dany obiekt. Pojedyncze PK mogą składać się z innych PK tworząc pojedyncze komponenty lub jednostki. PoniŜszy diagram prezentuje przykładowe zaleŝności pomiędzy pozycjami konfiguracji: 25

26 Rysunek 5. Przykładowe drzewo hierarchii PK Schemat wprowadzania identyfikacji pozycji konfiguracji moŝe składać się z następujących czynności: Zdefiniowane kryteriów i charakterystyk podziału obiektów które będą znajdowały się pod kontrolą ZKO Wybranie PK oraz określenie zaleŝności między nimi Zbudowanie hierarchii komponentów Ustalenie schematów i standardów nazewnictwa ułatwiających identyfikację PK Zdefiniowanie wersji bazowych kaŝdej z istniejących PK Opisanie i stworzenie interfejsów pomiędzy danymi pozycjami konfiguracji Ustalenie sposobu pobierania kaŝdej PK z wersji bazowej Nadanie odpowiednich identyfikatorów kaŝdej PK umoŝliwiających jednoznaczną ich identyfikację a takŝe umoŝliwienie określenia zaleŝności między nimi Odpowiednie dobranie liczby dostępnych PK, jest kompromisem pomiędzy przejrzystością procesów kontroli zmiany a łatwością zarządzania tymi obiektami. KaŜda pozycja konfiguracji staję się niepodzielną logiczną jednostką. Podział na te jednostki moŝe nastąpić w fazie projektowania planu zarządzania konfiguracją. Przyjęto, Ŝe kaŝda PK jest pewną częścią oprogramowania systemowego, która moŝe zostać zaprojektowana, zaimplementowana oraz przetestowana. W szczególności pozycjami konfiguracji mogą być takie elementy jak plan zarządzania projektem, specyfikacja wymagań, dokumenty projektów wysokiego i niskiego poziomu, kody źródłowe programów, dokumentacja, pliki wykonywalne czy teŝ skrypty testowe. W celu optymalnego wyboru i identyfikacji PK naleŝy uwzględnić: Poziom krytyczności i wpływu danego obiektu na architekturę system MoŜliwość wykorzystania danego obiektu w innych modułach MoŜliwość niezaleŝnego rozwijania obiektu w tym projektowania, implementacji i testowania 26

27 Konieczność zarządzania PK przez zróŝnicowane zespoły projektowe w rozproszonych lokalizacjach Wpływ platformy programistycznej i sprzętowej Rodzaj oprogramowania generyczne lub systemowe Poziom wsparcia danego komponentu przez dostawcę zewnętrznego Poziom komplikacji zmian koniecznych do modyfikacji komponentu Częstotliwość zmian dokonywanych w trakcie cyklu Ŝycia komponentu Wpływ komponentów powiązanych na komponent bazowy Rozmiary komponentu Kolejnym istotnym aspektem jest nazewnictwo pozycji konfiguracji. Konwencja moŝe uwzględniać uŝycie dowolnych symboli alfanumerycznych, powinna jednak ułatwiać jednoznaczną identyfikację danej PK oraz mówić o jej zaleŝnościach i umiejscowieniu w kontekście całego systemu. Brak jednoznacznej identyfikacji w uŝytej konwencji, prowadzi do niejasności, problemów oraz jest przyczyną wielu błędów Kontrola zmian konfiguracji Projekty, ze swej natury, mają charakter dynamiczny. Mogą być realizowane miesiącami, a nawet latami. W dodatku mają one tendencję do wzrostu i ulegania zmianom, a ich przebieg często jest trudny do przewidzenia.[7] Kontrola konfiguracji jest procesem mającym na celu planowanie przygotowania, oceny, przeglądu, koordynacji, przekazania, implementacji zaproponowanych zmian bądź defektów w stosunku do pozycji konfiguracji i wersji bazowej. [4] Kontrola modyfikacji i zmian w konfiguracji programowania, jest jednym z najczęściej wykorzystywanych procesów związanych z ZKO. Przegląd i zatwierdzanie danej konfiguracji jest wykonywany po jej ukończeniu lub przed kolejnymi wydaniami systemu. Czynności związane z kontrolą zmian, mają jednak miejsce za kaŝdym razem, kiedy powstaje wniosek o zmianę. Ich intensyfikacja następuje w fazie implementacji systemu oraz w trakcie poprawy zgłoszeń będących wynikiem wykrycia błędów w fazie testów integracyjnych i akceptacyjnych. Zmiany w drodze wniosków formalnych muszą być wykonywane takŝe w przypadku dodawania nowych funkcjonalności. Poszczególne czynności wykonywane w ramach kontroli zmiany mogą zostać w duŝej części zautomatyzowane. Na rynku dostępnych jest bardzo wiele narzędzi, dostępnych dla przeróŝnych platform sprzętowych i środowisk programistycznych. Większość z nich oferuję rozbudowane funkcje automatyzacji zadań związanych z kontrolą zmian, a sama funkcjonalność automatyzacji tych czynności, była motywem przewodnim podczas tworzenia pierwszych wersji tych narzędzi. NaleŜy pamiętać, Ŝe proces modyfikacji oprogramowania nie dotyczy jedynie pojedynczych komponentów. Istotne zmiany zgłaszane przez klienta bądź odwrotnie przez firmę wytwarzającą dany produkt, w drodze specjalnych wniosków, mogą wpływać na warunki umowy lub całkowitą wycenę prac czy termin oddania gotowego produktu. W takim wypadku powinien zostać przygotowany wniosek o zmianę, który następnie powinien zostać zatwierdzony przez drugą stronę. Wnioski o zmianę powinny podlegać, tak jak pozostałe obiekty, wszelkim procedurom zarządzania konfiguracją.[3] Przykładowy schemat przygotowywania wniosku o zmianę oraz jego zatwierdzania, przedstawia poniŝszy diagram: 27

28 Rysunek 6. Przykładowy cykl Ŝycia wniosku o zmianę Pomijając zmiany zaplanowane oraz te które zostały zgłoszone w drodze wniosków o zmianę, istnieje pewien typ zmian niewynikających bezpośrednio z przewidzianej funkcjonalności produktu. Inicjatorem tych zmian często są architekci i programiści którzy ze względu na zaistnienie pewnych wyjątkowych, na ogół nieprzewidzianych okoliczności, muszą odstąpić od ustalonej wcześniej specyfikacji produktu. Wprowadzenie zmian które nie są kontrolowane, rodzi powaŝne problemy zaczynając od opóźnień w harmonogramie projektu a na jego niepowodzeniu kończąc. Kontrola konfiguracji rozwiązuje bowiem istotne problemy związane z wytwarzaniem oprogramowanie związane z komunikacją, współdzielonymi danymi i istnieniem wielu wersji obiektów.[3] Poszczególne etapy kontroli zmiany, moŝna podzielić na pewne fazy: Zarejestrowanie zmiany Klasyfikacja i analiza zmiany Przydzielenie odpowiedzialności za zmianę Implementacja zmiany Przegląd i zatwierdzenie zmiany Rejestracja zmiany wnioski o zmianę mogą pochodzić z wielu źródeł. Mogą być one zarejestrowane przez uprawnionego do tego członka zespołu programistów, lidera zespołu, osobę odpowiedzialną za przegląd oraz przez uŝytkowników. Formalna procedura rejestracji wniosków o zmianę, opiera się na udokumentowaniu takiego wniosku. W zaleŝności od rodzaju zmiany i jej stopnia komplikacji, dokumentacja formalna moŝe zostać pominięta i zostać oddana całkowicie pod kontrolę narzędzi. 28

29 Klasyfikacja i analiza zmiany po zarejestrowaniu zmiany moŝe zostać ona sklasyfikowana według przeróŝnych kryteriów, takich jak jej wpływ na system, stopień skomplikowania, koszt, ryzyko oraz sposób jej zatwierdzania. Przydzielenie odpowiedzialności za zmianę Zmiany które z pewnych powodów zostały odrzucone trafiają ponownie do inicjatora, natomiast te dla których analiza była niekompletna, zostają odesłane zespołowi odpowiedzialnemu za analizę. Pozostałe, zatwierdzone wnioski, są przydzielanie poszczególnym podzespołom. W praktyce przy małych zmianach, wszelkie kwestie przekazywania zadań są rozwiązywane przez narzędzia ZKO. Dysponują one takimi funkcjami jak automatyczne powiadamianie o zadaniach np. drogą poczty elektronicznej zawierającej wszelkie potrzebne szczegóły na temat danego wniosku. Implementacja zmiany Kopie zmienianych obiektów powinny zostać udostępnione do modyfikacji (checkout z repozytorium) a następnie zakodowane według wcześniej przygotowanego projektu technicznego. Całość zmiany zostaje przetestowana, a ewentualne poprawki w wyniku nieoczekiwanych rezultatów testów poprawione. Jeśli zmiana po stronie konkretnych komponentów, odzwierciedla zmiany w dokumentacji muszą one równieŝ zostać wykonane. Gotowe, przetestowane i zweryfikowane jednostkowo komponenty trafiają ponownie do repozytorium jako wersja bazowa. Przegląd i zatwierdzenie zmiany zatwierdzone modyfikacje, które zostały zakodowane, przetestowane i zatwierdzone w drodze przeglądu wewnętrznego, muszą zostać zatwierdzone globalnie. Wykorzystanie narzędzi ZKO znacznie przyspiesza i ułatwia proces logowania historii kaŝdego wniosku o zmianę Określanie statusu konfiguracji Określanie statusu konfiguracji jest obszarem związanym z zarządzaniem konfiguracją polegającym na logowaniu i raportowaniu wszelkich informacji potrzebnych do sprawnego zarządzania systemem. Odpowiedni system ewidencjonujący bieŝący status konfiguracji powinien w szczególności posiadać następujące informację: Aktualny status pojedynczych komponentów Odpowiedzialność za implementację poszczególnych wniosków o zmianę Priorytety i znaczenie krytyczne poszczególnych wniosków o zmianę Status wniosków o zmianę ZaleŜności związane z konkretnym wnioskiem o zmianę Znacznik czasowy w którym dany wniosek został zarejestrowany, zatwierdzony bądź odrzucony a takŝe kiedy zakończyła się jego implementacja Statystyki błędów i ich przyczyn Raporty róŝnić pomiędzy poszczególnymi wersjami konfiguracji Logowanie informacji potrzebnych do określania statusu konfiguracji, moŝe odbywać się przy uŝyciu dedykowanej bazy danych bądź repozytorium. Szczególnie waŝnym jest odnotowanie momentów czasowych rozpoczęcia i zakończenia dla poszczególnych cykli. Dane zapisywane w bazie statusu konfiguracji mogą obejmować: Datę wniosku o zmianę Dane identyfikujące wniosek o zmianę takie jak nazwa i numer wersji Dane osoby inicjującej wniosek o zmianę Dane identyfikujące zmieniane pozycje konfiguracji oraz jej kolejnej wersji 29

30 Moment rozpoczęcia projektu zmiany, przeglądu i zatwierdzenia Moment rozpoczęcia i zakończenia etapu kodowania i testów Znacznik czasowy stworzenia komponentów pochodnych (takich jak kod wykonywalny) Data integracji zmiany z systemem Repozytorium statusu powinno uwzględniać odpowiednie reguły bezpieczeństwa i autoryzację dostępu do danych. Niedopuszczalne jest zarówno zapisywanie informacji przez osoby do tego nieuprawnione, jak równieŝ odpytywanie bazy i generowanie poufnych raportów dotyczących konfiguracji systemu. Kolejnym istotnym aspektem jest generacja raportów kontrolnych. Raporty które są generowane na podstawie surowych danych, powinny spełniać konkretne funkcje oraz posiadać odpowiedni stopień przydatności, a takŝe uwzględniać takie czynniki jak: Zakres informacji umieszczonych na raporcie Częstotliwość generowania raportu Zespół lub grupa osób dla których przeznaczonych jest raport Tymczasowość (raport generowany na Ŝądanie) lub stałość raportu (raporty cykliczne) Raporty cykliczne zawierają zwykle informacje które naleŝy przeglądać i analizować okresowo oraz propagować do zainteresowanych osób. Raporty na Ŝądanie dotyczą natomiast informacji potrzebnych na daną chwilę. PoniŜsza tabela pokazuje kilka najczęściej uŝywanych raportów w podziale na ich typy. Raporty okresowe Status i historia prac nad wszystkimi aktywnymi wnioskami w systemie Raport postępu prac projektowych wraz z uwzględnieniem róŝnicy w stosunku do ostatnio wysłanego raportu i okres Lista i status istniejących w systemie pozycji konfiguracji Lista waŝnych zdarzeń projektowych uporządkowana chronologicznie takie jak rejestracja nowego dokumentu wymagań czy zmiana składu komitetu ZKO Raporty na Ŝądanie Lista wszystkich wniosków o zmianę Lista zaakceptowanych wniosków o zmianę Lista wniosków o zmianę będących obecnie w realizacji Lista wniosków oczekujących z ostatnich N miesięcy Liczba osób pracujących nad danym wnioskiem Czas potrzebny do implementacji wniosku Tabela 3.1 Przykładowe raporty w procesach określania statusu konfiguracji Z doświadczeń autora wynika, iŝ wykorzystanie zaawansowanych funkcji takich narzędzi, wiąŝę się niestety z wysokimi kosztami zakupu. Rozwiązania oferujące wszystkie opisane funkcje, zdolne do generowania wyrafinowanych raportów oraz pełną automatyzacje zadań mogą więc wymagać znacznego nakładu finansowego. 30

31 3.6. Zarządzanie Konfiguracją oprogramowania według metodyk i standardów Obecnie zarządzanie konfiguracją jest przedmiotem wielu opublikowanych na świecie dokumentów standaryzujących zarówno z obszaru przemysłu jak i oprogramowania komputerowego. Warto tutaj wspomnieć o kilku popularnych standardach, uŝywanych do opisu ogólnego zarządzania zmianami jak teŝ dotyczących stricte procedur Zarządzania Konfiguracją Oprogramowania. ISO 9001 Standard ten definiuje wymagania szczegółowe stawiane przed procesami, które spełniają pewne normy jakości. Mimo iŝ nie odnosi się on bezpośrednio do ZKO a jego zastosowania wiąŝą się głownie z wykorzystaniem w przemyśle, warto o nim wspomnieć, gdyŝ wprowadza on wiele pojęć znanych i uŝywanych w zarządzaniu konfiguracją. Koncentruję się nad takim zagadnieniami jak audyt i nadzorowanie obiegu dokumentów, kontrolowania jakości poprzez odpowiednie pomiary itd. Opisane czynności ujęte są przede wszystkim w kontekście przyszłej satysfakcji potencjalnego klienta z dostarczonego mu produktu. [3] ISO Dokument opisuje międzynarodowy standard, mogący być uszczegółowieniem wspomnianego wyŝej ISO 9001 oraz wprowadzającym termin Zarządzania konfiguracją. Dostarcza on ogólnego opisu zarządzania zmianami oraz definiuje procesy. Zarządzanie konfiguracją rozpatrywane jest w kontekście obszaru odnoszącego się do aspektów technicznych wytwarzania i wsparcia cyklu Ŝycia obiektów (pozycji konfiguracji). Głównym załoŝeniem jest konieczność dostarczenia pewnego scentralizowanego dokumentu (planu zarządzania konfiguracją), słuŝącego jako podręcznik projektowy i rozpropagowanego do osób zainteresowanych. Dodatkowe załączniki do standardu zawierają szablony tworzenia takiego planu. [3] EIA-649 Standard ten opisuje podstawowe zasady zarządzania konfiguracją w kontekście wytwarzania kodu. Cechą charakterystyczną tego dokumentu jest jego przejrzystość i przyjazny język. Zawiera on zbiór tzw. dobrych zasad i powszechnych praktyk, z punktu widzenia dobrze prowadzonego projektu. Wyjaśnia on krok po kroku znaczenie podstawowych obszarów ZKO, ich cele oraz moŝliwe korzyści z ich stosowania. Załącznik do standardu, zawiera dodatkowo listę 50 głównych zasad ZKO, które zostały omówione w dokumencie. [3] ANSI/IEEE Std-1042 Standard ten jest uwaŝany za jeden z najbardziej wyczerpujących i obszernych dokumentów traktujących o tematyce ZKO oraz wprowadzający podstawowe koncepcje i pojęcia. Opisuje on wdroŝenie procedur Zarządzania Konfiguracją w kontekście projektów programistycznych przy załoŝeniu podziału etapów na planowanie oraz implementację. Analitycy i menedŝerowie, wprowadzający procedury ZKO do projektu, mogą znaleźć gotowe scenariusze wdroŝeń oraz wskazówki i sugestie wskazujące sposób postępowania w konkretnych sytuacjach. [3] ANSI/IEEE Std-730 Dokument ten koncentruje się na tym aspekcie ZKO, jakim jest plan zarządzania jakością. Opisuje on standardy, jakie musi spełniać implementacja oprogramowania o znaczeniu krytycznym, przy czym wskazówki w nich zawarte mają równieŝ odniesienie do innych typów projektów. [3] ANSI/IEEE Std-1028 Podstawowym celem tego dokumentu jest definicja i szczegółowy opis wymagań dotyczących procesów przeglądu i nadzorowania zmian. Nie stanowi on sam w sobie wytycznych do tego, jakie jest kryterium wprowadzenia kontroli w danej organizacji, lecz moŝe stanowić wzorzec gotowych procedur i reguł postępowania, w zakresie audytu konfiguracji systemu. [3] IEEE/EIA Jest międzynarodowym standardem opisującym cykl Ŝycia oprogramowania w kontekście procesów ZKO. Zawiera opis zadań jakie powinny być wykonane podczas projektowania, 31

32 analizy, implementacji i konserwacji systemu. Dokument moŝe zostać wykorzystany do celów poprawy istniejących w danej organizacji procedur wytwarzania oprogramowania. Zarządzanie konfiguracją jest tu ujęte w kontekście jednego z procesów towarzyszących cyklowi Ŝycia oprogramowania, składającym się z takich zagadnień jak identyfikacja pozycji konfiguracji, definicji produktu bazowego czy kontrola zmian. [3] IEEE Std-828 Standard ten dotyczy szczegółowego opisu planu Zarządzania Konfiguracją Oprogramowania. Zakłada on, Ŝe zadania związane z ZKO, występują na kaŝdym projekcie a ich zdefiniowanie na etapie planowania, przyczynia się do wzrostu efektywności w fazie implementacji. Standard opisuje konieczność stworzenia centralnego dokumentu, zawierającego wytyczne w zakresie ZKO, który powinien być rozpropagowany wszystkim zainteresowanym stronom. IEEE Std-828 stanowi uzupełnienie dla standardu IEEE Std [3] Warto w tym miejscu przyjrzeć się bliŝej normie IEEE Std-828 opisującej precyzyjnie podstawowe postulaty i właściwości jakie powinien spełniać plan zarządzania konfiguracją (w tym cały cykl Ŝycia wersji oprogramowania oraz zakres czynności jakie powinny zostać wykonane aby norma została spełniona). Nadmienia on o potrzebie istnienia dokumentu zatytułowanego Zarządzanie konfiguracją i jego umiejscowienie w publicznie dostępnym dla pracowników projektu miejscu, opisie formatu, zakresie materiału obejmującego wytyczne itd. Dokument ten nosi tytuł Planu Zarządzania Konfiguracją i stanowi istotny element kaŝdego projektu, dla którego wdraŝane są procedury ZKO. Od czasu opublikowana standardu w roku 1990, został on dwukrotnie zastąpiony (w roku 1998 przez standard IEEE Std oraz stosunkowo niedawno przez IEEE Std ). Dokument pokrywa sześć głównych obszarów Planu Zarządzania Konfiguracją: I. Wprowadzenie Część ta zawiera informacje wprowadzające. Omawia cele do których norma została stworzona (zastosowanie w projektach, przeznaczenie). Definiuje podstawowe pojęcia takie jak: Plan Zarządzania konfiguracją Definicja produktu bazowego Pozycje konfiguracji W sekcji tej znajdziemy równieŝ odnośniki do innych dokumentów powiązanych ( w tym np. IEEE Std będący słownikiem terminów z zakresu inŝynierii oprogramowania). II. III. Zarządzanie Sekcja ta koncentruje się na określeniu zakresu odpowiedzialności oraz określeniu osób odpowiedzialnych za koordynację całego procesu. WaŜnym elementem określonym na tym etapie jest definicja ról pracowników, które dotykają obszaru zarządzania konfiguracją oraz zasady ich współpracy (z uwzględnieniem obowiązujących dyrektyw). Konieczne jest równieŝ określenie stosunku ZKO do innych obszarów zarządzania projektem oraz do całego cyklu wytwórczego. Czynności wchodzących w skład procesu zarządzania konfiguracją powinny uwzględniać czynniki zarówno z zakresu technologii jak i zarządzania. Generalnie są one podzielone na 4 grupy: Identyfikacja pozycji konfiguracji ( takich jak kod wykonywalny, dokumentacja uŝytkownika, narzędzia, kompilatory itd.) ale równieŝ identyfikacja kontroli wersji, standardów nazewnictwa. Kontrola czynności konfiguracyjnych powinna opisywać procedury wnioskowania o zmianę systemową, opis procesu rewizji takiej zmiany i jej wpływu na cały system. Przechowywanie zmian konfiguracyjnych sekcja ta powinna zawierać indeks pozycji konfiguracyjnych wchodzących w skład procedur przechowywania i śledzenia, sposobu archiwizowania artefaktów konfiguracyjnych. 32

33 Audyt opisuje cele przeglądu pozycji konfiguracji zanim wejdą one w skład produktu bazowego, uczestników i osoby uprawnione do procesu przeglądu oraz kryteria zatwierdzenia zmian. IV. Harmonogram procesu zarządzania konfiguracją w tym zakres odpowiedzialności za przebieg procesu na przestrzeni czasu i jego wpływ na pozostałe czynności projektowe, określenie kamieni milowych itd. Dopuszczalne jest wykorzystanie diagramów obrazujących przebieg harmonogramu. V. Zasoby opisuje zasoby sprzętowe, programowe, techniczne, ludzkie i inne, potrzebne do realizacji planu. KaŜdy zasób winien być jednoznacznie zidentyfikowany wraz z jego wpływem na cały proces w przypadku dostępności bądź jego braku. VI. Aktualizacja i zarządzanie planem informacje tu zawarte powinny ukazywać sposób aktualizacji PZK na przestrzeni czasu oraz dostarczać wskazówek na temat synchronizacji rzeczywistego przebiegu projektu, z faktycznymi wytycznymi zawartymi w planie. Opisując podejście istniejących standardów do dziedziny, jaką jest Zarządzanie Konfiguracją, nie sposób pominąć podejścia uŝywanego w metodyce ITIL (skrót odnosi się do IT Infrastructure Library). Biblioteka ITIL, stanowi zbiór wskazówek, czynności i najlepszych praktyk, jakie mogą zostać zastosowane w danej organizacji w celu usprawnienia ich usług. Narodziła się jako połączenie doświadczenia i pomysłów setek tysięcy osób, związanych z dostarczaniem i rozwojem usług szeroko pojętego sektora IT. Jednym z podstawowych paradygmatów tej metodyki, jest pomoc w podejmowaniu decyzji w taki sposób, aby zapewnić osobom które są za nie odpowiedzialne, odpowiednie wsparcie. [5] Biblioteka ITIL (w swoim drugim wydaniu) jest zasadniczo podzielona na dwa główne obszary dostarczanie usług oraz ich wsparcie. Obszar dostarczania usług opisuje takie aspekty jak: Zarządzanie poziomem usług Zarządzanie pojemnością usług Zarządzanie ciągłością usług Zarządzanie dostępnością usług Zarządzanie budŝetem Obszar wsparcia koncentruje się natomiast na: Organizacji kontaktowego punktu wsparcia (tzw. Service Desk) Procesach zarządzaniu defektami Zarządzaniu problemami Zarządzaniu zmianami Zarządzaniu wydaniami Zarządzaniu konfiguracją 33

34 4. Narzędzia wspomagające procesy Zarządzania Konfiguracją oprogramowania 4.1. Ogólna charakterystyka narzędzi ZKO Narzędzia wspomagające procesy zarządzania konfiguracji oprogramowania, mają obecnie kluczowe znaczenie w środowiskach rozwoju systemów, w których zespoły projektowe składają się nieraz z tysięcy osób rozproszonych w róŝnych regionach geograficznych. Narzędzia ZKO są obecnie dostępne na niemal kaŝdą platformę sprzętową i programową a rynek obfituje w tysiące wariantów oferujących zróŝnicowane moŝliwości. Zdaniem autora, taka mnogość rodzi ryzyko wyboru nieodpowiedniego narzędzia, a problemy które miało ono rozwiązywać, mogą stać się jeszcze bardziej znaczące. Początkowe projekty narzędzi ZKO, zakładały ich przeznaczenie do kontrolowania zmian w kodzie źródłowym. Pierwsze narzędzia UNIX-owe, zostały stworzone tylko i wyłącznie do kontroli zmian w kodu. Miały one bardzo ograniczoną funkcjonalność, bądź była ona stopniowo dodawana na przestrzeni czasu. Ewolucja koncepcji zarządzania konfiguracją, zrodziła potrzebę automatycznej kontroli czegoś więcej niŝ tylko zmiany w kodzie źródłowym oprogramowania. Dzisiejsze narzędzia słuŝące zarządzaniu konfiguracją, wspierają kontrolę dowolnych artefaktów projektowych, konfigurację procesów budowy produktu końcowego, wsparcie dla procesów kopiowania oprogramowania, udogodnienia i automatyzacje procesów wdroŝeniowych. Rynek generuję kolejne nowatorskie rozwiązana w zakresie narzędzi ZKO, a w projektach występuje tendencja do zastępowania moŝliwie jak największej liczby procesów wykonywanych ręcznie, na rzecz narzędzi w pełni automatyzujących te procesy. Przyczyną takiego stanu rzeczy jest przede wszystkim: Zmniejszenie kosztów rozwoju oprogramowania poprzez wyeliminowanie narzutu czasowego koniecznego do wykonania uciąŝliwych i powtarzalnych procesów, które dodatkowo mogą generować niepotrzebne błędy. Zapewnienie dostępu do istotnych, aktualnych informacji, dla odpowiednich osób w zaleŝności od ich potrzeb i zakresu odpowiedzialności. Automatyzacja procesów takich jak raportowanie, konfiguracja wydania, kontrole i przechowywanie kolejnych wersji komponentów, porównywanie i scalanie gałęzi rozwoju. Większa elastyczność biznesowa, uzyskana dzięki funkcjom dodatkowym narzędzi, takim jak automatyczne diagnozowanie i naprawianie problemów czy moŝliwość konfiguracji wydania produktu końcowego. Wraz ze wzrostem popularności narzędzi, rośnie takŝe tendencja do rozwoju i ulepszania narzędzi. Firmy zajmujące się rozwojem oprogramowania prześcigają się w stworzeniu produktu spełniającego oczekiwania klienta, a nieraz narzucające mu pewne standardy Funkcje narzędzi ZKO Ręczne wykonywanie większości typowych zadań związanych z ZKO stało się przeszłością. Manualne czynności konieczne do realizacji powtarzalnych zadań są monotonne, uciąŝliwe i dodatkowo czasochłonne. Wiele z nich, takich jak kontrola zmiany, logowanie historii zmian czy cykliczne raportowanie muszą zostać prędzej czy później zastąpione uŝyciem narzędzi. 34

35 W środowisku, w którym programista bądź analityk systemowy poświęca znaczną część swojego cennego czasu na dokumentację, rejestrację historii zmian, tworzenie raportów moŝna zauwaŝyć tendencje do spadku wydajności realizacji zadań kluczowych. Automatyzacja pozwala członkom zespołów programistycznych na efektywniejszą realizację zadań właściwych i przeniesieniu cięŝaru wykonania czynności, choć bardzo istotnych z punktu widzenia projektu to jednak schematycznych, na narzędzia konfiguracji oprogramowania.[3] PoniŜsze zestawienie prezentuje główne funkcje które powinny pełnić narzędzia pełniące funkcje zarządzania konfiguracją. Kontrola wersji naleŝy do głównych funkcji narzędzi ZKO. Przechowywanie wielu wersji umoŝliwia odtworzeniu stanu rozwoju oprogramowania w dowolnym momencie czasowym. KaŜde liczące się narzędzie powinno udostępniać funkcje wersjonowania takie jak zmiana i tworzenie nowych wersji składających się z plików bądź zbiorów. Narzędzia takie powinny grupować poszczególne wersje w pewien punkt konfiguracji, który razem moŝe tworzyć wydanie. KaŜda zmiana na rzecz obiektu powinna odzwierciedlać jego nową wersję bądź rewizję. Kontrola zmiany jest to funkcja którą powinny implementować nowoczesne narzędzia, w zakresie pełnego cyklu zmiany. Zmiana inicjowana wnioskiem powinna np. generować powiadomienie systemowe dla osób zainteresowanych, w celu jej analizy i weryfikacji. Nierzadko narzędzia udostępniają takie moŝliwości jak wirtualne spotkanie, wideokonferencje itd. Rozpoczęcie prac nad danym obiektem, moŝe zostać odnotowane w systemie, a kaŝda dalsza akcja podjęta na rzecz tego obiektu, moŝe być śledzona przed osobę nadzorującą. Większość obecnie uŝywanych w komercyjnych projektach narzędzi, umoŝliwia równoległe wprowadzanie zmian przy jednoczesnej ich kontroli. Równoległe gałęzie mogą zostać, w zaleŝności od podejścia, połączone w jedną lub teŝ stanowić niezaleŝne wobec siebie dystrybucje. Śledzenie problemów i defektów działania mające związek z wykrywaniem problemów które są podejmowane proceduralnie, są bardzo czasochłonne i skomplikowane. KaŜdy defekt powinien być przedmiotem specjalnego zgłoszenia, które to następnie naleŝy przeanalizować, naprawić itd. Narzędzia dysponujące bazą aktywnych i rozwiązanych problemów, ułatwiają analizę nowych zgłoszeń. Specjalny moduł danego narzędzia słuŝyć moŝe do śledzenia historii pojedynczego problemu od momentu powstania aŝ do momentu zakończenia, uwzględniając wszystkie detale takie jak stemple czasowe zdarzeń czy identyfikację osób odpowiedzialnych za ostatnie modyfikacje. Wsparcie budowy produktu finalnego kiedy proces implementacji zostaje zakończony następuje faza integracji wszystkich jego komponentów do odpowiedniej wersji wydania. Poszczególne moduły mogą zostać ponownie przekompilowane w róŝnych środowiskach, z róŝnymi parametrami. Budowa gotowego produktu lub jego części moŝe odbywać się na poziomie konkretnego modułu bądź teŝ systemu jako całości. W szczególności kaŝda pojedyncza konfiguracja powinna zostać zachowana, włączając w to takie dane jak wersje kompilatorów i linkerów, wersja i rodzaj systemu operacyjnego, bazy danych itp. MoŜe bowiem zaistnieć potrzeba odtworzenia produktu bazowego np. z fazy beta testów. Zbiór takich informacji jest na ogół przechwytywany a następnie zapisywany w sposób automatyczny dzięki takim mechanizmom jak badanie kodu źródłowego, analiza składni i uwzględnianie zaleŝności. Raportowanie i audyt w klasycznych procedurach zarządzania konfiguracją, rejestrowanie wszystkich czynności, które mogą być następnie wykorzystane w celach audytu, jest zwykle uciąŝliwe i czasochłonne. Zastosowanie funkcji automatycznego logowania zdarzeń i przechowywanie ich w specjalnych repozytoriach, nie wymaga Ŝadnej dodatkowej ingerencji ludzkiej. Jest ponadto dokładniejsze i szybsze. Zagregowane informacje przechowywane w bazach statusu konfiguracji, mogą słuŝyć jako dane do budowania bardzo zróŝnicowanych raportów, według kryteriów podanych 35

36 przez uŝytkownika. Raporty mogą być tworzone automatycznie lub na Ŝądanie, a ich forma wynikowa przedstawiona w postaci tabel czy wykresów. Są one podstawą do śledzenia postępu projektu, oraz rozliczania zespołów z wykonanych zadań. Funkcje autoryzacji poniewaŝ duŝa ilość zagregowanych informacji, zawierającej historię danego projektu stanowi cenne źródło wiedzy i zawiera dane poufne, dostęp do niej winien być ograniczony jedynie do odpowiedniego minimum. Nadzorowanie proceduralne dostępu do danych niebędących pod kontrolą Ŝadnego systemu, jest wysoce problematyczne. Obecnie niemal kaŝde narzędzie posiada mniej lub bardziej wyrafinowane funkcje autoryzacji i zabezpieczeń. Uzyskanie dostępu do informacji jest zapewnione przez zintegrowane mechanizmy takie jak monity logowania. UŜytkownicy nie muszą być świadomi szczegółów nadanych im uprawnień, a zakres dostępnych danych moŝe być na tej podstawie filtrowany i ograniczany. Funkcje autoryzacji są szczególnie istotne w narzędziach nadzorujących repozytoria, do których moŝna uzyskać dostęp za pomocą róŝnych kanałów dostępów takich jak aplikacja WEB Architektura systemów zarządzania wersjami Lokalna baza danych wersji - Zarządzanie wersjami komponentów oprogramowania, w swojej najprostszej postaci moŝe odbywać się bez kontroli jakichkolwiek narzędzi. W grę wchodzi wówczas wypracowanie odpowiedniej systematyki i reguł postępowania. W wielu projektach amatorskich stosowana jest metoda, polegająca na kopiowaniu plików do nowego katalogu, przy tworzeniu nowych rewizji. Katalogi mogą mieć takie atrybuty zaszyte w swojej nazwie jak stemple czasowe i numer kolejnej rewizji. Podejście to jest co prawda niezwykle proste, jednak naraŝone na błędy i nienadające się w praktyce do stosowania w projektach wieloosobowych. Pewnym rozwinięciem takiego podejścia jest wzorzec stosowany w architekturze pierwszych narzędzi słuŝących wersjonowaniu obiektów. Zasada działania opiera się na tworzeniu tzw. delty dla kaŝdego zmienianego komponentu i przechowywaniu jej w prostej bazie danych, pełniącej role repozytorium. Schemat działania tego podejścia, został przedstawiony na poniŝszym rysunku. Rysunek 7. Architektura lokalnego systemu wersjonowania plików Scentralizowane systemy kontroli wersji w celu umoŝliwienia współpracy wieloosobowej na rzecz tego samego projektu, został opracowany mechanizm oparty o klasyczną architekturę klientserwer. Polega on na udostępnieniu centralnego repozytorium danych i zapewnieniu dostępu do niego wszystkim zainteresowanym. Administrator repozytorium jest odpowiedzialny za jego utrzymanie, spójność oraz kontrolę praw dostępu uŝytkowników z niego korzystających. Programiści bądź inne 36

37 osoby dokonujące zmian w artefaktach projektu, łączą się z serwerem za pomocą wolnostojących aplikacji klienckich, aplikacji sieci WEB, bądź innych kanałów dostępu. Takie podejście jest na chwilę obecną najbardziej popularne wśród twórców oprogramowania i stanowi de facto standard w duŝych projektach komercyjnych. Model ten nie jest oczywiście pozbawiony wad. Istotnym problemem jest konieczność wykonywania częstych kopii zapasowych. Utrata centralnego repozytorium danych, moŝe się bowiem okazać niezwykle kosztowna. Pobranie(checkout) Pobranie(checkout) Rysunek 8. Architektura scentralizowanego systemu kontroli wersji Rozproszone systemy kontroli wersji alternatywą dla systemów scentralizowanych są systemy rozproszone. Zasada działania polega na istnieniu wielu, równoprawnych wersji repozytoriów lokalnych, utrzymywanych przez kaŝdą uczestnicząco w rozwoju oprogramowania jednostkę i stanowią w pewnym sensie backup tego repozytorium. Podejście takie posiada wiele istotnych zalet. KaŜdy z systemów moŝe utrzymywać dodatkowo wiele róŝnych repozytoriów oraz umoŝliwiać jednoczesną współpracę z róŝnymi grupami osób, w sposób zróŝnicowany. Wymiana Rysunek 9. Architektura rozproszonego systemu kontroli wersji 37

38 4.4. Charakterystyka wybranych narzędzi Obecnie na rynku oprogramowania zarówno komercyjnego jak i darmowego istnieje ogromna liczba narzędzi wspierających procesy zarządzania konfiguracją i kontroli wersji. Wybór tego właściwego, nie jest wbrew pozorom łatwym zadaniem, a ostateczna decyzja zaleŝy od rzeczywistych potrzeb uŝytkownika. Narzędzie stanowi jedynie ogniwo całego łańcucha i chociaŝ bardzo istotne jest jednak zaleŝne od reszty. Wybierając odpowiednie narzędzie moŝna kierować się dowolnymi kryteriami. Warto jednak wziąć pod uwagę co najmniej kilka z poniŝej wymienionych: Platforma sprzętowa dla której dostępne jest dane narzędzie Koszt narzędzia (w pełni darmowe, ograniczone sposobem uŝytkowania, komercyjne) Wydajność Dostępność dokumentacji i dodatkowe wsparcie MoŜliwość tworzenia gałęzi programowania i sposób ich późniejszej integracji Wsparcie dla procesów pracy MoŜliwość dostępu wielokanałowego w tym aplikacje Web, klient graficzny Rodzaj architektury (lokalna, scentralizowana, rozproszona) Wsparcie transakcyjności MoŜliwość integracji z innymi narzędziami lub środowiskami programistycznymi Sposób konfiguracji Funkcje automatyzacji zadań Dalsza część pracy, przedstawia opis kilku sztandarowych narzędzi reprezentujących róŝnorodność zarówno pod względem architektury, kosztów utrzymania jak i przeznaczenia. Narzędzia te były i są nadal uŝywane w wielu projektach. KaŜde z nich ma swoje grono, zarówno gorących sympatyków jak i przeciwników. Niektóre stały się standardem w pewnych kręgach, inne powoli wychodzą z uŝycia. Przykłady te nie wyczerpują oczywiście charakterystyki i mnogości wszystkich dostępnych rozwiązań Concurrent version system (CVS) System CVS jest obecnie jednym z najpopularniejszych systemów kontroli wersji udostępnionym na licencji General Public License (GPL), uŝywanym przez ogromną liczbę projektów programistycznych, w szczególności tych, o otwartym kodzie źródłowym. Jest składnikiem niemal wszystkich istniejących dystrybucji systemów Linux, dostępny na niemal kaŝdą z obecnie uŝywanych platform sprzętowych. Pozostaje ciągle w uŝyciu mimo zastąpienia go bardziej niezawodnym systemem SVN. Początkowa idea tego systemu, narodziła się z powstania zestawu skryptów, które były publikowane na grupach dyskusyjnych. Miały one na celu ułatwienie programistom wersjonowania ich kodu, udostępniając funkcjonalność róŝnicowania poszczególnych wersji plików. Algorytmy tam uŝywane, stały się następnie podstawą, istniejących w CVS mechanizmów. System moŝe być uŝywany do wielu zadań związanych z wersjonowaniem plików, takich jak administracja zawartością stron sieci Web czy przechowywanie historii wersji dokumentacji projektowej. Architektura zakłada podział na część kliencką i część serwerową. Serwer jest odpowiedzialny za utrzymanie centralnego repozytorium danych w którym przechowywane są wszelkie pliki kodów źródłowych danego projektu. Poszczególne aplikacje klienckie, mogą uzyskiwać połączenie z serwerem. Tworzenie kopii repozytorium (checkout), wymaga utworzenia odpowiedniej struktury katalogów na dysku lokalnym. Centralne repozytorium, jest odpowiedzialne za przechowywanie kopii wszystkich wykorzystywanych plików i struktur katalogów podlegających wersjonowaniu. Dostęp do niego nigdy nie jest uzyskiwany 38

39 bezpośrednio, lecz za pomocą aplikacji klienckiej. Zasadniczo istnieją dwie metody dostępu do repozytorium lokalna i zdalna. Domyślną ścieŝką dostępu do danych jest ścieŝka lokalna, znajdująca się w uprzednio ustalonej lokalizacji na dysku ( w systemach Unix i Linux struktura nadrzędna zapisywana jest zwykle w katalogu /usr/local/cvsroot). Struktura repozytorium składa się z plików administracyjnych przechowujących meta dane oraz pozostałe informacje charakterystyczne dla kaŝdego poddrzewa oraz części właściwej, składującej wersje poszczególnych plików. Architektura zakłada odseparowanie danych dostępnych do wewnętrznego uŝytku repozytorium, poprzez nadanie plikom rozszerzenia z suffixem,v, a takŝe zapewnieniem odpowiednich praw dostępu do tych plików. Pomimo duŝej popularności, prostoty uŝytkowania, darmowej licencji oraz wykorzystania systemu w wielu projektach zakończonych sukcesem (takich jak projekt interpretera skryptów PHP oraz PERL czy teŝ serwera WWW Apache), nie jest on pozbawiony wad. Do głównych niedogodności naleŝą: Zmiana nazw plików i katalogów jest w CVS znacznie utrudniona lub wręcz niemoŝliwa zaś mechanizmy przenoszenia cały struktur drzew katalogów w ogóle nie istnieją System nie wspiera backupu danych repozytorium Niedostatecznie dobra identyfikacja meta danych, powoduje problemy z wersjonowaniem plików binarnych, konwencją znacznika końca linii czy teŝ niepoprawną obsługą dowiązań symbolicznych w systemach klasy Unix Aktualizacja repozytorium nie jest atomowa zmiana danych repozytorium która zostanie przerwana (np. w skutek zerwania połączenia sieciowego) powoduję utratę spójności danych repozytorium Subversion (SVN) System Subversion powstał jako alternatywa mająca zastąpić przestarzałe i niedoskonałe narzędzie jakim było CVS. Zasadniczo posiada on znaczną większość jego funkcji, udostępniając dodatkowo szereg ulepszeń: Wersjonowanie katalogów i operacji zmiany nazw oraz ścieŝek zasada działania CVS opierała się na mechanizmie wersjonowania jedynie pojedynczych plików. Subversion jest w stanie wersjonować całe struktury katalogów. Wady jakie posiadało CVS takie jak brak moŝliwości utworzenia pustego katalogu w strukturze projektu, czy teŝ niemoŝliwość zmiany ich nazw. Wersjonowanie meta danych meta dane przechowują takie informacje o projekcie jak sposób kodowania znaków końca linii w plikach tekstowych, czy teŝ parametry kontroli dostępu. Dzięki architekturze SVN kaŝda zmiana tych danych moŝe zostać zapisana w historii. Atomowość zmian w repozytoriach w kontekście zapisywania danych do repozytorium, oznacza to kontrolę jego aktualizacji i zapisywanie wszystkich zmian w ramach jednej operacji lub Ŝadnej z nich. Jeśli zostanie wykonane Ŝądanie zatwierdzenia nowych wersji duŝej ilości plików jednocześnie, a operacja taka moŝe zajmować znaczącą ilość czasu, wtedy system zadba o to aby zasoby na ten czas zostały zablokowane a równoległa aktualizacja tych samych zbiorów niemoŝliwa. Ulepszone mechanizmy przechowywania danych w repozytorium tworzenie nowych gałęzi rozwoju komponentów, bądź całych drzew, zajmuje duŝo mniejszą ilość przestrzeni dyskowej a takŝe innych zasobów takich jak czas procesora, potrzebnych do jej wygenerowania Natywna architektura klient serwer w związku z tym Ŝe SVN od początku powstawał jako system mający spełniać z góry załoŝone oczekiwania uŝytkowników, jego architektura została zaprojektowana w tej konwencji. Granice pomiędzy poszczególnymi warstwami są jasno 39

40 zdefiniowane, kaŝda warstwa jest podzielona na odpowiednie biblioteki co ułatwia wprowadzanie modyfikacji i dodatkowych funkcji. Protokół komunikacyjny pozwala na synchronizację wprowadzanych zmian, poprzez porównywanie wersji występującej na repozytorium centralnym oraz lokalnym. Porównanie to jest sprawdzane na podstawie wysyłania jedynie róŝnicy pomiędzy wersjami, co znacznie zmniejsza ilość wysyłanych danych. Wielojęzyczność separacja plików przechowujących komunikaty systemu, pozwala społecznościom na samodzielne tłumaczenie i publikację wielojęzycznych interfejsów. Ulepszone mechanizmy wersjonowania plików binarnych i tekstowych problem z wersjonowaniem plików binarnych stanowił jedną z największych słabości narzędzia CVS. Poprawność obsługi w SVN, uzyskano poprzez dodatkowe mechanizmy kontroli udostępnione na poziomie klienta oraz efektywne przechowywanie róŝnic w plikach binarnych repozytorium bez konieczności utrzymywania kaŝdej kopii osobno. Architektura systemu jest oparta o kilka, niezaleŝnych od siebie warstw. KaŜda z nich posiada specjalny interfejs programistyczny (API), umoŝliwiający programistom dodawanie nowych funkcjonalności, protokołów czy aplikacji klienckich, bez wpływu na pozostałe obszary systemu. PoniŜszy rysunek obrazuje podział pomiędzy poszczególnymi warstwami: Rysunek 10. Architektura systemu Subversion [I3] 40

41 4.4.3 Git Projekt aplikacji Git został zainicjowany przez Linusa Torvaldsa. Jego celem było stworzenie narzędzia kontroli wersji, w architekturze rozproszonej, którym moŝna było zastąpić aplikację Bitkeeper uŝywaną przez twórców jądra systemu Linux jako systemu kontroli wersji. Głównymi załoŝeniami przy tworzeniu nowego systemu były: Architektura rozproszona Prostota uŝytkowania Wysoka wydajność Wysoki stopień wsparcia dla nieliniowego, równoległego rozwoju oprogramowania składającego się z bardzo duŝej ilości gałęzi Większość czynności które moŝna wykonać pracując na kodzie kontrolowanym przez Git, wymagania jedynie dostępu do lokalnej kopii danych. Jest to zasadnicza róŝnica w stosunku do systemów scentralizowanych, gdzie kaŝda operacja jest związana z pewnym dodatkowym narzutem koniecznym na uzgodnienie zmian z repozytorium centralnym. W szczególności przechowywana lokalnie jest historia zmian wykonanych na rzecz obiektów a odtworzenie poprzedniej wersji obiektu, odbywa się na podstawie lokalnego obliczenia zmian na podstawie delty. KaŜda zmiana na rzecz danego obiektu, wymaga takŝe wyliczenia jego sumy kontrolnej (za pomocą algorytmu SHA-1). Integracja tych mechanizmów kontroli danych w systemie, umoŝliwia wykrycie potencjalnych uszkodzeń danych. Wersjonowanie plików będących pod kontrolą Git, opiera się o trzy stany w jakich moŝe znajdować się obiekt: Zatwierdzony stan ten wskazuje na zgodność pliku lokalnego z repozytorium Zmodyfikowany obiekt został zmodyfikowany ale nie zatwierdzony w repozytorium Oznaczony stan ten opisuje obiekt, na rzecz którego wykonano modyfikację, nie zatwierdzono go jeszcze w repozytorium, jednak zostanie ono wykonane podczas następnej operacji commit Katalog główny Git przechowuje bazę obiektów właściwych oraz ich meta danych. Dane te są kopiowane bezpośrednio podczas wykonywania kopii zapasowych oraz importowane w przypadku pobierania (operacji klonowania) repozytorium z innego ogniwa projektu. Katalog obiektów oznaczonych do zmian jest de facto plikiem płaskim, znajdującym się w katalogu głównym, przechowującym listę obiektów przeznaczonych do zatwierdzenia podczas wykonania kolejnej operacji commit. Katalog roboczy stanowi kopię pojedynczej rewizji danego repozytorium. Dane znajdujące się w tym katalogu są uzyskiwane na podstawie zawartości głównej bazy lokalnej, z danych skompresowanych. Scenariusz modyfikacji danych wygląda następująco: I. UŜytkownik dokonuje modyfikacji obiektów w katalogu roboczym II. Dane modyfikowane są oznaczane jako przeznaczone do zatwierdzenia III. Następuje zatwierdzenie (operacja commit) a dane z katalogu roboczego są przenoszone do głównego repozytorium lokalnego ZaleŜności pomiędzy obszarami repozytorium oraz operacjami wykonywanymi na jego rzecz przedstawia poniŝszy rysunek: 41

42 Rysunek 11. Operacje wykonywane na lokalnym repozytorium Git. [8] KaŜdy obiekt znajdujący się repozytorium głównym, jest obiektem zatwierdzonym. KaŜdy które uległ zmianie i będzie do niego dodanym (w zaleŝności od tego czy informacja o tym została juŝ zapisana), uznaje się za zmodyfikowany IBM Rational ClearCase / ClearQuest Pakiet narzędzi dostarczanych przez IBM, jest liderem wśród aplikacji komercyjnych słuŝących zarządzaniu konfiguracją. Dostarcza on zaawansowane rozwiązania zania dostosowane do wielu typów projektów, w zaleŝności od ich specyfiki i potrzeb. Pokrywa on takie obszary narzędziowe ZKO jak: Kontrola wersji obiektów Kontrola konfiguracji systemu Niektóre aspekty zarządzania projektem w kontekście ZKO Funkcjonalność pakietu wykracza poza zakres podobnych narzędzi dostępnych bez opłat licencyjnych. Poza standardowymi funkcjami kontroli wersji i konfiguracji, pakiet ClearCase moŝe zostać skonfigurowany jako narzędzie kontrolujące procesy pracy. Wykorzystanie pełnych moŝliwości tego narzędzia nie jest oczywiście cie moŝliwe, bez odpowiedniego nakładu pracy, związanego z planowaniem ZKO a następnie odpowiednim dostosowaniu go do potrzeb projektu. ZaleŜy to od takich czynników jak stopień skomplikowania i rozmiar projektu, liczba etapów wchodzących cych w skład zmiany, liczba osób zaangaŝowanych w rozwój systemu itd. Elastyczność narzędzi z rodziny IBM Rational, opiera się między innymi na praktycznie nieograniczonych moŝliwościach skalowania, tworzenia scenariuszy, identyfikacji dowolnych pozycji konfiguracji za pomocą odpowiednich skryptów. Pakiet narzędziowy Rational ClearQuest jest dostępny w trzech wariantach: ClearCase LT jest wersją podstawową pakietu wspierającą najwaŝniejsze funkcjonalności i procesy ZKO. Jest jednocześnie stosunkowo łatwy do wdroŝenia i uŝytkowania a jego instalacja moŝe opierać się o prosty serwer, pochłaniający cy rozsądną ilość zasobów. Repozytorium będące pod kontrolą tego wariantu, wspiera wszystkie najwaŝniejsze operacje takie jak powrót do poprzedniej konfiguracji systemu i moŝliwość odtworzenia dowolnego punktu konfiguracji. 42

43 ClearCase wspomaga procesy kontroli zmiany w duŝych środowiskach, umoŝliwia zespołom projektowym kontrolowanie wymagań, kodu źródłowego, dokumentacji, skryptów testowych i innych artefaktów. Wspiera dodatkowo procesy pracy i konfigurację procesów budowy finalnego produktu. ClearCase MultiSite kładzie nacisk na wspomaganie procesów równoległego wytwarzania oprogramowania przez duŝe, rozproszone zespoły projektowe. Posiada wbudowane mechanizmy automatycznej repliki repozytoriów oraz naprawy błędów danych. Pakiet ClearQuest słuŝy z kolei do kontroli i śledzenia zmian oraz defektów. MoŜe zostać uŝyty jako samodzielne narzędzie lub w połączeniu z pakietem ClearCase, stanowiąc rozwiązanie w zakresie czterech głównych obszarów - kontroli wersji, kontroli konfiguracji, kontroli procesów, kontroli defektów. Narzędzia Rational zbudowane są w oparciu o architekturę klient-serwer. System wspiera istnienie więcej niŝ jednego serwera. KaŜdy z nich pełni rolę hosta zarządzania konfiguracją. PoniŜszy rysunek prezentuję architekturę sieciową rozwiązania: Rysunek 12. Przykładowa infrastruktura systemowa narzędzia IBM Rational ClearCase KaŜdy element struktury sieciowej aplikacji Rational ClearCase pełni określoną rolę: Stacja kliencka korzysta z niej kaŝdy uŝytkownik pracujący w środowisku ClearCase, uruchamiając aplikacje dostępowe z graficznym interfejsem uŝytkownika, lub te wywoływane z wiersza poleceń Serwer repozytorium stacja mogąca przechowywać replikę repozytorium danych (serwer typu VOB) lub zmaterializowane perspektywy uŝywane w zapytaniach (serwer VIEW) Serwer licencji kaŝde środowisko projektowe korzystające z pakietu Rational, musi posiadać specjalny serwer, który na podstawie typu licencji, udostępnia zestaw akcji moŝliwych do wykonania. KaŜda aplikacja, zarówno kliencka jak i serwerowa, musi zostać skojarzona z odpowiednim serwerem licencji w celu jej prawidłowego działania Serwer rejestru pełni on rolę lokalizatora zasobów współdzielonych takich jak repozytoria danych Serwer Web udostępnia on wszelkie usługi, uruchamiane za pośrednictwem aplikacji sieci Web Serwer NAS urządzenia typu NAS (Network Attached Storage) pełnią rolę pamięci dyskowych, które mogą zostać podłączone bezpośrednio do sieci. W środowisku Rational 43

44 serwer pełni funkcję interfejsu z danymi, umoŝliwiając innym aplikacjom ClearCase uzyskanie dostępu do tych danych Serwer dostępowy dla systemów klasy UNIX systemy oparte na architekturze UNIX, które mają ograniczony dostęp do aplikacji klienckich, mogą dzięki temu serwerowi, uzyskać dostęp do danych z wykorzystaniem standardowych funkcji sieciowego systemu plików Pomimo ogromnych moŝliwości jakie zapewnia pakiet IBM Rational nie jest on pozbawiony pewnych istotnych wad: Zintegrowany system plików uŝywany jako nośnik repozytorium jest znacznie wolniejszy od standardowych systemów plików oraz dodatkowo moŝe powodować problemy podczas aktualizacji systemu do nowszej wersji Wysokie koszty licencji systemu Wysoki koszt potrzebnych zasobów instalacja i utrzymanie środowiska wymaga uruchomienia wyspecjalizowanych oraz wydajnych stacji roboczych, nawet w przypadku niewielkich zespołów, a do ich administracji nierzadko potrzebny jest wykwalifikowany personel 44

45 5. Opis narzędzi uŝytych do realizacji części praktycznej Niniejszy rozdział stanowi wstęp do opisu szczegółów implementacji rozwiązania, będącego prototypem narzędzia słuŝącego do Zarządzania Konfiguracją Oprogramowania. Opisuje on poglądowo najwaŝniejsze technologie, pakiety narzędziowe, systemy i biblioteki, wykorzystane w implementacji Java Język Java Java, jest obiektowym językiem programowania, opartym o składnie przypominającą języki z rodziny C/C++. Został zaprojektowany i zaimplementowany przez firmę Sun Microsystems. Na temat języka Java, powstała ogromna liczba publikacji o charakterze naukowym i dydaktycznym. Ilość ta wciąŝ rośnie, co ma bezpośredni związek z niesłabnącą popularnością tego języka, mimo silnej konkurencji ze strony innych korporacji promujących własne rozwiązania, takich jak Microsoft. Java stała się standardem przemysłowym twórców oprogramowania z róŝnych dziedzin i zakresów, jest przedmiotem wykładanym obowiązkowo na wielu kierunkach informatycznych a rynek pracy poszukuje wykwalifikowanych specjalistów, posiadających odpowiednie certyfikaty z zakresu rozwiązań firmy Sun. Opisanie wszelkich aspektów zarówno języka jak i samej szeroko pojętej technologii, wykracza poza zakres tej pracy. Do najwaŝniejszych cech Javy naleŝą: NiezaleŜność od platformy systemowej i sprzętowej dzięki zastosowaniu technologii opartej o tzw. maszynę wirtualną (VM Virtual Machine) programy napisane w języku Java, mogą zostać bez rekompilacji uruchomione na dowolnej platformie na której zainstalowano VM Pełna obiektowość układ poszczególnych jednostek aplikacji, wymusza przechowywanie kaŝdego obiektu w osobnej klasie zaś kaŝdy obiekt (łącznie z obiektami typów prostych) dziedziczy po klasie nadrzędnej. Innowacją twórców języka jest ponadto wprowadzenie interfejsów, które pozwalają zdefiniować pewien określony zbiór operacji jakie klasa jest w stanie wykonać (mechanizm ten powstał w wyniku zastąpienia koncepcji wielo-dziedziczenia znanego z języka C++). Silna kontrola typologiczna mimo rosnącego trendu i szerzącej się popularności języków posiadających słabą kontrolę typów (takich jak Ruby, PHP czy Python) Java pozostaje przy paradygmacie silnej kontroli typologicznej. Dzięki takiemu podejściu, wiele błędów moŝe zostać wykrytych juŝ na etapie kompilacji programu. Bogaty zbiór bibliotek dostarczanych wraz z dystrybucją hierarchia pakietów i klas jest skonstruowana w sposób pozwalający programiście na szybkie i bezproblemowe korzystanie z dołączonych do dystrybucji bibliotek, poprzez dołączenie stosownej deklaracji w nagłówku obiektu. Bezpieczeństwo i niezawodność cel ten został osiągnięty między innymi za pomocą silnie zintegrowanego mechanizmu wyjątków. Poza zintegrowanymi wyjątkami występującymi dla zdarzeń takich jak przekroczenie rozmiaru tablicy, próba czytania nieistniejącego pliku bądź niezgodność typów w wyniku niepoprawnej operacji przypisania, mechanizm Javy wymusza takŝe deklarację bądź implementację nowych wyjątków zwracanych przez obiekty. Zintegrowany mechanizm zwalniania zaalokowanej pamięci dzięki rozwiązaniu zaimplementowanemu w maszynie wirtualnej, programista jest zwolniony z obowiązku kaŝdorazowego zwalniania zaalokowanych zasobów. Dzięki temu kod staje się bardziej 45

46 przejrzysty, a takŝe spada współczynnik prawdopodobieństwa popełnienia niepotrzebnych błędów. Dostępność mechanizmów refleksji program moŝe być modyfikowany w trakcie wykonania na podstawie własnego kodu, co pozwala np. na tworzenie konstrukcji semantycznych uŝytkownika czy uzyskanie informacji o klasach w momencie wykonywania programu. Nie bez znaczenia są równieŝ pewne wady tego języka, jak chociaŝby stosunkowo mniejsza wydajność aplikacji działających pod kontrolą maszyny wirtualnej. Prawdą jest równieŝ stwierdzenie, Ŝe język ten nie nadaję się do absolutnie wszystkich zastosowań (przykładem mogą być tu aplikacje czasu rzeczywistego, czy teŝ pewne obszary programowania systemowego) Środowisko programistyczne Eclipse Efektywna implementacja nie była by moŝliwa bez wykorzystania odpowiedniego środowiska programistycznego (IDE) dla języka Java. Do tego celu autor wybrał jedno z najbardziej znanych i najpopularniejszych środowisk przeznaczonych do tworzenia aplikacji w języku Java, jakim jest Eclipse. Projekt został początkowo zainicjowany przez firmę IBM, a następnie wspierany jako wolne oprogramowanie przez Eclipse Foundation. Obecnie Eclipse jest zintegrowanym środowiskiem programistycznym działającym na niemal kaŝdej dostępnej platformie (pod warunkiem zainstalowania na niej wirtualnej maszyny Java). Rdzeń aplikacji nie stanowi co prawda w pełni funkcjonalnego IDE dla konkretnego języka programowania, jednak dzięki dostępności wtyczek, moŝna w nim rozwijać aplikacje w takich językach jak C/C++, Java, PHP. Istnieją nawet wtyczki rozszerzające moŝliwości pakietu o wsparcie języków spadkowych takich jako COBOL. Wygoda i jednocześnie ogromne moŝliwości, sprawiły Ŝe Eclipse stało się niezwykle popularne, dzięki takim funkcją jak: Gotowe wzorce kodu (funkcje, szablony klas) Hierarchiczna reprezentacja obiektów w postaci drzewa Wbudowane debuggery w ramach poszczególnych dystrybucji Ewaluacja elementów kodu ad-hoc Podpowiadanie składni (code snippets) Wsparcie narzędzi refaktoringu Automatyczne rozwiązywanie reguł zaleŝności pakietów Ogromne moŝliwości rozszerzania dzięki zaawansowanemu mechanizmowi wtyczek Warto równieŝ wspomnieć o istnieniu wtyczek, słuŝących jako interfejs do narzędzi wersjonowania kodu takich jak sublcipse. PoniŜszy ekran prezentuje przykładowy wygląd obszaru roboczego projektu na przykładzie codesnippeta: 46

47 Rysunek 13. Przykład działania mechanizmu podpowiedzi składni w środowisku Eclipse 5.2. Technologie Microsoft Język C# C# jest obiektowym językiem programowania, opracowanym przez firmę Microsoft. Jego składnia jest bardzo podobna do takich języków jak C/C++ czy Java. Sama konstrukcja platformy systemowej równieŝ zawiera wiele elementów charakterystycznych dla Javy. NajwaŜniejsze elementy języka to m.in.: Istnienie w hierarchii obiektów dziedziczonych jednego obiektu nadrzędnego (klasy object) Mechanizmy refleksji umoŝliwiające analizę kodu i jego modyfikację w czasie wykonania programu Brak konieczności zarządzania pamięcią (brak arytmetyki wskaźnikowej) obiekty usuwane są przez mechanizm odśmiecający Typy parametryzowane, parametryzowane kolekcje (tzw. generics ) Rozbudowana biblioteka wbudowanych klas Aplikacje napisane w języku C# są niezaleŝne od platformy systemowej. KaŜdy program jest kompilowany do kodu pośredniego (w języku Common Intermediate Language będącego swego rodzaju odpowiednikiem asemblera). Kod taki moŝe zostać następnie wykonany w przygotowanym do tego celu środowisku uruchomieniowym (obecnie dominującym jest.net Framework który w momencie pisania pracy doczekał się wersji 4.0, istnieją jednak inne implementacje takie Mono czy DotGNU) Środowisko programistyczne Microsoft Visual Studio Podobnie jak w przypadku części prototypu systemu napisanej w języku Java, autor posłuŝył się jednym z dostępnych dla języka C#, środowisk programistycznych (IDE) Microsoft Visual Studio w wersji Środowisko to zostało stworzone i jest wspierane niezmiennie jako produkt firmy Microsoft. Pakiet łączy w sobie moŝliwość tworzenia aplikacji (poza samym C#) w róŝnych językach programowania takich jak: 47

48 Microsoft Visual Basic Microsoft Visual C++ Microsoft Visual J# (wariant Javy) Microsoft Visual Web Developer ASP.NET (skryptowy język do tworzenia aplikacji internetowych) Pakiet oferuje standardowe funkcje charakterystyczne dla tego typu narzędzi m.in.: Kolorowanie składni kodu źródłowego Narzędzia refaktoringu Podpowiadanie składni Funkcje analizy istniejącego kodu Generator diagramów klas Wbudowany debugger Zdaniem autora są one jednak mniej intuicyjne i przejrzyste od tych, które oferuję pakiet Eclipse. Rysunek 14. Okno główne środowiska programistycznego Microsoft Visual Studio Windows Presentation Foundation Pakiet Windows Presentation Foundation (WPF), jest zbiorem bibliotek wchodzących w skład platformy Microsoft.NET od wersji 3.0. Pełnią one funkcję silnika oraz interfejsu dostępowego (API) słuŝącego do opisu bogatego interfejsu uŝytkownika (UI), grafiki, multimediów etc. Podstawowym sposobem definicji elementów interfejsu (poza deklaracją bezpośrednio w kodzie aplikacji), jest i opis za pomocą specjalnego języka opartego o XML XAML (extensible Application Markup Language). 48

49 Język XAML znacznie ułatwia definicję elementów interfejsu uŝytkownika, pozwalając na odseparowanie logiki aplikacji od warstwy prezentacyjnej. Są one tworzone w plikach o rozszerzeniu *.xaml naleŝących do danego okna lub jego części. Poza standardową moŝliwością definicji danego interfejsu w fazie budowania aplikacji, technologia umoŝliwia ładowanie elementów XAML w czasie wykonania aplikacji. Rozwiązanie takie umoŝliwia np. dynamiczne stworzenie interfejsu uŝytkownika bądź jego części, po stronie serwera i jego wykorzystanie przez klienta w zaleŝności od kontekstu. Przykładowa deklaracja kontrolki składającej się z przycisku jest trywialna: <UserControl x:class="cmtclient.views.usercontrol1" xmlns=" xmlns:x=" Height="100" Width="300"> <Button Height="50" Name="Button" Width="75">Button</Button> </UserControl> Rysunek 15. Wyświetlenie kontrolki WPF Button zadeklarowanej z poziomu języka XAML Bardzo istotnym udogodnieniem (wykorzystywanym przez autora niejednokrotnie w implementacji prototypu systemu) jest moŝliwość wiązania elementów UI z modelem danych, takich jak pola składające się z typów prostych, kolekcje obiektów, triggery zdarzeń. PoniŜszy przykład pokazuję wiązanie kolekcji drzewa (TreeNode) udostępniającą metodę listowania węzłów potomnych (ChildNodes), z kontrolką WPF klasy TreeView. <TreeView Name="tree" ItemsSource="{Binding ChildNodes}"> <TreeView.Resources> <ResourceDictionary> <HierarchicalDataTemplate DataType="{x:Type mina:treenode}"> <views:queryview /> </HierarchicalDataTemplate> </ResourceDictionary> </TreeView.Resources> </TreeView> Rysunek 16. Kontrolka TreeView propagowana treścią kolekcji TreeNode 49

50 5.3. Obiektowa baza danych ODRA Projekt obiektowej bazy danych ODRA (Object Database for Rapid Application development) powstał w wyniku prac badawczych zespołu projektowego pod kierunkiem prof. dr hab. inŝ. Kazimierza Subiety. System został zaimplementowany w całości w języku Java. Obiektowa baza danych jest rozwiązaniem innowacyjnym, w stosunku do dominującego obecnie standardu jakim są relacyjne systemy baz danych. Cechy charakterystyczne systemu to przede wszystkim: Obiektowość system w pełni implementuje wszelkie mechanizmy charakterystyczne dla podejścia obiektowego w tym klasy, dziedziczenie obiektów, kolekcje itd. Zintegrowany język zapytań SBQL (Stack-Based Query Language) umoŝliwia wykonywanie intuicyjnych zapytań, będących integralną częścią języka programowania co eliminuje problem tzw. impedancji, bez zbędnego narzutu na dodatkową i niepotrzebną składnię Elastyczna architektura sieciowa umoŝliwiająca współistnienie wielu repozytoriów danych działających w róŝnych środowiskach oraz moŝliwość połączenia serwera z wieloma klienta i odwrotnie Zintegrowana optymalizacja zapytań wykorzystująca mechanizmy takie jak indeksy czy teŝ przebudowa drzewa syntaktycznego zapytania Wirtualne perspektywy z pełnymi moŝliwościami aktualizacji podejście zastosowane w systemie ODRA opiera się na zasadzie definiowania operacji takich jak tworzenie, aktualizacja i usuwanie, jako część składowa perspektywy określona przez jej twórcę. Jest to zasadnicza zmiana w stosunku do rozwiązań znanych np. z języka SQL czy teŝ jego odmian zaimplementowanych w róŝnych systemach relacyjnych, które czynią perspektywy mało elastycznymi MoŜliwość dostępu do repozytorium z poziomu języków takich jak Java czy C# - dzięki bibliotece JOBC/NOBC Osobną gałąź projektu, stanowi zintegrowane środowisko programistyczne (IDE) wyposaŝone w edytor tekstowy obsługujący składnię poleceń SBQL oraz umoŝliwiający bezpośrednie połączenie z danym serwerem i wybór modułu a takŝe wykonywanie zapytań. Szczegółowy opis podejścia stosowego do języków zapytań oraz funkcjonalności systemu Odra, wykracza poza zakres tej pracy Inne narzędzia i biblioteki Biblioteka SVNKit Biblioteka SVNKit stanowi interfejs programistyczny z niemal wszystkimi dostępnymi funkcjami bibliotek SVN, które oryginalnie zostały napisane w języku C. Do najwaŝniejszych funkcji biblioteki naleŝą: Dostęp do repozytoriów z uŝyciem notacji URL Administracja repozytorium (dostęp do operacji narzędzia svn admin ) MoŜliwość uruchomienia niezaleŝnie od platformy sprzętowej MoŜliwość wykorzystania istniejących plików konfiguracyjnych SVN Częste aktualizację biblioteki zgodne ze zmianami w narzędziu SVN 50

51 Rysunek 17. Koncepcja biblioteki SVNKit [I2] Apache MINA Apache MINA (Multipurpose Infrastructure for Network Applications) jest frameworkiem stanowiącym szkielet komunikacji dla aplikacji sieciowych. Udostępnia generyczne interfejsy umoŝliwiające w uproszczony sposób, zaimplementowanie aplikacji serwerowych i klienckich z wykorzystaniem dowolnych protokołów. Podstawowymi cechami biblioteki są: Mechanizm komunikacji asynchronicznej opartej zbudowany w oparciu o bibliotekę Java NIO Jednolity interfejs programistyczny umoŝliwiający komunikację nisko poziomową (dekodowanie tablic bajtów) jak i wysoko poziomową (obiekty zdefiniowane przez uŝytkownika) MoŜliwość wykorzystania popularnych protokołów (TCP/IP, UDP) jak równieŝ implementacja własnego Konfigurowalny model podziału wątków pracy serwera MoŜliwość przechowywania obiektów w kaŝdej sesji klienta z osobna Wbudowane mechanizmy szyfrowania Integracja z frameworkami aplikacji Java takimi jak Spring Apache Commons Apache Commons stanowi zbiór bibliotek składających się z komponentów wielokrotnego uŝytku, realizujących szereg często wykonywanych zadań. Niektóre z nich stanowią rozszerzenie standardowych pakietów Javy (np. rozbudowane kolekcje, zmieniona obsługa typów prostych języka, 51

52 operacje na plikach) lub realizują bardziej złoŝone funkcjonalności (uniwersalne API logowania, kompresja i archiwizacja plików, przetwarzanie danych konfiguracyjnych, parser komend wiersza poleceń). Biblioteki w ramach Apache Commons moŝna podzielić na trzy obszary w zaleŝności od stadium ich rozwoju: Commons Prope obszar bibliotek stabilnych Commons Sandbox obszar bibliotek rozwojowych Commons Dormant obszar bibliotek spadkowych 52

53 6. Prototyp narzędzia ZKO 6.1. ZałoŜenia i zarys rozwiązania Doświadczenie w pracy z narzędziami dostępnymi na rynku prowadzą do pewnych wniosków. Okazuje się Ŝe trudno znaleźć kompromis pomiędzy: a) rozwiązaniami komercyjnymi które oferują ogromne moŝliwości funkcjonalne, jednak kosztem skomplikowanej obsługi, wysokich nakładów finansowych potrzebnych na zakup licencji, jak i na utrzymanie infrastruktury oraz nierzadko powolnym działaniem b) narzędziami darmowymi oferującymi głównie funkcję wersjonowania kodu i słuŝące jako repozytorium, bez elastycznych moŝliwości wdroŝenia procesów będących częścią systematyki projektowej, które pozwalałyby dodatkowo na integrację z kodem zawartym w repozytorium Dzięki integracji nieograniczonych niemal zasobów narzędzi i bibliotek open-source, z nowatorskimi rozwiązaniami w zakresie przechowywania danych, została podjęta próba stworzenia narzędzia posiadającego prosty interfejs oraz duŝe moŝliwości adaptacji do konkretnego projektu. Prototyp systemu opiera się na architekturze scentralizowanej klient-serwer, z moŝliwością repliki zarówno repozytorium kodu jak i bazy danych konfiguracji. Podstawowe załoŝenia prototypu systemu to: Architektura sieciowa Zintegrowane repozytorium wersji kodu, oparte na sprawdzonych rozwiązaniach Baza danych konfiguracji oparta o model obiektowy MoŜliwość obsługi wielu projektów o róŝnych scenariuszach MoŜliwość elastycznej konfiguracji i dostosowania do konkretnego projektu MoŜliwość implementacji dostępu za pomocą wielu kanałów (klient tekstowy, aplikacja okienkowa, aplikacja Web) Rozwiązanie będzie umoŝliwiać proste zarządzanie obiektami, będącymi elementami pewnej dowolnej, abstrakcyjnej zmiany. Typ i charakter zmiany jest zamknięty w ramach scenariusza zarządzanego przez serwer. Scenariusz jest modelowany przez administratora (osobę zarządzającą zmianą) z wykorzystaniem dwóch źródeł danych: a) Repozytorium obiektów zdefiniowanych na potrzeby danego scenariusza b) Repozytorium kodu SVN powiązanego ze scenariuszem Model danego scenariusza jest przechowywany w obiektowej bazie danych Odra, przy czym musi on zostać zdefiniowany i utworzony przed rozpoczęciem korzystania z systemu. Repozytorium SVN stanowi uzupełnienie i moŝe zostać pominięte w danym scenariuszu. System umoŝliwia dodawanie, modyfikację, usuwanie oraz odpytywanie repozytorium za pomocą: Kwerend predefiniowanych wbudowanych w dany scenariusz Kwerend zdefiniowanych przez uŝytkownika Zapytań ad-hoc 53

54 6.2. Model komunikacji Rozwiązanie zostało zaprojektowanie w klasycznej architekturze klient-serwer opartej o protokół TCP/IP z warstwą pośrednią jaką jest biblioteka dostępowa. Serwer o Jest odpowiedzialny za kontrolę dostępu klientów i obsługę Ŝądań o Zarządza połączeniami z repozytoriami danych Biblioteka dostępowa: o Udostępnia jednolite API pozwalające na wywoływanie funkcji serwera o Stanowi element wspólny w komunikacji pomiędzy róŝnymi kanałami Klient o MoŜe być dowolną aplikacją słuŝącą jako kanał dostępowy (np. klient Web, aplikacja graficzna, klient dostępny z wiersza poleceń) o Korzysta tylko z funkcji udostępnionych przez bibliotekę Schemat komunikacji systemu OdraCMT został przedstawiony na poniŝszym rysunku: Rysunek 18. Model komunikacji prototypu systemu OdraCMT 6.3. Opis funkcjonalności Przygotowanie nowego scenariusza Przed rozpoczęciem korzystania z narzędzia, naleŝy zainicjować dane serwera odpowiednim scenariuszem. 54

55 Wymaga to podjęcia szeregu czynności (symbolem zostały oznaczone zadania opcjonalne - niewymagane do poprawnego uruchomienia scenariusza): Utworzenie struktury modelu danych i kompilacja modułu systemu Odra - moŝe zostać wykonane na kilka sposobów: Wykonanie przygotowanego skryptu w języku SBQL Zaimportowanie pliku XML/XSD Oba zadania mogą zostać zrealizowane zarówno z wiersza poleceń klienta wchodzącego w skład dystrybucji, jak teŝ za pomocą funkcji udostępnionych przez IDE dla systemu Odra. Baza danych moŝe zostać uruchomiona zarówno na stacji roboczej hostującej serwer OdraCMT, jak teŝ w innej dowolnej lokalizacji sieciowej. Utworzenie repozytorium kodu moduł serwera jest elementem pakietu Subversion. Korzystanie z SVN jest moŝliwe po skonfigurowaniu i uruchomieniu serwera oraz stworzeniu repozytorium i powiązanie go w aplikacji OdraCMT. Więcej na temat uruchamiania hosta Subversion znajduję się w jego dokumentacji [I3]. Definicja danych konfiguracyjnych jest moŝliwa poprzez edycję pliku config.xml znajdującego się w katalogu głównym serwera. Struktura zawiera poniŝsze sekcje: Nazwa węzła <system-configuration> <server> [port] <scenarios> <scenario> [name] [description] [location] <queries> [name] [definition] [window] <parameters> [name] [type] [value] <odra> [host] [port] [module] [user] [password] <svn> [url] [user] [password] Zastosowanie Węzeł nadrzędny pliku konfiguracyjnego Sekcja konfiguracji globalnej serwera. Obecnie tylko port domyślny. Sekcja konfiguracji scenariuszy Dane konfiguracyjne pojedynczego scenariusza - nazwa - opis - lokalizacja zasobów Definicja zapytań domyślnych (dostępnych po uruchomieniu scenariusza, bez dodatkowej ingerencji uŝytkownika). Opcjonalny parametr window określa lokalizację interfejsu uŝytkownika uŝywanego w konkretnym zapytaniu Parametry konkretnego zapytania - nazwa parametru - typ parametru - wartość początkowa parametru Dane systemu Odra powiązanego ze scenariuszem - nazwa hosta - port - moduł przechowujący dane scenariusza - nazwa uŝytkownika - hasło Dane repozytorium Subversion - adres repozytorium w postaci url - nazwa uŝytkownika - hasło Tabela Węzły konfiguracyjne serwera 55

56 Zasilenie bazy danymi inicjalnymi podobnie jak definicja modułu moŝe zostać wykonana z poziomu klienta tekstowego jak i IDE zarówno za pomocą skryptu w języku SBQL jak teŝ w meta danych zawartych w pliku XML. Sytuacja taka moŝe być poŝądana w przypadku konieczności utworzenia takich danych początkowych jak dane słownikowe itd Rozpoczęcie pracy z klientem GUI Podstawowa funkcjonalność narzędzia została zaimplementowana dla klienta graficznego działającego w środowisku Windows. Dzięki udostępnieniu funkcji serwera w bibliotece, podobna funkcjonalność moŝe zostać stworzona dla innych kanałów dostępu (klient tekstowy, klient WWW, itd.). W celu poprawnego działania klienta, wymagane jest zainstalowanie biblioteki Microsoft.NET Framework w wersji 3.5. Po uruchomieniu programu wyświetlone zostaje okno główne składające się z dwóch obszarów: Obszar zapytań (QUERIES) UmoŜliwia zarządzanie zapytaniami oraz ich wykonywanie Obszar roboczy (WORKSPACE) SłuŜy do modyfikacji i przeglądania danych obiektów zapytań i ich wyników Rysunek 19. Okno główne klienta graficznego Wykonywanie i modyfikacja zapytań jest moŝliwa po nawiązaniu połączenia z serwerem (prototyp nie posiada zaimplementowanego mechanizmu uwierzytelniania uŝytkowników) i wybraniu odpowiedniego scenariusza udostępnionego przez serwer. 56