Co jakiś czas spotykamy się z analizami, dywagacjami i dyskusjami na temat obiektowości. Temat jest niezmiernie interesujący, choćby z uwagi na namiętności jakie potrafi budzić w zagorzałych zwolennikach i prześladowcach koncepcji obiektowych. Bardzo się cieszymy, że na łamach CW pojawił się obszerny artykuł dotyczący obiektowości realizacji złożonych przedsięwzięć informatycznych (M. Łakomy "Dlaczego technika obiektowa", CW 45/169). Ponieważ zaś nie do końca zgadzamy się z zawartymi w nim poglądami (a czasem wręcz zupełnie się z nimi nie zgadzamy), pozwalamy sobie na niniejszą polemikę. Domyślamy się jednocześnie, że wywołanie dyskusji było zamierzeniem Autora, który sam przyznaje się do tego, że lubi wsadzać kij w mrowisko. A więc - mrówki, do dzieła.

W poszukiwaniu panaceum, czyli mitologia informatyki

Jesteśmy przekonani, że jakkolwiek technologia obiektowa będzie odgrywała coraz większe znaczenie w praktyce tworzenia poważnych systemów informatycznych, należy mówić głośno nie tylko o jej zaletach, ale również o wszystkich niewiadomych jakie stoją przed wdrażającymi ją zespołami. Zabrakło w bardzo optymistycznym artykule redaktora Łakomego zdrowego dystansu do triumfalnych okrzyków wznoszonych przez wyznawców obiektowości, dystansu, który powinien wszak cechować wypowiedzi analityka rynku. Prezentowanie podejścia obiektowego jako jedynie słusznego, obowiązującego od jutra w dobrym towarzystwie kroju garnituru, grozi przekształceniem merytorycznej dyskusji w kolejną instancję klasy "rozmów o wyższości świąt Wielkiej Nocy nad świętami Bożego Narodzenia".

Faktem jest, że informatyka była, jest i będzie zasypywana objawieniami w stylu "Oto prawdziwa technologia przyszłości, która pozwoli wyjść projektom informatycznym z zapaści przekroczonych terminów, kosztów i systemów niemożliwych do utrzymania". Do mitologii informatyki należą między innymi:

* Assembler - oto nareszcie język pozwalający zapomnieć o kodach instrukcji, pozwoli ujarzmić pętle i nadać strukturę programom!

* COBOL i inne języki 3 generacji - oto nareszcie narzędzie do łatwego tworzenia dużych systemów biznesowych, niezależne od platformy realizacji, dostępne dla zwykłych ludzi (słynne ADD GIN TO TONIC GIVING MARTINI)!

* Programowanie strukturalne - oto jedynie słuszny sposób tworzenia kodu systemów, śmierć GOTO, jeśli system jest mało wydajny, wystarczy przecież zmienić komputer!

* 4GL - zmaksymalizuj efektywność programistów, zamień specyfikacje w działający kod, pozbądź się kłopotów z projektowaniem dialogu - 4GL zrobi to za Ciebie!

* I-CASE - śmierć programistom, oto nareszcie automat do generowania kompletnych, bezbłędnych systemów informatycznych!

Można by dołączać do tej listy wiele innych pojęć - sloganów informatyki.

Dlaczego zatem mitologia - czy wszystkie wymienione wyżej rozwiązania nie sprawdziły się? Zależy od punktu widzenia. Faktycznie - języki 4GL są bardziej wydajne od COBOL-u, a automatyczne generowanie pozwala zredukować wysiłek programistów ponoszony na typowe, trywialne fragmenty konstrukcji. Sęk w tym, że mimo rozwijającej się technologii, kryzys inżynierii oprogramowania ogłoszony w latach 70. trwa, ma się dobrze i żadna z nowości technologicznych nie zdołała tego, jak na razie, zmienić. W tym sensie żadne panaceum nie spełniło pokładanych w nim nadziei. Jedyny, jak na razie, rzetelnie udokumentowany sposób radzenia sobie z objawami kryzysu, polega na aplikowaniu właściwych technologii we właściwych - to znaczy przynoszących zwrot poniesionych inwestycji - miejscach procesu produkcyjnego.

Opłacalność, to inżynierska i biznesowa kategoria myślenia. Przy okazji rozmowy, poruszającej m.in. kwestie strategii inwestowania w rozwój technologii informatycznych - z dyrektorem wydziału informatyki - jednego z dużych zakładów przemysłowych, nasz rozmówca zilustrował swój punkt widzenia przykładem: w zakładzie tym współżyją ze sobą obrabiarki pochodzące jeszcze sprzed wojny i stale skutecznie wypełniające swą funkcję oraz bardzo nowoczesne urządzenia sterowane numerycznie. Każde z nich jest niezbędne w cyklu technologicznym, ale każde z nich w innym stopniu pozwala zwrócić inwestycje poniesione na modernizację. Jesteśmy przekonani, że tym, czego producenci oprogramowania i zespoły projektowe potrzebują, nie jest myślenie w kategoriach panaceum, a więc myślenie magiczne. Żadna technologia nie ma siły sprawczej zdolnej zamienić chaotyczne wytwórstwo aplikacji w wydajny i uporządkowany proces produkcyjny. Potrzebne jest tu myślenie inżynierskie, rozważenie wszystkich kosztów związanych z inwestycją i konkretnych efektów, jakie usprawnienie może przynieść organizacji.

Jaki właściwie jest ten koń?

Znane jest powszechnie powiedzenie, że "koń jaki jest, każdy widzi". Niestety, kiedy dwie osoby mówią o obiektowości, nie zawsze mogą być pewne, że mówią o tym samym koniu. Nawet rozmowa o własnościach obiektowych narzędzi implementacji (na przykład językach programowania) może prowadzić do nieporozumień. Przypomina nam się artykuł z magazynu BYTE (marzec 1989, Peter Wegner, "Learning the language") omawiający popularne języki programowania funkcjonujące na rynku jako narzędzia obiektowe -C++, Smalltalk, Simula, CLOS (obiektowe narzecze Lispu) i kilka innych. Okazało się, że zbiór wspólnych własności tych języków, takich jak możliwość definiowania obiektów, możliwości przesyłania komunikatów, możliwości definiowania klas obiektów, różnych form dziedziczenia, jest pusty! Wydaje się, że dzisiaj panuje już pewien kanon wskazujący "pakowanie" usług i danych w obiekty oraz dziedziczenie własności w strukturze klas jako niezbędny składnik obiektowych narzędzi implementacji. Z drugiej jednak strony, Visual Basic postrzegany jest na rynku jako narzędzie obiektowe, co stoi w jawnej sprzeczności z wymienionymi powyżej postulatami. Bywa że narzędzia obiektowe ograniczają swoją obiektowość ds. związanych z interakcją z użytkownikiem - pozwalają więc definiować tylko obiekty dialogowe skupiające w sobie dane i obsługę zdarzeń.

Prawdziwy problem zaczyna się jednak w momencie tworzenia obiektów "trwałych" - przechowywanych w bazach danych. Wciąż brakuje standardu obiektowych systemów baz danych na miarę SQL-a. Niewiele dużych organizacji zdecydowałoby się dzisiaj na powierzenie swoich danych biznesowych bazom obiektowym z równym zaufaniem, jakie okazują bazom takim jak Sybase, Informix czy systemom dostępnym na maszynach klasy mainframe.

Magia liczb

Bardzo wysoka wydajność zespołów projektowych jest jedną z najczęściej cytowanych korzyści wynikających z zastosowania obiektowych narzędzi i metod realizacji systemów. Nie mamy zamiaru kwestionować rzetelności tych danych, jestśmy o niej przekonani. Chcielibyśmy jedynie zwrócić uwagę na kilka aspektów, które mogą w istotny sposób wpłynąć na odczytywanie tych danych.

Po pierwsze - dane często dotyczą projektów w których dominuje reengineering. Oznacza to, że zespół projektowy doskonale zna wymagania użytkownika, zna specyficzne wymagania wydajnościowe, wie co sprawdziło się, a co nie, w istniejącym systemie. Buduje w kilka miesięcy rozwiązanie obiektowe korzystając z wieloletniego doświadczenia związanego z opracowaniem i utrzymaniem istniejącego systemu. Nie oznacza to znowu, że technologia obiektowa nie jest wydajna (przynajmniej w sferze projektowania i implementacji). Skok wydajności możliwy do osiągnięcia w zwykłych projektach nie musi jednak być tak wielki, jak to się z pozoru wydaje, co w istotny sposób wpływa na ocenę opłacalności zmiany technologii.

Bywa też tak, że podawana wydajność dotyczy projektów, w których specyfikacja wymagań została opracowana metodami tradycyjnymi i czasu jej realizacji nie uwzględnia się przy oszacowaniu wydajności zespołu. Sami spotkaliśmy się kilka razy z tego typu przykładami. Nie zawsze fakt wykorzystywania tradycyjnej (strukturalnej) specyfikacji wymagań był podawany explicite. To niedopowiedzenie powoduje oczywiście "przekłamanie oczekiwań", jako że specyfikację wymagań trzeba jakoś wykonać, a na temat obiektowych metod analizy nie są nam znane żadne dane, które mogłyby świadczyć o ich przewadze nad tradycyjnymi w kwestii wydajności.

Wreszcie ostatnia sprawa. Projekty w technologii obiektowej, nawet te poważne, stanowią często pilotaż nowej technologii implementacji realizowany przez zespół wysokiej klasy specjalistów, znających "od podszewki" środowisko implementacji, wykorzystywane techniki projektowania i architekturę techniczną. Wiadomą rzeczą jest, że przeciętny zespół projektowy składa się z przeciętnych ludzi, dla których wzrost wydajności może znacznie odbiegać od rezultatów osiągniętych przez taką "brygadę SWAT" (Specialists With Advanced Tools).

Król nie umarł!

Niezwykle zbulwersowała nas informacja o tym, że "dawne metodologie się nie sprawdziły". Podejrzewamy, że chodzi nie tyle o metodologie (metodologia to wiedza dotycząca metod) co o metodyki, przy czym przymiotnik "dawne" oznacza - prawdopodobnie - klasyczne metodyki strukturalne. Nie wiemy oczywiście na jakich faktach oparte jest to stwierdzenie, co utrudni nieco polemikę. Ponieważ z argumentami podobnymi do tych, jakich użył Autor artykułu, można się spotkać w książce Yourdona na temat analizy obiektowej (nb. jest to niezwykle cenna inicjatywa wydawnicza na naszym rynku, pozbawionym praktycznie poważnych publikacji dotyczących inżynierii oprogramowania), pozwolimy sobie na wykorzystanie tego faktu w niniejszej dyskusji.

Należy odróżnić przykłady złej metodyki od przykładów jej złego stosowania. Niektóre przykłady z Yourdona zdecydowanie należą do tej drugiej kategorii. Yourdon podaje przykład projektu, w którym dwa realizowane niezależnie wątki analizy (modelowania danych i procesów) prowadziły do różnych wyników - analitycy od danych pogłębiali zrozumienie systemu i tworzyli coraz bardziej złożony model, podczas gdy analitycy od procesów budowali model przepływu danych stopniowo dekomponując funkcje. Problem polegał na tym, że oba zespoły pracowały niezależnie, nie uzgadniały lub nie chciały uzgadniać na bieżąco wyników prowadzonej analizy. Próba dokonania tego dopiero po zbudowaniu modeli DFD i ERD nie może zakończyć się powodzeniem. Jednym z podstawowych założeń metodyk strukturalnych jest podejście iteracyjne - na ogół nie buduje się dobrego modelu od "pierwszego cięcia". Proces ten wymaga kolejnych przybliżeń, których zrealizowanie jest możliwe tylko dzięki dobrej komunikacji z użytkownikiem oraz między grupami analityków.

Współczesne podejścia strukturalne dostarczają kilku technik wymagających wspólnego spojrzenia na system od strony diagramów DFD i ERD. Techniki te (np.: historia życia encji, tablica incydencji encja-proces, tablica CRUD itp.) w pewien sposób wymuszają bieżącą synchronizację modeli. Dlatego dzisiaj byłoby znacznie trudniej osiągnąć wynik równoległej, niezależnej pracy nad modelami DFD i ERD niż w połowie lat 80., skąd pochodzi przykład Yourdona.

Dodamy tylko, że stwierdzenie, jakoby tego typu sytuacja nagminnie szła w parze z wykorzystaniem różnych narzędzi do modelowania danych i procesów, jest chyba zupełnym nieporozumieniem. Nie znamy żadnej organizacji w kraju czy za granicą, która mogłaby sobie pozwolić na zastosowanie do jednego projektu dwóch różnych, nie zintegrowanych narzędzi CASE. Oczywiście zdarza się zastosowanie innej platformy do etapu analizy czy strategii a innej do konstruowania systemu, jednak wykorzystanie dwóch narzędzi do tworzenia dwóch komponentów tej samej specyfikacji to chwyt czysto literacki - to się w przyrodzie nie zdarza.

Pęknięcia, szczeliny i kit

Yourdon dużo mówi o pęknięciu w teorii związanym ze złym dopasowaniem klasycznych modeli procesów i modeli danych. Uważa że analityczne modele obiektowe rozwiązują sprawę i nareszcie przeklęta szczelina zniknie z cyklu projektowego. Naszym zdaniem, podstawowe nieporozumienie wiąże się z rolą, jaką dawne metody strukturalne nadawały diagramom przepływu danych próbując opierać na nich strukturę aplikacji. Do tego diagramy te rzeczywiście nie bardzo się nadają. Nowoczesne metodyki strukturalne dawno zrezygnowały z takiego wykorzystania DFD, pozostawiając im jednak tę rolę do jakiej nadają się znakomicie - do wyrażania zakresu systemu, jego ogólnej struktury funkcjonalnej i architektury z punktu widzenia użytkownika. Tak się składa, że notacja DFD okazuje się w praktyce bardzo intuicyjna, dobrze oddaje dynamikę przepływu informacji i pozwala określić podstawowe źródła i ujścia danych, w sposób umożliwiający aktywny udział oraz zrozumienie ze strony użytkowników.

Z drugiej strony, prezentacja funkcjonalnej strony systemu w postaci usług doczepionych do statycznej struktury informacji (struktur całość-część lub gen-spec) utrudnia ocenę i zrozumienie koncepcji systemu narzucając bardzo drobiazgowy podział na usługi dedykowane do poszczególnych klas i obiektów. Na taki podział jest miejsce wówczas, kiedy przechodzimy od architektury do opracowywania poszczególnych aplikacji, w których techniki obiektowe znakomicie sprawdzają się przy opisywaniu modelu koncepcyjnego aplikacji. Tak więc klasyczne, przeglądowe modele danych i procesów wydają się być ciągle aktualne i nie warto wyrzucać ich do lamusa, zwłaszcza w wypadku poważniejszych przedsięwzięć wymagających intensywnej współpracy z użytkownikiem, podejścia iteracyjnego i solidnego zaplanowania.

Sądzimy że znacznie poważniejszym "pęknięciem w teorii" jest brak możliwości zaimplementowania specyfikacji obiektowych - rzecz nie do uniknięcia jeśli wykorzystujemy np. relacyjną technologię przetwarzania danych. Naprawdę nie wiemy co jest zadaniem trudniejszym - przejście od obiektowej specyfikacji do nieobiektowego środowiska implementacji, czy przejście od strukturalnej specyfikacji analitycznej do strukturalnego środowiska implementacji. Pewną podpowiedź może dać praktyka. Od kilkunastu lat rozwijane i stosowane są strategie przejścia od modelu DFD systemu do specyfikacji projektowej, którą najczęściej bywa zestaw diagramów struktury programu (Structure Chart - SC). Proces ten nie jest łatwy, wymaga dobrego przygotowania i pewnego doświadczenia od osoby podejmującej ów wysiłek, pozwala na wybór strategii przejścia w zależności od charakteru systemu. Wbrew obiegowym opiniom proces ten jest dość dobrze określony i opisany (np. Page-Jones). Nieco inaczej wygląda problem w przypadku realizacji specyfikacji obiektowej w relacyjnym środowisku bazodanowym. Pierwsze rozwiązania tego w pewnym sensie "nienaturalnego" połączenia (obiekty i relacyjna baza danych) zaczynają się dopiero pojawiać. Zbyt wcześnie jest na sprawdzone metody, w tej dziedzinie świat jest jeszcze na etapie pionierskim.

Młoda niedojrzałość

Na obecnym etapie nie można wymagać dojrzałości od obiektowych metod analizy i projektowania systemów informatycznych. Jest to podejście jeszcze bardzo młode, pierwsze publikacje na ten temat pojawiły się pod koniec lat 80. Dynamika rozwoju metodyk obiektowych jest bardzo duża. W ciągu kilku lat przebyły one drogę od etapu raczkowania, w którym widoczne były poszukiwania prowadzone w wielu kierunkach trochę "po omacku", do etapu stabilnego i ciągłego rozwoju, kiedy to zarysowuje się jedno dominujące podejście silnie bazujące na dorobku strukturalnym (Rumbaugh, Shlaer-Mellor). Metody strukturalne wymagały około dziesięciu lat na osiągnięcie poziomu dojrzałości pozwalającego na stosowanie ich w sposób przemysłowy (pierwsze publikacje na temat projektowania, a potem i analizy strukturalnej pojawiają się w połowie lat 70.). Kolejnych pięć lat potrzebnych było na zbudowanie na ich bazie spójnych i dopracowanych procesów produkcji oprogramowania, opisujących ściśle cykl życia projektu od etapu analizy wstępnej po pielęgnację gotowego systemu oraz proces jego zarządzania (norma DOD-2167 i DOD-2167A, Digital Program Methodology DECa, LBMS Systems Engineering itp. - są to produkty z końca lat 80. i początku lat 90.).

Dynamika rozwoju metodyk obiektowych jest większa -prawdopodobnie procentują doświadczenia zdobyte w metodykach strukturalnych. Podejście strukturalne było przecież pierwszym systematycznym, stosowanym w sposób przemysłowy, procesem produkcji oprogramowania. Mimo tak szybkiej ewolucji metodyk obiektowych, nie można jeszcze powiedzieć, że są one dojrzałe. Nie dysponują one wyraźnie ukształtowanymi technikami ani standardami. Stosowanie podejścia obiektowego do całego cyklu projektowego jest obecnie działalnością pionierską. W ogromnej większości przypadków menedżerowie projektów dążąc do minimalizacji ryzyka niepowodzenia i uzyskania przewidywalnych wyników, nie mogą sobie pozwolić na stosowanie nieustabilizowanego podejścia.

Przyszłość w tej dziedzinie wydaje się przewidywalna. Eksperci zajmujący się metodykami obiektowymi oraz producenci obiektowych środowisk rozwoju oprogramowania (w tym także narzędzi CASE) są zdania, że techniki obiektowe staną się przemysłową metodą produkcji w ciągu kilku najbliższych lat. Wiele wskazuje na to, że mają rację - wspomniana już metodyka obiektowa Rumbaugh, bazująca na podejściu strukturalnym, znajduje coraz większe uznanie, proces rozwoju oprogramowania lansowany przez duet Shlaer-Mellor stanowi pierwsze spójne ujęcie cyklu życia projektu oparte na metodykach obiektowych. Metoda Shlaer-Mellor spełnia nieźle kryteria procesu rozwoju oprogramowania zdefiniowanego w modelu Capability Maturity Model. Jest to pięciostopniowy model dojrzałości procesu produkcji oprogramowania opracowany przez Software Engineering Institute w latach 1992-93. Współczesne podejścia obiektowe oraz kierunki, w jakich zmierzają, są pasjonującym tematem, świetnie nadającym się na osobny artykuł.

Konkluzją dla powyższych dyskusji może być stwierdzenie, że metodyki obiektowe rozwijają się bardzo szybko, stanowią podejście coraz bardziej dojrzałe, jednak przemysłowe ich stosowanie, pozwalające efektywnie osiągać przewidywalne produkty będzie możliwe dopiero za kilka lat. Obecnie niemal jedynym wyjściem jest stosowanie podejścia tradycyjnego - czyli strukturalnego. Dostępne jest ono na rynku metod produkcji w wielu mniej lub bardziej sformalizowanych odmianach, jest silnie wspierane przez narzędzia implementacji w przeciwieństwie do podejścia obiektowego. Na pewno nie można powiedzieć, że podejście strukturalne się nie sprawdziło. Zgodnie z nim wykonano zbyt wiele systemów. Niepowodzenia oczywiście się zdarzają, ale są one przecież cechą działalności ludzkiej.