Kierunki

Krytyka, która nie wkazuje na pozytywne alternatywy, nie jest konstruktywna. Do jakiego paradygmatu powinniśmy zatem dążyć? Interesującą opcją jest tzw. chaos deterministyczny, czyli modyfikacja systemu za pomocą ciągu kontrolowanych stanów nierównowagi. Brzmi ładnie. Przełóżmy to na konkretne cechy poszukiwanej metody:

A. Wielowariantowość.

Dla każdego implementowanego systemu istnieje wiele rozwiązań i zwłaszcza w początkowych fazach projektu nie powinniśmy arbitralnie przesądzać o wyższości któregoś z nich nad innymi. Pomocne może tu być stosowanie takich metod, jak analiza morfologiczna i zastępowanie podejścia mechanicystycznego, operującego sekwencjami przyczynowo-skutkowymi, podejściem macierzowo-holograficznym, lepiej odpowiadającym dynamice specyfikowanych procesów o charakterze równoległym.

B. Otwartość.

Cecha ta jest przede wszystkim sposobem konstruowania systemu, a nie efektem automatyzmu w stosowaniu określonych typów architektur informatycznych (np. systemy unixopodobne). Jednakże otwartość jest też dążeniem do ideału systemu samouczącego się i zgodą na pewną niedokończoność rozwiązania warunkującą jego elastyczność. W technice takie algorytmy pozostawiają jeszcze wiele do życzenia, natomiast w zakresie metod zarządzania możliwości tworzenia adaptacyjnych organizacji są większe, ich podstawą bowiem nie jest bezduszny procesor, lecz człowiek.

C. Systemowość.

Złożony system informatyczny wymaga równie złożonych metod zarządzania z nim skojarzonych. Metoda taka powinna mieć charakter interdyscyplinarnej syntezy, jednostronne ujęcie czysto analityczne bowiem nie wyjaśnia wystarczająco związków między strukturą systemu a jego stanem. Na przykład dla kompleksowych aplikacji jedynie znajomość parametrów sprzętu komputerowego i oprogramowania na nim wykonującego się nie daje pewności co do czasu działania programu (zjawisko paradoksu złożoności obliczeniowej).

D. Heterogeniczność.

Otaczający nas świat jest tak zróżnicowany, że kusząca wizja użycia metody o jednolitej i „czystej" linii koncepcyjnej (np. konsekwentne stosowanie obiektowości na wszystkich etapach projektowania) ma niewielką szansę realizacji w praktyce. Musimy pogodzić się z koegzystencją COBOL-a i C++ czy modeli relacyjnych i standardów hierarchiczno-sieciowych dla baz danych. Metodzie, która tego stanu rzeczy nie uwzględnia, grozi syndrom „wieży z kości słoniowej".

Szampan i owoce

Oczywiście, zaakceptowanie nowego paradygmatu to także kwestia świadomości. W początkach rozwoju informatyki szacowano, że 100 dużych kompuerów zaspokoi potrzeby obliczeniowe całej ludzkości. Gdyby wówczas ktokolwiek wystąpił z twierdzeniem, iż po paru dziesięcioleciach komputer zmieści się w teczce, a posłużyć się nim będzie mógł przeciętny człowiek, byłby uznany za niekompetentnego fantastę. Zresztą jeszcze w latach 70. poważne prognozy zakładały, że nawet jeśli uda się masowo produkować tanie komputery, to do roku 2000 światowe zapotrzebowanie na nie nie przekroczy miliona sztuk. Do tego czasu bowiem nie będzie można wykształcić więcej wysoko wykwalifikowanych administratorów – inżynierów o specjalności informatyka. Było oczywiste, że tylko taki ekspert jest w stanie obsłużyć skomplikowany "mózg elektronowy".

Nie zapominajmy też o tym, że w życiu „szampanskoje i frukty eto konkrietno: wodka i ogórcy". Jak zatem praktycznie łączyć paradygmaty w ramach technologii informacyjnej? Przyjrzyjmy się temu na przykładzie baz danych i ich otoczenia. Języki programowania są wciąż głównym instrumentem komunikowania się użytkownika z bazą danych. Również w obliczu dynamicznego rozwoju narzędzi wspomagających generowanie aplikacji („graficzne" języki programowania, CASE – Computer Aided Software Engineering) języki programowania są nadal ważne dla metod zarządzania bazą danych. Dotyczy to zarówno języków projektowanych specjalnie dla baz danych (SQL), jak i współpracujących z nimi języków wysokiego poziomu (3GL, 4GL).