Czy narzędzia CASE mają przyszłość?

Od pewnego czasu w środowiskach programistycznych pojawiła się wątpliwość czy narzędzia CASE są najlepiej przystosowane do opracowania dużych aplikacji w przedsiębiorstwach.

Od pewnego czasu w środowiskach programistycznych pojawiła się wątpliwość czy narzędzia CASE są najlepiej przystosowane do opracowania dużych aplikacji w przedsiębiorstwach.

Programowanie strukturalne, wprowadzone i dość powszechnie przyjęte w praktyce programistycznej, propaguje dwie metody opracowania i przygotowania programów, tworzące metodologię opracowania aplikacji: z góry na dół (top-down) z dołu do góry (bottom-up), ściśle ze sobą powiązane. Jednak nie wszyscy wybitni informatycy, zgadzają się z tą metodologią tworzenia oprogramowania. Na przykład Donald E. Knuth promuje metodę opartą raczej na sposobie myślenia człowieka, który najchętniej pisze i dokumentuje program w takiej kolejności, w jakiej na myśl przychodzą mu rozwiązania poszczególnych problemów. Jest to tzw. metoda programowania literackiego (literate programming). Na komputer zaś składa obowiązek poskładania w logiczną całość swych cząstkowych produktów, wysupłania z nich dokumentacji i stworzenia kompletnej aplikacji.

W opracowaniu aplikacji dla przedsiębiorstw dominują także dwie metody pracy. Jedna jest oparta na systematycznym wykorzystaniu metodologii CASE, zgodnie ze wzorcami opracowanymi przez najwybitniejszych jej twórców. W znacznej mierze korzystają oni z metod programowania strukturalnego, rozpoczynając rozwiązywanie problemu od opracowania hierarchicznej struktury związków i zależności, które po dostatecznym dopracowaniu szczegółów stają się podstawą do opracowania aplikacji. Jest to więc typowa metoda top-down.

Druga metoda w znacznej mierze korzysta z pomocy użytkownika. Na podstawie stałych rozmów z użytkownikami tworzy się prototyp aplikacji i poddaje go ciągłej weryfikacji przez użytkownika. Ponieważ prosty prototyp nie wymaga wiele pracy, to można przedstawiać użytkownikowi do oceny wiele takich prototypów i dość szybko uzyskać jego akceptację. Potem zaś następuje etap dopracowania szczegółów aplikacji i wykonania właściwego jej projektu, zgodnego z koncepcją przyjętą przez użytkownika, który poczuwa się do współautorstwa projektu. Łatwiej więc akceptuje końcowy produkt, gdyż w części się z nim utożsamia. Ta metoda często nosi nazwę szybkiego przygotowania aplikacji (RAD -rapid application development).

Brak zrozumienia u użytkownika

Jeszcze do niedawna wśród programistów bardzo popularne podejście do opracowania nowych programów polegało na przygotowaniu nowego "rewelacyjnego" produktu i "rzucaniu" go przed tłumy, które powinny najpierw stanąć w zachwycie przed wspomnianym produktem, potem zaś rzucić się nań hurmem. I tak właśnie postępuje się przy przygotowaniu aplikacji opartych na metodach CASE. Zwykle kończy się to pełnym rozczarowaniem. Użytkownik lubi mieć swoje zdanie na temat tego, co jest dla niego najlepsze oraz brać czynny udział w opracowaniu aplikacji, którą będzie się posługiwał.

W metodzie CASE zasadniczy kontakt z użytkownikiem ogranicza się do zadania mu pewnej liczby pytań. Odpowiedzi na nie stanowią podstawę do stworzenia hierarchicznego modelu działania przedsiębiorstwa, pokazanego na skomplikowanych diagramach przepływu danych i zależności. Często ten etap przygotowania aplikacji staje się skuteczną przeszkodą do jej zakończenia, gdy analityk na podstawie uzyskanych odpowiedzi nie jest w stanie stworzyć poprawnego, kompletnego modelu działania przedsiębiorstwa i przepływu danych. Nie może więc przystąpić do następnych etapów tworzenia aplikacji. Często także utworzone modele na tyle odbiegają od faktycznego sposobu działania firmy, że zrealizowane na ich podstawie programy są odrzucane przez użytkowników.

Użytkownik przede wszystkim

W tym momencie trzeba przypomnieć pewną socjologiczną właściwość działań ludzkich: nie myślimy w kategoriach hierarchii dziedziczenia cech, nawet jeśli w jakiejś chwili ją tworzymy. Dla człowieka nie jest ważne czy ugryzł go owczarek, czy pekińczyk. Powie raczej, że ugryzł go pies. Nie powie także, że ugryzł go czworonożny ssak. Biolog tworzy oczywiście całą taksonomię gatunku "pies", połączy w rodziny, określi pochodzenie poszczególnych ras i dojdzie w górę do ssaków, kręgowców, w końcu do zwierząt. Taksonomia jest to zespół zasad klasyfikacji gatunków zwierzęcych i roślinnych, także sztuka opisywania i tworzenia jednostek systematycznych. Służy do tworzenia hierarchii dziedziczenia i włączania klas. W taksonomii każdy niższy poziom klasyfikacji jest podklasą ("dzieckiem") wyższej klasy ("rodzicielskiej").

Taksonomie są tak rozpowszechnione, że można by sądzić, że jest to jedyny rodzaj hierarchii jaki istnieje. A jest to nieprawda. Bo czy istnieje związek hierarchii dziedziczenia między palcem a całą dłonią. Tu zachodzi raczej zależność między pewną całością a jej częścią. Pies jest specyficznym kręgowcem, ale palec nie jest specyficzną dłonią.

Człowiek operuje i tworzy pojęcia na pewnym środkowym poziomie struktury hierarchicznej przedmiotów, osób czy rzeczy. Tworzy pojęcia i określenia dla tych obiektów, które są mu najbliższe i dotyczą sfery jego bezpośrednich działań. W trakcie działalności praktycznej dochodzi (raczej niechętnie) do wyższych i niższych poziomów klasyfikacji obiektów, z którymi styka się na co dzień.

Podobnie jest w informatyce. Jeżeli rozmawia się z potencjalnym użytkownikiem programów to łatwo zauważyć, że operuje on raczej bliskimi mu pojęciami (faktura, zamówienie, zapis księgowy, dokument), nie interesują go strukturalne zależności między używanymi przez niego danymi ani ich przepływ w przedsiębiorstwie czy sposób obsługi przez inne działy przedsiębiorstwa.

Na tym właśnie bazuje metoda opracowania aplikacji, wykorzystująca prototyp jako podstawowe narzędzie do tworzenia aplikacji. Twórca oprogramowania bazujący na doświadczeniu użytkowników nie pyta ich o zdanie na temat tego, jak aplikacja ma wyglądać: on im pokazuje przez cały czas ich hipotetyczną aplikację, dopracowuje ją w szczegółach, tworzy struktury dopasowane do sposobu działania przedsiębiorstwa. Nie są to jednak koniecznie struktury hierarchiczne. Bazując na poprzednim doświadczeniu, gdy analizuje operacje związane np. z zamówieniami, nie musi za każdym razem schodzić do najniższego poziomu hierarchii realizacji tej funkcji systemu.

Czy narzędzia CASE mają przyszłość?

Wracając do tytułowego pytania, trzeba powiedzieć oczywiście "Tak". Jednakże niekoniecznie w postaci, w jakiej znamy je teraz. Wydaje się, że w świecie informatycznym coraz bardziej utrwala się przekonanie, że tylko dobra i ciągła współpraca z użytkownikiem, dla którego przeznaczona jest aplikacja, może dać wyniki zadowalające obie strony. Programista będzie zadowolony z wykonanej pracy, zaś użytkownik z jego produktu. Wymaga to jednak częstszego stosowania niestandardowych metod. Metodologia nie może być celem samym w sobie. Ma służyć jedynie osiągnięciu celu nadrzędnego - dobrego produktu.

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

TOP 200