Planowanie złoonego wdroenia systemu IT

Transkrypt

1 BIULETYN INSTYTUTU AUTOMATYKI I ROBOTYKI NR 31, 2011 Planowanie złoonego wdroenia systemu IT Łukasz LASZKO, Andrzej STASIAK Instytut Teleinformatyki i Automatyki WAT, ul. Gen. S. Kaliskiego 2, Warszawa llaszko@wat.edu.pl, astasiak@wat.edu.pl STRESZCZENIE: W artykule przedstawiono zestaw technik i modeli wspierajcych procesy planowania wdroe systemów IT. Złoono tych procesów zilustrowano przykładem opisu wdroenia produktów platformy Jazz wykorzystywanych w badaniach i dydaktyce na Wydziale Cybernetyki WAT. Dodatkowo wskazano kierunek rozwoju tych procesów: od modeli konfiguracji w jzyku UML, do kompletnych opisów wdroe w postaci modeli topologii. Modele topologii mog by uruchamiane, co pozwala na prowadzenie eksperymentów w zakresie architektury oprogramowania. SŁOWA KLUCZOWE: model topologii, model wdroenia, planowanie wdroenia, jzyki dziedzinowe, UML. 1. Wprowadzenie W artykule przedstawiony został opis procesu planowania złoonego wdroenia systemu IT na przykładzie wykorzystywanego w pracach badawczych oraz udostpnionego studentom Wojskowej Akademii Technicznej rozwizania serwerowego opartego na produktach platformy IBM Jazz 1. Studenci i pracownicy maj równie moliwo wykorzystania innej platformy, np. Microsoft Team Foundation Server (TFS). Proces planowania wdroenia, ze wzgldu na swoj złoono [7] 2, [3], został udokumentowany z wykorzystaniem jzyka UML [1] i opracowanego przez IBM jzyka dziedzinowego (DSL) do opisu wdroe systemów IT [3], [4]. Podyktowane zostało to tym, e 1 W artykule przyjto, e system Jazz tworzy platforma i aplikacje działajce w jej rodowisku. 2 Firma IBM w swoim przewodniku do instalacji wskazuje na trzy typy organizacji wdroenia, od prostej, typu evaluation, przez department (wybran do wdroenia na Wydziale Cybernetyki WAT) do korporacyjnej, typu enterprise. 55

2 Łukasz Laszko, Andrzej Stasiak rodki dostpne w UML, to jest diagramy: wdroenia (ang. deployment diagram), komponentów (ang. component diagram) i klas (ang. class diagram), nie pozwoliły na pełn specyfikacj (z wymagan ekspresywnoci) kompletu cech opisu konfiguracji (dla planowanego wdroenia) [1]. Szczegółowo przedstawionych w artykule modeli została dobrana tak, aby mona było zastosowa techniki symulacyjnej weryfikacji modeli (UML i topologii), które pozwalaj potwierdzi słuszno podjtych decyzji architektonicznych przed przeprowadzeniem wdroenia. W artykule wykazujemy, e moliwe jest opracowanie modeli topologii, które adekwatnie opisuj wdroenie, a zaproponowana metoda jego planowania jest skuteczna. Artykuł rozpoczynamy od krótkiej charakterystyki dostpnych technik prowadzcych do opracowania modelu wdroenia koncentrujc si na opisie wdroenia rozwizania serwerowego i okrelajc jedynie podstawowe własnoci stacji klienckich. Zasadnicz cz artykułu stanowi modele UML i opis ich powiza z modelami topologii. W pracy przedstawiamy równie praktyczne uwagi dotyczce przeprowadzonego wdroenia, które naszym zdaniem s istotne dla planowania złoonych wdroe systemów IT. 2. Ewaluacja modeli wdroenia Obecnie najpopularniejszym sposobem na utrwalanie decyzji dotyczcych wdroe systemów IT (krótko przedstawionym w kolejnym podrozdziale 2.1) jest dostarczenie specyfikacji wdroenia, która zasadniczo bazuje na diagramach wdroenia jzyka UML [6] i jest uzupełniana diagramami opisu struktury i zachowania. Jednak rodki te nie s wystarczajce. Nie pozwalaj w precyzyjny sposób opisa procesów konfigurowania wdraanych systemów tak, aby opis ten stanowił szczegółowy przewodnik (plan wdroenia). Dla zwikszenia precyzji modeli wdroenia skuteczne s dwie drogi: pierwsza sprowadza si do dostarczenia dedykowanego profilu jzyka UML; druga zakłada zdefiniowanie własnego jzyka dziedzinowego (który nie bazuje na UML). Rozwój własnego jzyka dziedzinowego wybrała firma IBM [2], [3]. Jest on dostarczany wraz platform IBM Rational Software Architect [4], [5] jako narzdzie wsparcia procesów modelowania topologii i opisu prowadzonych wdroe systemów IT i zostanie szerzej opisany w podrozdziale Biuletyn Instytutu Automatyki i Robotyki, 31/2011

3 Planowanie złoonego wdroenia systemu IT 2.1. Modele konfiguracji w jzyku UML Diagramy wdroenia UML pozwalaj na utrwalenie decyzji dotyczcych architektury systemu. Przedstawiaj one: opis fizycznych elementów wdroenia; zwizki midzy oprogramowaniem a sprztem wchodzcym w skład systemu; procesy dystrybucji systemu. Diagramy wdroenia s zwykle opracowywane podczas definiowania architektury budowanego systemu oraz wdraania jego oprogramowania i przedstawiaj rozmieszczenie wzłów w systemie rozproszonym, artefakty, które s przechowywane w wzłach, oraz ich realizacje. Wzły reprezentuj urzdzenia, takie jak komputery, czujniki, drukarki, jak równie inne urzdzenia tworzce rodowisko wykonawcze (ang. runtime). cieki komunikacyjne i linki (wizania) na diagramach wdroenia okrelaj fizyczne połczenia w systemie Modele topologii Planowanie wdroenia i jego automatyzacji jest pomostem pomidzy projektowaniem aplikacji i ich wdraaniem, który nazywamy modelem topologii [2]. Modele topologii stosujemy, aby uproci cykl ycia aplikacji na trzy sposoby: 1. Twórcy aplikacji mog a priori przyj, e ich aplikacje bd działa w rodowisku wdroenia (zamiast czeka na ich zbudowanie i weryfikacj swoich decyzji). 2. Wdroeniowiec moe przewidzie potrzeby aplikacji i zapewni, e rodowisko wdraania pozwoli na ich poprawne działanie (nie tylko ze wzgldu na wymagania technologiczne, ale i dodatkowe, dotyczce np. uytecznoci, niezawodnoci, wydajnoci i skalowalnoci zgodnie z modelem FURPS). 3. Architekci mog wymusi stosowanie najlepszych praktyk i standardów korporacyjnych w zakresie tworzenia planów rozmieszczenia oraz bada histori scenariuszy wdroe, które zakoczyły si sukcesem (jak i porak). W duym uproszczeniu moemy przyj, e modele topologii definiuj architektur rozlokowania elementów systemu, odwołujc si do dwóch poj: jednostka i link [4], [5], [7], gdzie: Biuletyn Instytutu Automatyki i Robotyki, 31/

4 Łukasz Laszko, Andrzej Stasiak jednostkami s fragmenty aplikacji lub elementy infrastruktury wdraania (w tym sprzt serwera, serwer aplikacji, bazy danych i systemy operacyjne); linki okrelaj relacje (zwizki) midzy jednostkami. Na przykład aplikacja Web, aby mogła poprawnie działa, musi by uruchomiona na serwerze WWW. W topologii, która opisuje t relacj, jednostka reprezentujca aplikacj internetow jest hostowana, czyli powinna by połczona zwizkiem typu hosting z serwerem WWW. Rozszerzajc wczeniejsze okrelenie modelu topologii (jako pomostu pomidzy projektowaniem aplikacji a ich wdraaniem), pod pojciem model topologii systemu IT rozumie bdziemy celowy opis systemu, który obrazuje jego kształt, okrelony przez zasoby systemu i zalenoci midzy nimi. Wan cech podejcia topologicznego jest moliwo planowania, a nastpnie weryfikacji modelowanych scenariuszy rozlokowania. Planowanie wdroenia wie si z okreleniem architektury rozlokowania elementów systemu (zarówno jako poj konceptualnych, jak i fizycznych) i jest trudnym procesem, który moe doprowadzi do pojawienia si duej liczby błdów. Ryzyko popełnienia błdu mona ograniczy przez zastosowanie si projektanta do nastpujcych reguł: wprowadzenie procesu planowania wdroenia we wczesnej fazie wytwarzania aplikacji (ju podczas projektowania); ponowne uycie szablonów topologii, zdefiniowanych i zweryfikowanych we wczeniejszych wdroeniach; zastosowanie wczesnej walidacji scenariusza architektury rozlokowania, a tym samym identyfikacja niekompatybilnoci artefaktów modelu Konceptualne modele topologii Do realizacji procesów planowania topologii aplikacji uytecznym narzdziem bdzie edytor, który umoliwi włczanie elementów sprztu komputerowego i oprogramowania do planu opisów, przed planowaniem szczegółów technologicznych. Za jego pomoc bdzie moliwe tworzenie modeli wysokiego poziomu [2], [4]. Model logiczny poddawany jest badaniom majcym na celu zastosowanie modelowania operacyjnego, które w zakresie topologii jest podejciem do podejmowania decyzji o sprawnej architekturze systemu komputerowego. Podczas tworzenia modelu operacyjnego powstaje opis systemu na wysokim poziomie abstrakcji, w którym s wyszczególnione komponenty aplikacji oraz 58 Biuletyn Instytutu Automatyki i Robotyki, 31/2011

5 Planowanie złoonego wdroenia systemu IT ich powizania, lokalizacja oraz rozwizania dla postawionych wymaga biznesowych okrelonych w kontrakcie (rys. 1, rys. 2). Nie specyfikuje on natomiast szczegółów technologicznych aplikacji czy infrastruktury, takich jak system operacyjny czy serwer aplikacji, który bdzie uyty. Topologia na tym poziomie abstrakcji odwołuje si do modeli logicznych (koncentrujc si na prezentacji aspektu struktury systemu). Na rys. 1 przedstawiono model konceptualny dla planowanego wdroenia. W dalszej czci artykułu przedstawimy jedynie opis serwerów funkcjonalnoci i baz danych, pomijajc w nim aspekt bezpieczestwa (komponenty tworzce Wydziałowy FireWall ). Rys. 1. Logiczny model wdroenia serwera platformy Jazz Przedstawiony na rys. 1 model specyfikuje jedynie zasoby serwera, natomiast na rys. 2 uzupełniono go o element Stanowisko pracy (jako aplikacj klienck). W modelu logicznym mog by wykorzystane nastpujce elementy: Rozlokowanie fizyczne, geograficzne miejsce albo strefa bezpieczestwa (np. rys. 1: Serwerownia, Internet, Serwery Bezpieczestwa, ); Aktor osoba albo zewntrzny system komputerowy, który jest w interakcji z modelowanym systemem (np. klient, administrator, czy, jak na rys. 1: wdroeniowiec, członek zespołu, model importer jako zewntrzny system); Biuletyn Instytutu Automatyki i Robotyki, 31/

6 Łukasz Laszko, Andrzej Stasiak Komponent relokowalna cz oprogramowania (np. na rys. 2: przegldarka WWW, CCM, ); Wzeł wymagana do działania, instalacji czy konfiguracji komponentu lub innego elementu programowego infrastruktura (np. na rys. 2: stanowisko pracy, serwer aplikacji wydziałowych, serwer wydziałowych baz danych); Jednostka konfiguracji aspekt komponentu aplikacji, który czyni go niezalenym od rodowiska działania aplikacji. Rys. 2. Logiczny model wdroenia typu departament Fizyczne modele topologii Topologia opisuje elementy i łcza midzy elementami. Elementy reprezentuj czci systemu komputerowego, takie jak np. sprzt komputerowy, serwery, ich oprogramowanie, oraz obsług systemów i komponentów aplikacji [3], [5]. Łcza reprezentuj tu zwizki midzy tymi elementami, takie jak na przykład komunikacja. Tworzenie samego diagramu topologii typowo realizowane jest w nastpujcych dwóch krokach: budowa perspektywy konfiguracji; budowa topologii. 60 Biuletyn Instytutu Automatyki i Robotyki, 31/2011

7 Planowanie złoonego wdroenia systemu IT Na diagramie umieszczane s elementy, które reprezentuj koncepcj budowanej aplikacji w postaci komponentów (np. komponentów WWW). Elementy mog by połczone midzy sob za pomoc jednego z piciu typów łczy [1]: Hostowanie (ang. hosting link) łcze z elementami hostujcymi wskazuje, e jeden element topologii ( go ) jest goszczony (hostowany) przez inny element gospodarz (tzn. gospodarz spełnia wszystkie wymagania gocia ); Realizacja (ang. realization link) łcze realizacji wskazuje, e element wyjciowy jest specyficznym odwzorowaniem cech opisanych przez element ródłowy; Zaleno (ang. dependency link) łcze zalenoci wskazuje, e jeden element wymaga innego albo okrela, czy usługa jest dostarczona przez ten element; Ograniczenia (ang. constraint link) łcze ogranicze wystpuje midzy dwoma elementami, wskazujc na ograniczenia relacji midzy nimi; Naley do (ang. membership link) łcze zawierania wskazuje, e jeden element zawarty jest w innym elemencie (naley do niego) albo jest członem innego elementu. Narzdzia konfiguracji architektury skoncentrowane s wokół modelu topologii. Topologia, równie i w tym zakresie, zawiera elementy, które mog reprezentowa róne byty (na rónych poziomach abstrakcji), włczajc w to sprzt komputerowy, oprogramowanie i ich zasoby konfiguracyjne, w tym np. uytkowników, grupy uytkowników itd. Na rys. 4 przedstawiono fragment modelu wdroenia, okrelany jako fizyczny model topologii, tzn. model, który okrela rzeczywiste elementy, które zostan uyte podczas wdroenia. Te rzeczywiste elementy s obrazami maszyn wirtualnych pracujcych w rodowisku serwera Dell PowerEdge Ciekawa jest moliwo definiowania kompletu szczegółów konfiguracyjnych nie tylko dla zasobów fizycznych, ale i wirtualizowanych (np. liczba procesorów i ich rdzeni, wielko pamici RAM). Warto tu równie zauway, e model logiczny okrelony w poprzednim kroku moe by zaimportowany do modelu fizycznego, a jego elementy mog by ponownie wykorzystane do zbudowania modelu wdroenia. Przykładem moe tu by ponowne uycie programowych fizycznych elementów modelu stanowicych komponenty bazy danych, jako bazy danych odpowiadajcych im produktów platformy jazz, przedstawionych na (rys. 5). Bazy danych, w rozumieniu modelu topologii wdroenia, s hostowane na serwerze JAZZDB. W rodowisku produkcyjnym, zgodnie z przedstawionym na rys. 4 modelem, pracuj one pod kontrol systemu operacyjnego Windows XP (lub jego emulacji, w rodowisku wirtualizacji VMware). Biuletyn Instytutu Automatyki i Robotyki, 31/

8 Łukasz Laszko, Andrzej Stasiak Rys. 3. Lista baz danych utworzonych na potrzeby systemu Jazz. Rys. 4. Fragment modelu realnego (fizycznego) wdroenia 62 Biuletyn Instytutu Automatyki i Robotyki, 31/2011

9 Planowanie złoonego wdroenia systemu IT 3. Planowanie wdroenia systemu Jazz (JTS) Jako przykład złoonego wdroenia zostanie przedstawiona instalacja i konfiguracja systemu pracy grupowej IBM Jazz Team Server (JTS) [7] 3 wraz z wybranymi aplikacjami rozszerzajcymi jego funkcjonalno o administrowanie projektami cyklu ycia (LPA), zarzdzanie wymaganiami (RM), zarzdzanie zmian (CCM), testowanie (zarzdzanie jakoci, QM) oraz zarzdzanie modelami graficznymi (publikowanie i komentowanie diagramów, DM) (rys. 5). Rys. 5. Komponenty programowe utrzymywanego rodowiska produkcyjnego Na omawianej platformie JTS moliwe jest osadzenie równie innych aplikacji udostpnianych w ramach inicjatywy Jazz 4. Jednak te, które zostały wybrane, zdaniem autorów stanowi niezbdne minimum do budowania skutecznego wsparcia dla zespołów projektowych. Warto nadmieni, e wspomniane rozwizanie alternatywne (TFS, które funkcjonalnie pokrywa obszary CCM, QM, RM, pomijajc istotne dla dydaktyki obszary DM i LPA [8]), dostpne dla pracowników i studentów, nie jest obecnie powszechnie stosowane w rodowisku akademickim, w naszej ocenie wynika to głównie z tak szerokiego zakresu moliwoci uycia platformy Jazz (rys. 5). 3 W artykule opisano wersj Lista aplikacji udostpnionych w ramach inicjatywy Jazz dostpna jest pod nastpujcym adresem: JTS jest platform przygotowan do osadzania aplikacji webowych, zatem, z uwagi na lune powizania midzy aplikacjami, moliwe s róne konfiguracje aplikacji na tej platformie. Biuletyn Instytutu Automatyki i Robotyki, 31/

10 Łukasz Laszko, Andrzej Stasiak 3.1. Instalacja Wynikiem instalacji bdzie zbudowana infrastruktura, która po konfiguracji komponentów programowych (rys. 5) bdzie udostpniała zakładan funkcjonalno systemu pracy grupowej 5. Instalacja polega na scaleniu czci rodziny aplikacji Jazz Team Server z aplikacj specjalizowan, słuc do zarzdzania modelami graficznymi (Design Management (DM) w wersji 3.0.1) tworzonymi w rodowisku narzdzia CASE (IBM Rational Software Architect lub IBM Rational Rhapsody) [4], [5]. Firma IBM, właciciel inicjatywy Jazz, mimo dojrzałoci rodowiska rozwijanego w ramach tej inicjatywy (obecnie wydawana jest wersja 4) nie udostpniła kompletnego podrcznika instalacji dla architektury opisywanej w tej pracy [7], co stanowiło dla autorów dodatkow zacht do udokumentowania tego procesu. Według załoe opublikowanych na stronie inicjatywy Jazz, udostpniane s dwa sposoby instalacji 6 : instalacja z kompletnego archiwum oraz instalacja z sieci (Web) 7. Bez wzgldu na sposób instalacji omawiana wersja aplikacji zawiera, oprócz docelowych aplikacji, podstawowe licencje (w tym licencje czasowe) oraz serwer aplikacji 8 Apache Tomcat w wersji (rys. 4, rys. 5). Alternatywnym serwerem aplikacji, zalecanym przez Jazz, jest IBM Websphere Application Server w wersji 6.1 lub nowszej 9. Zaproponowany przez autorów proces instalacji przedstawiony jest na rys. 6. Wyrónione w tym procesie aktywnoci pokazuj działania, jakie naley wykona, by zbudowa rodowisko projektu o załoonej funkcjonalnoci. Opisany proces instalacji nie uwzgldnia postpowania zwizanego z instalacj bazy danych, gdy jest on opisany w materiałach udostpnianych przez IBM 10, z uwzgldnieniem rónych systemów baz danych, takich jak: Apache Derby w wersji 10.5, IBM DB2 w wersji 9.5 i 9.7 Express, Workgroup i Enterprise, Microsoft SQL Server w wersji od Express 2005 SP3 do 2008 R2 oraz Oracle Database w wersji 10g i 11g Standard i Enterprise Release 2. W opisywanym rozwizaniu wykorzystano baz IBM DB2 Express w wersji 9.7. Zaznaczony na omawianym diagramie przepływ obiektów dodatkowo ukazuje zmian w katalogu docelowym aplikacji DM, która spowodowana jest scaleniem zawartoci tego katalogu z katalogiem JTS. 5 oraz 6 Dostpne mechanizmy instalacji zalene s od wyboru docelowej platformy, por. downloads/jazz-foundation/releases/3.0.1?p=alldownloads Design Management w omawianej wersji dostpny jest tylko na platform MS Windows i Linux. 7 Omawiane oprogramowanie udostpnia take moliwo pobrania zestawu SDK na potrzeby wykorzystania w projektach typu opensource. 8 Precyzujc, jest to serwer webowy i kontener serwletów. 9 Wymagania wstpne dla JTS opisuje: 10 Por. np. setup_db2.html 64 Biuletyn Instytutu Automatyki i Robotyki, 31/2011

11 Planowanie złoonego wdroenia systemu IT Rys. 6. Proces autorskiej instalacji systemu JTS Wspomniane wyej scalenie polega na przeniesieniu zawartoci niektórych podkatalogów katalogu JTS do katalogu DM. Podkatalogi te przedstawiono na rys. 7a. Dla ukazania zwizku midzy pakietami wykorzystano notacj zagniedenia pakietu oraz zaleno ze stereotypem «merge» oznaczajc scalenie zawartoci dwóch pakietów. Zastosowanie tej zalenoci skutkuje utworzeniem spójnej przestrzeni nazewniczej (w tym przypadku katalogowej). a) b) Rys. 7. a) Struktura elementów JTS wymaganych do scalenia w DM b) Wynikowa struktura katalogu Design Management Biuletyn Instytutu Automatyki i Robotyki, 31/

12 Łukasz Laszko, Andrzej Stasiak Na rys. 7a. jawnie wskazano miejsce osadzenia artefaktów wykonywalnych (tutaj archiwów aplikacji webowych) w ramach jednego wzła wdroenia. Zawarto pozostałych istotnych pakietów składa si z dokumentów konfiguracyjnych, licencji oraz skryptów. Te elementy nie zostały ukazane ze wzgldu na zachowanie czytelnoci diagramu. Wynikow struktur katalogów po instalacji przedstawiono na rys. 7b. Opisany proces instalacji (organizacja wdroenia typu departament [7]), z uwagi na charakter aplikacji udostpnianych w ramach inicjatywy Jazz 11, mona stosowa do opisu instalacji innych aplikacji rozszerzajcych funkcjonalno JTS. Ponadto autorzy zwracaj uwag na fakt, e komponenty aplikacji nie musz by rozlokowane w ramach jednego wzła Konfiguracja Zbudowana po instalacji infrastruktura projektu nie udostpnia jeszcze zakładanej funkcjonalnoci, to jest w pełni funkcjonalnego systemu pracy grupowej. Dzieje si tak z powodu braku powiza midzy aplikacjami składajcymi si na ten system. Powizania te zostan utworzone podczas procesu konfiguracji. Wymagania procesu konfiguracji przedstawiono w postaci przypadków uycia na diagramie na rys. 8. Wymagania pogrupowano w podsystemy 12 w celu: jawnego wskazania zakresu działa opisywanych przez przypadki uycia; zaznaczenia aplikacji, których dane wymaganie dotyczy; wyrónienia tych wymaga, które formułowane s wielokrotnie w stosunku do rónych aplikacji (ang. reuse). Na potrzeby konfiguracji autorzy wyrónili nastpujce role: Wdroeniowiec; Uczestnik projektu; Model Importer. Reprezentantami tych ról s aktorzy, których specyfikacji dokonano w tab. 1. Do zakresu zagadnie podejmowanych w niniejszym artykule maj zastosowanie jedynie te przypadki uycia, które wi si bezporednio z rol Wdroeniowca. Realizacje tych przypadków uycia omówione zostan w dalszej czci artykułu. 11 Zakładajcy lune powizania midzy aplikacjami w ramach wspólnej platformy. 12 Podsystem stanowi wyrónion funkcjonalnie logiczn cz systemu nadrzdnego. 66 Biuletyn Instytutu Automatyki i Robotyki, 31/2011

13 Planowanie złoonego wdroenia systemu IT Rys. 8. Wymagania wobec procesu konfiguracji systemu JTS Tab. 1. Specyfikacja aktorów Lp. Nazwa Opis Cel Odpowiedzialno Wdroeniowiec Członek zespołu Rola, której zadaniem jest dostarczenie uytkownikowi kocowemu kompletnej infrastruktury systemu pracy grupowej JTS Rola, której zadaniem jest weryfikacja skonfigurowanej infrastruktury pod ktem poprawnoci współdziałania tworzcych j aplikacji Zbudowa i skonfigurowa infrastruktur systemu pracy grupowej JTS Zweryfikowa poprawno konfiguracji infrastruktury systemu pracy grupowej JTS Zainstalowanie systemu JTS; Konfiguracja systemu JTS; Konfiguracja bazy danych. Wdroenie predefiniowanych, przykładowych projektów 3. Model Importer Rola, której zadaniem jest konfiguracja importu modeli graficznych do aplikacji zarzdzajcej tymi modelami (DM) Skonfigurowa import modeli graficznych do DM Skonfigurowanie lokalnego importu do DM Skonfigurowanie importu do DM z systemu kontroli wersji Biuletyn Instytutu Automatyki i Robotyki, 31/

14 Łukasz Laszko, Andrzej Stasiak Utworzenie baz danych Konfiguracja systemu poprzedzona zostanie przygotowaniem baz wykorzystywanych przez aplikacje systemu Jazz (rys. 5). Przy tworzeniu bazy danych mona wykorzysta wbudowany w system zarzdzania baz danych kreator lub wykona proste polecenie SQL, np. polecenie tworzce baz danych JAZZ w katalogu głównym dysku C: ma posta: create database JAZZ on c: using codeset UTF-8 territory en PAGESIZE Na potrzeby omawianego rozwizania naley w analogiczny sposób utworzy nastpujce bazy danych: CCM, DW, QM. Scenariusz realizacji tego zadania opisany jest na rys. 9. Lista utworzonych w ten sposób baz widoczna jest na rys. 3. Rys. 9. Scenariusz konfiguracji bazy danych Do kadej z utworzonych baz naley przypisa uytkownika, który jest jednoczenie uytkownikiem systemu operacyjnego 13, po czym wypromowa go 13 W celu zwikszenia bezpieczestwa naley ograniczy moliwoci logowania uytkownika do systemu, wyłczajc dla niego logowanie w trybie interakcyjnym, a pozostawiajc dopuszczalne jedynie logowanie w trybie usługi. 68 Biuletyn Instytutu Automatyki i Robotyki, 31/2011

15 Planowanie złoonego wdroenia systemu IT na administratora bazy danych (DBADM), za pomoc kreatora bd wykonujc proste polecenie SQL. Tak skonfigurowane bazy danych stanow główny magazyn danych przetwarzanych przez system pracy grupowej Konfiguracja systemu Jazz Konfiguracja ustawie podstawowych Dla opisywanego wdroenia opracowano scenariusze konfiguracji, które s opisane jako dialog midzy komponentami systemu. Scenariusz opisujcy konfiguracj ustawie podstawowych systemu Jazz Team Server, w oparciu o wbudowany kreator, przedstawia rys. 10. Dostp do kreatora odbywa si z wykorzystaniem przegldarki internetowej, po wprowadzeniu adresu serwera JTS, w nastpujcej postaci: serwera}:9443/jts/setup przy wykorzystaniu domylnych powiadcze administratora [7]: (login: ADMIN; hasło: ADMIN). Konfiguracja rozpoczyna si ustanowieniem publicznego adresu URI (ang. Uniform Resource Identifier). Adres ten jest niezbdny na potrzeby póniejszej komunikacji z aplikacj Jazz oraz z pozostałymi aplikacjami zalenymi. Zgodnie z ostrzeeniem wypisywanym w oknie kreatora raz ustanowionego adresu URI nie mona modyfikowa 14 (por. rys. 11). Kolejnym krokiem jest konfiguracja połczenia z baz danych (rys. 12) oraz utworzenie w jej obszarze wymaganych tabel. Tworzenia tabel mona dokona w kreatorze, bd za pomoc dostarczonego skryptu 15, znajdujcego si w katalogu instalacji: repotools-jts.bat createtables Pozostałe czynnoci konfiguracyjne, według scenariusza, dotycz powiadomie , rejestracji aplikacji, rejestru uytkowników oraz hurtowni danych. Powiadomienia spełniaj bardzo istotn rol w omawianym systemie. Umoliwiaj midzy innymi: rozsyłanie powiadomie grupowych, informowanie o zdarzeniach oraz zapraszanie nowych członków zespołów. W kreatorze mona wyspecyfikowa tzw. biał list odbiorów wiadomoci, dziki której moliwe jest ograniczenie liczby adresatów. Brakuje jednak moliwoci okrelenia zakresu powiadomie (filtra zdarze istotnych), co przy duej liczbie zdarze, stanowi potencjalne zagroenie zalewania skrzynek pocztowych nieistotnymi wiadomociami oraz, przypuszczalnie, blokowania adresu wybranego serwera SMTP. 14 Por. pkt jw. Biuletyn Instytutu Automatyki i Robotyki, 31/

16 Łukasz Laszko, Andrzej Stasiak W nastpnym kroku dokonywana jest rejestracja aplikacji. Jest to kluczowy element wizania aplikacji zainstalowanych na platformie Jazz. W tym punkcie dochodzi do ustanowienia instancji relacji midzy komponentami poprzez utworzenie wiza topologicznych. Powołanie wiza midzy komponentami umoliwia komunikacj midzy nimi. Z uwagi na lune powizania midzy aplikacjami, topologia systemu moe podlega zmianom (rozszerzeniom lub zaweniom, poprzez dodawanie lub usuwanie komponentów, co moe odbywa si równie w czasie działania w rodowisku produkcyjnym), podczas rejestracji nowym aplikacjom przypisywane s unikalne klucze konsumenta, które słu ich uwierzytelnianiu wzgldem platformy Jazz. Aplikacje nieuwierzytelnione nie s dostpne (widoczne) z poziomu serwera JTS. Wynik rejestracji aplikacji pokazano na rys. 13. Rys. 10. Scenariusz konfiguracji systemu JTS Rys. 11. Konfiguracja URI 70 Biuletyn Instytutu Automatyki i Robotyki, 31/2011

17 Planowanie złoonego wdroenia systemu IT Rys. 12. Konfiguracja połczenia z baz danych Nastpna czynno wykonywana podczas konfiguracji dotyczy wyboru rejestru uytkowników systemu Jazz. Domylnie informacje o uytkownikach magazynowane s w plikach serwera Tomcat, moliwe jest take wykorzystanie usługi LDAP lub innego zewntrznego rejestru. W przypadku wyboru usługi LDAP naley poda dodatkowe wartoci wymaganych parametrów 16, natomiast w sytuacji wyboru ustawie domylnych taka potrzeba nie wystpuje. Przykład wykorzystania lokalnego magazynu uytkowników serwera Tomcat przedstawia rys. 14. Rys. 13. Wynik rejestracji aplikacji 16 Pomocny przy okrelaniu tych wartoci jest nastpujcy artykuł dostpny pod adresem: Biuletyn Instytutu Automatyki i Robotyki, 31/

18 Łukasz Laszko, Andrzej Stasiak Oprócz wskazania rejestru uytkowników mona take wybra licencje domylne dla nowo tworzonych uytkowników 17. Warto zauway, e aplikacje osadzone na platformie Jazz posiadaj oddzielne licencjonowane. Jazz w tym przypadku odpowiada jedynie za zarzdzanie tymi licencjami. Rys. 14. Fragment zawartoci magazynu uytkowników serwera Tomcat Ostatnim krokiem konfiguracji ustawie podstawowych jest konfiguracja hurtowni danych, która wykorzystywania jest do raportowania i analiz. Proces konfiguracji niewiele róni si od konfiguracji bazy danych. Rónica polega na utworzeniu nowego uytkownika, który bdzie odpowiedzialny za gromadzenie danych. Po wprowadzeniu wymaganych parametrów konfiguracji hurtowni danych, naley dokona utworzenia tabel. Czynno t mona wykona przy pomocy kreatora (rys. 15) bd z wykorzystaniem skryptu: repotools-jts.bat createwarehouse Rys. 15. Konfiguracja hurtowni danych 17 Istnieje moliwo zainstalowania licencji przed konfiguracj systemu. Mona to zrobi w kreatorze: com.ibm.team.repository.admin.managelicenses. 72 Biuletyn Instytutu Automatyki i Robotyki, 31/2011

19 Planowanie złoonego wdroenia systemu IT Cho cz konfiguracji JTS dotyczca ustawie podstawowych została zakoczona, to (zawarto pliku konfiguracyjnego przedstawia rys. 16), z uwagi na zaleno aplikacji osadzonych na omawianej platformie od samej platformy (rys. 2, rys. 5), proces konfiguracji systemu pracy grupowej nie został zakoczony. Rys. 16. Zawarto pliku konfiguracyjnego JTS (teamserver.properties) po zakoczonym procesie konfiguracji ustawie podstawowych Konfiguracja aplikacji Aplikacje, które zostały osadzone i zarejestrowane na platformie Jazz, nie udostpniaj jeszcze zakładanej funkcjonalnoci, por. pkt 3.2, gdy same aplikacje nie zostały skonfigurowane. W stosunku do wybranych aplikacji proces konfiguracji bdzie podobny, cho w niewielkim stopniu róny, przedstawia go diagram z rys. 17, drobne rónice w konfiguracji wypływaj ze specyfiki aplikacji, co zostało oznaczone na rysunku przez fragment typu opt. Wymaganie: Skonfiguruj aplikacj wskazane na rys. 8, według wyej zauwaonych rozbienoci w konfiguracji, opisane zostało jako abstrakcyjne, co oznacza, e wymagania pochodne w stosunku do niego bd konkretyzowane, w zalenoci od danego podsystemu pozostajcego w relacji z wymaganiem abstrakcyjnym. Na tym kocz si procesy instalacji i konfiguracji sytemu Jazz. Biuletyn Instytutu Automatyki i Robotyki, 31/

20 Łukasz Laszko, Andrzej Stasiak Rys. 17. Konfiguracja aplikacji Praktyczne uwagi do przeprowadzonego wdroenia W rozdziale tym przedstawiono praktyczne uwagi (najlepsze praktyki) dotyczce przeprowadzonego wdroenia, które naszym zdaniem mog mie istotne zastosowanie przy planowaniu i przeprowadzaniu wdroenia oraz modyfikacjach, takich jak: zmiana rozmieszczenia aplikacji, zmiana lokalizacji serwera (w tym adresu URI), itp. Opisany w pkt. 3.1 proces instalacji autorzy przeprowadzili kilkakrotnie, czciowo równie bez uycia kreatora, tzn. modyfikujc zapisy w plikach konfiguracyjnych JTS oraz innych aplikacji (rys. 18, zmiany wymagaj artefakty ze stereotypem document). Moliwo samodzielnej modyfikacji tych plików dała podstaw do eksperymentu przeniesienia infrastruktury do innej lokalizacji i zmiany adresu URI, co nie jest moliwe do wykonania przy pomocy standardowego kreatora 18 (por. rys. 11). 18 Podrcznik instalacji tej wersji zaznacza wprost, e nie jest moliwa taka zmiana, jedyna wskazywana moliwo obejcia tego ograniczenia istnieje w zwizku z modyfikacj zapisów w DNS (pozostawiajc niezmienion nazw hosta), por. 74 Biuletyn Instytutu Automatyki i Robotyki, 31/2011

21 Planowanie złoonego wdroenia systemu IT Rys. 18. Komponenty konfiguracyjne systemu JTS Przeprowadzono kilka prób, w których: udało si: przenie lokalizacj serwera; zmodyfikowa adres URI; przywróci poprawno wiza w obszarze topologii (w tym midzy aplikacjami oraz aplikacjami a baz danych); podmieni komponent zarejestrowany z niezarejestrowanym tego samego typu (łcznie z podmian klucza konsumenta); zachowa poprawno i cigło licencjonowania po zmianie lokalizacji serwera; zachowa konta uytkowników i ich licencje po zmianie lokalizacji serwera; nie udało si: przywróci współdziałania obszarów projektów w ramach cyklu ycia projektu w nowej lokalizacji serwera. _URLs.html Biuletyn Instytutu Automatyki i Robotyki, 31/

22 Łukasz Laszko, Andrzej Stasiak Wszystkie eksperymenty przeprowadzone zostały w rodowisku wirtualizacji (rys. 4). Uzyskane wyniki mog stanowi zalecenia do planowania wdroe systemu Jazz w oparciu o rozwizania szablonowe, które mog posłuy budowaniu infrastruktury: o wysokiej dostpnoci (ang. high availability systems) przez utworzenie wzłów redundantnych; o szybkiej naprawialnoci (ang. reparable systems) przez wymian komponentu lub całego wzła. Naley zwróci uwag, e wybór odpowiedniej wersji JTS oraz innych aplikacji jest kluczowy dla przeprowadzenia omawianego wdroenia. Autorzy zalecaj wykorzystywanie wyłcznie wersji oznaczonych jako wydanie (ang. Release). Do pozostałych udostpnionych wersji, tzn. Beta, Milestone i Release Candidate, brakuje dokumentacji, a archiwa instalacji mog zawiera róne wersje aplikacji, co moe stwarza dodatkowe problemy przy wdraaniu tego rozwizania. Modelowy opis przeprowadzonego wdroenia przedstawiono na diagramie wdroenia UML, na rys. 19. Rys. 19. Architektura systemu pracy grupowej Jazz przedstawiona na diagramie wdroenia UML 76 Biuletyn Instytutu Automatyki i Robotyki, 31/2011

23 Planowanie złoonego wdroenia systemu IT 4. Podsumowanie W artykule przedstawiono ogóln metod realizacji procesu planowania wdroenia bazujc na koncepcji MDD (ang. Model Driven Development), w której proces wdroenia opisany jest za pomoc modeli: UML i topologii systemu. Modele topologii s dialektem jzyka UML przeznaczonym dla architektów i wdroeniowców oprogramowania, i to one pozwoliły nam, z wymagan dla automatyzacji procesów wdroenia szczegółowoci, opisa ten proces w specjalizowanym jzyku dziedzinowym i zweryfikowa go na przykładzie konkretnego wdroenia, zrealizowanego na Wydziale Cybernetyki WAT. Dodatkow korzyci płync z opracowania modeli topologii jest moliwo ich symulacji, bez koniecznoci oczekiwania wdroeniowców na weryfikacj załoe architektonicznych na fizycznych zasobach systemu. Weryfikacj t moemy przeprowadzi, zanim te zasoby zostan zbudowane i, prowadzc eksperymenty, okreli, które z opracowanych wzorców topologii bd akceptowalne, a które naley odrzuci. Literatura [1] D BROWSKI W., STASIAK A., MARKOWSKI K., Modeling using configuration topology, Przegld Elektrotechniczny, 9/2010, pp [2] Planning deployment with the topology editor, IBM Tutorial, IBM, [3] Modeling deployment topologies, IBM Tutorial, IBM, [4] NARINDER M., Anatomy of a topology model used in IBM Rational Software Architect Version 7.5: Part 1: Deployment modeling, IBM, [5] NARINDER M., Anatomy of a topology model used in IBM Rational Software Architect Version 7.5: Part 2: Advanced concepts, IBM, [6] D BROWSKI W., STASIAK A., WOLSKI M., Modelowanie systemów informatycznych w jzyku UML 2.1, PWN, Warszawa, [7] Jazz Team Server 3.0.1, Interactive Installation Guide, IBM, boulder.ibm.com/infocenter/clmhelp/v3r0m1/topic/com.ibm.jazz.install.doc/topics/ roadmap_form.html. [8] Team Foundation Server, Overview, Microsoft, visualstudio/en-us/products/2010-editions/team-foundation-server/overview. Biuletyn Instytutu Automatyki i Robotyki, 31/

24 Łukasz Laszko, Andrzej Stasiak Planning of IT system complex deployment ABSTRACT: This paper presents a set of techniques as well as models supporting planning of IT systems deployment. The complexity of such processes was depicted using an example of the Jazz platform deployment which is widely use in research and didactics on Cybernetics Faculty at the MUT. Additionally, development directions for such processes were indicated, starting from UML s deployment models and ending in comprehensive topology models which provide the basement for architectural experiments. KEYWORDS: topology model, deployment model, deployment planning, domain languages, UML. Praca wpłynła do redakcji: Biuletyn Instytutu Automatyki i Robotyki, 31/2011