Łączenie paradygmatów
-
- Jarosław Badurek,
- 08.09.1997
Modelowanie koegzystencyjne
Przede wszystkim sama implementacja konkretnych pakietów software’owych to już zaawansowany krok projektowy. Należy założyć, że poprzedziła go faza analizy systemowej. Ta z kolei z powodzeniem może być realizowana metodami obiektowymi. Jest to zwłaszcza istotne dla firm, których specyfika jest bardziej zorientowana „na dane" niż na modelowanie samej struktury funkcji ich przetwarzania, a to właśnie jest charakterystyczne dla informatyki gospodarczej. Innymi słowy - pierwszoplanowe znaczenie ma tu model danych i związany z nim interfejs użytkownika tj. interpretacja tego modelu (w kategoriach informatycznych).
Czy potrzebna jest tu w ogóle obiektowość? Od lat istnieją przecież stabilne metody analizy strukturalnej, do tego doda się C++, a potem można pokombinować jak to wszystko skleić z dowolną nową bazą danych firmy XYZ. Przecież tam w Kalifornii oni już najlepiej wiedzą, co jest dobre, a w siedzibie XYZ pięć tysięcy zdolnych chłopaków nie robi nic innego, tylko myśli, jakby tu najlepiej te obiekty podejść. Można i tak. Jeśli implementujemy naszą bazę danych po to, żeby dotychczasowe statystyki papierowe zastąpić ich obrazami na ekranie, to zostańmy lepiej na poziomie dobrze poznanych prostych związków przyczynowo-skutkowych typu: użytkownik chce mieć datę w prawym dolnym rogu zamiast w lewym górnym, to się mu ją „przesunie". Wszystko. Jeżeli natomiast celem jest zapewnienie firmie możliwości transformowania danych w prawdziwe informacje, a może nawet w wiedzę to przyjrzyjmy się, czym zajmują się poszczególne fragmenty statystycznej aplikacji w rozważanym obszarze:
Z tego zgrubnego podziału wynika, że zaledwie 1/4 całości to funkcje specyficzne dla danej aplikacji – reszta da się „zakapslować" (encapsulation) i wielokrotnie wykorzystywać, niezależnie w różnych wariantach (reuse) – od tej konstatacji już tylko krok do obiektowości.
Jak wiadomo, w 1846 r. Le Verrier za pomocą kartki pakieru i ołówka odkrył planetę Neptun. Zaiste potężne to narzędzia w połączeniu z ludzkim umysłem. Francuski astronom widział dalej niż jego koledzy wyposażeni w klasyczne teleskopy, bo lepiej od nich liczył. Trochę podobnie jest z analizą systemową. Zwłaszcza w mniejszych przedsiębiorstwach warto najpierw pomyśleć o wymienionym „sprzęcie", zanim zdecydujemy się na zakup drogich pakietów CASE – te okażą się niezwykle pomocne w miarę rozwoju prac i dla większych projektów. I znowu przychodzi czas na paradygmaty. Znaleźliśmy bowiem pożądane obiekty, klasy, metody i atrybuty, czyli to, co jest efektem samej analizy. Co dalej?
Powiedzmy, że nasza baza jest relacyjna. Jeżeli uda nam się teraz dokonać relacyjnej interpretacji wyników analizy obiektowej, to miękko połączymy dwa różne światy! Czas poświęcony na analizę nie jest stracony – gdy w przyszłości zdecydujemy się na zastosowanie obiektowej bazy danych, wówczas poszukiwane przejście będzie miało stosunek 1:1. Jak może wyglądać takie odwzorowanie? To już naprawdę w dużym stopniu zależy od specyfiki naszego projektu. Z pewnością będziemy dążyć do powiązania klas i obiektów z relacjami. Logiczną tego konsekwencją jest przyporządkowanie atrybutów obiektowych atrybutom relacji.
Musimy też przejrzeć możliwości standardów software’owych, którymi dysponujemy. Na przykład z tzw. wizji (view) da się "wycisnąć" elementy dziedziczenia, czyli cechę obiektową. Wizja jest przecież relacją wirtualną,, korzystającą z wcześniej zdefiniowanych schematów bazy danych. Niezależnie od kształtu dróg łączących obie technologie (mapping) widać wyraźnie, że stajemy tu przed wyborem określonej filozofii postępowania – modelowanie koegzystencyjne jest rozwiązaniem ewolucyjnym, gwarantującym większą stabilność w dłuższej perspektywie – gwałtowny krok technologiczny o charakterze rewolucyjnym jest bardziej ryzykowny. Zwróćmy też uwagę, że nie stoi to w sprzeczności z koncepcją deterministycznego chaosu: ideałem są ciągi małych rewolucji kontrolowanych przez nadrzędny proces ewolucyjny.
