Standaryzacja podejścia obiektowego

Czy z wielu metod obiektowych wyłoni się jeden obowiązujący standard.

Czy z wielu metod obiektowych wyłoni się jeden obowiązujący standard.

Zmierzch metod strukturalnych, brak standardu

Wykorzystywane od 20 lat metodyki strukturalne zdążyły okrzepnąć (czytaj: skostnieć). Jednak trudno wśród nich wymienić jedną, która się stała obowiązującą. Brak zgody na wybór jednej, z co najmniej kilku znaczących metodyk, dzieli środowisko analityków systemów.

Producenci narzędzi CASE albo odsunęli problem wyboru (ich narzędzia implementują wiele metodyk, dając wybór użytkownikowi), albo dokonali wyboru jednej, najwyżej wg nich ocenianej metodyki (to ryzyko podjęli wielcy producenci), albo zdecydowali się na stworzenie własnej, unikając w ten sposób ryzyka zmian generowanych przez ich twórców.

To bezkrólewie charakteryzujące podejście strukturalne jest jednym z objawów jego kryzysu. Odpowiedzią na ten kryzys jest powstanie metodyk obiektowych.

Dojrzałość procesu tworzenia oprogramowania

Jednym z podstawowych sposobów oceny metodyki jest określenie stopnia dojrzałości procesu tworzenia oprogramowania, zdefiniowanego w ramach danej metodyki.

Procesem tworzenia oprogramowania nazywamy zbiór aktywności, technik i wskazówek praktycznych stanowiących przewodnik tworzenia oprogramowania. Istnieją kryteria pozwalające mierzyć stopień dojrzałości takiego procesu. Posługując się tymi kryteriami wyróżniono 5 stopni dojrzałości procesu tworzenia oprogramowania:

1. podstawowy - decyzje o rozpoczynaniu pewnych aktywności są podejmowane doraźnie, a powodzenie przedsięwzięcia zależy wyłącznie od indywidualnych umiejętności

2. powtarzalny - określone są takie aktywności, jak: planowanie, zarządzanie zmianami, śledzenie postępu prac, kontrola jakości, zarządzanie konfiguracją

3. definiowalny - proces tworzenia oprogramowania i proces zarządzania procesem tworzenia oprogramowania są określone, udokumentowane i stają się obowiązujące w całej organizacji

4. zarządzalny - określone są kryteria oceny procesów i produktów

5. optymalizowalny - określone są: proces ciągłego ulepszania procesu tworzenia oprogramowania i jego produktów, zarządzanie zmianami techniki, zarządzanie zmianami procesu.

Dojrzałość metodyk obiektowych

Wbrew powszechnym sądom część rozwijanych od lat 80. metodyk obiektowych osiągnęła 4 stopień dojrzałości. Należy do nich między innymi metodyka Shlaer-Mellor.

Trzy generacje metod obiektowych

Do tej pory powstały dwie generacje metod obiektowych.

W latach 80. rozwijane były metody pierwszej generacji. Są wśród nich tak znane jak: Shlaer-Mellor, Coad-Yordon, Wirfs-Brock, Booch, OMT/Rumbaugh. Metody obiektowe pierwszej generacji bazowały na osiągnięciach podejścia strukturalnego. Ich bardzo silny wpływ można zobaczyć w metodyce Shlaer-Mellor.

W latach 80. powstały metody obiektowe drugiej generacji: Booch-94, OMT2, Fusion, SOMA.

Metodyka Fusion (pochodząca z HP) jest oparta na metodykach: Booch, OMT/Rumbaugh i Wirfs-Brock i pokrywa cały proces tworzenia oprogramowania.

Metodyka SOMA (pochodząca z BIS) jest oparta na metodykach obiektowych: HOOD, Coad/Yourdon, Wirfs-Brock i OMT. Jej nowatorstwo polega na rozszerzeniu definicji obiektu o reguły.

Ograniczenia metodyk

Każda metodyka niesie oprócz korzyści również pewne ograniczenia. Wybierzmy dla przykładu metodykę OMT/Rumbaugh (40% rynku). Jej niewątpliwymi ograniczeniami są:

- brak możliwości modelowania wzorców (templates) bardzo przydatnych przy tworzeniu bibliotek klas

- brak możliwości określenia praw dostępu do atrybutów i metod klas (publiczny, prywatny, chroniony)

- brak możliwości modelowania wymagań

- brak możliwości rozróżnienia klas trwałych (persistent) i nietrwałych (non-persistent)

- brak możliwości modelowania komunikacji między klasami.

Każdy producent narzędzi CASE próbuje wzbogacać metodykę na swój niepowtarzalny sposób. Generalnie jest rozszerzana i modyfikowana notacja lub są tworzone dla symboli graficznych formularze, za pomocą których można uzupełnić model o informacje niezbędne do generowania kodu. Te niestandardowe rozszerzenia powodują, że każda organizacja musi dostosować proces produkcyjny do używanego narzędzia.

Pamiętajmy jednak, że ogólnie problem ograniczenia metodyk jest nieusuwalny. Wynika to z twierdzenia Kurta G(dla o

niezupełności pochodzącego z 1927 r.

Poza inżynierię oprogramowania

W roku 1987 została opublikowana metodyka inżynierii systemowej Objectory/Jacobson. Zaproponowała ona spojrzenie na system z punktu widzenia użytkownika, z którym związała scenariusze (use cases). Technika scenariuszy Jacobsona zyskała sobie wielu zwolenników. Metodyka Jacobsona daje możliwość definiowania modelu wymagań.

Standard podejścia obiektowego

Metodyka Unified jest trzecią generacją metod obiektowych. Stanowi unifikację dwóch wiodących metodyk obiektowych OMT/Rumbaugh i Booch-94, które dzielą ponad 50% rynku światowego. Metodyka Unified ma zawierać pewne koncepcje pochodzące od tak znanych metodyków, jak: Jacobson, Wirfs-Brock, Ward, Cunningham, Rubin, Harel, Gamma (twórca wzorców projektowych - design patterns), Odell, Coad, Yourdon, Shlaer i Mellor.

W założeniu metodyka Unified ma stać się standardem dla podejścia obiektowego. Nad zdefiniowaniem tej metodyki pracują od 1994 r. Grady Booch i James Rumbaugh, a ostatnio również Ivar Jacobson.

Kryteria oceny jakości technik diagramowych - oczekiwania użytkowników

Bardzo ważnym elementem metodyki jest notacja. Można sobie wyobrazić następujące kryteria oceny jakości notacji:

- dające się narysować odręcznie - mimo wielkiej popularności narzędzi CASE część prac wstępnych jest prowadzona za pomocą ołówka i papieru; analityk powinien z łatwością narysować każdy z symboli graficznych używanych w danej technice diagramowej; wymaga to od twórców unikania definiowania symboli, które trudno (gdy są narysowane odręcznie) odróżnić od siebie

- jak najmniej nowych symboli graficznych; wprowadzanie nowych symboli graficznych powinno uwzględniać ogólną niechęć analityków do używania coraz to nowych "obrazków"

- jedno - wiele spojrzeń - notacja nie powinna wymuszać pokazywania każdego aspektu systemu na jednym diagramie, gdyż spada czytelność takiego diagramu;

- gęstość informacji; każde spojrzenie na system powinno zawierać dostatecznie dużo informacji by mieć wartość produkcyjną

- spójność reguł - wiele spojrzeń na system wymaga zdefiniowania reguł określających wzajemne relacje między tymi spojrzeniami

- reguły zawierania - dla każdego spojrzenia powinny być określone wymagane symbole graficzne

- żadnych specjalnych miejsc na symbolach graficznych; niektóre notacje wymagają umieszczania etykiet lub napisów w specjalnych miejscach - utrudnia to znacznie rysowanie takich diagramów.

- alternatywne reprezentacje - dopuszczanie pewnej swobody notacyjnej.

Założenia standardu

Twórcy nowej metodyki muszą uniknąć zbyt złożonej notacji, mogącej przykryć rzeczywiste problemy analityka, projektanta i programisty oraz zbyt ubogiej notacji, która mogłaby ograniczyć alternatywne możliwości rozwiązania problemu.

Wprowadzenie zbyt dużej liczby zmian w stosunku do istniejących metodyk może zniechęcić przyszłych użytkowników, wprowadzenie zbyt małej liczby zmian może osłabić zainteresowanie nową metodyką.

Powstanie standardu podejścia obiektowego pozwoli skoncentrować się na podniesieniu poziomu dojrzałości techniki obiektowej. Ponadto pozwoli na zdefiniowanie narzędzi szczelniej pokrywających proces tworzenia oprogramowania i automatyzujących ten proces.

Metodyka Unified powinna:

- umożliwić obiektowe modelowanie systemów

- być łatwa w użyciu dla analityków, projektantów i programistów

- być przeznaczona do modelowania złożonych systemów

- być możliwa do użycia przez człowieka i maszynę.

Poniżej przedstawion listę założeń standardu:

- prostota - metodyka powinna wymagać niewielu pojęć i symboli graficznych

- pełna wyrazu - metodyka powinna dać się zastosować do modelowania szerokiego spektrum systemów

- użyteczna - metodyka powinna się koncentrować wyłącznie na tych elementach, które mają praktyczne znaczenie dla inżynierii systemowej i oprogramowania

- uporządkowana - problemy często spotykane powinny dać się prosto modelować

- wewnętrznie spójna - te same pojęcia i symbole powinny być używane w ten sam sposób w całej metodyce

- ortogonalna - niezależne pojęcia powinny być modelowane niezależnie

- warstwowa - zaawansowane pojęcia powinny być rozszerzeniem bardziej podstawowych pojęć

- stabilna - powinna przyjmować pojęcia i symbole, które są powszechnie używane i zrozumiałe

- diagramy łatwe do rysowania

c rozszerzalna - użytkownicy i producenci narzędzi CASE powinni mieć pewną swobodę w celu rozszerzenia i adaptacji metody.

Twórcy metodyki Unified przedstawiają ją za pomocą metamodelu opisującego notację oraz proces tworzenia oprogramowania (w trakcie opracowywania) w ramach tej metodyki.

Jednym z wyzwań dla twórców metodyki Unified jest włączenie do niej tzw. wzorców projektowych (design patterns).

Konsekwencje powstania standardu dla rynku polskiego

Firmy tworzące oprogramowanie stoją dziś przed szansą dokonania najlepszego wyboru wśród dziesiątek metodyk obiektowych, szansą stworzenia standardu.

---

Jacek Wojcieszyński jest pracownikiem firmy Rodan System.

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

TOP 200