Określenie liczebności klas biorących udział w powiązaniach na diagramach klas to jedna z najważniejszych decyzji analitycznych, mająca niebagatelny wpływ na funkcjonalność modelowanego systemu. Zobaczmy więc, jak poprawnie określać liczebności, aby uniknąć przykrych niespodzianek.
Załóżmy, że projektujemy system dla firmy ubezpieczeniowej, która oferuje m. in. obowiązkowe ubezpieczenia odpowiedzialności cywilnej (OC) pojazdów. Nasz system będzie pozwalał na rejestrowanie i obsługę szkód wyrządzonych przez klientów naszej firmy innym uczestnikom ruchu drogowego. Trzeba zatem stworzyć model, zgodnie z którym w systemie rejestrowane i przechowywane będą informacje o szkodach.
Podczas sesji analitycznej dowiadujemy się, że pracownicy zajmujący się likwidacją szkód będą do systemu wprowadzali zgłoszenia szkód. Każde takie zgłoszenie będzie zawierać:
- dane osoby poszkodowanej,
- dane sprawcy,
- dane pojazdów biorących udział w zdarzeniu (w tym pojazdu sprawcy i osoby poszkodowanej).
Model systemu rejestracji szkód obejmujący te informacje jest przedstawiony na rysunku 1. W modelu tym zakładamy, że sprawca jest klientem naszej firmy ubezpieczeniowej, tzn. ma w niej wykupioną polisę OC. Dlatego szkodę przyporządkowaliśmy bezpośrednio do polisy, z której będzie wypłacone odszkodowanie. Natomiast osoba poszkodowana zwykle klientem naszej firmy nie jest. Dlatego zamodelowaliśmy ją w postaci osobnej klasy Poszkodowany. Na tej samej zasadzie odróżniliśmy pojazdy sprawców ubezpieczone w naszej firmie (klasa PojazdUbezpieczony) od pojazdów uczestników zdarzenia (klasa Pojazd).
Rysunek 1. Globalna baza poszkodowanych i pojazdów
Naturalne jest, że jedna osoba ? o ile jest wystarczająco pechowa ? może być poszkodowana w wielu szkodach. Dlatego w naszym modelu przy powiązaniu klas Szkoda i Poszkodowany po stronie klasy Szkoda pojawia się liczebność 0..*. W podobny sposób dopuszczamy, aby jeden pojazd mógł brać udział w wielu szkodach. Efektem tego będzie powstanie globalnej, wspólnej dla wszystkich szkód bazy poszkodowanych oraz globalnej bazy pojazdów uczestniczących w zdarzeniach.
Zastanówmy się, jak będzie działał system zgodny z takim modelem. Otóż pracownik rejestrujący zgłoszenie szkody będzie musiał najpierw sprawdzić, czy poszkodowany był już wcześniej poszkodowanym w jakimś innym zdarzeniu i czy jest już zarejestrowany w systemie. W tym celu wykona zapewne wyszukiwanie w bazie poszkodowanych. Dopiero jeśli nie znajdzie w niej właściwej osoby, wprowadzi jej dane do bazy. Podobnie nasz pracownik postąpi z pojazdami. Taki sposób pracy z systemem byłby bardzo obiecujący, ponieważ pracownicy nie musieliby ponownie wklepywać danych poszkodowanych oraz pojazdów, którzy są juz zapisani w bazie.
Przyjrzyjmy sie jednak, jakie będą konsekwencje stosowania takiego modelu w dłuższym okresie czasu. Wyobraźmy sobie, że pani Janina Kowalska była poszkodowana w wypadku w lipcu 2007 roku. Wówczas w systemie zarejestrowano zgłoszoną przez nią szkodę i wprowadzono jej dane do bazy poszkodowanych. Kilka miesięcy później wyszła za mąż i zmieniła nazwisko ? teraz nazywa się Janina Nowak. Pech chciał, że w grudniu 2009 roku ponownie brała udział w wypadku, którego sprawcą był klient tej samej firmy ubezpieczeniowej. Zgłasza więc kolejną szkodę. Pracownik rejestrujący szkodę wyszukuje jej dane, wprowadzając do wyszukiwarki numer PESEL. Okazuje się, że pani Janina figuruje już w bazie poszkodowanych, lecz pod starym nazwiskiem. Niewiele się zastanawiając, nasz pracownik aktualizuje dane pani Janiny i rejestruje nową szkodę.
Załóżmy teraz, że z jakichś powodów nasza firma ubezpieczeniowa wraca do sprawy wypadku pani Janiny sprzed dwóch i pół roku. I co się wtedy okazuje? Że w systemie zarejestrowano jako poszkodowaną panią Janinę Nowak, mimo że na papierowym formularzu zgłoszeniowym, zeskanowanym i przechowywanym w archiwum, podpisała się jako Janina Kowalska! Podobną sytuację mielibyśmy w przypadku zmiany danych pojazdu uczestniczącego w kilku szkodach.
Jak więc widać, nasz model dopuszcza dokonywanie zmian w danych historycznych przy okazji wprowadzania nowych danych. Wynika to z tego, że obiekty klasy Poszkodowany i Pojazd mogą być współdzielone przez kilka szkód. Sytuacja taka ? jak można się domyślić ? nie jest pożądana, zwłaszcza jeśli weźmiemy pod uwagę, że likwidacją szkód w naszej firmie ubezpieczeniowej zajmuje się kilkaset osób rozsianych po całym kraju. Pracownik obsługujący pierwszą szkodę pani Janiny odpowiada za jakość swojej pracy i nie może brać odpowiedzialności za zmiany danych wprowadzone przez kogo innego dwa i pół roku później.
Okazuje się więc, że globalna baza wszystkich poszkodowanych oraz pojazdów, zaproponowana w modelu z rysunku 1, nie jest dobrym rozwiązaniem. Właściwe byłoby raczej uniemożliwienie współdzielenia tych danych przez wiele szkód. Oznacza to, że dane poszkodowanych oraz ich pojazdów muszą być wprowadzane do systemu przy każdej szkodzie. Koncepcję tą ilustruje model z rysunku 2. Użyliśmy w nim kompozycji, aby zaznaczyć, że dane poszkodowanych i pojazdów przynależą do konkretnych szkód.
Rysunek 2. Dane uczestników zdarzenia i pojazdów przypisane do szkody
Co jednak zrobimy, jeśli ta sama osoba zgłosi się do nas kolejny raz jako poszkodowana? Skoro model zabrania nam przypisać jej dane do kolejnej szkody, to po prostu wprowadzimy jej dane ponownie. Dane będą więc powtórzone, ale dzięki temu każda szkoda będzie miała swój prywatny komplet danych, które nie będą współdzielone z innymi szkodami. Zmiany danych poszkodowanego lub pojazdu, dokonane już po obsłużeniu szkody (np. przy rejestracji kolejnej szkody), nie będą więc odzwierciedlane w danych historycznych dotyczących tej szkody.
Okazuje się więc, że dokładne odzwierciedlanie rzeczywistości biznesowej nie zawsze przynosi dobre rezultaty. Rzeczywistość firmy ubezpieczeniowej jest taka, że jednej osobie może się zdarzyć kilkukrotne uczestnictwo w wypadku. Tą rzeczywistość odzwierciedla model z rysunku 1. Jednak tworząc model, trzeba także uwzględnić uwarunkowania organizacyjne oraz oczekiwania odnośnie funkcjonalności systemu. Może to spowodować zmianę modelu i przyjęcie pewnych ? na pierwszy rzut oka niepoprawnych ? założeń, tak jak w modelu z rysunku 2.
Na koniec zwróćmy uwagę, że powyższe rozważania nie dotyczą sprawców szkód, ich pojazdów oraz polis. Sprawcy są bowiem klientami naszej firmy ubezpieczeniowej. Musi więc ona przechowywać ich pełną bazę, wraz z danymi ich pojazdów i polis. Klient jest w tej bazie przechowywany także wtedy, gdy nie był sprawcą żadnej szkody. Jego dane są w niej aktualizowane, jeśli tylko złoży zgłoszenie zmiany danych. Innymi słowy, baza klientów, pojazdów i polis istnieje niezależnie od systemu obsługi szkód. Nic nie stoi więc na przeszkodzie, abyśmy z niej podczas rejestrowania szkód korzystali.
Szymon Zioło
Artykuł został opublikowany w Software Developer's Journal nr 12/2009.
