ACTA U N IV ER SITA TIS LOD ZIEN SIS
FOLIA OECONOM ICA 167,2003
K onrad W oźniacki* W Y K O R Z Y S T A N I E „ M O D E L U Ś R O D O W I S K O W E G O ” W A N A L IZ IE S Y S T E M Ó W B A N K O W Y C H A r ty k u ł p r z e d s ta w ia o g ó ln e za s a d y b u d o w y m o d e lu ś r o d o w i-sk o w e g o w a n a liz ie sy s te m ó w b a n k o w y c h . Z o s ta ły w n im o p is a n e p o d s ta w o w e za s a d y k o n s tr u k c ji o p is u c e lu system u , d ia g r a m u k o n te k s to w e g o i listy zdarzeń. T h is a r tic le p r e s e n ts g e n e r a l a s p e c ts o f b u ild in g th e m o d e l in b a n k sy s te m a n a ly s is p ro c e s s. T h e re a r e d e s c r ib e d b a sic c o n s tr u c -tio n ru le s o f: sy s te m o b jects, c o n te x t d ia g r a m a n d th e list o f events.
Jednym z trudniejszych etapów pracy nad projektem z dziedziny system ów bankow ych jest określenie arbitralnych granic budow anego rozwiązania. P ierw -szym m odelem , który musi zbudow ać analityk, jest schem at ukazujący um iej-scow ienie tw orzonego oprogram ow ania w docelow ym otoczeniu. U kazuje on jedynie zespół interfejsów między system em a jeg o otoczeniem i jest określany
m ianem m odelu środow iskow ego.
O prócz zidentyfikow ania tego, co znajduje się na zew nątrz system u, a co je st jeg o integralną częścią, wyznaczam y granice pracy. S ą one arbitralne, gdyż m ogą być w ynikiem rozporządzenia kierow nictw a, politycznych negocjacji lub przypadku. Budowany system bankow y powinien być system em racjonalnym , a co za tym idzie produkującym celow e wyniki, będące odpow iedzią na dobrze zdefiniow ane zdarzenia i bodźce pochodzenia środow iskow ego.
NOWOCZESNA ANALIZA STRUKTURALNA
Rys. 1 Składniki modelu środowiskowego. Źródło: opracowanie własne DIAGRAM KONTEKSTÓW ZACHOWANIA DIAGRAM SIECI PRZEJŚĆ DIAGRAM W SŁOWNIKU S^ S Yr i5 jAiCJI DIAGRAM DANYCH PROCESÓW DIAGRAM PRZEPŁYWU DANYCH DIAGRAM ZWIĄZKÓW ENCJI
Zgodnie z przedstaw ionym powyżej rysunkiem , w skład m odelu środow i-skow ego w chodzą: opis celu system u, diagram kontekstow y i lista zdarzeń. Po-niżej przybliżę znaczenie poszczególnych składowych.
Opis celu systemu
Ta składow a m odelu środow iskow ego jest krótkim i zw ięzłym określeniem celu system u, w ykonyw anym w formie tekstowej. Założeniem jej istnienia jest sform ułow anie, w kilku zdaniach, idei tw orzenia program u. Taki opis, który nie powinien przekraczać długości jednego akapitu, adresow any jest do kierow nic-tw a szczebla najw yższego, które nie jest bezpośrednio zaangażow ane w projekt. Nie m a potrzeby budow ania kom pletnego i szczegółow ego opisu system u, gdyż jest to zadaniem pozostałych elem entów m odelu środow iskow ego i wym agań.
Wielu zw olenników now oczesnej analizy strukturalnej postuluje, aby w podsum ow aniu określenia celu zam ieszczać dodatkow o opis wym iernych
korzyści osiągniętych dzięki nowemu rozw iązaniu1. W rzeczyw istości realizacja takiego zadania, w przypadku projektu dużego system u bankow ego, jest zada-niem trudnym . Z uwagi na to, zazw yczaj pojaw ia się w tym m iejscu osobna analiza kosztów i zysków.
D iagram kontekstow y
Pojęcie diagram u kontekstow ego je st ściśle zw iązane z zagadnieniem bu-dow y zrów now ażonych diagram ów bąbli (przepływ u -DFD). W rzeczyw istości jest to specjalny model Data Flow Diagram, reprezentujący cały system jak o pojedynczy proces. Jego zadaniem jest uw ypuklenie interfejsów m iędzy syste-mem a zew nętrznym i term inatoram i.
W przypadku system ów bankowych" pow szechne są sytuacje, gdy z uwagi na sw oje rozm iary pojedynczy diagram transform acji jest nieczytelny dla użyt-kow nika. Co za tym idzie, zasadnym jest wówczas dokonanie podziału diagram u na szereg poziom ów , z których każdy dostarcza większej ilości szczegółów 0 poziom ie nadrzędnym 1. W tak powstałej strukturze hierarchicznej na najw yż-szym poziom ie um ieszczany jest diagram kontekstowy (jeden proces i przepły-wy z term inatoram i i m agazynam i zew nętrznym i), zaś poniżej znajduje się dia-gram oznaczany sym bolem „D iadia-gram 0 ”. Diadia-gram ten przedstaw ia najw yższy 1 zarazem najbardziej syntetyczny sposób widzenia głów nych funkcji i interfej-sów system u.
1 Porównaj Yourdon E., Współczesna analiza strukturalna, WNT, W arszawa 1996, s. 291.
2 •
Z racji wielkiej ilości procesów i magazynów danych aplikacje bankowe są systemami dużymi. 3 Podejście takie można porównać do sposobu organizacji map w atlasie sam ochodowym . Na
pierwszej stronie umieszczamy mapę całego obszaru, aby na kolejnych stronach zamieścić jej rozw inięcia zawierające szczegółowe opisy interesujących nas elementów.
Rys.2 Fragment zrównoważonego DFD wyprowadzonego z diagramu kontek-stowego. Źródło: Yourdon E„ Współczesna analiza strukturalna, WNT, W arszawa 1996.
N owo pow stały diagram niższego poziom u dziedziczy nazw ę procesu, którego uszczegółow ienie stanowi. D odatkow o, zaleca się num erow anie procesów za-w artych na diagram ach za-w form ie hierarchicznej. Procesy będące składnikam i diagram u podrzędnego dla procesu X, będą nosiły nazwy X.1, X.2 do X.n, gdzie n - jest liczbą procesów na diagram ie podrzędnym .
Tak opisany sposób dzielenia dużego diagram u przepływ u danych na diagram y podrzędne w ym aga kilku słów kom entarza. I tak, przy budow aniu zrów now ażo-nego DFD należy zw rócić uw agę na następujące sprawy:
1. Istnieje problem z odgórnym określeniem ilości w yspecyfikow anych po-ziom ów DFD. D obrym naw ykiem jest nieprzekraczanie liczby sześciu pro-cesów na jednym diagram ie, przy jednoczesnym dekom ponow aniu diagra-mu kontekstow ego. Proces ten wykonyw any jest tak długo, póki nie opiszem y pełnej funkcjonalności system u.
2. Z uwagi a fakt, że niektóre części system u m ogą być bardziej złożone od innych, m ogą w ym agać dekom pozycji do większej ilości poziom ów . Tym
sam ym nie możem y z góry założyć, że każdy z procesów zostanie rozpisa-ny np. na trzech poziom ach szczegółow ości4.
3. Dla zapew nienia zgodności poziom ów diagram ów przepływ u danych zale-cam zastosow anie prostej zasady: przepływy danych w chodzące i w ycho-dzące z procesu na danym poziom ie powinny odpow iadać przepływ om da-nych wchodzących i w ychodzących z całego diagram u niższego poziom u opisującego ten proces.
4. C elem popraw nego ukazania m agazynu na kilku poziom ach należy w spo-sób św iadom y w prow adzić pew ną nadm iarow ość do m odelu. W tym celu pokazujem y m agazyn na najwyższym poziom ie, na którym jest używ any jak o interfejs między procesam i. W dalszej części należy pokazyw ać go na każdym diagram ie niższego poziom u, który stanowi szerszy opis procesu wyjściow ego.
5. Nazwy nadaw ane procesom (jak i innym składnikom DFD) pow inny być znaczące. W stosunku do nazwy procesu zasadne jest określanie jej frazą czasow nikow o-dopełnieniow ą, która w prosty i jednoznaczny sposób bę-dzie identyfikow ała czynność, w ykonyw aną przez ten proces (np. oblicz oprocentow anie). W ażne jest popraw ne etykietow anie procesu, um ożliw ia-jące w eryfikację poprawności D FD 5 przez osoby trzecie oraz nadaw anie składnikom nazw z języ k a znanego użytkow nikow i6. Zasadnym jest doko-nyw anie num eracji procesów - najlepiej w sposób hierarchiczny. N um ero-w anie procesóero-w nie je st jednoznaczne z kolejnością ich ero-w ykonyero-w ania. Z a-stosow anie num eracji hierarchicznej pozwoli odw zorow ać pow iązania procesów z poziom ów nadrzędnych, z procesami poziom u bezpośrednio
4 Należy zwrócić uwagę, że jeśli jeden z procesów występujących na Diagramie 0 możemy uznać za elem entarny, zaś drugi z nich wymaga rozpisania na 10 poziomach, to prawdopodobnie nasz ogólny model systemu został źle zorganizowany. W takiej sytuacji powinno się dokonać w y-dzielenia osobnych procesów z procesu nadrzędnego lub przenieść pewne części tego diagramu do procesu uznanego za elementarny.
5 Należy zwrócić uwagę, aby nie używać czasowników zbyt ogólnych, których znaczenie może obejm ować kilka sytuacji. Nazwa „obsłuż dane" nie specyfikuje jednoznacznie, co z tymi dany-mi ma się stać (kasowanie, dodanie, edycja...).
6 Należy wystrzegać się stosowania skrótów i akronimów stosowanych w instytucji klienta. W przypadku budowy systemu bankowego nazwy powinny być zrozum iałe dla pracowników innych banków (kwestia audytu) a nie być określeniami specyficznymi dla danej jednostki (np. WKPiS -W ydział Koordynacji Płatności i Sprawozdawczości, czy dokument M T W /I3-24/G - który okazuje się jakim ś wewnętrznym formularzem stosowanym w jednym z departamentów Banku). Określenia takie bardzo silnie w iążą diagram z aktualnym sposobem działania Banku. W miarę możliwości należy wystrzegać się używania w analizie tego typu określeń, gdyż ja k a -kolwiek zmiana w nazwie wydziału czy numeracji pism wewnętrznych pociągnie za sobą ko-nieczność ingerencji w tworzone opracowanie.
niższego (opisującym i pełniej proces nadrzędny). Przykładow o, proces nad-rzędny opisany num erem „3 -d o d a j klienta banku”, m oże zostać rozpisany na trzy diagram y szczegółow e o num erach:
3.1 dodaj klienta korporacyjnego, 3.2 dodaj osobę fizyczną,
3.3 dodaj podm iot zbiorow y7.
6. Nie należy w zbraniać się przed przerysow yw aniem diagram ów ilekroć jest to uzasadnione przyczynam i estetycznym i. W rzeczyw istości proces ten b ę-dzie trw ał aż do osiągnięcia:
popraw ności technicznej, zadow olenia użytkow nika,
stanu dostatecznego uporządkow ania i czytelności DFD.
7. Należy unikać nadm iernej kom plikacji diagram ów przepływ u danych. C elem diagram u jest m odelow anie funkcji realizow anych przez system wraz z w ystępującym i m iędzy nimi interakcjam i, lecz w sposób m ożliwie czytelny dla użytkow nika. Jest to szczególnie trudne w przypadku diagram u kontekstow ego, który ze względu na sw ą specyfikę zaw iera jeden proces (system ) w raz ze wszystkim i interfejsam i prow adzącym i do zew nętrznych term inatorów .
8. Konieczne jest dołożenie starań m ających na celu zapew nienie niesprzecz- ności w ew nętrznej i zew nętrznej DFD. O statnim zaleceniem jest w eryfika-cja logicznej niesprzeczności DFD, dla której zapew nienia, należy zw racać uwagę na cztery podstaw ow e kw estie w czasie tw orzenia diagram u.
- U nikania tak zw anych „studni” , pod pojęciem których rozum ie się proces posiadający tylko w ejścia (bez jakichkolw iek wyjść), określany w term inologii analitycznej często kategorią czarnej dziury. Powstaje ona w wyniku pom inięcia, lub uznania za mało w ażny, przepływ u da-nych w ychodzącego z procesu.
Jest to zasadne w sytuacji, gdy procesy te będą się różnić. Dla każdego z rodzajów klientów zaistnieje konieczność zasilenia systemu innymi danymi o podmiocie. W ynika to ze specyfiki systemu bankowego - dla osób fizycznych przechowujemy dane scoringowe, zaś dla klienta korporacyjnego dane dotyczące zaangażowania kapitałowego.
M ODU LO
PESEL
Rys.3 Przykład procesu określanego mianem czarnej dziury. Źródło: Opracowanie własne.
- U nikania procesów spontanicznej generacji, będących odw rotnością studni - charakteryzujących się posiadaniem jedynie w yjściow ych przepływ ów danych. Zazwyczaj w obrębie system u nie zdarzają się procesy generujące przepływ y na zasadzie perpetum m obile, a je d y -nym rozsąd-nym przykładem m oże być system ow y generator liczb pseudolosow ych.
- W ystrzeganie się nieopisanych przepływ ów danych i procesów , któ-rych istnienie jest zazwyczaj skutkiem niedbałości. W przypadku po-m inięcia nazwy dla procesu będzie to zbliżenie się do notacji diagrapo-m u przepływ u sterow ania.
- U nikanie istnienia m agazynów służących tylko do zapisu lub tylko do odczytu. Typow y magazyn powinien posiadać zarów no w ejścia jak i wyjścia. W yjątkowym przypadkiem uzasadniającym istnienie m agazynu tylko do zapisu m oże być m agazyn zew nętrzny pełniący rolę interfejsu w stosunku do pew nego zew nętrznego term inatora. Przykładem z dziedziny bankow ości m oże być konieczność tw orzenia spraw ozdań dla GUS o operacjach zagranicznych realizow anych przy w ykorzysta-niu system u SW IFT-ow ego. Dla każdej płatności im portow ej (w ycho-dzącej8) istnieje konieczność raportow ania celu płatności oraz zapisa-nia jej w odpow iedniej bazie (dla celów spraw ozdaw czych GUS).
8 __
W systemie SW IFT płatności wychodzące określane są mianem przekazów importowych, zaś przychodzące -przekazów eksportowych. Ta pozorna odwrotność bierze się z powodu kierunku danej płatności. Dla przekazów eksportowych oczekujemy na zapłatę celem pokrycia faktury a więc na płatność przychodzącą.
R aportow anie to nie w ym aga żadnych odczytów z bazy realizow anych przez bank, a więc dany m agazyn jest m agazynem tylko do zapisu. Lista zdarzeń
Lista zdarzeń jest trzecim i ostatnim elem entem diagram u środow iskow ego. C harakteryzując jej budow ę m ożna pow iedzieć, że stanow i ona tekstow ą listę bodźców w ystępujących w św iecie zew nętrznym . Każdy elem ent tej listy opa-trzony je st jednym z trzech m ożliwych znaczników : (P), (T) lub (S). O znaczają one odpow iednio:
P- przepływ, T- tem porarność S- sterow anie.
Z darzenie sterow ane przepływ em (P), jak sam a nazw a w skazuje, jest po-wiązane z pew nym przepływ em danych. System może stw ierdzić, że zdarzenie m iało miejsce, gdyż pojaw iła się pew na grupa danych, które o tym św iadczą. O dpow iada to oczyw iście przepływ ow i danych na diagram ie kontekstow ym . Nie ma jednak konieczności zachow ania jednoznacznej odpow iedniości m iędzy przepływ am i danych na diagram ie kontekstow ym a zdarzeniam i z listy zdarzeń. W ynika to z faktu, iż tylko część przepływ ów jest zw iązana ze zdarzeniam i. Pozostałe stanow ić będą jed y n ie ”tło” dla w yprodukow ania odpow iedzi przez system.
D rugim z rodzajów znaczników jest litera (T), sym bolizująca zdarzenie tem porarne - w yzw alane w określonym czasie. Przykładem m oże być tu banko-wa sesja ELIX IR, która zachodzi o określonych godzinach. Szczególnym ro-dzajem zdarzenia (T) są zdarzenia sterujące (S). S tanow ią one w danej chwili wew nętrzny bodziec system u będąc niezależnym i od regularnego upływ u czasu. Przepływ pow iązany ze zdarzeniem sterującym jest zazw yczaj przepływ em typu binarnego. Przepływ y tego typu opisałem przy okazji om aw iania procesów i przepływ ów sterujących na diagram ach DFD.
Jak widać, praw idłow a budow a m odelu środow iskow ego w przypadku ana-lizy system u bankow ego jest przedsięw zięciem złożonym i w ym agającym w ie-dzy i dośw iadczenia. Cechy te są o tyle niezbędne, że praw idłow ość w ykonania analizy w znacznej m ierze w pływ a na koszty projektu inform atycznego jak i na sam o jeg o pow odzenie. Budowany w ramach modelu środow iskow ego schemat tw orzonego oprogram ow ania je st w praw dzie jedynie w idokiem na interfejsy między system em a jeg o otoczeniem , lecz popełnione na tym etapie błędy prze-noszone są dalej w „głąb” projektu, ujaw niając się na praw ie każdym etapie cyklu życia system u.
Ź ród ła
1. R. Baker, CASE method. M odelowanie związków encji. W ydawnictwa Naukowo-Techniczne, W arszawa 1996.
2. T. De Marco, Structured analysis and System Specification. Yourdon Press 1978. 3. I. T. Hawryszkiewycz, Introduction to Systems Analysis and Design, Prentice Hall, 1994. 4. J. Roszkowski, Analiza i projektowanie strukturalne W ydawnictwo Helion, Gliwice 1998. 5. E. Yourdon, Współczesna analiza strukturalna, W ydawnictwa Naukowo-Techniczne,
