O UML 2.0, czyli co nowego w projektowaniu

Część 8: o pewnych, niekoniecznie dobrych założeniach w projektowaniu systemów informatycznych.

Sebastian Wyrwał
sebastian@foxe.pl

W poprzednim odcinku przedstawiono pewne zaczerpnięte z życia przykłady, dotyczące spójności i redundancji danych oraz integracji systemów informatycznych. Tematyka ta będzie kontynuowana w niniejszym odcinku, gdyż życie obfituje w przykłady złego projektowania.

Zdecydowana większość książek, czy wykładów akademickich zawiera przykłady typowo akademickie, starając się pokazać jak modelować automat z napojami lub zapisy na wybieralne kursy na wyższej uczelni. Niestety, prawie nikt nie pokazuje, jak uniknąć wielu błędów, czyli mówiąc kolokwialnie: „jak nie projektować”. Oczywiście, uwagi na poziomie dyskusji akademickich są w praktycznym życiu mniej cenne, niż doświadczenie nabyte w praktyce – nie tylko projektowej, ale również na drodze wnikliwej obserwacji systemów informatycznych, które nas otaczają. Mówiąc krótko: taka krytyka systemów informatycznych. Trzeba pamiętać, że UML to tylko język do wyrażania różnych idei, czy – mówiąc bardziej technicznie – artefaktów projektowych; z drugiej strony może on przyczynić się znacząco do poprawienia jakości specyfikacji i poprawienia komunikacji.

Bardzo istotna jest umiejętność obserwacji, krytycznego myślenia i wreszcie pomysł. Mając pomysł, możemy zastanowić się, jak go poprawnie zapisać tak, aby inni, po obejrzeniu diagramu mieli na myśli to, co my. Ta, czy inna metodyka powie nam, w jakiej kolejności wykonywać pewne zadania, wprowadzi pewien porządek, ale sama na pewno niczego nie wymyśli. Zbyt mechaniczne podejście do projektowania powoduje, że powstające systemy są mało elastyczne i ergonomiczne, sprawiając wiele problemów ich użytkownikom. Projektant, czy analityk to niekoniecznie „smutny” i „nieprzystępny” człowiek w mniej lub bardziej modnym garniturze, ale pewnego rodzaju wizjoner. Należy pamiętać, że sama znajomość gramatyki, literatury etc. nie czyni z nikogo poety. Sama znajomość nut nie czyni z nikogo kompozytora. Warto pamiętać, że w firmach często te, czy inne stanowiska obejmują osoby na drodze pewnego rodzaju awansu. Nic w tym dziwnego, czy złego, ale należy zastanowić się, czy ktoś kto jest dobrym programistą, musi być równie dobrym analitykiem, czy projektantem? W szkołach wyższych często projektować uczą osoby, które w praktyce same nigdy niczego nie zaprojektowały, a ich znajomość zagadnienia – nawet jeśli bardzo gruntowna – ogranicza się do teorii i akademickich przykładów, czy projektów. Jeszcze gorzej gdy projektowania uczą osoby nie mające z informatyką nic wspólnego, np. specjaliści od automatyki, elektrotechniki, metrologii etc.

W pewnych dziedzinach nauki (i wiele wskazuje na to, że w informatyce też) teoria jest bardzo daleko od praktyki. Pewne praktyczne zastosowanie „czegoś”, co jest przedmiotem np. rozprawy doktorskiej, jest często uznawane za wadę; jednocześnie preferowane są „ambitne” prace, które jednak nie mają żadnego zastosowania. Informatyka – zwłaszcza ta na uczelniach technicznych – to nie matematyka. W wielu krajach preferowany jest ścisły związek nauki z przemysłem, a prace mające zastosowanie praktyczne są „premiowane” stypendiami od różnych firm i koncernów. Często jest też tak, że prostota jest u nas uznawana za wadę… Można by pewnie zapytać psychologów, specjalistów od języka, czy kultury, jaki wpływ na mentalność ludzi ma język. Można jednak zauważyć, że w krajach anglojęzycznych zwięzłość i prostota jest doceniania. Kto nie wierzy, niech popatrzy na źródła jakiejś dobrze napisanej biblioteki programistycznej, zwracając uwagę na kod, nazwy, komentarze etc. Z drugiej strony wielu „naukowców” cechuje pewna arogancja intelektualna. Autor widział kiedyś na jakimś forum dyskusję na temat przydatności jakiejś tam publikacji dotyczącej projektowania. Któryś z internautów zgłosił pewną uwagę (chyba związaną z metodyką), i autor owej publikacji przyznał mu częściowo rację. Ów internauta szybko się jednak z tego wycofał stwierdzając, że nie miał uprzednio racji. W dalszej, interesującej do pewnego stopnia polemice było widać pewną przekorę i chęć skrytykowania wszystkiego.

Pod koniec dyskusji rzecz nie dotyczyła już jakiegoś szczegółu, czy zagadnienia, ale tego, że zdaniem owego internauty nie warto nic pisać czy uczyć projektowania… gdyż są to opracowania! A cała wiedza o projektowaniu i metodyce zdaniem tego człowieka, zawarta jest w specyfikacji języka UML, czyli w dokumentach [INF] i [SUP].

Każdy, kto chociaż przejrzał te dokumenty wie, że o metodyce i procesie projektowania nie ma tam mowy. Każdy może oczywiście wyrażać swoje poglądy, ale jak się okazało internauta ten był doktorem habilitowanym lub profesorem, pracującym w bardzo prestiżowej polskiej instytucji naukowej i oczywiście naukowo zajmował się… informatyką. Wiele osób tutaj może się oburzyć, co autor rozumie. Wystarczy jednak spojrzeć krytycznym okiem na wiele – powstałych za bardzo wielkie pieniądze – systemów. Wiele rzeczy jest w nich, mówiąc delikatnie, bez sensu. Przykłady w poprzednim odcinku potwierdzają to zdaniem autora bardzo wyraźnie. Pokazane w tym odcinku przykłady pokażą, że różne problemy mają charakter ogólny i dotyczą również systemów z innych dziedzin.

Na bank przyszedł czas

Banki to kolejny, po firmach telekomunikacyjnych, przykład dużych firm. Złożoność systemów obsługujących bank jest bardzo duża. Zazwyczaj bank „składa” się z wielu, lepiej lub gorzej zintegrowanych systemów informatycznych. Ludzie z branży nie mają wątpliwości, że system informatyczny to kręgosłup każdego banku i bez niego działanie tej instytucji w dzisiejszych czasach nie jest w praktyce w ogóle możliwe. W literaturze wyróżnia się różne podejścia do projektowania systemów bankowych, np. podejście zorientowane na księgowość (praktycznie wszystko w takim systemie jest kontem), podejście zorientowane na produkty, etc. Każde z tych podejść ma swoje wady i zalety. Oczywiście zaprojektowanie systemu bankowego lub choćby jego fragmentu daleko wykracza poza ramy tego cyklu i wymaga głębokiej wiedzy dziedzinowej. Z drugiej jednak strony, warto na sprawę spojrzeć „oczami klienta”, spróbować przeanalizować pewne przykłady i zasygnalizować pewne widoczne błędy. Zdarza się tak, że producenci, wdrożeniowcy lub integratorzy skupiają się na pewnych, jakże istotnych szczegółach, zapominając o sprawach oczywistych. Z drugiej strony, wielu profesjonalistów zaangażowanych w projekty bankowe nie stosuje, nie zna lub zna bardzo pobieżnie jakąś konkretną metodykę lub język projektowania. Często projekty powstają dość chaotycznie, a sam projekt to opis w języku naturalnym, rozumiany różnie przez różne osoby. Często jest też tak, że różne osoby biorące udział w projekcie zupełnie inaczej rozumieją dany opis słowny lub diagram w UML, lub nawet – co gorsza, każdy ma zupełnie inną wiedzę na temat różnych procedur bankowych: np. udzielania kredytów, czy sprawdzania wiarygodności klienta. Jest to bardzo widoczne przy tworzeniu diagramów przypadków użycia, diagramów procesów biznesowych, czy diagramów sekwencji.

Rzeczywiste problemy

Opisane poniżej problemy są jak najbardziej prawdziwe. Nie ma oczywiście znaczenia jaki bank „jest bohaterem”.

  1. Bank, który oferuje dostęp do rachunku (sprawdzanie historii rachunku, dokonywanie przelewów etc.) poprzez bankowość elektroniczną chce rozszerzyć jej funkcjonalność tak, aby klient przy jej pomocy miał możliwość wykonywania operacji na rachunkach posiadanych kart kredytowych, które zostały mu wydane przez ten bank. Rachunek karty kredytowej powinien być widoczny „jako karta kredytowa”. Klient ma mieć możliwość sprawdzania historii operacji kartą i spłaty zadłużenia.
  2. Załóżmy, że klient zakładał rachunek w banku w zamierzchłych czasach, gdy system banku nie obsługiwał jeszcze polskich liter. Na skutek tego, w jego nazwisku zamiast „eł”w systemie bankowym było „el”. W ciągu ponad dekady bank zmienił system, ale nazwiska klienta nikt nie poprawił. (Czemu trudno się dziwić, gdyż raczej trudno byłoby napisać algorytm, który „będzie wiedział”, że np. Laka to Łąka, ale bez polskich liter. Można oczywiście zrobić to w oparciu o sztuczną inteligencje lub słowniki nazwisk, ale nie wydaje się to dobrym pomysłem). Klient ma wiele produktów bankowych, w tym kartę kredytową. Nietrudno zgadnąć, że na karcie nazwisko klienta widniało bez polskich liter. W końcu po wielu latach, przy okazji wypłaty środków w kasie, pracownica banku poprawiła w systemie bankowym nazwisko klienta na zgodne z tym w dowodzie osobistym, czyli z polską literą. Po zmianie nazwiska bank zaoferował klientowi podwyższenie limitu na karcie kredytowej, co miało być dokonane po podpisaniu nowej umowy do (tej samej) karty kredytowej. Umowa została wygenerowana w oddziale, a w systemie oddziału nazwisko klienta było już poprawione. W jednostce obsługującej karty kredytowe i jej systemie (jak się okazało przy rozmowie z infolinią) dalej funkcjonowało stare nazwisko tj. bez polskich liter. Widać więc, że zmiana danych osobowych w systemie oddziału banku (widoczna nawet w bankowości elektronicznej) nie została rozpropagowana do systemu obsługującego karty kredytowe.
  3. Ten sam klient nie widzi swojej karty kredytowej w systemie bankowości elektronicznej. Według informacji banku… przez rozbieżność nazwisk.
  4. Klient postanowił inwestować co miesiąc pewną drobną kwotę w fundusze inwestycyjne. W oddziale banku założył rejestr i kupił pierwszą jednostkę uczestnictwa. Pracownica banku zapewniała go, iż do funduszy będzie miał dostęp poprzez bankowość elektroniczną, która oczywiście ma taką funkcjonalność. W praktyce okazuje się, że jeśli rejestr został założony w oddziale, to przez bankowość elektroniczną nie ma dostępu do funduszu.

Inżynieria wymagań się kłania

Trudno wyrokować, czy systemy tego lub innego banku są źle, czy dobrze zaprojektowane. Ani, czy owe projekty mogłyby być lepsze. Być może opisane problemy mają swoje źródło w niedoskonałej konfiguracji, parametryzacji, czy integracji. Być może mają one przynajmniej częściowo swe źródło w nieusuniętych błędach… Wydaje się jednak, iż pierwotnym źródłem błędów są… niewłaściwie opracowane specyfikacje wymagań. Jest to prawdziwe nawet wtedy, gdy problemy te są wynikiem niewykrytych błędów. Może tu zachodzić prosta zależność:

źle sformułowane wymagania -> źle dobrane dane testowe.

Znając życie można dojść do wniosku, iż część wymagań w dużych systemach jest określana niejawnie, czyli kolejne osoby zaangażowane w projekt muszą się czegoś tam domyślać. Jeden domyśla się tego, drugi czegoś innego. Jedna osoba dany diagram PU czyta tak, a druga inaczej. Często firmy realizujące duże projekty tworzą bardziej sformalizowany projekt i diagramy w UML, „bo klient wymaga”. Często są dwie dokumentacje projektu – jedna „wewnętrzna” słowna i chaotyczna a druga „czysta” i tworzona zgodnie z wymaganiami dla klienta. Często ta druga dokumentacja jest mocno „po wykonawcza” i – co tu dużo mówić – zdarza się, że jest po prostu fikcją. Opisane przed chwilą praktyki są opisane nie tylko na przykładzie systemów bankowych, ale na podstawie tego, co naprawdę dzieje się w różnych firmach z różnych branż.

Truizmy? Niby tak. Ale to często rzeczywistość projektowania oprogramowania w Polsce. Oczywiście, trudno na podstawie pewnego zbioru firm wypowiadać się na temat innych. Ale w bardzo wielu firmach sytuacja jest podobna. UML jest traktowany jako zło konieczne. Czasem, jako coś na co nie wiadomo czemu „uparli” się przełożeni bądź klient. Oczywiście, nikt poza osobami zaangażowanymi w projekt, wytworzenie i rozwój bankowości elektronicznej w pewnym banku, o którym była mowa nie wie, czy w stosownym dokumencie pojawiło się zdanie:

Każdy klient korzystający z bankowości elektronicznej i mający kartę kredytową wydaną przez nasz bank powinien mieć dostęp do tej karty przy pomocy bankowości elektronicznej. Dostęp do karty kredytowej to: możliwość przeglądania historii operacji kartą, możliwość oglądania zestawień miesięcznych i dokonywania spłat.

Można również zadać sobie pytanie, w jakiej formie owo zdanie pojawiało się i jak sprawdzono, czy wymaganie to zostało zrealizowane… Wymaganie jest przynajmniej w założeniu bardzo proste i bardzo jednoznaczne. Niby takie proste, ale jednak system go nie spełnia w zadowalającym stopniu. Ktoś mógłby powiedzieć, że do realizacji dostępu do karty potrzebna jest poprawna integracja systemu bankowości elektronicznej i systemu obsługi kart kredytowych (dotąd zgadzamy się), a owa integracja wymaga, aby w obu systemach zgadzały się imię i nazwisko klienta (tego nie wiemy). Nawet jeśli tak jest, po złożeniu reklamacji klient powinien dostęp ten uzyskać, gdyż poprawa nazwiska w systemie obsługi kart to żaden problem. Dla nas znacznie ciekawsze jest jednak, dlaczego – po pierwsze, integracja systemów wymaga zgodności nazwisk i imion w obu systemach (z pozoru wydaje się to oczywistym wymaganiem, ale jak pokazuje życie wcale tak nie jest; zmiana nazwiska nie jest niczym wyjątkowym). Zestaw „nazwisko-imię” wcale nie jest unikalny, wielu przecież jest Janów Nowaków. Z drugiej strony, jeszcze ciekawsze jest zagadnienie, dlaczego zmiana dokonana przez pracownika banku nie propaguje się do wszystkich systemów tegoż banku. Klient jest przekonany, że skoro pracownik poprawił jego dane, to poprawił i basta, są one poprawione. Okazuje się jednak, że nie. Czy to klient ma mówić pracownikowi: proszę nie zapomnieć poprawić moich danych i tu i tu?

Imię i nazwisko

Imię i nazwisko jest dla każdego z nas czymś ważnym. W życiu dane te są czymś bardzo istotnym – podaje się je załatwiając jakąkolwiek sprawę, czy pisząc jakiekolwiek pismo. Podaje się je w umowach i wyrokach sądowych, słowem wszędzie. Wydaje się jednak, że w systemie informatycznym, „imię i nazwisko”1 nie jest niczym szczególnym, a jedyna „wyjątkowość” tej danej to taka, że jest to dana osobowa i trzeba ją chronić. Przecenianie wagi imienia i nazwiska wynika raczej z doświadczeń nabytych w życiu i pewnych przekonań na ten temat, jakie w każdym z nas się ukształtowały. Integracja systemów informatycznych z wykorzystaniem imienia i nazwiska wydaje się być przykładem „przeprojektowania”. Z imieniem i nazwiskiem wiążą się następujące problemy:

  • rozbieżności w pisowni,
  • zestaw „imię i nazwisko” nie jest w ogóle unikalny,
  • możliwość zmiany,
  • możliwość występowania wielu imion i nazwisk: Jan Jerzy Iksiński Nowak,
  • problemy z utrzymaniem spójności, gdy dane te zostaną zmienione w jednym systemie, a w innym nie.

Oczywiście autor nie ma na myśli tego, że imię i nazwisko nie powinno występować na karcie kredytowej, ponieważ występować musi. Są to jednak dane, które w ogólności mogą wymagać pewnej interpretacji. W dowodzie osobistym może bowiem występować Jan Jerzy Nowak, a na karcie Jan Nowak. Inna rzecz, że rozstrzygnięcie przez człowieka (np. sprzedawcy) faktu o tym, że to ta sama osoba może być mylne. Jan Nowak na karcie i Jan Nowak w dowodzie mogą być dwoma różnymi osobami, podczas gdy Janina Nowak i Janina Nowak – Kowalska to może być ta sama osoba, która dwa dni temu wyszła za mąż.

Dlatego z pewnością wymyślono numer PESEL, który przynajmniej w teorii ma być dla każdej osoby unikalny. Dlaczego przepisy nie wymagają umieszczenia go na karcie kredytowej, nie wiadomo. Poza tym, w systemie bankowym istnieje zapewne jakiś identyfikator klienta, który musi być unikalny. Ktoś może się pokusić, aby klienta identyfikować poprzez trójkę danych (imię, nazwisko, PESEL). W PESEL-ach są podobno błędy, ale intuicyjnie wiadomo, że im więcej danych, tym mniejsza możliwość błędu. Trójka taka jest jednak również złym wyborem, zaś dodanie PESEL-u pozwala wyeliminować jedynie to, że zestaw (imię, nazwisko) nie jest unikalny. Pozostałe problemy o których wspomnieliśmy, są nadal aktualne. Wydaje się, że dużo lepszym pomysłem jest integracja w oparciu o numer klienta z użyciem numeru PESEL do kontroli.

Integracja systemów po raz kolejny

Janina Nowak, która przychodzi do banku w celu uaktualnienia danych osobowych (np. nazwiska), chce z pewnością załatwić sprawę szybko i sprawnie. Nie powinno ją obchodzić, że bank ma kilka systemów, które integrują się tak sobie. Poza tym, jeśli przedstawi odpowiednie dokumenty i pracownik zmieni dane w systemie, powinna mieć świadomość tego, co zostało załatwione, a co nie. Niedopuszczalna jest sytuacja, w której klientka jest przekonana, że dane zostały „w banku” zmienione, a tymczasem prawda jest taka, że zostały zmienione w jednym systemie, a w innym nie. Zakładając, że w przebiegu projektu przypadki użycia są używane, to przyczyną tego typu problemów może być nieodróżnianie przypadków użycia biznesowych i systemowych. To, że klient przychodzi do banku i chce zmienić nazwisko, to jedno (biznesowy PU); zaś fakt, że pracownik banku musi „wejść” do trzech systemów, by to zrealizować (bo nie są one zintegrowane), to zupełnie co innego (trzy systemowe PU w trzech systemach). Dla klienta bank to całość, a dla pracownika to różne systemy, aplikacje, procedury postępowania, przepisy i procesy biznesowe. Oczywiście dobrze by było, gdyby aplikacja pracownika współpracowała z różnymi systemami i aby sama „dbała” o to, że zmiana ma być dokonana we wszystkich systemach, ale chyba jest to raczej pobożne życzenie.

Z przedstawionych przykładów widać, iż rozróżnienie biznesowych PU od systemowych jest bardzo istotne – zwłaszcza w dużych organizacjach, gdzie biznesowemu PU odpowiada więcej niż jeden systemowy PU. Błędy na tym poziomie mogą mieć całkiem poważne następstwa. Na poziomie organizacji współpracę różnych systemów, czy realizację biznesowego PU dobrze jest pokazać przy pomocy komunikatów – np. na diagramie sekwencji. Celowe może być też pokazanie realizacji biznesowego PU przy pomocy kolaboracji (współdziałania) gdzie realizatorami są różne systemy. Pamiętać należy również o tym, że jeśli pracownik w ramach realizacji danego biznesowego przypadku użycia musi „ręcznie” wykonać tę samą rzecz w kilku systemach, to jest bardzo prawdopodobne, że o którymś tam systemie zapomni…

Możliwa przyczyna Rozwiązanie Uwagi
Zła specyfikacja wymagań Poprawić specyfikację wymagań; kolejna integracja Jeśli zła specyfikacja wymagań PU uaktualniania danych osobowych, to można też zmienić sposób integracji
Zły projekt Poprawić projekt; implementacja; testowanie
Zła implementacja Poprawić błąd w kodzie; testować
Złe założenia integracji Poprawić sposób integracji
Złe dane testowe Tak dobierać dane testowe, aby dobrze sprawdzić integrację systemów w różnych nietypowych sytuacjach. Nie powodują błędu, ale to że nie zostało wykryte błędne wykonanie, które on powoduje

Wreszcie diagramy UML

Cykl ten traktuje o języku UML, więc trudno byłoby rozważań nie odnieść do tego właśnie języka.

Pamiętając, że UML jest jedynie sposobem zapisu diagramów projektowych, można wskazać te diagramy i konstrukcje języka, które mogą być pomocne w unikaniu tych błędów, o których była wcześniej mowa.

  1. Modelowanie biznesu (dziedziny).
  2. Modelowanie procesów biznesowych (czyli zachodzących w biznesie) przy pomocy diagramów aktywności.
  3. Modelowanie biznesowych przypadków użycia (stereotypowane PU).
  4. Pokazanie systemów i ich „granic” – np. z użyciem diagramów rozmieszczenia. Wstępne modelowanie współpracy systemów z ukazaniem ich integracji. Pokazanie wymiany komunikatów pomiędzy systemami. Można zamodelować system jako klasę i używając diagramów sekwencji pokazać wymianę komunikatów.
  5. Modelowanie systemowych przypadków użycia.
  6. Modelowanie zależności pomiędzy biznesowymi i systemowymi PU.
  7. Modelowanie przypadków testowych przy pomocy stereotypowanych przypadków użycia.

Pokazane przykłady mogą świadczyć o tym, że czasem najbardziej oczywiste i ogólne rzeczy są najtrudniejsze. Stwierdzenie takie jest trywialne, ale… często skupienie się na różnych szczegółach projektowanego rozwiązania (często technicznych) sprawia, że z oczu traci się całość lub ogólną ideę rozwiązania. UML może tutaj wydatnie pomóc, gdyż można tworzyć modele na różnych poziomach abstrakcji i szczegółowości.

C.D.N.

Literatura

  • [PMIO2003] Śledzenie propagacji zależności w projekcie obiektowym [w:] Problemy i metody inżynierii oprogramowania, WNT 2003
  • [INF] Unified Modeling Language: Infrastructure version 2.0. www.omg.org, Marzec 2006
  • [SUP] Unified Modeling Language: Superstructure version 2.0. www.omg.org, Sierpień 2005

1 Na tym poziomie rozważań traktujemy imię i nazwisko łącznie.