Strategia powielania

Opracowujesz nowy system i chcesz korzystać z technik obiektowych? Uważaj! Czy przypadkiem szacując rentowność całej inwestycji nie przyjąłeś złudnych założeń? Słowo "reuse" staje się popularne - wszyscy chcą mieć kod, nadający się do wielokrotnego wykorzystania. Jest to jedno z obiecywanych dobrodziejstw technik obiektowych. Inne - to redukcja kosztów nadzoru nad ewolucją programu (maintenance) i przyspieszenie wejścia na rynek. Może się jednak okazać, że perspektywa wielokrotnego wykorzystania kodu w aplikacjach opracowywanych z użyciem technik obiektowych jest po prostu iluzoryczna. Dotyczy to zresztą każdej innej techniki opracowywania aplikacji.

Opracowujesz nowy system i chcesz korzystać z technik obiektowych? Uważaj! Czy przypadkiem szacując rentowność całej inwestycji nie przyjąłeś złudnych założeń? Słowo "reuse" staje się popularne - wszyscy chcą mieć kod, nadający się do wielokrotnego wykorzystania. Jest to jedno z obiecywanych dobrodziejstw technik obiektowych. Inne - to redukcja kosztów nadzoru nad ewolucją programu (maintenance) i przyspieszenie wejścia na rynek. Może się jednak okazać, że perspektywa wielokrotnego wykorzystania kodu w aplikacjach opracowywanych z użyciem technik obiektowych jest po prostu iluzoryczna. Dotyczy to zresztą każdej innej techniki opracowywania aplikacji.

Aby wielokrotne wykorzystanie kodu stało się opłacalne, musi być od samego początku uwzględnione w strategii działania. Specjaliści, umiejący skutecznie wykorzystać obiektowe techniki opracowywania aplikacji, osiągają powielenie średnio 60%-70% kodu. Oznacza to, że dla każdej aplikacji muszą napisać 30%-40% nowego kodu, a resztę mogą uzyskać jako wynik powtórnego wykorzystania. Jednak aby dorobić się takiego kodu, trzeba najpierw przygotować:

* obiektowy model działań przedsiębiorstwa

* repozytorium obiektowe

* nadzór nad konfiguracją połączony z obsługą całego projektu

* architekturę odpowiednią dla technologii obiektowej

* no i jeszcze jedno: nie będzie żadnego wielokrotnego wykorzystania, jeśli nie mamy w zanadrzu dwóch lub trzech gotowych projektów z tej samej dziedziny biznesu.

Oto doświadczenia Charlesa Troxella - menedżera, który kierując zespołem projektantów liczącym 4 tys. osób wdrożył 2500 z nich do pracy technikami obiektowymi, używając opracowanych na miejscu procedur obiegu zadań (workflow) w celu wychwycenia - techniką szybkiego prototypowania - reguł, obiektów i procesów działających w przedsiębiorstwie.

Według Troxella kluczem do skutecznego działania jest zabezpieczenie się przed "utratą panowania nad własnymi obiektami". Zespół Troxella opracował specjalne programy - "maszyny wnioskujące" - których używa do kontrolowania zebranych reguł działania przedsiębiorstwa. Po drugie - trzeba hamować rozrost bibliotek klas i zapędy projektantów, definiujących nowe zachowania obiektów.

Grupa Troxella zawarła opis elementów funkcjonowania biznesu w zbiorze stu obiektów - cała reszta daje się z nich wyprowadzić. Opieka nad repozytorium obiektów i procesów należy do zespołu inżynierii wymagań. Bada on spójność każdego projektu z bazą wstępnie zaakceptowanych procesów i obiektów.

Inny ekspert w dziedzinie zarządzania pionem informatycznym - Jim Stikeleather - podkreśla kluczową rolę kompleksowej obsługi projektu. Realizując projekty zawsze zaleca stosowanie CASE-ów z repozytoriami powielanych klas obiektowych, korzystanie z narzędzi do testowania i do nadzoru konfiguracji oraz z kompletnego środowiska rojektowo-programistycznego. "Nie można liczyć na to, że ludzie sami załatwią powielanie kodu. Tę funkcję trzeba zautomatyzować" twierdzi Stikeleather.

John Matthews - prezes Genesis Development Corp. - podkreśla znaczenie technicznej definicji architektury leżącej u podstaw projektu i powielania usług realizowanych przez obiekty. Według jego sugestii zespół opracowujący architekturę systemu powinien pracować równolegle z zespołem odpowiedzialnym za informacyjną zawartość obiektów, aby wyabstrahować te ich działania, które można przenieść do innych aplikacji.

Strategia zachęcająca do tworzenia odpowiednio skonstruowanych programów, zawierająca wymienione elelmenty (i jeszcze inne), jest potrzebna każdemu, kto serio myśli o osiągnięciu wielorazowej używalności kodu. Stawką jest możliwość powielania na poziomie 60%, więc chyba warto inwestować.

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

TOP 200