Architektury, komponenty i uparty Polak

Z Wojtkiem Kozaczyńskim, pełniącym funkcję Director of Architectures & Application Frameworks w firmie Rational, rozmawia Jakub Chabik.

Z Wojtkiem Kozaczyńskim, pełniącym funkcję Director of Architectures & Application Frameworks w firmie Rational, rozmawia Jakub Chabik

Architektury, komponenty i uparty Polak

Wojtek Kozaczyński, pełniący funkcję Director of Architectures & Application Frameworks w firmie Rational.

Pamiętam sytuację z początku lat dziewięćdziesiątych, kiedy obiektowe modelowanie systemów dopiero się zaczynało. Istniało mnóstwo metod, metodyk, języków, guru i standardów. Co zmieniło się od tego czasu?

Najważniejsza zmiana to, że już nie ma chaosu - dziesięciu języków i dwudziestu metodyk, tylko jeden standard: Unified Modeling Language. Jest także jedna, niezależna od producentów organizacja Object Management Group (OMG), która wspiera ten standard. Jest także duża społeczność użytkowników tego standardu, która korzysta z niego i jednocześnie pomaga w jego rozwoju.

Właśnie UML oraz Rational Unified Process (RUP) są krytykowane za to, że są obszerne, trudne i ciężkie. Jednocześnie jest grupa ludzi, który odrzucają ten cały bagaż i rozwijają Extreme Programming (XP) czy Agile Modeling (AM). Część ludzi mówi "musimy coraz bardziej rozwijać i dopracowywać metody złożone", a inni mówią "proste rzeczy powinny być proste". Dlaczego jest tak, że - paradoksalnie - świat idzie w dwie przeciwne strony?

To jest argument tyleż często używany co niesłuszny. W wielu przypadkach jest on propagowany przez ludzi, którzy mają w tym finansowy interes. Gdyby miał Pan rozrusznik serca, to wolałby Pan, żeby był on robiony - przy użyciu RUP czy XP?

Zacznijmy jednak od początku. RUP co prawda w nazwie ma słowo process, ale w istocie jest to process framework. Każda firma powinna wziąć tę podstawę i wyprodukować proces dostosowany do swoich wymagań. Mamy nawet narzędzia do dopasowania - jeżeli kupi się od nas RUP, to każdy ma możliwość "włączania" i "wyłączania" poszczególnych elementów procesu. Jeżeli to nie wystarcza, to mamy również RUP Process Workbench - narzędzie, za pomocą którego można zmienić całą zawartość procesu. RUP może więc być dowolnie duży albo dowolnie mały i jest to wyłącznie wynik świadomego dopasowania procesu do potrzeb firmy. Czytelnicy mogą znaleźć informacje o XP wersji RUP na naszej stronie internetowej.

Druga rzecz to UML. W pewnym momencie stał się on się takim przysłowiowym koszem na śmieci - jak ktoś czegoś potrzebował, dodawało się to do UML. W pewnym momencie zrozumienie standardu stało się trudne. Podstawowy, użytkowy podzbiór UML jest bardzo prosty i większość ludzi korzysta jedynie z tego małego podzbioru.. Prace nad wersja 2.0 UML mają go uprościć.

Trzeba jednak uczciwie powiedzieć, że niektóre ułatwienia nie mogą posunąć się poza pewną rozsądną granicę. W inżynierii systemów są problemy, które zwyczajnie nie są proste. Czasami trzeba nawet zejść na poziom języka programowania.

Wspomniał Pan o języku programowania. Pamiętam, na początku lat dziewięćdziesiątych okładkę amerykańskiego tygodnika, który głosił, że narzędzia CASE zawładną całkowicie tworzeniem systemów, a języki programowania odejdą do lamusa. Dlaczego ta wizja się nie sprawdziła? Czy kiedyś ma szansę się sprawdzić?

W narzędziach Rationala staramy się przenieść naprawdę wiele rzeczy do, nazwijmy to, programowania wizualnego. Ale w wielu miejscach wyświetlamy ramkę i prosimy o wpisanie kodu. Po prostu niektóre rzeczy najłatwiej zapisać w językach programowania. Weźmy na przykład podstawową konstrukcję programistyczną, jak jaką jest klauzula warunkowa if...then...else. Żeby zapisać to wizualnie trzeba narysować co najmniej trzy bloki i pięć połączeń. To po prostu nie ma sensu, łatwiej jest to zapisać w kodzie.

Natomiast wiele rzeczy, szczególnie rzeczy strukturalne - i to jeszcze struktury wyższego poziomu - powinny być modelowane w językach wizualnych. Języki programowania nie mają środków opisu dla tego poziomu abstrakcji. Języki czwartej generacji mają pewne konstrukcje agregujące kilka lub kilkanaście elementów tradycyjnego języka programowania, ale żaden z nich nie potrafi przedstawić struktur, zależności czasowych, odpowiedzialności, itd. Najistotniejszą kwestią jest tak naprawdę continuum, łagodne przejście pomiędzy wysokim poziomem abstrakcji zapewnianym przez języki wizualne, a szczegółowością, którą oferuje język programowania.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200