Obiektowe narzędzia do opracowania aplikacji wymagają obiektowego modelowania.

Czy pamiętacie sławne zdanie Toma Hanksa z filmu Forrest Gump? "Źycie jest jak pudełko czekoladek. Nigdy nie wiesz, co ci się przytrafi." Podobne zdanie dobrze oddaje stan narzędzi do opracowania aplikacji.

Pierwszymi narzędziami do opracowania aplikacji były kompilatory wywoływane z linii poleceń, edytory plików źródłowych i program make, pozwalający na minimalną automatyzację pracy (najprostsza analogia: czekoladka bez nadzienia). Następnie pojawiły się zintegrowane środowiska IDE, zawierające wbudowany debugger (czekoladka nadziewana). Obecnie trudno sobie wyobrazić czasy, kiedy debugger nie był dostępny. Czy są jeszcze inne niezbędne narzędzia?

Jest to już indywidualna sprawa; kiedyś był to program lint do usuwania błędów składniowych z kodu źródłowego C. Obecnie Borland oferuje np. Codeguard do wykrywania i analizy błędów, a Numega podobny program o nazwie Bounds Checker. Wykrywają one wiele błędów, dających zupełnie niezrozumiałe komunikaty, wynikające z przekroczenia zakresu wskaźników, zapisu do okien, niszczenia zawartości pamięci i in. (czekoladka z orzechem).

Nadal jednak jesteśmy jeszcze na poziomie narzędzi co najwyżej drugiej generacji, których użycie jest męczące, a przydatność do opracowania skomplikowanych aplikacji w biznesie kwestionowana.

Aby opracować aplikacje w technice obiektowej, zespół programistów musi dysponować znacznie większym zestawem narzędziowym, pozwalającym na projektowanie, realizację, rozpowszechnianie, dokumentowanie i poprawianie projektu.

Metodyki i narzędzia do projektowania

Pierwsza generacja. Publikacje na temat obiektowych metod analizy i projektowania aplikacji pojawiły się już wiele lat temu. Teoretycy metod obiektowych proponowali metodyki Boocha (Grady Booch - firma Rational Software), Object Modelling Technique OMT (Jim Rumbaugh, firma General Electric) i Use Case (Ivar Jacobson, firma Objectory). Natomiast narzędzia do niektórych metodyk nie pojawiły się wcale albo tak późno, że programista, który potrzebował stosować jakąś metodykę, był skazany na papier, ołówek lub tablicę. W jednym ze znanych domów software'owych w Polsce spotkałem się z opinią, że najlepszym narzędziem do metodyki OMT jest biała tablica i komplet mazaków.

Druga generacja. Zaznaczyła się pojawieniem liczby narzędzi automatyzujących pewne aspekty procesu projektowania aplikacji obiektowych. Wprowadzenie narzędzi spowodowało czasem modyfikację metodyki, gdy okazywało się, że teoria i praktyka zbyt daleko rozmijają się. W ostatnich kilku latach pojawiły się takie narzędzia, jak Rational Rose for Windows, Select OMT, Objectoruy, Popkin System Architect i in. Okazało się też, że wiele z narzędzi i metody zbliżyło się do siebie na tyle, że zaczęto myśleć o ich ujednoliceniu.

Pojawiły się także narzędzia "dwukierunkowe", pozwalające na połączenie procesu modelowania i kodowania przy ścisłym związku tych etapów: zmiana w kodzie ujawniała się w modelu i odwrotnie. Przykładem takiego narzędzia jest nowa wersja Rationa Rose i pakiet Together C++ (niemieckiej firmy Object International) dołączany do najwyższych wersji Borland C++.

Trzecia generacja. To już intensyfikacja prób ujednolicenia metodyki i stworzenia zunifikowanego języka modelowania (Unified Modelling Language - UML). Język ten łączy najlepsze cechy innych języków, obejmuje wszystkie etapy projektowania aplikacji, ujednolica notację i dokumentację aplikacji obiektowych. Wpływ na jego opracowanie, mimo że jest głównie dziełem metodyków z firmy Rationa Software, mieli G. Booch, I. Jacobson, P.Coad, E. Yourdon, W. Cunnigham i inni.

Bardziej szczegółowe informacje na temat UML można znaleźć w witrynie Web firmy Rational Rose www.rational.com.