5792343642

7

CS>

czasu poświęcono nad taką konstrukcją oprogramowania, by wspomniany warunek spełniało. Na pytanie, dlaczego nie zastosowano technologii token ring, padła odpowiedź, że nie używano jej wcześniej w projektach, a było mało czasu (o ile dobrze pamiętam, to zespół miał kilka miesięcy).

Innym czynnikiem decydującym o wyborze DBMS (systemu zarządzającego bazą danych) jest oprogramowanie, które posiada klient. O ile czynnik ten ma marginalne znaczenie w przypadku, gdy usługi będą realizowane na dedykowanym serwerze, to jest już bardzo istotny w sytuacji, gdy przeznaczeniem produktu (gotowej aplikacji) jest sprzedaż dla indywidualnego klienta. Przykład mogą stanowić programy księgowe.

Architekturę możemy rozpatrywać w dwóch płaszczyznach:

1)    podział aplikacji na modułu realizujące określone usługi,

2)    podział aplikacji na warstwy ze względu na sposób przetwarzania danych.

Pierwszy z tych podziałów jest ściśle związany z rzeczywistością, którą ma opisywać projekt. Jeśli decydujemy się na modułową realizację programu, to bardzo istotne jest ustalenie, czy i w jaki sposób realizowana będzie wymiana informacji pomiędzy modułami. Często stosowaną techniką jest export/import danych do pliku, ale nawet w tym przypadku pojawiają się pytania, np. czy inicjowany i wykonywany przez użytkownika,, czy też przez wyzwalacz, czy jego realizacja pociąga za sobą zmiany w bazie danych (np. rejestracja operacji w odpowiednim miejscu i/lub blokowanie rekordów).

Innym problemem są wymogi prawne. Zachęcam do obejrzenia witryny wwwjanosik.net (dotyczy problemów z konstrukcją alternatywnego programu - w miejsce PŁATNIKA, do transmisji danych do ZUS).

Najczęściej stosowana architektura to dwu lub trój warstwowa.

Pierwsze rozwiązanie jest zapewne znane. Mamy wówczas warstwę danych oraz warstwę aplikacji, która stanowi interfejs pomiędzy użytkownikiem i bazą danych. Drugie rozwiązanie, omówione np. w [3], pokazuje rysunek obok.

WARSTWA PREZENTACJI.