Rozmowa z Nasserem Kettani z IBM/Rational, autorem publikacji na temat modelowania i wykładowcą uniwersytetu Paris Dauphine.

Oficjalna premiera IBM Rational Software Development Platform odbyła się kilka tygodni temu z wielką pompą. Czy produkt jest aż tak przełomowy, czy też może ważniejszy jest fakt, że został on ściśle zintegrowany z technologią Eclipse?

Pod jedną wspólną nazwą IBM Software Development Platform (SDP) oferujemy 7 produktów, część nowych, część istniejących, ale znacznie ulepszonych, praktycznie napisanych na nowo, umieszczonych na platformie narzędziowej open source Eclipse 3.0. Wykorzystują one całą gamę standardów i technologii, w tym UML 2.0, rozwiązania architektoniczne sterowane modelami (MDA), architekturę usługową SOA, nową technologię testowania Hyades i wiele innych.

Przyglądając się używanym narzędziom do programowania, widzimy całą paletę niesłychanie różnorodnych produktów: edytorów tekstu, debuggerów, testerów, programów do konfiguracji, zarządzania zmianami, zbierania wymagań itp. pochodzących od różnych dostawców. Mniej więcej od 5 lat następuje ich integracja, chociaż jest to proces trudny, głównie z powodu braku standardów współpracy i komunikacji, w tym na różnych platformach systemowych.

IBM ponad 3 lata temu wystartował z projektem Eclipse z zamysłem dostarczenia na rynek ram integracyjnych do włączania w nie różnych narzędzi, dostarczanych nie tylko przez IBM, ale również przez inne firmy i przez społeczność otwartego kodu. Każdy może pobrać kod Eclipse i budować na jego podstawie własne narzędzia. Celem było stworzenie jednorodnego ekosystemu dla narzędzi programistycznych.

Eclipse można uznać za rodzaj uniwersalnej szyny software'owej, do której włącza się różne narzędzia. Jest to zresztą jedyny taki system na rynku. Jednym z ważniejszych elementów Eclipse są ramy EMF (Eclipse Modelling Framework), służące do budowy różnych standardów w ekosystemie, w tym ich ścisłej integracji semantycznej. Na EMF oparte zostały pakiety Eclipse do obsługi UML 2.0, Javy, C++ i inne.

W jaki sposób IBM Software Development Platform wspiera budowę solidnej i elastycznej architektury systemu informatycznego? Pojawia się tu pojęcie architektury software'owej...

Jest wiele elementów w SDP, które temu sprzyjają. UML 2.0 jest to jedyny standardowy język, który pozwala na wizualne wyrażenie i opisanie architektury systemów. Ważne jest wsparcie dla opracowanego przez konsorcjum OMG standardu architektury sterowanej modelami (MDA - Model Driven Architecture przyp. red.), charakteryzującej się tym, że pozwala modelować architekturę systemu w sposób niezależny od jego implementacji. Narzędzia SDP pozwalają na przekształcenie modelu PIM (Platform Independent Model) na model specyficzny dla platformy PSM (Platform Specific Model). IBM bardzo serio wspiera również usługi sieciowe WS i architekturę usługową SOA (Service Oriented Architecture). Czwarty element to możliwość walidacji i sprawdzenia rozwiązania architektonicznego: na podstawie kodu opracowanego przez programistów architekt aplikacji może sprawdzić, czy wszystkie wymagania zostały spełnione.

To dyscyplina, która pojawiła się w ciągu ostatnich 10 lat jako wynik pracy naukowców z Uniwersytetu Kalifornijskiego w Irvine, Mary Shaw i Davida Garlana z Uniwersytetu Carnegie Mellon, Ericha Gammy z IBM Zurich oraz wysiłku firm Rational Software i Microsoft. Architektura software'owa to spójny zestaw abstrakcyjnych wzorców (patterns) sterujących każdym aspektem projektowania większego systemu software'owego. Pozwalają one określić, jak się system buduje, opisuje i dokumentuje, testuje, uwiarygodnia...

Modelowaniu od zawsze towarzyszyło hasło jakości. W jaki sposób nowa platforma narzędziowa IBM wpisuje się w ten sposób myślenia o produkcji oprogramowania? Co to jest Rational Unified Process?

Nikt nie potrafi wbudować jakości w już istniejący produkt. Jakość musi być wbudowywana w program na każdym etapie jego tworzenia - każdy uczestnik tego procesu musi dbać o jakość. W SDP wbudowaliśmy procedury, które pozwalają na sprawdzenie na każdym etapie projektu poprawności architektury, modelu, kodu i gotowego programu. Dbanie o jakość to bardziej problem kultury korporacyjnej niż problem techniczny.

Przyglądając się procesowi tworzenia oprogramowania, kilka lat temu stwierdziliśmy, że nie istnieją formalnie zdefiniowane procedury opisujące proces. Wydano wiele książek na ten temat, ale zawierają one jedynie pewne pomysły - nie uczą jak tworzyć oprogramowanie. Pracując z klientami, IBM zdobył ogromne doświadczenie w tej dziedzinie - przekonaliśmy się empirycznie co działa, a co nie. Na tej podstawie powstał zbiór najlepszych praktyk, zwany właśnie Rational Unified Process (RUP). RUP zawiera dokumentację, procedury, przypadki użycia (use case), przykłady itp. Jeśli nie wiesz jak coś zrobić, zawsze znajdziesz informację o tym w RUP. Zalecenia RUP można pobrać z Internetu.

RUP stanowi również coś w rodzaju standardu przemysłowego, fundamentu. Sprawił, że mówiąc o przypadkach użycia wszyscy mają obecnie na myśli to samo. RUP dokumentuje wszystkie procesy związane z tworzeniem oprogramowania - od architektury i modelowania po kodowanie i testowanie. Dzięki RUP firmy uzyskują dodatkową korzyść w postaci jednolitości procesów, co ułatwia przenoszenie ludzi z jednego projektu do innego i włączanie do nich nowych pracowników.

Czy RUP nie jest więc zbyt ujednolicony, w sensie - zbyt mało elastyczny, a jednocześnie zbyt skomplikowany?

Jest oczywiste, że żadne dwie organizacje nie stosują takich samych procesów w tworzeniu oprogramowania; nawet na poziomie dwóch projektów w tej samej organizacji procesy są różne. Wszystko zależy od wymagań, poziomu doświadczenia zespołu, harmonogramu, kosztów, technologii itd.

IBM oparł nową wersję RUP na opracowanym przez OMG standardzie Software Process Engineering Metamodel (SPEM), pozwalającym opisywać i modelować procesy i realizować je w postaci komponentów. Cały RUP jest więc zestawem komponentów o różnym poziomie szczegółowości, dostosowanych do różnego poziomu wiedzy i doświadczenia użytkowników.

Tworzenie oprogramowania to działalność inżynierska, nie sztuka - jak uważa wielu programistów. IBM wspomaga użytkowników we wdrażaniu dobrych praktyk inżynierskich. Narzędzia IBM pozwalają klientom dostosowywać swoje praktyki do zmieniających się potrzeb, definiować procesy i włączać je do RUP w postaci zestawu komponentów.

Rozmawiał Marian Łakomy