140 20 13MB
Polish Pages [208] Year 2010
KRZYSZTOF SACHA ;íl ¡m
íí
INŻYNIERIA OPROGRAMOWANIA
W Y D A W N IC TW O NA U KO W E PWN W A R S ZA W A 2010
Projekt oldadki: Michał Rosiński Redakcja: Ewa Zdanowicz Skład komputerowy: K rzysztof Świstak
Spis treści Recenzenci: dr liab. inż. Tadeusz Nowicki \
prof. dr hab. inż. Janusz Sosnowski
P rzed m ow a .....................................................................................................................................................7 Copyright (O by W ydawnictwo Naukowe PWN SA W arszawa 2 0 10
Część I. Procesy i m etod y........................................................................................................................I i 1.
W szystkie prawa zastrzeżone. Reprodukcja bez zezwolenia zabroniona.
W p row adzenie..................................................................................................................................13 1.1. 1.2. 1.3.
ISBN: 978-83-01-16179-8 1.4. 1.5. W ydaw nictwo N aukowe PWN SA 02-676 W arszawa, ul. Postępu 18 tel. (0 22) 69 54 321 faks (0 22) 69 54 031
1.6. 2.
e -m a il: p w n @ p w n .c o m .p l w w w .p w n .p l
Inżynieria w ym agań ........................................................................................................................ 50 2.1.
t W ydanie pierwsze Arkuszy drukarskich 26,5 Druk ukończono w styczniu 2010 r. Druk i oprawa: D rukarnia W ydawnictw Naukowych Sp. z o.o. 92-333 Łódź, ul. W ydawnicza 1/3
Proces rozw oju systemu inform atycznego...................................................................... 15 O kreślenie w ym agań.................................................................... 19 W ytwarzanie oprogram ow ania............................ '............................................................ 21 1.3.1. Procesy......................................................................................................................23 1.3.2. M etody......................................................................................................................30 W eryfikacja 1 zatw ierdzanie................................................................................................. 33 Inżynieria oprogram ow ania................................................................................................. 37 1.5.1. Raport C h a o s .......................................................................................................... 38 1.5.2. Polski rynek I T .......................................................................................................40 Historia i kierunki ro zw o ju................................................................................................. 43
2.2.
|
2.3.
2.4. 2.5. 2.6.
Klasyfikacja w ym agań.......................................................................................................... 51 2.1.1. Zakres w ym agań.................................................................................................... 5 1 2.1.2. Poziomy opisu w ym agań......................................................................................54 Proces określania w ym agań................................................................................................. 57 2.2.1. Analiza SWOT............................ 58 2.2.2. Studium w ykonalności.......................................................................................... 62 2.2.3. Przygotowanie w ykonania projektu................................................................... 64 Pozyskiwanie i dokum entowanie w y m agań .......................................................... 66 2 .3 .1. M etody pozyskiwania w y m ag ań ........................................................................67 2.3.2. Specyfikacja w y m agań......................................................................................... 68 Prototypow anie (prototyping) ..............................................................................................71 Zarządzanie w ym aganiam i.................................................................................................. 74 Uwagi bibliograficzne............................................................................................................76
S p is treści
4
Spis treści
5
4—---------3.
M etody s t r u k tu r a ln e ........................................................................................................................ 79 3.1.
3.2.
3.3.
3.4.
3.5. 4.
Narzędzia m odelow ania........................................................................................................80 3.1.1. H ierarchia fu n k cji...................................................................................................80 3 .1.2. Diagram przepływu d an y ch ..................................................................................82 3.1.3. Diagram encji...........................................................................................................85 3.1.4. Schem at stru k tu ry ...................................................................................................87 Techniki analizy strategicznej.............................................................................................89 3.2.1. M odelowanie przetw arzania................................................................................ 90 3.2.2. M odelowanie dan y ch .............................................................................................93 3.2.3. Schem at kon tek stu ................................................................................................. 96 Techniki analizy strukturalnej.............................................................................................98 3 .3 .1. Budowa modelu fizy czn eg o ................................................................................ 99 3.3.2. Budowa modelu lo g iczn eg o ...............................................................................103 3.3.3. M odelow anie danych ........................................................................................... 106 3.3.4. Budow a now ego modelu fizycznego.................... 108 Techniki projektow ania aplikacji............................................'i...................................... 110 3.4..J . Projektow anie struktury programu ............................................................111 3.4.2. Projektow anie bazy d a n y c h ................................................................................1 14 3.4.3. Projektow anie interfejsu użytkow nika............................................................117 3.4.4. Technologie w spom agające................................................................................I 19 Uwagi bibliograficzne..........................................................................................................120
M etody o b iek to w e............................................................................................................................ 123 4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.
N arzędzia m odelow ania...................................................................................................... 124 4.1.1. M odel przypadków użycia.................................................................................. 126 4 . 1.2. Diagram k la s .......................................................................................................... 132 M odelowanie procesów bizn eso w y ch ............................................................................. 140 4.2.1. Narzędzia m odelow ania.......................................................................................141 4.2.2. Budowa m o d elu.....................................................................................................144 M odelowanie wymagań uży tk o w n ik a ;... 150 4.3.1. Budowa modelu b iznesow ego............................................................................153 4.3.2. Budowa modelu sy stem ow ego...........................................................................155 4.3.3. Reguły biznesow e.......................................... 160 M odelowanie dzied zin y ...................................................!................................................. 161 4.4.1. Narzędzia m odelow ania................................................................................y.. 161 4.4.2. M odelowanie struktury ........................................................................................ 165 4.4.3. M odelowanie zachow ania.................................|................................................ 168 Projektow anie oprogram ow ania........................................ {.............................................170 4 .5 .1. N arzędzia m odelowania stru k tu ry ................... $...........................................171 4.5.2. N arzędzia m odelowania w spółdziałania |.....................i........................ 175 4.5.3. Projektowanie architektury oprogram ow ania.’.............................................. 178 4.5.4. Projektowanie program ów ...................................................................................183 Technologie obiektow e........................................................................................................195 4.6.1. A rchitektura w arstw ow a......................................................................................196 4.6.2. Projektow anie architektury oprogram ow ania.................................................198 4.6.3. Projektowanie program ów ..................................................................................203 Proces R U P ............................................................................................................................209
4.8. 5.
4.7.1. Faza rozpoczęcia...................................................................................................211 4.7.2. Faza opracowań i a ................................................................................................ 213 4.7.3. Faza konstrukcji....................................................................................................215 4.7.4. Faza przekazania...................................................................................................216 Uwagi bibliograficzne......................................................................................................... 217
T esto w anie o p ro g ra m o w a n ia .....................................................................................................220 5.1. 5.2.
5.3.
5.4.
5.5. 5.6.
Poziom y testow ania............................................................................................................ 221 Organizacja procesu testow ania........................................................................................226 5.2.1. Planowanie testó w ...............................................................................................226 5.2.2. Przygotowanie testów ..........................................................................................228 5.2.3. Testow anie a usuw anie defek tó w ................................................................... 23 f M etryki................................................................................................................................... 232 5.3.1. M etryki pokrycia kodu........................................................................................ 233 5.3.2. Metryki pokrycia w ym agań............................................................................... 236 5.3.3. Inne m etryki........................................................................................................... 237 M etody testow ania...............................................................................................................240 5.4.1. Testow anie czarnej skrzynki............................................................................. 241 5.4.2. Testow anie białej sk rzy n k i................................................................................244 A utom atyzacja testow ania................................................................................................. 246 Uwagi bibliograficzne......................................................................................................... 251
C zęść II. Z a rz ą d z a n ie p ro je k ta m i......................................................................................................253 6.
Z a rz ą d z a n ie p ro je k te m in fo rm aty czn y m ................................................................................255 6 . 1.
6.2.
6.3.
6.4.
6.5. 6.6. 6.7. 7.
Struktura organizacyjna projektu...................................................................................... 256 6.1.1. Schem at struktury organizacyjnej..................................................................... 256 6 .1.2. Projekty zam aw iane............................................................................................. 259 Planowanie projektu.............................................................................................................261 6 .2 .1. Określenie podziału p ra c y .................................................................................. 262 6.2.2. Tw orzenie harm onogram u.................................................................................. 267 6.2.3. Plan projektu.......................................................................................................... 272 Planowanie kosztów ............................................................................................................. 274 6.3.1. Heurystyczne metody szacow ania.....................................................................275 6.3.2. Analityczne metody szacow ania........................................................................ 277 6.3.3. Tw orzenie budżetu................................................................................................287 Zarządzanie, przebiegiem projektu......................................................................................288 6 .4 .1. K ontrola postępów ......................................................................................289 6.4.2. Działania k o rekcyjne........................................................................................... 290 Zarządzanie ryzykiem ..........................................................................................................294 M etoda PR 1N C E2.................................................................................................................298 Uwagi bibliograficzne........................................................................................................ 302
Z a rz ą d z a n ie jak o ścią...................................................................................................................... 305 7.1.
.1akość oprogram ow ania (ISO 91 2 6 )............................................................................... 306 7.1.1. Model jak o ści......................................................................................................... 307 7.1.2. M etryki jak o ści......................................................................................................309
Spis treści
6
7.2.
7.3.
7.4. 7.5. 8.
M eto d y k a z w in n a ...........................................................................................................................334 8.1. 8.2.
8.3.
8.4. 8.5. 9.
System zarządzania jak o ścią ........................................................................................... 312 7.2.1. Kom pleksowe zarządzanie jakością (T Q M )................................................ 313 7.2.2. N orm a ISO 9 0 0 1 .................'...................... !....................................................... 314 7.2.3. M odel CM M 1......................................................................................................318 M etody zapew nienia ja k o śc i............................................................................. 319 7.3.1. S tan d ard y .............................................................................................................320 7.3.2. Przeglądy i in sp ek cje....................................................... .'.................................323 7.3.3. Projektowanie m etryk jakości (G Q M )............................................................325 Plan zapew nienia ja k o ś c i................................................................................................. 330 Uwagi bibliograficzne....................................................................................................... 332
Planowanie w y d a n ia......................................................................................................... 335 Iteracja p ro jek tu .*...................................................................................................... 338 339 8.2.1. Planow anie iteracji................................................. 8.2.2. W ykonanie iteracji............................................................................................341 Z asad y ....................................................................* ............................................................. 343 8.3.1. Reguły tworzenia k o d u ..................................................................................... 343 8.3.2. M etody p ra c y ...................................................................................................... 345 8.3.3. M anifest zw inności............................................................................................ 346 Praktyki z w in n e ...................................................................................................................347 Uwagi k o ń co w e ...................................................................................................................348
K o n serw acja o p ro g ra m o w a n ia .................................................................................................. 350 9.1. 9.2.
9.3. 9.4.
9.5.
Struktura k o n serw acji....................................................................................................... 351 Proces konserw acji............................................................................................................. 353 9.2.1. Procedura kontroli zm ian.................................................................................. 354 9.2.2. Norm a IEEE 1219...............................................................................................355 Inżynieria o d w ro tn a ........................................................................................................... 357 Systemy odziedziczone...................................................................................................... 360 9.4.1. O pakow anie.........................................................................................................362 9.4.2. Korporacyjna szyna usług................................................................................. 363 Uwagi bibliograficzne....................................................................................................... 364
10. System y k ry ty c z n e .......................................................................................................................... 366 10.1. 10.2. 10.3.
10.4. 10.5.
W ym agania..........................................................................................................................367 A naliza bezpieczeństw a....................................................r............................................... 371 Projektow anie stru k tu raln e............................................ j .................................................376 376 10.3.1. Proces projektow y............................................... 10.3.2. Budow a modelu funkcjonalnego.................... | .............................................. 378 10.3.3. Budowa modelu im plem entacyjnego ............. ■,.............................................. 382 Autom atyczna generacja program ów ............................................................................. 387 Uwagi bibliograficzne........................................................................................................393
B ib lio g ra fia ............................................................................................................ - ..................................394 In d e k s ...........................................................................................................................................................410
P rzedm ow a \
Nauka stara się opisać i wyjaśnić świat. Inżynieria stara się rozwiązać praktyczne problemy, które na świecie występują. Inżynieria oprogramowania stara się budować i utrzymywać systemy oprogramowania służące rozwiązywaniu tych problemów. Celem działania jest znajdowanie dobrych rozwiązań o akceptowalnym koszcie wdro żenia i utrzymania. Z upływem lat oprogramowanie rozpowszechnia się coraz bardziej w takich ob szarach ży d a, w których złe działanie systemu może stać się źródłem poważnych strat i zakłóceń w funkcjonowaniu społeczeństwa. Przykładami takich zastosowań są systemy zarządzające działaniem przedsiębiorstw i korporacji, systemy wspomagające działanie administracji publicznej i instytucji zabezpieczenia socjalnego, a także syste my sterujące różnymi instalacjami technicznymi. Jakość usług oferowanych społe czeństwu w tycli dziedzinach zależy od jakości oprogramowania wspomagającego działanie odpowiednich przedsiębiorstw i organizacji. Inżynieria oprogramowania dysponuje zbiorem metod, technik i technologii, któ re umożliwiają projektowanie rozwiązań spełniających stawiane im wymagania. Zbiór tych narzędzi, dostępnych dla projektantów i wykonawców oprogramowania, rozwija się i zmienia z upływem czasu, a wybór najlepszych narzędzi może być w różnych projektach różny. Celem tej książki jest przedstawienie bieżącego stanu inżynierii oprogramowania i pokazanie najlepszych praktyk, które udowodniły swą wartość w wielu już wykona nych projektach. Książka jest monografią obejmującą całość dziedziny inżynierii oprogramowania, od określenia wymagań dla tworzonego produktu, poprzez modelo wanie, projektowanie i wytwarzanie oprogramowania, aż po konserwację golowego produktu. Książka jest przeznaczona dla szerokiego kręgu odbiorców związanych z prze mysłem informatycznym oraz studentów wszystkich typów szkół wyższych kształcących
P rzedm ow a
8
w kierunku Informatyka. Praktycy inżynierii oprogramowania mogą ją potraktować jako kompendium porządkujące ich wiedzę lub użyć jako uzupełniające źródło infor macji o wybranych zagadnieniach. Dla studentów książka jest podręcznikiem, który w pełni pokrywa wymagania określone w standardach kształcenia dla tego kierunku. Treść książki jest podzielona na dwie części. Część pierwsza (obejmująca roz działy 1-5) przedstawia procesy i metody używane podczas tworzenia oprogramowa nia, w tym przede wszystkim sposoby rozpoznawania i definiowania wymagań, meto dy modelowania i projektowania rozwiązania (strukturalne i obiektowe) oraz sposoby testowania wytworzonego produktu. Unikalną cechą tej części książki, nieczęsto spotykaną w literaturze, jest powiązanie działań modelowania oprogramowania na różnych poziomach abstrakcji z technologiami implementacyjnymi i doprowadzenie opisu aż do poziomu kodu programu. Część druga (obejmująca rozdziały 6-10) przed stawia metody zarządzania projektem informatycznym, którego celem jest zbudowa nie nowego lub utrzymanie już istniejącego oprogramowania. W tej części książki są opisane tradycyjne metody planowania i zarządzania przebiegiem projektu oraz zarzą dzania jakością, nowe techniki zarządzania projektem zwinnym oraz specyficzne problemy występujące podczas konserwacji oprogramowania. Ostatni rozdział książki, nie w pełni mieszczący się w tej klasyfikacji, jest poświęcony systemom krytycznym, od których może zależeć bezpieczeństwo ludzi. Układ treści w kolejnych rozdziałach przedstawia się następująco. Rozdział 1 wprowadz.it Czytelnika w problemy tworzenia oprogramowania. W y jaśnia działania, jakie należy podjąć w celu stworzenia systemu informatycznego i jego oprogramowania, oraz szkicuje procesy wytwórcze i stosowane w ich ramach metody projektowania, weryfikowania i zatwierdzania wytworzonych produktów. Zamknięciem tego rozdziału jest raport przedstawiający bieżący stan inżynierii opro gramowania na światowym i polskim rynku informatycznym, jej historię oraz główne kierunki i logikę rozwoju. Rozdział 2 opisuje działania zmierzające do zdefiniowania celu i zakresu sys temu informatycznego oraz określenia wymagali, jakie musi spełniać jego oprogra mowanie. Takie działania wykonuje się zawsze przed podjęciem decyzji o poniesieniu nakładów w procesie wytwórczym. Inżynieria wymaąań łączy interes wytwórcy, nabywcy i bezpośredniego użytkownika oprogramowanią i obejmuje działania podej mowane przez każdą z tych stron przedsięwzięcia. j, Rozdział 3 przedstawia metodykę strukturalną, klika określa jedno z dwóch głównych podejść do wytwarzania oprogramowania, jakie funkcjonują obecnie na rynku infoifnatycznym. Metody strukturalne dostarczają modeli opisu wymagań, analizy problemu i projektowania struktury oprogramowania oraz technik i technologii umożliwiających tworzenie kodu aplikacji na podstawie wcześniej wykonanych modeli. Treść rozdziału obejmuje podstawy koncepcyjne podejścia strukturalnego, modele oraz metody ich stosowania w projekcie.
P rzedm ow a
9
Rozdział 4 przedstawia metodykę obiektową, która określa alternatywne podej ście do wytwarzania oprogramowania, funkcjonujące i szybko zyskujące popularność na rynku informatycznym, zwłaszcza w obszarze zastosowań internetowych i multi medialnych. Metody obiektowe posługują się obszernym zestawem modeli umożli wiających wyrażenie różnych aspektów projektowanego systemu na wszystkich eta pach jego wytwarzania oraz dysponują dojrzałymi technologiami automatyzującymi niektóre aspekty i etapy tego procesu. Treść rozdziału obejmuje podstawy koncepcyj ne podejścia obiektowego, modele, metody oraz wybrane technologie aplikacyjne. Rozdział 5 wyjaśnia zakres, organizację i metody prowadzenia procesu testowania, który w dużym stopniu decyduje o niezawodności wytworzonego oprogramowania i który pochłania znaczną część wysiłku i kosztu każdego projektu. Opis obejmuje planowanie i przygotowanie testów, metody pomiaru wiarygodności, strategie i metody testowania i usuwania defektów oraz narzędzia automatyzacji procesu testowania. Rozdział 6 wprowadza Czytelnika w problemy zarządzania projektem informa tycznym. Wyjaśnia, czym jest projekt, oraz opisuje sposób organizacji zespołu pro jektowego i działania podejmowane przez kierownika projektu podczas planowania, szacowania kosztów, zarządzania przebiegiem prac oraz przewidywania i ograniczania czynników ryzyka. Rozdział 7 uzupełnia i rozszerza horyzont zagadnień poruszanych w poprzednim rozdziale o działania zmierzające do oceny i zapewnienia jakości w projekcie infor matycznym. Wprowadza i wyjaśnia modele jakości produktu (oprogramowania) i proce su wytwórczego, zdefiniowane w międzynarodowych normach rodziny ISO 9000, opisuje podejście kompleksowego zarządzania jakością oraz wskazuje konkretne metody zapewnienia jakości oprogramowania, jakie można stosować w czasie trwania projektu. Rozdział 8 przedstawia alternatywne podejście do zarządzania projektem infor matycznym, promowane przez metodykę zwinną, a oparte na pewnych formach ze społowej odpowiedzialności za wykonaną pracę. Zasadniczą cechą metodyki zwinnej jest odejście od długookresowego planowania, dokumentowania i realizowani:! planu projektu na rzecz krótkoterminowego wyznaczania celów i elastycznego reagowania na zmiany potrzeb użytkowników oraz bieżące problemy projektu. Rozdział 9 wprowadza na scenę projekty informatyczne, których celem nie jest tworzenie nowego oprogramowania, lecz utrzymywanie i modyfikowanie stosownie do potrzeb użytkowników oprogramowania systemów już istniejących. Specyficznym problemem takich projektów, niewystępującym w projektach nowych, jest nagminny brak aktualnej dokumentacji oprogramowania, a w przypadku systemów bardzo starych nawet brak aktualnego kodu programów źródłowych. Treść rozdziału obej muje sposoby odtwarzania dokumentacji oprogramowania za pomocą technik inżynie rii odwrotnej oraz metody integracji starych systemów z nowymi w architekturze korporacyjnej szyny usług.
10
P rzed m o w a
Rozdział 10 opisuje problemy i metody stosowane podczas tworzenia oprogra mowania system ów krytycznych, tzn. systemów sterujących instalacjami i urządze niami, których błędne działanie może zagrozić życiu łub zdrowiu ludzi. Opis obejmuje specyficzne cechy i wymagania stawiane takim systemom, metody analizy bezpie czeństwa oraz szczególne podejścia stosowane podczas projektowania i implementacji oprogramowania. Granice inżynierii oprogramowania - choć nie są ostro zakreślone - pokrywają się w dużym stopniu z zakresem tej monografii. Nie oznacza to jednak, że książka po krywa - w jakim ś stopniu - wszystkie obszary inżynierii występujące w projekcie informatycznym. Najpoważniejszym wykluczeniem jest pominięcie obszaru baz danych, które wykształciły się w odrębną dziedzinę wiedzy, mającą własne książki, czasopisma i konferencje. Z tych samych powodów pominięte zostały technologie sieciowe oraz - lokujące się na wyższym poziomie abstrakcji - architektury usługowe (SOA). Książka nie obejmuje także specjalistycznych zagadtiień związanych z archi tekturą kom ponentową oraz współpracą człowieka ż maszyną. Ostatnią, niemal samodzielną, częścią książki jest bibliografia. Obejmuje zarów no pozycje klasyczne, pokazujące rozwój dziedziny oraz wkład wniesiony przez jej twórców, jak i zupełnie nowe opracowania, z których Czytelnik może czerpać naj nowszą wiedzę na temat interesujących go zagadnień. Dla ułatwienia poruszania się w tym materiale bibliografia jest podzielona na działy tematyczne, których zakres częścióW o'ptrkrywa się z zakresem rozdziałów książki, a częściowo obejmuje inne, zwarte jednostki treściowe.
t h i
Część I Procesy i metody
W prow adzenie ;1I Inżynieria oprogramowania zajmuje się metodami wytwarzania, oceniania i utrzymy wania oprogramowania systemów komputerowych oraz metodami zarządzania reali zacją projektów informatycznych. Celem stosowania tych metod jest zapewnienie wysokiej jakości oprogramowania oraz doprowadzenie do terminowej i zgodnej z budżetem realizacji projektu. Znaczenie metod inżynierii oprogramowania rośnie wraz z wielkością projektu. W bardzo małych projektach, zwłaszcza realizowanych dla siebie, wystarczy niekiedy sama umiejętność programowania. W nieco większych przydatne stają się metody modelowania problemu na różnych poziomach abstrakcji. Budowa wielkiego systemu informatycznego jest tak skomplikowanym zadaniem, że nie można od razu przystąpić do opracowania programów. Potrzeba bardzo ścisłego podejścia, aby zapanować nad złożonością problemu i opisać wymagania, zaprojektować sposób realizacji oraz wykonać i zatwierdzić produkt. Dlatego metody inżynierii oprogramowania są prze znaczone głównie dla dużych projektów, które wykazują następujące cechy:
:t!l
■ wykonanie projektu angażuje zespół ludzi, którego skład może zmieniać się w wyniku naturalnej fluktuacji personelu; * wymagania użytkowników są trudne do uchwycenia, trudne do wyrażenia i podlegają zmianom zarówno w trakcie, jak i po zakończeniu projektu; * eksploatacja wytworzonego oprogramowania trwa wiele lat i jest związana z ewolucją programów, które muszą nadążać za postępującymi w ciągu tych lat zmianami; * przetwarzanie realizowane w systemie jest złożone, a skutki ewentualnych awarii mogą być rozległe i dotkliwe dla otoczenia. ____ W celu pokazania znaczenia wszystkich wymienionych cech projektu rozważmy przykład opracowania oprogramowania systemu wspierającego działanie niezbyt
14
1. W pro w ad zen ie
dużego banku, prowadzącego rachunki paruset tysięcy klientów. Proces opracowania i wdrożenia takiego systemu trwa przeciętnie dwa lub trzy lata i angażuje w tym czasie blisko sto osób zatrudnionych przez bank i przez dostawcę systemu. Zarówno dane przechowywane w systemie, jak i realizowane na tych danych przetwarzanie są zbyt skomplikowane, aby człowiek mógł je po prostu zapamiętać i rozważyć z całą dokładnością. M uszą więc istnieć metody dekomponowania całości przetwarzania na mniejsze, możliwe do analizy fragmenty oraz budowania uproszczonych modeli, pozbawionych nieistotnych szczegółów, a uwzględniających wszystkie istotne na danym etapie cechy projektu. Modele te będą sukcesywnie rozwijane i uszczególawiane aż do osiągnięcia pełnej dokładności opisu w opracowanym na końcu kodzie programu. W czasie trwania projektu pracownicy przychodzą i odchodzą z pracy, a w ym a gania banku zmieniają się zarówno w wyniku zmian przepisów prawa bankowego, jak i w wyniku wprowadzania na rynek nowych produktów -bankowych. W szystkie te zmiany nie powinny naruszać ciągłości prac projektowych. Muszą zatem istnieć metody zapisywania wiedzy o projekcie w sposób zrozumiały dla wszystkich człon ków zespołu projektowego, metody przechowywania tej wiedzy i przekazywania jej nowym pracownikom oraz metody umożliwiające wprowadzanie zmian do projektu, bez rujnowania elektów już zrealizowanych etapów pracy.
L I . Proces rozw oju system u inform atycznego
15
cały kraj i dotyczyć podstaw egzystencji ogromnych grup społecznych. Aby do tego nie dopuścić, projekt systemu musi przewidywać specjalne strategie działania, zapew niające przetrwanie systemu pomimo awarii, a przynajmniej chroniące go od utraty istotnych danych, dotyczących np. stanu kont lub stanu przerwanych awarią transakcji.
1.1.
P ro c e s ro z w o ju s y s te m u in fo rm a ty c z n e g o
Oprogramowanie nie jest produktem samodzielnym, który można wykorzystywać bez powiązania z innymi elementami. Przeciwnie, oprogramowanie jest zawsze tylko częścią systemu informatycznego, obejmującego także sprzęt, łącza komunikacyjne oraz standardowe programy systemowe, integrujące i zarządzające działaniem całości. Dlatego, rozważając proces wytwarzania oprogramowania, trzeba pamiętać o całości systemu, w którym to oprogramowanie ma działać. Ogólny schemat procesu rozwoju systemu (.system development process, system lifecycle), w ramach którego powstaje także oprogramowanie, obejmuje zawsze cztery kolejno wykonywane luzy (rys. I. I).
Koszt, jaki inwestor musi ponieść podczas realizacji systemu bankowego, wy raźnie przekracza sto milionów złotych, a zwrot takiej sumy można uzyskać tylko w długim okresie czasu, sięgającym kilkunastu lub nawet kilkudziesięciu lat. W tym czasie zarówno przepisy, jak i oferowane do sprzedaży produkty bankowe, a także możliwości technologiczne, związane np. z komunikacją ze światem zewnętrznym, ulegają nieustannym zmianom, które z kolei wymuszają wprowadzanie zmian do eksploatowanego oprogramowania. Jeśli potrzeba zmian wystąpi wiele lat po wdroże niu systemu, to prawdopodobnie zmiany te będą wprowadzane przez zupełnie nowych ludzi, którzy nie brali udziału w opracowaniu systemu i nic na temat jego budowy nie wiedzą. Efektywność ich pracy będzie w ogromnym stopniu zależeć od sposobu udokumentowania budowy systemu w postaci różnorakich modeli. Działający system wspiera wszystkie procesy biznesowe wykonywane we wszy stkich oddziałach banku, którego pracownicy są przeszkoleni do obsługiwania zleceń klientów przy użyciu odpowiednich funkcji systemu^ Ewentualna awaria systemu uniemożliwia wykonywanie tych funkcji, co może calkpwicie sparaliżować normalne funkcjonowanie banku. Wszyscy klienci - ludzie i firmy posiadające konta w którym kolwiek oddziale - zostają pozbawieni dostępu do swoich pieniędzy. Straty wynikają ce z roszczeń odszkodowawczych oraz z utraty części klientów mogą w skrajnym przypadku doprowadzić nawet do bankructwa banku. W przypadku jeszcze większego systemu, takiego jak system obsługi ubezpieczeń społecznych lub system obsługujący proces dopłat bezpośrednich w rolnictwie, potencjalny zakres strat może obejmować
Rysunek 1.1. Proces rozwoju systemu inform atycznego
■ O kreślenie w ym agań. W stępną fazą każdego projektu, poprzedzającą podję cie decyzji o jego realizacji, jest określenie wymagań, jakie powinien spełniać
16
1. W p row adzenie
1.1. Proces rozwoju systemu informatycznego
17
—-------------------------------------------------------------------------------------------------------------------produkt, oraz przeprowadzenie studium wykonalności, prowadzącego do oszacowania kosztu i czasu realizacji przedsięwzięcia. Wyspecyfikowanie wszystkich wymagań otwiera drogę do negocjacji z dostawcami sprzętu i oprogramowania, które mogą doprowadzić do zawarcia umowy (kontraktu) na wykonanie systemu. ■ W ytw orzenie system u. W ymagania zapisane w umowie na wykonanie sys temu informatycznego opisują na ogól usługi, jakie ma dostarczać budowany system, bez wchodzenia w szczegóły realizacji tych usług. Czynnością otwie rającą fazę wytwarzania jest analiza wymagań, prowadząca do uszczegóło wienia opisu oraz określenia związków i zależności istniejących między róż nymi wymaganiami. Następnym krokiem jest podzielenie wymagań na lo gicznie powiązane obszary i przypisanie ich do odrębnych komponentów systemu. W ten sposób powstaje architektura systemu wyznaczająca jego po dział na współpracujące komponenty, sposób przypisania wymagań do po szczególnych komponentów oraz sposób, współpracy komponentów w celu zrealizowania wszystkich wymaganych usług. Zależnie od rodzaju systemu część komponentów może mieć charakter programowy, a część sprzętowy. Po zdefiniowaniu wymagań dla komponentów są one wytwarzane w nie zależnych od siebie procesach wytwórczych, kupowane gotowe lub konfigu rowane z elementów pochodzących np. z poprzednio realizowanych projek tów. Zastosowanie komponentów gotowych jest niemal zawsze tańsze, szyb sze i obciążone mniejszym ryzykiem niepowodzenia. Może jednak wymagać zmiany wymagań stawianych innym komponentom, w przypadku gdy gotowy komponent nie wykonuje wszystkich funkcji przypisanych mu w projekcie systemu. Końcową czynnością fazy wytwarzania jest integracja komponentów połą czona z testowaniem poprawności ich działania i współdziałania. W szystkie wykryte błędy są usuwane przez poprawienie błędnie działających kompo nentów. W małych projektach integracja może być wykonana w jednym kro ku, którego wynikiem jest gotowy system. W projektach wielkich integracja jest na ogól wykonywana przyrostowo, co polega na stopniowym dołączaniu do systemu kolejnych komponentów, po jednynj w każdym kolejnym kroku. Praktyka wytwarzania systemów pokazała, żel czynności integracji i te stowanie systemu są długotrwałym procesem, który pochłania często połowę kosztów całego projektu. , ■ W drożenie. Duży system informatyczny, wspierający działanie przedsiębior stwa, obejmuje swym zakresem wiele procesów biznesowych wykonywanych w lej firmie. W prowadzenie do eksploatacji takiego systemu nie jest rzeczą prostą, gdyż wymaga przełamania przyzwyczajeń i zmiany sposobu pracy lu dzi, a często także zmiany struktury organizacyjnej firmy. Wdrożenie nowego systemu wymaga też na ogół przeniesienia do tego systemu wszystkich da-
nycli i dokumentów, które dotychczas były przetwarzane ręcznie lub przy użyciu innych systemów. Przeprowadzenie operacji obejmującej r pracowanie nowego modelu pracy firmy, przeszkolenie pracowników i przeniesienie da nych, bez spowodowania istotnych zakłóceń w pracy przedsiębiorstwa, jest bardzo trudnym zadaniem. Proces wdrożenia nie musi być operacją jednorazową. Jeżeli kolejne wy dania systemu, powstające podczas przyrostowej integracji systemu, mają wartość biznesową, to mogą być wdrażane stopniowo, jedno po drugim. Taki przyrostowy wariant procesu wytwarzania systemu obrazuje na rys. 1. ł prze rywana strzałka obejmująca fazy wytworzenia i wdrożenia. ” K onserw acja sy stem u 1. Po wprowadzeniu do eksploatacji system zaczyna działać produkcyjnie. W tym okresie mogą się ujawnić niewykryte wcześniej błędy, a użytkownicy mogą uświadomić sobie istniejące i nieprzewidziane wcześniej potrzeby. Po jakim ś czasie zmienić się mogą przepisy prawa lub profil działania przedsiębiorstwa. W szystkie te sytuacje wymagają wprowa dzenia mniejszych lub większych poprawek albo nawet znaczącej modyfikacji działającego systemu. Działania te, nazywane konserwacją lub ewolucją sys temu, są kosztowną, lecz nieuchronną częścią życia każdego systemu infor matycznego. Okres konserwacji systemu kończy się dopiero wraz z wycofa niem go z eksploatacji, choć i wówczas trzeba jeszcze wykonać pewne prace związane z przeniesieniem danych do nowego systemu. Przedstawiony schemat procesu rozwoju systemu informatycznego nie pokazuje żadnych metod używanych w poszczególnych fazach tego procesu. Przedmiotem opisu są tu tylko cele oraz następstwo czynności wykonywanych w ciągu życia sys temu. Istotnymi elementami opisu są też zdarzenia warunkujące przechodzenie z jednej fazy do drugiej: ■ uzgodnienie specyfikacji wymagań, dokonywane w procesie podejmowania decyzji i podpisywania umowy na realizację systemu; * zatwierdzenie zgodności produktu z wymaganiami, dokonywane podczas od bioru części lub całości systemu. Ogromna złożoność problemu sprawia, że racjonalna organizacja całego przed sięwzięcia wymaga zaplanowania i wykonania wszystkich czynności w sposób syste matyczny i zgodny z jakąś uznaną i sprawdzoną metodyką.
1 Angielska nazwa tej fazy: maintenance, byw a tłumaczona na język polski jako konserwacja lub pielęgnacja. Termin pielęgnacja sugeruje utrzym yw anie lub przyw racanie pierwotnego stanu pacjenta. Term in konserwacja obejm uje to sam o plus ew entualne zmiany modernizacyj ne. Ponieważ 80% zadań tej fazy dotyczy modernizacji (ewolucji) oprogramowania, w tej książce używany jest w yłącznie termin konserwacja.
18
I . W p ro w ad zen ie
Rzeczywisty przebieg procesu rozwoju systemu oraz sposób przechodzenia mię dzy jego fazami zależą w dużym stopniu od przeznaczenia systemu i rodzaju od biorcy, dla którego ten system jest budowany. Można tu wyróżnić dwie istotnie różne sytuacje występujące na rynku produktów informatycznych: * budowa systemu na zamówienie konkretnego odbiorcy, np. systemu wspiera jącego działanie banku, przedsiębiorstwa produkcyjnego lub instytucji pu blicznej; ■ budowa systemu wytwarzanego dla masowego odbiorcy, np. systemu opera cyjnego, kompilatora albo gry komputerowej. W pierwszym przypadku wymagania określa zleceniodawca. Rola wykonawcy w tej fazie projektu ogranicza się do uściślenia wymagań, sprawdzenia możliwości wykonania systemu w zadanym terminie i określenia kosztu. Dojście do decyzji 0 realizacji przedsięwzięcia następuje często w drodze przetargu albo negocjacji z wyBMriym" wykonawcą. Faza wytwarzania obejmuje implementację oprogramowa nia realizującego wymagane funkcje oraz zbudowanie infrastruktury informatycznej, dopasowanej do potrzeb i zapewniającej zadowalające funkcjonowanie programów jak najmniejszym kosztem. W tym celu należy dobrać serwery o odpowiedniej wydaj ności, wyposażyć je w macierze dyskowe i pamięci masowe zdolne do przechowywa nia potrzebnych danych operacyjnych i archiwalnych, zaprojektować układ połączeń sieciowych gwarantujących wymagany poziom wydajności i bezpieczeństwa systemu, określić i skonfigurować oprogramowanie systemowe, takie jak system operacyjny, motor bazy danych i oprogramowanie pośredniczące (middleware), oraz zainstalować, zintegrować i dostroić wszystkie te elementy. Po wytworzeniu i przetestowaniu sys temu przez wytwórcę zleceniodawca dokonuje odbioru produktu w drodze testowania akceptacyjncgo, po którym rozpoczyna się trudna faza wdrożenia systemu w docelo wym środowisku przedsiębiorstwa. Po zakończeniu tej fazy wszelkie dalsze prace nad systemem podczas jego eksploatacji są inicjowane przez użytkowników.
1.2. O k reślen ie w ym agań
19
w zamian raporty o zauważonych błędach. Gdy liczba napływających raportów spad nie do założonego poziomu, producent usuwa błędy i wypuszcza na rynek pierwszą wersję produktu, kończąc tym samym etap testowania u odbiorcy (testowanie bela'). Od tej chwili produkt jest oferowany na rynku różnym odbiorcom. Po zakupie takiego oprogramowania jego wdrożenie nie różni się specjalnie od wdrożenia systemu za mawianego podobnej wielkości. Nieco inaczej przebiega natomiast faza konserwacji, w której nie występuje konieczność odpowiadania na indywidualne potrzeby odbior cy. Zamiast tego producent nieustannie bada potrzeby rynku, kontroluje poczynania konkurencji i co pewien czas wypuszcza kolejne, ulepszone wersje swojego produktu. ( Systemy budowane na zamówienie bardzo rzadko mogą być wdrożone ponownie w innym przedsiębiorstwie i przeważnie powstają w jednym egzemplarzu. Systemy budowane dla masowego odbiorcy są wytwarzane i oferowane wielokrotnie. Szczególnym przypadkiem systemów informatycznych są systemy wbudowane (embecided systeins), które tworzą integralną całość z otaczającą ten system instalacją techniczną. Przykładem może być system obsługi tarczy antyrakictowej, którego istotnym elementem jest. podsystem radarów namierzających nadlatujące rakiety, lub konsola Playstation, która zawiera specjalizowane procesory graficzne. Podział użyt kowych funkcji systemu między sprzęt i oprogramowanie jest tu decyzją projektowi) i zarówno programy, jak i elementy sprzętowe są projektowane specjalnie dla tego konkretnego zastosowania. Na przykład, animacja lub kompresja obrazu w konsoli graficznej może być realizowana przez specjalny program albo specjalne urządzenie. Proces wytwarzania systemu wbudowanego obejmuje więc czynności projektowania i wytwarzania zarówno oprogramowania, jak i sprzętu. Znanymi przykładami syste mów wbudowanych są systemy sterujące instalacjami przemysłowymi, transporto wymi, wojskowymi, a także centralami telefonicznymi lub urządzeniami powszechne go użytku.
W drugim przypadku wymagania określa producent, który wykonuje w tym celu odpowiednie badania rynku, ustala docelowe grupy odbiorców, poziom ich dochodów, potencjalne zapotrzebowanie itd. Ponieważ oprogramowanie jest przeznaczone dla szerokiego kręgu odbiorców, nie może wymagać nietypowej konfiguracji sprzętu przeciwnie, musi działać poprawnie na szerokiej platformie sprzętowej. W związku z tym nie ma na ogól potrzeby projektowania i budo\|ania żadnej specjalnej infra struktury informatycznej. Po wytworzeniu oprogramowania nie ma też komu dokonać niezależnego odbioru produktu. Zamiast tego po etapie testowania przez wytwórcę (testowanie alfa') oprogramowanie jest przekazywane wybranym dystrybutorom 1 użytkownikom, którzy za darmo korzystają z tej wersji programów, przekazując
Początkiem każdego projektu jest określenie jego celu oraz sprecyzowanie wymagań, jakie powinien spełnić końcowy produkt. Jest to zadanie kluczowe dla powodzenia całego przedsięwzięcia. Specyfikacja wymagań mówi projektantom, co ma być zro bione i jaki system, jakie oprogramowanie, ma powstać w wyniku wykonania pro jektu. Odbiór gotowego produktu zostanie dokonany przez sprawdzenie zgodności działania systemu ze specyfikacją wymagań. Jeśli wymagania nie będą odzwiercie dlały rzeczywistych potrzeb użytkownika, to może się okazać, że dużym wysiłkiem zbuduje się nie taki system, jaki jest rzeczywiście potrzebny.
1 a - pierwsza litera alfabetu greckiego użycza tu nazwy pierwszemu etapowi testowania produktu u wytwórcy.
1 p - druga litera alfabetu greckiego używana jako nazwa następnego etapu testowania pro duktu u odbiorcy.
1.2.
O k re ś le n ie w y m a g a ń
20
i . W p row adzenie
Dla zilustrowania złożoności problemu określenia wymagań rozważmy ponow nie oprogramowanie systemu wspierającego działanie banku, opisanego na początku tego rozdziału. Czego od tego systemu żądamy? ■ Czy ma jedynie prowadzić konta klientów, którzy lokują swoje środki w ban ku, czy także obsługiwać kredyty udzielane klientom, którzy konta w tym banku nie mają? ■ Jeżeli ma obsługiwać kredyty, to w jakim zakresie: czy tylko kontroli i księ gowania spłacanych rat kredytu, czy także oceny ryzyka kredytowego i auto matyzacji obsługi wniosków kredytowych? ■ Jak ma przebiegać proces przyznania kredytu i na podstawie jakich danych ma zapaść decyzja? Czy o przyznaniu kredytu ma decydować system, czy pracownik banku? " Jak ma być naliczane oprocentowanie kont i kredytów - tygodniowo, mie sięcznie, kwartalnie czy rocznie? Czy ma być obliczana efektywna stopa pro centowa? ■ Czy konta klientów mają być przechowywane w centralnej bazie danych czy w lokalnych bazach oddziałów banku? Jak ma się system zachować w razie przerwania łączności oddziału z centralą? ■ Co może, a co nie może się zdarzyć w chwili awarii? Na pewno nie może dojść do utraty danych o stanie kont i kredytów. Ale jak szybko system musi wznowić działanie? Natychmiast? Po kilku godzinach? Po kilku dniach? Każda odpowiedź na postawione pytania wymaga innego działania, a czasem i innej budowy oprogramowania. Kto ma tych odpowiedzi udzielić - projektant czy użytkownik? Raczej użytkownik, tyle że spełnienie niektórych wymagań może być bar dzo kosztowne. Na przykład, żądanie natychmiastowego wznowienia działania ]po awarii wymaga zbudowania systemu zapasowego, co podwaja koszty projektu, a nie jest, być może, niezbędne. Konieczna jest jakaś wymiana informacji między użytkownikiem a projektantem, prowadząca do kompromisu równoważącego potrzeby z możliwościami. Uzgodnione i zatwierdzone wymagania stają się częścią decyzji (umo\yy) reali zacji oprogramowania. Bardzo często wraz z wymaganiami definiuje się metody sprawdzenia stopnia spełnienia wymagań podczas odbioru gotowego produktu. Określenie i zatwierdzenie wymagań nie jest akljpm jednorazowym. Zarówno w czasie trwania oryginalnego projektu, jak i potem, podczas eksploatacji oprogramo wania, wymagania mogą się zmieniać w wyniku zmian zachodzących w realnym świecie biznesu. Może zmienić się prawo, mogą pojawić się nowe produkty bankowe, może zmienić się technologia. Nie można po prostu zignorować tych zmian. Z drugiej strony każdy system tworzy pewną spójną całość i dostosowanie systemu do zmienio nych wymagań może okazać się kosztowne. Co więcej, każda modyfikacja grozi wpro wadzeniem nowych błędów i wymaga kosztownej weryfikacji wszystkich zmienionych
.3. W ytw arzanie o program ow ania
21
elementów. Dlatego zmianami wymagań trzeba jakoś zarządzać. Po pierwsze, celo wość każdej zgłoszonej zmiany wymaga sprawdzenia. Po drugie, należy sprawdzić, czy nowe wymagania nie są w jakiś sposób sprzeczne z innymi wymaganiami. Dalej, zgłoszenia zmian dotyczących tych samych elementów systemu można pogrupować i zrealizować łącznie, ograniczając w ten sposób koszty modyfikacji. Znów wraca pytanie: kto ma zarządzać zmianami wymagań? Oceny celowości i ryzyka biznesowego związanego z wprowadzeniem lub zaniechaniem zmian musi dokonać użytkownik. Oceny kosztu i konsekwencji wprowadzenia zmian powinien dokonać wykonawca. Dlatego inżynieria wymagań rozwija się na styku projektanta z użytkownikiem, w miejscu, w którym spotyka się wiedza z obydwu dziedzin. Do kładniejsze przedstawienie tych zagadnień znajduje się w rozdziale 2.
1.3.
W y tw a rz a n ie o p ro g ra m o w a n ia
Oprogramowanie jest dobrem niematerialnym, którego produkcja masowa prawie nic nie kosztuje. Cały wysiłek i koszt wytwarzania są skupione w procesie opracowania pierwszego egzemplarza programów, które następnie można niemal za darmo powie lać. Dlatego proces wytwarzania oprogramowania jest w swojej istocie procesem projektowym, w którym opis potrzeb (wymagań) użytkownika przekształca się w działające oprogramowanie. W skład tego procesu wchodzi szereg działań, które można podzielić na cztery zasadnicze rodzaje. " A naliza (ancilysis). Działania analityczne mają na celu poznanie i opisanie problemu określonego przez wymagania użytkownika, wskazanie jego ele mentów i ich powiązań oraz dokładne zdefiniowanie tego, co oprogramowanie ma robić, bez pokazywania, jak ma być zbudowane. Wykonanie tego zadania obejmuje zbadanie dziedziny zastosowania, zrozumienie potrzeb użytkowni ka, wypracowanie koncepcji rozwiązania i zbudowanie modelu opisującego sposób spełnienia wymagań. Model powinien określać wszystkie wymagane funkcje i działania systemu, dane gromadzone i przetwarzane podczas wyko nywania tych funkcji oraz algorytmy i ograniczenia wykonania funkcji. M o del analityczny nie pokazuje natomiast budowy ani technologii wykonania programów. Sposób wykonania analizy oraz sposób udokumentowania jej wyników zależą od przyjętej metody tworzenia oprogramowania. “ P rojektow anie (design). Czynności projektowe przekształcają niezależny od technologii opis działania oprogramowania (model analityczny) w schemat budowy programu. W ykonanie tego zadania obejmuje wyznaczenie podsta wowych elementów programu, przypisanie im funkcji określonych podczas analizy, wybranie technologii informatycznej odpowiedniej dffrci-m/ncji opro gramowania oraz stworzenie modelu opisującego szczegóły jego budowy.
22
1. W p row adzenie
Model ten powinien określać strukturę programów, strukturę danych oraz sposób współdziałania wszystkich elementów przy wykorzystaniu wybranej technologii. M odel projektowy wciąż nie zawiera wielu szczegółów, które zo staną ustalone dopiero w kodzie programów. Sposób wykonania projektu oraz natura elementów programu zależą od przyjętej metody projektowania i wy korzystanej technologii implementacyjnej. ■ Im p lem en tacja (implementation.). Czynności implementacyjne przekształcają schemat budowy oprogramowania (model projektowy) w działający kod pro gramu. W ykonanie tego zadania obejmuje napisanie i uruchomienie wszyst kich elementów programu, połączenie tych elementów w działający system oraz przygotowanie testów sprawdzających poprawność działania. Bardzo często wraz z programami powstaje dokumentacja użytkowa i techniczna. * W ery fik acja i zatw ierd zan ie (verification and- validation). Opracowanie oprogramowania jest długim i trudnym procesem, pbdezas którego ludzie po pełniają błędy. Celem weryfikacji jest kontrola prawidłowości wykonania wszystkich działań i poprawności wytwarzanych przez nie wyników. Celem zatwierdzania jest sprawdzenie zgodności produktu z potrzebami użytkow nika. Sposób wykonania czynności kontrolnych zależy od postaci produktu. Dokumenty analityczne i projektowe można weryfikować, dokonując prze glądu ich treści. Program można sprawdzać eksperymentalnie, testując go w działaniu, przy czym przedmiotem testowania mogą być zarówno poszcze gólne jednostki programowe, jak i cale moduły, a w końcu kompletny produkt finalny. Ostateczna ocena i zatwierdzenie oprogramowania są podstawą do konania odbioru produktu. Jeszcze jednym rodzajem czynności, jaki można wyróżnić, jest konserw acja (maintenance), obejmująca wszelkie zmiany programów dokonywane po rozpoczęciu eksploatacji. M ieści się w tym usuwanie późno wykrytych błędów oraz wprowadzanie poprawek i modyfikacji odzwierciedlających zmiany zachodzące w świecie użytkow ników programu. Konserwacja zawiera w sobie kombinację czynności analizy, pro jektowania, implementacji, weryfikacji i zatwierdzania. Tym, co odróżnia działania związane z konserwacją od oryginalnego opracowania oprogramowania, jest koniecz ność ingerowania w strukturę działających programów. W ymaga to identyfikacji budowy i sposobu działania programu, a także stałego, analizowania potencjalnego wpływu zmian na inne części programu. Elementy lejnie występują w tak dużym natężeniu w oryginalnym procesie wytwórczym. Bardzo trudno jest ocenić wagę i udział poszczególnych rodzajów działań w pro cesie tworzenia oprogramowania oraz oszacować wysiłek niezbędny do ich wykona nia. Ocena taka jest jednak potrzebna, gdyż jej celem jest takie rozłożenie akcentów inżynierii oprogramowania, aby koncentrować uwagę na ulepszeniu czynności najbar dziej znaczących.
1.3. W ytw arzanie opro g ram o w an ia
23
Metoda, którą można tu zastosować, opiera się na szacowaniu kosztów. Całko wity koszt wytworzenia oprogramowania, na który składa się koszt zaangażowania ludzi i innych zasobów, rozkłada się między wykonanie wszystkich wymienionych działań. Jednym ze sposobów pomiaru wagi danego rodzaju działania jest oszacowa nie jego udziału w koszcie całego przedsięwzięcia. Ocena jest trudna, gdyż działania nie są ostro rozgraniczone, a ich udział w różnych projektach informatycznych waha się w dość szerokim zakresie. Jednak przyjmując koszt oryginalnego projektu (bez konserwacji) za 100%, można podać następujące, bardzo orientacyjne, oszacowanie [2 0 1 ,4 ,8 ]: ,
* ■ ■ ■ *
analiza projektowanie implementacja weryfikacja i zatwierdzanie konserwacja
15%, 25%, 20%, 40%, 100-300%.
Największy udział w kosztach weryfikacji i zatwierdzania mają koszty usuwania błędów popełnionych na różnych etapach procesu wytwórczego, a wykrytych podczas testowania programów. Największy udział w kosztach konserwacji ma dostosowywa nie programów do zmieniających się z czasem wymagań użytkowników. Wnioski płynące z tego zestawienia pokazują, że ograniczenie całkowitych kosztów oprogra mowania wymaga użycia takich metod, które umożliwią szybką weryfikację i usuwa nie błędów popełnianych w kolejnych krokach wytwarzania oraz będą sprzyjać łatwej modyfikacji gotowych programów.
1.3.1. P ro ce sy Różne rodzaje działań mogą występować w procesie tworzenia oprogramowania w różnej kolejności - następować po sobie, nakładać się na siebie lub powtarzać wielokrotnie, wyznaczając podział całego procesu na wyodrębnione fazy, widoczne z poziomu zarządzania projektem. Taki układ faz nazywa się procesem wytwarzania oprogramowania (software development process). Nie ma jednego uniwersalnego procesu akceptowanego przez wszystkich. Zależnie od konkretnej sytuacji i polityki wytwórcy stosuje się w praktyce bardzo różne procesy, które w uproszczeniu można sprowadzić do postaci kilku różnych modeli. Logika podpowiada, że proces rozwoju oprogramowania jest częścią procesu rozwoju systemu, opisanego w podrozdziale l .l. Niewątpliwie jest to prawda w przy padku systemów wbudowanych, w których część funkcji użytkowych wykonuje sprzęt, a część oprogramowanie, i w których konieczne są etapy dopasowania obydwu tych składników. Inaczej wygląda proces wytwórczy systemu, w którym wszystkie istotne funkcje użytkowe spełnia oprogramowanie niezależne lub prawie niezależne od sprzętu, na którym działa. Tworzenie systemu jest tu tożsame z tworzeniem opro
24
1. W p row adzenie
1.3. W ytwarzanie oprogram ow ania
25
4 -----------------------------------------gram owania i granica między obydwu procesami ulega zatarciu. W takim przypadku proces rozwoju systemu, opisany w podrozdziale 1.1, można traktować jako model pokazujący widoczne dla użytkownika etapy kontraktowania, odbioru i wdrażania systemu. Procesy opisane w tym podrozdziale są natomiast modelami przedstawiają cymi liizy wytwarzania oprogramowania, w których są stosowane różne metody i w któ rych wykonaniu biorą często udział różni ludzie.
oprogramowania są testowane celem sprawdzenia zgodności ich działania z projektem. Testowaniu towarzyszy usuwanie wszystkich znalezionych w programie defektów.
P ro c e s k a s k a d o w y
Odbiór i wdrożenie oprogramowania następuje po zakończeniu fazy testowania akceplaeyjnego, które dotyczy całego produktu i ma na celu ocenę zgodności jego działania ze specyfikacją wymagań. Po zakończeniu wdrożenia rozpoczyna się okres eksploatacji, związany z nieuchronną konserwacją wytworzonego oprogramowania.
W procesie wytwórczym zorganizowanym zgodnie z modelem kaskadowym (water fall model) zasadnicze działania są uporządkowane w sposób szeregowy, tworząc ciąg następujących po sobie faz, wykonywanych kolejno, jedna po drugiej, bez powracania do faz ju ż wykonanych (rys. 1.2). Każda faza obejmuje określony rodzaj działań dotyczących całości tworzonego oprogramowania.
W ynikiem każdej fazy są odpowiednie dokumenty projektowe, które podlegają formalnej weryfikacji i zatwierdzeniu przez kierownictwo projektu. Zakończenie dziakiń i zatwierdzenie wyników poprzedniej fazy jest niezbędnym w m li m rozpo częcia fazy następnej. "
Kaskadowy model procesu wytwórczego jest szeroko stosowany w praktyce. Do jego zalet należą jasne uporządkowanie pracy, brak powtarzania działań oraz wbudo wany mechanizm weryfikacji wyników każdej fazy. Wadą jest bardzo późna ocena stopnia spełnienia wymagań użytkownika, następująca w tym modelu dopiero w fazie testowania akceplaeyjnego - ju ż po zbudowaniu i zintegrowaniu całości oprogramo wania. Poprawienie ewentualnych błędów w tak późnej fazie procesu jest bardzo trudne i kosztowne. Do wad trzeba też zaliczyć niską odporność na zmiany wymagań następujące w trakcie trwania procesu. Ponieważ model kaskadowy nie przewiduje powracania do czynności wcześniejszych, nie ma w nim żadnego naturalnego miejsca na wprowadzenie ewentualnych zmian w już wykonanych działaniach. Konieczność dokonania takich zmian zaburza istotnie harmonogram całego procesu i staje się źródłem dodatkowych kosztów. P ro c e s ite ra c y jn y
R ysunek 1.2. M odel kaskadowy procesu tworzenia oprogram ow ania
Początkowa faza określenia wymagań ma na celu przygotowanie decyzji o roz poczęciu budowy oprogramowania. Jeżeli oprogramowanie stanowi część większego systemu, to specyfikacja wymagań stawianych oprogramowaniu powstaje podczas projektowania systemu. Jeżeli nie, to specyfikacja wy|nagań musi być dostarczona przez, zleceniodawcę oprogramowania lub wypracowana^w wyniku działań marketin gowych. Treść specyfikacji wymagań odzwierciedla na |>gół biznesowy punkt widze nia i określa ogólnie usługi, jakich od oprogramowania oczekuje przyszły użytkownik. Trzy następne fazy obejmują podstawowe czynności analizy, projektowania i implementacji programów. Kolejna faza, integracja i testowanie, ma na celu stopniowe łączenie poszczególnych jednostek programu, opracowanych w fazie implementacji, w coraz większe moduły aż do poziomu całości oprogramowania. Każda jednostka, a następnie każdy powstający w procesie integracji moduł programu i w końcu całość
W procesie wytwórczym zorganizowanym zgodnie z modelem iteracyjnym (iterative model) nie rozmieszcza się różnych rodzajów działań w różnych fazach procesu, lecz przewiduje iteracyjne powtarzanie wszystkich rodzajów działań - a przynajmniej elementów tych działań - w każdej fazie. Co więcej, wykonanie każdej fazy procesu może wymagać wykonania kilku następujących po sobie iteracji. W tak zorganizowa nym procesie wytwórczym każda kolejna iteracja zwiększa wiedzę o wszystkich aspektach tworzonego oprogramowania i przyczynia się do lepszej oceny ryzyka wystąpienia zakłóceń. Podział procesu na fazy (rys. 1.3) odzwierciedla tu kolejność podejmowania decyzji o angażowaniu coraz większych środków niezbędnych do zakończenia produkcji oprogramowania. Faza rozpoczęcia jest fazą określenia wymagań, na podstawie których ocenia się koszty, korzyści i ryzyko niepowodzenia oraz wskazuje jakąś koncepcję rozwiązania, dowodząc w ten sposób możliwości wykonania projektu. Działania związane z wery fikacją i oceną ograniczają się w tej fazie do zatwierdzenia wymagań oraz wskazania koncepcji testowania akceplaeyjnego. W złożonym projekcie faza rozpoczęcia może przebiegać iteracyjnie, tworząc kilkuetapowy cykl planowania inwestycji, obejmujący
]. W pro w ad zen ie
26
Rozpoczęcie
1.3. W ytw arzanie op ro g ram o w an ia
27
dokonywane w procesie, testowania akceptacyjnego. Również faza przekazania może mieć kilka iteracji, obejmujących różne wersje oprogramowania lub różne podsystemy.
Specyfikacja wymagań, ocena ryzyka Opracowanie Analityczny opis produktu, architektura, pian konstrukcji, ocena ryzyka Konstrukcja programu Działające programy, projekt, kod, dokumentacja, plan wdrożenia Przekazanie
R y su n ek 1.3. M odel iteracyjny procesu tworzenia oprogram ow ania
np. studium możliwości, studium przedrealizacyjne i studium wykonalności. Zależnie od oceny szans i zagrożeń projekt może być kontynuowany po zakończeniu tej fazy lub zaniechany z bardzo ograniczonymi stratami. Faza opracowania ma na celu wypracowanie całościowej koncepcji rozwiązania. Analiza wymagań prowadzi do zbudowania modelu zachowania systemu, który daje podstawę do wybrania technologii realizacyjnej i zaprojektowania architektury opro gramowania. Kolejne iteracje tej fazy mogą prowadzić - w złożonym projekcie - do opracowania kilku modeli zachowania o rosnącym stopniu szczegółowości. Działania związane z implementacją i weryfikacją mogą dotyczyć wstępnych prototypów pro gramu. Zależnie od powtórnej oceny szans i zagrożeń projekt może być kontynu owany po zakończeniu tej fazy lub zaniechany przed poniesieniem zasadniczej części kosztów. Faza konstrukcji jest okresem produkcji oprogramowania. Kolejne iteracje tej fa zy prowadzą do zbudowania kolejnych wersji systemu, realizujących coraz większą część wymagań. Każda iteracja obejmuje analizę realizowanych funkcji, projekt budowanego w tym kroku fragmentu oprogramowania, implementację oraz integrację wytworzonego fragmentu z już istniejącymi programami. Czynności te nie są wyko nywane szeregowo (jak w modelu kaskadowym), leczynogą się przeplatać w miarę potrzeb. Taki sposób pracy dobrze odpowiada naluńilnemu sposobowi myślenia człowieka, który podczas rozwiązywania trudnego prifblemu na przemian poszerza pole obserwacji i drąży w głąb wybrane fragmenty. Wynikiem każdej iteracji jest ograniczona, ale działająca wersja oprogramowania, którą można przedstawić do oceny użytkownikowi. Po zaplanowanej liczbie iteracji otrzymuje się kompletne, działające oprogramowanie. Faza przekazania nie różni się zbytnio od fazy wdrożenia w modelu kaskado wym. Tak samo też przebiega odbiór i zatwierdzenie gotowego oprogramowania,
Proces iteracyjny znacznie łagodzi główne wady procesu kaskadowego. Ponieważ oprogramowanie jest budowane stopniowo, a każdy wytworzony fragment jest podda wany testowaniu i ocenie, więc dużo wcześniej można wykryć i poprawić ewentualne błędy i niezgodności ze specyfikacją wymagań. Również zmiana wymagań w trakcie trwania procesu nie jest katastrofą, lecz może być uwzględniona przez rozszerzenie zakresu jednej z następnych iteracji. Model ten nie jest jednak pozbawiony wad. Prakty ka pokazała, że bardzo trudno jest tak ustalić kolejność implementowania funkcji opro gramowania, aby realizacja następnej grupy funkcji, w kolejnej iteracji fazy konstrukcji, nie wymagała wprowadzenia zmian w już istniejącym kodzie programu. Zwiększa to ilość pracy do wykonania i pociąga za sobą konieczność ponownego testowania zmie nionych fragmentów programów. Zarządzanie procesem iteracyjnym jest również trudniejsze niż zarządzanie ściśle szeregowym procesem kaskadowym. P ro c e s z w in n y Zarówno w kaskadowym, jak i iteracyjnym procesie wytwórczym wszystkie działania podejmuje się w kontekście całości budowanego systemu. W początkowych fazach procesu określa się całość wymagań użytkownika i całościową koncepcję działania systemu, tak aby zobaczyć całość pracy do wykonania. Następnie tworzy się projekt architektury całego oprogramowania i dopiero wtedy rozpoczyna się pisanie kotlu programu. Powstająca przy tym dokumentacja analityczna i projektowa rozrasta się do monstrualnych rozmiarów. Celem takiego postępowania jest - używając języka teorii sterowania - zapewnienie globalnej optymalizacji budowanego systemu. Praktyka pokazała jednak, że osiągnięcie tego celu w szybko zmieniającym się świecie jest trudne, a koszty - wysokie. Po pierwsze, samo opracowanie i utrzymanie aktualnej dokumentacji, która w dużym projekcie może liczyć tysiące stron, jest kosztowne. Po drugie, proces wytwórczy jest ociężały, gdyż każda zmiana w projekcie lub kodzie programu wymaga modyfikacji wielu dokumentów oraz ponownej ich weryfikacji i zatwierdzenia. Taki powtarzający się cykl zmian pochłania znaczną część energii i zasobów projeklu. W procesie zwinnym (agile process), zwanym też lekkim, odrzuca się cało ściowy sposób postrzegania i modelowania przyszłych rozwiązań na rzecz szybkiej implementacji bieżących wymagań i lokalnej optymalizacji w odpowiedzi na zmiany. Skoro nie da się z góry przewidzieć całości wymagań i całości rozwiązania, klórc za chwilę mogą ulec zmianie, to nie warto tworzyć i dokumentować ich modeli. Zamiast tego trzeba szybko stworzyć produkt realizujący część potrzeb użytkownika, a polem rozwijać go dalej, uwzględniając przy tym zarówno zmiany, jak i nowe potrzeby. Dlatego horyzont czasowy procesu zwinnego obejmuje co najwyżej kilka mie sięcy, podczas których powstaje kompletne wydanie (release) oprogramowania. Jeśli
28
1. W p row adzenie
użytkownik potrzebuje większego systemu, to powstanie on w ciągu kilku wydań trudno określić ilu, ponieważ przedmiotem planowania jest zawsze tylko jedno, bie żące wydanie. Zakres wydania określa użytkownik podczas negocjacji, nazywanych planowaniem wydania (release planning) lub grą planistyczną, których wynikiem jest zwięzły opis wymagań, opis testów akceptacyjnych oraz szkic architektury progra mów. W dalszym ciągu procesu dokładny opis wymagań zastąpi rozmowa z użytkow nikiem, stale obecnym w zespole, oraz opis testów, które muszą być spełnione. W ytwarzanie wydania przebiega iteracyjnie (rys. 1.4), przy czym liczba iteracji jest ustalona, a czas trwania każdej iteracji jest taki sam i wynosi zazwyczaj 2-3 tygodnie. Zakres działań wykonywanych w bieżącej iteracji ustala się w chwili jej rozpoczęcia, biorąc pod uwagę preferencje użytkownika i indywidualne możliwości deweloperów - ludzie nie są wymienni i mają różne predyspozycje do wykonywania różnych działań. Podczas iteracji oprócz programów implementujących funkcje wy magane przez użytkownika opracowuje się też testy akćeptacyjne, umożliwiające sprawdzenie działania implementowanych funkcji. Planowanie wydania 1
1.3. W y tw arzanie o p ro g ram o w an ia
29
Proces zwinny pozwala na istotne zmniejszenie kosztów projektu i jednoczesne za pewnienie wysokiej satysfakcji użytkowników. Szybkie tworzenie kodu, od początku projektu, i nierozerwalne związanie tworzenia kodu z testowaniem umożliwiają szybkie wykrywanie i poprawianie błędów. Stałe utrzymywanie działającej wersji programu daje możliwość stałej kontroli i oceny rezultatów przez użytkownika. Po stronie wad trzeba wymienić przede wszystkim krótki horyzont planowania. Trzeba ogromnej dozy zaufa nia do wykonawcy, aby zaakceptować obietnicę wykonania systemu w ciągu kilku (nie wiadomo ilu) wydań. Innym problemem jest praca z niepełną dokumentacją, zastępowa ną przez bezpośrednią komunikację deweloperów między sobą i z użytkownikiem. Taki styl pracy jest możliwy tylko w niewielkim zespole. P ro c e s k o m p o n e n to w y Wytwarzanie oprogramowania nie zawsze polega na opracowaniu i napisaniu progra mów od początku. W ręcz przeciwnie, coraz częściej wykorzystuje się w projektach gotowe komponenty, opracowane wcześniej w ramach innych projektów albo stwo rzone specjalnie z myślą o wielokrotnym użyciu. Projekty tego typu, w których zasad niczym problemem jest dobór, a później integracja gotowych komponentów, są nazy wane projektami integratorskimi.
Wymagania użytkownika, koncepcja testów, szkic architektury
Kolejna iteracja 1r
Bieżąca wersja oprogramowania
Testowanie akceptacyjne 1
Wydanie oprogramowania
R ysunek 1.4. Model zwinnego procesu tworzenia oprogram ow ania
1
Jedynym miernikiem postępu prac jest przyrost działającego kodu. Deweloperzy wybierają do wykonania funkcje programu przypisane,do tej iteracji, po czym imple mentują najpierw testy umożliwiające sprawdzenie działania wytworzonej jednostki programu, potem sam program. Praca nie jest zakończona, dopóki jednbstka nie przejdzie wszystkich testów. Jeśli testy przejdą pomyjilnie, to nowa jednostka pro gramu jest integrowana z resztą istniejącego kodu. \M ten sposób w każdej chwili trwania projektu istnieje jakaś działająca wersja oprogramowania, którą można poka zać użytkownikom i uzyskać ich akceptację lub uwagi krytyczne. Każda iteracja kończy się po wyczerpaniu swego czasu. Te funkcje, które przejdą testy akceptacyjnc, są zaliczane do wyników iteracji. Te, które ich nie przejdą albo nie zostaną w ogóle wykonane, są przesuwane do następnej iteracji. Stały rytm czasowy wyznaczany przez kolejne iteracje umożliwia precyzyjną ocenę postępów projektu i podejmowanie - w razie potrzeby - działań korygujących pojawiające się problemy.
R ysunek 1.5. Model kom ponentowego procesu tworzenia oprogram ow ania
Proces tworżenia oprogramowania z komponentów (component-based process) jest zwykle zgodny z modelem kaskadowym (rys. 1.5), w którym zmianie ulegają zakres i sposób wykonania poszczególnych faz. Faza analityczna, nazywana często analizą przedwdrożeniową, obejmuje przegląd dostępnych na rynku komponentów, analizę luk występujących między wymaganiami a funkcjami komponentów oraz wybór kom ponentów do wykorzystania. Wybranie komponentów, odwzorowanie wymagań w ich funkcje oraz specyfikacja luk, wymagających uzupełnienia, pozwalają określić praco
30
1. W pro w ad zen ie
J.3. W ytw arzanie oprogram ow ania
31
_ 4 _ -----------------------------------------------------------------------------------------
chłonność dalszych prac i oszacować koszt oraz termin opracowania całości. Uzgodnie nie tych warunków otwiera drogę do negocjacji umowy na wykonanie produktu. Dalsze prace koncentrują się na zaprojektowaniu architektury całości, a następnie implementacji zaprojektowanego rozwiązania, polegającej na dostosowaniu kompo nentów do docelowego środowiska pracy oraz implementacji elementów wypełniają cych luki funkcjonalne i elementów pełniących rolę interfejsów umożliwiających współpracę komponentów. Sposób wykonania tych prac zależy od zakresu możliwego dos toso wa n ia ko mpo nen tó w . Komponenty o znanym kodzie źródłowym mogą być modyfikowane, w zakresie zgodnym z prawem autorskim, przy użyciu tych samych metod, które są stosowane podczas tworzenia oprogramowania. Komponenty konfigurowalne, dostarczane przez producenta bez kodu źródłowego, ale ze specjalnymi narzędziami konfiguracyjnymi, np. moduł finansowo-księgowy albo moduł obsługi kont gankowych, są konfiguro wane przy użyciu tych narzędzi. Komponenty p nieznanym kodzie źródłowym są włączane do systemu poprzez opracowane w tym celu programy sprzęgające, które z jednej strony akceptują interfejs stosowany w nowym systemie, a z drugiej korzy stają z funkcji udostępnianych przez wykorzystywane komponenty. Budowanie oprogramowania z gotowych komponentów jest prawie zawsze szyb sze, tańsze i obarczone niższym ryzykiem niepowodzenia niż opracowanie zupełnie nowego produktu. W adą - z biznesowego punktu widzenia - jest uzależnienie użyt kownika od producenta wykorzystanych komponentów, który może np. zaprzestać konserwacji komponentu kupionego bez kodu źródłowego, zmienić jego działanie w następnej wersji lub odmówić prawa do modyfikacji niezbędnej dla dostosowania komponentu do zmienionych wymagań.
1 .3 .2 . M e to d y Proces tworzenia oprogramowania wyznacza ogólne ramy dla wykonania działań analitycznych, projektowych, implementacyjnych i Weryfikacyjnych, wskazuje cel i oczekiwane wyniki kolejnych faz oraz określa warunki przejścia do następnej fazy. Wynikiem wykonania kolejnych działań są kolejne modele oprogramowania, budo wane na różnych poziomach abstrakcji - od modelu (wymagań aż do działającego programu - odzwierciedlające wiedzę posiadaną na dat^ym etapie projektu. Definicja procesu nie określa natomiast metod wykonania działali Metody muszą być zdefinio wane oddzielnie, w sposób spójny w całym procesie -i tak, aby modele budowane wcześniej tworzyły podstawę dla modeli budowanych na etapach późniejszych. M etody tworzenia oprogramowania określają rodzaj modeli budowanych w wy niku różnych działań, schematy ułatwiające tworzenie modeli dobrych oraz wskazówki-httgerujące prawidłową kolejność tworzenia modeli. Przyjmując za podstawę klasyfikacji metod rodzaj wykorzystywanych modeli, można wyróżnić dwie grupy
metod analizy i projektowania oprogramowania, będące ciągle w powszechnym uży ciu. Metody te wyrastają z dwóch różnych technologii implementacyjnych i opierają się na dwóch różnych zestawach modeli koncepcyjnych. Teoretycznie oba rodzaje metod mogą być używane w dowolnym typie procesu projektowego. Praktyka poka zała jednak, że metody strukturalne stosuje się często w procesie kaskadowym, a me tody obiektowe - w procesach iteracyjnych i zwinnych. M e to d y s tr u k tu r a ln e Metody strukturalne (struclured methods) wykorzystują model przetwarzania danych zawierający dwie odrębne warstwy: pasywne dane, opisujące stan dziedziny zastoso wania, i aktywne funkcje, przetwarzające dane zgodnie z obowiązującym algorytmem działania. Jest to model tradycyjnie stosowany do opisywania sposobu działania organizacji administracyjnych lub gospodarczych, w których pracownicy (aktywne funkcje) przetwarzają gromadzone w tej organizacji dokumenty (pasywne dane). Model ten jest również zgodny z budową strukturalnych języków programowania, takich jak C lub Pascal, w których podstawowymi elementami syntaktycznymi są pod programy (funkcje) i definicje danych. Działania analityczne obejmują dwa wątki: określenie funkcji, dekomponowanych w celu zwiększenia dokładności opisu na funkcje prostsze, oraz określenie struktur danych i ich wzajemnych powiązań. Wynikiem pierwszego rodzaju działań jest model przetwarzania przedstawiony w postaci diagramu przepływu danych (patrz rys. 3.2), którego węzłami są aktywne funkcje i pasywne zbiory danych, a lukami - przepływy przenoszące między nimi porcje danych potrzebne do wykonania funkcji. Wynikiem drugiego działania jest model danych przedstawiony w postaci diagramu encji (patrz rys. 3.6), którego węzłami są zbiory danych, a lukami relacje istniejące między zapisanymi w tych zbiorach danymi. Obydwa modele - diagram przepływu danych i diagram encji opisują dokładnie, jakie dane podlegają przetwarzaniu i na czym to przetwarzanie pole ga, nie określają natomiast w żaden sposób budowy programu. Działania projektowe obejmują wyznaczenie podstawowych elementów progra mu, do których zostają przypisane funkcje zdefiniowane podczas analizy, określenie sposobu wywoływania i komunikowania się podprogramów oraz opracowanie struktu ry danych. Wynikiem tych działań jest model budowy programu, przedstawiony w postaci diagramu struktury (patrz rys. 3.8) opisującego hierarchię wywołujących się podprogramów i definiującego sposób ich komunikowania się za pomocą argumentów lub danych wspólnych, oraz model tabel i indeksów bazy danych. Obydwa modele, które opisują szczegółowo postać przyszłej implementacji, powstają przez przekształcenie wcześniejszych modeli analitycznych. W eryfikacja zgodności obydwu typów modeli jest warunkiem zatwierdzenia wyników projektu.
1. W p row adzenie
32
1.4. W ery fik acja i zatw ierdzanie
33
W arto zauważyć naturalny związek modeli strukturalnych z fazami procesu ka skadowego:
sposób działania oprogramowania widziany przez użytkowników oraz obiekty podle gające temu działaniu, nie określają natomiast budowy programów.
* w fazie określenia wymagań powstają hierarchiczne definicje funkcji, ■ w fazie analizy budowane są diagramy przepływu danych i diagramy encji, B w fazie projektowania powstaje diagram struktury programu i opis tabel bazy danych, " w fazie implementacji powstają podprogramy i tabele, “ w fazie integracji następuje połączenie podprogramów zgodnie z projektem oraz testowanie poprawności działania.
Projektowanie programu polega na odwzorowaniu klas trwałych w tabele bazy danych, zdefiniowaniu sposobu wykonania przypadków użycia przez współdziałające obiekty różnych klas i potraktowaniu diagramu klas jako diagramu hierarchii dziedzi czenia języka obiektowego.
Z drugiej strony trzeba też zauważyć niedogodności tej metodyki. Należą do nich konieczność zmiany rodzaju modelu podczas przejścia od analizy do projektu oraz mala modyfikowalność implementacji. Zarówno zmiana, jak i dodanie nowego za chowania programu pociąga za sobą konieczność zmiany Wszystkich modeli, zmody fikowania istniejących programów i powtórzenia procesu testowania. Strukturalne metody opracowania oprogramowania są dokładnie opisane w roz dziale 3. M e to d y o b ie k to w e Metody obiektowe (object-orienied metliods) opisują proces przetwarzania jako wynik interakcji wielu autonomicznych obiektów, z których każdy reprezentuje jakiś frag ment dziedziny zastosowania i zawiera w sobie zarówno porcję danych charakteryzu jących stan tego fragmentu, jak i funkcje przetwarzające te dane. Jest lo model często stosowany do opisywania sposobu działania zbiorowości ludzkich, np. oddziałów wojskowych, w których każdy żołnierz lub oddział ma zestaw cech (atrybutów) określających jego zdolności bojowe oraz pewne moce sprawcze umożliwiające mu wykonywanie zadań. Dziejąca się akcja jest wynikiem interakcji żołnierzy i oddziałów komunikujących się z sobą zgodnie z pewnymi ustalonymi regułami. Model ten jest też zgodny z budową obiektowych języków programowania, takich jak C++ lub Java, w których podstawowymi elementami syntaktycznymi są klasy obiektów zawierających w sobie elementy danych (pola) i operacje (metody). Działania analityczne obejmują dwa wątki: okreśipnie zachowań oprogramowa nia, widocznych dla zewnętrznych użytkowników, o ra | wyodrębnienie i sklasyfiko wanie elementów dziedziny zastosowania, których te zachowania dotyczą. Wynikiem pierwszego rodzaju działań jest model zachowania systemu zapisany w formie przy padków użycia (patrz rys. 4.2), opisujących sposoby wykorzystania systemu przez użytkowników. W ynikiem drugiego działania jest klasyfikacja elementów dziedziny zastosowania, przedstawiona w postaci diagramu klas (patrz rys. 4.4), którego węzłami są klasy obiektów, a lukami relacje klasyfikacyjne i stowarzyszeniowe występujące między tymi klasami. Obydwa modele - przypadków użycia i klas - opisują dokładnie
Siłą metod obiektowych jest elastyczność i łatwość wprowadzania zmian, wyni kająca z dwóch czynników. Pierwszym czynnikiem jest brak radykalnej zmiany modelu tworzonego przez działania analityczne i projektowe. Modelem podstawowym, używa nym od wczesnej analizy wymagań aż do implementacji, jest diagram klas, obudowany pewną liczbą modeli pomocniczych. Jednorodność notacji pozwala uniknąć kłopotliwej weryfikacji zgodności modelu projektowego z modelem analitycznym. Drugim czynni kiem jest dostępność mechanizmu dziedziczenia, pozwalającego na dodawanie nowych zachowań bez zmieniania pozostałej części modelu lub nawet programu-___ Łatwość wprowadzania zmian umożliwia efektywne wykorzystanie metod obiek towych w iteracyjnym procesie projektowym, w którym: D w fazie opracowania powstają scenariusze przypadków użycia, diagram klas dziedziny zastosowania, opis architektury oraz plan wykonania iteracji fazy konstrukcji; ■ w fazie konstrukcji powstaje diagram klas programu, model współdziałania obiektów i w końcu program realizujący funkcjonalność systemu. Podejście obiektowe ma też swoje słabości. M odele obiektowe są mniej intuicyj ne od strukturalnych, a duża liczba różnych modeli pomocniczych zwiększa złożoność projektu. Jteracyjny styl pracy powoduje konieczność modyfikowania wcześniej opracowanego kodu podczas integrowania z kodem wytworzonym w kolejnej iteracji. Obiektowe metody opracowania oprogramowania są dokładnie opisane w roz dziale 4.
1.4.
W e ry fik a c ja i z a tw ie rd z a n ie
Każdy program powinien być poprawny w dwojakim sensie: powinien być zbudowa ny zgodnie z regularni sztuki, bez błędów i ukrytych usterek, oraz powinien zaspo kajać potrzeby użytkownika w tych zastosowaniach, do których jest przeznaczony. Aby zapewnić osiągnięcie obydwu tych celów, potrzebne są dwa rodzaje działań kontrolnych, wplecionych w różne fazy procesu wytwórczego. " W ery fikacja (verification). Błędne działanie programu może być wynikiem pomyłek popełnionych przez różnych ludzi w różnych fazach procesu wy
34
1. W pro w ad zen ie
twórczego, np. pomyłek projektanta lub programisty. Dlatego na każdym eta pie projektu trzeba sprawdzać poprawność jego wyników względem wyników poprzedniego etapu, odpowiadając na pytania typu: czy projekt zapewnia spełnienie wymagań zapisanych w specyfikacji? Albo: czy implementacja programu jest zgodna z ustaleniami projektu? ■ Z atw ierd zan ie (validalion). Nawet poprawnie zbudowany program może nie zaspokoić potrzeb użytkownika, jeżeli te potrzeby zostaną źle rozpoznane lub wymagania nie zostaną zrealizowane w całości. Dlatego po analizie wymagań oraz po implementacji oprogramowania trzeba sprawdzić poprawność obu tych produktów, odpowiadając na pytania typu: czy specyfikacja oprogramo wania określa te funkcje, których oczekuje użytkownik? Oraz: czy gotowe oprogramowanie działa w sposób zgodny z oczekiwaniami i potrzebami użyt kownika? W ymagania dotyczące poprawności, a w ślad za tym rodzaj i intensywność działań związanych z weryfikacją i zatwierdzaniem oprogramowania zależą od cha rakteru zastosowania i są tym wyższe, im większe straty mogą powstać w wyniku błędnego działania programu. ■ Najwyższe wymagania stawiamy programom w tych dziedzinach, w których błędne działanie może zagrozić życiu lub zdrowiu ludzi, np. w sterowaniu przemysłowym, transporcie, energetyce, medycynie - tu niedopuszczalne są nawet pojedyncze błędy. B Niższe wymagania obowiązują w takich dziedzinach, w których błędy nie ro dzą poważnych następstw, np. błąd edytora tekstu albo gry komputerowej też jest oczywiście niepożądany, ale drobne usterki nie dyskwalifikują tu całkiem produktu. M ożna powiedzieć, że program musi działać poprawnie w stopniu akceptowal nym w swojej dziedzinie zastosowania. Poprawność nie jest jedyną pożądaną cechą oprogramowania. Przykładami in nych takich cech moga być łatwość użycia, wydajność, niezawodność lub łatwość konserwacji. W szystkie te cechy składają się łącznie na^pojęcie jakości oprogramowa nia. Celem stosowania różnych metod inżynierii oprogramowania jest wytworzenie produktu o odpowiednio wysokiej jakości. Przedmiotejji weryfikacji i zatwierdzenia powinna więc być nie tylko poprawność, lecz także wszystkie inne cechy decydujące o jakości oprogramowania. W eryfikacja i zatwierdzanie mają inaczej określony cel i nieco inne nastawienie. W praktyce jednak obydwa rodzaje działań używają podobnych metod oceny i w tym aspekcie nie ma między nimi wyraźnego rozgraniczenia. W iększy wpływ na rodzaj stosowanych metod oceny ma postać ocenianego produktu. Dokumenty powstające w procesie wytwórczym można oceniać statycznie, tzn. analizować ich treść, korzystając
1.4. W eryfikacja i zatw ierd zan ie
35
w razie potrzeby z pomocy ekspertów. Działające programy można oceniać dyna micznie, tzn. sprawdzać w działaniu. Biorąc to pod uwagę, można wyróżnić trzy podstawowe rodzaje metod weryfikacji i zatwierdzania.
\
■ Testow anie (testing). Jest to metoda oceny oprogramowania polegająca na wykonywaniu programu z zadanym zestawem danych wejściowych oraz reje strowaniu i ocenianiu wyników, np. poprawności wykonania funkcji lub osiąg niętej wydajności. Celem procesu testowania jest leż zawsze wykrycie i usu nięcie tkwiących w programie defektów. Natura testowania ogranicza zakres zastosowania tej metody do produktów wykonalnych, czyli programów lub ich prototypów. Co więcej, dawno już za uważono, że testowanie może co najwyżej ujawnić obecność błędów, ale nie może udowodnić ich braku. Testowanie oprogramowania, traktowane jako metoda wykrywania błędów, jest też procesem mocno spóźnionym - błędy mogą powstawać już od samego początku projektu, a testowaniu podlegają dopiero gotowe programy. Skutkiem tak późnego wykrycia błędu może być bardzo wysoki koszt jego usunięcia (por. podrozdział 1.3). Mimo tych wad te stowanie jest najważniejszą i najbardziej wiarygodną metodą weryfikacji i zatwierdzania oprogramowania przed dostawą. ■ P rzeglądy i inspekcje (reviews and inspections). Są formą oceny jakości prac i produktów wykonanych procesie wytwórczym, polegającą na kontroli i oce nie treści dokumentów analitycznych i projektowych, takich jak specyfikacja wymagań, projekt, program lub plan testowania. Przygotowanie przeglądu obejmuje często opracowanie recenzji oceniających badany dokument lub stan prac. Najważniejszym elementem przeglądu jest spotkanie z udziałem in nych członków zespołu i - być może - kierownictwa lub przedstawicieli za mawiającego, podczas którego następuje rozpoznanie i analiza wszystkich zgłoszonych problemów i zastrzeżeń. Pozytywna ocena może prowadzić do zatwierdzenia produktu. W przeciwnym razie rezultatem przeglądu może być tylko ocena stanu zaawansowania prac oraz zbiór uwag wskazujących na ko nieczność dokonania poprawek. Zaletą technik oceny za pomocą statycznej analizy dokumentów jest brak ograniczeń co do zakresu zastosowania - przedmiotem oceny przez ekspertów mogą być wszystkie produkty i wszystkie prace podejmowane podczas pro cesu wytwórczego. Doświadczenia wielu firm dowodzą, że systematyczne przeglądy i inspekcje są skuteczną metodą oceny postępów prac, zatwierdza nia ich wyników i podnoszenia jakości. Inspekcje projektu lub kodu mogą też służyć weryfikacji tych produktów. Dowodzenie popraw ności (correctness proving). M etoda ta polega na for malnym (matematycznym) wykazaniu, że program lub inny produkt procesu wytwórczego ma pożądane właściwości. Z teoretycznego punktu widzenia
36
1. W p row adzenie
„I .5. Inżynieria oprogram ow ania
37
■4—-----------------------------------------------------------------------------------------------------------------dowodzenie poprawności programów jest możliwe, gdyż każdy program komputerowy jest formalnym zapisem pewnych przekształceń liczbowych, którego interpretację określa jednoznacznie wykonująca ten program ma szyna. Gdyby możliwe było matematyczne sformułowanie wymagań, moż liwe byłoby również matematyczne udowodnienie, czy rozważany program te wymagania spełnia, czy nie. W praktyce okazało się, że wcielenie tej idei w życie jest bardzo trudne. Część trudności ma charakter techniczny - przeprowadzenie dowodu jest znacznie trudniejsze niż napisanie programu, a dowód jest zwykle dłuższy niż program i też może zawierać błędy. Te trudności, być może, rozwiąże kiedyś automatyzacja procesu dowodzenia. Pozostałe trudności mają charakter fun damentalny - jak zapisać wymagania w sposób formalny i jak taki formalny zapis wymagań zatwierdzić. Czy można oczekiwać, że np. eksperci w dziedzi nie bankowości zapiszą wymagania dla systemu bankowego w postaci kil kuset stron równań? Dlatego dowodzenie poprawności stosuje się w praktyce w bardzo ograni czonym zakresie. Po pierwsze, w dziedzinie systemów sterujących, w których inżynierowie z natury rzeczy operują matematycznym opisem rzeczywistości, a katastrofalne następstwa błędów usprawiedliwiają poniesienie dodatkowych kosztów. Po drugie, bardzo często wymaga się dowodów poprawności istot nych fragmentów specyfikacji wymagań - algorytmów działania, np. algo rytmu sortowania zbioru, lub protokołów komunikacyjnych. Przedmiotem weryfikacji i zatwierdzania, przy użyciu wymienionych metod, może być kod programu lub dokumenty projektowe. Istotna różnica między tymi dwoma przypadkami polega na tym, że celem kontroli programu jest wykrycie i usu nięcie już istniejących w nim błędów, natomiast celem oceny dokumentów pro jektowych jest zapobieżenie powstaniu błędów. Obydwa rodzaje działań mają więc różny charakter i zachodzą w różnych momentach procesu wytwórczego.
wytwarzania oprogramowania, nosi nazwę procesu zapew nienia jakości o p ro g ra mow ania. Metody zapewnienia jakości będą omawiane w rozdziale 7.
1.5.
In ż y n ie ria o p ro g ra m o w a n ia
Inżynieria oprogramowania powstała niespełna pół wieku temu, a jej zadaniem miało być wypracowanie skutecznych sposobów budowania i wdrażania wielkich systemów informatycznych w przewidywalnym terminie i z rozsądnym kosztem. W ciągu lego czasu powstało szereg procesów organizacyjnych, metod i technologii wytwarzania oprogramowania. W iele systemów informatycznych zostało zbudowanych i wdrożo nych do eksploatacji, a oprogramowanie znajduje się w niemal każdym bardziej złożonym urządzeniu domowym. Jednocześnie jednak obecny stan inżynierii opro gramowania trudno uznać za zadowalający. Odsetek projektów, których nie udało się doprowadzić do końca lub które znacząco przekroczyły założony koszt: i czas realiza cji, jest bardzo wysoki - dużo wyższy niż w innych dziedzinach inżynierii. Przyczyny takiej sytuacji są złożone. Z jednej strony projekty informatyczne mają wiele cech wspólnych z projektami wykonywanymi w innych dziedzinach inżynierii. Po tej stronie trzeba umieścić konieczność zbilansowania nakładów finan sowych, pracy ludzkiej i czasu, niezbędnych do osiągnięcia celu, z posiadanymi zasobami oraz związaną z tym potrzebę zarządzania przedsięwzięciem. Z drugiej strony główny produkt projektu informatycznego, jakim jest oprogramowanie, ma szereg cech specyficznych, istotnie różnych od cech produktu powstającego w innych projektach, np. budowlanych lub mechanicznych.
Podstawową metodą weryfikacji i zatwierdzenia programu jest testow anie. Pro ces testowania dzieli się na ogół na odrębne fazy testowania przez producenta (weryfikacja) i testowania akceptacyjnego przez użytkownika (zatwierdzanie). Prze bieg procesu i metody testowania będą dokładnie omówione w rozdziale 5.
■ Oprogramowanie jest tworem niematerialnym, którego elementów, powstają cych w procesie wytwórczym, nie można obejrzeć i ocenić, opierając się na sygnałach odbieranych przez nasze zmysły. ■ Wymagania stawiane oprogramowaniu są często tak złożone i różnorodne, że bardzo trudno jest je dokładnie określić, a potem ocenić stopień ich wykonania. ■ Oprogramowanie jest podatne na zmiany - nadużywanie tej właściwości pro wadzi do niespotykanej gdzie indziej zmienności wymagań w czasie trwania projektu.
Podstawową metodą weryfikacji i zatwierdzenia dokumentów projektowych jest analiza statyczna. Ocenie mogą przy tym podlegać nie tylko kolejno wytwarzane opisy analityczne, modele projektowe itp., ale także dokumenty planistyczne określa jące sposób prowadzenia procesu wytwórczego. W ten sposób, oprócz oceniania produktów działań wytwórczych, ocenie zostaje poddany sam proces wytwórczy. M otywacją leżącą u podstaw takiego postępowania jest „milcząco przyjmowane zało żenie, że dobry proces wytwórczy powinien doprowadzić do powstania dobrego produktu. Całość działań kontrolnych i ulepszających, podejmowanych w procesie
■ Koszt i czas wytwarzania oprogramowania skupiają się w procesie projekto wym - masowa produkcja raz stworzonego programu niemal nic nie kosztuje ani nie zajmuje czasu. " Projekty informatyczne są w dużym stopniu niepowtarzalne, a techniki pro jektowe są stosunkowo nowe i nie w pełni dojrzałe, czego wynikiem jest trudność oszacowania czasu i nakładów niezbędnych do realizacji projektu. ■ Wiedza z dziedziny zastosowania jest odległa od wiedzy informatycznej, z czego wynika trudność porozumienia między zamawiającym a wykonawcą.
1. W pro w ad zen ie
38
1.5. In ży n ieria opro g ram o w an ia
39
Te unikalne cechy oprogramowania prowadzą do dużej niepewności rezultatu projektu informatycznego; niepewności tym większej, im większy i bardziej nowator ski jest projekt. Miarą tej niepewności jest bardzo duża liczba projektów, których wyniki znacząco odbiegają od zamierzeń i oczekiwań.
tów i pozostaje w przybliżeniu stała. Przytoczone dane z jednej strony świadczą o niezbyt wysokiej skuteczności istniejących metod zarządzania i wytwarzania opro gramowania, z drugiej jednak dowodzą postępującego rozwoju dziedziny, która doj rzewa i wyciąga wnioski z popełnionych błędów.
Celem tego podrozdziału jest przedstawienie oceny stanu inżynierii oprogramo wania na świecie, określenie głównych czynników decydujących o sukcesie projektu i pokazanie na tym tle obrazu polskiego rynku IT (Information Technology).
Analiza charakteru realizowanych projektów informatycznych pokazuje, że są 1o przedsięwzięcia o dość różnej naturze. Wspólną ich cechą jest cel polegający na opracowaniu i wdrożeniu do eksploatacji oprogramowania, wykorzystywanego na stępnie w administracji, gospodarce lub w życiu codziennym. Różnice między nimi wynikają z różnego znaczenia przypisanego słowu „opracowanie”. W niektórych projektach opracowanie oznacza napisanie nowych programów, a w innych - połącze nie i dostosowanie do wymagań programów, które w całości lub w istotnej części zostały kupione gotowe. Podział rynku IT między różne rodzaje projektów oraz zakres wykorzystania różnych rodzajów metod podczas projektów polegających na tworzeniu nowego oprogramowania jest przedstawiony w tab. 1.1.
1 .5 .1 . R a p o rt C h a o s Systematyczne badania przebiegu i wyników projektów informatycznych, prowadzone w USA od ponad dziesięciu lat, są publikowane co dwa lata w formie raportów o znamiennym tytule „Chaos” [24]. M etoda budowania raportu polega na ankietowa niu kilku tysięcy kierowników największych projektów informatycznych i klasyfiko waniu rezultatów zgodnie z przyjętymi kryteriami. Raport dzieli wszystkie badane projekty na trzy kategorie. ■ Sukces - projekty ukończone w terminie i w ramach założonego budżetu. ■ Przekroczenie - projekty ukończone za cenę znacznego przekroczenia bu dżetu lub czasu wykonania albo ograniczenia pierwotnie zakładanej funkcjo nalności. ■ Porażka - projekty porzucone bez zakończenia. 100 %
—
90% —
Porażka
80% —
Tabela 1.1. Podział rynku projektów informatycznych (USA)
R ok b a d a n ia
O p r o g r a m o w a n ie n o w e
P r o j e k t y in te g ra to r.s k ie
2000
46%
54 %
2004
55%
45%
m e to d y s t r u k t u r a l n e
m e to d y o b ie k to w e
2000
72%
28%
2004
65%
35 %
70% — 60% — 50% —
Przekroczenie
40% _ 30% — 20% _ Sukces
10%-. 0%
—
1994
1996
1998
2000
2002
J 2004
2006
R ysunek 1.6. Zestaw ienie sukcesów i porażek projektów infolm atycznych (USA)
W yniki raportu (rys. 1.6) pokazują, że liczba pomyślnie zakończonych projektów nie przekracza obecnie jednej trzeciej wszystkich podjętych projektów. O ptymistycz nym akcentem jest fakt, że liczba ta system atycznie rośnie, w przeciwieństwie do liczby porażek, która w zbliżonej proporcji spada. Liczba projektów ukończonych z opóźnieniem lub nieoczekiwanie dużym kosztem sięga połowy wszystkich projek
Interesującą obserwacją jest porównanie zakresu stosowania metod struktural nych i obiektowych. Siłą metod strukturalnych jest duża liczba doświadczonych projektantów oraz dojrzałość technologii relacyjnych baz danych, które dominują na rynku systemów używanych w biznesie i administracji. Siłą metod obiektowych jest większa podatność na zmiany (konserwacja) oraz zalety obiektowych technologii komunikacyjnych wykorzystywanych przy budowie systemów rozproszonych. Przed stawione tu dane pokazują istniejącą obecnie przewagę metod strukturalnych. Prze waga ta jednak dość szybko maleje, częściowo w wyniku dominacji metod obiekto wych w programach nauczania informatyki w szkołach wyższych, a częściowo w wyniku nieustannego rozwoju i dojrzewania dostępnych technologii obiektowych. Ważnym celem badań prowadzonych przez autorów raportu było ustalenie listy najważniejszych czynników sprzyjających powodzeniu projektu. Ponieważ lista odzwierciedla doświadczenia kierowników projektu, więc wymienione na niej czyn niki odnoszą się w większym stopniu do organizacji przedsięwzięcia niż do konkret
I . W prow adzenie
40
nych metod używanych podczas tworzenia oprogramowania. Zawartość listy zmienia się nieznacznie w poszczególnych wydaniach raportu, w ślad za zmianami zachodzą cymi na rynku 1T. W 2004 r. na liście pięciu najważniejszych czynników sukcesu znalazły się: 1. 2. 3. 4. 5.
Zaangażowanie ze strony użytkownika. W sparcie ze strony zarządu firmy. Dobrze określone cele biznesowe. Ograniczony zakres projektu. Zwinne procesy wytwórcze.
Znaczenie tych czynników dla powodzenia projektu można wyjaśnić następu jąco. Duże zaangażowanie użytkownika gwarantuje dobre rozpoznanie jego wymagań oraz bieżącą kontrolę zgodności budowanego systemu z t potrzebami. Zmniejsza to ryzyko zbudowania systemu, który nie zostanie zatwierdzony przez użytkownika i będzie wymagał gruntownej przebudowy natychmiast po zakończeniu procesu wy twórczego. W arto zauważyć, że udział użytkownika jest najmniejszy w procesie kaskadowym, a największy w procesach zwinnych. W sparcie ze strony zarządu zapewnia dostępność potrzebnych zasobów oraz śpiewne rozwiązywanie problemów. Dobrze określone cele biznesowe oznaczają z jednej strony dobrze określone wymagania, a z drugiej - brak nadmiernych, często nierealistycznych oczekiwań użytkownika. Wszystkie te warunki łatwiej spełnić w niezbyt dużym projekcie (czwarty czynnik na liście), dla którego łatwiej oszacować potrzebne zasoby i łatwiej ocenić wyniki. Zgodnie z tym zaleceniem lepiej jest po dzielić budowę wielkiego systemu na kilka mniejszych projektów, niż budować całość w jednym przedsięwzięciu. Tę wskazówkę można wcielić w życie w każdym rodzaju procesu wytwórczego. W arto jednak zauważyć, że podział na niewielkie wydania jest w procesach zwinnych (piąty czynnik na liście) normalną praktyką.
1 .5 .2 . P o lski ry n e k IT Polski rynek informatyczny nie jest tak duży jak amerykański, jednak w ostatnim dziesięcioleciu przeżywa burzliwy rozwój wywołany zmianą ustroju gospodarczego i przystąpieniem Polski do Unii Europejskiej. Potrzeb^ dostosowania się do nowej rzeczywistości wymusiła budowę wielu dużych systempw informatycznych obsługu jących obywateli, przedsiębiorstwa i administrację publiczną. Przebieg procesu wytwarzania niektórych z tych systemów był przedmiotem oceny zarówno ze strony zleceniodawców, jak i różnych instytucji kontrolnych. Treść tego punktu odzwierciedla obserwacje dotyczące metod i technologii wytwarzania oprogramowania, dokonane podczas oceny różnych faz opracowania sześciu takich systemów: kompleksowego systemu informatycznego Zakładu Ubezpieczeń Społecz
ni .5. Inżynieria o p ro g ram o w an ia
41
nycli, dwóch systemów do obsługi dopłat bezpośrednich i zakupów interwencyjnych w ramach wspólnej polityki rolnej UE, systemu obsługującego komercyjny bank średniej wielkości oraz nieco mniejszych systemów przeznaczonych do obsługi wybo rów lokalnych oraz rozdziału i kontroli ruchu przesyłek pocztowych na terenie kraju [21, 23, 22). Wytwórcami oprogramowania dla tych systemów były duże krajowe firmy informatyczne lub polskie oddziały renomowanych firm zagranicznych. Tech n o lo g ie stosowane przy tworzeniu oprogramowania należą do wiodących technologii dostępnych w przemyśle informatycznym. Mimo to nie wszystkie budowane systemy zostały ukończone zgodnie z założeniami, tzn. w granicach zaplanowanego czasu i budżetu. Wszystkie wymienione systemy obejmują swym zasięgiem obszar całego kraju i wpływają na warunki życia milionów ludzi. W szystkie też należą do kategorii syste mów dużych lub bardzo dużych. Parametry określające charakter i wielkość tych systemów są podane w tab. 1.2. T abela 1.2. A trybuty charakteryzujące rozm iar omawianych system ów informatycznych
L ic z b a : In d y w id u a ln y c h kom P rzetw arzan y ch
S y s te m
S y s te m
Zakupy
S y s te m
S y s te m
O b s łu g a
o b s łu g i
d o p ła t
in te r w e n
bankow y
p o c z to w y
w y b o ró w '
ZUS
r o ln y c h
c y jn e
17 0 0 0 0 0 0
2 300 000
800 000
500 000
300 000 000
12 0 0 0 0 0 0
1 000 000
36 0 0 0 0 0 0
540 000 0 00'
23 0 0 0
8 500
500
800
2 500
6 000
300
3 30
17
22
17
5 500
d o k u m e n tó w (ro c z n ie ) U ż y tk o w n ik ó w M iejsc u ż y tk o w a n ia I 50 0 0 0 0 p rz e sy łe k d z ie n n ie
Ostateczne wyniki realizacji wszystkich sześciu projektów doskonale odpowia dają statystykom raportu Chaos. Dwa systemy zostały zbudowane w ramach założo nego czasu i budżetu. W trzech przypadkach koszty i czas zostały przekroczone, jednak zasadnicze elementy systemów zostały wdrożone w czasie, który umożliwił realizację zadań i osiągnięcie założonych celów. Jeden system zawiódł kompletnie i nie byl stanie działać w chwili, gdy byl potrzebny. Zarówno charakter projektu, jak procesy i metody tworzenia oprogramowania, użyte w różnych projektach, różniły się między sobą istotnie (tab. 1.3). W czterech przypadkach oprogramowanie było budowane od nowa, w dwóch pozostałych domi nowały prace integratorskie z wykorzystaniem gotowych komponentów - ogólnodo stępnych lub pochodzących z innych projektów. Oprogramowanie budowane ocl nowa było tworzone w dwu przypadkach z użyciem metod obiektowych, w jednym przy
1. W pro w ad zen ie
42
padku dominowały metody strukturalne, a jeden projekt powstał z wykorzystaniem obydwu rodzajów metod. T abela 1.3. Procesy i metody użyte w procesach wytwórczych
Metody strukturalne
Metody obiektowe
Projekt integratorski
2,5*
0,5*
1
Proces kaskadowy
i
Proces iteraeyjny
J.6. H istoria i kierunki rozw oju
43
tów, jest przedstawiony na rys. 1.7. Pomiar opierał się na zliczaniu zmienionych i niezmienionych plików zawierających klasy programu po każdej z siedmiu iteracji procesu. Udział kodu przechodzącego bez zmian do następnej iteracji waha się od kilkunastu procent w pierwszej iteracji do ponad 80% w ostatniej. Bardziej optymistyczny obraz zmian pokazuje rys. 1.8, zgodnie z którym ogrom na większość plików wytworzonych w każdej iteracji była zachowana - ze zmianami _ w finalnym kodzie oprogramowania. Ponieważ treścią plików były klasy programu, można stąd wnioskować, że architektura oprogramowania, wyrażona przez klasy i iclt powiązania, pozostawała - od drugiej iteracji - bardzo stabilnym elementem projektu.
1
Proces żywiołowy
100%
* W jednym przypadku połączono analizę obiektową z projektem strukturalnym
90% 80%
Porównując zastosowane w rozważanych projektach procesy tworzenia oprogra mowania, trzeba podkreślić, że użycie procesuj kaskadowego nie musiało oznaczać budowy i wdrożenia całego systemu w ciągu jednej sekwencji faz. Przeciwnie, bu dowa i wdrażanie oprogramowania następowało zazwyczaj przyrostowo, dzięki de kompozycji całości na moduły o dobrze określonej funkcjonalności łub terytorialnym zasięgu działania, budowane i wdrażane sukcesywnie w zaplanowanej kolejności. Budowa i wdrożenie następnego modułu nie pociągało za sobą konieczności poważ nego modyfikowania modułów już istniejących. Zwornikiem całości systemu była w tych przypadkach wspólna baza danych lub wspólny system komunikacji modułów.
70% 60% 50% 40% 30%
SÍ JB.m
20%
10% 0%
IV
V
VI
N um er Iteracji
Rysunek 1.8. Procent plików zachow anych - ze zmianami - w finalnej wersji oprogramowania 100%
-
90%
—
80%
-
—
—
.........— ......— ....- ------- ------------- ---- —
-
........
- -
------------
70% - ................-
r...
50% ................-......!
j
40% -.............. — ■
j'j
i
■ ! i
!
i'---------
;■..........................................
:
|
:
I
■
!
■-
-
30% ..........
20%
........
10% no/
„
i“ ; . _ i
^—
:
I
1__ i
ii
i - _1
HI
'
IV
_ i
.1 - -
V
’ 1..... ........
VI \
ft
Proces tworzenia oprogramowania powstającego w projektach integralorskich opiera! się na wykorzystaniu analizy luk, wykonywanej zwykle w kilku krokach. Pierwszym krokiem było ustalenie i zapisanie wymagań w formie listy wymaganych usług, definiowanych przez określenie wszystkich wymaganych funkcji i jednostek danych. W drugim kroku badano możliwość realizacji tych usług przez dostępne na rynku komponenty. Wynikiem analizy była lista luk do wypełnienia. Trzeci krok polegał na wybraniu najodpowiedniejszych komponentów i implementacji kodu zapełniającego luki. W ostatnim kroku następowała konfiguracja oraz integracja wybranych komponentów z wykonanym dodatkowym kodem.
N um er iteracji
Rysunek 1.7. Procent kodu zachowanego bez modyfikacji w następnej iteracji procesu wytwórczego
1.6. Zupełnie inaczej przebiegało tworzenie oprogramowania w procesie iteracyjnym, w którym każda następna iteracja rozszerzała zakres funkcjonalny tych samych kom ponentów programu. Integracja nowo wytworzonego kodu programu z kodem już istniejącym wymagała zawsze pewnej modyfikacji wcześniej wytworzonego kodu. Zakres tej modyfikacji, zmierzony podczas realizacji jednego z opisywanych projek
H is to ria i k ie ru n k i ro z w o ju
Historyczne korzenie informatyki sięgają starożytności, jednak pierwsza programo wana maszyna licząca Z3 została zbudowana z przekaźników przez Konrada Zuse dopiero w i 941 r. Pierwszym komputerem elektronicznym była lampowa maszyna ENIAC (Electronic Nurnerical Integrator A nd Calculator), uruchomiona na Uniwer sytecie Pensylwanii w 1946 r. W ażną datą jest także rok 1945, w którym John von
44
1. W prow adzenie
N eum ana ogłosił aktualny do dziś raport opisujący koncepcję budowy i działania komputera [222]. W początkowym okresie rozwoju podstawowe problemy projektowe i eksploata cyjne były związane z niedostatkami sprzętu. W tym okresie komputery obywały się bez systemów operacyjnych, a programy były pisane w języku maszynowym. Mały wymiar rozwiązywanych problemów nie wymagał żadnych sformalizowanych proce dur projektowych, a opracowanie programów było bardziej dziedziną sztuki niż inży nierii. Potrzeba oddzielenia algorytmu przetwarzania, związanego z konkretnym zastosowaniem, od cech sprzętu, niezależnych od zastosowania, doprowadziła jednak wkrótce do opracowania algorytmicznych języków programowania [216] oraz wyod rębnienia systemu operacyjnego. Obie te zmiany oderwały proces opracowania pro gramów od osobliwości sprzętu. Technologie półprzewodnikowe, wprowadzone w latach sześćdziesiątych, przy niosły spadek rozmiarów i cen sprzętu, połączony ze znaczącym wzrostem jego moż liwości. Spowodowało to szybki wzrost zastosowań komputerów w nauce, wojsku i gospodarce. Rosnącym potrzebom i możliwościom sprzętu nie towarzyszył w ystar czający wzrost możliwości oprogramowania. Pod koniec lat sześćdziesiątych okazało się, że rozwój systemów komputerowych jest ograniczony przez możliwości wytwa rzania oprogramowania. Stwierdził to raport [221] z konferencji zatytułowanej S oft ware E ngineering, zorganizowanej przez NATO w 1968 r. Tę datę przyjmuje się umownie za datę narodzin inżynierii oprogramowania. Opanowanie produkcji układów scalonych, na początku lat siedemdziesiątych, przyniosło dalszy spadek cen oraz wzrost niezawodności i wydajności sprzętu ponad potrzeby przeciętnego użytkownika, co dało impuls do rozwoju systemów wielozada niowych. Konsole graficzne otworzyły nowe m ożliw ości'dialogu człowieka z kom puterem, a rozwój transmisji szeregowej umożliwił budowę sieci komputerowych. Rozpowszechnienie mikrokomputerów w latach osiemdziesiątych przyniosło zatarcie granicy między inteligentnym procesorem a urządzeniami zewnętrznymi. Sieci zawie rające komputery, inteligentne czujniki i elementy wykonawcze, programowane sterowniki, inteligentne terminale i urządzenia komunikacyjne stworzyły rrtożliwości rozproszonego zbierania, gromadzenia i przetwarzania^ danych. W ywołało to kolejną falę wzrostu zastosowania narzędzi informatycznych] w gospodarce, administracji, wojskowości i w życiu codziennym. Przybliżona chronologia tych zdarzeń jest poka zana w tab. 1.4. ( Równolegle z rozwojem sprzętu postępował rozwój narzędzi programowych. Na rynku pojawiły się rozproszone systemy operacyjne dla lokalnych sieci komputerowych, relacyjne bazy danych oraz języki obiektowe. Mimo tych wysiłków rozwój oprogramo wania nie nadążał za lawinowo rosnącym zapotrzebowaniem. Systematycznie wzrastało zapotrzebowanie na lepsze i wydajniejsze metody wytwarzania oprogramowania.
1.6. H istoria i kierunki rozw oju
45
Tabela 1.4. C hronologia rozwoju technologii informatycznych
K ok 1950
S p rzę t K o m p u te ry la m p o w e
O p r o g r a m o w a n ie B ra k s y ste m u o p e ra c y jn e g o
M e to d y M e to d y in tu ic y jn e
J ę z y k a se m b le ra
I960
1970
K o m p u te ry z c e n tra liz o w a n e
J ę z y k i s tru k tu ra ln e
T e rm in a le te k sto w e
S y ste m y o p e ra c y jn e
M in ik o m p u te ry
S y s te m y w ie lo z a d a n io w e
P ro je k to w a n ie s tru k tu ra ln e
S y s te m y w ie lo p ro c e so ro w e
P a k ie ty a p lik a c y jn e
S y s te m y C A S E
T e rm in a le g ra fic z n e
P rz y ja z n y in te rfe js g ra fic z n y
S ieci k o m p u te ro w e
A n a liz a s tru k tu ra ln a R e la c y jn e b a zy d a n y c h
1980
P r o g ra m o w a n ie s tru k tu ra ln e
M ik ro k o m p u te ry
Ję z y k i o b ie k to w e
In te lig e n tn e te rm in a le
S y s te m y o k ie n k o w e
K o m p u te ry o s o b iste
S y s te m y sie c io w e
In ż y n ie ria w y m a g ań P ro g ra m o w a n ie o b ie k to w e P ro je k to w a n ie o b ie k to w e
1990
W a rstw a m id d le w a re
A n a liz a o b ie k to w a
U k ła d y sc a lo n e n a z a m ó w ie n ie
P rz e g lą d a rk i sie c io w e
Z in te g ro w a n e s y ste m y C A S E
R o zw ó j sieci lo k a ln y c h
J ę z y k i te c h n o lo g ia J a v a
Pow szechny d ostęp d o Internetu
A rc h ite k tu ra S O A
Język U M L
O lb rz y m i w z ro st e la sty c z n o śc i
O b ie k to w e b a zy d a n y c h
T e c h n o lo g ie X M L
i m o c y o b lic z e n io w e j sp rz ę tu
P la tfo rm y J a v a , .N et, p h p , ...
M e to d y z w in n e
M e to d y k a R U P 2000
Pierwsze prace nad metodami i narzędziami wspierającymi tworzenie oprogra mowania, podjęto jeszcze w latach pięćdziesiątych, były poświęcone dyscyplinie programowania. Opracowane w tym okresie zasady programowania strukturalnego dostarczyły wskazówek dotyczących kodowania stosunkowo niewielkich grup in strukcji, tworzących regularne konstrukcje sekwencji, alternatywy i iteracji. W tym samym czasie powstała notacja BNF (Baclats-Naur Form ) używana do opisywania sldadni języków programowania [215], Najważniejszym rezultatem tych prac było opracowanie strukturalnych języków programowania, takich jak Fortran, Algol, Cobol, Pascal i C. Dalsze badania podjęły próbę zdefiniowania semantyki programów [218, 219] oraz wskazały stopniową dekompozycję problemu na prostsze fragmenty jako podstawowy środek dochodzenia do finalnej struktury programu [223, 214, 212, 213]. Ta odnowiona wersja starej zasady „dziel i rządź” nie rozwiązała jednak żadnych problemów projekto wych z powodu niemożności wskazania jasnych kryteriów dekompozycji i oceny jako ści programu. Trwałą spuścizną tego podejścia okazał się jednak model hierarchii funkcji, wykorzystywany z powodzeniem we wczesnych etapach analizy.
46
I . W p ro w ad zen ie
Traktowanie programu jako zapisu algorytmu, otrzymywanego w drodze stop niowej dekompozycji problemu aż do uzyskania sekwencji instrukcji języka progra mowania, stworzyło nadzieję na możliwość sformalizowania tego procesu i matema tycznego udowodnienia jego poprawności [224, 231]. Podstawową zaletą takiego podejścia stałoby się wyeliminowanie potrzeby testowania i zagwarantowanie po prawności programu. Szeroki rozgłos zyskała opracowana w wiedeńskim laboratorium firmy IBM metoda formalnego konstruowania programów [228, 229] znana pod akronimem VDM (Vienna Development Method) oraz nieco późniejsza metoda for malnej specyfikacji oprogramowania Z [232], Praktyczne wykorzystanie metod for malnych napotkało jednak trudności wynikające z braku dobrej metody zatwierdzania formalnej specyfikacji wymagań przez ekspertów w dziedzinie zastosowania (którzy nie są matematykami) oraz wysokiej pracochłonności i kosztu stosowania. Te i inne problemy sprawiły, żc formalne metody wytwarzania nic są stosowane w projektach komercyjnych, choć znajdują zastosowanie w tych dziedzinach, w których mniej liczą się koszty, a dominującym wymaganiem jest -.pewność działania (por. podrozdział 10.4). Milowym krokiem rozwoju metod tworzenia oprogramowania stal się pomysł rozdzielenia analizy problemu od projektu programu i wykorzystania grafu przepływu danych jako modelu analitycznego, przekształcanego następnie w schemat struktury programu [50, 46, 40, 48, 44, 42]. Trwałą wartością tego podejścia stało się zdefinio wanie inżynierskich kryteriów jakości struktury programu, promujących rozwiązania modularne, zbudowane z modułów wewnętrznie spójnych (cohesion) i połączonych stosunkowo słabymi więzami (coupling). W tym samym czasie powstała koncepcja a w ślad za nią technologia - relacyjnych baz danych [211, 209, 210]. Modele grafu przepływu danych, struktury programu oraz diagramu encji stały się podstawowymi narzędziami koncepcyjnymi szybko dojrzewającej metodyki strukturalnej. Wraz z rozwojiarrrnctod pojawiły się komputerowe systemy wspomagające wytwarzanie oprogra mowania (Computer Aided Software Engineering - CASE). Metody strukturalne nie zdołały jednak rozwiązać kluczowego dla efektywności procesów wytwórczych problemu wielokrotnego użycia tych samych elementów w różnych projektach programistycznych (reusability). Pierwszą praktyczną realizacją tego pomysłu stały się biblioteki podprogramów standardowych, udostępniane przez kompilatory języków programowania. Rozszerzenie dej idei na większe elementy okazało się jednak trudne, gdyż wszystkie większe elementy oprogramowania muszą zawierać nie tylko programy, ale i dane określające kontekst ich działania. Dostrzeże nie tego faktu doprowadziło do powstania koncepcji programowania obiektowego, zgodnie z którą podstawowymi jednostkam i programu nie są podprogramy (funkcje), lecz obiekty zawierające zarówno programy, jak i dane wystarczające do ich wykona nia. Pierwszym efektem prac w tym kierunku stało się opracowanie szeregu języków obiektowych, takich jak Smalltalk [220], Eiffel [70], C++, Delphi i Java.
J,.6. H istoria i kierunki rozw oju
47
Sukces i rosnąca popularność języków obiektowych pociągnęły za sobą rozwój metod modelowania struktury i współpracy obiektów oraz doprowadziły do powstania inetod projektowania i analizy opartych na tym paradygmacie [75, 64, 74, 66], Prze łomowym momentem rozwoju okazało się ukształtowanie języka modelowania UML (.Unified Mode ling Language) [76, 77] oraz opracowanie procesu i metodyki RUP (Rational Unified Process) [13, 19]. Równolegle z rozwojem metod obiektowych na rynku pojawiły się narzędzia technologiczne. M ożna do nich zaliczyć biblioteki klas obiektów przeznaczonych do wielokrotnego użycia, serwery aplikacyjne tworzące uniwersalne środowisko wykonawcze rozproszonych komponentów (obiektów) oraz sypiemy wspomagające projektowanie (CASE). Rozwojowi metod analizy i projektowania oprogramowania towarzyszył rozwój pro cesów wytwórczych. Początkowo na rynku tworzenia oprogramowania dominował wzo rowany na innych działach inżynierii proces kaskadowy, opisany po raz pierwszy w kry tycznej pracy 120], Już wtedy dostrzeżono główne wady tego modelu, którymi są: późna weryfikacja decyzji projektowych, następująca dopiero podczas testowania gotowych programów, oraz brak mechanizmu uwzględniania zmian. Oprócz wad proces kaskadowy ma również szereg zalet i do dziś jest często skutecznie stosowany, zwłaszcza w projektach wykonywanych w stabilnym otoczeniu o dobrze ustalonych wymaganiach. Ewolucja gospodarki rynkowej i postępująca globalizacja życia doprowadziły do przyspieszenia tempa zmian, faworyzującego procesy wytwórcze zdolne do szybkiego reagowania na zmiany. Odpowiedzią inżynierii oprogramowania na to wyzwanie stały się procesy iteracyjne, zakładające powtarzalny rytm pracy, połączony z powtarzającą się oceną rezultatów i kroczącym planowaniem dalszych działań w odpowiedzi na zmieniają ce się uwarunkowania projektu. Dużą rolę w rozwoju procesów iteracyjnych odegrał model spiralny [16], opisujący powtarzalny cykl wytwarzania kolejnych dokumentów projektowych - od specyfikacji wymagań aż do gotowego oprogramowania (rys. 1.9). Wykonanie każdego cyklu obejmuje zawsze cztery rodzaje działań: wyznaczenie celów i wariantów wykonania, ocenę ryzyka i wybranie najlepszego wariantu, wytworzenie produktu w sposób minimalizujący ryzyko oraz zaplanowanie następnej iteracji. 1. W yznaczenie celów, w ariantów i ograniczeń
4. Zaplanow anie kolejne) fazy
____
2. O cena w ariantów , określenie i usunięcie obszarów ryzyka
3. W ytw orzenie i weryfikacja kolejnego produktu
Rysunek 1.9. Model spiralny procesu tworzenia oprogram ow ania
1. W pro w ad zen ie
48
1.6. i j _
Uznanie kluczowej roli iteracyjnego planowania w odpowiedzi na zmiany do prowadziło nieco później do ukształtowania procesu RUP oraz procesów zwinnych |139, 138, 132], W arunkiem skutecznego stosowania procesów, które dopuszczają możliwość zmian, jest posiadanie takich metod analitycznych i projektowych, które tworzą artefakty podatne na zmiany. Dlatego obydwa typy procesów" są w praktyce stosowane przede wszystkim w powiązaniu z wykorzystaniem metod obiektowych. Inną próbą odpowiedzi na potrzebę szybkiego wytwarzania nowych produktów programowych są procesy wytwórcze oparte na wykorzystaniu gotowych komponen tów (Commercial, ojf-the-shelf - COTS). Wynikiem tego nurtu prac stało się zwięk szenie roli procesów komponentowych |1 1]. Dalszym krokiem na drodze do budowy oprogram owania przez składanie go z gotowych elementów są metody i architektury usługowe (Service-Oriented Architecture - SOA), zakładające komponowanie funk cjonalności oprogram owania z usług dostarczanych przez zewnętrznych dostawców | I2J. Zasadnicza różnica między koncepcją tworzenia oprogramowania aplikacyjnego z gotowych komponentów a koncepcją tworzenia go z usług wynika z prawa własno ści składników. Komponenty są kupowane od wytwórcy w określonej postaci i od tej chwili stają się własnością wytwórcy oprogramowania aplikacyjnego. Żaden szczegół implementacji komponentów nie może ulec zmianie bez jego woli. Usługi pozostają przez cały czas własnością dostawcy, który administruje ich wykonaniem i może w dowolnym momencie zmienić sposób ich implementacji i zasady funkcjonowania. Stwarza to zupełnie nową sytuację dla wytwórcy oprogramowania aplikacyjnego. Metoda
Rysunek 1.10. Elementy procesu i metody [ 17 ] l Procesy tworzenia oprogramowania określają rodzaj i kolejność wykonania działań. Metody - strukturalne, obiektowe lub formalne - narzucają sposób wykona nia tych działań oraz rodzaj tworzonych w ich wyniku modeli (produktów pracy). Metoda może też określać role ludzi biorących udział w projekcie oraz definiować ich zadania. Elastyczność obiektowych metod tworzenia oprogramowania, wyrażająca się zdolnością efektywnego działania w ramach różnych procesów projektowych, stwarza możliwość projektowania różnych kombinacji tych czynników. Pomocą w projekto waniu sposobu prowadzenia konkretnego projektu są narzędzia do projektowania
U
Historia i kierunki rozwoju ---------------------------------------------------—
49
metod, rozwijające się głównie w kontekście procesu i metodyki RUP [17], Perspek tywę oraz wzajemne relacje elementów procesu i metody dobrze opisuje model archi tektury UMA (Unified M ethod Archilecture), przedstawiony schematycznie na rys. 1.10. Połączenie wybranych składników procesu i treści metody definiuje konkretny i dobrze określony sposób prowadzenia prac wytwórczych.
2.1. K lasyfikacja w ym agań
2.1.
Inżynieria w ym agań
Określenie wymagań, jakie musi spełniać oprogramowanie, jest tym miejscem pro jektu, w którym najbardziej i najwyraźniej stykają się interesy wszystkich jego udzia łowców. Klientów, czyli zarządów firm, które finansują projekt w nadziei, że przynie sie on ich firmom wymierne korzyści biznesowe. Użytkowników, którzy będą praco wać z nowym systemem i którzy liczą, że ułatwi on im wykonywanie codziennych zadań. Kierownika projektu, który musi zaplanować i przeprowadzić budowę opro gramowania. Deweloperów, którym wymagania mówią, co mają zbudować. Testerów, dla których wymagania są wzorcem poprawnego działania systemu. Sprzedawców, którzy muszą znaleźć i przygotować odbiorców. W ymagania formułowane przez, lub dla, różnych udziałowców projektu różnią się przeznaczeniem, językiem i poziomem szczegółowości. Dlatego istnieje wiele postaci wymagań, tworzonych w różnych okresach, podczas przygotowania i wykona nia projektu. Co więcej, raz określone wymagania nie są niezmienne. Zmiany potrzeb biznesowych klientów, a także zmiany dostępnych technologii wytwarzania oprogra mowania mogą prowadzić do zmiany wymagań. Ta różnorodność i długotrwałość procesu określania wymagań stwarza niebezpieczeństwo popełnienia błędów, których wynikiem będzie zbudowanie systemu niespełniającego oczekiwań klientów i użyt kowników. Poprawienie tych błędów może wym agaćjistotnej przebudowy systemu, pociągającej za sobą ogromne koszty. \ Z tych powodów wymagania muszą być staranni! dokumentowane, uzgadniane i zatwierdzane. Dotyczy to zarówno oryginalnych wymagań, definiowanych na starcie projektu, jak i wszelkich późniejszych zmian, które też muszą być dokładnie kontro lowane, uzgadniane i zatwierdzane. W szystkie istniejące wersje wymagań muszą być poddane rygorystycznym procedurom kontroli zmian.
51
K la s y fik a c ja w y m a g a ń
Wymaganiem jest: każda właściwość oprogramowania potrzebna użytkownikowi do zaspokojenia jego potrzeb. Wymaganiem jest każda właściwość oprogramowania niezbędna do zatwierdzenia gotowego produktu. Wymaganiem jest każdy zapis do kumentujący właściwości określone w dwóch poprzednich zdaniach. Przytoczone definicje, zaczerpnięte ze słownika inżynierii oprogramowania [174], wskazują naj ważniejsze koncepcje inżynierii wymagań. Po pierwsze, istnieje wiele postaci wyma gań, które muszą odzwierciedlać biznesowe potrzeby użytkowników, sformułowane vy zrozumiałym dla nich języku, oraz wyrażać techniczne ograniczenia przeznaczone dla projektantów oprogramowania. Po drugie, wymagania muszą określać wszystkie rodzaje właściwości potrzebnych użytkownikom i badanych podczas odbioru pro duktu. Po trzecie, wymagania muszą być udokumentowane. Określenie wymagań rysuje się więc jako proces budowania i dokumentowania kolejnych postaci wymagań. Na różnych etapach tego procesu mogą wystąpić różne zapisy, które mogą być uważane za dokumentację wymagań stawianych oprogramo waniu na danym etapie ich definiowania. Aby uporządkować sposób widzenia wyma gań, można podzielić wymagania stawiane oprogramowaniu pod względem zakresu, którego dotyczą, oraz pod względem języka i poziomu szczegółowości, na jakim są zdefiniowane. Oba te podziały są ważne, gdyż pozwalają uściślić problem oraz narzu cić wspólne i jednolite rozumienie wymagań.
2.1.1. Z a k re s w y m ag a ń Wymagania stawiane oprogramowaniu nie są jednorodne i mogą dotyczyć jego róż nych właściwości. Ze względu na inny charakter i sposób opisu tradycyjnie dzieli się wymagania na dwie kategorie: wymagania funkcjonalne (fitncUonal reąuireimmts), które określają zestaw funkcji realizowanych przez oprogramowanie, i wymagania niefunkcjonalne1 (non-functional reąuirenients), które określają jakość i granice, w jakich te funkcje mają być realizowane. Istnieją także wymagania, które trudno jednoznacznie umieścić w ramach tego podziału, np. wymaganie zgodności działania systemu z obowiązującym prawem - trudno na razie powiedzieć, czy wymaga to do dania pewnych funkcji czy dostosowania innych właściwości programu. Dlatego cza sem wyróżnia się trzecią kategorię, którą nazwiemy tu wymaganiami zgodności (■compliance reąuiremenls). Wszystkie kategorie wymagań są ważne i wszystkie mu szą być zdefiniowane i uzgodnione przed przystąpieniem do budowy oprogramowania.
1 Puryśei językow i wolą nazwę: w ymagania pozafunkcjonalne. Jednak przemysł informatyczny mówi o wymaganiach niefunkcjonalnych i dlatego ten właśnie termin je st używany w tej książce.
2. In żynieria w ym agań
52
,2.1. K lasyfikacja w ym agań
53
W y m a g a n ia fu n k c jo n a ln e
W y m a g a n ia n ie fu n k c jo n a ln e
W iększość pytań dotyczących systemu wspierającego działanie banku, jakie postawi liśmy na początku podrozdziału 1.2, odnosi się do funkcji wykonywanych przez oprogramowanie tego systemu. Lista tycli funkcji, określająca wymagania funkcjo nalne, może zaczynać się następująco:
Wskazanie funkcji oprogramowania nie określa wszystkich cech istotnych dla przy szłego użytkownika. Różne funkcje mogą być wykonywane szybciej lub wolniej, liczba przetwarzanych kont może być duża lub mala, wznowienie działania po awarii może zajmować kilka godzin lub kilka dni itd. Rzeczywista przydatność systemu zależy przeważnie od jego wydajności, niezawodności, bezpieczeństwa i wygody używania. W wielu zastosowaniach ważna jest również przenośność i łatwość kon serwacji. W szystkie te cechy mogą mieć mniejsze lub większe znaczenie w różnych dziedzinach zastosowania. Zbyt wolna reakcja programu sterującego instalacją prze mysłową może być powodem katastrofy zagrażającej życiu lub zdrowiu ludzi; po wolne działanie edytora tekstu co najwyżej zirytuje użytkownika. Te wymagania, które w danym zastosowaniu są ważne, muszą zostać dokładnie określone i zapisane.
“ system powinien prowadzić indywidualne konta klientów banku, ■ system powinien księgować wszystkie wpłaty i wypłaty na koncie klienta, ■ system powinien umożliwiać właścicielowi konta wykonanie przelewu na dowolny inny rachunek bankowy, B system powinien przechowywać historię wszystkich operacji wykonanych na koncie, B Każdy punkt listy podaje jedną, dość dobrze określoną funkcję. Cała lista opisuje wymaganą funkcjonalność przyszłego systemu. Zwróćmy jednak uwagę, że przytoczony opis wymagań jest dość zgrubny i nie wyjaśnia wielu istotnych szczegółów. W przypadku pierwszej z wymienionych wyżej funkcji (prowadzenie kont) nic wiadomo, na przykład, czy klientami banku będą osoby fizyczne, firmy czy jedne i drugie? Jakie dane identyfikacyjne klienta mają być przechowywane w systemie? Czy po zmianie nazwiska lub nazwy firmy trzeba będzie zamknąć stare konto i otworzyć nowe, czy też można zachować konto, zmieniając jedynie opis właściciela? Czy można mieć konta w różnych walutach, a jeśli tak, to w jakich? Lista wariantów jest długa i nie jest oczywiste, jak dokładnie trzeba tę funkcję opisać. Nie ma jednoznacznej odpowiedzi na tak postawione pytanie. W różnych fazach opracowania oprogramowania opisuje się funkcje na różnych poziomach szczegóło wości. Na początku, w chwili podpisania umowy, opisuje się funkcjonalność systemu w dość ogólnej postaci usług świadczonych przez oprogramowanie na rzecz użytkow nika. Później, w wyniku analizy, dochodzi się do opisania wszystkich funkcji, jakie występują w menu programu. A całkiem dokładny opis sposobu realizacji Wszystkich funkcji znajdziemy dopiero w.kodzie programu. Definiując wymagania, trzeba zwrócić uwagę, aby nadmiarem szczegółów nie narzucić przedwcześnie sposobu implementacji. Na przykład, wymaganie: „system powinien chronologicznie pam iętać wszystkie wykonanJ transakcje i wyświetlać je na żądanie użytkownika" jest niepoprawne, gdyż narzuca sposób zorganizowania archi wum operacji (pamiętanie w chronologicznej kolejności czasu wykonania). Tym, czego naprawdę żądamy, jest chronologiczny porządek wyświetlania, a decyzja, czy prowadzić archiwum chronologicznie, czy sortować transakcje przed wyświetleniem, powinna pozostać w gestii projektanta.
Zdefiniowanie wymagań niefunkcjonalnych nie jest łatwe. Nie wystarczy zażą dać po prostu wysokiej wydajności systemu. Takie sformułowanie doprowadzi tylko do sporów podczas odbioru systemu, gdyż rozróżnienie wydajności wysokiej i niskiej jest całkowicie subiektywne. Aby zobiektywizować ocenę, trzeba zapisać te wymaga nia w postaci ilościowej, podając mierzalne wartości istotnych w danym zastosowaniu parametrów. Lista wymagań niefunkcjonalnych dla oprogramowania banku może więc zaczynać się następująco: H system powinien obsługiwać nie mniej niż 300 000 kont klientów; B średni czas wykonania transakcji na koncie klienta nie powinien przekroczyć 2 ms, a żadna transakcja nie powinna trwać dłużej niż 10 ms; ■ maksymalny czas niesprawności systemu po awarii nie może przekraczać 8 godzin; ■ system powinien gwarantować prawidłowe zachowanie stanu kont klientów pomimo awarii bazy danych; B Część przytoczonych wymagań niefunkcjonalnych dotyczy nie tylko oprogra mowania, ale także sprzętu, na którym to oprogramowanie działa. Na przykład, czas wykonania transakcji zależy nie tylko od sposobu napisania programu, ale także od szybkości komputera; częstość i zasięg awarii zależą nie tylko od odporności pro gramu na błędy, ale także od awaryjności urządzeń itd. W ymagania niefunkcjonalne określają więc na ogól pożądane właściwości całego systemu. Tylko niektóre z nich, np. wymaganie zachowania stanu kont po awarii, mogą być spełnione wyłącznie przy użyciu środków programowych.
2. In żynieria w ym agań
54
2.1. K lasyfikacja w ym agań
55
W y m a g a n ia z g o d n o ś c i Oprogramowanie, które wspiera działania użytkowników w pewnej dziedzinie zasto sowania, powinno to robić w zgodzie z regulacjami prawnymi, standardami i zwy czajami panującymi w tej dziedzinie. Na przykład: ■ oprogramowanie systemu IACS obliczające wysokość dopłat w ramach wspólnej polityki rolnej UE musi to robić zgodnie z obowiązującym ustawo dawstwem krajowym i rozporządzeniami unijnymi; ■ system wspierający działanie banku gromadzi dane identyfikacyjne klientów i musi wykonywać tę funkcję zgodnie z wymogami ustawy o ochronie danych osobowych; ■ oprogramowanie do zarządzania siecią gazociągów, które m.in. oblicza prze pływy gazu w różnych odcinkach gazociągu, musi uwzględniać przyjęte w branży sposoby obliczania i pomiaru takich przepływów w rurach o róż nych kształtach i przekrojach. W szystkie te wymagania muszą być uwzględnione przy opracowaniu oprogra mowania. W pierwszym przykładzie zgodność z normami prawa jest wręcz głównym rodzajem wymagań. Rolą użytkownika jest sformułowanie wymagań zgodności i dostarczenie wiedzy z dziedziny zastosowania. Rolą wytwórcy oprogramowania jest przeprowadzenie dokładnej analizy wymagań, obejmującej także poznanie dziedziny.
2 .1 .2 . P o zio m y o pisu w y m a g a ń Dokładne zidentyfikowanie i opisanie wszystkich wymagań stawianych oprogramo waniu wymaga dużej wiedzy na temat potrzeb użytkownika, technologicznych możliwoścHiaiifflkojenia tych potrzeb, kosztów różnych wariantów realizacji i związanego z nimi ryzyka. Na początku projektu tej wiedzy jeszcze nie ma, a jej pozyskanie i udo kumentowanie wymaga wysiłku, czasu i pieniędzy. Dlatego określanie wymagań nie jest pojedynczą czynnością, ale procesem, z którego stopniowo wyłaniają się kolejne opisy wymagań, budowane w różnym celu i na różnych poziomach szczegółowości. W tym czasie stopniowo wzrasta wiedza wszystkich udziałowców projektu, umożliwiając im podejmowanie kolejnych decyzji o zaniechaniu lub kontynuowaniu projektu i angażo waniu coraz większych środków. Jeśli zapadnie ostateczha decyzja o realizacji projektu, to na końcu tego procesu powstanie kompletna specyfikacja wymagań, na tyle szczegó łowa, aby umożliwić deweloperom budowę oprogramowania (rys. 2.1). Pierwszym poziomem, na jakim są rozważane wymagania, jest poziom strate gicznych potrzeb biznesowych. Opis wymagań, prezentowany na tym poziomie w postaci wizji projektu, ma pomóc w ocenie biznesowego sensu przedsięwzięcia i podjęciu decyzji o rozpoczęciu prac zmierzających do jego realizacji. Osiągnięcie tego celu nie wymaga wnikania w szczegóły. Przeciwnie, wizja projektu ma krótko określić cel biznesowy, zakres i przypuszczalny koszt zbudowania systemu.
Projektowanie i implementacja
Rysunek 2.1. Poziomy opisu wymagań i zw iązane z nimi decyzje
Na przykład, po przystąpieniu Polski do Unii Europejskiej rolnicy zyskali prawo do dopłat w ramach wspólnej polityki rolnej UE. W tym celu konieczne było zbudo wanie systemu zapewniającego obsługę odpowiednich programów pomocowych. Powstała wizja systemu, która określiła jego cel i zakres: rejestracja ok. 2 min gospo darstw i 800 tys. siedzib stad, obsługa przyjmowania i kontroli wniosków, naliczanie dopłat zgodnie z odpowiednimi rozporządzeniami unijnymi, realizacja wypłat dla rolników oraz kontrola sanitarna ruchu zwierząt hodowlanych na terenie kraju. Sza cunkowy koszt rzędu 0,5 mkl złotych. Dokument wizji nie zawiera technicznych szczegółów niezbędnych do imple mentacji i wdrożenia oprogramowania. Nie jest to jednak jego Celem. Zakres danych umożliwia ocenę biznesowej racjonalności przedsięwzięcia, wystarczającą do wyasy gnowania środków na prace zmierzające do określenia wymagań. Drugim poziomem opisu wymagań jest specyfikacja usług i właściwości systemu istotnych dla użytkownika. Opis wymagań na tym poziomie ma służyć jako podstawa do negocjacji i zawarcia umowy z wykonawcą projektu. Dla osiągnięcia tego celu specyfikacja wymagań musi być na tyle kompletna i szczegółowa, aby dokładnie opisać oczekiwania klienta w stosunku do planowanego systemu i umożliwić poten cjalnym wykonawcom dokładną ocenę kosztu i czasu jego wykonania. Jednocześnie jednak opis wymagali musi być na tyle abstrakcyjny, aby nie sugerować konkretnych rozwiązań. Po zakończeniu negocjacji specyfikacja wymagań użytkownika stanie się częścią umowy określającą dokładnie to, co klient ma prawo oczekiwać, a wykonawca zobowiązał się dostarczyć. Na przykład, wymagania stawiane systemowi IACS, wspierającemu realizację dopiat bezpośrednich w ramach wspólnej polityki rolnej Unii Europejskiej, można postawić na tym poziomie następująco. ■ Prowadzenie rejestracji gospodarstw rolnych. Zakres funkcji: - wprowadzanie i kontrola wniosków o zarejestrowanie gospodarstwa, - drukowanie decyzji o zarejestrowaniu i nadaniu numeru gospodarstwu,
2. Inżynieria w ym agań
56
-
wyszukanie gospodarstwa w ewidencji na podstawie różnych atrybutów, modyfikacja danych gospodarstwa w ewidencji, wyrejestrowanie gospodarstwa z ewidencji.
H W ym agania użytkownika nie opisują dokładnie wszystkich szczegółów zacho wania przyszłego systemu, np. interfejsu użytkownika, na które użytkownik chciałby zapewne móc wpływać. Szczegółowość opisu wystarcza jednak do tego, aby dokład nie określić zakres funkcjonalności, koszt i termin realizacji oraz podjąć decyzję o rozpoczęciu budowy systemu. Trzecim poziomem opisu jest specyfikacja wszystkich właściwości funkcjonal nych i niefunkcjonalnych na tyle dokładna, aby pozwolić użytkownikom na zrozu mienie i zatwierdzenie ostatecznego kształtu systemu. Opracowanie takiej specyfikacji wymaga zaangażowania dużych środków, co jest możliiye dopiero po podpisaniu umowy na wykonanie oprogramowania (lub tylko na wykonanie analizy). Na przykład, funkcje składające się na prowadzenie ewidencji producentów rol nych przez system TACS można opisać następująco. ■ W prowadzenie i kontrola wniosku o zarejestrowanie gospodarstwa: - przyjęcie dokumentu w kancelarii i nadanie mu daty i unikalnego numeru, - utworzenie sprawy o zarejestrowanie gospodarstwa (lub przypisanie do kumentu do istniejącej sprawy), - wprowadzenie treści dokumentu, - kontrola poprawności wprowadzenia treści dokumentu, - weryfikacja treści wniosku przez sprawdzenie danych osobowych w reje strze PESEL i sprawdzenie danych działek rolnych w rejestrach geode zyjnych, - nadanie gospodarstwu identyfikatora i rejestracja w ewidencji. Uwagi: - identyfikatory producentów są unikalne i mają postać ..., - kontroli poprawności wprowadzenia dokumentu dokonuje inny operator, - komunikacja z rejestrami geodezyjnymi prz&z okresowy import danych, - komunikacja z rejestrem PESEL on-line za [łomocą interfejsu - dane wprowadzone do ewidencji nie są nigcjy usuwane - system przecho wuje pełną historię zmian,
Opis wymagań systemowych, który jest zwykle znacznie obszerniejszy od przy toczonego przykładu, powinien umożliwić zaprojektowanie i napisanie programów oraz zdefiniowanie testów akceptacyjnych, które pozwolą odebrać gotowy produkt.
9.2 . Proces określania w ym agań
2.2.
57
P ro c e s o k re ś la n ia w y m a g a ń
Źródłem wymagań są biznesowe potrzeby klientów. W przypadku produktów rynko wych ogólnego przeznaczenia, np. gier komputerowych, potrzeby te rozpoznaje - albo kreuje i przekonuje do nich klientów - dział marketingu wytwórcy. W przypadku produktów budowanych na zamówienie konkretnych odbiorców, zwykle organizacji administracyjnych lub gospodarczych, potrzeby wyznaczają ich zarządy na podstawie analizy rynku, bieżącej sytuacji przedsiębiorstwa i wybranej strategii rozwoju. Ele mentem służącym zaspokojeniu potrzeb klientów mogą być systemy informatyczne budowane od podstaw lub rozwijane w oparciu o już posiadane, starsze, systemy. Proces ustalania potrzeb biznesowych organizacji i planowania sposobu ich zaspoko jenia nazywa się w naukach o zarządzaniu planowaniem strategicznym. Proces planowania strategicznego można przedstawić w postaci sekwencji kro ków prowadzących od analizy potrzeb i możliwości do definicji realnych przedsię wzięć mogących wspierać działania przedsiębiorstwa. 1. Określenie informacyjnych potrzeb firmy. Celem tego kroku jest znalezienie tych obszarów' działania, których funkcjonowanie można poprawić za pomocą narzędzi informatycznych. Metoda postępowania obejmuje analizę struktury organizacyjnej przedsiębiorstwa i obszarów jego działania (procesów bizne sowych), rozpoznanie problemów występujących w dotychczasowym środo wisku pracy oraz wskazanie celów biznesowych, które mają być osiągnięte. Elementem definicji celu powinno być określenie ilościowych mierników' sukcesu, np. skrócenie czasu obsługi klienta, zmniejszenie liczby reklamacji. 2. Ocena aktualnego stanu informatyzacji oraz istniejących ograniczeń i uwa runkowań. Celem tego kroku jest przegląd posiadanych systemów informa tycznych, analiza możliwości ich wykorzystania do zaspokojenia informacyj nych potrzeb firmy oraz określenie czynników ograniczających swobodę przy szłych decyzji. Metoda postępowania obejmuje inwentaryzację posiadanych systemów', ocenę ich wydajności i możliwości rozbudowy, przegląd kadr, anali zę obowiązujących aktów prawnych i norm, identyfikację współpracujących systemów' zewnętrznych oraz analizę źródeł finansowania rozwoju. 3. Budowa docelowego modelu systemów informatycznych. Celem jest tu okre ślenie kształtu przyszłych rozwiązań, wspierających cele firmy i uwzględnia ją c y c h , istniejące uwarunkowania, a przy tym minimalizujących nakłady i zachowujących najlepsze elementy już istniejących systemów. Metoda obejmuje porównanie potrzeb z możliwościami istniejących systemów, wska zanie i uporządkowanie luk oraz zdefiniowanie nowych systemów i działań niezbędnych do osiągnięcia docelowego stanu. Wyniki tych działań określają wymagania biznesowe dla przyszłych rozwiązań informatycznych.
j 2. in ży n ie ria w ym agań
58
4.
Opracowanie planu realizacji (wstępnego). Celem jest tu ocena możliwości i kosztu realizacji potrzebnych systemów, określenie odpowiedzialności za przygotowanie projektów, ustalenie ramowego harmonogramu realizacji i po ziomu nakładów oraz sposobu ich finansowania. M etoda postępowania obej muje przeprowadzenie studium wykonalności planowanych projektów, prze gląd kadr zarządczych, szacowanie kosztów i analizę finansowych moż liwości przedsiębiorstwa.
Podstawowym problemem początkowych etapów planowania strategicznego jest uporządkowanie posiadanych informacji oraz wybór kierunku dalszego działania. Jedną z najpopularniejszych metod tego etapu jest analiza SWOT. Przygotowanie realizacji wybranych projektów wymaga dokładniejszego określenia wymagań i sta rannego zbadania możliwości i kosztu ich wykonania. Jest to celem studium wyko nalności, które można scharakteryzować jako szybką symulację wykonania projektu. W yniki studium wykonalności otwierają drogę do wyspecyfikowania wymagań użyt kownika, które mogą być podstawą do negocjacji i zawarcia umowy. Metody wyko nania analizy strategicznej prowadzącej do określenia wymagań użytkownika zależą od wybranej metodyki analizy i projektowania oprogramowania. Te metody będą dokładnie opisane w dwóch następnych rozdziałach książki. Metody szacowania kosztów będą przedstawione w rozdziale 6.
,,2.2. Proces określania w ym agań
59
Bank dostrzegł problem 3 lata wcześniej i podpisał, umowę na opracowanie no wego systemu, oferującego petne usługi w dowolnej placówce banku. Umowa podzie liła zadania między zespoły robocze banku i zespoły dostawcy systemu. Niestety, projekt nabrał opóźnień i po trzech latach pracy bank wciąż nie ma. nowego systemu, choć wydał na projekt wiele pieniędzy, stracił wielu klientów i. stanął, przed konieczno ścią podjęcia zdecydowanych działań. Tylko jakich? Możliwości, obejmują: ■ kontynuację, projektu aż. do (niepewnego) końca, • zerwanie umowy i zmodernizowanie posiadanego systemu, ■ zerwanie umowy i pozostanie przy posiadanym systemie. \
Pierwszym krokiem metody jest ocena sytuacji i zestawienie silnych i słabych stron organizacji oraz szans i zagrożeń występujących w otoczeniu zewnętrznym. Wynikiem oceny są cztery listy czynników, którym należy przypisać wagi (0-10) określające wielkość wpływu na sytuację firmy. Wagi czynników wewnętrznych - sil i słabości - powinny być współmierne w takim sensie, że siła o wadze np. 7 powinna pomagać przedsiębiorstwu w takim samym stopniu, jak słabość o wadze 7 mu szko dzi. Podobnie współmierne powinny być oceny czynników zewnętrznych. Przykłado wy opis sil i słabości banku jest pokazany w tab. 2.1. Tabela 2.1. Siły i słabości wewnątrz organizacji
2 .2 .1 . A n a liza S W O T Jedną z najczęściej stosowanych metod planowania strategicznego jest analiza SWOT (,Strengths, Weaknesses, Opporlunities, Threats), której nazwa pochodzi od pierw szych liter angielskich słów oznaczających: siły, słabości, szanse i zagrożenia. Dwa pierwsze słowa odnoszą się do czynników wewnętrznych, tzn. sil i słabości tkwiących w analizowanej organizacji. Dwa następne dotyczą czynników zewnętrznych, tzn. szans i zagrożeń istniejących w otaczającym je świecie. Metoda podaje sposób mode lowania sytuacji przedsiębiorstwa oraz algorytm analizy prowadzący do określenia sposobów użycia sil do wykorzystania szans lub odparcia zagrożeń albo skoncentro wania się na naprawie własnych słabości, jeśli to one są czynnikiem dominującym. Działanie metody można przedstawić na przykładzie sytuacji banku, którego problem wygląda następująco. i it i Bank posiada zdecentralizowany system informatyczny wspomagający pracę od działów. System jest dobrze znany pracownikom, działa bez. zarzutu i nie powoduje kłopotów eksploatacyjnych. Problemem jest zdecentralizowana struktura systemu, która przypisuje klientów do oddziałów i znacząco ogranicza zakres operacji dostęp nych poz.a oddziałem macierzystym. Niezadowoleni z. lego klienci zaczynają przenosić się do konkurencyjnych banków.
Silne strony banku Rozbudowana sieć placówek w gminach Gotowy nowy model procesów biznesowych Dobre stosunki z producentem obecnego systemu Dobra grupa analityczno-projeklowa Dodatni bilans działalności operacyjnej Określona strategia prowadzenia projektu
Słabe struny banku 10 6 6 4 3 2
Brak centralnego systemu bankowego Duże zaangażowanie kadry w opóźniony projekt Brak środków do zakończenia inwestycji Duże środki zaangażowane w projekt Brak dostatecznej kadry Mala skala operacji Banku Brak dobrego menedżera projektu
10 9 7 7 6 3 2
Drugim, najbardziej charakterystycznym, krokiem metody jest zestawienie wszy stkich czynników we wspólnej tabeli ocen, nazywanej tabelą .SWOT (tab. 2.2). Lewa kolumna tabeli opisuje czynniki wewnętrzne, a prawa zewnętrzne. Górny wiersz tabeli opisuje czynniki pozytywne (siły i szanse), a dolny negatywne (słabości i zagrożenia). W celu wypełnienia tabeli należy wybrać po pięć najważniejszych czynników w każ dej z czterech kategorii, odrzucając pozostałe. Następnie należy znormalizować oceny w taki sposób, aby suma ocen czynników wewnętrznych, tzn. sil i słabości, była równa 100%, oraz suma ocen czynników zewnętrznych, tzn. szans i zagrożeń, wy no
60
2. In żynieria w ym agań
siła również 100%. Uzyskane w ten sposób wartości należy wpisać w cztery kwadranty tabeli SWOT. Tabela 2.2. Tabela SW OT podsum owująca oceny wszystkich czynników
S iły
[% 1
S zan se
1%1 12,2
R o zb u d o w a m i s ieć p la c ó w e k w g m in a c h
14,7
M o,żliw ośó ro z w o ju d z ia ła ln o ś c i d e ta lic z n e j
G o lo w y n o w y m o d el p ro c e só w b izn eso w y ch
8,8
M o ż liw o ś ć o b s łu g i-g m in i p o w ia tó w
10,8
D o b re sto su n k i z p ro d u c e n te m o b e c n e g o
8,8
M o ż liw o ś ć o b s łu g i lo k a ln y c h
10,8
p rz e d się b io rc ó w
sy ste m u D o b ra g ru p a a n a lity c z n o -p ro je k lo w a
5 ,9
N isk i k o s z t m o d e rn iz a c ji o b e c n e g o sy ste m u
9.5
D o d a tn i b ila n s d z ia ła ln o ś c i o p e ra c y jn e j
4 ,4
M o ż liw o ś ć m o d e rn iz a c ji p rz e z w y tw ó rc ę
9.5
Sum a
4 2 ,6
Sum a
Proces o k reślan ia w ym agań
Ostatnim krokiem analizy jest zestawienie tabeli korelacji czynników dominują cych (tab. 2.3). W iersze tabeli odpowiadają dominującym czynnikom wewnętrznym w przykładowym banku są nimi słabości, a kolumny reprezentują dominujące czyn niki zewnętrzne - w przykładzie banku są nimi szanse. W kratkach tabeli wpisuje się 0, gdy nie ma wyraźnego związku między odpowiadającymi tej kratce czynnikami wewnętrznym i zewnętrznym, lub 1, gdy taki związek istnieje. Na przykład, brak systemu centralnego przeszkadza bankowi w rozwoju działalności detalicznej i obsłu dze lokalnych firm, gdyż zarówno ludzie, jak i przedsiębiorcy przekraczają granice oddziałów, natomiast nie przeszkadza w obsłudze gmin i powiatów, które z natury tkwią w jednym miejscu. Tabela 2.3. Tabela korelacji szanse - słabości
5 2 ,7 S z a n sa
S ła b o ś c i
Z a g r o ż e n ia
i:% !
61
r% ]
R o zw ó j
O b słu g a
O b słu g a
M ały
W y tw ó rc a
d e ta lu
g m in
firm
k o sz t
m o d e rn iz u je
i p o w ia tó w
lo k a ln y c h
m o d e rn iz a c ji
R azem
B ruk c e n tra ln e g o s y ste m u b a n k o w e g o
14,7
D a lsz y o d p ły w k lie n tó w
13.5
Słabość
D u ż e z a a n g a ż o w a n ie k a d ry w o p ó ź n io n y
13.3
P o trz e b a d u ż y c h śro d k ó w n a d o k o ń c z e n ie
9.5
B rak s y sle m ii c e n tra ln e g o
1
0
I
0
0
2
1
1
I
0
1
4
0
0
0
1
0
1
0
0
0
0
0
0
B rak k a d ry n a d o k o ń c z e n ie
0
0
0
1
1
9
R azem
2
1
2
2
2
p ro jek t
in w e sty c ji
B rak ś ro d k ó w d o z a k o ń c z e n ia in w e sty c ji
10.3
G ro ź b a k a r u m o w n y c h za z e rw a n ie u m o w y
8.5
D uże z a a n g a ż o w a n ie k a d ry
D u ż e śro d k i z a a n g a ż o w a n e w p ro je k t
10.3
N ie ja sn e p e rs p e k ty w y se rw iso w a n ia
8,1
w pro jek t
B rak d o s ta te c z n e j kad ry
8,8
6,8
d o k o ń c ze n ie
re a liz o w a n e g o sy ste m u
B rak śro d k ó w na
G ro ź b a sp o ru są d o w e g o o z e rw a n ie u m o w y Sum a R az e m
5 7 ,4 100
Sum a R az e m
4 7 ,3 100
Suma ocen obliczona w każdym kwadrancie tabeli wyraża względną' wartość każdego z czterech czynników - sił, słabości, szans i zagrożeń. Kolejnym krokiem metody jest porównanie wartości sil i słabości w celu ustalenia czynnika dominują cego wewnątrz przedsiębiorstwa oraz wartości szans- i zagrożeń w celu ustalenia czynnika dominującego w otoczeniu. .leżeli w sytuacji dominują siły (nad słabościami) oraz szanse (nad zagrożeniami) - to nie jest przypadek naszego banku - to organizadja powinna wybrać strategię agresywną i użyć swych sił do wykorzystania szans. Jeś\i dominują siły i zagrożenia, to organizacja powinna wybrać strategię defensywną i |użyć swych sil do odparcia zagrożeń. Jeżeli w sytuacji dominują słabości oraz szanse - to jest przypadek naszego ban ku - to organizacja powinna przyjąć strategię naprawczą i dążyć do usunięcia słabości, które przeszkadzają w wykorzystaniu szans. Jeśli natomiast dominują słabości i zagro żenia, to organizacja nie ma w ręku żadnych atutów. Powinna przyjąć strategię pa sywną i starać się usuwać te słabości, które wystawiają ją na największe zagrożenia.
Z a a n g a ż o w a n e śro d k i w projekt
Suma tych ocen w każdym wierszu pokazuje znaczenie danego czynnika we wnętrznego dla rozwoju sytuacji zewnętrznej (wykorzystania sił lub odparcia zagro żeń). Suma ocen w kolumnach pokazuje, które czynniki zewnętrzne najbardziej ko rzystają z sil lub najbardziej tracą z powodu słabości przedsiębiorstwa. W rozważanym przykładzie tabela korelacji szans i słabości pokazuje, żc z szan sami najsilniej korelują (ujemnie) następujące słabości banku: ■ duże zaangażowanie własnej kadry we wlokący się projekt, B brak dostatecznej kadry do zakończenia tego projektu, ■ brak zcentralizowanego systemu bankowego. Taki wynik może skłaniać do podjęcia decyzji o wycofaniu się z realizacji obec nego projektu, co odciąży kadrę banku, i modernizacji dotychczas posiadanego syste mu, co zapewni bankowi niezależność kont klientów od miejsca ich założenia.
62
2. Inżynieria w ym agań
Przedstawiona analiza sytuacji banku dobrze ilustruje sposób działania metody. Trzeba jednak pamiętać o uproszczeniach wprowadzonych w przykładzie: braku szczegółowej analizy kosztów - zakończenia realizowanego projektu, wyjścia z umo wy i centralizacji dotychczas eksploatowanego systemu - oraz pominięciu dokładnego porównania cech obydwu rozważanych systemów: tego nowego (wdrażanego) i dotychczas eksploatowanego. Kontekst przykładu nasuwa podejrzenie, że ten nowy jest lepszy - gdyby dotychczasowy system był i lepszy, i tańszy, to przed laty nie podjęto by decyzji o wdrożeniu innego systemu.
2 .2 .2 . S tu d iu m w y k o n a ln o ś c i W ymagania biznesowe określają potrzeby i intencje inwestora w kontekście strategii rozwojowej przedsiębiorstwa. Podjęcie decyzji o zaangażowaniu dużych środków w przedsięwzięcie wymaga większej liczby danych: cjokladniejszych wymagań, analizy wariantów rozwiązania oraz wiarygodnie, określonego czasu i kosztu wykona nia projektu. Studium wykonalności (feasibilily shtdy) obejmuje badanie wszystkich tych obszarów jednocześnie. Wyniki studium dokumentuje raport wykonalności, którepT neśc jest podstawą do podjęcia decyzji o rozpoczęciu przedsięwzięcia. Studium wykonalności może być przeprowadzone przez inwestora własnymi si lami albo może być zlecone wyspecjalizowanej firmie konsultingowej. W obu przy padkach studium nie może trwać zbyt długo - im jest krótsze, tym mniej kosztuje i jest bardziej syntetyczne. Celem studium jest zwarta ocena całości, a nie analiza szczegółów. Z drugiej strony wyniki zbyt pospiesznych badań mogą być obarczone większym błędem. Sposób przeprowadzenia studium obejmuje zebranie danych oraz dokonanie oceny możliwości spełnienia wymagań w kilku obszarach, oznaczanych czasem akronimem PEST (political, economic, social, technological), z uwzględnieniem niepewności i ryzyka. C z y n n ik i te c h n ic z n e Ocena wykonalności technicznej polega na znalezieniu rozwiązań wychodzących ze stanu aktualnego i prowadzących do zamierzonego celu. Kluczowym problemem jest prawidłowe zidentyfikowanie i poddanie analizie krytycznych obszarów projektu, w których jest skumulowane ryzyko związane z nagromadzeniem zmian, konieczno ścią stworzenia nowych konstrukcji lub zastosowania!nowych metod i technologii. Pozostałe obszary i problemy występujące rutynowo w typowych projektach są bada ne w sposób zgrubny. W ynikiem analizy jest określenie wymaganych funkcji systemu i najważniej szych zbiorów danych oraz wskazanie możliwych wariantów realizacji. Opis propo nowanych rozwiązań obejmuje wskazanie architektury systemu, oszacowanie jego
7,,2. Proces określania wymagań
2U
______________________
63
rozmiaru i określenie strategii budowy. Na tej podstawie można oszacować praco chłonność oraz spodziewany czas i koszt realizacji projektu. C z y n n ik i lu d z k ie i o r g a n iz a c y jn e Ocena wykonalności w tym obszarze obejmuje zbadanie zakresu dostosowań organi zacji i ludzi, jakie będą niezbędne do osiągnięcia celów projektu. Konieczne dostoso wania organizacyjne mogą stać się źródłem dużych kosztów, a ich zakres może po ważnie utrudnić wykonanie i wdrożenie rezultatów projektu. Podobnie, opór ludzi, którzy muszą współdziałać z systemem, może zadecydować o klęsce całego przedsię wzięcia. Podstawowe problemy badane w tym obszarze można scharakteryzować następująco: ■ informatyzacja może zmienić sposób działania firmy, prowadząc do koniecz ności zreorganizowania jej struktury i zdefiniowania nowych procesów bizne sowych; ’ * system może przejąć część operacji wykonywanych dotąd ręcznie, eliminując potrzebę istnienia niektórych stanowisk; obecność systemu może też stworzyć potrzebę wykonywania innych działań - może to zmienić charakter pracy lu dzi i wymagać reorganizacji zatrudnienia albo szerokiego programu szkoleń; * informatyzacja może wpłynąć na postać kontaktów organizacji z otoczeniem (np. bankowym) - należy ocenić potrzebę i możliwość adaptacji otoczenia. W projektach rynkowych, których celem jest wytworzenie produktów ogólnego przeznaczenia, takich jak gry komputerowe lub narzędzia wspomagające projektowa nie, znaczenie tego obszaru jest mniejsze i obejmuje raczej zbadanie przyzwyczajeń i wzorców kulturowych funkcjonujących na rynku, dla którego przeznaczony jest produkt. O p ła c a ln o ś ć e k o n o m ic z n a Tradycyjną miarą opłacalności inwestycji, stosowaną w ekonomii, jest stosunek zysku oczekiwanego lub osiągniętego dzięki tej inwestycji do poniesionych nakładów. Jest to tzw. zwrot z inwestycji (return o f investment - ROI). Jeżeli zysk realizuje się w ciągu kolejnych n lat, to lepszym wskaźnikiem opłacalności staje się wewnętrzna stopa zwrotu (interncil return ratio — IRR). Jest to taka stopa oprocentowania kapitału, przy której zysk uzyskany z inwestycji w ciągu n lat równoważy wartość nakładów inwestycyjnych oprocentowanych na irr procent rocznie: Nakład ( 1 + irr )" = Zysk Tego typu miary stosunkowo łatwo stosować do produktów sprzedawanych na rynku, dla których oczekiwany zysk wynika wprost z oczekiwanej wielkości sprze daży. W przypadku produktów zamawianych, których zadaniem jest wspomożenie działania przedsiębiorstwa, oszacowanie spodziewanego zysku jest dużo trudniejsze.
2. Inżynieria w ym agań
64
Najłatwiejszym do uwzględnienia źródłem zysku jest spodziewana redukcja zatrud nienia. Inne korzyści, wynikające z poprawy działania przedsiębiorstwa, możliwości podjęcia nowych zadań i zdobycia przewagi konkurencyjnej, są znacznie trudniejsze do wycenienia. Obliczenie nakładów jest zwykle prostsze, jednak wymaga uwzględnienia całego szeregu kategorii kosztów, w tym kosztów ponoszonych od razu, do których należą: ■ koszty opracowania oprogramowania (w tym koszt narzędzi wspomagających), a koszty zakupu i instalacji infrastruktury (komputery, sieci, zasilanie, klimaty zacja), * koszty szkolenia personelu oraz koszt spadku wydajności w okresie wdrażania, * koszt pomieszczeń i energii, oraz kosztów ponoszonych w późniejszych latach eksploatacji, które obejmują: %' ■ koszty eksploatacji sprzętu, łączy sieciowych, licencji oprogramowania i serwisu, ■ koszty konserwacji i ewolucji systemu, ■ koszty amortyzacji sprzętu. Ocena opłacalności, nawet niezbyt precyzyjna, może ułatwić porównanie i selek cję wariantów rozwiązań o różnym poziomie ryzyka - rozwiązanie o wyższym ryzyku niepowodzenia powinno obiecywać wyższą stopę zwrotu. C z y n n ik i p ra w n e Przepisy prawa mogą wielorako wpływać na projekt. Czasami są źródłem wymagań (por. wymagania zgodności w punkcie 2.1.1). W innych przypadkach stwarzają ogra niczenia, zabraniając pewnych działań - np. ustawa o ochronie danych osobowych zabrania gromadzenia pewnych danych - lub nakładając obowiązek stosowania spe cjalnych rozwiązań - ta sama ustawa wymaga zabezpieczenia gromadzonych danych. Istotny wpływ na projekt może też mieć obowiązek przestrzegania praw autorskich. Innego rodzaju ograniczeniem jest konieczność wyłaniania wykonawcy systemu w przetargu, nałożona ustawą na przedsiębiorstwa administracji publicznej.
2 .2 .3 . P rzy g o to w a n ie w y k o n a n ia pro jektu Jeżeli wybrany projekt jest wykonywany własnymi silami, to rozpoczęcie wykonania wymaga wewnętrznej decyzji zarządu przedsiębiorstw^ i przydzielenia niezbędnych zasobów - ludzi, pomieszczeń i infrastruktury informatycznej. Jeżeli projekt ma być zlecony zewnętrznemu wykonawcy, to rozpoczęcie wykonania wymaga wybrania wykonawcy i zawarcia odpowiedniej umowy. Procedura wyłaniania wykonawcy przyjmuje często postać przetargu, w którym biorą udział zamawiający oraz oferenci.
2,2. Proces o kreślania w ym agań
65
Rozpisanie p rz e ta rg u
Procedura przetargowa rozpoczyna się od opublikowania przez zamawiającego Specy fikacji Istotnych W arunków Zamówienia (SIWZ). Treść tego dokumentu dzieli się zazwyczaj na trzy części. ■ Podstawowe informacje o zamawiającym, na które składają się opis zadań, struktury oraz ram prawnych przedsiębiorstwa, charakterystyka posiadanych systemów informatycznych oraz wskazanie problemów i mankamentów ist niejących rozwiązań. B Opis przedmiotu zamówienia określający cel i zakres projektu, funkcjonalne i niefunkcjonalne wymagania użytkownika, znane ograniczenia realizacyjne oraz oczekiwany termin lub harmonogram wdrożenia. » W ymagania dodatkowe obejmujące projekt umowy realizacyjnej, projekt or ganizacji zarządzania przedsięwzięciem, wymaganie przedstawienia referencji potwierdzających wiarygodność oferenta itp. Zamawiający powołuje też komisję przetargową, która oceni wszystkie złożone oferty zgodnie z podanymi w SIW Z kryteriami i wybierze wykonawcę projektu. O p ra c o w a n ie o fe rty Opublikowanie SIW Z jest dla wykonawcy punktem startowym procesu wytwórczego. Z jego punktu widzenia podstawowe informacje o zamawiającym definiują kontekst przedsięwzięcia, opis przedmiotu zamówienia określa wymagania użytkownika, a wymagania dodatkowe specyfikują istniejące ograniczenia. Opracowanie wiarygod nej oferty wymaga analizy tych danych (analiza strategiczna), której celem jest rozwi nięcie wymagali na tyle, aby stworzyć koncepcję rozwiązania oraz określić ogólną architekturę systemu, harmonogram wykonania, pracochłonność i koszt. Treść oferty musi być zgodna z wymaganiami narzuconymi przez SIWZ. Zazwyczaj w ofercie występują następujące elementy. ■ Charakterystyka proponowanego rozwiązania, obejmująca projekt koncep cyjny systemu, opis jego architektury, interfejsu i technologii realizacji. ■ Dokładny opis rozwiązań wybranej części systemu (zgodnie z wymaganiami SIWZ). ■ Organizacja procesu wytwórczego, opis metody realizacji, charakterystyka zespołów roboczych desygnowanych do wykonania projektu. ■ Kosztorys i harmonogram prac. ■ Inne informacje wymienione przez zamawiającego w SIWZ, w tym pełno mocnictwa reprezentantów firmy i referencje z wykonania poprzednich pro jektów.
66
2. Inżynieria w ym agań
W ybranie oferty przez komisję przetargową i zawarcie umowy oznacza rozpo częcie realizacji przedsięwzięcia. Odnosząc te działania do modeli procesów wytwór czych przedstawionych w rozdziale 1, można zauważyć, że podpisanie umowy kończy fazę określenia wymagań na rys. 1.1 i 1.2 lub fazę rozpoczęcia na rys. 1.3. r Działania związane z opracowaniem specyfikacji istotnych warunków zamówie nia (wliczając w to studium wykonalności) oraz oferty, jakkolw iek wykonywane przez różne podmioty, obejmują prace analityczne wchodzące w skład procesu określenia wymagań. Jakość wykonania tych prac ma duży wpływ na powodzenie całego przed sięwzięcia. Jednocześnie wszystkie prace są wykonywane przed podpisaniem umowy, bez gwarancji jakiegokolw iek zysku. Dlatego bardzo ważne jest właściwe ustalenie czasu trwania i stopnia szczegółowości analizy prowadzonej w ramach tego procesu. Na pewno czas ten nie powinien być zbyt długi. Nie tylko ze względu na koszty, ale także dlatego, że celem podejmowanych tu działań nie jest dokładna analiza wszyst kich szczegółów, tylko ustalenie i uzgodnienie wymagań; wiarygodne oszacowanie kosztów i podjęcie właściwej decyzji o rozpoczęciu lub zaniechaniu projektu. Jeżeli system nie powstaje na zamówienie zewnętrznego klienta, lecz jest wytwa rzany dla masowego odbiorcy (por. podrozdział 1.1), to przebieg całego procesu ulega pewnej zmianie. Faza planowania strategicznego przeradza się w fazę badania rynku i odkrywania potrzeb potencjalnych odbiorców przez dział marketingu oraz weryfika cji propozycji marketingowych podczas studium wykonalności projektu. Postępowa nie przetargowe zastępuje analiza strategiczna wykonywana przez własne działy rozwojowe przedsiębiorstwa. Wyniki tej analizy są podstawą do podjęcia decyzji o realizacji lub zarzuceniu projektu. Dalsze prace toczą się zgodnie z wybranym modelem procesu wytwórczego.
2 .3 .
P o z y s k iw a n ie i d o k u m e n to w a n ie w y m a g a ń
Tylko w nielicznych przypadkach organizacja gospodarcza lub administracyjna, planująca wdrożenie nowego systemu informatycznego, jest: w stanie wykonać wszystkie prace analityczne i przygotować specyfikację wymagań własnymi silami. Zakres jej działania obejmuje na co dzień zupełnie iniiy obszar, do którego dostoso wane są też kwalifikacje pracowników. Dlatego często',konieczne jest zlecenie przy gotowania specyfikacji wymagań specjalistycznej firmie'doradczej lub informatycznej (niekiedy będzie to wykonawca systemu), która dostarczy odpowiedni zespól anality ków. Takie rozwiązanie rodzi nowy problem, wynikający z braku znajomości dzie dziny zastosowania i celów biznesowych organizacji przez zewnętrznych analityków. Kluczowym czynnikiem powodzenia ich pracy staje się zrozumienie użytkowników i pozyskanie od nich wiedzy na temat wymagań oraz udokumentowanie tych wymagań w sposób zrozumiały zarówno dla użytkowników, jak i dla wykonawców systemu.
2 3. P ozyskiw anie i d o k u m en to w a n ie w ym agań
67
2.3.1. M e to d y p o zy s k iw a n ia w y m ag a ń Aby wykonać swoje zadanie, analitycy tworzący specyfikację wymagań muszą po znać dziedzinę zastosowania i organizację, dla której oprogramowanie jest przezna czone, zrozumieć sposób jej działania oraz poznać jej problemy, zamierzenia i ograni czenia. Podstawowe metody pozyskiwania wiedzy obejmują: ■ studiowanie dostępnej dokumentacji, ■ wywiady z przedstawicielami kierownictwa, ■ obserwację i analizę obiegu dokumentów. ’ Dokumentacja istotna dla poznania organizacji obejmuje akty prawne regulujące jej działanie, schemat struktury organizacyjnej, regulaminy, procedury i instrukcje stanowiskowe, strategię rozwoju oraz opisy istniejących w firmie systemów informa tycznych. Dobrym źródłem wiedzy - zwłaszcza w projektach rynkowych - są również opisy produktów konkurencyjnych. Informacje niedostępne w dokumentach można uzyskać od przedstawicieli kie rownictwa podczas wywiadów, których lematem mogą być zadania i problemy orga nizacji, podstawowe procesy biznesowe, zakresy odpowiedzialności pracowników oraz plany na przyszłość. Umiejętność przeprowadzania wywiadów wykracza poza techniczną sferę informatyki i wymaga pewnych talentów z zakresu komunikacji międzyludzkiej oraz elementarnej znajomości socjologii. Kluczową sprawą jest przy gotowanie zawczasu takiego zestawu pytań, który ułatwi osiągnięcie celu analizy, umiejętne dobranie respondentów spośród osób, które mogą na te pytania odpowie dzieć, oraz zadbanie, aby cel wywiadu byi od początku jasny dla obu stron. W trakcie wywiadu należy prowadzić notatki, a po jego zakończeniu - uporządkować notatki i uzyskać autoryzację ich ostatecznej wersji od respondenta. Kolejnym źródłem informacji może być analiza obiegu dokumentów krążących w organizacji. W czasie analizy należy zwrócić szczególną uwagę na sposób tworze nia dokumentów - kto je tworzy, w jakim celu, na podstawie jakich źródeł - oraz ich treść, rozmiar i przeznaczenie - jakie zawierają dane, dla kogo są przeznaczone, jak długo są przechowywane. Zespolenie wiedzy uzyskanej z tych lrzęch źródeł umożliwia stworzenie modelu działania organizacji, opisującego jej strukturę, podstawowe procesy biznesowe oraz dane. Budowę modelu należy rozpocząć równolegle ze zbieraniem informacji, mody fikując model w miarę pozyskiwania nowych danych. Takie postępowanie ułatwia korelowanie informacji pochodzących z różnych źródeł lub sformułowanych w różny sposób oraz wykrywanie i usuwanie nieuniknionych sprzeczności. Kolejne wersje modelu można wykorzystać podczas kolejnych wywiadów, pokazując je użytkowni kom w celu weryfikacji i zatwierdzenia.
68
2. In żynieria w ym agań
Zbudowanie modelu działania organizacji umożliwia uzgodnienie zakresu no wego systemu przez wskazanie tych procesów organizacji, które będą podlegały zmianom. Nowy system może wspierać już istniejące procesy, zmieniać ich przebieg albo prowadzić do powstania zupełnie nowych działań, W pierwszym przypadku wymagania użytkowników można zebrać, korzystając z obserwacji jdż wykonywa nych działań, analizy celów biznesowych oraz oczekiwani i zwyczajów przyszłych użytkowników. W ostatnim przypadku opis wymagań można stworzyć na podstawie analizy modelu planowanych działań i procesów biznesowych. Postać modelu tworzonego podczas analizy strategicznej oraz sposób jego two rzenia nie są jednoznacznie określone i zależą od użytych metod. Metodyka struktu ralna preferuje inne modele i techniki modelowania niż podejście obiektowe. Sposób wykonania analizy strategicznej za pomocą metod strukturalnych jest przedstawiony w rozdziale 3. Sposób wykonania analizy strategicznej z użyciem metod obiektowych jest opisany w rozdziale 4.
2 .3 .2 . S p e c y fik a c ja w y m a g a ń Specyfikacja wymagań jest podstawowym dokumentem rozpoczynającym prace nad budową oprogramowania. Zawartość specyfikacji wymagań powinna dokładnie okre ślać, co oprogramowanie ma robić, nie powinna jednak narzucać, ja k ma być zbudo wane. Narzucenie w specyfikacji wymagań określonych rozwiązań byłoby przed wczesnym i niepotrzebnym ograniczeniem swobody projektanta, utrudniającym stworzenie optymalnego projektu. Opracowanie specyfikacji wymaga ścisłej współpracy głównych udziałowców przedsięwzięcia: klienta i użytkowników, którzy znają dziedzinę zastosowania i swoje potrzeby, oraz wykonawcy, który zna dostępne technologie i rozumie wynikające z nich ograniczenia. Żadna ze stron nie ma wystarczających kompetencji do samodzielnego opracowania dobrej specyfikacji wymagań. Konieczność ścisłego współdziałania partnerów o różnym zakresie wykształcenia i działąjących w różnych dziedzinach ogranicza język ich komunikacji i utrudnia wykorzystanie specjalistycznych modeli i notacji, które mogą być niezrozumiale dla drugiej strony. Dlatego najczęśfciej stoso wanym językiem opisu wymagań jest język naturalpy, wzbogacony w niezbędne formalizmy, takie jak formuły matematyczne, używane w dziedzinie zastosowania. Inne środki wyrazu, w tym przede wszystkim modele ijnalizy strukturalnej lub obiek towej, są wykorzystywane na tym etapie projektu w ograniczonym zakresie. Badania ankietowe, w których wzięło udział 151 firm informatycznych z całego świata, przeprowadzone na uniwersytecie w Tren to [35] pokazały, że 79% specyfika cji wymagań jest pisanych w języku naturalnym, 16% używa strukturalizowanego języka naturalnego (formularze, wzorce pseudokodu), a jedynie 5% wykorzystuje sformalizowane języki specyfikacyjne. Problemem związanym w wykorzystaniem języka naturalnego jest wieloznaczność zapisu. Wadą języków sformalizowanych jest
mniejsza czytelność oraz potencjalna możliwość przedwczesnego narzucenia konkret nych rozwiązali. Specyfikacja wymagań jest częścią umowy między zleceniodawcą a wykonawcą, określającą cechy budowanego oprogramowania. Ta podstawowa^wsk;—„pecyfikacji wymagań sprawia, że usuwanie skutków błędów popełnionych w specyfikacji jest trudne i kosztowne. W ynika to z faktu, że z reguły błędy te są niewidoczne podczas projektowania i implementacji, a wychodzą na jaw dopiero podczas ostatecznej oceny i prób eksploatacyjnych. Usunięcie błędów wymaga nie tylko przeprojektowania i ponownego programowania pewnych fragmentów, lecz również powtórzenia calcgo procesu testowania. Z tego powodu sposób opracowania specyfikacji wymagań ma duże znaczenie dla powodzenia całego projektu. Standard A N S i/IE E E 8 3 0
Standard ANSI/IEEE 830 [177] formułuje szereg zaleceń, jakie powinna spełniać dobrze napisana specyfikacja wymagań. Treść dokumentu powinna opisywać wszyst kie pożądane cechy oprogramowania: wymagania funkcjonalne, wymagania niefunk cjonalne, sprzęgi zewnętrzne oraz ograniczenia narzucone na kształt oprogramowania. Specyfikacja nie powinna natomiast zawierać wymagań dotyczących procesu wy twórczego, które są również ważne, ale które powinny być zapisane w innych doku mentach, np. wprost w umowie. Dobrze opracowaną specyfikację charakteryzują następujące cechy. B Poprawność - specyfikacja powinna opisywać tylko te wymagania, które są potrzebne użytkownikom. Jeżeli oprogramowanie jest elementem większego systemu, to specyfikacja wymagań musi wynikać z projektu systemu i nie może być sprzeczna z jakim kolwiek innym dokumentem projektowym. W in nych przypadkach weryfikacja poprawności specyfikacji może polegać tylko na subiektywnej ocenie użytkownika. B Jednoznaczność - zapis każdego wymagania powinien mieć tylko jedną inter pretację. Cecha ta jest prawie niemożliwa do osiągnięcia w dokumencie pisa nym w języku naturalnym. Jako minimum można jednak wymagać unikania synonimów dla określenia tego samego pojęcia, a w razie specyficznego uży cia nazw wieloznacznych - umieszczenia ich definicji w słowniku, stanowią cym uzupełnienie specyfikacji. ■ Kompletność - specyfikacja powinna wymieniać wszystkie wymagania funk cjonalne i niefunkcjonalne, które muszą być spełnione. Opis wymagań powi nien definiować odpowiedź systemu na wszystkie możliwe wartości danych wejściowych zarówno poprawne, jak i niepoprawne, we wszystkich stanach programu. Redakcja dokumentu powinna uwzględniać podpisy i odnośniki w tekście dla wszystkich tabel i rysunków.
y !
2. Inżynieria wymagań
70
■ Spójność - opisy wymagań znajdujące się w specyfikacji nie mogą zawierać sprzeczności. Redakcyjnym zabiegiem wspomagającym osiągnięcie tego celu jest takie uporządkowanie tekstu, aby każde wymaganie było opisane tylko w jednym miejscu. Ponadto, we wszystkich opisach odnoszących się do tych samych działań lub obiektów powinna być użyta ta sama terminologia. ■ Uporządkowanie - jeśli nie wszystkie wymagania opisane w specyfikacji są tak samo ważne dla użytkownika, to powinny być jaw nie sklasyfikowane pod w zględem ważności, np.: wymagania niezbędne, pożądane i mile widziane. Określenie ważności wymagań poprawia czytelność dokumentu i umożliwia właściwe rozłożenie wysiłku podczas wytwarzania oprogramowania przy ograniczonych zasobach. ■ W eryfikowalność - opisy wymagań powinny być tak formułowane, aby moż liwe było jednoznaczne rozstrzygnięcie, czy finalny produkt spełnia te wymaga nia, czy nie. Problem dotyczy przede wszystkim Wymagań niefunkcjonalnych. Na przykład, wymaganie: „czas odpowiedzi systemu nie powinien zazwyczaj przekraczać 10 s”, jest nieweryfikowalne, gdyż nie wiadomo dokładnie, co to znaczy „zazwyczaj” . ■ M odyjikowalność - struktura i styl napisania specyfikacji powinny umożli wiać wprowadzanie zmian bez naruszania spójności dokumentu. W tym celu specyfikacja powinna być podzielona na rozdziały i punkty opisujące po szczególne wymagania, przy czym każde wymaganie powinno być opisane tylko w jednym punkcie. Związki między pokrewnymi punktami powinny być pokazane za pomocą odsyłaczy. * Powiązanie (traceability) - każde wymaganie zamieszczone w specyfik i p wymagań powinno mieć wskazane źródło pochodzenia, w postaci np. nun punktu jakiegoś wcześniejszego dokumentu analitycznego, aktu prawnego lun normy branżowej. W celu umożliwienia późniejszego powiązania specyfikacji z dokumentami projektowymi wszystkie punkty specyfikacji wymagań po winny być numerowane. Dla ułatwienia przechowywania, przeglądania, aktualizacji i powielania doku ment powinien być sporządzony w formie możliwej do^ przetwarzania komputerowego. Treść dokumentu powinna być zorganizowana zgodnie Ą następującym wzorcem. ii |
,2.4. P r o t o t y p o w a n i e (p ro lo iy p in g )
7I
■ listę dokumentów związanych, do których odwołują się poszczególne punkty specyfikacji, wraz ze wskazaniem sposobu dostępu do tych dokumentów; ■ streszczenie wyjaśniające zawartość i strukturę pozostałej części dokumentu. Opis ogólny. Drugi rozdział opisuje miejsce oprogramowania w otoczeniu, naj ważniejsze funkcje oraz znane ograniczenia projektowe. Zakres treści:
,
■ opis otoczenia, obejmujący współpracujące systemy, interfejsy komunikacyj ne i ludzi; ■ podstawowe funkcje, uporządkowane zgodnie z biegiem procesów biznesowych; ■ opis ograniczeń, wskazujący czynniki krępujące swobodę projektantów, takie jak regulacje prawne, wymogi bezpieczeństwa, wymagania zgodności ilp; * założenia, sprawy nierozstrzygnięte oraz wymagania pominięte w lej wersji produktu. Wymagania szczegółowe. Ta część dokumentu zawiera specyfikację wymagań, opisanych w postaci odrębnych, numerowanych lub nazwanych punktów. Struk tura opisu może być różna, zawsze jednak powinna zawierać następujące ele menty: * opis danych, obejmujący wszystkie rodzaje danych wprowadzanych i wytwa rzanych przez oprogramowanie (dokumenty, raporty, ekrany, komunikaty); ■ opis funkcji, określający dla każdej funkcji jej dane wejściowe, algorytm przetwarzania danych prawidłowych i nieprawidłowych, wyniki oraz warianty działania; ■ opis bazy danych, określający kategorie danych, ich powiązania, sposób wy korzystania przez funkcje, więzy integralności oraz okresy przechowywania; * wymagania niefunkcjonalne dotyczące wydajności, niezawodności, bezpie czeństwa, zachowania w razie awarii, przenośności itp., opisane ilościowo i odniesione, w miarę potrzeb, do poszczególnych funkcji; ■ ograniczenia projektowe. Indeks i dodatki. Indeks zawiera listę używanych ważnych pojęć, odniesionych do numerów punktów dokumentu. Dodatki mogą zawierać m.in. przykładowe formaty przetwarzanych dokumentów, modele analityczne lub wyniki analizy kosztów.
Wstęp. Pierwszy rozdział zawiera informacje wyjaśniające przeznaczenie doku mentu i ułatwiające korzystanie z jego treści: ■ cel dokumentu i spodziewany krąg czytelników; ■ zakres specyfikacji, określony przez nazwę produktu i opis obszaru zastoso wania; ■ słownik definicji pojęć i skrótów nazw używanych w treści dokumentu;
2.4.
P ro to ty p o w a n ie {prototyping)
Analiza i zatwierdzenie specyfikacji wymagań przez użytkowników lub ekspertów w dziedzinie zastosowania wymaga zrozumienia treści tego dokumentu, zajmującego często wiele stron tekstu, oraz wyobrażenia sobie postaci i sposobu funkcjonowania
72
2. Inżynieria w ym agań
nieistniejącego jeszcze systemu. Poleganie tylko na wyobraźni czytelnika jest ryzy kowne i niemal zawsze mniej pewne od możliwości zbadania realnie istniejącego obiektu. Dążenie do ograniczenia tego ryzyka leży u podstaw techniki oceny polegają cej na budowaniu prototypu przed przystąpieniem do budowy rzeczywistego produktu. Prototyp oprogramowania jest prowizoryczną implementacją, mającą tylko pew ne wybrane cechy finalnego produktu. Przykładem takiego prototypu może być inter fejs użytkownika, prezentujący menu funkcji i umożliwiający nawigowanie między różnymi ekranami systemu, ale niepowiązany z żadną logiką wykonującą znajdujące się w menu funkcje. Działający prototyp może przyjmować dane wejściowe, wyświe tlać stule albo losowo wybrane odpowiedzi oraz drukować pewne z góry przygotowa ne raporty. Korzystając z prototypu, użytkownik może eksperymentalnie ocenić kompletność danych wejściowych, jakie muszą być wprowadzane do systemu, kom pletność potrzebnych mu funkcji oraz dostępność potrzebnych raportów. W razie wątpliwości funkcje prototypu mogą zostać szybko zmiehione, co daje możliwość wypróbowania różnych wariantów działania systemu. Prototyp ukazujący szeroki, ale powierzchowny obraz działania programu i niepodejmujący głębszych problemów jego realizacji jest nazywany niekiedy prototypem poziomym (horizontal prototype). W ykorzystanie takiego prototypu nie musi istotnie zmieniać procesu wytwarzania oprogramowania. Prototyp powstaje podczas analizy wymagań, odgrywa swą rolę podczas oceny i zatwierdzania specyfikacji, a po za twierdzeniu może stać się jej istotną częścią. Główną korzyścią wynikającą z posiada nia takiego prototypu jest możliwość lepszego rozpoznania rzeczywistych potrzeb użytkownika oraz bardziej wiarygodna ocena specyfikacji wymagań. Dodatkową korzyścią jest zebranie przez programistów pierwszych doświadczeń podczas budo wania prototypu. Zalety prototypowania, nazywanego leż makietowaniem, okazały się tak duże, że używanie lej techniki stało się obecnie powszechnie obowiązującym standardem. Prototyp interfejsu użytkownika jest niemal zawsze budowany podczas analizy wy magań, zarówno w kaskadowym, jak i ileracyjnym procesie wytwórczym. W najprost szym przypadku prototyp może mieć postać „papierową” , i obejmować narysowane przez grafika zrzuty z ekranu; Bardziej rozbudowany prototyp może składać się z zestawu stron internetowych wyświetlanych na ekranie komputera albo być kom pletnym, działającym programem wyświetlającym kojejne ekrany i symulującym rzeczywisty dialog z użytkownikiem. Niezależnie od |technild realizacji głównym celem prototypu poziomego jest ograniczenie ryzyka niekompletnego lub nieprawi dłowego wyspecyfikowania wymagań. Zupełnie innym sposobem wykorzystania techniki prototypowania jest budowa nie prototypowych rozwiązań pewnych wybranych problemów projektowych. Taki prototyp implementujący pewien wybrany fragment funkcjonalności w sposób zgodny z docelowym rozwiązaniem jest nazywany prototypem pionowym (vertical protoi
T
.2.4. P r o t o t y p o w a n i e (p ro to typ in g )
73
type). C e le m tw o rz e n ia tak ie g o p ro to ty p u m o że b y ć np. s p ra w d z e n ie w y d ajn o ści w ybranej a rc h ite k tu ry w p e w n y c h sy tu a c ja c h , u d o w o d n ie n ie w y k o n a ln o śc i ro z w ią z a nia w w y b ra n ej te c h n o lo g ii im p le m e n ta c y jn e j alb o e k sp e ry m e n ta ln e z b a d a n ie n o w a torskiego a lg o ry tm u d z ia ła n ia . P ro to ty p y p io n o w e m o g ą p o w sta w a ć w e w c z e sn y c h fazach p ro c e su w y tw a rz a n ia o p ro g ra m o w a n ia - p o d c z a s stu d iu m w y k o n a ln o śc i, alb o z n a c z n ie p ó źn iej - p o d czas p ro jek to w an ia i o c e n ia n ia ró ż n y c h m o ż liw y c h w a ria n tó w p ro jek tu o p ro g ra m o w a n ia . W ia ry g o d n o ść o c en y je s t tym w ię k sz a , im te c h n o lo g ia re a liz a c ji p ro to ty p u jest: b liższa pro d u k cy jn ej te c h n o lo g ii w y tw a rz a n ia o p ro g ra m o w a n ia . G łó w n ą k o rz y śc ią w y n ik a jącą z p o sia d a n ia p ro to ty p u je s t o g ra n ic z e n ie ry z y k a p ro je k to w e g o p o le g a ją c e g o na w yborze n ie w ła ś c iw y c h m eto d lub te c h n o lo g ii re a liz a c y jn y c h .
Rola prototypu w procesie tworzenia oprogramowania może być różna. Najczęst szym sposobem wykorzystania techniki prototypowania jest budowa jednorazowych prototypów służących badaniu wymagań lub wariantów projektu. Po zakończeniu badania i wybraniu właściwego wariantu prototyp jest odrzucany (throwaway proto type), a projekt biegnie dalej, zgodnie z wybranym modelem procesu wytwórczego. Zyskiem z posiadania prototypu jest lepsze zrozumienie problemu (dziedziny zasto sowania, wymagań, wariantów projektu) prowadzące do zmniejszenia ryzyka niepo wodzenia. Ceną jest dodatkowy koszt budowy prototypu. Inny sposób wykorzystania prototypu polega na stopniowej rozbudowie jego możliwości, aż do spełnienia wszystkich wymagań użytkownika - w tym momencie prototyp przekształci się w implementację oprogramowania (evolutionary prototype). Ta idea jest - do pewnego stopnia - realizowana przez iteracyjne procesy wytwórcze, zwłaszcza procesy zwinne. Wyniki kolejnych iteracji można z tej perspektywy trakto wać jako kolejne prototypy pionowe, realizujące część funkcji oprogramowania i służące użytkownikom do badania oraz oceny jakości i zgodności z potrzebami. Każda następna iteracja ulepsza prototyp zgodnie z uwagami użytkowników, aż do pełnego zaspokojenia ich potrzeb w finalnym produkcie. Prototyp odrzucany powinien być zbudowany szybko i tanio, bez konieczności dbania o jakość tego produktu. Prototyp ewolucyjny powinien być budowany z wyko rzystaniem standardów jakości oraz narzędzi docelowego środowiska produkcyjnego. Tak różne wymagania i założenia projektowe sprawiają, że decyzja o sposobie dal szego wykorzystania prototypu powinna być podjęta jeszcze przed jego budową [27]. Pozwoli to zapobiec zarówno takiej sytuacji, w której prowizoryczne rozwiązania prototypu staną się trwałą częścią finalnej aplikacji, jak i takiej, w której koszty ponie sione na stworzenie prototypu o produkcyjnej jakości zostaną zmarnowane i wraz z nim odrzucone.
2. Inżynieria w ym agań
74
2 .5 .
Z a rz ą d z a n ie w y m a g a n ia m i
Określenie wymagań nie jest jednorazow ym aktem napisania specyfikacji. Przeciwnie, jest procesem, w którym raz ustalone wymagania ulegają zmianom i uzupełnieniom. Powodem zmian mogą być popełnione wcześniej błędy, zmieniające się z czasem potrzeby użytkowników, ograniczenia wynikające z braku zasobów niezbędnych do spełnienia wszystkich wymagań oraz konflikty występujące między różnymi grupami użytkowników. Proces określania wymagań rozpoczyna się wraz z powstaniem po trzeb, obejm uje cały okres realizacji projektu i trwa również w czasie eksploatacji produktu, w którym nowe wymagania mogą prowadzić do konieczności opracowania nowych wersji oprogramowania. Każda zmiana wymagań zaburza przebieg procesu wytwórczego i może stać się przyczyną poważnych kosztów. Koszt wprowadzenia zmiany w projekcie rośnie z upływem czasu i jest tym większy, im bardziej zaawansowane są prace [111]. O ile uwzględnienie zmiany podczas określania wymagań nie kosztuje wiele (pod warun kiem że zm iana nie rozszerza zakresu projektu), o tyle uwzględnienie tej samej zmia ny w późniejszych etapach wytwarzania wymaga powtórzenia części prac i poniesie nia związanych z tym kosztów (rys. 2.2). Stworzenie i utrzymanie spójnego zbioru wymagań, zapanowanie nad zmianami oraz ograniczenie powodowanych przez nie kosztów jest celem procesu zarządzania wymaganiami.
2,,.5. Z arz ąd z an ie w ym aganiam i
75
których celem jest sprawdzenie, czy przyjęty zbiór wymagań poprawnie i kompletnie określa potrzeby i oczekiwania klienta, zależą od sposobu sformułowania wymagań. Do najszerzej stosowanych w praktyce należą następujące metody oceny. * Przegląd - jakość specyfikacji wymagań mogą ocenić eksperci, dokonując przeglądu i analizy jej treści. Jest to najszerzej stosowana metoda oceny, któ rej słabością jest poleganie wyłącznie na wiedzy i wyobraźni ekspertów. ■ Ocena prototypu - demonstracja zachowania programu stymuluje wyobraźnię ekspertów i użytkowników, zwiększając w ten sposób wiarygodność oceny. Badanie prototypu powinno koncentrować się na ocenie kompletności i uży» teczności funkcji, a nie na ocenie wyglądu prototypu. ■ Automatyczne ,sprawdzenie poprawności - zapisanie wymagań w postaci mo delu o matematycznie określonych regułach poprawności umożliwia spraw dzenie tych reguł przez automatyczne narzędzie. Zaletą metody jest dowód poprawności modelu, wadą - niemożliwość automatycznego sprawdzenia zgodności modelu z potrzebami klienta. * Tworzenie testów - końcowym sprawdzianem zgodności programów z wy maganiami będą testy akceptacyjne, których treść musi odzwierciedlać wszy stkie istotne elementy wymagań. Opracowanie tych testów wraz z określeniem wymagań pomaga w ocenie znaczenia, spójności i wykonalności wymagali. Zatwierdzenie specyfikacji nie gwarantuje - niestety - niezmienności wymagali. Pojawiające się z upływem czasu żądania zmian prowadzą do usuwania nieaktualnych wymagań, dodawania nowych oraz zmieniania treści niektórych zapisów. Nie można przy tym wykluczyć, że pewne usunięte z powodu konfliktu wymagania zostaną po jakimś czasie zgłoszone ponownie. Aby zapobiec wielokrotnemu powtarzaniu tych samych analiz, oprócz aktualnej postaci zbioru wymagań przechowuje się często całą historię zmian, obejmującą wymagania odrzucone oraz uzasadnienia przyczyn ich odrzucenia.
R ysunek 2.2. W zględny koszt zmiany wymagań w różnych fazach procesu w ytwórczego
W początkowym okresie prac głównym problemem jest odkrywanie, gromadze nie i dokumentowanie wymagań oraz usuwanie istniejących między nimi sprzeczno ści. Ponieważ wymagania zgłaszane przez różnych użytkowników mogą się różnić od siebie, konieczne jest porównywanie zgłoszonych wymagań i rozstrzyganie istnieją cych między nimi konfliktów. Decyzje rozstrzygające konflikt podejmuje klient, natomiast wykrywanie konfliktów i utrzymywanie spójnego zbioru wymagań należy do zadań zarządzającego wymaganiami analityka. Stworzenie specyfikacji wymagań umożliwia podpisanie umowy i rozpoczęcie prac nad budową oprogramowania. Zanim to jednak nastąpi, konieczna jest ocena zgromadzonych wymagań i zatwierdzenie ich końcowej postaci. Metody oceny,
Kontrolowanie zmian i zarządzanie wymaganiami w projekcie informatycznym wymaga przetwarzania dużego zbioru danych charakteryzujących wymagania, ich historię oraz występujące między nimi powiązania i zależności. Pomocne w realizacji tych zadań są narzędzia CASE wspomagające analityka w wykonaniu takich czynno ści, jak: * wprowadzanie i przechowywanie wymagań zapisanych w języku naturalnym lub przy użyciu modeli graficznych; * nadawanie wymaganiom unikalnych oznaczeń oraz przechowywanie ich tre ści wraz z informacjami dotyczącymi pochodzenia, powiązań i historii zmian; ■ przeglądanie, zmienianie i usuwanie wymagań, automatyczne śledzenie i uaktualnianie powiązań wymagań zmienianych lub usuniętych;
2. Inżynieria w ym agań
76
■ sortowanie wymagań pod względem znaczenia oraz drukowanie wszystkich, lub tylko wybranych, wymagań w postaci specyfikacji o wymaganej formie graficznej; - zamrażanie aktualnie obowiązującej wersji wymagań, porównywanie różnych wersji, automatyczne siedzenie historii zmian. Narzędzia CASE wspomagające proces zarządzania wymaganiami są zwykle przystosowane do współpracy z popularnymi edytorami tekstów i arkuszami kalkula cyjnymi. Z drugiej strony narzędzia te są często dostarczane przez producentów wiel kich systemów CASE wspomagających pełny cykl wytwarzania oprogramowania i w takim przypadku są również przystosowane do współpracy z tymi systemami. Przykładem takiej kombinacji może być oferowany przez IBM program ReąuisitePro współpracujący z systemami Rational Software Architect i Rational Test M anager lub dostarczany przez firmę Borland pakiet Caliber współpracujący z systemem Together.
2 .6 ,
wymagań użytkownika, definiujący przypadki użycia, reguły biznesowe i atrybuty jakości, oraz dodatkowo tekstową specyfikację produktu. Nie precyzuje, na jakim poziomie jest zawierana umowa. Wydaje się, że niejednoznaczność wynika z różnych zwyczajów panujących w różnych organizacjach i różnych dziedzinach zastosowania. Metody spccyfikowania wymagań. Prócz metod opisanych w tym rozdziale, wart wzmianki jest sposób definiowania wymagań przez sprecyzowanie warunku wstępnego (precondition) opisującego stan systemu, jaki musi być spełniony przed wykonaniem programu (działania), oraz warunku wynikowego (postcondilion), jaki musi być spełniony po jego zakończeniu. Takie sformułowanie wym agafedokładnie specyfikuje efekt działania programu, bez wskazywania sposobu jego realizacji. Warunki wstępne i wynikowe, które zostały wprowadzone do informatyki jako ele menty tzw. logiki Hoare’a [219], służącej dowodzeniu poprawności programów, są adaptacją metody opisywania rzeczywistości opracowanej przez Poppera1 [258],
U w a g i b ib lio g ra fic z n e
Polny opis dziedziny inżynierii wymagań podają obszerne monografie [30, 29J. Szereg informacji na temat procesów i metod inżynierii wymagań można też znaleźć w wyda nych po polsku książkach |4, 2j. Klasyfikacja wymagań. Nie ma jednej, akceptowanej przez wszystkich, klasyfi kacji wymagań pod względem zakresu. Wszyscy autorzy zgodnie wyróżniają wyma gania funkcjonalne i niefunkcjonalne. W popularnym podręczniku Sommerville’a [4] wyróżniona jest dodatkowa kategoria wymagań dziedzinowych, które mogą być funkcjonalne lub niefunkcjonalne, a ponadto: „wynikają bardziej z dziedziny zastoso wania systemu niż z konkretnych potrzeb użytkowników”. Nie wydaje się to słuszne, gdyż każdy użytkownik działa w określonej dziedzinie i wszystkie jego potrzeby wynikają z potrzeb i zwyczajów tej dziedziny. Sommerville zalicza do wymagań dla oprogramowania także wymagania organizacyjne, czego wyraźnie nie zaleca standard IEEE 830 [177], ' Pełną klasyfikację wymagań podaje też norma ISO 91.26 [181], w której nie wy stępuje nazwa wymagania niefunkcjonalne (por. podrozdział 7.1).
I
Poziomy opisu wymagań. W tym zakresie też nie'm a pełnej zgodności. Sommer ville wyróżnia poziom wymagań użytkownika, odpowiedni do rozpisania przetargu, poziom wymagań systemowych, które mogą być wymienione w umowie, oraz specy fikację produktu, opracowaną w wyniku analizy, np. w fazie opracowania procesu iteracyjnego. Davis [27] proponuje umieszczenie w umowie wymagań użytkownika, co pozostawi większy margines swobody dla wykonawcy. W iegers [30] wyróżnia poziom wymagań biznesowych, określających strategiczne cele organizacji, poziom
Architektura korporacyjna. Jednym z najważniejszych problemów formuło wania wymagań na wczesnym etapie planowania strategicznego jest właściwe wkom ponowanie systemów informatycznych w biznesową, organizacyjną i informacyjną strukturę organizacji (przedsiębiorstwa). Całościowy obraz wszystkich wymienionych elementów jest nazywany architekturą korporacyjną. Badanie i projektowanie archi tektury korporacyjnej jest stosunkowo nową dziedzin;) wiedzy, u początków której leży praca Zachmana [38]. Tak zwana siatka Zachmana określa taksonomię elemen tów, które należy rozważyć, opisując lub projektując architekturę korporacyjną przed siębiorstwa. Istnieje szereg metod projektowania architektury korporacyjnej. Do najpopularniejszych należą dwie powszechnie dostępne metody: TOGAF (The Open Group Architecture Framework [36]) i FEA (Federal Enterprise Architecture [33]). Dokładniejszy opis architektury korporacyjnej daleko wykracza poza ramy lej książki. Zainteresowani tematem mogą znaleźć wszelkie informacje (łącznie z podręcznikami) w Internecie. Można również sięgnąć do książki [26].
Ekonomia inwestycji informatycznych. Strassmann [197] kwestionuje przydat ność tradycyjnych miar opłacalności inwestycji, przyjmujących kapitał za główny czynnik tworzenia wartości w procesach gospodarczych. Jego zdaniem, kapitał jest tani i łatwo dostępny, a głównym ograniczeniem są ludzie. Dlatego zysk zastępuje wartością dodaną informacji, która powinna przewyższać koszt posiadania kapitału. Dokładniejszy opis metody Strassmanna można znaleźć w jego książce. Karl Popper (1902-1994) jest u w a ż a n y za je d n e g o z n a jw ię k s z y c h filo z o fó w n au k i XX w iek u . S fo rm u ło w ał n i.in . z a s a d ę fa ls y f ik o w a ln o ś c i te o rii n a u k o w y c h .
2. Inżynieria w ym agań
78
Prototypowanie. Prototypowanie jest dziś efektywną techniką wspierającą ana lizę i zatwierdzanie wymagań oraz badanie wariantów różnych rozwiązań projekto wych. W historii informatyki był także okres, w którym próbowano zapisywać specy fikację wymagań w sposób wykonalny, badać ją jako prototyp programu, a następnie przekształcać w implementację za pom ocą automatycznych narzędzi (transformatio nal inipkm antation [15]). Jako języki specyfikacyjne wykorzystywano języki funk cyjne [237], sieci procesów [236] lub sieci Petriego [234, 235], Nurt ten nie osiągnął praktycznych sukcesów, ale metody formalnego modelowania za pomocą wymienio nych narzędzi są wciąż używane.
3 M etody strukturalne
Zarządzanie wymaganiami. Solidny opis problemów i technik zarządzania wymaganiami jest podany w [25]. Obszerny przegląd dostępnych na rynku narzędzi zarządzania wymaganiami można znaleźć w [31]. Po szczegóły trzeba jednak sięgnąć do dokumentacji konkretnych narzędzi, np. [37].,, Podstawą procesu wytwórczego, wykształconego przez metodykę strukturalną, jest dostrzeżenie i uznanie potrzeby zbudowania przed implementacją dwóch różnych modeli oprogramowania: abstrakcyjnego modelu analitycznego (essential model), opisującego przebieg przetwarzania danych w sposób niezależny od technologii reali zacyjnej, oraz konkretnego modelu projektowego (implemcntation model), poka zującego sposób wykonania tego przetwarzania w wybranej technologii realizacyjnej. Dopiero następnym krokiem procesu wytwórczego jest implementacja programów oraz integracja całości oprogramowania, dokonywana w sposób opisany w modelu projektowym. Takie wieloetapowe podejście ułatwia zapanowanie nad złożonością problemu dzięki rozdzieleniu zagadnień rozważanych na różnych etapach przedsięwzięcia. Opracowanie kolejnych modeli, opisujących budowane programy z coraz większą dokładnością, wyznacza podział całości prac na sekwencyjne, kolejno wykonywane fazy, wpisujące się w kaskadowy model wytwarzania oprogramowania.
t h ?
Najważniejsze elementy metodyki strukturalnej określają zestaw modeli przed stawiających istotne cechy oprogramowania na różnych poziomach szczegółowości, techniki modelowania wskazujące sposób i kolejność budowania modeli oraz metody weryfikacji poprawności i spójności kolejno powstających modeli. W spólną cechą modeli strukturalnych jest sposób opisywania przetwarzania, wyraźnie rozróżniający pasywne dane i aktywne działania, opisywane zgodnie z zasadą dekompozycji funk cjonalnej. Tak zorganizowany model dobrze odpowiada naturze strukturalnych języ ków programowania, w których podstawowymi jednostkam i synlaktycznymi są defi nicje danych (zmiennych) i działające na tych danych podprogramy.
3. M etody strukturalne
80
3 .1 .
N a rz ę d z ia m o d e lo w a n ia
Koncepcyjne narzędzia modelowania strukturalnego obejmują szereg diagramów odwzorowujących strukturę i relacje zachodzące między jednostkami danych oraz zależności zachodzące między procesami realizującymi wymagane przez użytkownika przetwarzanie. Podstawowymi rodzajami modeli, budowanymi w kolejnych krokach procesu wytwarzania oprogramowania, są: a hierarchia funkcji, przedstawiająca wymagania użytkownika zapisane w po staci listy funkcji do wykonania; ■ diagram przepływu danych, pokazujący funkcje oprogramowania oraz dane przepływające między tymi funkcjami w czasie realizacji przetwarzania; ■ diagram encji, obrazujący najważniejsze struktury danych podlegające prze twarzaniu oraz relacje istniejące między tymi strukturami; y ■ schemat struktury programu, pokazujący podprogramy realizujące funkcje oraz definiujący sposób wywoływania i przekazywania danych między pod programami. Wszystkie budowane modele mają czytelną postać graficzną i dobrze określone znaczenie odwołujące się do formalnych koncepcji matematycznych.
3 .1 .1 . H iera rc h ia funkcji Każdy, nawet bardzo złożony, proces przetwarzania danych można przedstawić w postaci zestawu funkcji, wykonywanych na opisujących ten proces danych. Jeżeli funkcje wchodzące w skład tego zestawu są nadal złożone, to można je dalej rozbić na kolejny zbiór funkcji prostszych. Na przykład, działanie dużej firmy ubezpieczeniowej można opisać jako złożenie funkcji wykonywanych przez poszczególne jej działy:
3.1. N arzędzia m odelow ania -A-...................... .........................
D ek o m p o zy cję funkcji m ożna k o n ty n u o w ać d o w o ln ie długo, o p isu jąc d ziałan ie p rze d się b io rstw a w co raz d ro b n iejszy c h szczegółach. N a przy k ład , o b słu g a inw estycji k ap itało w y ch m oże się sk ład ać z n astęp u jący ch elem en tó w : 2 .2.1. P rzeg ląd m o żliw o ści in w esto w an ia 2 .2 .2 . P rzy g o to w an ie zleceń in w esty cy jn y ch 2 .2 .3 . O k reso w a o cen a w y n ik ó w in w esto w an ia 2.2 .4 . ... K resem d ek o m p o zy c ji staje się o siąg n ięcie po zio m u funkcji elem en tarn y ch , tzn. takich, któ rych w y k o n an ie je s t c z y n n o ścią n iep o d zieln ą. Inaczej m ów iąc, funkcja e lem en tarn a m oże być w y k o n an a lub nie, ale nie m oże być w y k o n an a częściow o. N a p rzy k ład , z lec en ie in w esty cy jn e m o że być p raw ie przygotowane - p rzy g o to w an ie zleceń nie je s t w ięc fu n k cją elem en tarn ą. A le g o to w e zlec en ie zakupu akcji m oże być albo z ło żo n e na g iełdzie, albo nie. N ie m ożna go zło ży ć częścio w o . Z ło żen ie zlecenia na g iełd zie je st w ięc fu n k cją elem en tarn ą. W y n ik iem takiej sy stem aty czn ej, zstęp u jącej co raz niżej, d ek o m p o zy cji działań je s t hierarchia funkcji (hierarchy o f functions), p rz e d staw iająca ro zw ażan y proces p rzetw arzan ia d anych na w y b ran y m p o zio m ie szczeg ó ło w o ści. H ierarch ię funkcji m ożna z ap isać w sp o só b tek sto w y , w form ie p rzy p o m in ającej spis treści książki, albo g raficzn ie, w po staci sc h e m aty czn eg o ry su n k u (rys. 3.1). Z a le tą o p isu te k sto w eg o jest. brak o g ran iczeń na ro z m ia r m odelu o raz m o żliw o ść u z u p ełn ien ia nazw funkcji k ró t kim i, je d n o z d a n io w y m i k o m en tarzam i w y jaśn iający m i ich za k re s i przezn aczen ie. Z aletą m odelu g raficzn eg o jest m o żliw o ść zw arteg o p rz ed staw ien ia całości p rzetw a rzania na je d n e j kartce, m ożliw ej do o g arn ięcia jednym sp o jrzen ie m . N a ogól w y g o d nie je s t p rzy g o to w ać o b y d w ie form y m odelu.
1. Prowadzenie działalności ubezpieczeniowej 2. Prowadzenie działalności ekonomicznej 3. Zarządzanie
'
4 .. . .
I i Każdą z tych funkcji można opisać dokładniej w postaci złożenia prostszych funkcji wykonywanych przez różne komórki działu. Na przykład, prowadzenie dzia łalności ekonomicznej zawiera w sobie kilka rodzajów działań: 2 .1. Obsługa inwestycji 2.2. Obsługa inwestycji kapitałowych 2.3. Obsługa finansowo-księgowa 2.4. ...
81
R ysunek 3.1. Hierarchia funkcji firmy ubezpieczeniowej
82
3. M etody strukturalne
Warto podkreślić, że hierarchia funkcji jest modelem przedsiębiorstwa, a nie me nu systemu informatycznego. Model powstaje w fazie strategicznej, gdy nie jest jeszcze przesądzone, które funkcje będą w przyszłości wykonywane automatycznie, a które pozostaną przy realizacji ręcznej. Kluczowe decyzje dotyczące zakresu funk cjonalności budowanego oprogramowania wyraża się w tym modelu przez dodanie lub usunięcie wybranych funkcji. Podstawowe dane, na których mają działać funkcje, można opisać osobno, w formie tekstowej lub w postaci diagramu encji. Po podjęciu decyzji o realizacji systemu i jego zakresie hierarchia funkcji staje się naturalną czę ścią umowy realizacyjnej, opisującą wymagania funkcjonalne. Zaletami hierarchii funkcji są prostota, czytelność i przydatność podczas formu łowania zapisów umowy. Ze względu na swą prostotę model ma też ograniczenia, którymi są: brak pokazania zależności między funkcjami oraz brak pokazania danych, na których działają funkcje.
3.1.2. D iag ram p rzepływ u danych Diagram przepływu danych (data flo w diagram) jest znacznie dokładniejszym mode lem przetwarzania, pokazującym nie tylko funkcje, ale także dane, które muszą prze pływać w określonym porządku między funkcjami w celu wytworzenia pożądanych wyników. Model ma postać grafu (rys. 3.2), którego węzły reprezentują procesy przetwarzające (funkcje) oraz magazyny danych (zbiory), a luki skierowane pokazują przepływy danych między procesami i magazynami danych. Procesy, rysowane na diagramie w postaci okręgów, są elementami aktywnymi, które mogą pobierać dane z magazynów lub odbierać je od innych procesów, przetwarzać i przekazywać wyniki do magazynów lub do innych procesów. Magazyny, rysowane jako niedomknięte prostokąty, są elementami pasywnymi, które mogą tylko przechowywać dane.
3.1. N arzędzia m odelow ania
83
procesów. W ten sposób kolejne porcje danych przepływają przez diagram aż do momentu, w którym opuszczą system w postaci finalnych wyników przetwarzania. Semantyka diagramu nic określa kolejności wykonania procesów, które mogą wykonać się natychmiast, gdy tylko otrzymają wszystkie niezbędne do ich wykonania dane wejściowe. Na przykład, proces Rejestracja zamówienia na rys. 3.2 wykonuje się w chwili pojawienia się przepływu wejściowego Zamówienie. Wynikiem wykonania procesu jest zapisanie zarejestrowanego zamówienia w magazynie Zamówienia do realizacji. Ponieważ dane znajdujące się w magazynach są zawsze dostępne dla się gających po nie procesów, więc proces Planowanie wykonania może wykonać się ( w dowolnej chwili, niezwiązanej z tempem zapełniania magazynu. Procesy Wykona nie produktu i Wystawienie faktury mogą wykonać się dopiero po pojawieniu się wyników procesu Planowanie wykonania, ale porządek ich wykonania - równolegle lub jeden po drugim w dowolnej kolejności - pozostaje nieokreślony. Nieokreślony jest także mechanizm realizacji przepływów danych. Procesy występujące na diagramie przepływu danych mogą realizować funkcje proste lub złożone, podobnie jak funkcje występujące w hierarchii funkcji. Istotnym elementem opisu, którego diagram nie zawiera, jest specyfikacja przetwarzania proce su, czyli określenie sposobu przekształcania danych wejściowych w dane wyjściowe. Koniecznego uzupełnienia tego braku można dokonać na dwa sposoby: ■ przez dekompozycję złożonego procesu i pokazanie jego wewnętrznej struk tury na bardziej szczegółowym diagramie przepływu danych, ■ przez opisanie działania prostego procesu w języku naturalnym (np. polskim), w postaci graficznej (np. sieci działań), w pseudokodzie lub w notacji mate matycznej. Z a m ó w ie n ie ' d o rea liza cji
S ch em a t ko n stru kcji
Ó pfs te ch n iczn y
-
Z a m ó w ie n ie ko szto rys
.
...
^
T
T a ryfika to r czy n n o ści
Rysunek 3.3. Diagram 2: Planowanie wykonania R ysunek 3.2. Diagram przepływu danych
Przetwarzanie obrazowane przez diagram zaczyna się w chwili pojawienia się danych przenoszonych przez przepływy wejściowe. Dostępność danych wejściowych umożliwia wykonanie procesu, który realizuje przypisaną do niego funkcję i wytwarza wyniki przenoszone przez przepływy wyjściowe do magazynów lub do kolejnych
Przykładem dekompozycji może być rozbicie procesu Planowanie wykonania z rys. 3.2 na bardziej szczegółowe czynności opisane za pomocą diagramu pokazane go na rys. 3.3. Warto zauważyć, że na diagramie obrazującym strukturę procesu mogą pojawić się nie tylko procesy składowe, aie także wewnętrzne magazyny danych. Elementarnym warunkiem poprawności takiej dekompozycji jest zgodność przeply-
84
3. M etody strukturalne
wów wejściowych i wyjściowych dekomponowanego procesu z przepływami wej ściowymi i wyjściowymi opisującego ten proces diagramu. Dekompozycję procesów można powtórzyć wielokrotnie, budując wielopozio mową hierarchię diagramów, w której na najwyższym poziomie znajduje się diagram numer 0, przedstawiający całość przetwarzania (w naszym przykładzie jest to rys. 3.2), a na niższych poziomach występują diagramy modelujące poszczególne procesy z rysunku wyższego poziomu (rys. 3.4). Numer diagramu niższego poziomu odpowia da zawsze numerowi procesu na diagramie wyższego poziomu. Rozwijając hierarchię diagramów, należy dbać o spójność tego rozwinięcia - wszystkie przepływy łączące się z procesem na diagramie wyższego poziomu muszą mieć swoje odpowiedniki w przepływach wchodzących lub wychodzących z diagramu rozwijającego ten proces na niższym poziomie. Proces dekompozycji można kontynuować dowolnie długo, aż do osiągnięcia takiego poziomu szczegółowości, na którym bez trudu można opisać działanie wszystkich procesów składowych. Opisy procesów znajdujących się na diagramach najniższego poziomu, zwykle zajmujące co-najwyżej jedną stronę papieru, nazywa się minispecyfikacjanii.
3 . 1. N a r z ę d z i a m o d e l o w a n i a
85
3.1.3. D iag ram encji Funkcje realizowane przez oprogramowanie systemu informatycznego działają na danych, które opisują fragmenty świata objęte działaniem systemu. W tym świecie występują rozmaite obiekty, np. klienci, towary i zamówienia w przedsiębiorstwie handlowym, które można opisać według pewnego schematu. Na przykład, każdy klient przedsiębiorstwa ma nazwę i adres, każdy towar jest charakteryzowany przez nazwę, nazwę producenta i cenę, a każde zamówienie ma datę wystawienia i adres dostawy. Pojedyncze elementy opisu, takie jak nazwa, adres lub cena, są nazywane atry b u ta m i obiektu. Kategoria obiektów opisywanych za pomocą tego samego zbioru atrybutów jest nazywana cncją (entity). W ten sposób każda encja opisuje pewien rodzaj obiektów, charakteryzowanych w dziedzinie zastosowania przez ustalony zestaw atrybutów. Obiekty różnego rodzaju są na ogól opisywane przez różne zestawy atrybutów (tzn. tworzą różne encjc), nato miast obiekty tego samego rodzaju są opisywane przez te same atrybuty. Zbiór atry butów obiektu powinien być tak dobrany, aby różnym obiektom danego rodzaju odpowiadały różne wartości atrybutów - obiekty o tych samych wartościach atrybu tów są niemożliwe do odróżnienia. Przykładowy opis towarów sprzedawanych w sklepie z oponami samochodowymi jest pokazany na rys. 3.5. Można zauważyć, że wartości atrybutów nie pokrywają się dla żadnych dwócli rodzajów opon. Mimo to żaden atrybut nie identyfikuje jednoznacznie towaru i aby wskazać pożądany typ opony, trzeba podać wartości trzech różnych atrybutów. Nie jest to wygodne w praktyce, dlatego w tabeli opon dodany został dodatkowy atrybutnumer katalogowy, który jednoznacznie identyfikuje konkretny typ opony. Atrybut, którego wartość jednoznacznie wskazuje obiekt encji, jest nazywany kluczem. Numer 1 2 3 4 5
Producent Michelin Michelin Kleber Pirelli Uniroyal
Nazwa Alpin A3 Alpin A3 Krisalp Hp W19Q Snowsport MS Plus 55
Rozmiar 175/65 R14 195/60 R15 195/65 R15 195/60 R15 215/65 R15
Cena 315,00 416,00 315,00 392,84 424,56
Towar
tt numer producent nazwa rozm iar cena
Rysunek 3.5. Lista towarów sklepu i model opisu tych danych w postaci encji Towar Rysunek 3.4. Hierarchiczna organizacja diagramów przepływu danych 'I Diagram przepływu danych jest modelem analitycznym, niezależnym od tech nologii realizacji przetwarzania. Można go wykorzystać do modelowania zarówno działań przedsiębiorstwa, jak i oprogramowania. Zasadniczą wartością modelu jest dekompozycja całości przetwarzania na dobrze określone jednostki (procesy i maga zyny danych) oraz pokazanie wzajemnych powiązań tych jednostek. Model jest intu icyjny i zrozumiały dla czytelnika bez specjalistycznego przygotowania.
Opisanie sposobu działania, a później zbudowanie oprogramowania wymaga zdefiniowania nie tylko wszystkich encji i ich atrybutów, lecz także zależności istnie jących między obiektami poszczególnych encji. We wspomnianym wyżej przedsię biorstwie handlowym zamówienia nie biorą się z powietrza, lecz są składane przez konkretnych klientów. Z kolei celem złożenia zamówienia jest wskazanie pewnych towarów, które dany klient ma zamiar zakupić. Między klientami, zamówieniami i towarami istnieją więc zależności, które nadają sens ich istnieniu.
86
3. M etody strukturalne
Modelem danych obrazującym encje i ich powiązania jest diagram encji (enlity-relationship diagram.), zwany też diagramem encja-związek bądź diagramem związ ków encji, pokazany przykładowo na rys. 3.6. Podstawowymi elementami diagramu są encje, rysowane w postaci prostokątów z wpisaną wewnątrz nazwą encji i listą atrybutów, oraz związki (relacje) występujące między encjami, przedstawiane jako linie łączące encje. Fakt istnienia związku między dwoma encjami oznacza, że pewne obiekty jednej encji są w jakiś sposób powiązane z pewnymi obiektami drugiej encji. Na przykład, każde zamówienie zostało wystawione przez jakiegoś klienta - tym samym każde konkretne zamówienie (każdy obiekt encji Zamówienie) jest jedno znacznie związane z konkretnym klientem, który to zamówienie wystawił. Podobnie, każde zamówienie jest jednoznacznie związane z zestawem towarów, których to zamówienie dotyczy.
R ysunek 3.6. Diagram encji przedstawiający związki łączące różne obiekty w systemie sprzedaży
Charakter związku łączącego dwie encje można opisać na diagramie za pomocą nazwy, wyjaśniającej rolę tego związku w rzeczywistym świecie. Nazwę umieszcza się na ogół w pobliżu encji (blisko końca linii) i interpretuje z jej punktu widzenia. Taka konwencja zapisu umożliwia opisywanie zależności między danymi w zrozu miałym języku naturalnym, np.: Klient składa Zamówienie, Zamówienie wskazuje Towar, co bardzo ułatwia analitykom komunikację z użytkownikami i znacząco podnosi wiarygodność dokonywanej przez nich weryfikacji modelu. Niektóre narzę dzia wspomagające proces opracowania oprogramowania mogą generować opisy w języku naturalnym automatycznie, na podstawie diagramu encji. Inne symbole, jakie mogą wystąpić przy końcach linii oznaczającej związek, tzn. poprzeczna kreska, „kurza łapka” i kółko, określają liczbę obiektów danej encji, które mogą być związane z każdym obiektem encji znajdującej się na drugim końcu linii. W większości przypadków na końcu linii występują dwa ęymbole, określające naj mniejszą i największą dozwoloną liczbę obiektów. W przyjętej konwencji oznaczeń kółko oznacza 0, poprzeczna kreska 1, a „kurza łapka” wskazuje, że w związku może uczestniczyć wiele obiektów, W ten sposób, zgodnie z modelem przedstawionym na rys. 3.6, każde Zamówienie jest złożone przez jednego Klienta. Nie ma zamówień, których nikt nie zlożyl, nie ma też zamówień złożonych łącznie przez kilku klientów. Natomiast każdy klient mógł ziożyć wiele zamówień, ale mógł też jeszcze nie złożyć żadnego. Z kolei każde Zamówienie może wskazywać wiele Towarów, jednak nie mniej niż jeden (nie ma zamówień, które nie wskazują żadnego towaru). Podobnie, każdy Towar może być wskazany w wielu Zamówieniach. Natomiast tego, czy mogą
3.1. N arzędzia m odelow ania 4 _ ----------------------------------------
87
istnieć towary, które nie są wskazane w żadnym zamówieniu, model nie mówi - być może na tym etapie prac jeszcze tego nie wiemy. Podczas budowy modelu danych mogą pojawić się encje, które nie są zupełnie jednorodne. Na przykład, wśród towarów sklepu motoryzacyjnego - charakteryzowa nych zawsze przez nazwę, nazwę producenta i cenę - mogą się znaleźć opony cha rakteryzowane dodatkowo przez rozmiar, foteliki dziecięce charakteryzowane przez wagę dziecka i dodatkowy opis oraz różne drobne akcesoria, takie jak kamizelki odblaskowe, które poza opisem tekstowym żadnych innych atrybutów nie mają. Różne listy atrybutów oznaczają, że w istocie mamy do czynienia z różnymi encjami, , które opisują różne szczególne przypadki Towaru: Opony, Foteliki, Pokrowce itd. Takie sytuacje opisuje się w modelu za pomocą specjalnej notacji pokazanej na rys. 3.7. Łatwo zauważyć, że encja Towar grupuje atrybuty wspólne dla całej kategorii produktów, podczas gdy pozostałe encje zawierają wyłącznic atrybuty wyróżniające produkty konkretnego rodzaju. W ten sposób encja Towar jest uogólnieniem wszyst' kich konkretnych rodzajów towaru. Semantyka związku uogólnienia zawiera w sobie regułę dziedziczenia: każdy obiekt typu szczegółowego, np. Opona lub Fotelik, jest szczególnym przypadkiem typu ogólnego, po którym dziedziczy wszystkie atrybuty i wszystkie związki. Zatem, zgodnie z rys. 3.6 i 3.7, każda opona i każdy fotelik mogą być wskazane w zamówieniu jakiegoś klienta.
Atrybuty opony: - nazwa - producent - cena - rozmiar
Atrybuty fotelika: - nazwa - producent - cena ■ waga_dziecka - opis
Rysunek 3.7. Modelowanie związku uogólnienia (towar i jego szczególne przykłady)
Diagram encji nie ma reprezentacji hierarchicznej. Jeżeli rysunek staje się zbyt duży, można go po prostu podzielić na części, tworząc np. odrębne diagramy danych wykorzystywanych przez różne działy przedsiębiorstwa. Bardzo często dla oszczędno ści miejsca pokazuje się na diagramie tylko nazwy encji, bez wyliczania ich atrybutów (które w takim przypadku trzeba udokumentować osobno).
3.1.4. S ch em a t struktury Analityczne modele przetwarzania, takie jak hierarchia funkcji i diagram przepływu danych, opisują dokładnie, co ma być zrobione, nie wyjaśniają jednak wcale, ja k nut
f 88
3. M etody strukturalne
być zbudowany program, który to przetwarzanie wykona. Schemat struktury programu (siriicture chart) jest modelem projektowym, który przedstawia budowę programu. Najważniejszymi elementami modelu są: podprogramy, rysowane jako prostokąty; wywołania podprogramów, rysowane jako strzałki z zaznaczonymi obok argumentami i wynikami wywołań; zbiory i wspólne struktury danych, rysowane jako skośne równoległoboki lub prostokąty przylegające do podprogramów. Przykładowy schemat struktury programu ustawiającego przebieg wjazdowy (tzn. drogę wjazdu pociągu) na komputerowo sterowanej stacji kolejowej jest pokazany na rys. 3.8. Widoczny na rysunku łącznik ERR umożliwia kontynuowanie schematu na innym rysunku.
3.2. T echniki analizy strategicznej
89
program Odczytanie położenia pociągu jakichś funkcji korekcyjnych (opisanych na odrębnym schemacie wskazanym przez łącznik ERR). Warto zauważyć, że chociaż podprogram Przestawienie zwrotnicy może być wielokrotnie wywołany wewnątrz programu Ustawienie przebiegu, to na schemacie rysuje się tylko jedrtą strzałkę wywołania. Niektóre metody przewidują jednak umieszczanie na schematach struktury dodatkowych wyróżnień oznaczających wy wołania warunkowe lub wielokrotne. Schemat struktury jest modelem graficznym obrazującym najważniejsze jednost ki programowe oraz sposób ich wzajemnej współpracy. Koniecznym uzupełnieniem schematu, niezbędnym dla implementacji programu, jest opis algorytmów działania podprogramów, tzn. opis sposobu przekształcania danych wejściowych, otrzymywa nych podczas wywołania podprogramu, w wyniki. Źródłem informacji niezbędnych do opracowania takich specyfikacji jednostek są minispecyfikacje procesów przenie sione tu z modelu analitycznego.
3.2.
T e c h n ik i a n a liz y s tra te g ic zn e ]
Pierwszym krokiem prac, poprzedzającym przystąpienie do opracowania oprogramo wania systemu informatycznego, jest określenie roli i zakresu działania systemu, zdefiniowanie zadań, jakie ma on wypełniać na rzecz otoczenia, oraz określenie wielkości i wydajności przetwarzania. Zebranie i udokumentowanie tych informacji umożliwia ocenę kosztów opracowania systemu, analizę opłacalności i podjęcie decyzji o realizacji przedsięwzięcia (podpisanie umowy) łub jego zaniechaniu.
R ysunek 3.8. Schemat struktury programu ustawiającego drogę wjazdu pociągu na stację
Nietrudno zauważyć, że postać schematu struktury jęsl dopasowana do składni strukturalnych języków programowania, takich jak C, Pascal lub Fortran, których podstawowe jednostki syntaktyczne odpowiadają bezpośrednio elementom rtiodelu. Zgodnie ze schematem program Ustawienie przebiegu wjazdowego wywołuje trzy podprogramy: Odczytanie położenia pociągu, Odczytanie nakładu jazdy i Ustawienie przebiegu. Pierwszy z tych podprogramów zwraca w wynil)u numer i pozycję wjeż dżającego pociągu, drugi odczytuje ze zbioru Rozkład jazdyhm m er przebiegu przewi dzianego dla pociągu o podanym numerze, a trzeci ustawia zwrotnice wchodzące w skład wybranego przebiegu. Argumenty i wyniki wywołań, wyróżnione zaczernionym kółeczkiem, pełnią rolę sterującą - od ich wartości zależy rodzaj działali, które będą dalej podjęte. Na przy kład, błąd weryfikacji położenia pociągu może spowodować wywołanie przez pod
W większości przypadków, z jakimi mamy do czynienia w biznesie, administra cji i innych dziedzinach działalności człowieka, systemy informatyczne są budowane w celu usprawnienia, rozszerzenia lub zastąpienia części działań wykonywanych dotychczas w inny sposób. Taka sytuacja występuje podczas informatyzacji banków, przedsiębiorstw produkcyjnych, organów administracji publicznej, a także przy opra cowaniu np. kolejnych wersji gier fabularnych, w które można grać z komputerem albo z innymi osobami. Dokładny zakres działań systemu w nowej strukturze organi zacji nie jest często na początku prac przesądzony. Racjonalne podejście analizy strategicznej polega na ustaleniu wszystkich czynności, jakie występują w organizacji, a następnie określeniu, które z nich mają znaleźć się w zakresie działania nowego systemu, a które mają pozostać na zewnątrz. Odpowiedź na tak postawione pytanie wyznacza granice przyszłej aplikacji i wskazuje wymagane funkcje oprogramowania. Kolejnym krokiem może być określenie niezbędnej wydajności przetwarzania oraz innych wymagań niefunkcjonalnych i na tej podstawie oszacowanie pracochłonności oraz kosztu opracowania oprogramowania spełniającego wszystkie tak określone wymagania.
3. M etody strukturalne
90
Podstawowe modele tworzone podczas analizy strategicznej obejmują hierarchię funkcji, opisującą wymagany zakres przetwarzania, oraz diagramy encji, przedsta wiające strukturę przetwarzanych danych. Hierarchia funkcji powstaje w wyniku dekompozycji opisu całości przetwarzania i wyodrębnienia poszczególnych funkcji. Diagram encji jest wynikiem ustalenia najważniejszych rodzajów danych oraz opisa nia ich struktury wewnętrznej i istniejących między nimi powiązań. Obydwa modele powstają stopniowo i na każdym etapie pracy odzwierciedlają bieżącą wiedzę anality ków na temat sposobu rozwiązania problemu. Dalsza część rozdziału opisuje sposób tworzenia i wykorzystania modeli struktu ralnych u' kolejnych Jazach procesu wytwarzania oprogramowania dla przykładowego przedsiębiorstwa handlowego, którym jest firm a zajmująca się wysyłkową sprzedażą akcesoriów samochodowych, takich ja k opony, felgi, bagażniki itp. Pełny katalog oferowanych towarów jest dostępny w witrynie internetowej. Firma przyjmuje zamó wienia klientów nadsyłane pocztą elektroniczną i wysyła zamówione towary pocztą kurierską. Każde przyjęte zamówienie jest potwierdzane e-mailem, którego treski określa również, form ę płatności. Zamówienia o wartości nieprz.ekraczającej pewnej sumy są opłacane przez, klienta przy odbiorze. Zamówienia o większej wartości klient opłaca przelewem, przed wysłaniem towaru, na podstawie wystawionej przez, .firmę faktury pro forma. W przypadku zamówień małych, lecz dotyczących towarów niety powych wymagane jest wpłacenie zaliczki. Firma, ma nowy i wydajny system księgowy oraz starą aplikację magazynową. Cały proces obsługi zamówień jest realizowany ręcznie. Ogromny wzrost sprzedaży zmusił kierownict wo firm y do unowocześnienia jej struktury i wsparcia działań pracowników narzędziami, informatycznymi. Przy okazji postanowiono dopuścić możliwość składania, zamówień na formularzach interneto wych, choć nie zdecydowano się na prowadzenie typowej sprzedaży przez Internet dla z.rrzrfinzyznia ryzyka reklamacji, sklep zachęca do podawania w zamówieniu typu pojazdu klienta, co umożliwia pracownikom weryfikację zgodności, zamówienia z intencjami klienta. Biznesowym, celem przedsięwzięcia jest redukcja kosztów (spadek zatrudnienia i wzrost wydajności pracy) oraz zwiększenie obrotów dzięki ułatwieniu komunikacji z klientami.
o rozważanym zadaniu. Przykład wstępnego, jeszcze niekompletnego, modelu działa nia przedsiębiorstwa sprzedaży wysyłkowej przedstawia rys. 3.9. Całość działań związanych z prowadzeniem przedsiębiorstwa wysyłkowego jest tu rozbita na pięć głównych funkcji, wykonywanych przez różne działy firmy: reklamy, zaopatrzenia, obsługi magazynu towarów, sprzedaży i zarządzania finansami. Ta ostatnia funkcja obejmuje ważne czynności rozliczenia z dostawcami i klientami.
Rysunek 3.9. W stępna hierarchia funkcji przedsiębiorstwa sprzedaży wysyłkowej
Taki model może powstać już pierwszego dnia analizy, po zapoznaniu się ze schematem organizacyjnym przedsiębiorstwa i rozmowie z jego szefem. Model nie jest jeszcze kompletny - przerywane linie na diagramie sugerują potrzebę dalszej dekompozycji funkcji - jednak tworzy dobrą podstawę do dalszych działań. Hierar chia funkcji jest modelem bardzo intuicyjnym i zrozumiałym dla każdego, bez wiciu dodatkowych wyjaśnień. Przystępując do przeprowadzenia kolejnych wywiatlów, można posłużyć się tym modelem w celu uściślenia rozmowy i uzyskania od roz mówcy potwierdzenia swojej wizji przedsiębiorstwa.
Głównym problemem analizy strategicznej jest pozyskanie |uporządkow anie wiedzy na temat dziedziny zastosowania i wymagań przyszłych użytkowników oprogramo wania. Podstawowe metody pozyskiwania wiedzy obejmują lekturę dostępnych do kumentów oraz rozmowy z użytkownikami i sponsorami projektu (por. podrozdział 2.3). Sposobem porządkowania stopniowo gromadzonej wiedzy jest modelowanie wymagań w postaci hierarchii funkcji.
Kolejne wywiady z użytkownikiem i obserwacja przedsiębiorstwa mogą kory gować pierwotne wyobrażenia o jego funkcjonowaniu. Co więcej, może się okazać, że wbrew dotychczasowej tradycji i organizacji przedsiębiorstwa pewne funkcje są tak powiązane, żc nie ma powodu, by traktować je oddzielnie. W takim przypadku można zmodyfikować model, łącząc ze sobą pokrewne funkcje - końcowym celem analizy nie jest przecież wierne odwzorowanie istniejącego systemu przetwarzania, lecz zbudowanie takiego systemu, który najlepiej pasuje do profilu działania przedsiębior stwa. Podobnie, może się też okazać, że nie od razu dostrzeżemy wszystkie funkcje przedsiębiorstwa i obecność oraz znaczenie niektórych funkcji odkryjemy dopiero po pewnym czasie. Na przykład, w modelu z rys. 3.9 brakuje zapewne funkcji związa nych z zarządzaniem personelem - rekrutacją pracowników, rozliczaniem wynagro dzeń, planowaniem urlopów i dni wolnych itp.
Dobra hierarchia funkcji nie powstaje od razu. Wręcz przeciwnie, model jest rozwijany stopniowo i doskonalony w miarę postępów analizy i wzrostu wiedzy
Po zebraniu większej liczby danych, pochodzących z obserwacji i wywiadów przeprowadzonych z kierownikami działów firmy, można zbudować kolejny model
3.2.1. M o d elo w a n ie p rzetw arzan ia
^
92
3. M etody strukturalne
przetwarzania, zawierający dokładniejszą hierarchię funkcji. W tym miejscu trzeba jednak podkreślić, że budowany model nie powinien stać się nadmiernie szczegółowy. Celem analizy strategicznej nie jest zebranie i opisanie wszystkich szczegółów prze twarzania, lecz uchwycenie i skonstruowanie syntetycznego obrazu, który umożliwi zdefiniowanie zakresu pracy oraz oszacowanie jej pracochłonności i kosztu. Nie ma sztywnych reguł, ale w większości przypadków wystarczy rozwinięcie hierarchii funkcji do trzech [207] lub co najwyżej czterech poziomów. Model trzeba jednak uzupełnić opisem słownym określającym sposób wykonania funkcji. W tym celu dla każdej funkcji na najniższym poziomie hierarchii można podać np.: ■ zdarzenie inicjujące i szacunkową częstość wykonania funkcji, B słowny opis sposobu wykonania, B kluczowe dane wprowadzane lub wytwarzane przez tę funkcję.
3.2. T echniki analizy strategicznej
93
Na przykład, jeśli w rozważanym przedsiębiorstwie sprzedaży wysyłkowej ist nieje dobrze działająca aplikacja księgowa, to kierownictwo firmy prawdopodobnie nie uzna tego obszaru działania za priorytetowy kierunek zmian. Również ręczna organizacja załatwiania spraw pracowniczych może - zdaniem kierownictwa firmy nie wymagać jakichkolwiek udoskonaleń, podobnie jak proces wybierania nowych towarów i wyszukiwania dostawców. Priorytetowym polem działania firmy jest: sprzedaż i jej najbliższe otoczenie, które wymagają pilnego unowocześnienia. Zakres zmian obejmie więc pełną automatyzację obiegu związanych z tym procesem doku mentów oraz wprowadzenie możliwości przyjmowania zamówień składanych przez Internet. Ze względu na niską stopę zwrotów i reklamacji zdecydowano także o wyłą czeniu obsługi tego procesu z zasięgu planowanego systemu. Wynikający z tych decyzji zakres budowanego systemu jest pokazany na rys. 3.10. Podjęcie decyzji dotyczących zakresu działań przedsiębiorstwa objętych działa niem systemu umożliwia sformułowanie, wymagań funkcjonalnych, które zostaną zapisane w umowie na opracowanie oprogramowania: 1. Obsługa przepływu towarów 1.1. Zamawianie towarów u dostawców 1.2. Przyjmowanie dostaw towarów 1.3. Składowanie towarów 1.4. Wysyłanie towarów klientom 2. Obsługa klientów 2.1. Przyjmowanie zamówień
___
2.2. Określenie sposobu płatności
3.2.2. M o d elo w a n ie danych
Rysunek 3.10. Ostateczna hierarchia funkcji przedsiębiorstwa sprzedaży wysyłkowej
Hierarchia funkcji przedstawiona na rys. 3.10 modeluje działanie przedsiębior stwa wystarczająco dokładnie, aby na jej podstawie sformułować strategię działania. Można w tym celu nałożyć na tę hierarchię obszary objęte działaniem już istniejących systemów i w ten sposób znaleźć istniejące między nimi luki i ewentualne redundan cje. Porównując wyniki tej analizy z priorytetami i możliwościami firmy, można podjąć decyzję o pozostawieniu pewnych czynności do realizacji ręcznej i - ostatecz nie - wytyczyć zakres nowego projektu.
himkcje są elementami procesu przetwarzania danych. Równie ważnym elementem tego procesu są dane, których wartości - ustalone w wyniku działania funkcji - opi sują stan dziedziny zastosowania: banku, przedsiębiorstwa produkcyjnego albo gry komputerowej. Dlatego podczas analizy strategicznej nie należy koncentrować się tylko na definiowaniu funkcji, ale równolegle z odkrywaniem funkcji starać się odnaj dywać i klasyfikować dane oraz dokumentować istniejące między tymi danymi po wiązania. Sposobem porządkowania stopniowo gromadzonej wiedzy jest modelowa nie danych w postaci diagramów encji. Odnalezienie najważniejszych encji następuje często podczas analizy obiegu do kumentów w realnym świecie. Niektóre encje wprost odpowiadają dokumentom krążącym w przedsiębiorstwie. Mogą to być np. zamówienia, faktury, noty magazy nowe, opisy klientów i dostawców. Inne ważne encje można znaleźć, analizując treść wywiadów, przeprowadzonych z użytkownikami, zgodnie z prostą zasadą: rzeczow
3. M etody .strukturalne
94
3 2. Techniki analizy strategicznej
95
- Y ------------------------------------- :---------------------------------------------------------------------— niki pojawiające się w opisach działania mogą okazać się nazwami encji, a czasowniki odnoszące się do encji mogą okazać się nazwami związków encji.
■ spodziewaną liczbę obiektów encji, jakie mogą pojawić się w systemie, oraz rozmiar pojedynczego obiektu;
Podobnie jak hierarchia funkcji, diagram encji nie powstaje od razu. Jest rozwi jany stopniowo i doskonalony w miarę postępów analizy i odkrywania nowych encji i nowych związków. Trzeba jednak pamiętać, że osiągnięcie celów analizy strategicz nej nie wymaga zbudowania diagramu encji pokazującego strukturę wszystkich przetwarzanych danych. Przeciwnie, model powinien pokazać tylko najważniejsze encje, których obecność jest niezbędna dla zrozumienia logiki działania systemu i które w największym stopniu wpływają na ilość danych gromadzonych i przetwarza nych przez oprogramowanie. Model może nie uwzględniać części atrybutów, a niektó re encje mogą być narysowane w ogóle bez wyliczenia atrybutów. Na tym etapie pracy nie ma też potrzeby budowania jednego spójnego diagramu obejmującego wszystkie znalezione encje. Bardzo często buduje się odrębne modele danych funk cjonujących w różnych działach przedsiębiorstwa. Takie podejście może ułatwić proces weryfikacji, gdyż użytkownicy pracujący w różnych działach najlepiej znają te rodzaje danych, z którymi mają do czynienia w swojej codziennej pracy.
■ wymagany okres przechowywania obiektów oraz dodatkowe wymagania do tyczące archiwizacji obiektów historycznych;
Przykładowy diagram encji, opisujący dane podlegające przetwarzaniu w przed siębiorstwie sprzedaży wysyłkowej, jest przedstawiony na rys. 3.11. Model jest dość zgrubny, ale obrazuje strukturę danych wystarczająco dokładnie, aby na jego podsta wie ocenić stopień złożoności oraz rozmiar danych niezbędnych dla prawidłowego wykonania funkcji wchodzących w skład procesu obsługi sprzedaży. W tym celu trzeba jednak uzupełnić diagram dodatkowym opisem słownym, określającym prze znaczenie i rozmiar poszczególnych encji. Dla każdej encji można podać np.: odbiera
za w iera ------------------------Przesyłka realizuje dotyczy -< j
składa Zamówienie
Y
odnosi się do sklada
opisuje Katalog
zawiera V I ------------------------------- Dostawa
dotyczy
Reklamacja
wysyła
Y realizuje określa ^ Zamówienie zaopatrzeniowe
otrzymuje
Rysunek 3.11. Diagram encji obrazujący dane funkcji obsługi magazynu i sprzedaży (model fazy strategicznej)
* tempo napływu obiektów encji do systemu, mierzone liczbą obiektów w jed nostce czasu (średnie, maksymalne). Hierarchia funkcji i diagram encji opisują dwa aspekty oprogramowania - wyko nywane działania i przetwarzane dane. Obydwa modele odnoszą się do tego samego systemu i powinny być ze sobą zgodne. Weryfikacja zgodności, możliwa na tym ¿tąpie prac, polega na sprawdzeniu, czy funkcje występujące w hierarchii realizują wszystkie podstawowe operacje dotyczące danych, tzn.: tworzenie obiektów encji (icreate), odczytywanie wartości atrybutów (read), zmienianie wartości atrybutów (,upclate) i usuwanie obiektów encji (delete). Wygodnym narzędziem takiej weryfikacji jest macierz koincydencji, której wiersze odpowiadają encjom, kolumny funkcjom, a kratki - odpowiadające parom złożonym z funkcji i encji - pokazują operacje wyko nywane przez tę funkcję na danej encji. Weryfikacja polega na sprawdzeniu, czy każda encja jest potrzebna do wykonania jakiejś funkcji, czy każda funkcja przetwarza dane zapisane w jakiejś encji oraz czy łączny zbiór operacji wpisanych w każdym wierszu zawiera wszystkie cztery operacje realizujące pełny cykl życia cncji. Ponie waż do kratek macierzy koincydencji wpisuje się zazwyczaj pierwsze litery angiel skich nazw operacji, macierz ta jest często nazywana macierzą CRUD. Macierz CRUD modelu przedsiębiorstwa sprzedaży wysyłkowej jest pokazana w tab. 3.1. Jak wynika z tabeli, model nie spełnia wszystkich kryteriów weryfikacji, gdyż nie ma w nim żadnej funkcji usuwającej opisy klientów, żadnej funkcji usuwają cej opisy dostaw ani funkcji tworzącej i usuwającej opisy dostawców. Nie znaczy to jeszcze, że model jest błędny - jednak każda z tych sytuacji wymaga wyjaśnienia. W tym przykładzie wszystkie wymienione braki można łatwo wyjaśnić, gdyż operacje usunięcia opisu klienta oraz utworzenia i usunięcia opisu dostawcy mogą być wyko nane wyłącznie w trybie operacji ręcznej, natomiast opisy dostaw są tworzone w chwili przyjęcia dostawy, nigdy nie podlegają modyfikacji, a ich usunięcie nastę puje w innym trybie, po upływie 2 lat od daty przyjęcia dostawy. Zweryfikowane i uzgodnione z użytkownikiem modele hierarchii funkcji i dia gramów encji określają łącznie zakres przetwarzania wymaganego od budowanego oprogramowania. Zawarta w tych modelach informacja, uzupełniona opisem rozmiaru danych i sposobu wykonania funkcji, umożliwia oszacowanie rozmiarów przyszłego systemu, zaproponowanie jego architektury sprzętowej i określenie pracochłonności wykonania. W większości przypadków taki zestaw danych pozwala na podjęcie decy zji o rozpoczęciu lub zaniechaniu przedsięwzięcia.
3. M etody strukturalne
96
T abela 3.1. Macierz CRUD kojarząca funkcje z encjami modelu danych Przyjm owanie
Składowanie
Wysyłanie
Przyjmowanie
Określanie
towarów
dostaw
towarów
towarów
zamówień
płatności
Towar
CRD
RU
RU
RU
R
Katalog
CRUD
R
R
R
R
RUD
CR
RU
Zam awianie
Zam ówienie
CRUD
Przesyłka
R
Klient Zam ówienie
CRUD
CRU
R
zaopatrzeniowe CR
Dostawa Dostawca
RU
R
R
♦
3 .2 .3 . S c h e m a t kontekstu Określenie funkcji i danych przetwarzanych przez oprogramowanie pozwala wyzna czyć granicę oddzielającą to, co dzieje się wewnątrz budowanego systemu, od ze wnętrznego otoczenia, w którym znajdują się użytkownicy oraz inne systemy współ pracujące. Wyraźne zdefiniowanie tej granicy i wyjaśnienie, jakie dane wpływają do budowanego systemu i w jaki sposób system ma na te dane odpowiadać, jest ważnym czynnikiem określenia wymagań wyznaczających sposób działania oprogramowania. Graficznym modelem opisującym zewnętrzne otoczenie systemu jest schemat
3.2. T echniki analizy strategicznej ~
97 *
“
"
systemu będzie w tym wypadku Klient, czy raczej Przeglądarka internetowa, która jest urządzeniem bezpośrednio współpracującym z systemem'? W większości przy padków lepszym wyborem jest pokazanie w modelu użytkownika końcowego, tzn. człowieka, a nie urządzenia lub programu sprzęgającego system z tym użytkowni kiem. Wyeksponowanie urządzenia uzależnia model od konkretnej techniki realizacji sprzęgu systemu z otoczeniem. Odsunięcie tych szczegółów realizacyjnych prowadzi do stabilnego modelu analitycznego, niewrażliwego na zmiany technologii realizacyjnej. Kolejna wątpliwość dotyczy operatorów systemu. Klienci przysyłający zamó wienia pocztą elektroniczną nie mają bezpośredniego kontaktu z systemem. W komu nikacji pośredniczy Operator, który odbiera e-maile i wpisuje zamówienia do syste mu. Czy należy uwzględnić jego obecność w modelu'? Odpowiedź na to pytanie jest podobna do poprzedniej. Model analizy strategicznej reprezentuje biznesowy punkt widzenia budowanego systemu. Z tej perspektywy operator systemu jest tylko ele mentem realizacji sprzęgu systemu z użytkownikiem biznesowym. Jego obecność w modelu analitycznym uzależniłaby ten model od konkretnej organizacji sprzęgu. Dzięki przyjęciu takich reguł budowy modelu schemat kontekstu może stać się całkowicie niezależny od konkretnej techniki realizacji sprzęgu systemu z otoczeniem. Rzeczywista technologia realizacji sprzęgu zostanie pokazana dopiero na późniejszych etapach projektu. W przykładowym przedsiębiorstwie sprzedaży wysyłkowej można wyróżnić dwa terminatory: Klient i Dostawca. Schemat kontekstu systemu jest pokazany na rys. 3.12.
Klient
Zamówienie, Płatność .......... . . /
Zamówienie zaopatrzeniowe, \ ............Zaplata ..............4. Dostawca System \ I sprzedaży )
W
V Towar, Faktura
\ ^ s y lk °w e | y T
Towar, Faktura ......
kontekstu (conlext diagram). Elementami modelu są: ■ cały budowany system, przedstawiany na ogól w postaci okręgu; " obiekty współpracujące, tzn. ludzie i inne systemy, przedstawiane w postaci prostokątnych terminatorów (nazywanych też encjami zewnętrznymi); ■ przepływy danych przekraczające granicę systemu, przedstawiane za 'pomocą strzałek łączących system z terminatorami. j Kierunki strzałek obrazujących przepływy danych między systemem a terminato rami pokazują, relację producent-konsument, przy czym zak|ada się, że konsument jest zawsze gotowy do przyjęcia danych - nie ma ukrytych magazynów związanych ze strzałkami. Mimo koncepcyjnej prostoty modelu jego budowa - w tym zwłaszcza wybór terminatorów - nie zawsze jest oczywista. System budowany dla przykładowego przedsiębiorstwa sprzedaży wysyłkowej na pewno musi obsługiwać klientów. Niektó rzy z nich będą składać zamówienia przez Internet. Czy właściwym terminatorem
Rysunek 3.12. Schemat kontekstu przedsiębiorstwa sprzedaży wysyłkowej
Podobnie jak w przypadku diagramów encji, niezbędnym uzupełnieniem sche matu kontekstu jest opis tekstowy obejmujący przede wszystkim: ■ narracyjny opis przeznaczenia i celu budowy systemu; ■ opis przepływów danych, z podaniem wszystkich znanych szczegółów struk tury danych i oszacowań ich rozmiaru; ■ lista atrybutów systemu (wymagań niefunkcjonalnych), takich jak szybkość działania, wydajność i niezawodność. Jeżeli schemat kontekstu jest bardzo duży, to można go podzielić na fragmenty zawierające segmenty kola obrazującego opisywany system. Notację schematu kon tekstu można też wykorzystać do przedstawienia przepływów materiału, energii lub
’
3.3. Techniki analizy strukturalnej
3. M etody strukturalne
98
!\
Schemat kontekstu można uważać za dodatkowy poziom modelu diagramów przepływu danych, usytuowany powyżej całej hierarchii diagramów.
Podstawowymi narzędziami modelowania wykorzystywanymi w fazie analizy są diagramy przepływu danych, obrazujące procesy przetwarzania danych i występujące między nimi sprzężenia, oraz diagramy encji, opisujące' strukturę przetwarzanych danych. Model jest budowany stopniowo w kilku krokach, których rezultaty są przed stawiane klientowi celem uzgodnienia sposobu rozumienia problemu i uzyskania aprobaty dla proponowanych rozwiązań. ^ W większości przypadków systemy informatyczne powitają w celu usprawnienia działania przedsiębiorstw lub innych organizacji, które już ljhają zorganizowany jakiś system przetwarzania danych (np. ręczny). Istniejący systeiii odzwierciedla potrzeby firmy, a jednocześnie ma ograniczenia wynikające z dotychczasowej technologii realizacji. Zamodelowanie istniejącego systemu jest dobrym punkiem wyjścia do dalszej analizy, której celem będzie zachowanie potrzebnych działań, z jednoczesnym uwolnieniem się od ograniczeń technologicznych. Dodatkową zaletą takiego podejścia jest łatwość uzyskania od użytkowników informacji o sposobie działania systemu,
99
1. Budowę modelu fizycznego, który przedstawia sposób przetwarzania danych w obecnie działającym systemie. 2. Budowę modelu logicznego, który usuwa ograniczenia dotychczas stosowanej technologii realizacyjnej i obrazuje sposób przetwarzania w „idealnej” tech nologii.
T e c h n ik i a n a liz y s tru k tu ra ln e j
Zakończenie analizy strategicznej, podjęcie decyzji i podpisanie umowy rozpoczyna realizację przedsięwzięcia. Przedmiotem prac w fazie analizy (szczegółowej) jest ten fragment przedsiębiorstwa, który znajduje się w zakresie działania budowanego sys temu. Głównym zadaniem jest teraz dokładne opisanie sposobu działania oprogramo wania. Analiza strukturalna dostarcza w tym celu dwa rodzaje model i. Logikę działa nia opisuje diagram przepływu danych. Modelem struktury danych pozostaje diagram encji, który podlega jednak daleko idącym zmianom. Obydwie czynności - budowa diagrawrmąfrzeplywu danych i przebudowa diagramu encji - mogą być wykonywane równolegle. Warunkiem powodzenia pracy jest zebranie i udokumentowanie dokładniejszych danych na temat zakresu i sposobu działania oprogramowania. Metody pozyskiwania informacji pozostają podobne do metod z poprzedniej fazy prac i obejmują studiowa nie dokumentów opisujących dziedzinę zastosowania oraz przeprowadzanie wywia dów z użytkownikami. Na tym etapie analizy wywiady muszą stać się bardziej szcze gółowe, co wymaga zejścia w dół, z poziomu kierownictwa przedsiębiorstwa do poziomu szeregowych pracowników wykonujących zadania na stanowiskach pracy. Celem tych działań jest stworzenie modelu analitycznego, który obrazuje sposób działania oprogramowania, ale nie określa jego budowy.
1_
który znają i którego używają na co dzień, oraz możliwość wiarygodnej weryfikacji sposobu rozumienia problemu przez obie strony umowy. Dlatego typowy przebieg procesu modelowania zachowania obejmuje następujące kroki:
informacji. Rysunek taki może stanowić pierwszy krok analizy, ułatwiający budowę modelu przetwarzania.
3 .3 .
-
\
3. Budowę nowego modelu fizycznego, który przedstawia sposób działania oprogramowania nowego systemu. Dotychczasowy model fizyczny pokazuje sposób realizacji procesów bizneso wych przedsiębiorstwa. Przekształcenie modelu fizycznego w model logiczny może oznaczać zmianę tych procesów, prowadzącą do zmiany sposobu działania firmy. W tym miejscu metodyka strukturalna wykracza poza obszar inżynierii oprogramowa nia, a nawet poza obszar techniki, i staje się narzędziem znanej w naukach o zarządzaniu koncepcji restrukturyzacji procesów biznesowych (Business Process Re-engineering ~ BPR) w celu poprawy wydajności działania przedsiębiorstwa [244, 240, 2451.
Trzeba jednak zaznaczyć, że budowa dotychczasowego modelu fizycznego jest krokiem opcjonalnym, który może być pominięty ze względu na koszty lub w przy padku budowania całkiem nowego systemu, który nie miał żadnego poprzednika. Taka sytuacja występuje często podczas wytwarzania oprogramowania systemów sterujących, które otwierają nowe możliwości lub zastępują wcześniejsze urządzenia oparte na zupełnie innych zasadach działania. Dlatego metody zorientowane na pro jektowanie oprogramowania sterującego nie obejmują na ogół lego kroku (por. pod rozdział 10.3).
3.3.1. B udow a m odelu fizyczn eg o Podstawowymi źródłami informacji są dla analityków wywiady z użytkownikami oraz bieżące dokumenty firmy, takie jak statut, opis struktury organizacyjnej, regulamin, instrukcje stanowiskowe. Wszystkie te źródła opisują stan bieżący, a nie przyszły, który powstanie po zbudowaniu nowego systemu informatycznego. Dlatego pierwszy model zbudowany przez analityków niemal zawsze w większym lub mniejszym stopniu odzwierciedla obecną strukturę i organizację pracy, które - być może - ulegną zmianie w wyniku wprowadzenia nowego systemu. Powróćmy do przykładu przedsiębiorstwa sprzedaży wysyłkowej. Punktem wyj ścia analizy jest hierarchia funkcji (rys. 3.10), opisująca zadania do wykonania, oraz schemat kontekstu (rys. 3.12), pokazujący granice systemu i zewnętrzne obiekty współpracujące. Pierwszy krok, obejmujący wywiady z pracownikami oraz obserwa cję obiegu dokumentów i sposobu działania przedsiębiorstwa, może prowadzić do
3. M etody strukturalne
i00
„3.3. Techniki analizy strukturalnej S i—
zbudowania modelu pokazującego zasadnicze procesy systemu oraz przepływy da nych między tymi procesami (rys. 3.13). Łatwo zauważyć,'że procesy odpowiadają dość dobrze funkcjom znajdującym się na najwyższym poziomie hierarchii funkcji. Nie powinno to być zaskoczeniem, gdyż zarówno funkcje hierarchii, jak i procesy modelu fizycznego odpowiadają często komórkom organizacyjnym przedsiębiorstwa. Kiiont
Zam ów ienia czekające
* P otw ierdzenie
. (2a) Z am ów ienie płatne p rzelew em lub zaliczkow ane
\ ( 1)
Zam ów ienia do realizacji
•{2}
Faktura
\
— r~
N ow y to w a r ____ \
Z a m ó w ie n ie , to w a ró w "
Za m ów ienie d o ż a p ia ty
^9 ) ...^ a o p a trz e n ie ł
^
Z a m ó w io m b y ^ ^ ^ j ^ B r a k u j ą c e
zao pa trze n iow e ,,^ ,* ,^
to w a ry ..
Zam ów ienie d o w ylłpnanla ^
/
Zam ów ienie w ykopano \
Zam ów ienie opłacone (2b)
----------------------------------------------------------------------------- --
2 O bsługa \ m agazynu /
(7) v Z am ów ienie n iezrealizow ane
. Dostaw a
D ostaw ca
ysunek 3.13. Diagram 0: System sprzedaży wysyłkowej
Diagram przepływu danych opisuje wymagane przetwarzanie znacznie dokład niej niż hierarchia funkcji. Przepływy łączące funkcje umożliwiają pokazanie ich współdziałania oraz wymiany danych następującej podczas realizacji procesów bizne sowych. l Najważniejszy proces biznesowy przedsiębiorstwa sprzedaży wysyłkowej, jakim jest obsługa zam ówień klientów, rozpoczyna się w chwili ^płynięcia zamówienia od klienta (1). Pracownicy działu sprzedaży rejestrują wpływające zamówienia i dzielą je na dwie grupy: ■ zamówienia, które powinny zostać opłacone przelewem przed realizacją, są odkładane na stos zamówień czekających (2a); ■ zamówienia płatne przy odbiorze są odkładane na stos zamówień do realizacji (2).
W podobny sposób można opisać przebieg procesu zakupu tow arów od dostaw ców. Stos zamówień zaległych jest regularnie przeglądany przez pracowników działu zaopatrzenia (S), którzy zamawiają brakujące towary u dostawców (9), pozostawiając zalegle zamówienia na stosie. Kopie zamówień złożonych u dostawców oczekują na stosie zamówień zaopatrzeniowych do chwili, w której obsługa magazynu potwierdzi odebranie dostawy (10). Potwierdzone zamówienia zaopatrzeniowe są przekazywane do działu księgowości (11), który opłaca związane z tymi zamówieniami faktury dostawców (i 2). Opis przetwarzania, jaki można przedstawić na pojedynczym diagramie, jest z konieczności dość ogólny. Podstawowym ograniczeniem jest rozmiar i stopień skomplikowania rysunku - pokazanie wszystkich szczegółów działania przedsiębior stwa wymagałoby zbudowania bardzo dużego diagramu, zagmatwanego i trudnego do objęcia ludzkim umysłem. Taki sposób postępowania stanowiłby zaprzeczenie idei posługiwania się modelami graficznymi, które są tworzone dla uzyskania przejrzysto ści i zrozumiałości opisu większej, niż jest to możliwe do uzyskania za pomocą opi sów tekstowych. Badania psychofizyczne wykonane jeszcze w latach pięćdziesiątych XX wieku [261] pokazały, że optymalną dla naszej zdolności pojmowania jest de kompozycja problemu na ok. 7 elementów. Stąd zwykle przyjmuje się tę wartość jako wskazanie zalecanej liczby procesów na diagramie. Bardziej szczegółowy opis przetwarzania wymaga zbudowania hierarchii dia gramów, w której struktura poszczególnych procesów diagramu wyższego poziomu jest przedstawiona na odrębnych diagramach niższego poziomu. Ns^p-r^i-lad, proces I: Obsługa zamówień można opisać za pomocą diagramu pokazanego na rys. 3.14, a proces 2: Obsługa magazynu - przy użyciu diagramu pokazanego na rys. 3.15.
102
3. M etody strukturalne
Zamówienie
Opis towaru
staną się na tyle proste, aby ich specyfikacje mieściły się na jednej stronie. Przykład takiej minispecyfikacji, zapisanej w pseudokodzie, jest pokazany na rys. 3.16.
Towary
Proces 2.1: Sprawdzenie stanu magazynu______________________
Klient Drukowana kopia załnówienia „wierdzenłe
Zamówienieplatne'" przelewem lub zaliczkowane Zamówienie płatne ----przy odbiorze
Zamówienia czekające
Zamówienia do realizacji
i
R ysunek 3.14. Diagram 1: Obsługa zamówień
Dla każdego wybranego zam ówienia wykonaj Przeglądaj pozycje zam ówienia i dia każdej pozycji wykonaj Znajdź opis towaru w magazynie Jeśli tow ar dostępny, to Zaznacz pobranie towaru Zaznacz pozycję zrealizowaną W przeciwnym p rzy p a d k u . Przerwij przeglądanie pozycji zam ówienia Jeśli wszystkie pozycje zrealizowane, to Przekaż zam ówienie do wysyłki W przeciwnym przypadku Dla każdej pozycji zamówienia Cofnij pobranie towaru Przekaż zam ówienie do zbioru zam ówień zaległych Koniec obsługi zamówienia
Rysunek 3,16. Specyfikacja procesu 2.1: Sprawdzenie stanu magazynu
3.3.2. B udow a m odelu lo gicznego
D ostaw ca
... ...........DostaWa
S
z fakturą ►
Klient
R ysunek 3.15. Diagram 2: Obsługa magazynu
Końcowa hierarchia diagramów opisuje całość przetwarzania zgodnie z zasadą zstępującej dekompozycji funkcji. Nie znaczy to jednak,^że tak właśnie przebiega proces budowania modelu przez analityka. W rzeczywistości częstym punktem star towym jest zgrubny, jednopoziomowy model obrazujący tępzęść przetwarzania, która jest najlepiej rozumiana przez analityka na danym etapie pracy. W miarę postępów analizy diagram zaczyna przekraczać rozsądne rozmiary, co zmusza analityka do uporządkowania modelu i przejścia na opis hierarchiczny - powiązane grupy proce sów są łączone w pojedyncze procesy wyższego poziomu, a drobne szczegóły prze twarzania są przenoszone na diagramy poziomu niższego. Na ogól budowę hierarchii diagramów przepływu danych prowadzi się do takiego poziomu, na którym procesy
Model fizyczny pokazuje przebieg procesów przetwarzania danych, realizowanych w konkretnej technologii implementacyjnej. W systemie ręcznego przetwarzania danych przepływy w modelu obrazują ruch fizycznie istniejących obiektów. Na przy kład, widoczny na rys. 3.J3 zbiór Zamówienia czekające może mieć postać segregato ra, z którego część dokumentów jest przenoszona przez pracowników działu księgowości do innego segregatora Zamówień do realizacji. Fizyczne przemieszczenie zamówień do osobnego zbioru jest niezbędne dla ułatwienia pracy ludzi obsługują cych magazyn i uniknięcia pomyłek polegających na realizacji zamówień, które nie zostały właściwie opłacone. Odrębne segregatory Zamówień czekających i Zamówień do realizacji oraz ko nieczność przekładania kartek zamówień z jednego segregatora do drugiego są przy kładami zależności procesu przetwarzania od technologii realizacyjnej (realizacja ręczna). W innej technologii realizacyjnej - takiej, w której nie grozi pomylenie zamówień różnego rodzaju - odrębne segregatory stają się zbędne. Zamiast nich wystarczy jeden wspólny zbiór zamówień, rozróżnianych za pomocą dodatkowego oznaczenia czekające, do realizacji lub wykonane. Każda zmiana technologii realiza cyjnej, np. wprowadzenie komputerów, skanerów dokumentów, oznakowanie zamó wień kodem kreskowym itp. może prowadzić do daleko idących zmian modelu. W rezultacie model fizyczny jest niestabilny i podlega częstym zmianom.
104
3. M etody strukturalne
105
3 . T ech n ik i analizy strukturalnej Znm óyyionjo w ykon ano
Celem budowy modelu logicznego jest pokazanie wewnętrznej logiki procesów przetwarzania danych, nieobarczonych naleciałościami konkretnej technologii imple mentacyjnej. Niezależność od zmieniającej się technologii zapewnia stabilność modelu, który powinien zachować aktualność pomimo nieuchronnych zmian technologicznych. Hierarchiczna struktura modelu fizycznego odzwierciedla na ogól obecną struk turę organizacyjną przedsiębiorstwa, którego działy odpowiadają procesom pokaza nym na diagramie najwyższego poziomu. Dlatego przekształcenie modelu fizycznego w model logiczny rozpoczyna się zwykle od usunięcia hierarchii i połączenia diagra mów przepływu danych znajdujących się na niższym poziomie. Procesy występujące na diagramach niższego poziomu odzwierciedlają czynności, które muszą być wyko nane niezależnie od przypisania ich do tego czy innego działu firmy. Połączony, zwykle bardzo duży, model przedstawia przebieg obecnych procesów przetwarzania, oderwany od konkretnej struktury organizacyjnej przedsiębiorstwa. Dalszym krokiem budowania modelu logicznego jest usunięcie wszystkich ele mentów modelu fizycznego wynikających z obecnie'stosowanej technologii realiza cyjnej. Należą do nich: ■ procesy transportowe (przenoszenie danych, zmiana nośnika, kontrola błę dów, ...), * procesy wsadowe (gromadzenie danych), " przepływy przemieszczające fizyczne obiekty, a wsadowe magazyny danych, ■ magazyny bez wejść lub wyjść.
Z a m ó w ienia w ykon ane
P rzosyłka J M :-.
Z n m o w lonio d o w ysyłki
Z am ó w ie n ia
F aktu ry d lii klien lów
P rzyg otow ano
} ...
Kllont Drul ow nn n kopia zar ló w ie n ia
\
/
P o tw ie rd z a n ia \
j
2,1 S p ra w d zo n io stanu
/
Z a m ó w ie n ie p ła tn a p rzy ocłbiorzo
d o w y k o n a n ia
przosylki
\
\n m g n z y n u / Tow ar (gr'“ ’’-! * sprzo dany Z a n jó w io n le / n t™ \ Stan n io z re a iiz o w a n o y ' m a g a zyn o w y
Zam óW ionic płatno przelewom lub za liczkow ano
Z am ów ienia czekająca
Z a m ó w lo n ta za o p a trze n io w o
J to tw le r d z o r fo d o sta w y
Rysunek 3.17. Połączony model fizyczny
Faktu ry dla klien tów
Powróćmy do przykładu przedsiębiorstwa sprzedaży 'wysyłkowej. Diagram 0, pokazany na rys. 3.13, przedstawia całość przetwarzania danych wykonywanego w przedsiębiorstwie, diagramy 1 i 2, pokazane na rys. 3.14 i 3.15, przedstawiają dokładniej interesujące nas procesy Obsługa zamówień i Obsługa magazynu. Usunię cie hierarchizacji polega na połączeniu diagramów I i 2, co.prowadzi do zbiorczego modelu przetwarzania pokazanego na rys. 3.17. Analizując połączony model fizyczny, można zauważyć, że elementami ściśle związanymi z obecną (ręczną) technologią realizacji przetwarzania są w nim: ■ wsadowe magazyny danych: Zamówienia czekającej Zamówienia do realiza cji, Zamówienia zaległe i Zamówienia wykonanej które można połączyć w jeden magazyn Zamówienia; ■ procesy i magazyny opisujące fizyczne przemieszczenia towarów: Pakowanie przesyłki i Składowanie towarów, które zostaną z modelu usunięte. Wynikiem tych zmian jest model logiczny aplikacji obsługi sprzedaży pokazany na rys. 3.18. Łatwo zauważyć znaczne uproszczenie modelu, w którym wyraźnie wyodrębniają się drogi przepływu zamówień i towarów.
A
R y su n e k 3.18. M odel logiczny aplikacji obsługi sprzedaży
3. M e to d y stru k tu ra ln e
1 06
a 3 T echniki analizy .strukturalnej _iU Ć
Budowanie modelu logicznego wymagało szeregu działań, podczas których ist niała możliwość popełnienia błędu, np. pominięcia jakiejś Funkcji lub jakiegoś połą czenia funkcji z magazynem danych. Dlatego opracowany model logiczny powinien być przed zatwierdzeniem poddany weryfikacji polegającej na próbie odnalezienia wśród procesów modelu wszystkich funkcji elementarnych, które występują w hierar c h ii’m ukejfi w modelu fizycznym, oraz zbudowaniu macierzy CRUD, sprawdzającej korelację modelu zachowania z modelem danych.
Celem prac wykonywanych w fazie analizy szczegółowej jest zbudowanie mo delu dokładnego. Metody pracy analityka oraz źródła wykorzystywanej przez niego informacji nie ulegają zasadniczej zmianie, jednak poziom szczegółowości opisu wzrasta, a praca obejmuje swym zasięgiem wszystkie obszary dziedziny problemu, a nie tylko te najważniejsze. Konieczność poznania szczegółów wymaganego prze twarzania zmienia zakres wywiadów - obejmują one teraz pracowników niższych szczebli, którzy wiedzą, jak pracuje firma, a w przyszłości będą bezpośrednimi użyt kownikami tworzonego oprogramowania. Istotnym elementem budowania kompletnego modelu danych jest uzupełnianie i porządkowanie atrybutów encji, nazywane normalizacją modelu. Celem tego procesu jest uniknięcie redundancji danych i doprowadzenie modelu do postaci, która jest wymagana do utworzenia tabel relacyjnej bazy danych. Proces normalizacji przebiega w kilku krokach, których wynikiem są kolejno numerowane „postacie normalne”. Na ogól wymaga się normalizacji sięgającej trzeciej postaci normalnej. 1. Pierwsza postać normalna - atrybuty encji są wartościami niepodzielnymi. Na przykład, jeśli w czasie przetwarzania danych l^lienta pojawia się potrzeba wyodrębniania z jego adresu nazwy m iejscow ośc| to adres nie będzie prawi dłowym atrybutem encji Klient. Normalizacja \fymaga rozbicia adresu na części składowe. 2, Druga postać normalna - każda wartość klucza jednoznacznie wyznacza wartości wszystkich atrybutów encji. Na przykład, atrybut nazwisko nie bę dzie poprawnym kluczem encji Klient, ponieważ może pojawić się kilku klientów o tym samym nazwisku. Rozwiązaniem problemu może być nadanie klientom unikalnych identyfikatorów lub posłużenie się numerami PESEL.
107
3. Trzecia postać normalna - atrybut, który nie jest kluczem, nie wyznacza jed noznacznie wartości innych atrybutów encji. Na przykład, gdyby cncja Za mówienie zawierała identyfikator klienta i adres klienta, to atrybut identyfi kator klienta jednoznacznie wyznaczałby adres klienta. Przechowywanie ad resu w tej encji byłoby nadmiarowe, gdyż znając identyfikator klienta, można zawsze odszukać jego adres w treści encji Klient. Dokładny opis wszystkich postaci normalnych oraz sformalizowanego procesu ich osiągania można znaleźć w podręcznikach projektowania baz danych, np. [208, 206, 202 |.
3 .3 .3 . M o d e lo w a n ie danych Model danych utworzony podczas analizy strategicznej nie jest zbyt szczegółowy. Nie ma on przecież opisywać całości danych podlegających przetwarzaniu, a jedynie wyjaśniać sposób działania funkcji wymienionych w hierarchii funkcji. Dlatego model ten zawiera tylko najważniejsze encje, których obecność jest oczywista, najważniejsze atrybuty, które są niezbędne do scharakteryzowania encji, oraz podstawowe związki między encjami.
------------------------------------- 1
'
Rozwijając wstępny diagram encji, opracowany podczas analizy strategicznej, trzeba poświęcić szczególną uwagę takim związkom, które po obu stronach mogą dotyczyć wielu obiektów. Tego typu związki wiele-do-wielu, których przykładem może być związek łączący encje Towar i Zamówienie na rys. 3.6, utrudniają człowie kowi uchwycenie natury powiązań istniejących między konkretnymi obiektami w dziedzinie zastosowania. Dlatego w większości praktycznie realizowanych syste mów przetwarzania danych wprowadza się jakieś encje pośredniczące, których obec ność umożliwia zdefiniowanie powiązań między przetwarzanymi obiektami za pomocą bardziej jednoznacznych związków typu jeden-do-wiełu. Na przykład, w nie mal wszystkich systemach przetwarzających zamówienia występuje pojęcie „pozycji zamówienia”, czyli samodzielnej części zamówienia określającej zapotrzebowanie na jeden konkretny towar. W ogromnej większości przypadków każda pozycja zamówie nia może być przedmiotem odrębnej dostawy i księgowania, niezależnie od losu pozostałych pozycji tego samego zamówienia. Sposób powiązania wielu obiektów jednego rodzaju z wieloma obiektami innego rodzaju poprzez uncję pośredniczącą jest pokazany na rys. 3.19.
Rysunek 3.19. Jednoznaczne powiązanie towarów i zamówień poprzez pozycje zamówienia
Obecność związku wiele-do-wielu w modelu danych wskazuje najczęściej na pominięcie jakiegoś ważnego pojęcia występującego w realnym świecie i konieczność przeprowadzenia bardziej wnikliwej analizy tego fragmentu dziedziny zastosowania. Przykładowy model uporządkowanego modelu danych przedsiębiorstwa sprzedaży wysyłkowej, pozbawiony związków wiele-do-wielu, jest pokazany na rys. 3.20.
3. M etody strukturalne
108
3.3. Techniki analizy strukturalnej
wysyła
zawiera
uzupełnia
Dostawa
Pozycja dostawy realizuje
Pozycja magazynu
Dostawca zawiera
określa
wysłana _ --------------------------|---------------------------- Pozycja przesyłki
otrzymuje Zamówienie zaopatrzeniowe
Pozycja zamówienia
za w ie ra --------------------------j>-|----------------- 1Przesyłka
odbiera
realizuje
Klient
109
L
-*
Przyjęcie dostawy rozpoczyna się od skanowania czytnikiem wszystkich dostar czonych towarów. System rozpoznaje odczytany kod towaru (proces 5.1), zlicza poszczególne pozycje towarowe i znajduje odpowiadające im zamówienia w zbiorze Zamówienia zaopatrzeniowe (proces 5.2). Pracownik magazynu widzi na terminalu treść zamówienia oraz liczbę dostarczonych sztuk towaru i na tej podstawie podejmuje decyzję o przyjęciu lub odrzuceniu każdej pozycji dostawy. Pozycje odrzucone są zwracane dostawcy. Pozycje przyjęte są wciągane na stan magazynu (proces 5.3). a ich opis jest zapisywany w zbiorze Pozycje przyjęte. Po zakończeniu procesu przyj mowania dostawy system drukuje dokument przyjęcia zewnętrznego (PZ) potwier dzający przyjęcie towarów do magazynu.
sktada
sprzedana Zamówienie
Pozycja zamówienia )>
Produkt przyjęty
odnosi się do
Towary w m agazynie
m agazynu
opisuje Towar
Opis katalogowy Z a m ó w ie n ie t- p o z y c ja dOG lnwy
Opona
Fotelik
Bagażnik przyjęte
R ysunek 3.20. Diagram encji obrazujący dane funkcji obsługi magazynu i sprzedaży (model analizy szczegółowej)
3 .3 .4 . B ud ow a no w eg o m odelu fizyczn eg o Celem działania na tym etapie pracy jest określenie mechanizmów realizacji przetwa rzania opisanego w modelu logicznym. Na razie nie wiadomo nawet, jak bęęlą wpro wadzane do systemu zamówienia nadsyłane pocztą elektroniczną, jak będzie wyglądać współpraca systemu z pracownikami pakującymi towary i wysyłającymi przesyłki ani jak będą przyjmowane nowe dostawy. Zajmijmy się tym ostatnim problemem. Przenoszenie towarów i rozmieszczanie icli w magazynie będzie zapewne wykonywane ręcznie. System komputerowy może jednak wspomagać ten proces, odnajdując zamówienia ^odpowiadające zawartości dostawy, sprawdzając zgodność dokumentów dostawy z treścią zamówienia, aktuali zując automatycznie opis stanu magazynu i drukując dokunjenty przyjęcia towarów do magazynu (dokument PZ). Dalsze możliwości automatyzacji procesu przyjmowania dostaw zależą istotnie od wyposażenia magazynu. Jeśli dostarczane towary mają oznaczenia w postaci kodu kreskowego, a magazyn zostanie wyposażony w odpo wiednie czytniki, to komputer może automatycznie sprawdzać zawartość i komplet ność przyjmowanej dostawy. Caiość związanego z tym procesem przetwarzania jest pokazana na rys. 3.21.
5.4
D rukow anie V lokum entu P 2 Czytnik kodu kreskowego
Kod kreskowy
I Rozpoznanie I tekstu J
A
^ D o ku m e n t PZ
D rukarka
Rysunek 3.21. Diagram 5: Przyjęcie dostawy
W rzeczywistości nowy model fizyczny nie jest wynikiem decyzji podjętych ar bitralnie przez analityków. Decyzja co do sposobu wprowadzania i wyprowadzania danych wiąże się ściśle z opracowaniem nowych procedur biznesowych, zgodnie z którymi będzie działać przedsiębiorstwo, i jest podejmowana zawsze w ścisłej współpracy z użytkownikiem, który ma w tym względzie glos decydujący. Opracowa nie tych procedur wymaga oceny wielu czynników biznesowych, takich jak zakres ko niecznego szkolenia personelu, możliwość wystąpienia zakłóceń pracy firmy na etapie wdrożenia oraz niezbędne wydatki inwestycyjne (np. na zakup czytników kodu kre skowego). Dlatego wynikiem analizy szczegółowej jest nie tylko model systemu docelowego, ale także plan przejścia na nowy system, obejmujący co najmniej trzy elementy: ■ pian testowania akceptacyjnego, określający czas, miejsce i zakres odpowie dzialności stron podczas zatwierdzania systemu (np. kto dostarczy środowisko
3, M etody strukturalne
testowe, jaką metodą będą sprawdzane wymagania, jak będą zgłaszane błędy, jak będzie przebiegał proces poprawiania błędów itp.); * plan szkoleń, określający czas, miejsce i zakres szkoleń niezbędnych dla po szczególnych stanowisk pracy (także: metodę szkolenia, liczebność grup tre ningowych, dostępność systemu szkoleniowego i podręczników) oraz sposób zapewnienia ciągłości pracy firmy podczas szkolenia części pracowników; 0 plan wdrożenia, określający m.in. sposób przenoszenia danych między starym a nowym systemem, kolejność włączania do eksploatacji modułów nowego systemu i wyłączania starego (może obydwa systemy będą przez pewien czas pracować równolegle) oraz liczbę pracowników niezbędnych na poszczegól nych stanowiskach pracy.
3 .4 .
T e c h n ik i p ro je k to w a n ia a p lik a c ji
Model analityczny, w skład którego wchodzi hierarchia diagramów przepływu danych i diagram encji, opisuje reguły przetwarzania oraz zakres danych niezbędnych do realizacji tego przetwarzania. Jednocześnie model ten nie zawiera szczegółów tech nologii realizacyjnej ani nie określa budowy programu. Te właśnie elementy są doda wane podczas budowania modelu projektowego. Pierwszą decyzją, jaką musi podjąć projektant, jest podział całego systemu na odrębne programy (aplikacje), wykonywane niezależnie - i być może równolegle z pozostałymi programami. Z punktu widzenia użytkownika program może odpowia dać funkcji w głównym menu systemu. Na poziomie wielozadaniowego systemu operacyjnego program może być odrębnym procesem wykonywanym równolegle z. innymi procesami. Na przykład, w systemie wspomagającym pracę przedsiębiorstwa jednym programem może być funkcja realizacji zamówienia, a drugim - funkcja przyjmowania dostawy towarów do magazynu. Obie funkcje nie są całkiem niezależ ne, gdyż współdzielą zbiór (encję) opisujący stan magazynu. Mogą jednak być wyko nywane niezależnie przez dwóch lub więcej użytkowników (kilku pracowników może w tym samym czasie realizować różne zamówienia), innym przykładem może być system pokładowy samolotu, w którym jeden program może obliczać pozycję i pręd kość samolotu na podstawie wskazań inercyjnego systemwj pomiarowego (żyroskopu), drugi okresowo korygować położenie na podstawie wskazań GPS, a trzeci - wyświe tlać obliczone wartości dla pilota. Wszystkie te programy fłzialają równolegle i permai współdziałając z sobą za pomocą usług udostępnianych przez system operay |~yT uiiputera pokładowego. uKreślenie granic programów polega na logicznym pogrupowaniu funkcji poka zanych na diagramie przepływu danych. Kryteria, jakie można zastosować podczas tej czynności, łatwiej podać, niż stosować w praktyce:
3.4. T echniki projektow ania aplikacji
* łączyć razem funkcje powiązane przepływami bezpośrednimi - wykonanie jednej z tych funkcji niejako wymusza wykonanie drugiej; powstający pro gram stanie się dla użytkownika-narzędziem umożliwiającym łatwą realizację obu zadań; ■ łączyć razem funkcje sięgające do ściśle powiązanych encji - jest wysoce prawdopodobne, że modyfikacja jednej encji będzie wymagała jednoczesnej zmiany drugiej; • łączyć razem funkcje wykonywane w tym samym miejscu i czasie - zapewne będzie je wykonywał ten sam użytkownik. i Stosując te reguły do przykładu pokazanego na rys. 3 .18, można wyodrębnić trzy programy: przyjmowanie zamówień, realizacja zamówienia i przyjęcie nowej dosta wy. Programy te mogą stać się niezależnymi aplikacjami, wywoływanymi oddzielnie przez różnych pracowników przedsiębiorstwa, albo mogą być zintegrowane w jednej aplikacji, w której staną się funkcjami dostępnymi w głównym menu aplikacji. Po zdefiniowaniu granic programów kolejnym krokiem jest określenie sposobu budowy każdego programu i zaprojektowanie bazy danych. Działania te wymagają użycia różnych technologii implementacyjnych i są często wykonywane przez różnych ludzi. Trzeba też zaprojektować interfejs użytkownika, obejmujący raporty i formula rze ekranowe. Działania te, zwłaszcza implementacja bazy danych i interfejsu użyt kownika, są bardzo silnie wspierane przez dostępne narzędzia wspomagające.
3.4.1. P ro jekto w an ie struktury program u Zaprojektowanie programu wymaga wskazania podstawowych modułów tego pro gramu (podprogramów, funkcji, struktur danych), określenia sposobu współpracy każdego modułu z innymi modułami, zbiorami danych i urządzeniami oraz zdefinio wania algorytmów działania wszystkich modułów. Punktem wyjścia (ego etapu bu dowy oprogramowania są diagramy przepływu danych, pokazujące podstawowe funkcje do wykonania i występujące między nimi zależności, oraz diagramy encji, określające strukturę danych trwałych. Wynikiem powinien być schemat struktury programu oraz algorytmiczne specyfikacje pokazanych na schemacie podprogramów. Oczywistym kryterium poprawności projektu jest wierne odwzorowanie całości przetwarzania, przedstawionego w modelu analitycznym, w strukturze programu. Dobrym sposobem zapewnienia zgodności modeli jest budowanie schematu struktury przez stopniowe przekształcanie diagramu przepływu danych tak, aby moż liwe było wskazanie odpowiadających sobie elementów obydwu modeli. Jedna z naj częściej stosowanych metod tego przekształcania polega na hierarchicznym budo waniu kolejnych pięter schematu struktury, poczynając od programu głównego, po przez bezpośrednio wywoływane podprogramy, aż do podprogramów i zbiorów znajdujących się na najniższym poziomie hierarchii wywołań. Procedura przeksztal-
3. M etody strukturalne
I io
3 .4 . Techniki projektow ania aplikacji
— n— testowe, jaką metodą będą sprawdzane wymagania, jak będą zgłaszane błędy, jak będzie przebiegał proces poprawiania błędów ilp.); " plan szkoleń, określający czas, miejsce i zakres szkoleń niezbędnych dla po szczególnych stanowisk pracy (także: metodę szkolenia, liczebność grup tre ningowych, dostępność systemu szkoleniowego i podręczników) oraz sposób zapewnienia ciągłości pracy firmy podczas szkolenia części pracowników; “ plan wdrożenia, określający m.in. sposób przenoszenia danych między starym a nowym systemem, kolejność włączania do eksploatacji modułów nowego systemu i wyłączania starego (może obydwa systemy będą przez pewien czas pracować równolegle) oraz liczbę pracowników niezbędnych na poszczegól nych stanowiskach pracy.
3 .4 .
T e c h n ik i p ro je k to w a n ia a p lik a c ji
Model analityczny, w skład którego wchodzi hierarchia diagramów przepływu danych i diagram encji, opisuje reguły przetwarzania oraz zakres danych niezbędnych do realizacji tego przetwarzania. Jednocześnie model ten nie zawiera szczegółów tech nologii realizacyjnej ani nie określa budowy programu. Te właśnie elementy są doda wane podczas budowania modelu projektowego. Pierwszą decyzją, jaką musi podjąć projektant, jest podział całego systemu na odrębne programy (aplikacje), wykonywane niezależnie - i być może równolegle z pozostałymi programami. Z punktu widzenia użytkownika program może odpowia dać funkcji w głównym menu systemu. Na poziomie wielozadaniowego systemu operacyjnego program może być odrębnym procesem wykonywanym równolegle z innymi procesami. Na przykład, w systemie wspomagającym pracę przedsiębiorstwa jednym programem może być funkcja realizacji zamówienia, a drugim - funkcja przyjmowania dostawy towarów do magazynu. Obie funkcje nie są całkiem niezależ ne, gdyż współdzielą zbiór (encję) opisujący stan magazynu. Mogą jednak być wyko nywane niezależnie przez dwóch lub więcej użytkowników (kilku pracowników może w tym samym czasie realizować różne zamówienia). Innym przykładem nfoże być system pokładowy samolotu, w którym jeden program może obliczać pozycję i pręd kość samolotu na podstawie wskazań inercyjnego systemu (pomiarowego (żyroskopu), drugi okresowo korygować położenie na podstawie wskaztjń GPS, a trzeci - wyświe tlać obliczone wartości dla pilota. Wszystkie te programy dliałają równolegle i perma nentnie, współdziałając z sobą za pomocą usług udostępnianych przez system opera cyjny komputera pokładowego. Określenie granic programów polega na logicznym pogrupowaniu funkcji poka zanych na diagramie przepływu danych. Kryteria, jakie można zastosować podczas tej czynności, łatwiej podać, niż stosować w praktyce:
............................. .... ■ łączyć razem funkcje powiązane przepływami bezpośrednimi - wykonanie jednej z tych funkcji niejako wymusza wykonanie drugiej; powstający pro gram stanie się dla użytkownika narzędziem umożliwiającym łatwą realizację obu zadali; ■ łączyć razem funkcje sięgające do ściśle powiązanych encji - jest wysoce prawdopodobne, że modyfikacja jednej encji będzie wymagała jednoczesnej zmiany drugiej; ■ łączyć razem funkcje wykonywane w tym samym miejscu i czasie - zapewne będzie je wykonywał ten sam użytkownik.
Stosując te reguły do przykładu pokazanego na rys. 3.18, można wyodrębnić trzy programy: przyjmowanie zamówień, realizacja zamówienia i przyjęcie nowej dosta wy. Programy te mogą stać się niezależnymi aplikacjami, wywoływanymi oddzielnie przez różnych pracowników przedsiębiorstwa, albo mogą być zintegrowane w jednej aplikacji, w której staną się funkcjami dostępnymi w głównym mena-apriiiicji. Po zdefiniowaniu granic programów kolejnym krokiem jest określenie sposobu budowy każdego programu i zaprojektowanie bazy danych. Działania te wymagają użycia różnych technologii implementacyjnych i są często wykonywane przez różnych ludzi. Trzeba też zaprojektować interfejs użytkownika, obejmujący raporty i formula rze ekranowe. Działania te, zwłaszcza implementacja bazy danych i interfejsu użyt kownika, są bardzo silnie wspierane przez dostępne narzędzia wspomagające.
3.4.1. P ro jekto w an ie struktury program u Zaprojektowanie programu wymaga wskazania podstawowych modułów tego pro gramu (podprogramów, funkcji, struktur danych), określenia sposobu współpracy każdego modułu z innymi modułami, zbiorami danych i urządzeniami oraz zdefinio wania algorytmów działania wszystkich modułów. Punktem wyjścia tego etapu bu dowy oprogramowania są diagramy przepływu danych, pokazujące podstawowe funkcje do wykonania i występujące między nimi zależności, oraz diagramy encji, określające strukturę danych trwałych. Wynikiem powinien być schemat struktury programu oraz. algorytmiczne specyfikacje pokazanych na schemacie podprogramów. Oczywistym kryterium poprawności projektu jest wierne odwzorowanie całości przetwarzania, przedstawionego w modelu analitycznym, w strukturze programu. Dobrym sposobem zapewnienia zgodności modeli jest budowanie schematu struktury przez stopniowe przekształcanie diagramu przepływu danych tak, aby moż liwe było wskazanie odpowiadających sobie elementów obydwu modeli. Jedna z naj częściej stosowanych metod tego przekształcania polega na hierarchicznym budo waniu kolejnych pięter schematu struktury, poczynając od programu głównego, po przez bezpośrednio wywoływane podprogramy, aż do podprogramów i zbiorów znajdujących się na najniższym poziomie hierarchii wywołań. Procedura przekształ
112
3. M etody strukturalne
cania zaczyna się od wybrania centralnej funkcji diagramu, realizującej zasadniczą część przetwarzania aplikacji i położonej zazwyczaj w centralnym miejscu diagramu. W ybór tej funkcji jest dość subiektywny i zależy od punktu widzenia projektanta. W następnym kroku powstaje górna część schematu struktury, złożona z programu głównego aplikacji oraz podprogramów odpowiadających kolejno: przepływom do prowadzającym dane wejściowe do funkcji centralnej, samej funkcji centralnej i przepływom wyprowadzającym wyniki wykonania funkcji centralnej. Prześledźmy ten proces na przykładzie aplikacji przyjęcia dostawy, pokazanej na rys. 3.21. Centralne miejsce diagramu zajmuje funkcja Sprawdzenie pozycji dostawy, która przetwarza opisy kolejnych Pozycji, dostawy dostarczane z czytnika kodu kre skowego przez funkcję Rozpoznanie tekstu i przekazuje opisy Pozycji przyjętych do funkcji Aktualizacja stanu magazynu. Pozostałe działania, polegające na odczytaniu zamówienia z magazynu Zamówień zaopatrzeniowych i zatwierdzeniu przyjęcia pozycji przez pracownika na Terminalu magazynu, m ożna'uznać za wewnętrzne operacje funkcji centralnej. W ten sposób powstaje górne piętro schematu struktury programu, zawierające podprogramy. Odczytanie pozycji dostawy, Sprawdzenie pozycji dostawy i Obsługa pozycji przyjętej (rys. 3.22). Dodatkowa strzałka, obejmu jąca na rysunku wywołania tych trzech podprogramów, symbolizuje wielokrotne wywołania w pętli przetwarzania kolejnych pozycji dostawy. Romb u nasady wywo łania ostatniej funkcji podkreśla warunkowość tego wywołania, dokonywanego nie dla wszystkich pozycji dostawy, a jedynie dla pozycji przyjętych. Czwarta funkcja diagramu przepływu danych, tzn. Drukowanie dokumentu PZ, nie jest bezpośrednio związana z wykonaniem funkcji centralnej. Funkcja ta przetwarza zbiór wyników powstały po sprawdzeniu wszystkich pozycji dostawy - jest więc wyko nywana w innym momencie i w innym rytmie czasowym aniżeli funkcja centralna. W tej sytuacji funkcja ta może być wyodrębniona jako oddzielna aplikacja lub dołączona jako dodatkowy podprogram wywoływany z menu modułu Przyjęcia dostawy. W kolejnych krokach procedury przekształcania diagramu przepływu danych w schemat struktury programu powstają niższe warstwy schematu. Operacje uznane za wewnętrzne w funkcji centralnej stają się podprogramami wywoływanymi przez tę funkcję. W ten sposób na rys. 3.22 pojawiają się podprogramy: Znalezienie zamówie nia, Potwierdzenie pozycji i Akceptacja pozycji. ' Funkcje dostarczające przepływy do funkcji centralnej, takie jak Rozpoznanie tekstu na rys. 3.21, są przekształcane na podprogramy niższej warstwy. Funkcja i jej przepływy wejściowe stają się podprogramami wywoływanymi przez podprogram odpowiadający w górnej warstwie schematu przepływowi wejściowemu funkcji centralnej. W ten sposób na rys. 3.22 pojawiają się podprogramy: Odczyt kodu kre skowego i Rozpoznanie tekstu. Gdyby na diagramie przepływu danych istniały dalsze funkcje dostarczające przepływy do funkcji Rozpoznanie tekstu, to zostałyby prze kształcone na kolejną, jeszcze niższą warstwę.
3.4. T echniki projektow ania aplikacji
113
Przyjęcio dostaw y
$0^
n*h 4 . ..............
O dczytanie pozycji dostaw y
Sprawdzenie pozycji dostawy
O bsiupa pozycji przyjętej
T„
Drukowania dokum entu PZ
\
Rysunek 3.22. Schemat struktury modułu Przyjęcie dostawy
W analogiczny sposób są przekształcane funkcje odbierające wyniki funkcji centralnej, takie jak Aktualizacja stanu magazynu na rys. 3.21.. Funkcje te oraz ich przepływy wyjściowe stają się podprogramami wywoływanymi przez podprogramy odpowiadające w górnej warstwie schematu przepływom wyjściowym funkcji cen tralnej. W ten sposób na rys. 3.22 powstały podprogramy Aktualizacja magazynu i Zapis pozycji przyjętej. Schemat struktury dokładnie przedstawia budowę programu, pokazując wszyst kie zasadnicze podprogramy, hierarchię wywołań wraz z argumentami przekazywa nymi podczas wywołania oraz wspólne struktury danych, takie jak Pozycje przyjęte na rys. 3.22. Brakującym elementem projektu są algorytmy przetwarzania, których jed nak nie trzeba wymyślać od nowa, lecz które są niemal bez zmian przejmowane z minispecyfikacji procesów diagramu przepływu danych. Przeniesienie specyfikacji algorytmów działania między obydwoma modelami wydatnie pomaga w zapewnieniu zgodności projektu z wynikami analizy. Drugą zaletą sformalizowanej procedury przekształcania diagramu przepływu danych w schemat struktury jest możliwość łatwej weryfikacji kompletności projektu. W tym celu należy zestawić tabelę, której wiersze zawierają w pierwszej kolumnie elementy diagramu przepływu danych, tzn. funkcje, magazyny i przepływy, a w dru giej - realizujące te elementy podprogramy, zbiory i urządzenia ze schematu struktury. Przykład takiego odwzorowania jest pokazany w lab. 3.2. Niemożliwość wskazania
3. M etody strukturalne
realizacji jakichkolwiek elementów modelu analitycznego świadczy o niekompletno ści projektu. T abela 3.2. Tabela powiązań diagramu Przyjęcie dostawy (rys. 3.21) ze schematem struktury programu (rys. 3.22)
Lp.
Schem at struktury
Diagram przepływu danych
1
Funkcja - R ozpoznanie tekstu
Podprogram - R ozpoznanie tekstu
2
Funkcja - Sprawdzenie pozycji dostawy
Podprogram - Sprawdzenie pozycji dostawy
3
Funkcja - Aktualizacja stanu m agazynu
Podprogram - Aktualizacja magazynu
4
Funkcja - Drukowanie dokum entu PZ
Podprogram - Drukowanie dokum entu PZ
5
Przepływ - K od kreskow y
Podprogram - Odczyt kpdu kreskowego
6
Przepływ - Zam ów ienie +.pozyc/a dostawy
Podprogram - Akceptacja pozycji
7
Przepływ - Decyzja
Podprogram - A kceptacja pozycji
8
M agazyn - Zam ów ienia zaopatrzeniowe
Tabela - Zam ówienia zaopatrzeniowe
W wielu przypadkach przydatna jest również tabela pokazująca odwzorowanie odwrotne, tzn. przyporządkowująca elementom schematu struktury realizowane przez nie elementy diagramu przepływu danych. Zawartość takiej tabeli wskazuje źródła pochodzenia wszystkich elementów projektu i dowodzi, że projekt realizuje tylko te zachowania, które zostały zatwierdzone podczas analizy. Posiadanie obydwu rodzajów tabel może znacząco ułatwić przyszłą konserwację programu. Po zmianie wymagań użytkownika można łatwo wskazać elementy dia gramu przepływu danych opisujące tę część wymagań, których zmiana dotyczy, a następnie zlokalizować moduły programu odpowiadające za ich realizację. Co więcej, po określeniu obszaru zmian w kodzie można znaleźć wszystkie elementy diagramu przepływu danych, które ten Fragment programu realizuje, i w ten sposób ocenić potencjalny wpływ zmian na inne zachowania aplikacji. '
3 .4 .2 . P ro jekto w an ie bazy danych
\
¡1 Zaprojektowanie bazy danych wymaga zdefiniowania tabeli przechowujących encje modelu danych, określenia dla każdej tabeli zestawu indeksów gwarantujących szyb kie wyszukiwanie potrzebnych danych w tabeli oraz wskazania sposobu rozmieszcze nia tabel i indeksów w plikach systemu operacyjnego. Na ogól konieczne jest też opracowanie planów archiwizacji i odtwarzania danych po awarii. Punktem wyjścia tego etapu projektu są diagramy encji, określające strukturę danych i występujące między nimi zależności, oraz wymagania użytkownika dotyczące wydajności przetwa-
3.4. T echniki projektow ania aplikacji
rzania i niezawodności przechowywania danych. Wynikiem jest dokumentacja umoż liwiająca wcielenie projektu w życie - tzn. utworzenie potrzebnych plików oraz dostarczenie elementarnych operacji zapisania, odczytania i wyszukania danych w tabeli przez dostępne na rynku systemy relacyjnych baz danych (Relational Data base Management System - RDBMS), takie jak Oracle, DB2, MySQL lub podobne. Operacja przekształcenia diagramu encji w projekt tabel jest na ogól bezpośred nia: każda encja staje się tabelą, której wiersze przechowują dane opisujące pojedyn czy obiekt encji, a kolumny odpowiadają atrybutom encji. Przykład odwzorowania encji pokazanych na rys. 3.19 na tabele ilustruje rys. 3.23. Kolumny tabel wyróżnione pogrubionym drukiem zawierają klucze własne, jednoznacznie identyfikujące po szczególne obiekty encji, a kolumny wyróżnione kursywą zawierają klucze obce, wskazujące powiązane obiekty innej encji. Id 1201 1204 1302 1306 1400
Tabela: P ozycje_Zam ów ień
Tabela: Zam ów ienia
N rZam . 1 1 2 N um er 1 2 3
Nazwa Baqaznik box eco Baqaznik box junior Fotelik 12 kq Fotelik 20 kq Kamizelka
Nr P ozycji 1 2 1 Data 4.04.2008 4.04.2008 7.04,2008
Ilość 2 1 1
Producent Motoplastik SA Motoplastik SA Motoplastik SA Delfin sp. zoo Delfin sp. zoo
W artość 40,00 392,84 20,00
Cena 315,00 392,84 259,56 317,00 20,00
Id 1400 1204 1400
Adres Kukułcza 2 m. 324 Nowowiejska 15/19 Relaksowa 321 m. 57
Rysunek 3.23. Schemat tabel odpowiadających diagramowi encji pokazanemu na rys. 3.19.
Niektóre konstrukcje występujące na diagramach encji lamią jednak zasadę bez pośredniości przekształcenia i wymagają większego namysłu. Przykładem może być odwzorowanie relacji uogólnienia pokazanej na rys. 3.7. Przekształcenie każdej encji modelu w odrębną tabelę bazy danych prowadzi do sytuacji, w której znalezienie wszystkich atrybutów jakiegoś towaru, np. opony, wymaga przeszukania dwóch tabel: Towar i Opona, co zajmuje znacznie więcej czasu niż przeszukanie jednej tabeli. Innym rozwiązaniem jest odwzorowanie wszystkich encji w jedną tabelę, zawierającą kolumny dla atrybutów wszystkich encji - w tym przykładzie byłyby to kolumny: nazwa, producent, cena, rozmiar, waga_ciz.iecka, opis, kolor. Ujemną stroną takiego odwzorowania jest jednak nieekonomiczne wykorzystanie pamięci, gdyż część każ dego wiersza tabeli pozostałaby niewykorzystana (np. waga_dziecka w wierszu opi
3. M etody strukturalne
sującym oponę). Jeszcze innym wariantem jest zaniechanie wyodrębniania atrybutów wspólnych i wprowadzenie odrębnych tabel dla każdego rodzaju towaru. To rozwią zanie jest pozbawione wad dwóch poprzednich, jednak utrzymanie możliwości jedno litego traktowania wszystkich towarów wymaga utrzymania identycznego układu kolumn odpowiadających wspólnym atrybutom we wszystkich tabelach, co może utrudnić późniejsze modyfikacje systemu. Nie ma jednoznacznie najlepszego rozwiązania przedstawionego problemu. Oce na zależy od charakteru aplikacji i postawionych jej wymagań, liczby uogólnionych cncji oraz liczby atrybutów wspólnych i atrybutów specyficznych. W ybór wariantu jest decyzją projektową, która musi być podjęta przez projektanta na podstawie jego wiedzy i doświadczenia. W praktyce wytwarzania oprogramowania przekształcenie diagramu cncji w schemat tabel bazy danych jest zwykle wykonywane automatycznie przez odpo wiednie narzędzia CASE. W przypadkach wątpliwych, takich jak opisany w poprzed nim akapicie przypadek relacji uogólnienia, projektant ma na ogól możliwość wyboru odpowiedniego wariantu przekształcenia. Wraz z utworzeniem tabel narzędzie wspo magające tworzy automatycznie potrzebne indeksy - przeważnie potrzebne są co najmniej indeksy dla każdego klucza własnego tabeli i dla każdego klucza obcego. W razie potrzeby specyficznego przeszukiwania tabel projektant może utworzyć indeksy dodatkowe, których obecność przyspieszy najczęściej występujące operacje. Projektowanie tabel i indeksów, nazywane często projektowaniem logicznym, jest zwykle pierwszym etapem projektu bazy danych. Drugi etap, nazywany projekto waniem implementacji fizycznej, obejmuje rozmieszczenie tabel na dyskach i opra cowanie planów archiwizacji i odtwarzania po awarii. Zasadniczym elementem projektu implementacji fizycznej jest określenie przesti/.cni .mbd^AY najprostszym ujęciu pojedyncza przestrzeń tabel obejmuje obszar jednego lub grupy fizycznych dysków systemu. Tabele przypisane do tej samej prze strzeni tabel będą więc przechowywane w plikach znajdujących się na tym samym dysku, a tabele przypisane do różnych przestrzeni tabel będą przechowywane w pli kach znajdujących się na różnych dyskach systemu. Konsekwencje wyboru przestrze ni tabel są wielorakie. , \ * Różne dyski systemu mogą pracować równolegle \ oznacza to, że operacje dostępu do tabel przypisanych do różnych przestrzejhi mogą przebiegać rów nocześnie, co może znacznie poprawić wydajność. • a Awarie sprzętu dotykają na ogól pojedynczych urządzeń - ewentualna awaria dysku wyłączy więc z użycia tylko tabele przypisane do lej właśnie przestrze ni. Odpowiednie przypisane przestrzeni tabel może pozwolić na utrzymanie pracy części aplikacji niekorzystającej z utraconych tabel, pomimo wystąpie nia awarii.
3,4. T echniki projektow ania aplikacji
■ Przestrzenie tabel mogą być zwykle niezależnie dołączane i wyłączane z sys temu - dzięki temu operacje archiwizacji i konserwacji mogą być wykony wane bez wyłączania z użytku całości pracującej aplikacji. Zaprojektowanie dużej i wydajnej bazy danych jest zadaniem skomplikowanym, którego omówienie wykracza znacznie poza ramy tej książki. Dokładniejszy opis naszkicowanych tu zagadnień można znaleźć w podręcznikach projektowania baz danych, np. [204, 205, 208],
3.4,3. P ro je kto w an ie in terfejsu użytko w n ika Większość programów jest tworzona z myślą o bezpośrednim wykorzystaniu przez człowieka w pracy, przy załatwianiu spraw finansowych lub urzędowych, albo po prostu dla rozrywki1. Dlatego znaczną część każdego oprogramowania stanowi inter fejs użytkownika, czyli ta jego część, która odpowiada za komunikację z człowiekiem. We współczesnych systemach komputerowych używany interfejs ma najczęściej postać graficzną (Graphicctl User Inlerface - GUI) i obejmuje formularze ekranowe, za pośrednictwem których użytkownik wprowadza dane i odczytuje wyniki, okienka dialogowe oraz raporty — wyświetlane, drukowane na papierze lub wysyłane do in nych systemów w postaci plików tekstowych. Zaprojektowanie interfejsu użytkownika wymaga określenia dwóch różnych ele mentów. Pierwszym jest sekwencja komunikacji, czyli treść i kolejność wyświetlania następujących po sobie ekranów i okienek dialogowych. Drugim jest format danych oraz kształt graficzny wszystkich widocznych dla człowieka elementów interfejsu. Sekwencję komunikacji można wyrazić słownie, np, w postaci scenariusza opi sującego punkt po punkcie wszystkie kolejno wyświetlane ekrany. Dla każdego ekra nu trzeba zdefiniować jego treść oraz wyliczyć zdarzenia powodujące przejście do następnych ekranów. Takim zdarzeniem jest zazwyczaj naciśnięcie klawisza Euler, naciśnięcie przycisku wyboru lub wskazanie kursorem i kliknięcie kreślonego ele mentu ekranu. Na przykład, podczas wyświetlania na ekranie listy zamówień, jakie nadeszły od rana do sklepu sprzedaży wysyłkowej, kliknięcie numeru zamówienia w jednym z wierszy może prowadzić do nowego ekranu pokazującego to wybrane zamówienie. Zbiór scenariuszy można zorganizować wokół typowych procedur bizne sowych wykonywanych na ogól przez użytkowników. Alternatywnym sposobem opisania sekwencji komunikacji może być narysowa nie diagramu stanów, na którym każdy stan określa treść ekranu, a każde przejście odpowiada zmianie treści wyświetlonej na ekranie.
Wyjątkiem jest oprogramowanie wbudowane pracujące często autom atycznie, bez stałego kontaktu z człowiekiem. Specyficzne wymagania tej grupy programów są przedstawione w rozdziale 10.
3. M etody strukturalne
118
Graficzną formę elementów interfejsu można przedstawić w postaci makiety (prototypu). W najprostszym przypadku może to być rysunek symulujący zrzuty z ekranu, w bardziej złożonym - działający prototyp interfejsu użytkownika. Działają cy prototyp jest oczywiście rozwiązaniem lepszym, które może pokazać nie tylko wygląd interfejsu, ale także sekwencję komunikacji. Opracowanie prototypu'interfejsu użytkownika jest przykładem zastosowania techniki prototypowania opisanej w roz dziale 2 . R a p o rty i m o d u ły ra p o rtu ją c e Typową częścią niemal każdej aplikacji biznesowej jest moduł tworzący raporty, których treść opisuje wyniki już wykonanego przetwarzania. Dane wchodzące w skład raportu są wybierane z bazy danych i po sformatowaniu prezentowane użytkownikowi w czytelnej postaci na ekranie, drukowane w postaci trwałego dokumentu papiero wego lub udostępniane na portalu informacyjnym w Internecie. Przeznaczeniem modułów raportujących jest wyłącznie informowanie użytkownika - zawartość bazy danych nie ulega w czasie tworzenia raportu żadnej zmianie. Przykładem modułu raportującego w aplikacji obsługującej wysyłkową sprzedaż towarów może być podprogram Drukowanie dokumentu PZ na rys. 3.22. Treść tego dokumentu jest typowym raportem, potwierdzającym dostawę i wyliczającym przyjęte do magazynu towary. Ani treść zamówień, ani stan magazynu nie ulegają podczas tworzenia dokumentu PZ żadnym zmianom. Postać dokumentu PZ, pokazana na rys. 3.24, jest przykładem raportu tabelarycznego, którego kolejne wiersze odpowiadają zawartości kolejnych wierszy wybranych z jednej lub kilku tabel bazy danych. Oprócz wartości odczytanych z bazy danych raport zawiera stały nagłówek, napisany przez użytkownika podczas definiowania raportu, oraz wartość ogólną obliczoną podczas generowania raportu zgodnie z algorytmem określonym podczas definiowania raportu. PZ
|
ul. Wysyłkowa 3 00-665 Warszawa NIP 222-22-22-222 REGON Data przyjęcia i/ ’ 1 2 3 4 5
] Oryginał/Kopia Dostawca: Hurtownia opon „Oponiarz" ul. Samochodowa 2 00-665 Warszawa NIP 111-11-11-111 | 05.04.2008 1 t
Dokum ent przyięcia do magazynu nr:
Przedsiębiorstwo Handlu Wysyłkowego
N im m towaru Michelin, Alpin 3,175/65 R14 Michelin, Alpin 3; 195/60 R15 Kleber, Krisalp Hp, 195/65 R15 Pirelli, W190 Snowsport, 195/60 R15 ¡Jniroyai, MS Plus 55, 215/65 R15
id towaru 0822 0823 0831 0841 0856
R y su n e k 3.24. Przykład raportu tabelarycznego
Ilość Jedn. miary 12 szt. szt. 16 8 szt. 8 szt. 4” szt.
\ Cena §75,00 1364,00 280,00 340,00 360,00
Wadość 3300,00 5824,00 2240,00 2720,00 1440,00
W artość ogółem :
15524,00
>
Stawka VAT 22% 22% 22% 22% 22%
^ 4 . T e c h n ik i p ro je k to w a n ia ap lik a c ji
1 19
Inną, często spotykaną postacią raportu jest raport macierzowy, w którym za równo wiersze, jak i kolumny odpowiadają różnym kategoriom obiektów, a komórki opisują relacje łączące te obiekty. Przykładem takiego raportu mógłby być raport sprzedaży, którego kratki pokazują sprzedaż różnych rodzajów opon (kolumny) W różnych województwach kraju (wiersze). F o rm u la rz e e k ra n o w e Przeważająca większość aplikacji biznesowych umożliwia interaktywną komunikację z użytkownikiem, który wprowadza do systemu dane (np. zamówienia, zapytania 0 stan pozycji magazynowych) i na bieżąco otrzymuje odpowiedzi systemu (np. okre ślenie dostępności towaru). Zasadniczym narzędziem takiej komunikacji są formularze ekranowe zawierające pola danych do wprowadzenia, przyciski wyboru, pola danych pokazujące obliczone wyniki, stale objaśnienia itd. Specyfikacja formularzy obejmuje zdefiniowanie pól danych i innych elementów, wskazanie rozmieszczenia tych ele mentów na powierzchni ekranu, określenie menu operacji dostępnych w formularzu 1zdefiniowanie reguł nawigacji między ekranami. Przykładem prostego dialogu z użytkownikiem może być podprogram Akcepta cja pozycji na rys. 3.22, który przyjmuje decyzję użytkownika dotyczącą przyjęcia lub odrzucenia pozycji dostawy. W tym celu podprogram wyświetli formularz zawierają cy: pole danych zamówienia, wyszukanego wcześniej w tabeli Zamówienia zaopa trzeniowe, pole danych pozycji dostawy, która została zeskanowana czytnikiem kodu kreskowego, oraz pole wyboru decyzji o akceptacji lub odrzuceniu. W iersz zamówie nia odpowiadający przyjmowanej pozycji zostanie zapewne podświetlony. ■
i
a
■
3.4.4. T e c h n o lo g ie w s p o m a g a ją c e
' '"r ~' ' ~y»^ .
Metody strukturalne dostarczają narzędzi koncepcyjnych (modeli) umożliwiających analizę problemu oraz przekształcenie modelu analitycznego w model projektowy, pokazujący budowę programu i bazy danych. Metody są wspierane przez technologie, które dostarczają narzędzi fizycznych (oprogramowanie wspomagające) umożliwiają cych automatyzację znacznej części prac projektowych i implementacyjnych. Prace analityczne, które wymagają twórczego wysiłku człowieka, są znacznie mniej podatne na automatyzację. Podstawowe technologie implementacyjne obejmują relacyjne bazy danych (RDBMS), systemy wspomagające projektowanie (CASE) oraz języki czwar tej generacji (4GL). Nośnikiem automatyzacji projektowania są języki czwartej generacji, które moż na określić jako języki problemowe, zorientowane na niezwykle wydajne progra mowanie komercyjnych aplikacji biznesowych. Charakterystyczną cechą lego obszaru zastosowań jest konieczność gromadzenia i manipulowania dużymi zbiorami danych, przy jednoczesnej prostocie wymaganych obliczeń. Podstawowe zadania aplikacji
120
3. M etody strukturalne
ograniczają się tu często do komunikacji z użytkownikiem, zapisywania i wyszukiwa nia potrzebnych danych oraz przygotowania wymaganych przez użytkownika raportów. Powróćmy raz jeszcze do przykładu aplikacji przyjęcia dostawy, pokazanej na rys. 3.24. Przestawione tam rozwiązanie, w którym interfejs użytkownika reprezentuje podprogram Akceptacja pozycji, jest mocno uproszczone. Implementacja interfejsu użytkownika jest złożona i rzadko udaje się skupić te funkcje w"jednym podprogra mie. W tym przykładzie w skład interfejsu użytkownika wejdzie zapewne dosyć dużo ekranów obsługujących sytuacje wyjątkowe, np. takie, w których nie uda się rozpo znać etykiety towaru i konieczne będzie wprowadzenie tych danych ręcznie (ekran wprowadzania towaru), lub takie, w których okaże się, że brakuje zamówienia, gdyż towary dostarczono na zamówienie telefoniczne (ekran edycji zamówienia). W rezul tacie struktura aplikacji zostanie zdominowana przez układ interfejsu użytkownika, z instrukcjami sięgającymi do tabel bazy danych lub modyfikującymi zawartość tych tabel, wplecionymi wprost w obsługę poszczególnych pól danych' i przycisków wyboru. Program aplikacji biznesowej, realizujący zarówno funkcje interfejsu użytkow nika, jak i dostępu do danych, można zaprogramować ręcznie w wybranym języku programowania, np. C. Alternatywą ręcznego budowania programu jest sięgnięcie do technologii wspomagających projektowanie i wykorzystanie narzędzi automatycznego generowania aplikacji, dostarczonych przez producenta bazy danych lub innego, niezależnego wytwórcę oprogramowania. Drugie rozwiązanie jest szybsze i mniej narażone na błędy. Wygenerowanie apli kacji wymaga zdefiniowania interfejsu (formularze i raporty), wskazania tabel bazy danych, z lub do których mają być przesiane wartości, podania kryteriów wybierania danych oraz określenia algorytmów obliczania wartości pochodnych. Program w języku czwartej generacji zostanie wygenerowany automatycznie, a jego interpretator (run-time module) może być włączony w skład aplikacji jako jeden z jej podprogramów. Technologia języków 4GL jest w pełni dojrzała. Generatory formularzy i gene ratory raportów, wchodzące w skład systemów wspomagających CASE, umożliwiają definiowanie różnych wariantów interfejsu, różnych typów dostępu do baz danych oraz prostych obliczeń. Z kolei narzędzia interpretujące programy 4GL mogą nie tylko współpracować z różnymi bazami danych, ale także oferują możliwość zdalnego dostępu wielu stacji roboczych użytkownika do odległych paz danych poprzez łącza sieciowe. !
3 .5 .
U w a g i b ib lio g ra fic z n e
Dobry opis dojrzałego już stanu rozwoju metodyki strukturalnej podają monografie [49, 45]. Przegląd konkretnych metod strukturalnych, pokazujący zarówno ich cechy wspólne, jak i dzielące je różnice, można znaleźć w książce [39].
„3.5. Uwagi bibliograficzne
Jii—
121
---------- ----------------------------------------------------
Metodyka strukturalna. Metodyka strukturalna opiera się na zasadzie modelo wania i systematycznego dekomponowania problemu w dwóch wymiarach: w dzie dzinie funkcji (procesów przetwarzania) oraz w dziedzinie danych. W ramach tej metodyki powstało szereg metod przypisujących różne znaczenie działaniom podej mowanym w obu tych dziedzinach. Klasyczne metody strukturalne, których rozwój zapoczątkowały prace Yourdona i DeMarco [50, 40, 46], przypisywały większe zna czenie dekompozycji i modelowaniu w dziedzinie funkcji. Odmienne podejście przyjmowały rozwijające się równolegle metody uznające strukturę danych za najbar dziej stabilny element problemu, do którego powinna zostać dopasowana struktura powstającego programu [48, 44]. W len nurt Wpisywały się też prace nad modelami danych [211, 210], których trwałym wynikiem koncepcyjnym był diagram encji oraz rozwój relacyjnych baz danych, które na długie lata określiły sposób przechowywania dużych ilości danych w systemach komputerowych. Wraz z rozwojem metod powstawały komputerowe narzędzia wspomagające, oferujące możliwość tworzenia diagramów i sprawdzania ich spójności, prowadzenia słownika projektu, a z czasem także generowania prototypów. Rozwój tych narzędzi oraz języków 4GL [14] doprowadził do powstania systemów wspomagających zdol nych do wygenerowania z modelu niemal gotowej aplikacji biznesowej. Ten nurt rozwoju zyskał nieco później nazwę RAD (Rapid Application Development) i wykro czył daleko poza melodykę strukturalną. Metodyka strukturalna dojrzała i począwszy od lat dziewięćdziesiątych XX wie ku nie rozwija się dalej. Intensywnie rozwijają się natomiast związane z tą metodyką technologie - systemy relacyjnych baz danych (RDBMS) i narzędzia wspomagające (CASE). Dzięki temu metodyka strukturalna wciąż utrzymuje dominujący udział w rynku IT (por. tab. 1.1). Drugim segmentem rynku, który stanowi'domenę zastoso wania metod strukturalnych, jest wytwarzanie systemów wbudowanych. Przyczyny tego stanu rzeczy są wyjaśnione w rozdziale 10. M etody stru k tu ra ln e . Rozwojowi koncepcji związanych z modelowaniem i projektowaniem oprogramowania towarzyszy! wymuszany potrzebami praktycznymi rozwój metod prowadzenia wielkich projektów informatycznych. Na przecięciu tych dwóch nurtów rozwojowych powstały kompletne metody projektowe, oferujące modele, narzędzia i techniki zarządzania projektami. Przykładami takich metod stosowanych z powodzeniem do dnia dzisiejszego - mogą być: * klasyczne metody Yourdona [50, 40,49], " metoda SSADM (Structured Systems Analysis and Design Method) |4I ] opra cowana i promowana przez brytyjskie agendy rządowe, ■ metoda CDM (Custom Development Method), znana wcześniej jako CASE*Method [203], opracowana i promowana przez firmę Oracle.
122
3. M etody strukturalne
W Polsce szczególnie popularna jest metoda CDM i jej mutacje, silnie wspierana przez potężne narzędzia wspomagające oferowane przez dominującego w naszym kraju producenta baz danych. Bardzo dobry opis technik analizy i projektowania strukturalnego, stosowanych w tej metodzie, można znaleźć w [207]. Nieco na uboczu głównego nurtu rozwijały się badania nad metodami wytwarza nia systemów wbudowanych, które wprowadziły szereg, rozszerzeń, związanych z koniecznością modelowania dynamiki systemu i przepływu sterowania, oraz zaak centowały potrzebę bardzo precyzyjnego definiowania wymagań i rygorystycznej dyscypliny prowadzenia projektu. Przykładami takich metod mogą być: metoda W arda-Mellora [47] (opisana w podrozdziale 10.3), metoda Hatley-Pirbhai [43] i używana w brytyjskiej armii metoda MASCOT (M odular Approach to Software Constniction Operation and Test) [52]. R elacyjne liazy danych. Bardzo ważnym, choć wyl i / i] jcym poza ramy tej książki tematem jest modelowanie i projektowanie baz danych. Czytelnik pragnący gruntownie poznać te zagadnienia powinien sięgnąć do opasłych monografii [208, 204, 205], Dobrym źródłem informacji mogą być też podręczniki [206, 202, 207],
4 M etody obiektow e
Świat, postrzegany z perspektywy obiektowej, sldada się z wielu niezależnych obiek tów, z których każdy zarządza jakim ś fragmentem rzeczywistości i obejmuje dane opisujące stan tego fragmentu oraz działania ten stan zmieniające. Przyjmując ten punkt widzenia, metodyka obiektowa dąży do odwzorowania struktury obiektów w architekturze oprogramowania i opisania procesu przetwarzania jako wyniku współ działania wielu obiektów, które współpracują ze sobą dla osiągnięcia założonego celu. Zapanowanie nad złożonością takiego opisu wymaga sklasyfikowania wszystkich obiektów i zdefiniowania ich budowy wewnętrznej, zachowania, wzajemnych relacji w przestrzeni i czasie oraz reguł współpracy. Przyjętą metodą opisu jest modelowanie wybranych aspektów systemu z różnych punktów widzenia. ■ Model procesów biznesowych pokazuje ogólny obraz dziedziny zastosowa nia, w której ma działać tworzone oprogramowanie, z punktu widzenia akto rów biznesowych. ■ Model wymagań opisuje wszystkie sposoby używania systemu do wspierania procesów biznesowych, tworząc niezależny od implementacji wzorzec za chowań oprogramowania, przedstawiony z punktu widzenia użytkowników. B Model dziedziny opisuje strukturę i zachowanie tych obiektów dziedziny za stosowania, których reprezentacja będzie przechowywana i przetwarzana przez tworzone oprogramowanie. B Model architektury oprogramowania opisuje główne komponenty systemu oraz ich zależności i zasady współpracy, tworząc schemat, zgodnie z którym zostaną zaimplementowane wszystkie programy. Wzajemna zależność modeli obiektowych oraz uznanie nieuchronności zmian w projekcie sprawiają, że budowa tych modeli nie przebiega na ogół sekwencyjnie, lecz jest powtarzana, rozwijana i modyfikowana wielokrotnie zgodnie z logiką ¡tera-
124
4. M etody obiektow e
cyjnego procesu wytwórczego. Wynikiem każdej iteracji jest działająca wersja syste mu. Wynikiem ostatniej iteracji jest implementacja całości oprogramowania. Duża liczba i różnorodność modeli obiektowych stwarzają jednak możliwość używania ich w różnych kombinacjach i w różny sposób, zależnie od przyjętej organizacji procesu wytwórczego. Zasadnicze różnice między podejściami polegają na różnej intensywno ści korzystania z technik modelowania. Procesy sformalizowane zalecają budowę obszernych, dokładnych i dobrze udokumentowanych modeli przed przystąpieniem do pisania programów. Procesy i metody zwinne (lekkie) preferuj;) oszczędne wykorzy stanie technik modelowania w minimalnym zakresie niezbędnym do wykształcenia koncepcji i struktury kodu. Najważniejsze elementy metodyki obiektowej określają zestaw modeli używa nych do opisu różnych aspektów oprogramowania, techniki modelowania wskazujące sposób i kolejność budowy modeli oraz metody odróżniania dobrych modeli od złych. ObickJpugMnodel systemu dobrze odpowiada strukturze obiektowych języków pro gramowania, w których podstawowymi jednostkami synlaktycznymi są klasy, defi niujące budowę obiektów współpracujących ze sobą podczas wykonania programu.
4 .1 .
N a rz ę d z ia m o d e lo w a n ia
Koncepcyjne narzędzia używane w procesie modelowania obiektowego wciąż się rozwijają i zarówno ich liczba, jak i postać podlegają nadal zmianom. Szeroko akcep towanym forum tego rozwoju jest konsorcjum OMG (Objęci Management Group), wspierane przez blisko 300 firm i organizacji informatycznych. Wynikiem prac tego konsorcjum jest język modelowania UML (Unijied Modeling Language) standaryzu jący zestaw, składnię oraz sposób rozumienia modeli obiektowych. Wersja 2 języka UML definiuje trzynaście różnych modeli graficznych (diagramów), wobec dziewię ciu, jakie występowały w wersji 1. Specyfikacja języka UML jest powszechnie uzna wanym punktem odniesienia, choć nie wszystkie praktycznie używane metody wyko rzystują pełny zestaw tych modeli. Lista diagramów wchodzących w slclad języka UML, wersja 2.1 [77], jest przed stawiona w tab. 4.1, wraz z krótkim opisem ich przeznaczenia. Różne modele mają różną silę wyrazu oraz różne znaczenie i przeznaczenie^, w procesie projektowym. Sześć z tych modeli, tzn. diagram klas, komponentów, pakietów, obiektów, struktury złożonej oraz rozmieszczenia, opisuje statyczną strukturę 'oprogramowania. Pozosta łych siedem, tzn. diagram czynności, przypadków użycia, maszyny stanowej, sekwen cji, komunikacji, przeglądu interakcji oraz czasowy, służy do opisu dynamicznego zachowania i współdziałania elementów systemu.
T a b e la
4.L Modele obiektowe (UML 2 . 1)
R o d z a j d ia g r a m u
P r z e z n a c z e n ie
O p is 4.1.1
D iagram
Id e n ty fik a c ja k a te g o rii u ż y tk o w n ik ó w o ra z sp o so b ó w u ż y w an ia
przypadków u ży cia
p rz e z nich sy ste m u
D iagram klas
M o d e lo w a n ie k las o b ie k tó w i ich w z a je m n y c h relacji
4 .1 .2
D iagram c zy n n o śc i
M o d e lo w a n ie p ro c e só w b iz n e so w y c h , sc e n a riu sz y p rz y p a d k ó w
4.2.1
(diagram a k ty w n o śc i)
u ż y c ia lub a lg o ry tm ó w
D iagram m a sz y n y stan o w ej
M o d e lo w a n ie histo rii ż y cia o b ie k tu - je g o s ta n ó w i m o ż liw y c h
4.4.1
p rz e jść m ię d z y stan am i D iagram k o m p o n e n tó w
M o d e lo w a n ie fiz y c z n y c h s k ła d n ik ó w o p ro g ra m o w a n ia , ich
4.5.1
z ależ n o ści i in te rfejsó w D iagram p a k ie tó w
G ru p o w a n ie e le m e n tó w m o d e lu w p a k ie ty i p o k a z a n ie
4.5.1
w z a je m n y c h z ależ n o ści p a k ie tó w .Diagram ro z m ie s z c z e n ia
M o d e lo w a n ie k o n fig u ra c ji sp rz ę to w y c h i p ro g ra m o w y c h
(diagram w d ro ż e n ia)
k o m p o n e n tó w sy ste m u
D iagram sek w e n c ji
M o d e lo w a n ie c z a so w e j s e k w e n c ji w y m ia n y k o m u n ik a tó w
(diagram p rz e b ie g u )
po d c za s w sp ó łp ra c y o b ie k tó w , p a k ie tó w lub k o m p o n e n tó w
D iagram k o m u n ik a c ji
M o d e lo w a n ie p rz e p ły w u k o m u n ik a tó w p o d c za s w sp ó łp ra c y
4.5.1
4 .5 .2
4 .5 .2
o b ie k tó w , p a k ie tó w lub k o m p o n e n tó w D iagram stru k tu ry z ło ż o n ej
M o d e lo w a n ie w e w n ę trz n e j stru k tu ry z ło ż o n ej k lasy, k o m p o n e n tu lu b p rz y p a d k u u ż y cia
D iagram prz e g lą d u
M o d e lo w a n ie p rz e p ły w u ste ro w a n ia w p ro c e sie b iz n e so w y m
interakcji
lu b sy ste m ie
D iagram o b ie k tó w
M o d e lo w a n ie c h w ilo w e j k o n fig u ra c ji o b ie k tó w o p ro g ra m o w a n ia
D iagram c za so w y
M o d e lo w a n ie u z ależ n ie ń cza so w y cli
Wszystkie diagramy mają czytelną postać graficzną oraz dobrze udokumento wane znaczenie. Wyjątkowe miejsce wśród modeli obiektowych zajmu je - niezależnie od metody i procesu wytwórczego - diagram klas, którego rozwój postępuje nieprze rwanie przez cały czas trwania projektu, a którego końcowa postać określa strukturę finalnego programu. Niemal wszystkie pozostałe modele opisują pewne właściwości klas, obiektów lub ich współdziałania. Drugim, charakterystycznym modelem obiek towym jest model przypadków użycia, który opisuje wymagania użytkowników i steruje przebiegiem procesu wytwórczego. Te dwa modele zostaną przedstawione oddzielnie w kolejnych punktach tego podrozdziału. Pozostałe diagramy języka UML będą opisywane sukcesywnie, wraz ze wskazaniem ich miejsca w projekcie.
126
4. M elody obiektow e
4 .1 .1 . M o d e l p rzy p a d k ó w użycia
ą ,l . N arzędzia m o delow ania
I2 7
czyć na diagramie w postaci prostokąta obejmującego przypadki użycia definiujące zachowanie systemu (rys. 4.2).
Wymagania użytkowników systemu informacyjnego można przedstawić w postaci listy zadań, które chcą oni za pomocą tego systemu wykonywać. Każde z tych zadań można opisać, podając'kolejność działań, w toku których użytkownik wybierze zada nie, poda dane niezbędne do jego realizacji i odbierze potrzebne mu wyniki. W ten sposób opis wymagań przyjmie postać opisu wszystkich sposobów używania systemu przez użytkowników. Podstawowymi elementami tak zbudowanego modelu są: akto rzy (actors), z których każdy reprezentuje pewną kategorię użytkowników systemu, przypadki użycia (use cases) opisujące sposoby używania systemu przez aktorów oraz relacje kojarzące aktorów z przypadkami użycia. Na przykład, zadania wykonywane przez firmę ubezpieczeniową obejmują za warcie ubezpieczenia OC lub AC oraz wypłacenie odszkodowania, nazywane likwi dacją szkody. i Z a w a rc ie u b e z p ie c z e n ia jest wykonywane na zlecenie klienta, któremu przynosi korzyść w postaci ochrony przed odpowiedzialnością cywilną lub rozbiciem własnego samochodu. Wykonanie zadania obejmuje wypełnienie danych na formularzu, dołączenie kopii dokumentów samochodu, opłacenie składki i odebranie polisy ubezpieczeniowej. L ik w id a c ja s z k o d y następuje na wniosek klienta, któremu przynosi korzyść w postaci zwrotu poniesionych kosztów. Wykonanie zadania obejmuje wypełnienie formularza zgłoszenia szkody, przedstawienie polisy ubezpieczeniowej, ocenienie przez firmę zasadności roszczenia i wartości szkody oraz dokonanie przelewu na konto klienta.__________________________________________
Graficzną reprezentacją modelu jest diagram przypadków użycia (use case dia gram), którego podstawowymi elementami są ikony aktorów, owale reprezentujące przypadki użycia oraz linie przedstawiające zachodzące między nimi relacje (rys. 4 .1). istnienie relacji łączącej aktora z przypadkiem użycia wskazuje na zaangażowanie tego aktora w realizację danego przypadku. Aktora inicjującego wykonanie przypadku użycia można wyróżnić dodatkową strzałką umieszczoną na końcu linii relacji.
Informacyjna zawartość diagramu przypadków użycia jest dość uboga i nie opi suje wystarczająco dokładnie sposobu używania systemu przez użytkowników. Dla tego podstawowym środkiem dokumentowania modelu jest tekstowy zapis scenariu szy, opisujących krok po kroku sposób wykonania wszystkich przypadków użycia. Na przykład, scenariusz likwidacji szkody z ubezpieczenia można przedstawić następująco. Likwidacja szkody S c e n a riu s z g łó w n y :
1. Przyjmujący rejestruje zgłoszenie szkody w systemie. Zgłoszenie obejmuje numer polisy, dane zgłaszającego, datę wypadku i datę zgłoszenia. 2. System tworzy sprawę likwidacji szkody i nadaje jej unikalny numer identyfikacyjny. 3. Przyjmujący wprowadza dane określające charakter szkody, obejmujące opis wypadku i opis uszkodzeń, oraz podpisuje dokument zgłoszenia. 4. Rzeczoznawca określa wartość szkody. 5. System przypisuje likwidatora szkody, który ocenia zasadność zgłoszenia i prowadzi po stępowanie odszkodowawcze. 6. Likwidator oblicza wartość odszkodowania i przekazuje zlecenie wypłaty do działu księ gowości.
W trakcie likwidacji szkody mogą pojawić się różne sytuacje nadzwyczajne, uniemożliwiające doprowadzenie procedury do końca, np. zgłoszenie może okazać się duplikatem (sprawę zgłosili niezależnie sprawca wypadku i poszkodowany właściciel pojazdu) albo polisa ubezpieczeniowa może okazać się z jakichś powodów nieważna. Scenariusz postępowania ulega wówczas zmianie i pojawiają się scenariusze alterna tywne. Aktorzy diagramu przypadków użycia modelują zewnętrzne obiekty współpra cujące z budowanym systemem. Mogą nimi być ludzie, np. klienci, operatorzy, pra cownicy firmy, lub urządzenia i inne współpracujące systemy. Przypadki użycia opisują zachowanie systemu widziane oczami aktorów. Między systemem a otocze niem, z którym ten system ma współpracować, istnieje granica, którą można zazna
Likwidacja szkody
-
S c e n a riu s z a lte rn a ty w n y 1 - d u p lik a t z g ło s z e n ia :
1. Jak w scenariuszu głównym. 2. System powiadamia o istniejącym zgłoszeniu i odmawia utworzenia sprawy.
■•,€>.
4. M etody obiektow e
128 S c e n a riu s z a lte rn a ty w n y 2 - n ie w a ż n a p o lis a :
1-5. Jak w scenariuszu głównym. 6. Likwidator powiadamia klienta o odmowie odszkodowania i zamyka sprawę.____________
Pojedynczy przypadek użycia reprezentuje więc zbiór scenariuszy, w którym ist nieje scenariusz główny, opisujący typowy sposób postępowania prowadzący do osiągnięcia celu użytkownika, oraz scenariusze alternatywne, opisujące sposoby postępowania w razie niemożności wykonania scenariusza głównego. Modelowanie wymagań za pomocą przypadków użycia może przebiegać na róż nych poziomach abstrakcji. Przypadki użycia Zawarcie ubezpieczenia i Likwidacja szkody tworzą całościowy opis sposobów obsługiwania klientów przez przedsiębior stwo ubezpieczeniowe. Taki model jest bardzo użyteczny w początkowym stadium projektu. Dalsza analiza reguł działania i wymagań użytkowników może prowadzić do wyodrębnienia przypadków użycia opisujących sposoby używania systemu do wyko nania poszczególnych kroków obsługi klienta przez pracowników firmy, takich jak: Rejestracja dokumentu, Rejestracja zgłoszenia szkody, Utworzenie sprawy szkody, Wycena wartości, szkody, Obliczenie odszkodowania itd. Każdy z tych przypadków użycia jest odrębnym zadaniem, wykonywanym przez uprawnionego pracownika firmy ubezpieczeniowej przy wykorzystaniu określonych funkcji systemu. W miarę budowania coraz dokładniejszego modelu liczba przypadków użycia ro śnie i pojawia się problem zapanowania nad złożonością rozrastającego się modelu. Środkiem do tego celu jest uporządkowanie zbioru przypadków użycia za pomocą relacji (związków) obrazujących wzajemne zależności różnych przypadków użycia i umożliwiających wyodrębnienie i wielokrotne wykorzystanie części wspólnych. Język UML definiuje trzy zasadnicze rodzaje takich relacji: uogólnienie, rozszerzenie i zawieranie. Uogólnienie (generaliz.alion) modeluje sytuację, w której jeden przypadek uży cia określa pewien ogólny scenariusz postępowania, w ramach którego inne przypadki realizują swoje specyficzne scenariusze, odbiegające w pewnych miejscach od ogól nego schematu. Na przykład, rejestracja zgłoszenia szkody w systemie informatycz nym firmy ubezpieczeniowej, z którą wiąże się otwarcie nowej sprawy o likwidację szkody, jest szczególnym przypadkiem rejestrowania dowolnego dokumentu składa nego na dziennik w kancelarii firmy. Aby zaznaczyć pokrewieństwo obydwu przy padków i uniknąć dwukrotnego powtarzania opisu tych sairtych kroków scenariusza, można te przypadki udokumentować następująco. i PU1. R e je s tra c ja d o k u m e n tu (uogólnienie) 1. 2. 3. 4. 5.
Pracownik rozpoczyna proces. System wyświetla formularz rejestracji dokumentu. Pracownik wprowadza opis dokumentu (rodzaj dokumentu, data, składający). Pracownik zatwierdza rejestrację. System rejestruje dokument i nadaje mu unikalny numer.
4.1. N arzędzia m odelow ania
129
PU 2. R e je s tra c ja z g ło s z e n ia s z k o d y (specjalizacja PU1) 1-5. Jak w przypadku uogólniającym. 6. Utworzenie sprawy likwidacji szkody (PU4). 7. Przyjmujący wprowadza dane szkody (okoliczności powstania, zakres uszkodzeń, uczestnicy). 8. Przyjmujący zatwierdza rejestrację danych szkody.
Rozszerzenie (extension) modeluje sytuację, w której scenariusz jednego przy padku użycia może być czasem rozszerzony o dodatkowe czynności, włączane w ściśle określonym miejscu scenariusza podstawowego. Te dodatkowe czynności tworzą odrębny przypadek użycia, który może być również wykorzystany samodziel nie albo w kontekście innego przypadku użycia. Na przykład, zarejestrowanie doku mentu w systemie ubezpieczeniowym wymaga często dołączenia tego dokumentu do jednej z prowadzonych spraw. Dołączenie dokumentu do sprawy nie jest integralną częścią rejestracji dokumentu, ponieważ niektóre dokumenty nie są związane z żadną prowadzoną sprawą. Z drugiej strony potrzeba dołączenia dokumentu do sprawy może wystąpić samodzielnie, np. w sytuacji, w której jakiś dokument nie został podczas rejestracji dołączony do właściwej sprawy. Rozszerzający przypadek użycia można zapisać następująco. PU3. D o łą c ze n ie d o k u m e n tu d o s p ra w y (rozszerza PU1 po kroku 5) 1. Pracownik wybiera opcje dołączenia do sprawy. 2. System wyświetla ekran wyboru sprawy. 3. Pracownik wybiera sprawę i zatwierdza dołączenie.
Z aw ieranie (inclusion) modeluje sytuację, w której scenariusz jednego przy padku użycia jest wykonywany jako część innego przypadku użycia. Jednym z powo dów stosowania tej relacji może być chęć wyodrębnienia części wspólnej wielu przy padków użycia, tak aby nie powtarzać wielokrotnie opisu tych samych kroków. Innym powodem może być chęć podzielenia jednego skomplikowanego przypadku użycia na kilka przypadków prostszych. Zawieranie jednego przypadku użycia w innym można udokumentować następująco. PU4. U tw o rze n ie s p ra w y lik w id a c ji s z k o d y (włączane przez PU2)
~~
S c e n a riu s z g łó w n y :
1. System wyświetla formularz utworzenia sprawy. 2. Przyjmujący wprowadza opis sprawy (numer polisy, dane zgłaszającego, datę wypadku i datę zgłoszenia). 3. Przyjmujący zatwierdza opis sprawy. 4. System sprawdza poprawność zgłoszenia. 5. System tworzy sprawę i nadaje jej unikalny numer. S c e n a riu s z a lte rn a ty w n y 1 - d u p lik a t z g ło s z e n ia : 1-4. Jak w scenariuszu głównym. 5. System powiadamia o istniejącym zgłoszeniu i odmawia utworzenia sprawy.
4. M etody obiektow e
4.1. N arzędzia m odelow ania
131
- ń•----------------------------------------
Relacje porządkujące zbiór przypadków użycia mają swoje oznaczenia graficzne i mogą być pokazane na diagramie. Diagram reprezentujący przypadki użycia PU 1PU4 wraz z dodatkowym przypadkiem rejestracji sprawy szkody wymagającej refun dacji obcego ubezpieczyciela (tzw. regres) jest pokazany na rys. 4.3. Warto zauważyć, żc relacja uogólnienia może dotyczyć także aktorów. Nie ma w tym nic dziwnego aktor reprezentuje przecież klasę użytkowników odgrywających określoną rolę w systemie. Aktor specyficzny (Przyjmujący) dziedziczy wszystkie cechy aktora ogól nego (Pracownik), w tym także jego relacje. Z diagramu wynika więc, że pracownik (dowolny pracownik przedsiębiorstwa ubezpieczeniowego) może tylko rejestrować przyjęcie dokumentów i ewentualnie dołączać te dokumenty do właściwej sprawy. Natomiast Przyjmujący (pracownik punktu obsługi klientów) może rejestrować doku menty oraz rejestrować i tworzyć sprawy likwidacji szkód.
R ysunek 4.3. D ia g r a m p r z y p a d k ó w u ż y c i a z w ią z a n y c h z r e je s t r a c ją s z k o d y
Porównując diagram przypadków użycia z tekstowym zapisem scenariuszy przy padków użycia, można zauważyć, że zasadnicza informacja przydatna w procesie tworzenia oprogramowania jest zawarta w opisie tekstowym. Diagramy pozwalają objąć całość zadań systemu na bardzo wysokim poziomie ogólności. Natomiast szcze góły, określające treść zadań do wykonania, są zawarte wyłącznie w opisie teksto wym. Co więcej, w dużym projekcie, w którym liczba przypadków użycia sięga kilkudziesięciu lub nawet kilkuset przypadków, notacja graficzna zatraca swój główny walor poglądowości i staje się nieczytelna. Dlatego w praktyce dokumentacja dużych projektów obejmuje często wyłącznie tekstowe opisy przypadków użycia, pozosta wiając ewentualnie graficzne formy modelu jako pomocniczejfilustracje. D o k u m e n ta c ja m o d e lu Przypadki użycia są modelem wymagań użytkownika. Jednak ani scenariusze, ani diagramy przypadków użycia nie opisują całości wymagań stawianych systemom informatycznym. Poza zakresem modelu pozostają wymagania niefunkcjonalne oraz la część wymagali funkcjonalnych, która dotyczy algorytmów wykonania poszczegól nych kroków scenariusza. Uzupełnieniem brakujących elementów wymagań są
zwykle dodatkowe opisy tekstowe, zamieszczane w dokumentacji modelu przypad ków użycia. Ostateczna forma specyfikacji zależy od standardów dokumentacyjnych przyjętych w danym projekcie. Bardzo często pełna dokumentacja modelu (tekstowa) jest bardzo obszerna i obejmuje następujące elementy, określane dla każdego przy padku użycia: * nazwę (np. Rejestracja dokumentu) i numeryczny identyfikatórfiTffrPf//); ■ krótki opis zadania (np. rejestracja dowolnego dokumentu przyjętego w kan celarii); * aktorów' zaangażowanych w wykonanie danego przypadku; ■ zdarzenia inicjujące wykonanie przypadku (np. dostarczenie pisma do kance larii); ■ rezultaty wykonania (np. dokument zarejestrowany i dołączony do sprawy); ■ scenariusz główmy, prowadzący do wykonania zadania, oraz scenariusze al ternatywne, określające sposób postępowania w sytuacjach nietypowych; H reguły biznesowe, tzn. wszystkie znane reguły algorytmiczne określające spo sób wykonania kolejnych kroków scenariusza; B dokumenty potrzebne do realizacji scenariusza oraz dokumenty wytwarzane w'wyniku jego wykonania; ■ wymagania niefunkcjonalne, określające szacunkowo częstość wykonania da nego przypadku użycia, rozmiar przetwarzanych danych lub wymagany czas jego wykonania; n uwagi i otwarte pytania, wskazujące wszystkie sprawy niejasne w chwili two rzenia modelu, które muszą zostać wyjaśnione przed implementacją systemu. Z a s to s o w a n ie Modelowanie przypadków użycia jest uznaną metodą opisywania wymagań użytkow nika w sposób całkowicie niezależny od technologii realizacji systemu. Zaletami mo delu są czytelność i łatwość weryfikacji przez użytkowników i ekspertów w dziedzinie zastosowania. Dlatego budowa tego modelu jest podstawowym sposobem analizy i uzgadniania wymagań w fazie rozwijania projektu, przed przystąpieniem do kon strukcji oprogramowania. Podział całości modelu na grupy przypadków użycia o różnym stopniu ważności dla powodzenia przedsięwzięcia jest narzędziem planowa nia kolejności prac konstrukcyjnych w iteracyjnym procesie wytwórczym. Scenariusze przypadków użycia opisują wszystkie wymagane zachowania, z ja kich korzystają użytkownicy systemu. Zbiór tych scenariuszy tworzy więc niemal gotowy schemat scenariuszy testowania akceptacyjnego. Z tych samych powodów scenariusze przypadków użycia można wykorzystać podczas opracowania podręczni ków użytkownika jako naturalny schemat opisu pokazującego sposób wykonania typowych zadań przy użyciu nowego systemu.
132
4. M elody obiektow e
4 .1 .2 . D iag ram klas Świat, postrzegany z perspektywy obiektowej, składa się z wielu niezależnych obiek tów, które działają według pewnych reguł i współpracują ze sobą dla osiągnięcia założonego celu. Podstawowym sposobem budowania i porządkowania modelu świata jest kIas;w"ifHTf:i. czyli odnajdywanie klas (zbiorów) obiektów podobnych, zbudowa nych zgodnie z tym samym wzorcem i podejmujących takie same działania. Poznawa nie świata przez klasyfikowanie postrzeganych wokół obiektów jest fundamentalnym wzorcem pozyskiwania i porządkowania wiedzy przez człowieka. Stworzenie klasyfi kacji wszystkich znanych obiektów umożliwia rozszerzanie wiedzy i definiowanie nowych klas obiektów i nowych zachowań, przez wskazywanie podobieństwa do jakiejś istniejącej klasy i definiowanie różnic. Na przykład, wszystkie transakcje realizowane w przedsiębiorstwie sprzedaży wysyłkowej, które rozważaliśmy w poprzednim rozdziale, zaczynają się od złożenia przez klienta zamówienia na potrzebne mu towary, y / systemie istnieje więc klasa Klient, zawierająca wszystkich nabywców, oraz klasa Zamówienie, z których każde określa kupowane towary. Każdy obiekt należący do klasy Klient ma takie same atrybuty, np. nazwisko i adres, i każdy może wykonywać te same operacje, np. złożyć zamówienie. Podobnie, każdy obiekt należący do klasy Zamówienie ma takie same atrybuty, np. data złożenia, adres dostawy oraz status, i każdy może wykonać te same operacje, np. wydrukować swą treść oraz obliczyć wymaganą zaliczkę, przedpłatę, całkowitą wartość i podatek.
4.1. N arzędzia m odelow ania
z tych obiektów może wydrukować swój opis, każdy może wskazać potrzebę opłace nia zaliczki podczas zamawiania i każdy może być skojarzony z jakim ś obiektem klasy Pozycja. Relacja uogólnienia wprowadza hierarchię klas, w której takie same operacje występują w klasie ogólnej (nadrzędnej) i w klasach szczegółowych, położonych niżej .w hierarchii. Sposób wykonania tych operacji może być jednak różny i - na przykład - operacja z.aksięguj() może być realizowana w klasie Przelew inaczej niż w klasie WplataGotówkowa. W ten sposób klasa nadrzędna wprowadza pewną operację, a klasy pochodne dostarczają metod do jej realizacji. i Pokazana na rysunku klasyfikacja towarów nie musi być kompletna - mogą ist nieć towary, które nie należą do żadnej z pokazanych tu klas pochodnych. Klasyfika cja płatności ma inną naturę. Ograniczenie complete wskazuje, że ta klasyfikacja jest kompletna i każda Płatność jest albo Przelewem, albo Wplatcj Gotówkową. Nie ma innego rodzaju Płatności. Tym samym nie można powołać do życia żadnego obiektu Płatność bez jednoczesnego umiejscowienia go w którejś klasie pochodnej. Płatność jest więc klasą abstrakcyjną, co wizualnie podkreśla zapisanie jej nazwy na diagramie kursywą. Pozycja
Zamówienie
ilość cena
data adresOdbiorcy status
obliczW artośćf) drukuj() obliczŻaliczkę!)
Modelem obrazującym strukturę i wzajemne powiązania obiektów występują cych w systemie jest diagram klas (rys. 4.4). Głównymi elementami modelu są klasy obiektów, rysowane jako prostokąty, i ich relacje, czyli statyczne związki zachodzące między obiektami różnych klas, rysowane w postaci linii łączących klasy na diagra mie. Prostokąt obrazujący klasę jest zazwyczaj podzielony na trzy segmenty, zawie rające kolejno: nazwę klasy, zbiór atrybutów charakteryzujących każdy obiekt tej klasy oraz zbiór operacji, które mogą wykonać obiekty. Zarówno atrybuty, jak i ope racje mogą być czasem pominięte. W takim przypadku albo pozostawia się na rysunku puste segmenty, albo po prostu rysuje prostokąt zawierający tylko nazwę klasy. Zależnie od natury związku łączącego obiekty relacja może należeć do kategorii uogólnienia lub skojarzenia. Uogólnienie (generalization), Uvyróżnione na rysunku białym (niewypełnionym) trójkątem na końcu linii relacji, modeluje sytuację, w której obiekty jednej klasy są szczególnym przypadkiem obiektów innej klasy. Na przykład, szczególnym rodzajem Towaru sprzedawanego w sklepie wysyłkowym może być Opona, Fotelik lub Pokrowiec. Semantyka związku uogólnienia wymaga, aby każdy obiekt klasy specyficznej byl jednocześnie obiektem klasy uogólniającej, tzn. miał wszystkie jego atrybuty, realizował wszystkie jego operacje i pozostawał w tych samych relacjach z innymi klasami. Tak więc każda Opona na rys. 4.4, każdy Fotelik i każdy Pokrowiec mają swoją nazwę, producenta, cenę i stopę podatku VAT, każdy
133
0..*
drukuj!) obliczW artośćf) drukujFakturęf) w yślij!) zam knij!)
0?~ wskazuje ▼
Klient i nazwa adres
« składa
zamów( )
1..* -«dotyczy
Płatność data kwota
4/1 Towar
zaksięguj! )
nazwa producent cena stopaVat
(complete)
drukujOpis( ) czyZaliczkaj)
Przelew IdPrzelewu nrKonta
ZE Opona rozmiar
Fotelik wagaDziecka opis
Pokrowiec kolor
R y su n e k 4.4. D iagram klas systeniu sprzedaży w ysyłkow e
E WplataGotówkowa nazwaKuriera
4, M etody obiektow e
Skojarzenie (association), nazywane też asocjacją lub powiązaniem, modeluje sytuację, w której obiekty jednej klasy są w pewien sposób związane z obiektami innej klasy. Na przykład, Zamówienie jest związane z Klientem, który je zlożyl. Podobnie, Płatność jest związana z Zamówieniem, którego realizacji dotyczy. Rodzaj związku występującego między obiektami w dziedzinie aplikacji opisuje nazwa relacji umiesz czona na rysunku w pobliżu środka linii. Czarny trójkącik obok nazwy wskazuje kierunek czytania nazwy: to Klient składa Zamówienie, a nie Zamówienie składa Klienta. Nazwa relacji jest elementem opcjonalnym, który ma za zadanie ułatwić czytanie rysunku i jego weryfikację przez eksperta w dziedzinie aplikacji. Alternatyw nym sposobem opisywania znaczenia relacji jest wskazanie roli obiektu w tym skoja rzeniu - nazwę roli umieszcza się zwykłe w pobliżu końca relacji (rys. 4 .6). Jeżeli potraktujemy klasy jak zbiory obiektów, to istniejąca między nimi asocja cja jest zbiorem par obiektów stowarzyszonych - po jednym obiekcie z każdej klasy. Istotne dla przyszłej implementacji systemu jest wskazanie, w ilu takich parach może wystąpić jeden obiekt danej klasy. Na przykład: czy Zamówienie jest związane z jedną tylko Płatnością, czy może być opłacone w kilku ratach? Nasz sklep dopuszcza płat ności w ratach (niekiedy sam wymaga zaliczki, a później dopłacenia reszty). Tę in formację zaznaczają na diagramie symbole krotności umieszczone w pobliżu końca linii relacji. Opisują one liczbę obiektów z klasy stykającej się z tym końcem, które mogą być związane z pojedynczym obiektem klasy narysowanej na drugim końcu relacji. W naszym przykładzie Klient może złożyć dowolnie wiele Zamówień (w tym zero), ale każde Zamówienie może być złożone tylko przez jednego Klienta. Z kolei każde Zamówienie może być opłacone w kilku ratach, a każda Płatność może doty czyć dowolnie wielu Zamówień (nie mniej niż jednego).
Wszystkie rodzaje relacji, występujące na diagramie klas, obrazują statyczne związki zachodzące między obiektami w różnych okresach ich życia. Nie jest to równoznaczne z dynamicznym wywoływaniem operacji jednych obiektów przez inne. Sposób i kolejność współpracy obiektów przedstawiają w języku UML inne diagramy. Klasa jest zbiorem obiektów. Każdy egzemplarz klasy, czyli obiekt, zawiera dane zapisane w postaci wartości jego atrybutów. Asocjacja jest zbiorem par obiektów. Egzemplarz asocjacji, czyli para obiektów, nie ma żadnych nowych atrybutów ani operacji poza atrybutami i operacjami tworzących ten egzemplarz obiektów. 'Paki sposób modelowania nie oddaje dobrze wszystkich sytuacji rzeczywistego świata, w którym występują takie jednostki danych i takie działania, które charakteryzują raczej poszczególne egzemplarze relacji niż poszczególne obiekty skojarzonych klas. Na przykład, w systemie obsługującym wypożyczenia książek w bibliotece wystąpią na pewno klasy Czytelnik i Książka połączone relacją wypożyczenia. Wypożyczenie ma swoją datę i termin zwrotu książki. Obie te wartości nie charakteryzują ani czytel nika, ani książki, ale właśnie wystąpienie relacji wypożyczenia. Takie jednostki da nych można umieścić w klasie asocjacyjnej, czyli dodatkowej klasie, której obiekty opisują poszczególne egzemplarze relacji. Warto zauważyć, że w rzeczywistym sys temie bibliotecznym taka klasa oczywiście istnieje, a jej obiekty są nazywane rewer sami (rys. 4.3). Czytelnik
Książka O
numer status
CO
Szczególnym rodzajem skojarzenia jest kom pozycja | composition), zwana też agregacją całkowitą lub zespoleniem, wyróżniana graficzni»! czarnym rombem i mo delująca sytuację, w której obiekt jednej klasy jest częścią obiektu jakiejś innej klasy. Na przykład, Pozycja zamówienia jest w oczywisty sposób częścią całego Zamówie nia. Krotność tej relacji na rys. 4.4 wskazuje, że zamówienie może mieć wiele pozycji (co najmniej jedną). Nie ma natomiast sensu opisywanie krotności drugiego końca relacji, gdyż z definicji obiekt może być częścią tylko jednej kompozycji.
Słabszym wariantem kompozycji jest agregacja (aggregation), oznaczana kontu rem rombu o pustym wnętrzu, która dopuszcza możliwość bycia częścią kilku różnych całości. Agregacja jest częścią języka UM L i pojawia się niekiedy na diagramach, do których jednak zbyt wiele informacji nie wnosi.
0
Skojarzenie obiektów sugeruje, że znając jeden obiekt, będzie można łatwo od naleźć ten drugi i np. znaleźć zamówienie złożone przez konkretnego klienta. Realiza cja tej możliwości wymaga jednak utrzymywania w implementacji obiektu odsyłacza do obiektu skojarzonego. Nie zawsze jest to potrzebne. Ograniczenie możliwości odnajdywania skojarzonego obiektu obrazuje strzałka pokazująca dopuszczalny kieru nek nawigacji. Zgodnie z. rys. 4.4, znając Pozycję zamówienia, można łatwo odpaleźć Towar, który ta pozycja wskazuje. Ale znając Towar, nie da się łatwo odszukać tych wszystkich Pozycji różnych zamówień, które ten Towar wskazują.
13 5
4 1 N a rz ę d z ia m o d e lo w a n ia
;
¡
zam ów( ) wypożycz( ) z.wróć( )
pożyczył
1
nazwa adres p rzyp o m n ij( ) lim it! )
----------!--------Rewers okres data
R ysunek 4.5. Klasa asocjacyjna
In te rp re ta c ja d ia g ra m u Diagram klas jest głównym modelem obiektowym, który przewija się nieustannie przez cały czas trwania projektu. W ciągu tego czasu zmienia się zarówno poziom wiedzy, jak i zakres zainteresowania autorów i czytelników diagramu. Na początko wym etapie projektu diagram służy głównie modelowaniu dziedziny problemu
136
4. M elody obiektow e
i występujących w tej dziedzinie pojęć. Na końcowym etapie projektu diagram staje się modelem powstającego oprogramowania. Tę ewolucję sposobu interpretowania diagramu klas wyraża się często, mówiąc o różnych perspektywach widzenia diagramu. Perspektywa pojęciowa opisuje punkt widzenia analityka systemu. W tej per spektywie diagram klas służy przede wszystkim opisowi i porządkowaniu dziedziny problemu, kategoryzacji obiektów podlegających przetwarzaniu i pokazaniu stałych związków występujących między obiektami różnych klas. Model pojęciowy nie musi jeszcze mieć bliskiego związku z implementacją. Często nie uwzględnia się w nim operacji, których przypisanie jest decyzją projektową, często nie podaje się typu atrybutów. Co więcej, atrybuty klas traktuje się jako porcje danych charakteryzują cych obiekty, ale niekoniecznie implementowanych (później) jako pola klas w kodzie programu. Na przykład, z faktu, że w klasie Klient na rys. 4.4 występuje atrybut adres, wynika tylko tyle, że każdy klient ma swój adres. Natomiast czy adres jest polem klasy, czy obiektem skojarzonej klasy Adres - tego model nie rozstrzyga.
4 1 N a rz ę d z ia m o d e lo w a n ia
— .--------------------
137
ców zakładanych na siedzenia samochodu. Ponieważ komplet ma wszystkie cechy zarówno fotelika, jak i pokrowca, więc hierarchię relacji uogólnienia różnych rodza jów towarów można przedstawić jak na rys. 4.7. Pojęciowe znaczenie tego modelu jest jasne - Komplet jest szczególnym rodzajem Towaru, który ma wszystkie cechy Fotelika i Pokrowca. Implementacja modelu w języku C-H- też jest jasna - klasa Komplet dziedziczy po dwóch klasach bazowych (podstawowych): Pokrowiec i Fote lik, a te dziedziczą po klasie Towar. Implementacja w Javie jest jednak mniej jasna w tym języku nie ma dziedziczenia wielobazowego (wielodziedziczenia) i w którymś momencie projektu trzeba będzie dopasować model do semantyki dziedziczenia języka implementacji.
W pojęciowym diagramie klas nie ma istotnej różnicy między atrybutem a aso cjacją. Fakt, że każdy klient ma swój adres, można równie dobrze przedstawić w sposób pokazany na rys. 4.6 Nie ma między tymi modelami żadnych różnic poję ciowych - w obu przypadkach istnieje jednoznaczny związek między klientem a jego adresem. Natomiast znaczenie ma wyodrębnienie klasy Adres, które umożliwia odse parowanie opisu przetwarzania związanego z adresem, np. drukowania etykiet adre sowych i sprawdzania poprawności kodu pocztowego, od opisu przetwarzania zwią zanego z klientem, np. przyjmowania jego zamówień. Zwiększa to spójność definicji klas i możliwość ponownego wykorzystania raz opracowanego fragmentu (klasy) w innych miejscach projektu, np. do opisania adresu odbiorcy Zamówienia lub wypo sażenia klienta w dodatkowy adres korespondencyjny.
R ysunek 4.7. Podwójne dziedziczenie
R ysunek 4.6. Związek klienta z adresem
1,
\ Perspektywa pojęciowa nie traktuje też relacji uogólnienia jako oczywistego mo delu mechanizmu dziedziczenia obiektowych języków programowania. Relacja uogólnienia klas wyraża tu tylko fakt, że obiekty jednej klasy są szczególnym przy padkiem obiektów innej ldasy. Sposób zaimplementowania tej relacji w kodzie pro gramu nie jest z tego punktu widzenia istotny. Dla zilustrowania problemu przypuść my, że sprzedaż wysyłkowa objęła komplety złożone z fotelika dziecięcego i pokrow
Bardziej złożony problem powstanie wtedy, gdy specjaliści od marketingu w przedsiębiorstwie sprzedaży wysyłkowej podzielą wszystkie towary na luksusowe, dla których zaplanowano specjalną akcję promocyjną, i te z dolnej półki. W wyniku tych działań powstanie model pokazany na rys. 4.8. Pojęciowe znaczenie tego modelu jest jasne - towary można podzielić na kilka grup w różny sposób, zależnie od wybra nego kryterium podziału. Możliwość implementacji modelu przedstawia się już mniej jasno - żaden współczesny język programowania nie wspiera podwójnej klasyfikacji obiektów (dziedziczenie wielobazowe w C++ opisuje inny aspekt uogólnienia).
138
4. M etody obiektow e
139
4.1 . N a rz ę d z ia m o d e lo w a n ia
—h
Pozycja
Zam ówienie
11 ilość: int
+ data: Data {readonly)
fi cena: Kwota
+ adresO dbiorcy: Adres ff status: int - wartość: Kwota
+ znaidżPozvcie( i: Lista fi o b liczW a rto ść(): Kwota It o b licz P o d a te k j): Kwota - dajS taw kęP odatku(): int -o b lic z R a b a t(): Kwota
+ drukuj{ )’■void It obliczZaliczkę (): Kwota It obliczP rze dp la tę( ): Kwota # o b liczW a rto ść( ): Kwota It o b liczP o d a tek( ): Kwota - da(K alkulatorP odatku( ) - dajK alkułatorZaliczki() - dajl
Przygotowanie towaru
Wycena zamówienia
■ł>
Wysianie przesyłki
Y
Zamknięcie zamówienia
>©
[OK]
■>©
[OK]
R ysunek 4.12. Proces sprzedaży w przedsiębiorstwie handlowym
Istotnym rozszerzeniem pierwotnego modelu jest możliwość zapisywania czyn ności równoległych oraz możliwość odróżniania czynności wykonywanych podczas rutynowej realizacji procesu od czynności wykonywanych w sytuacjach nadzwyczaj nych. Na przykład, przygotowaniu przesyłki w przedsiębiorstwie handlowym towa rzyszy zwykle przygotowanie faktury, wysyłanej na ogół razem z towarem. Obie te czynności postępują równolegle i obie należą do działań rutynowych. Za działanie nadzwyczajne, zdarzające się stosunkowo rzadko, można natomiast uznać przerwanie przygotowań po skasowaniu przez klienta przyjętego do realizacji zamówienia. Roz winięty diagram czynności procesu sprzedaży, uwzględniający te sytuacje, jest poka zany na rys. 4.13. Miejsce rozchodzenia się (rozwidlenie) procesu na równolegle ciągi czynności za znacza gruba kreska, od której odchodzi kilka strzałek. Każda strzałka wyjściowa wy znacza początek odrębnego przebiegu czynności, wykonywanego niezależnie od pozostałych, równoległych przebiegów. Ponieważ wszystkie te czynności realiźują jakąś część wspólnego zadania, więc na ogól przychodzi taki ■rjioment, w którym należy ze brać ich wyniki przed wykonaniem następnych czynności. Miejsce schodzenia się (scalenia) kilku równoległych przebiegów czynności zaznfucza gruba kreska, do której dochodzi kilka strzałek. Miejsce to działa jak bramka, przdz którą można przejść i pójść dalej tylko wtedy, gdy do bramki dojdą wszystkie równolegle przebiegi czynności. Działania nadzwyczajne, powodujące przerwanie normalnego biegu procesu, za czynają się po otrzymaniu zewnętrznego sygnału, którego źródła leżą poza realizowa nym procesem. W naszym przykładzie takim sygnałem może być np. skasowanie zamówienia przez klienta, któremu zabrakło pieniędzy. Wycofanie zamówienia po woduje przerwanie normalnych działań i zaprzestanie jego obsługi. Symbolem
Wysianie faktury
\
Dokonanie płatności
Faktura
1 — {>
Przyjęcie płatności
/
Rysunek 4.13. Rozwinięty model procesu sprzedaży
Kolejnym elementem diagramu może być pokazanie nie tylko czynności, ale tak że obiektów, których te czynności dotyczą. Takim obiektem jest na rys. 4.13 faktura, wysyłana do klienta przed zrealizowaniem przez niego płatności. Strzałki łączące czynności z obiektem modelują przepływy danych. Oprócz obiektów przekazywanych bezpośrednio między czynnościami w modelu można pokazać zbiory (magazyny) obiektów, przechowywanych w sposób trwały, niezależnie od bieżących działań. Warto tym miejscu zauważyć, że diagramy czynności wyposażone w możliwości modelowania przebiegów równoległych i przepływów danych mają podobną silę wyrazu jak diagramy przepływu danych, wykorzystywane w metodach strukturalnych i opisane w rozdziale 3. Wykonanie złożonego procesu może angażować różne podmioty, odpowiadające za wykonanie różnych czynności. Na przykład, sprzedaż towaru w przedsiębiorstwie handlowym wymaga współpracy działu sprzedaży, który przygotowuje wysyłkę towaru, działu księgowości, który wystawia fakturę, oraz klienta, który musi dokonać płatności. Podmioty odpowiadające za wykonanie poszczególnych czynności można wskazać, dzieląc rysunek na odrębne obszary - tory (swimlcine) lub boksy - przypi sane do tych podmiotów i rozmieszczając czynności w granicach odpowiednich ob szarów (rys. 4.14). W yróżnienie podmiotów zaangażowanych w wykonanie procesu może istotnie wzbogacić model i dopomóc w identyfikacji jego głównych aktorów.
4. M etody obiektow e
144 Dział sprzedaży ^
Przyjęcie % zamówienia
Dział księgowości
[ Odrzucone ]
> -> OK 1
Wycena zamówienia
->
Przygotowanie towaru
Wysianie przesyłki
H f Przyjęcie płatności
Wysianie faktury
\
Klient
Zamknięcie zamówienia
l Faktura
fi 2. M odelow anie procesów biznesow ych
mogą korygować pierwotne wyobrażenia i wzbogacać model w dodatkowe szczegóły jego działania. Należy jednak pamiętać, że model bardziej szczegółowy nie musi być lepszy - celem modelowania jest uchwycenie obrazu całości i abstrahowanie od nieistotnych szczegółów. Znalezienie właściwego poziomu abstrakcji jest problemem twórczym. Pierwszym krokiem analizy jest identyfikacja głównych procesów, decydujących o pozycji i sukcesie przedsiębiorstwa. W przykładowej bibliotece uniwersyteckiej takimi procesami są niewątpliwie procesy wypożyczania i zwracania książek przez czytelników. Początkowy model procesu wypożyczania, pokazujący przede wszyst kim te elementy, które zostały podane w specyfikacji wymagań, jest przedstawiony na rys. 4.15.
Dokonanie płatności
R ysunek 4.14. Model procesu sprzedaży ze wskazaniem podmiotów odpowiadających za wykonanie czynności
Modelowanie procesów biznesowych nie jest jedynym zastosowaniem diagramu czynności. Model można wykorzystać wszędzie tam, gdzie zachodzi potrzeba przed stawienia kolejności wykonania działań, np. podczas specyfikowania scenariuszy przypadków użycia lub algorytmów złożonych metod. Zaletą modelu graficznego w łych zastosowaniach jest możliwość zwartego przedstawienia kilku alternatywnych wariantów postępowania na jednym diagramie. Niesekwencyjne rozszerzenia diagra mu i przerwania umożliwiają modelowanie nawet zaawansowanych mechanizmów programowania obiektowego, takich jak wyjątki. Złożone diagramy czynności można przedstawiać - w każdym zastosowaniu w postaci hierarchicznej, w której pojedyncza czynność diagramu wysokiego poziomu jest rozwijana na sekwencję czynności pokazywanych na odrębnym diagramie niższe go poziomu.
4 .2 .2 . B ud ow a m odelu Podstawowym problemem modelowania procesów biznesowych jest pozyskanie i uporządkowanie wiedzy na temat dziedziny zastosowania, obowiązujących w niej reguł oraz celów i oczekiwań działających w tej dziedzinie użytkowników oprogra mowania. Sposoby pozyskiwania wiedzy obejmują analizę dostępnych dokumentów oraz obserwację pracy w przedsiębiorstwie i rozmowy z użytkownikami i sponsorami projektu (por. podrozdział 2.3). Proces budowy modelu ma charakter iteracyjny - model jest rozwijany stop niowo i udoskonalany w miarę postępów analizy i wzrostu wiedzy o rozważanym problemie. Kolejne wywiady z użytkownikami oraz obserwacja przedsiębiorstwa
145
Czytelnik
Li
Przejrzenie katalogu
>
Sprawdzenie dostępności
Bibliotekarz
, o>
Rezerwacja książki
Niedostępna ]
Identyfikacja czytelnika
Utworzenie rewersu Wydanie książki
A
Zapisanie w kolejce
Rysunek 4.15. W stępny model procesu w ypożyczania książki w bibliotece
Zbudowany w ten sposób diagram nie wnosi zbyt: wiele do naszej wiedzy na le mat wypożyczania książek, pozwala jednak ogarnąć len proces jednym spojrzeniem. Istotnym elementem modelu jest leż wyraźne wskazanie zakresów odpowiedzialności dwóch różnych podmiotów biorących udział w realizacji wypożyczenia. Diagram można pokazać użytkownikom, uzgadniając w ten sposób wspólny język komunikacji i wspólne rozumienie problemu. Uwagi użytkowników mogą dopomóc w odkryciu niedostatków i nadmiernych uproszczeń modelu. Przykładem takich uproszczeń jest pominięcie kluczowych zbiorów danych, nie zbędnych do prawidłowego funkcjonowania organizacji, oraz pewnych dodatkowych warunków, jakie muszą być spełnione przed wykonaniem niektórych działań. Wa runki te mogą mieć charakter zewnętrzny w stosunku do modelu, przykładem może być tu potrzeba osobistej obecności czytelnika podczas wypożyczania książki, lub czasowy, np. konieczność automatycznego kasowania rezerwacji książki nieodebranej przez czytelnika w rozsądnym czasie. Tego typu uzależnienia modeluje się na diagra mie czynności, korzystając z symboli miejsc schodzenia się czynności równoległych tych, które należą do głównego nurtu procesu, i tych, które zależą od czasu lub oko liczności zewnętrznych.
146
4. M etody obiektow e
Uzupełnienie modelu może prowadzić do powstania kolejnej wersji, pokazującej najważniejsze zbiory danych oraz niewidoczne dotychczas uzależnienia (rys. 4.16) Magazyny danych są wyróżnione stereotypem «clatastore». Uzależnienie od czasu symbolizuje ikona klepsydry. Warunek obecności czytelnika podczas wypożyczania jest przedstawiony za pomocą sygnału Czytelnik obecny. Niezwrócenie książki w terminie powoduje wytworzenie sygnału Brak zwrotu, który może zainicjować inny proces odzyskiwania niezwróconych książek. Ikona kartki z zagiętym rogiem (nazywana czasem notatką) symbolizuje komentarz, który można dołączyć do dowol nego elementu diagramu, a który tu wskazuje na konieczność wybrania właściwej rezerwacji zgłaszającego się czytelnika. Dalsza część diagramu, opisująca sposób obsługi sytuacji braku dostępnej książki, jest przeniesiona na inny rysunek.
a2
Modelowanie procesów biznesowych ■
-
147 ■
■
W s tę p n y m o d e l d z ie d z in y
Procesy biznesowe, które ma wspierać tworzone oprogramowanie, toczą się w pewnej dziedzinie życia i wpływają na jej stan w sposób, który ma przynieść korzyści ich uczestnikom. Osiągnięcie tego celu wymaga zrozumienia potrzeb i oczekiwań użyt kowników oraz poznania dziedziny zastosowania, w której oni działają. Sposobem poznawania dziedziny jest identyfikacja i klasyfikacja obiektów, które w niej wystę pują, oraz określenie danych opisujących różne klasy obiektów'. W ykonanie tych działań nie zawsze jest proste i może wymagać dyskusji z użytkownikami, analizy dokumentów krążących w przedsiębiorstwie lub analizy innych modeli, np. diagra mów' czynności lub scenariuszy przypadków użycia. Na przykład, wydaje się, że ważnym pojęciem występującym w systemie biblio tecznym jest książka. Nie jest to jednak - w tej dziedzinie zastosowania - termin jednoznaczny. Jeżeli biblioteka posiada kilka woluminów książki Quo vadis, to trzeba odróżnić pozycję książkową, opisaną przez numer ISBN, tytuł, nazwisko autora i rok wydania, od konkretnego woluminu pozycji książkowej, opisanego przez numer inwentarzowy. Co więcej, jeżeli biblioteka uniwersytecka przechowuje i wypożycza także rozprawy doktorskie, opracowane na uczelni i niewydane drukiem, to nie można ich nazwać książkami, bo nie mają swojego numeru ISBN. Najprostszym modelem dziedziny jest słownik, wyliczający i wyjaśniający poję cia używane do opisania stanu dziedziny, przebiegu procesów biznesowych i wyma gań stawianych przez użytkowników. Jednym z najważniejszych zadań tego modelu na początkowym etapie analizy jest dostarczenie jednolitego słownictwa i zapewnie nie jednolitego rozumienia najważniejszych pojęć. Przykładowy słownik pojęć syste mu bibliotecznego jest pokazany w tab. 4.2. Tabela 4.2. Przykładowy słownik systemu bibliotecznego
Dobrze opracowany model procesów biznesowych ułatwia przejście do modelo wania innych aspektów budowanego systemu. Wyodrębnienie podmiotów odpowia dających za realizację działań stwarza dobrą podstawę do identyfikacji aktorów w modelu przypadków użycia. Wyodrębnienie kluczowych obiektów używanych pod czas realizacji procesów ułatwia identyfikację klas występujących w dziedzinie zasto sowania. Istotną zaletą modelu jest intuicyjność i zrozumiałość, która ułatwia komuni kację ludzi pochodzących z różnych środowisk, o różnym rodzaju i poziomie wy kształcenia. Jest to szczególne ważne na początku p|ocesu wytwórczego, kiedy zapadają strategiczne decyzje wymagające ścisłej współpracy informatyków i eksper tów w dziedzinie zastosowania. Z drugiej strony model procesów biznesowych nie definiuje wymagań wystar czająco dokładnie, aby umożliwić ocenę kosztu i czasu wykonania systemu. Dlatego modelowanie procesów biznesowych jest krokiem opcjonalnym, wykorzystywanym często nieformalnie do poglądowego opisania problemu podczas analizy strategicznej.
D e fin ic ja
K la s a Pozycja (k sią żk o w a )
P o z y c ja k sią ż k o w a o k re ślo n a p rz e z n u m e r, ty tu ł, a u to ró w , w y d a w c ę i rok w y d a n ia (ta k ż e IS B N )
W olum in
K a żd y k o n k re tn y e g z e m p la rz d o w o ln e j p o z y cji w y d a w n ic z e j
K atalog
P e łn y k a ta lo g w sz y stk ic h p o z y cji i w sz y stk ic h w o lu m in ó w p rz e c h o w y w a n y c h w b ib lio te c e
C zytelnik
Z a re je s tro w a n y u ż y tk o w n ik b ib lio te k i
R ew ers
Z a p is faktu w y p o ż y c z e n ia w o lu m in u p rz e z c z y te ln ik a
Pokazany słownik nie jest kompletny i nie zawiera wszystkich pojęć, które wy stąpią w projekcie systemu. Pełny model nie powstaje jednak od razu, ale jest rozwi
148
4. M etody obiektow e
jany stopniowo i udoskonalany w miarę postępów analizy i odkrywania nowych obiektów i ich relacji. Początkowy model dziedziny pokazuje tylko najważniejsze klasy obiektów, których obecność jest niezbędna dla zrozumienia sposobu działania systemu i które w największym stopniu wpływają na wolumen danych gromadzonych i przetwarzanych przez oprogramowanie. W bardziej złożonych przypadkach, w których stan dziedziny istotnie zależy od zmieniających się relacji między obiektami, lepszym narzędziem modelowania jest diagram klas (podrozdział 4.1), postrzegany w tej fazie projektu w perspektywie pojęciowej. Budowę modelu ułatwia prosta i sprawdzona w analizie strukturalnej reguła, zgodnie z którą występujące w opisach rzeczowniki są kandydatami na nazwy klas obiektów, a odnoszące się do nich frazy czasownikowe są kandydatami na nazwy relacji obiektów. Na przykład, wynikiem zapisania się czytelnika do kolejki oczekują cych na wybraną pozycję książkową jest powstanie relacji,oczekiwanie zachodzącej między obiektami Czytelnik i Pozycja. Podobne, choć nie takie same, relacje powstają i zanikają podczas rezerwowania, wypożyczania i zwracania książek. Wstępny diagram klas obiektów występujących w bibliotece uniwersyteckiej jest pokazany na rys. 4.17.
a 2 M o d e lo w a n ie p r o c e s ó w b iz n e s o w y c h 149 3 U — — -----------------------------------------------------------------------------------------------------
i łatwiejszym do wytłumaczenia niż brak rewersu w centralnym miejscu modelu bi blioteki. Uzupełnieniem modelu dziedziny są oszacowania ilościowe, które pośrednio określają wymaganą wydajność budowanego systemu. Przykładowe oszacowania liczby czytelników, książek i operacji są pokazane w lub. 4.3. Tabela 4.3. Oszacowania ilościowe dla systemu bibliotecznego P a ra m e tr
L p.
'
W a r to ś ć 2 5 0 0 00
1
L iczba p o zy cji w k a ta lo g u b ib lio te k i
2
Ł ą c z n a lic z b a w o lu m in ó w w b ib lio te c e
3
L iczba c z y te ln ik ó w
30 0 0 0
4
L icz b a je d n o c z e s n y c h w y p o ż y c z e ń (re w e rsó w )
60 000
5
L icz b a je d n o c z e s n y c h re z erw ac ji
10 0 00
6
L icz b a je d n o c z e s n y c h sesji z d a ln e g o d o s tę p u c z y te ln ik ó w
1 000 000
100
W stęp n y m o d e l w y m a g a ń
Oczekiwanie
Rysunek 4.17. Wstępny inodel klas systemu bibliotecznego Spostrzegawczy czytelnik zauważy, że w przykładzie na rys. 4.5 rewers został przedstawiony jako klasa asocjacyjna. Dlaczego więc w tym modelu jest zwykłą klasą? Oba sposoby zapisania modelu są poprawne. Z punktu widzenia logiki dia gramu klas Rewers jest niewątpliwie klasą asocjacyjną, gdyż każdy obiekt tej klasy opisuje dokładnie jedno wystąpienie relacji wypożyczaniu. Jednocześnie jednak rewers jest dobrze znanym i bardzo ważnym obiektem dziedziny zastosowania. Każdy bibliotekarz wie, że skojarzenie książki z wypożyczającymi ją czytelnikiem następuje piv.cz utworzenie rewersu. Wystąpienia tego mechanizmu oczekuje też w modelu. Ponieważ jednym z głównych zadań pojęciowego diagramu klas jest zapewnienie porozumienia z ekspertem w dziedzinie zastosowania, zatem lepszym rozwiązaniem wydaje się stworzenie prostego modelu zgodnego z przyzwyczajeniami i oczekiwa niami eksperta, aniżeli modelu formalnie lepszego, ale bardziej złożonego i wymaga jącego dodatkowych wyjaśnień. Zapis rezerwacji książki jest czymś mniej typowym
Procesy biznesowe, przebiegające w organizacji, są zwykle skomplikowane, a ich wykonanie angażuje wielu użytkowników, którzy oczekują wsparcia systemu podczas wykonywania swoich zadań. Naturalnym sposobem opisania tych oczekiwań jest wyodrębnienie czynności wykonywanych przez poszczególnych użytkowników i tekstowe zapisanie ich w postaci scenariuszy określających kolejność wykonywania działań. Zbudowany w ten sposób model przypadków użycia ogranicza się zwykle do wskazania głównych aktorów i najważniejszych zadań, definiowanych przez scenariu sze sukcesu. Dla każdego przypadku użycia można określić związane z nim wymaga nia niefunkcjonalne, dotyczące np. liczby użytkowników występujących w roli aktora, szacunkowej częstości wykonania zadań, liczby przetwarzanych dokumentów lub oczekiwanego czasu wykonania zadania. Budując model wymagań dla systemu bibliotecznego, możemy skorzystać z pro stego modelu procesów biznesowych pokazanego na rys. 4.15, na którym wyodręb niono dwóch głównych aktorów: Czytelnik i Bibliotekarz. Działania czytelnika obej mują rezerwację woluminu potrzebnej pozycji, jeżeli jest w danej chwili dostępny w bibliotece, lub rejestrację oczekiwania na zwrot jakiegoś woluminu, jeśli wszystkie są wypożyczone. Zadania bibliotekarza obejmują rejestrację faktów wypożyczenia i zwrotu. Scenariusze wymienionych przypadków użycia można zapisać następująco.
4 . M e to d y o b ie k to w e
P U 1. R e z e rw a c ja 1. Czytelnik przegląda katalog biblioteki i wskazuje wybraną pozycję. 2. System sprawdza dostępność. 3. Czytelnik rezerwuje egzemplarz pozycji lub zapisuje się do kolejki oczekiwania. P U 2. W y p o ż y c z e n ie w o lu m in u 1. 2. 3. 4.
System identyfikuje czytelnika. System identyfikuje wypożyczany wolumin. System zapisuje rewers wypożyczenia. Bibliotekarz wydaje wolumin czytelnikowi.
P U 3. Z w ró c e n ie w o lu m in u 1. System identyfikuje zwracany wolumin. 2. System odnajduje i usuwa rewers wypożyczenia. 3. System rezerwuje zwrócony wolumin dla oczekującego czytelnika.
Graficzna postać diagramu przypadków użycia (rys. 411,8) nie wnosi do modelu dużej wartości dodanej. Jedynym pożytkiem z diagramu jest wytyczenie granicy i zakresu systemu przez pokazanie, że inne kategorie pracowników i inne procesy przebiegające w bibliotece, takie jak np. zakupy nowych książek lub wycofanie uszkodzonych książek do naprawy, nie będą przez system wspierane. Diagram przy padków użycia pełni tu więc rolę analogiczną do roli schematu kontekstu opisanego w podrozdziale 3.2. Różnica między obydwoma modelami polega na tym, że schemat kontekstu pokazuje przepływy danych między systemem a jego otoczeniem, pomijając sposób realizacji tych przepływów, podczas gdy scenariusze przypadków użycia kon centrują się na opisaniu mechanizmu dialogu systemu z zewnętrznymi użytkownikami.
4 .3 .
M o d e lo w a n ie w y m a g a ń u ż y tk o w n ik a
Podstawowym narzędziem opisu wymagań użytkowników jest model przypadków użycia. Budowa modelu zaczyna się zwykle od identyfikacji aktorów. Informacji, potrzebnych do wykonania tego kroku, może dostarczyć schemat struktury przedsię biorstwa, wskazujący istniejące stanowiska pracy i definiujący role pełnione przez
3 . M odelow anie w ym agań użytkow nika
j5 1
pracowników, oraz opis kontaktów przedsiębiorstwa ze światem zewnętrznym. W systemach wspierających złożone procesy biznesowe, np.w administracji publicz nej lub edukacji, bardzo pomocny może być model tych procesów, opisujący kolej ność działań i wskazujący podmioty realizujące poszczególne czynności każdego procesu. W przypadku oprogramowania tworzonego dla anonimowych odbiorców masowych, takiego jak np. gry komputerowe, źródłem informacji umożliwiających identyfikację aktorów będą wyniki pracy działu marketingu, definiujące krąg docelo wych użytkowników produktu. Znając aktorów, można posunąć prace naprzód, określając cele i zadania wyko nywane przy pomocy systemu przez każdego aktora. Wymaga to rozważenia: ■ * ■ ■
roli aktora, wykonywanych i inicjowanych przez niego funkcji i zadań; danych, jakie wprowadza do systemu; potrzeb informacyjnych aktora, tzn. danych przekazywanych mu przez system; potrzeb utrzymania systemu, jego rozruchu, zatrzymania i konserwacji.
Każde zadanie prowadzące do jakiegoś celu - każdy sposób używania systemu przez aktora - jest, a przynajmniej może być, przypadkiem użycia. Po zidentyfikowa niu aktorów i ich zadań pierwszym krokiem w rozwoju modelu jest zwykle opracowa nie scenariuszy sukcesu, pokazujących dla każdego przypadku sposób postępowania prowadzący do realizacji celu. Wybór aktorów i przypadków użycia wchodzących w skład modelu jest poważną decyzją projektową, której wynikiem jest określenie zakresu przyszłego systemu. Biblioteka, pokazana na rys. 4.18, zatrudnia również innych pracowników i realizuje inne zadania - ma np. księgową, który prowadzi finanse i pilnuje budżetu placówki, ma dyrekcję oraz osoby odpowiadające za poszukiwania i zakupy nowych książek. Jednak ani te osoby, ani realizowane przez nie zadania nie są włączone w skład mo delu. Konsekwencją tej decyzji będzie ograniczenie funkcji systemu bibliotecznego do wspierania zadań związanych z udostępnianiem zbiorów i pozostawienie innych działań bez jakiegokolwiek wsparcia ze strony budowanego systemu. Następnym krokiem prac jest pełne rozwinięcie modelu i znalezienie oraz opisa nie wszystkich możliwych scenariuszy alternatywnych. Punktem wyjścia są scenariu sze sukcesu, które stają się scenariuszami głównymi i których analiza prowadzi do odkrycia miejsc, w których wykonanie scenariusza głównego może się załamać na skutek różnych okoliczności, wymuszających zmianę sposobu postępowania. Dla każdej takiej sytuacji powstaje odrębny scenariusz alternatywny. Szczegółowe definiowanie wszystkich scenariuszy alternatywnych może się wy dać nadmiarowe, jednak alternatywą jest pozostawienie nie w pełni zdefiniowanego zachowania, które w przyszłości zostanie „jakoś” zaimplementowane przez programi stów. Jeśli ta „jakaś” implementacja nie zostanie zaakceptowana podczas testowania akceptacyjnego, to rezultatem będzie konieczność dokonania niezwykle kosztownych
152
4. M e to d y o b iek to w e
poprawek gotowego produktu. Dlatego znacznie bezpieczniejszą strategią prowadze nia projektu jest dokładne zdefiniowanie wszystkich zachowań systemu i zatwierdze nie pełnego modelu wymagań przed przystąpieniem do konstrukcji oprogramowania. M odelowanie wymagań w postaci przypadków użycia jest procesem podejmo wania decyzji i dokumentowania rezultatów podejmowanych decyzji, które określają zakres i sposób działania budowanego systemu i jego oprogramowania. Najważniejsze decyzje są na ogół wynikiem osiągnięcia kompromisu co do potrzeb biznesowych i możliwości technicznych. Jakość tych decyzji zależy od przygotowania podejmują cych je ludzi. Dlatego istotnym czynnikiem sukcesu jest stworzenie pola do rozgrani czenia zakresu decyzji biznesowych od zakresu decyzji technicznych. Spełnienie tego warunku ułatwia rozdzielenie modelu przypadków użycia na dwa poziomy. Pierwszy poziom tworzą biznesowe p rzy p ad k i użycia {business use cases), mo delujące procedury realizowane w przedsiębiorstwie w odpowiedzi na żądania klien tów. Aktorami inicjującymi biznesowe przypadki użycia są często zewnętrzni klienci firmy, którzy - poza wydzielonymi portalami internetowymi - nie mają na ogól do stępu do systemów informatycznych przedsiębiorstwa. Zbudowanie takiego modelu umożliwia przedstawienie całości przetwarzania i ułatwia wyodrębnienie tych działań, które'ffcyuff^wspierane przez budowany system informatyczny. Biznesowy model przypadków użycia powstaje w ścisłej współpracy z użytkownikiem, który jest naj bardziej kompetentny w tym obszarze do podejmowania decyzji. Drugi poziom modelu tworzą system owe przy p ad k i użycia (system use cases), modelujące sposoby wykorzystania systemu informatycznego przez bezpośrednich użytkowników. Na tym poziomie modelowania aktorami inicjującymi przypadki użycia są osoby wykorzystujące system do wykonania swojej pracy, która często polega na załatwianiu spraw zgłaszanych przez aktorów biznesowych. Systemowe przypadki użycia tworzą model wymagań funkcjonalnych, precyzyjnie opisujący to, co oprogramowanie ma robić, bez przedwczesnego decydowania o tym, jak należy to oprogramowanie zbudować. W małych projektach programistycznych nie ma często potrzeby rozdzielania poziomów i model przypadków użycia może pokazywać tylko bezpośrednich użyt kowników systemu i ich systemowe przypadki użycia. W wielkich projektach syste mów informatycznych przeznaczonych dla przedsiębiorstw administracji publicznej lub dużych organizacji gospodarczych złożoność problemu zmusza do rozdzielenia poziomów abstrakcji, W takim przypadku budowa modelu jest prowadzona iteracyjnie, przy czym wynikiem pierwszego kroku jest model biznesowych przypadków użycia, a wynikiem drugiego - model systemowych przypadków użycia. Wyniki obydwu kroków są przedstawiane użytkownikom w celu uzgodnienia sposobu rozu mienia problemu i uzyskania aprobaty dla proponowanych rozwiązań.
4 ą M odelow anie w ym agali użytkow nika
153
4 3 . 1 . B ud ow a m o d elu b izn es o w eg o Powróćmy do systemu wspierającego działanie biblioteki uniwersyteckiej. Dogodnym punktem wyjścia do stworzenia modelu wymagań jest opis procesów biznesowych (podrozdział 4.2) zbudowany podczas analizy strategicznej. Podstawowe elementy modelu procesów biznesowych, tzn. aktorzy oraz sekwencja działań podejmowanych podczas wykonania typowych zadań, zostaną przeniesione do nowego modelu bez większych zmian. Dodatkowymi elementami będą brakujące szczegóły i alternatywne scenariusze wykonania działań oraz opisy mniej typowych zadań pominiętych w pierwszym modelu. ' Szczegółowe zdefiniowanie scenariuszy procedur biznesowych (PB) wymaga podjęcia szeregu decyzji dotyczących zachowania systemu w różnych .sytuacjach. W systemie bibliotecznym decyzje te będą dotyczyć np.: 1
■ zezwolenia na przeglądanie katalogów biblioteki - czy mogą lo robić dowolne osoby, czy tylko zarejestrowani czytelnicy; ■ zakresu zdalnego dostępu do biblioteki - jak dużo książek można zarezerwo wać, czy można odwołać rezerwację, czy można zrezygnować z oczekiwania na książkę; ■ sposobu postępowania w razie przekroczenia terminu zwrotu książki - czy przekraczający termin są jakoś karani, czy ¡racą prawo dalszych wypożyczeń itd.
Wszelkie wątpliwości, pojawiające się podczas podejmowania tych decyzji, mu szą być rozstrzygnięte przez zleceniodawcę lub upoważnionych przez niego ekspertów w dziedzinie zastosowania. Natomiast jednoznaczne zapisanie rezultatów decyzji w modelu oraz kontrola spójności przyjętych rozwiązań należą do obowiązków anali tyka. Biznesowy model biblioteki może wyglądać następująco. PB1. R ezerw acja A ktorzy: c z y te ln ik . S ce n a riu s z g łó w n y :
1. 2. 3. 4.
Czytelnik przegląda katalog biblioteki i wskazuje wybraną pozycję. System sprawdza dostępność. System sprawdza tożsamość czytelnika. System zapisuje rezerwację i potwierdza wykonanie operacji.
S ce n a riu s z a lte rn a ty w n y I - b ra k w o ln e j k s ią ż k i:
1-2. Jak w scenariuszu głównym. 3. Czytelnik wybiera opcję oczekiwania. 4. System sprawdza tożsamość czytelnika. 5. System zapisuje oczekiwanie i potwierdza wykonanie operacji. S c e n a riu s z a lte rn a ty w n y 2 - p rz e k ro c z o n y lim it w y p o ż y c z e ń :
1-3. Jak w scenariuszu głównym. 4. System powiadamia o przekroczeniu limitu wypożyczeó.
154
4. M etody obiektow e
P B 2. W y p o ż y c z e n ie w o lu m in u
4.3. M odelow anie w ym agań użytkow nika
155
4.3.2. B ud ow a m odelu sy ste m o w eg o
A k to rz y : c z y te ln ik , b ib lio te k a rz . S c e n a riu s z g łó w n y : 1. 2.
3. 4. 5.
B ib lio te k a rz id e n ty fik u je c z y te ln ik a w s y s te m ie . S y s te m s p ra w d z a s ta n k o n ta c z y te ln ik a . B ib lio te k a rz id e n ty fik u je w y p o ż y c z a n y w o lu m in w s y s te m ie . S y s te m z a p is u je re w e rs w y p o ż y c z e n ia i p o tw ie rd z a w y k o n a n ie o p e ra c ji. B ib lio te k a rz p rz e k a z u je w o lu m in c z y te ln ik o w i.
S c e n a riu s z a lte rn a ty w n y - n ie o p ła c o n a k a ra z a p rz e k ro c z o n y te rm in z w ro tu k s ią ż k i: 1-2. J a k w s c e n a r iu s z u g łó w n y m .
3. S y s te m p o w ia d a m ia o n ie o p ła c o n e j k a rz e i w y ś w ie tla je j w y s o k o ś ć . 4.
C z y te ln ik o p ła c a k a rę . W ra z ie o d m o w y o p ła c e n ia k a ry b ib lio te k a rz d e c y d u je a lb o o w y p o ż y c z e n iu - p o w r ó t d o k r o k u 3 s c e n a r iu s z a g łó w n e g o , a lb o o o d m o w ie - z a k o ń c z e n ie s c e n a riu s z a .
P B 3 . Z w ró c e n ie w o lu m in u A k to rz y : c z y te ln ik , b ib lio te k a rz . S c e n a riu s z g łó w n y : 1. 2.
3. 4. 5.
B ib lio te k a rz id e n ty fik u je z w ra c a n y w o lu m in w s y s te m ie . S y s te m z n a jd u je re w e rs w y p o ż y c z e n ia i s p ra w d z a te rm in z w ro tu . S y s te m s p ra w d z a k o le jk ę o c z e k iw a n ia i z n a jd u je o c z e k u ją c e g o c z y te ln ik a . S y s te m re z e rw u je z w r ó c o n y w o lu m in d la o c z e k u ją c e g o . S y s te m u s u w a re w e rs i p o tw ie rd z a z w ro t w o lu m in u .
S c e n a riu s z a lte rn a ty w n y - p rz e k ro c z o n y te rm in u z w ro tu : 1 -2 . J a k w s c e n a r iu s z u g łó w n y m .
3. S y s te m n a lic z a k a rę i w y ś w ie tla je j w y s o k o ś ć . 4. 5.
C z y te ln ik o p ła c a k a rę . J e ś li o d m a w ia o p ła c e n ia , s y s te m z a p a m ię tu je w y s o k o ś ć k a ry . P o w ró t d o k r o k u 3 s c e n a r iu s z a g łó w n e g o .
P B 4. P rz e g lą d a n ie ko n ta A k to rz y : c z y te ln ik .
Scenariusze biznesowych przypadków użycia są często złożone i obejmują szereg niezależnych operacji wymagających różnych działań użytkowników i systemu. Na przykład, procedura zwrócenia wypożyczonego woluminu obejmuje identyfikację woluminu na podstawie kodu kreskowego, zarezerwowanie go dla oczekującego czytelnika oraz opłacenie kary i wydrukowanie pokwitowania dla czytelnika. Każda z tych operacji określa niezależną funkcję systemu, która może mieć samodzielną wartość dla użytkownika i która musi być mu udostępniona poprzez jakiś interfejs komunikacyjny. Zatwierdzenie modelu biznesowego określa zakres i sposób działania systemu oraz otwiera drogę do zdefiniowania funkcji udostępnianych użytkownikom (FU). Decyzje podejmowane na tym poziomie analizy dotyczą przede wszystkim sposobu współpracy systemu z użytkownikami oraz sposobu wykonania poszczególnych funkcji. W systemie bibliotecznym decyzje te będą dotyczyć np.: określenia funkcji dostępnych dla różnych kategorii użytkowników (jak będzie zbudowane menu sys temu; które funkcje będą dostępne dla bibliotekarza, a które dla czytelnika), sposobu weryfikowania tożsamości i postępowania w razie niepowodzenia (identyfikowanie czytelnika na podstawie hasła, czy karty bibliotecznej; w razie błędnego hasła dopusz czenie kilku dalszych prób, czy zablokowanie konta), sposobu postępowania w sytu acjach nietypowych (czy można wypożyczyć książkę czytelnikowi bez ważnej karty bibliotecznej; czy można wypożyczyć książkę bez uprzedniej rezerwacji) itd. Część odpowiedzi na te pytania udzieli bezpośrednio zleceniodawca lub ekspert w dziedzinie zastosowania, pozostałe - będą wynikiem zatwierdzenia propozycji ana lityków przez zleceniodawcę. Systemowy model biblioteki, w którym zaznaczono odwołania do reguł biznesowych (RB) opisanych w następnym punkcie, może wyglą dać następująco.
S c e n a riu s z g łó w n y : 1. 2.
S y s te m s p ra w d z a to ż s a m o ś ć c z y te ln ik a . S y s te m w y ś w ie tla s ta n k o n ta c z y te ln ik a : lis tę w y p o ż y c z e ń ', lis tę re z e rw a c ji, lis tę o c z e k iw a ń i n a lic z o n ą k a rę . 3. C z y te ln ik u s u w a n ie p o trz e b n e re z e rw a c je i o c z e k iw a n ia . '
FU1. P rze g lą d a n ie ka talo g u W sp ie ra p r o c e d u r ę P B 1 - R e z e rw a c ja . F u n k c ja u o g ó ln ia ją c a d la F U 2 i F U 3 . A kto rzy : ka żd y. S c e n a riu s z g łó w n y :
Przeglądając scenariusze, łatwo odnaleźć ślady podjętych decyzji biznesowych. Katalog biblioteki mogą przeglądać dowolne osoby, ale rezerwować lub zapisywać się w oczekiwaniu na wybrane pozycje może tylko czytelnik o(znanej tożsamości. Liczba woluminów, jakie może wypożyczyć lub zarezerwować czytelnik, jest ograniczona. Przekroczenie terminu zwrotu pociąga za sobą karę finansową, ale decyzja o następ nym wypożyczeniu książki zadłużonemu czytelnikowi jest pozostawiona w gestii bibliotekarza. Zdalny dostęp do biblioteki obejmuje przeglądanie konta, w czasie którego czytelnik może odwołać rezerwację i zrezygnować z oczekiwania na wcze śniej wybraną pozycję.
1. 2. 3. 4. 5. 6.
C z y te ln ik w y b ie r a o p c ję p r z e g lą d a n ia k a ta lo g u . S y s te m p re z e n tu je e k ra n w y s z u k iw a n ia . C z y te ln ik w p ro w a d z a d a n e b ib lio g ra fic z n e s z u k a n e j p o z y c ji (R B 1 ). S y s te m p rz e s z u k u je k a ta lo g I w y ś w ie tla lis tę z n a le z io n y c h p o z y c ji. C z y te ln ik p rz e g lą d a lis tę i w y b ie r a p o z y c ję . S y s te m w y ś w ie tla in fo rm a c ję o k a te g o rii p o z y c ji (R B 2 ) I d o s tę p n o ś c i je j e g z e m p la rz y (R B 3).
FIJ2. R e je s tra c ja re z e rw a c ji W sp ie ra p r o c e d u r ę P B 1 - R e z e rw a c ja . F u n k c ja s p e c ja liz u ją c a F U 1 . K o rz y s ta z fu n k c ji FU 4. A k to rz y : c z y te ln ik .
156
4. M etody obiektow e
4^3. M odelow anie w ym agań użytkow nika
3 , S y s te m w y ś w ie tla s ta n k o n ta (R B 6 ). 4, C z y te ln ik o p c jo n a ln ie u s u w a re z e rw a c ję lu b o c z e k iw a n ie [ R o z s z e rz e n ie : w y b ó r o p e r a c ji ]. 5 , S y s te m p o tw ie rd z a w y k o n a n ie o p e ra c ji.
S c e n a riu s z g łó w n y : 1 -6 . J a k w fu n k c ji u o g ó ln ia ją c e j F U 1 . 7. C z y te ln ik w y b ie r a o p c ję re z e rw a c ji. 8. S y s te m s p ra w d z a lim it w y p o ż y c z e ń c z y te ln ik a . 9 . S y s te m re je s tru je re z e rw a c ję i w y ś w ie tla k o m u n ik a t p o tw ie rd z a ją c y . S c e n a riu s z a lte rn a ty w n y 1 - c z y te ln ik n ie je s t z a ło g o w a n y : 1-7 . J a k w s c e n a r iu s z u g łó w n y m . 8. L o g o w a n ie z a p o m o c ą fu n k c ji F U 4 . 9. P o w ró t d o k r o k u 8 s c e n a r iu s z a g łó w n e g o .
PU6. Usunięcie rezerwacji W spiera p r o c e d u r ę P B 4 - P rz e g lą d a n ie k o n ta . R o z s z e rz a fu n k c ję F U 5 w p u n k c ie : w y b ó r o p e ra c ji. F u n kcja w y k o n y w a n a te ż a u to m a ty c z n ie d la r e z e r w a c ji s ta rs z y c h n iż 2 d n i.
Aktorzy: czytelnik, czas. S ce n a riu s z g łó w n y :
1 . S y s te m u s u w a re z e rw a c ję . 2. J e ś li is tn ie je k o le jk a o c z e k u ją c y c h n a tę p o z y c ję , to s y s te m re je s tru je re z e rw a c ję d la p ie rw s z e g o o c z e k u ją c e g o c z y te ln ik a i w y s y ła d o n ie g o e -m a il p o w ia d a m ia ją c y .
S c e n a riu s z a lte rn a ty w n y 2 - p rz e k ro c z o n y lim it w y p o ż y c z e ń : 1 -8 . J a k w s c e n a r iu s z u g łó w n y m . 9 . S y s te m p o w ia d a m ia o p rz e k ro c z e n iu lim itu w y p o ż y c z e ń .
t PU7. Usunięcie oczekiwania
S c e n a riu s z a lte rn a ty w n y 3 - b ra k m o ż liw o ś c i re z e r w a c ji: 1-8. J a k w s c e n a r iu s z u g łó w n y m . 9. S y s te m o d r z u c a re z e rw a c ję i p o w ia d a m ia c z y te ln ik a o o d rz u c e n iu (R B 4 ).
F U 3. R e je s tra c ja o c ze k iw a n ia
S c e n a riu s z g łó w n y :
S c e n a riu s z a lte rn a ty w n y - c z y te ln ik n ie je s t z a ło g o w a n y :
FU 4. L o g o w a n ie c z y te ln ik a W s p ie ra p r o c e d u r ę P B 1 - R e z e rw a c ja o ra z p r o c e d u r ę P B 4 - P rz e g lą d a n ie k o n ta . A k to rz y : c z y te ln ik .
S y s te m u s u w a c z y te ln ik a z k o le jk i o c z e k u ją c y c h . wypożyczenia
c e j FU 11. A ktorzy: b ib lio te k a rz .
Scenariusz g łó w n y : B ib lio te k a rz w y b ie r a o p c ję w y p o ż y c z e n ia . B ib lio te k a rz w p ro w a d z a k o d k r e s k o w y k a rty b ib lio te c z n e j c z y te ln ik a z a p o m o c ą fu n k c ji FU9. 3. S y s te m s p ra w d z a s a ld o o p ła t k a rn y c h c z y te ln ik a . 4 . S y s te m z n a jd u je re z e rw a c ję i w y ś w ie tla o p is z a re z e rw o w a n e j p o z y c ji. 5. B ib lio te k a rz w p ro w a d z a k o d k r e s k o w y w y p o ż y c z a n e g o w o lu m in u z a p o m o c ą fu n k c ji FU 9 . 6. S y s te m o b lic z a te rm in z w ro tu (R B 7 ). 7. S y s te m tw o rz y re w e rs w y p o ż y c z e n ia i z a p is u je g o w b a z ie d a n y c h . S ce n a riu s z a lte rn a ty w n y 1 - n ie w a ż n a k a rta b ib lio te c z n a :
S c e n a riu s z g łó w n y :
1 -2 . J a k w s c e n a r iu s z u g łó w n y m . 3. S y s te m w y ś w ie tla in fo rm a c ję o b ra k u w a ż n o ś c i k a rty b ib lio te c z n e j.
S y s te m w y ś w ie tla o k n o lo g o w a n ia . C z y te ln ik w p ro w a d z a n a z w ę i h a s ło (R B 5 ). S y s te m s p ra w d z a h a s ło c z y te ln ik a . S y s te m z a m y k a o k n o lo g o w a n ia
S c e n a riu s z a lte rn a ty w n y 2 - n ie o p ła c o n a k a ra za p rz e k ro c z o n y te rm in z w ro tu : | 4
|
.
W s p ie ra p r o c e d u r ę P B 4 - P rz e g lą d a n ie k o n ta . K o iz y s ta z fu n k c ji F U 4 o ra z z fu n k c ji ro z s z e rz a ją c y c h F U 6 i F U 7. A k to rz y : c z y te ln ik . S c e n a riu s z g łó w n y : 1. 2.
1.
1. 2.
1-7 . J a k w s c e n a r iu s z u g łó w n y m . 8. L o g o w a n ie z a p o m o c ą fu n k c ji F U 4 . 9. P o w ró t d o k r o k u 8 s c e n a r iu s z a g łó w n e g o .
F U 5. P rz e g lą d a n ie ko n ta
'
W spiera p r o c e d u r ę P B 2 - W y p o ż y c z e n ie w o lu m in u . K o rz y s ta z fu n k c ji F U 9 o ra z z fu n k c ji ro z s z e rz a ją
1 -6 . J a k w fu n k c ji u o g ó ln ia ją c e j F U 1 . 7 . C z y te ln ik w y b ie r a o p c ję o c z e k iw a n ia . 8 . S y s te m z a p is u je c z y te ln ik a d o k o le jk i i p o tw ie rd z a w y k o n a n ie o p e ra c ji.
1-3 . J a k w s c e n a r iu s z u g łó w n y m . 4 . P o w ró t d o k r o k u 1 s c e n a riu s z a g łó w n e g o .
AMorzy: czyte ln ik
FU8. Rejestracja
A k to rz y : c z y te ln ik .
S c e n a riu s z a lte rn a ty w n y - b ra k z g o d n o ś c i h a s ta :
W spiera p ro c e d u r ę P B 4 - P rz e g lą d a n ie k o n ta . R o z s z e rz a fu n k c ję F U 5 w p u n k c ie : w y b ó r o p e ra c ji.
S cenariusz g łó w n y :
W s p ie ra p r o c e d u r ę P B 1 - R e z e rw a c ja . F u n k c ja s p e c ja liz u ją c a FU 1 . K o rz y s ta z fu n k c ji FU 4.
1. 2. 3. 4.
157
C z y te ln ik w y b ie r a o p c ję p r z e g lą d a n ia k o n ta . J e ś li c z y te ln ik n ie je s t z a ło g o w a n y , to lo g o w a n ie c z y te ln ik a z a p o m o c ą fu n k c ji F U 4 .
1-3. J a k w s c e n a r iu s z u g łó w n y m . 4. S y s te m p o w ia d a m ia o n ie o p ła c o n e j k a rz e i w y ś w ie tla je j w y s o k o ś ć . 5. B ib lio te k a rz o p c jo n a ln ie re je s tru je o p ła c e n ie k a ry [ R o z s z e rz e n ie : o p la ta ]. 6. P o o p ła c e n iu k a ry p o w ró t d o k r o k u 4 s c e n a r iu s z a g łó w n e g o . W ra z ie n ie o p ła c e n ia k a ry b ib lio te k a rz d e c y d u je a lb o o w y p o ż y c z e n iu - p o w r ó t d o k r o k u 4 s c e n a r iu s z a g łó w n e g o , a lb o o o d m o w ie - z a k o ń c z e n ie s c e n a riu s z a . S c e n a riu s z a lte rn a ty w n y 3 - b ra k re z e r w a c ji: 1-4. J a k w s c e n a r iu s z u g łó w n y m . S y s te m w y ś w ie tla in fo rm a c ję o b ra k u re z e rw a c ji.
5.
:~ T 4. M etody obiektowe
158 F U 9. O d c z y ta n ie ko d u k re s k o w e g o
W s p ie ra p r o c e d u r ę P B 2 - W y p o ż y c z e n ie w o lu m in u o ra z p r o c e d u r ę P B 3 - Z w ró c e n ie w o lu m in u . A k to rz y : b ib lio te k a rz . S c e n a riu s z g łó w n y : 1. 2.
S y s te m o d c z y tu je k o d z c z y tn ik a . S y s te m p o tw ie rd z a o d c z y ta n ie k o d u
S c e n a riu s z a lte rn a ty w n y - n ie p o w o d z e n ie o d c z y ta n ia k o d u : 1. 2. 3. 4.
4 3 Modelowanie wymagań użytkownika
/ r l —_
tożsamości czytelnika ogranicza się do sprawdzenia hasła podczas, i iwowania książki, ale wymaga przedstawienia karty bibliotecznej podczas w y p c/y c/ ima. Błęd ne hasło można poprawiać bez ograniczenia liczby prób, ale brak ważnej karty unie możliwia wypożyczenie. Nie można również wypożyczyć książki bez uprzedniego dokonania rezerwacji (zapewne będzie to można zrobić na miejscu, korzystając z terminala w bibliotece). Pożądanym uzupełnieniem dokumentacji modelu obejmującego dwa poziomy przypadków użycia są odniesienia wiążące systemowe przypadki użycia ze wspiera nymi przez nie przypadkami biznesowymi. W przykładowym modelu biblioteki takie odniesienia są podane w opisach wszystkich funkcji. Pożądane byłoby również spo r z ą d z e n ie tabeli pokazującej odwołania prowadzące w przeciwnym kierunku.
J a k w s c e n a r iu s z u g łó w n y m . S y s te m w y ś w ie tla o k n o rę c z n e g o w p ro w a d z a n ia k o d u . B ib lio te k a rz w p ro w a d z a k o d . P o w ró t d o k r o k u 2 s c e n a r iu s z a g łó w n e g o .
F U 1 0 . R e je s tra c ja zw ro tu W s p ie ra p r o c e d u r ę P B 3 - Z w ró c e n ie w o lu m in u . K o rz y s ta z fu n k c ji F U 9 o ra z z fu n k c ji ro z s z e rz a ją c e j F U 11. A k to rz y : b ib lio te k a rz . S c e n a riu s z g łó w n y :
Diagram systemowych przypadków użycia systemu bibliotecznego jest pokazany na rys. 4.19. Nawet w tak prostym i do tego mocno uproszczonym przypadku rysunek zajmuje niemal całą stronę. Bez szczegółowej dokumentacji scenariuszy wykonania sam diagram nie przedstawia większej wartości.
1. 2. 3. 4.
B ib lio te k a rz w y b ie r a o p c ję z w ra c a n ia . B ib lio te k a rz w p ro w a d z a k o d k r e s k o w y k s ią ż k i z a p o m o c ą fu n k c ji F U 9 . S y s te m z n a jd u je re w e rs i u s u w a g o z b a z y d a n y c h . S y s te m z n a jd u je c z y te ln ik a , s p ra w d z a te rm in z w ro tu i o b lic z a s a ld o o p ła t k a rn y c h . 5. J e ś li, is tn ie je k o le jk a o c z e k u ją c y c h n a tę p o z y c ję , to s y s te m re je s tru je re z e rw a c ję dla p ie rw s z e g o o c z e k u ją c e g o c z y te ln ik a i w y s y ła d o n ie g o e -m a il p o w ia d a m ia ją c y .
S c e n a riu s z a lte rn a ty w n y 1 - n ie z n a n a k s ią ż k a : 1 -3 . J a k w s c e n a r iu s z u g łó w n y m . 4 . S y s te m w y ś w ie tla k o m u n ik a t in fo rm u ją c y o n ie z n a n y m n u m e rz e k s ią ż k i. S c e n a riu s z a lte rn a ty w n y 2 - p rz e k ro c z o n y te rm in z w ro tu k s ią ż k i lu b n ie o p ła c o n a k a ra : 1-4 . J a k w s c e n a r iu s z u g łó w n y m .
5. S y s te m p o w ia d a m ia o p rz e k ro c z o n y m te rm in ie i w y ś w ie tla w y s o k o ś ć n a le ż n e j k a ry . 6. 7. 8.
B ib lio te k a rz o p c jo n a ln ie re je s tru je o p ła c e n ie k a ry [ R o z s z e rz e n ie : o p la ta ]. S y s te m re je s tru je s a ld o o p ła t n a k o n c ie c z y te ln ik a . P o w ró t d o k r o k u 5 s c e n a r iu s z a g łó w n e g o .
FU l 1. R e je s tra c ja o p ła ty W s p ie ra p r o c e d u r ę P B 2 - W y p o ż y c z e n ie w o lu m in u o ra z p r o c e d u r ę P B 3 - Z w ró c e n ie w o lu m in u . R o z s z e rz a fu n k c je F U 8 i F U 1 0 w p u n k c ie : o p la ta . ' A k to rz y : b ib lio te k a rz .
,
S c e n a riu s z g łó w n y :
\
1. 2. 3.
(5 9
-----------------------------------------------------------------------------------
S y s te m w y ś w ie tla w y s o k o ś ć o p ła ty k a rn e j. j B ib lio te k a rz p o tw ie rd z a z a p ła c e n ie k a ry . { S y s te m d ru k u je p o tw ie rd z e n ie w p ła ty .____________________ ;_______________________________ _
Scenariusze systemowych przypadków użycia definiują operacje udostępniane przez system różnym kategoriom użytkowników (aktorom) oraz sposoby inicjowania tych operacji przez użytkowników. Przeglądając treść scenariuszy, nietrudno odnaleźć odpowiedzi na wszystkie pytania postawione na wstępie tego punktu. Weryfikacja
Rysunek 4.19. D iagram system ow ych przypadków użycia system u bibliotecznego
160
4. M e to d y o b ie k to w e
4 .3 .3 . R e g u ły b izn e s o w e Scenariusze przypadków użycia przejrzyście przedstawiają kolejność wykonywanych działań, nie opisują natomiast algorytmu ich wykonania. Treść scenariuszy nie roz strzyga np. ile książek i na jak długo może pożyczyć czytelnik - czy wszyscy czytel nicy są równoprawni w tym względzie; od czego zależy wysokość kary za przekro czenie terminu. Odpowiedzi na te i podobne pytania są częścią wymagań - nie można ich pozostawić projektantom systemu. Dlatego elementem dokumentacji modelu przypadków użycia są również reguły biznesowe (business ndes) precyzujące sposób wykonania poszczególnych działań. W g u ly biznesowe powinny określać wszystkie algorytmy i ograniczenia działań znane na tym etapie analizy. Dla uniknięcia nieporozumień powinny być zapisane jawnie i bez ukrywania elementów jeszcze nieznanych lub nierozstrzygniętych. Znaczna część reguł biznesowych opisuje bieżącą politykę firmy, która jest najmniej stabilnym elementem wymagań. Wyodrębnienie takich reguł z treści scenariuszy przypadków użycia może wskazywać te elementy konstruowanej aplikacji, które najprędzej mogą stać się przedmiotem zmiany. Reguły biznesowe można zapisać osobno, w postaci numerowanej listy reguł, albo dołączyć do dokumentacji tych przypadków użycia, których dotyczą. Przykładowe reguły biznesowe systemu biblio tecznego mogą wyglądać następująco. R B1.
R B2.
R B3. R B4. R B5. R B6.
R B7.
D a n e b ib lio g ra fic z n e w y s z u k iw a n e j p o z y c ji o b e jm u ją : d o w o ln y fra g m e n t ty tu łu lu b n a zw i s k o a u to r a (w s p ó ła u to ra ) a lb o n u m e r IS B N . W y s z u k iw a n ie m o ż e b y ć o g ra n ic z o n e p rze z p o d a n ie ro k u (iu b z a k re s u la t) w y d a n ia . P o s ia d a n e p o z y c je w y d a w n ic z e s ą p o d z ie lo n e n a trz y k a te g o rie : p o d rę c z n ik i - w y p o ż y c z a n e n a s e m e s tr, o g ó ln e - w y p o ż y c z a n e n a m ie s ią c , o g ra n ic z o n e - w y p o ż y c z a n e p ra c o w n ik o m n a m ie s ią c , d o k to r a n to m n a ty d z ie ń i n ie w y p o ż y c z a n e s tu d e n to m . L is ta ka te g o rii m o ż e u le c z m ia n ie . W y ś w ie tla n a je s t lic z b a p o s ia d a n y c h w o lu m in ó w w y b ra n e j p o z y c ji w y d a w n ic z e j oraz lic z b a w o lu m in ó w d o s tę p n y c h lu b n a jb liż s z y te rm in z w ro tu . K o rz y s ta ją c z d o s tę p u in te rn e to w e g o , k ilk u c z y te ln ik ó w m o ż e je d n o c z e ś n ie p ró b o w a ć re z e rw a c ji je d y n e g o d o s tę p n e g o w o lu m in u . T y lk o je d n a z -ty c h re z e rw a c ji z o s ta n ie p rzyję ta . H a s ło c z y te ln ik a m u s i m ie ć c o n a jm n ie j 6 z n a k ó w i n ie m o ż e b y ć p o w tó rz e n ie m je g o n azw y. S ta n k o n ta c z y te ln ik a o b e jm u je : lic z b ę b ie ż ą c y c h w y p o ż y c z e ń ze w s k a z a n ie m w y p o ż y c z e ń z p r z e k ro c z o n y m te rm in e m z w ro tu , lis tę p o z y c ji z a re z e rw o w a n y c h z e w s k a z a n y m te rm in e m w a ż n o ś c i, lis tę p o z y c ji o c z e k iw a n y c h o ra z w a rtb ś ć n a le ż n y c h o p ła t k a rn y c h . T e rm in z w ro tu m o ż e z a le ż e ć o d k a te g o rii w y p o ż y c z a n e ! p o z y c ji i o d s ta tu s u c z y te ln ik a . S z c z e g ó ło w y a lg o ry tm o b lic z a n ia te rm in u z w ro tu z o s ta rjie u s ta lo n y p ó ź n ie j. M o ż liw e są z m ia n y re g u ł o b lic z a n ia te rm in u z w ro tu p o d c z a s d z ia ła m i s y s te m u .
... [d a ls z e re g u ły b iz n e s o w e ]
______________________________________________________________________ __
Dalsze reguły biznesowe systemu bibliotecznego mogą określać np. wymagania dotyczące kodu kreskowego identyfikującego karty biblioteczne i książki, treść e-maila informującego o rezerwacji książki, reguły naliczania opłat za przekroczenie
4 .4 . M o d e lo w a n ie d z ie d z in y
16 1
lerminu zwrotu i wiele innych elementów. Łączna liczba reguł zależy od wielkości i stopnia skomplikowania projektu oraz od stylu pisania dokumentacji.
4 ,4 .
M o d e lo w a n ie d z ie d z in y
Rozwijaniu i dokumentowaniu wymagań użytkowników, dotyczących tworzonego oprogramowania, towarzyszy modelowanie dziedziny zastosowania, w której to oprogramowanie ma działać. Punktem wyjścia do rozpoczęcia budowy modelu dzie dziny są rezultaty analizy strategicznej oraz informacje uzyskane z analizy dokumen tacji i wywiadów prowadzonych z użytkownikami w trakcie prac nad modelowaniem wymagań. Celem jest zbudowanie pełnego i dokładnego modelu, przedstawiającego klasyfikację, atrybuty i powiązania wszystkich obiektów dziedziny zastosowania istotnych dla realizacji wymagań oraz opisującego różne typy zachowań tych obiek tyw. Zarówno terminologia, jak i zawartość modelu dziedziny powinny być spójne z terminologią i treścią modelu przypadków użycia, natomiast kolejność, budowania tych modeli może być dowolna.
4.4.1. N a rzę d zia m o d elo w a n ia Podstawowym narzędziem modelowania struktury obiektów występujących w dzie dzinie zastosowania jest diagram klas, opisany dokładnie w podrozdziale 4.1. Narzę dziem modelowania zmieniających się w czasie zachowań obiektów jest diagram maszyny stanowej (stale machinę diagram). D iag ram m a s z y n y s ta n o w e j Podstawową koncepcją modelu jest pojęcie stanu, który podsumowuje dotychczasową historię życia obiektu. Zachowanie obiektu - określone przez to, co obiekt może robić w odpowiedzi na zewnętrzne pobudzenia, oraz to, co można z tym obiektem zrobić zależy tylko od jego bieżącego stanu, natomiast nie zależy od drogi, jaką do tego stanu doszedł. Na przykład, miejsce w systemie rezerwacji miejsc lotniczych może być wolne, zarezerwowane albo sprzedane. Miejsce wolne można zarezerwować albo sprzedać, ale nie można dla takiego miejsca wycofać rezerwacji ani zwrócić biletu. Miejsce zarezerwowane można sprzedać lub wycofać jego rezerwację, ale nie można go zarezerwować po raz drugi. Zachowanie miejsca zależy tylko od jego stanu - lo, czy i ile razy miejsce było rezerwowane i zwalniane w przeszłości, nic ma dla jego zachowania żadnego znaczenia. Diagram maszyny stanowej wylicza wszystkie stany, w jakich może znajdować się obiekt, oraz wszystkie możliwe przejścia między tymi stanami. Stany są przedsta wiane graficznie jako zaokrąglone prostokąty, a przejścia między stanami są rysowane jako strzałki. Stany mają nazwy, a przejścia noszą etykiety, zapisywane w posłaci:
162
4. M etody obiektow e
zdarzenie [ dozór / / akcja w których zdarzenie wskazuje przyczynę wykonania przejścia, akcja określa działania wykonywane w czasie przejścia, a dozór jest dodatkowym warunkiem, którego speł nienie jest niezbędne, dla wykonania przejścia. Dwa ostatnie elementy są,opcjonalne. Diagram maszyny stanowej, obrazujący cykl życia miejsca w pewnej taryfie lotniczej, jest pokazany na rys. 4.20.
163
4 ,4 . M odelow anie dziedziny
szóści spraw przysługuje prawo odwołania od niekorzystnej decyzji. W takim przy padku sprawa zostanie rozważona ponownie, przez drugą instancję, która może utrzymać pierwszą decyzję, uchylić ją (tak jakby pierwszego rozstrzygnięcia nie było) .,lbo nakazać ponowne rozpatrzenie sprawy. Zatem sprawa, która jest otwarta, może być w tym czasie albo w tolat - urząd nad nią pracuje (po raz pierwszy lub po odwoła niu). albo rozpatrzona - z wydaną decyzją I instancji (czeka na naszą akceptację lub odwołanie), albo zawieszona - w oczekiwaniu na brakujące dokumenty. Dokładniej szy model cyklu życia sprawy jest pokazany na rys. 4.22. Jak widać, podstawowe stany sprawy zawierają zagnieżdżone stany niższego poziomu, pokazujące szczegóło wy obraz jej załatwiania. zam kn ię ta
zwrot biletu [najpóźniej m iesiąc przed terminem] / zwrot 90% ceny
otwarta zawieszenie wznowienie
Rysunek 4.20. Diagram maszyny stanowej obrazujący cykl życia miejsca Diagram maszyny stanowej wyrasta z formalnego modelu automatu skończo nego, rozszerzonego w języku UML o elementy zwiększające silę wyrazu w różnych sytuacjach spotykanych w realnym świecie. Jednym z takich rozszerzeń jest możliwość reagowania na upływ czasu. Wyrażenie a/ter ( o k re s) określa zdarzenie pojawiające się automatycznie po upływie wskazanego okresu liczonego od chwili osiągnięcia danego stanu. Zarezerwowane miejsce, które nie zostanie wykupione w ciągu siedmiu dni od chwili rezerwacji, jest automatycznie zwalniane. Innym rozszerzeniem modelu jest możliwość hierarchizacji stanów, pozwalająca na opisywanie zachowania obiektu na różnych poziomach abstrakcji. Na przykład, niemal każda sprawa załatwiana w urzędzie może być albo otwarta —czyli rozważana przez urząd, albo zamknięta - czyli już zakończona wydaną prawomocnie decyzją. Zgrubny model obrazujący cykl życia sprawy można więc przedstawić jak na rys. 4.21.
otwarta
decyzja urzędu / zam knięcie sprawy ^
Rysunek 4.21. Zgrubny model życia sprawy urzędowej
odesłanie sprawy do archiwum
zam knięta
i
Jeśli dokładniej przyjrzymy się sposobowi załatwiania spraw w urzędach, to od kryjemy dwie ważne reguły. Po pierwsze, załatwienie sprawy może opóźnić się z winy petenta, jeśli nie złoży on wszystkich niezbędnych dokumentów. W takim przypadku urząd zażąda uzupełnienia dokumentów i zawiesi sprawę do czasu ich otrzymania. Po drugie, zgodnie z kodeksem postępowania administracyjnego w więk-
v zawieszona
decyzja I instancji
decyzja II instancji [uchylenie!
uchylona
decyzja II instancji [utrzymanie w mocy]
utrzymana w mocy
w to ku
A odwołanie
slandardowo
rozpatrzona zam knięcie spraw y , m inął term in odw ołania] V
Rysunek 4.22. Dokładniejszy model życia sprawy urzędowej Zbudowanie systemu wspomagającego działanie urzędu wymaga jeszcze głęb szego wejrzenia w sposób załatwiania spraw. Sprawa, która jest w toku, może być prowadzona - czyli badana przez odpowiedniego pracownika urzędu, może leżeć z decyzją - opracowana przez urzędnika, ale jeszcze niepodpisana przez naczelnika urzędu, i może być vt' odwołaniu - oczekując na decyzję II instancji. Pełny diagram maszyny stanowej opisującej caiość przetwarzania sprawy jest pokazany na rys. 4.23. Stany złożone nie rozszerzają znaczenia diagramu i są tylko wygodnym mecha nizmem grupowania stanów podobnych. Analizując diagram życia sprawy, łatwo za uważyć, że maszyna stanowa zawsze znajduje się w jednym ze stanów najniższego poziomu, z którego może przejść do innych stanów. Przejście prowadzące do stanu złożonego, np. przejście początkowe do stanu w loku, prowadzi do jego stanu począt kowego - tu do stanu prowadzona. Przejście wychodzące ze stanu złożonego jest skró towym oznaczeniem całego zbioru przejść, zaczynających się w każdym ze stanów wewnętrznych i prowadzących do stanu docelowego - przejście ze stanu w toku do stanu zawieszona może zacząć się w każdym z trzech stanów wewnętrznych. Dodatkowej interpretacji wymaga powrót do stanu złożonego, który powinien nastąpić do tego stanu wewnętrznego, z którego nastąpiło wyjście. Tę pamięć „historii wyjścia” zaznacza na diagramie symbol H w małym kółeczku. Przejście prowadzące do pamięci historii oznacza powrót do tego stanu, z którego nastąpiło wyjście ze stanu złożonego.
164
4. M e to d y o b iek to w e
163
¿4.4. M o d e lo w a n ie d z ie d z in y
maszyny stanowej jest modelem pierwszoplanowym, wykorzystywanym zarówno do definiowania wymagań, jak i do automatycznej generacji kodu. stop
pusta / wytącz pompę
start / zablokuj drzwi x /ptw órz dopływ wody
opróżnianie
A
napełnianie
after (3 0 m in .) / wytącz grzałkę w yłącz silrjik w łącz pompę
pełna / włącz grzałkę N^zamknij dopływ wody
/""p ra n ie grzanie
> 90°C / w yłącz g rz a łk ą
< 85°C / w łącz grzałkę oczekiwanie
R ysunek 4.23. Pełny model życia sprawy urzędowej
Diagram maszyny stanowej można interpretować jako model cyklu życia obiektu albo jako model algorytmu działania - z rys. 4.23 można odczytać nie tylko stany sprawy, ale też scenariusz działań, które prowadzą do jej załatwienia. W tej drugiej interpretacji zachodzi czasem potrzeba pokazania czynności (stanów) występujących równolegle. Na przykład, pralka może jednocześnie grzać wodę i mieszać pranie, obracając bębnem. Obydwie czynności dzieją się jednocześnie i niezależnie - sterow nik pralki może przerwać jedną z nich, kontynuując wciąż drugą. Sposób modelowa nia czynności równoległych na diagramie maszyny stanowej odwołuje się do symbo liki zaczerpniętej z diagramów czynności. Stany równolegle rysuje się jako wewnętrz ne stany stanu nadrzędnego, podzielonego na regiony (regiom), podobne do torów dzielących diagram czynności. Przejścia prowadzące do stanów równoległych wycho dzą z miejsca rozchodzenia się przejść podobnego do rozwidlenia na diagramie czyn ności. W analogiczny sposób można też przedstawić miejsce schodzenia się przejść. Algorytm działania sterownika pralki, z uwzględnieniem równoległości działania w stanie pranie, można przedstawić w sposób pokazany na rys. 4.24. Szczególną cechą sterownika jest to, żc akcje wykonywane podczas przejść mię dzy stanami odpowiadają bezpośrednio komendom (sygnałom sterującym) przekazy wanym do urządzeń wykonawczych. Podkreśleniem tej bezpośredniej odpowicdniości jest tryb rozkazujący użyty w nazwach akcji. I Diagram maszyny stanowej należy do najstarszych i najpopularniejszych modeli używanych w informatyce. Jest modelem formalnym, zapożyczonym z matematycznej teorii automatów skończonych. Jednocześnie jest modelem konstruktywnym, łatwym do przekształcenia w implementację. W dziedzinie systemów wbudowanych, w której donijjjującjtiii elementem jest dynamika reagowania na zdarzeni,a zewnętrzne, diagram
after ( 3 min.) bezruch
obrót w prawo
after (3 0 s) / silnik w praw a^
obrót w lewo
after (3 0 s ) / wyłącz silnik
Rysunek 4.24. Model działania sterownika pralki automatycznej
4.4.2. M o d e lo w a n ie stru ktu ry Głównym składnikiem modelu dziedziny jest diagram klas, przedstawiający klasyfi kację wszystkich obiektów leżących w polu zainteresowania użytkowników oraz związki między tymi obiektami. W tej fazie projektu diagram klas jest wciąż postrze gany w perspektywie pojęciowej, w której nic podjęto jeszcze decyzji o rozmieszcze niu w klasach operacji umożliwiających realizację wymagań (scenariuszy przypadków użycia). Budowa modelu klas nie jest jednak prostym uszczegółowieniem modelu analizy strategicznej. Jak zwykle podczas modelowania, tę samą rzeczywistość można zamodelować różnic - zależnie od celów modelowania, kontekstu oraz doświadczeń i wybo rów modelującego. Modelowanie dziedziny wymaga więc nie tylko odkrywania rzeczy wistości, lecz także podejmowania decyzji analitycznych o sposobie jej modelowania. Najpoważniejszym problemem jest wybór najlepszego sposobu odwzorowania w modelu rzeczywistości widzianej przez pryzmat wymagań użytkownika. Na przy kład, wymagania postawione systemowi wspierającemu działanie biblioteki mówią o konieczności zapewnienia możliwości rezerwacji woluminu dostępnej pozycji, ocze kiwania czytelnika na czasowo niedostępną pozycję oraz wypożyczenia. Realizacja tych wymagań wiąże się z koniecznością pamiętania przez system zapisu Rezerwacji,
166
4 . M e to d y o b ie k to w e
4,4, M o d e lo w a n ie d z ie d z in y
167
Oczekiwania i Rewersu wypożyczenia książki. Wszystkie wymienione tu klasy wystę pują we wstępnym modelu biblioteki, pokazanym na rys. 4.17. Dokładniejsza analiza wymienionych pojęć pokazuje jednak, że Rezerwacja i Rewers są raczej różnymi stanami tego samego obiektu niż różnymi obiektami. Re. zerwacja jest zapowiedzią wypożyczenia, która wiąże czytelnika z wybraną przez niego pozycją. Akt wypożyczenia polega na przypisaniu'czytelnikowi konkretnego Woluminu tej pozycji, co przekształca Rezerwację w Rewers, zachowujący istniejące powiązanie i wiążący czytelnika z. wypożyczonym Woluminem. Jedyną różnicą mię dzy obydwoma obiektami jest kilka dodatkowych atrybutów, takich jak numer wolu minu i okres wypożyczenia, określanych w chwili wypożyczenia woluminu. Dla Rezerwacji te atrybuty pozostają nieokreślone. Oczekiwanie na zamówioną pozycję nie może być traktowane tak samo. Wszyst kie Oczekiwania odnoszące się do tej samej pozycji tworzty (ćolejkę oczekujących na niedostępny egzemplarz i utrzymywanie tej kolejki jest najważniejszym elementem przetwarzania dotyczącym obiektów tej klasy. Wynikający z tych rozważań model powiązań klas obiektów jest pokazany na rys. 4.25.
R ysunek 4.25. Powiązania rezerwacji i rewersu wypożyczenia
Innym problemem jest wybór właściwej głębokości hierarchii relacji uogólnie nia. Biblioteka może wypożyczać książki osobom fizycznym albo innym bibliotekom. Naturalnym sposobem przedstawienia klasyfikacji czytehiików w modelu jest wyod rębnienie z klasy Czytelnik dwóch klas szczegółowych: 0.łęba i Biblioteka (rys. 4.26). Nie rozwiązuje to jednak całego problemu, gdyż osoby uprawnione do wypożyczania książek dzielą się na pracowników, studentów i doktorantów. Z kolei pracownicy dzielą się na pracowników naukowych, technicznych i administracyjnych, a w każdej z tych grup można wyróżnić co najmniej kilka różnych stanowisk pracy. Również studenci dzielą się na studiujących w trybie stacjonarnym lub niestacjonarnym, a ci ostatni - na studiujących zaocznie lub wieczorowo. Czy jest sens budować model pokazujący wszystkie wymienione poziomy klasyfikacji?
Rysunek 4.26. Klasyfikacja czytelników biblioteki
Odpowiedzi należy szukać w wymaganiach użytkownika. Jeżeli sposób wypoży czania książek czytelnikom wszystkich wymienionych kategorii jest istotnie różny i wymaga przechowywania w systemie różnych danych, to pokazanie pełnej klasyfika cji użytkowników' jest potrzebne. Jeżeli różnic nie ma, to nie ma sensu gmatwać modelu nieistotnymi szczegółami. W przypadku wątpliwości na ogól umieszcza się w modelu dziedziny klasy szczegółowe, traktując ich obecność jako sygnał koniecz ności pogłębienia analizy w przyszłości. Alternatywnym rozwiązaniem może być przypisanie obiektom klasy dodatkowego atrybutu definiującego kategorię obiektu w ramach tej klasy. Połączony model dziedziny biblioteki uniwersyteckiej, ilustrujący próbę rozwią zania wszystkich wymienionych problemów, jest pokazany na rys. 4.27. Warto zwró cić uwagę na sposób przedstawienia podwójnej klasyfikacji pozycji wydawniczych. Z jednej strony pozycje dzielą się na książki wydane drukiem i unikatowe rozprawy naukowe opracowane wewnątrz uniwersytetu. Z drugiej strony można je podzielić na podręczniki - wypożyczane na semestr, pozycje ogólnodostępne - wypożyczane na miesiąc, i pozycje z ograniczonym dostępem - wypożyczane różnym kategoriom czytelników na różny okres. Ponieważ książki i rozprawy charakteryzują się różnymi atrybutami, więc ten podział jest przedstawiony za pomocą relacji uogólnienia. Z kolei podział na różne kategorie książek, do których stosują się różne reguły biznesowe, jest pokazany przez skojarzenie ze słownikiem kategorii książek. Stereotyp «enumeration» wyróżnia klasę opisującą wyliczeniowy typ danych. Każdy obiekt klasy Pozycja jest w każdej chwali związany z dokładnie jedną wartością tego słownika, określającą w tym przypadku kategorię danej pozycji. Na diagramie nie ma klas asocjacyjnych, zastąpionych przez zwykle klasy Re wers i Oczekiwanie. Ten krok - eliminacja klas asocjacyjnych - musi być kiedyś wykonany, gdyż żaden z powszechnie używanych języków programowania ani żaden silnik baz danych nie wspiera koncepcji klasy asocjacyjnej. Dlatego stosowanie klas asocjacyjnych należy traktować jako metodę odkrywania i modelowania klas nieodpowiadających bezpośrednio bytom występującym w dziedzinie problemu, użyteczną
4. M elody obiektow e
169
^.4. M o d e lo w a n ie d z ie d z in y
na wstępnych etapach modelowania. W dalszym biegu projektu - już teraz albo pó£. niej podczas projektowania szczegółowego - klasy asocjacyjne i tak muszą być zastą pione zwykłymi klasami.
Rysunek 4.28. Diagram maszyny stanowej obrazujący cykl życia woluminu
Historia życia woluminu dobrze pokazuje ideę działania systemu wypożyczeń i jest użytecznym elementem wczesnej wizji systemu. Konfrontacja tego diagramu z modelem przypadków użycia oraz diagramem klas ujawnia jednak pewne niedopa sowanie tych modeli - operacja wypożyczenia dotyczy zawsze konkretnego woluminu, natomiast: rezerwacji podlega anonimowy wolumin pozycji wydawniczej (może być ich kilka). Trudno więc obydwa stany przypisać temu samemu woluminowi. Z drugiej strony rezerwacja i wypożyczenie są stanami sprawy załatwianej przez system na rzecz użytkownika. Dla każdej takiej sprawy jest tworzony odrębny obiekt klasy Rewers, którego stan zmienia się w czasie i odwzorowuje bieżący stan sprawy. Po zwróceniu woluminu przez czytelnika sprawa, a wraz z nią rewers, przestaje istnieć (rewersy mogą być przechowywane w archiwum). Diagram maszyny stanowej opisu jący historię życia Rewersu jest pokazany na rys. 4.29. rejestracja rezerwacji lub rejestracja Y zwrotu w olum inu oczekiwanej pozycji
R ysunek 4.27. Dokładny model klas dziedziny systemu bibliotecznego
rezerwacja
4 .4 .3 . M o d e lo w a n ie za c h o w a n ia Równolegle z identyfikacją klas i obiektów definiuje się podstawowe typy zachowań, jakie mogą przejawiać obiekty w czasie swojego życia. Narzędziem modelowania jest diagram maszyny stanowej, wyliczający wszystkie stany w jakich może znajdować się obiekt, oraz dopuszczalne przejścia między tymi stanami. Nie ma potrzeby mode lowania w ten sposób wszystkich obiektów dziedziny, ^naliza dotyczy zazwyczaj tylko tych obiektów, których stan i sposób zachowania i,sjiotnie wpływają na sposób działania systemu. Kluczowymi obiektami systemu bibliotecznego są na pewno wo luminy pozycji wydawniczych, których stan zmienia się w miarę rezerwacji, wypoży czeń i zwrotów. Historia życia woluminu oraz zestaw możliwych do wykonania operacji są pokazane na rys. 4.28.
usunięcie rezerwacji
rejestracja wypożyczenia / przypisanie wolum inu
after ( 2 d n i)
Y wypożyczenie
rejestracja zwrotu Y
->
W idoki «JSP» i
d L->
201
Elementami pakietu Bibliotekarz, są komponenty implementujące lokalny inter fejs bibliotekarza. Komponent GUI jest plikiem wykonalnym obsługującym całość graficznego interfejsu użytkownika. Komponent Interfejs czytnika obsługuje czytnik kodu kreskowego i udostępnia na zewnątrz metodę czytajKodKreskowyf )■ Komponent O peracje jest plikiem wykonalnym pośredniczącym w wywoływaniu operacji logiki biznesowej wykonywanych przez komponenty pakietu Aplikacja. Zależnie od wybra nego języka implementacji i systemu operacyjnego stacji roboczej poszczególne komponenty mogą mieć postać plików wykonalnych typu exe, archiwów jar, bibliotek
Bibliotekarz
Kontrolery «serwlet» l
Y~>. T echnologie obiektow e
Operacje «serwlet»
dli itp. Warstwa danych obejmuje tabele bazy danych i procedury składowane separu jące pozostałe komponenty oprogramowania od fizycznej struktury tabel. W ogromnej większości przypadków procedury składowane będą zawierać skrypty opracowane
Biblioteka
¡a Tabele
Rysunek 4.46. Diagram komponentów systemu bibliotecznego Sesyjne komponenty EJB pakietu Aplikacja są krótkotrwałymi obiektami powo ływanymi cło życia przez warstwę pośrednią, pracującą na serwerze, na czas trwania jednej sesji użytkownika. Klasy wchodzące w skład komponentu Rezerwacje wyko nują wszystkie operacje biznesowe, jakie mogą być wywołane zdalnie przez czytel nika. Klasy wchodzące w skład komponentu Wypożyczenia wykonują wszystkie operacje biznesowe, jakie mogą być wywołane przez bibliotekarza. Komponenty sesyjne nie są dzielone między różnych użytkowników. Jednoczesne zgłoszenia wielu użytkowników są obsługiwane przez powołanie do żjjcia przez oprogramowanie warstwy pośredniej wielu kopii (instancji) potrzebnego komponentu. W ten sposób warstwa pośrednia automatycznie rozwiązuje problem llrównoczesnej pracy wielu użytkowników systemu. I hncyjne komponenty EJB są trwałymi obiektami reprezentującymi dane pobiera ne z tabel bazy danych i modyfikowane przez komponenty sesyjne. Oprogramowanie warstwy pośledniej automatycznie śledzi obecność encji w pamięci i udostępnia dane różnym egzemplarzom komponentów sesyjnych.
w języku SQL. Określenie technologii implementacji na etapie projektu architektonicznego nie tylko konkretyzuje projekt, lecz także określa wymagane kwalifikacje wykonawców dalszych prac projektowych i implementacyjnych; Efektywne tworzenie stron JSP i serwletów wymaga dobrej znajomości tej właśnie technologii, dosyć odległej od technologii programowania np. w języku C++. Komponenty EJB muszą być tworzone przez programistów Javy, a projekt tabel i skrypty SQL powinni wykonać admini stratorzy bazy danych. Zdefiniowanie komponentów nie przesądza jeszcze o fizycznej architekturze systemu, na którą składa się również sposób rozmieszczenia warstw i komponentów na serwerach i stacjach roboczych systemu. Zasadnicza decyzja dotyczy tu rozdziele nia (lub połączenia na jednej maszynie) środowisk wykonawczych warstwy danych, warstwy aplikacyjnej i warstwy prezentacji obsługującej interfejs czytelnika. Podsta wowym kryterium przy podejmowaniu tej decyzji jest możliwość spełnienia wymagań niefunkcjonalnych, w tym zwłaszcza osiągnięcia wymaganej wydajności systemu przewidywane obciążenie serwerów nie może przekraczać ich nominalnej wydajności. Szacowanie przewidywanego obciążenia systemu jest trudne i wymaga pewnego doświadczenia praktycznego. Prosta metoda oceny polega na określeniu obciążenia serwera bazodanowego, wyrażonego liczbą transakcji na minutę, i przyjęciu, że inne serwery są obciążone w podobnym (lub nieco większym) stopniu. Tak obliczone obciążenie można porównać z wydajnością uzyskiwaną przez różne systemy podczas testów (TPC-C) przeprowadzanych i publikowanych przez Transaction Processing Performance Council j 256j. Podstawą do szacowania obciążenia systemu bibliotecznego są wymagania okre ślone w tab. 4.3. Przyjmując, że operacja wyszukania wszystkich pozycji pasujących do niepełnych danych bibliograficznych podanych przez czytelnika wymaga przecięt nie odczytania opisu 10 pozycji, i zakładając, że przeciętny czytelnik może wykonać dwie takie operacje w ciągu minuty, otrzymujemy - dla 100 czytelników - obciążenie
2 02
4. M etody obiektow e
2000 transakcji na minutę. Porównanie tej wartości z wydajnością jednoprocesorowe go serwera Xeon 2,8 GHz, przekraczającą 19 0001 transakcji, pokazuje, że wszystkie trzy pakiety: Czytelnik, Aplikacja i Dane, mogą być rozmieszczone na tym samym serwerze. Diagram rozmieszczenia komponentów oprogramowania w kontenerach warstwy pośredniej i na maszynach systemu jest pokazany na rys. 4 .47.
«device» :K om puter czytelnika
4
T echnologie obiektow e
a GUI
przeglądarka pliki cookies
gui.Jar barcode.dll operacje.jar
1..10
internet
S Czytnik
«kom puter PC» :S tacia bibliotekarza {Pentium 2,8 GHz) -
«device» K o m p u te r czytelnika
«device» :Stacia bibliotekarza
Przeglądarka
203
O
Ethernet {sieć w ewnętrzna)
«device» :Glównv serw er biblioteki {Intel Xeon, 2,8 GHz, OS=Linux)
Operacje
1..10 Internet / HTTP
Ethernet (sieć wewnętrzna)
«device» :Glównv serw er biblioteki «executionEnvironment» :K ontener w ebowy d Widoki «JSP»
d Kontrolery «serwlet»
d Operacje «serwlet»
«executionEnvironment» :RDBMS
Procedury składowane
«executionEnvironment» K o n te n e r EJB €3 Model «EJB encyjne»
«executionEnvironment» K o n te n e r EJB
«executionEnvironm ent» :RDBMS
widoki.jsp kontrolery.war operacje.war
rezerwacje.ear w ypożyczenia.ear m odel.ear specyfikacja.xm l
biblioteka.ddl skrypty.sql
1/ Rysunek 4 .4 8 . D ia g r a m r o z m ie s z c z e n ia a r t e f a k t ó w p r o je k t o w y c h s y s te m u b ib lio t e c z n e g o
RMI
d Rezerwacje «EJB sesyjny»
«executionEnvironment» K o n te n e r w ebowy
d W ypożyczenia «EJB sesyjny»
JDBC
Tabele
4.6.3. P ro je kto w an ie p ro g ra m ó w Metody projektowania i implementowania programów w wybranej technologii nic są uniwersalne - w przeciwieństwie do niezależnych od implementacji metod analizy lecz istotnie zależą od specyficznych cech tej technologii oraz od zakresu oferowane go przez nią wsparcia. Jeżeli pozostaniemy przy wybranej w punkcie 4.6.2 technologii EJB 3.0, to otrzymamy gotowe rozwiązanie dwóch ważnych problemów, zaledwie zaznaczonych w podrozdziale 4.5: komunikacji stacji roboczych z serwerem i współpracy programów logiki aplikacji z bazą danych. Krótką prezentację obydwu rozwiązań rozpoczniemy od lego drugiego. K o m p o n e n ty e n c y jn e
R ysunek 4 .4 /. D ia g r a m r o z m ie s z c z e n ia k o m p o n e n tó w s y s te m u b |b lio te c z n e g o
I ekslowa wersja tego samego diagramu, przedstawiająca rozmieszczenie artefaktów projektowych, a nie komponentów, jest pokazana na rys. 4.48.
W y d a jn o ś ć 1 P C - C z a le ż y o d k o n f ig u r a c ji s p rz ę tu , ty p u s y s te m u o p e r a c y jn e g o i m o t o r u b a zy danych.
Sposób współpracy programów z bazą danych opisuje specyfikacja Java Persistence API, tworząca wyodrębnioną część specyfikacji EJB 3.0. Trwale dane, przechowy wane w bazie danych, reprezentują na poziomie programu komponenty encyjne. Każdy taki komponent jest klasą, która zawiera atrybuty - odpowiadające kolumnom tabeli, oraz metody - przede wszystkim metody zwracające wartości atrybutów, metody ustawiające te wartości i przynajmniej jeden bezargumentowy konstruktor. Komponenty encyjne odróżniają od zwykłych klas adnotacje, czyli nicwehodzącc
204
4. M etody obiektow e
w skład języka Java polecenia dla kontenera EJB, Najważniejsze adnotacje identyfi. kują komponent encyjny, wskazują atrybut lub atrybuty pełniące rolę klucza głównego tabeli reprezentowanej przez ten komponent oraz definiują powiązania między encjami. Korzystając z tych adnotacji, możemy zdefiniować komponenty encyjne opi sujące model dziedziny biblioteki (rys. 4.41). package a p lik a c ja .m o d e l @ E ntity p u b l i c c la s s P ozycja im plem ents j a v a . i o . S e r i a l i z a b l e p r iv a t e i n t idP; p riva te S trin g autor; p r i v a t e S t r i ng t y t u l ; p r i v a t e i n t rokW ydania; p r iv a t e i n t liczbaW olum inow;
C
public
Pozycja O
@I d p u b lic
in t
public pu b lic pu b lic pu b lic
S trin g getA utorO C return autor; ] S trin g g e tT y tu lO C return t y t u l; 3 i n t g e tR ok W y daniat) C r e tu r n rokW ydania; 3 i n t getLiczb a W o lu m in o w t) C re tu rn liczbaW olum inow ;
C return
idP;
3
3
} © E ntity p u b l i c c l a s s Wolumin im p le m e n ts j a v a . i o . S e r i a l i z a b l e p r i v a t e i n t idW; p r i v a t e Pozycja p o z y c ja ;
[
in t getldW O
C return
idW;
3
©ManyToOne © J o i n C o l u m n ( n a me = " i d P " ) p u b lic Pozycja get P o z y c ja () C r e tu r n
3
> pozycja;
3
I
©Enti ty 1 p u b l i c c l a s s Rewersi m p l e m e n t s j a v a . i o . S e r i a l i z a b l 4 C p r i v a t e Dated a ta U tw o rz e n ia : | p r i v a t e Date o kre s W y po z ycz e n ia ; p r i v a t e Date d a ta Z w ro tu ; priva te priva te private
C zytelnik c z y te ln ik ; Pozycja pozycja; Wolumin wolum in;
©On e To On e @ J o i n C o l u m n ( name “ " i d C " ) pu b lic C zy te ln ik g e tC z y te ln ik () C re tu rn c z y te ln ik ; p u b lic void s e t C z y t e ln ik ( C z y t e ln ik c) i c z y t e l n i k ©On e To On e @ j o i n C o l u m n C name - " i d P " ) p u b lic Pozycja g e tP o z y c ja O C re tu r n p o zy cja ; p u b l i c v o i d s e t P o z y c j a ( P o z y c j a p) C p o z y c ja -
3 p;
3
@ManyToOne @ J o i n C o l u m n ( name = " i d W " ) p u b l i c Wolumin g e t W o lu m in O C r e t u r n w o lu m in ; 3 p u b l i c v o i d s e t W o l u m i n ( W o l u m i n w ) C w o l u m i n = w;
3
3 c;
3
K o m p o n e n ty s e s y jn e
p u b l 1c W o !u m in C ) C3 ©Id p u b lic
205
Adnotacja @Entity, bez dodatkowych parametrów, identyfikuje klasę jako kom ponent encyjny reprezentujący tabelę o tej samej nazwie. Adnotacja @Id, umieszczona przed definicją atrybutu lub przed definicją metody zwracającej wartość atrybutu, wska zuje atrybut pełniący rolę klucza głównego tabeli. Adnotacje ©ManyToOne oraz @JoinColumn w klasie Wolumin definiują powiązanie tej klasy - i reprezentowanej przez nią tabeli - z klasą Pozycja. Powiązanie jest typu wiele (obiektów H ds^ Wolumin) do jednego (obiektu klasy Pozycja), a klucz obcy tabeli Pozycja jest przechowywany w kolumnie "idP" tabeli Wolumin. Podobne znaczenie mają adnotacje @ManyToOne oraz @OneToOne umieszczone w kodzie klasy Rewers.
C3
g e tld P O
ą. 6. T echnologie obiektow e
Tworzenie, zapisywanie w bazie danych i wyszukiwanie obiektów encyjnych - tzn. egzemplarzy klasy tworzącej komponent encyjny - realizują metody specjalnej klasy bibliotecznej nazywanej zarządcą encji (EntilyManager). Funkcje wykonywane przez zarządcę encji odpowiadają z grubsza funkcjom, jakie przypisaliśmy w punkcie 4.5.4 klasie PortalDanych. Zarządca encji potrafi odnaleźć wskazane obiekty w bazie danych, załadować je do pamięci wraz z obiektami powiązanymi za pomocą asocjacji i rozwinąć model obiektowy zgodny ze strukturą diagramu klas. Co więcej, zarządca encji prowadzi wykaz obiektów znajdujących się aktualnie w pamięci i nigdy nie tworzy wielokrotnych kopii tego samego obiektu. Po zakończeniu transakcji zmienia jącej wartości atrybutów obiektu zarządca encji automatycznie uaktualnia opis obiektu zapisany w bazie danych. Wykorzystanie metod udostępnianych przez zarządcę encji uwalnia programistę od konieczności zajmowania się szczegółami współpracy z bazą danych. Jeśli zdecy dujemy się na realizację programu w architekturze zgodnej z wzorcem transaclion script, to metody ldasy kontrolerWypożyczeń znajdą się teraz w klasie sesyjnego komponentu Wypożyczenia (rys. 4.46). Przykładowy program realizujący metody
'W 206
4. M etody obiektowe
podajRez.erwacjęi ) i wypożycz( ), analogiczne do metod opisanych w punkcie 4.54 może wyglądać następująco. package a p lik a c ja .w y p o ż y c z e n i a ; ©Remote p u b l i c i n t e r f a c e W ypożyczeniaRem ote C p u b li c Pozycja p o d a jR e z e rw a c je tin t id C ); p u b l i c i n t w y p o z y c z tin t idW );
3 © Stateful p u b l i c c la s s Wypożyczenia iraplements WypożyczeniaRemote C @ PersistenceContext(unitN am e = " b ib li o t e k a " ) p r i v a t e E n t i t y M a n a g e r p; priva te priva te
Rewers Wolumin
rewers; wolum in;
p u b li c Pozycja p o d a jR e z e rw a c je tin t id C ) C Query q = p . c r e a t e Q u e r y ( " f r o m Rewers r w h e r e q.setP aram eter("a".id C ); q.setP aram eter("b",null ) ; rewers = ( Rewers)q. getS ingleR esul t O ; re tu rn rew ers.pozycja ;
r.idC =:a
and r . i d W = : b n ) ;
3 p u b l i c i n t w y p o z y c z t i n t idW) C wolumin = p . f in d t W o l u m in . c la s s , id W ) ; i f ( r e w e r s . p o z y c j a ! = w o l u m i n . p o z y c j a ) r e t u r n ERROR; r e w e r s . idW = idW re w e r s . okresW ypozyczenia obi i c z O k re s ( r e w e r s . p o z y c j a . k a t e g o r i a , r e w e r s . c z y t e l ni k . s t a t u s ) ; p.m ergetrew ers); . / / a k t u a l i z a c j a bazy r e t u r n OK;
3 3 Adnotacja @Remote identyfikuje interfejs WypożyczeniaRemote jako zdalny in terfejs komponentu - zdalny, tzn. taki, którego opentejc będą mogły wywoływać dowolne komponenty spoza kontenera EJB, np. aplikacje klienckie wykonywane na stacjach roboczych. Adnotacja @Sta te/ul identyfikuje klasę Wypożyczenia jako sta nowy komponent sesyjny - stanowy, tzn. taki, który ma atrybuty przechowujące wartości między kolejnymi wywołaniami jego metod. Oprócz komponentów stano wych istnieją też komponenty bezstanowc, które nie mają atrybutów. Każde wywoła nie metody takiego komponentu jest osobną transakcją, która nie pozostawia po sobie żadnego śladu w pamięci.
| , 6. T echnologie o biektow e
207
Adnotacja @PersislenceContext, umieszczona w klasie Wypożyczenia, informuje kontener EJB o konieczności powołania do życia obiektu zarządcy encji (prywatny obiekt p klasy EntityManager), obsługującego encje przechowywane w bazie danych o nazwie "biblioteka". Dzięki temu wszystkie metody klasy będą.m ogły korzystać Z usług zarządcy. Metoda podajRez,erwację() zawiera przede wszystkim zapytanie do bazy danych zapisane w języku EJB QL, zbliżonym do tradycyjnej notacji języka SQL. Zapylanie o treści: „znajdź w tabeli Rewers wszystkie obiekty, których atrybut iclC jest równy argumentowi a, a atrybut idW jest równy argumentowi /?” tworzy metoda create( ) wywołana na obiekcie zarządcy encji /?. Dwa kolejne wiersze programu definiują argumenty: a ma być równe identyfikatorowi czytelnika idC, a b ma być puste (nuli). Przedostatni wiersz programu realizuje zapytanie i tworzy poszukiwany obiekt rewers, a ostatni zwraca referencję do związanej z tym rewersem pozycji. Najciekawszym elementem metody jest właśnie ostatni wiersz. Zapytanie do bazy danych wyszukało ¡'załadowało do pamięci obiekt rewers. Instrukcja return zwraca jednak nie referencję do tego rewersu, lecz referencję do innego obiektu - do obiektu pozycja związanego z wyszukanym rewersem. Zatem w pamięci istnieje też obiekt pozycja, który został załadowany automatycznie przez zarządcę pamięci wraz z wyszukanym przez nas rewersem. Metoda wypożyczj ) zaczyna się od wywołania na obiekcie zarządcy encji p metody jind(), która znajduje w bazie danych opis woluminu o kluczu idW, tworzy w pamięci odpowiedni obiekt klasy Wolumin i zwraca referencję do tego obiektu. Jeśli jednak okaże się, że poszukiwany obiekt już istnieje, to metoda f i n d ( ) zwróci referencję do lego właśnie, już istniejącego, obiektu. Dwa kolejne wiersze programu wypełniają odpowied nie pola rewersu, rejestrując w ten sposób fakt wypożyczenia woluminu. Metoda merge() wywołana na obiekcie zarządcy encji p aktualizuje opis rewersu w bazie danych. Instrukcja return zwraca wartość potwierdzającą pomyślne zakończenie operacji. W treści klasy Wypożyczenia brakuje prywatnej metody oblicz.Okres(). Pominię cie to jest celowe, gdyż program tej metody nie ulega zmianie i jest identyczny z programem zamieszczonym w pierwszej części punktu 4.5.4. Poważniejszym pomi nięciem jest brak niezbędnych operacji importu różnych pakietów bibliotecznych. P o łą c z e n ie z s e rw e re m Ostatnim elementem aplikacji rejestrującej wypożyczenia jest program klienta, wyko nywany na stacji roboczej bibliotekarza. Główną trudnością lego programu jest połą czenie z kontenerem EJB, w którym są rozmieszczone komponenty warstwy logiki biznesowej, i uzyskanie od niego referencji do zdalnego interfejsu potrzebnego kom ponentu sesyjnego. Posiadanie takiej referencji umożliwi programowi klienta wywo ływanie metod udostępnianych przez komponent poprzez ten interfejs. Nawiązanie połączenia umożliwia usługa nazewnicza, oferowana przez serwer EJB poprzez inter-
208
4. M elody obiektow e
fejs JNDI (Java Naming and Directory Interface). Postać kodu służącego do nawiąza nia połączenia zależy - niestety - od producenta serwera. Przykładowy program klienta może wyglądać następująco. package b i b l i o t e k a r z . o p e r a c j e ; class
S ingleton
i
4.7. Proces RU P
209
zanych ze sposobem wywoływania operacji logiki biznesowej, realizowanych przez metody komponentu Wypożyczenia rezydującego na serwerze. W tym celu komponent Operacje udostępnia innym częściom programu statyczne metody podajRezerwację() j wypoż,ycz(), które uzyskują referencję do interfejsu zdalnego Wypoż.yczeniaReinote i za jego pośrednictwem wywołują potrzebne metody komponentu Wypożyczenia. y/ywolania w programie klienta mogą wyglądać następująco:
p riva te p riva te
s t a t ic S ingleton instance = n u ll; W y p o ż y c z e n i aRemote i n t e r f e j s ;
p o z y c j a ■= O p e r a c j e . p o d a j R e z e r w a c j e ( i d C ) ;
p riva te
S in g le to n t)
s tatus = O peracje.w ypozycz(idW );
C I n i t i a l C o n t e x t c o n t e x t = p o d a j C o n t e x t t ); O b je ct r e f = c o n t e x t . lo o k u p !"W ypożyczeniaRemote"); //in te rfe js i n t e r f e j s = ( W y p o ż y c z e n iaRemote) P o r ta b le R e m o te O b je c t.na r r o w ( r e f , Wypożyczeni aRemote.cl a s s ) ; 3 . p riv a te s ta tic In itia lC o n te x t podajC ontext() throw s NamingException C P r o p e r t i e s p = new P r o p e r t i e s ! ) ; p . p u t ( C o n t e x t . INITIAL_CONTEXT_FACTORY, " o r g . j n p . i n t e r f a c e s . Namin g C o n t e x t F a c t o r y " ); p.put(Context.URL_PKG_PREFIXES, "o rg .jb o s s .n a m in g :o rg .jn p .in te rfa c e s "); p.put(Context.PROVIDERJJRL," jn p : / / 1 9 2 . 6 4 .1 .2 :1 0 9 9 ") ; r e t u r n new I n i t i a l C o n t e x t ( p ) ; 3 p u b l i c s t a t i c W y p o ż y c z e n i aRemote i n t e r f e j s Z d a l n y ( )
/ / magi a //magia //URL serwera
C i f ( i n s t a n c e = = n u l l ) i n s t a n c e ~ new S i n g l e t o n O ; return in s ta n c e .in te rfe js ; 3 3 p u b lic c la s s O peracje C p u b li c s t a t i c Pozycja p o d a jR e z e rw a c je (in t idC ) ' C re tu rn S in g le to n .in te rfe js Z d a ln y ( ) .podajR ezerw acje(idC ); 3
Uzyskanie referencji do zdalnego interfejsu WypożyczeniaRemole jest zadaniem klasy Singleton. Konstrukcja tej klasy gwarantuje istnienie co najwyżej jednego obiektu klasy, który przechowuje referencję interfejsu WypożyczeniaRemole jako wartość atrybutu o nazwie interfejs. Statyczna metoda interfejsZdalny() tej klasy sprawdza istnienie tego obiektu, tworzy go, jeśli obiekt nie istnieje, i zwraca wartość atrybutu interfejs. Nawiązanie połączenia z serwerem i uzyskanie referencji do inter fejsu zdalnego następuje podczas tworzenia jedynego obiektu klasy Singleton i jest zawarte w jego konstruktorze. Pierwszą czynnością konstruktora jest nawiązanie połączenia z serwerem EJB, na którym rezydują komponenty pakietu Wypożyczenia. Kod nawiązujący połączenie jest ukryty w przykładzie w treści metody podajContext(), której wynikiem jest tzw. kontekst jndi, umożliwiający wywołanie metody lookup() wyszukującej zdalny interfejs potrzebne go komponentu. Ostatnią czynnością jest przekształcenie wyniku tego wyszukiwania - za pomocą metody narrow() - w referencję do interfejsu zdalnego komponentu. Kod metody podajC ontext(), nawiązujący połączenie z serwerem, musi być na pisany w sposób określony przez producenta serwera. Podane przez niego wiersze kodu należy potraktować jak formuły magiczne, tzn. przepisać dokładnie litera po literze, wstawiając w określonym miejscu adres URL serwera. Przytoczona w tym przykładzie treść metody podajC ontext() odnosi się do darmowego serwera JBoss.
I p u b lic
c
sta tic
in t w ypozycz(int
idW)
4
1'
4.7.
P ro c e s R U P
r e t u r n . S i n g l e t o n . i n t e r f e j s Z d a l ny ( ) . w y p o z y c z t i rft i d W ) ;
3
Komponent Operacje pakietu Bibliotekarz, jest częścią programu klienta, zain stalowanego na stacji roboczej bibliotekarza (rys. 4.46). Zadaniem tego komponentu jest ukrycie przed innymi częściami programu klienta technicznych szczegółów zwią-
Najczęściej stosowany sposób organizacji procesu wytwarzania oprogramowania opisuje iteracyjny proces RUP (Rational Unified Process), popierany przez OMG, który stal się dc facto standardowym procesem obiektowym. Proces RUP określa główne fazy projektu, podstawowe czynności i produkty wykonywane w kolejnych fazach oraz pewną filozofię ich wykonania. Duża część tych czynności i produktów jest: określona jako czynności i produkty opcjonalne, co daje możliwość - czy raczej
210
4. M etody obiektow e
stwarza konieczność - dopasowania procesu do indywidualnych potrzeb konkretnego projektu. Proces RUP jest więc raczej parametryzowanym wzorcem procesu wy. twórczego niż konkretnym procesem wytwórczym. Proces RUP dzieli całość działań związanych z wytwarzaniem oprogramowania na cztery fazy, z których każda pochłania pewną ilość zasobów (ludzi, pieniędzy, czasu) przeznaczonych dla projektu. Kolejność tych faz oraz orientacyjny rozkład zużycia zasobów w kolejnych fazach można przedstawić następująco [19]. 1. 2. 3. 4.
Rozpoczęcie (i/iception) - 5% wysiłku, 10% czasu. Opracowanie (elaboration) - 20% wysiłku, 30% czasu. Konstrukcja (construclion) - 65% wysiłku, 50% czasu. Przekazanie {tm nsitkm ) - 10% wysiłku, 10% czasu.
Każdą fazę wypełniają różne działania, rozw ijające'różne aspekty tworzonego oprogramowania. Wynikiem tych działań są określone produkty projektowe - specy fikacje, modele, pliki programu, pliki wykonalne, testy, raporty itp. - nazywane ogól nie artefaktami (artifacts). Definicja procesu RUP wyróżnia dziewięć rodzajów działań, nazywanych w dokumentacji dyscyplinami (disciptines), z których sześć podstawowych obejmuje: ■ ■ ht-p ■ ■ *
¿j.7. Proces RUP
Jj_ -----------------
beta w przypadku produktów ogólnodostępnych) oraz zapewnienie konserwacji i obsługi serwisowej. Orientacyjny rozkład czynności w procesie RUP jest pokazany na rys. 4.49. Podział procesu na cztery fazy nie oznacza, że każdą z nich można sprowadzić ¡jo pojedynczego wykonania sekwencji sześciu wymienionych czynności. Tak może się zdarzyć tylko w niewielkim projekcie. W większości przypadków struktura fazy przypomina wykonanie instrukcji pętli (iteracji), obejmującej powtarzalne wykonanie podobnych działań na kolejnych porcjach danych. Wynikiem każdej takiej iteracji są kolejne artefakty projektowe. Na przykład, faza opracowania projektu może przebie gać w dwóch iteracjach, obejmujących opracowanie biznesowego i systemowego modelu przypadków użycia, a faza konstrukcji w trzech iteracjach, obejmujących wytworzenie trzech działających wersji oprogramowania. Każda kolejna wersja im plementuje coraz szerszą funkcjonalność reprezentowaną przez coraz liczniejszy zbiór realizowanych przypadków użycia. Rozpoczęcie
Opracowanie
Konstrukcja
Przekazanie
modelowanie biznesowe (business modeling), analizę wymagań (require.me.n1s), i projektowanie {anedysis and design), implementację programów (implernenlation), testowanie {test), dostawę (deploymenf).
Trzy pozostałe dyscypliny są związane z procesem zarządzania projektem. RUP jest procesem iteracyjnym, którego każda faza obejmuje wykonanie wszyst kich wymienionych rodzajów działań - oczywiście w różnym zakresie i z różnym natę żeniem, wynikającym z różnych celów każdej fazy. Ce leni fazy rozpoczęcia jest uchwy cenie najważniejszych wymagań, wskazanie wizji rozwiązania, ocena ryzyka związanego z podjęciem przedsięwzięcia oraz oszacowanie koszty i czasu opracowania opro gramowania. W tej fazie dominujące znaczenie mają czynności modelowania bizneso wego i analizy wymagań. Faza opracowania jest skupioną na analizie wymagań i zapro jektowaniu architektury rozwiązania. Głównymi czynnościami tej fazy są więc analiza wymagań oraz analiza i projektowanie rozwiązania. W fazie konstrukcji powstają wszy stkie programy, przeprowadzane są testy i integracja całości systemu. W tej fazie domi nują czynności projektowania programów, implementacji i testowania. Faza przekazania jest przeznaczona na udostępnienie (dostawę) gotowego produktu użytkownikom. Obejmuje to instalację oprogramowania u klienta, testowanie akceptacyjne (lub testy
Warunkiem zakończenia bieżącej fazy jest opracowanie z góry założonego zbio ru artefaktów, dokumentujących osiągnięcie celów tej fazy. Weryfikacja i zatwierdze nie opracowanych artefaktów następuje podczas zaplanowanej kontroli postępów projektu. Harmonogram takich kontroli, nazywanych punktami kontrolnymi lub kamieniami milowymi (inilestones) projektu, jest jednym z narzędzi planowania i zarządzania projektem. Liczba i zakres kontroli zależą od potrzeb i charakteru pro jektu, jednak minimalny zbiór tych „kamieni milowych” wyznaczają punkty zakoń czenia kolejnych faz cyklu wytwórczego.
4.7.1. Faza ro zp o częcia baza rozpoczęcia poprzedza podjęcie decyzji o zaangażowaniu dużych środków t rozpoczęciu budowy oprogramowania. Jej głównym celem jest dostarczenie kierów-
212
4. M etody obiektow e
nietwu firmy danych niezbędnych do podjęcia tej strategicznej decyzji. Kluczowym elementem działań jest uchwycenie najważniejszych wyipagań użytkownika i wyzna czenie zakresu oraz rozmiaru budowanego systemu. Umożliwia to rozważenie róż nych sposobów zaspokojenia potrzeb (kupno lub budowa nowego systemu), opraco wanie koncepcji rozwiązania, wskazującej jakąś' możliwą do realizacji' architekturę systemu, oraz ocenę czasu i kosztu realizacji przedsięwzięcia. Najważniejsze wyniki fazy rozpoczęcia, weryfikowane i zatwierdzane na jej koń cu w punkcie kontroli celów przedsięwzięcia (Lifecycle Objectives), obejmują: * * ■ ■
dokument wizji, opisujący główne wymagania i ograniczenia; ocenę kosztu i korzyści biznesowych przedsięwzięcia; listę ryzyk opisujących zagrożenia dla realizacji przedsięwzięcia; wstępny plan rozwoju oprogramowania, określający strukturę organizacyjną i sposób zarządzania projektem; , ■ dokładny plan następnej iteracji projektu; ■ wstępne wersje słownika projektu i modelu przypadków użycia. Działania wykonywane w fazie rozpoczęcia koncentrują się na modelowaniu biznesowym i analizie wymagań, których celem jest określenie zakresu projektu i ustalenie kryteriów jego oceny. Modelowanie biznesowe może objąć opracowanie diagramów czynności najważniejszych procesów biznesowych, które mają być wspie rane przez tworzone oprogramowanie. Analiza wymagań obejmuje rozwinięcie scena riuszy najważniejszych przypadków użycia i opracowanie listy definicji najważniej szych pojęć dziedziny zastosowania. Uchwycenie podstawowych wymagań otwiera drogę do opracowania koncepcji rozwiązania oraz oszacowania wielkości systemu i kosztu jego opracowania. Decyzja o rozpoczęciu lub zaniechaniu przedsięwzięcia jest decyzją biznesową, która wykracza poza ramy inżynierii oprogramowania. W przykładowym projekcie oprogramowania systemu bibliotecznego, rozważa nym w tym rozdziale, modele budowane w fazie rozpoczęcia są opisane w podroz dziale 4.2. Plan rozwoju oprogramowania może przewidywać podział fazy opracowa nia na dwie sześciotygodniowe iteracje, fazę konstrukcji o długości pięciu miesięcy oraz miesięczny okres testowania akccptacyjnego i przekazania produktu. Pierwsza iteracja fazy opracowania kończy się zatwierdzeniem biznesowego, a druga - syste mowego, modelu przypadków użycia przez zleceniodawcę (punkty kontrolne projektu). Brak zatwierdzenia modelu w punkcie kontrolnym upoważnia strony do rozwiązania umowy. Metody szacowania kosztu opracowania i oceny ryzyka są elementem zarządza nia projektami i zostaną opisane w rozdziale 6.
4.7. Proces RU P
213
4.7.2. Faza o p ra c o w an ia Faza opracowania jest najbardziej twórczą fazą całego procesu wytwórczego. Jej celem jest: analiza wymagań oraz stworzenie całościowej koncepcji budowy oprogramowania. Podejmowane w tym czasie działania obejmują rozwinięcie modelu przypadków użycia i modelu dziedziny, określenie wymagań niefunkcjonalnych oraz opracowanie takiej architektury oprogramowania, która umożliwi spełnienie wszystkich zdefiniowany cli wymagań. W lej fazie prac następuje też wybór technologii realizacyjnej, która narzuca rodzaj dostępnych komponentów i mechanizmów ich integracji. Najważniejsze wyniki fazy opracowania, weryfikowane i zatwierdzane na jej końcu w punkcie kontroli architektury (Lijecycle Architecture), obejmują: ■ model przypadków użycia, opisujący wszystkie znane wymagania funkcjo nalne; ■ model dziedziny, opisujący dane gromadzone w systemie; * specyfikację ograniczeń i wymagań niefunkcjonalnych; ■ model architektury, opisujący sposób realizacji wymagań; ■ ■ " ■ ■
prototypy; scenariusze testowania akccptacyjnego; zaktualizowaną listę ryzyk; zaktualizowany plan rozwoju oprogramowania; plan iteracji fazy konstrukcji.
Działania wykonywane w fazie opracowania koncentrują się na analizie wyma gań oraz analizie i projektowaniu rozwiązania. Analiza wymagań prowadzi do rozwi nięcia głównych i alternatywnych scenariuszy tych wszystkich przypadków użycia, które mogą znacząco wpłynąć na architekturę systemu (zwykle nie mniej niż 80% wszystkich przypadków użycia). Pozostałe przypadki użycia mogą być określone później, pozostawiając na razie użytkownikom pewien margines sw efc«}^m ożliw ość wprowadzania zmian. Analiza dziedziny zastosowania prowadzi do zbudowania mo delu danych i udokumentowania wymagań niefunkcjonalnych. Wyniki analizy umo żliwiają wybór odpowiedniej technologii implementacyjnej i zaprojektowanie archi tektury rozwiązania. W dużym systemie biznesowym projektowanie może obejmować opracowanie architektury oprogramowania aplikacyjnego oraz typowych podsyste mów, np. poczty elektronicznej, bezpieczeństwa, hierarchicznego archiwum itp. Szczegółowy zapis scenariuszy systemowych przypadków użycia dokładnie określa sposób komunikacji systemu z użytkownikami. Dysponując tak dokładnym opisem, można łatwo zbudować prototyp interfejsu użytkownika, pokazujący gra ficzny układ menu systemu, wygląd wszystkich ekranów oraz zakres informacji prezentowanych i wprowadzanych na poszczególnych ekranach. W najprostszym przypadku prototyp może mieć postać narysowanych przez grafika zrzutów ekranu.
4. M etody obiektow e
214
W bardziej wyrafinowanej postaci prototyp może być działającym programem, napi sanym np. w Javie z wykorzystaniem biblioteki Swing. Model przypadków użycia jest nie tylko opisem wymagań, ale też narzędziem planowania fazy konstrukcji. Oceniając model, użytkownik wskazuje jednocześnie względną ważność każdego z nich (priorytet) dla powodzenia całego projektu. Te decyzje użytkownika, motywowane względami biznesowymi, określają przebieg fazy konstrukcji w ten sposób, że przypadki użycia o wysokim priorytecie są implemento wane w pierwszej kolejności, a przypadki mniej ważne przechodzą do dalszych itera cji procesu. Taka kolejność prac sprzyja zapewnieniu stabilności rozwoju oprogramo wania w kolejnych iteracjach procesu. W przykładowym projekcie oprogramowania systemu bibliotecznego do wyni ków fazy opracowania należą artefakty opisane w podrozdziałach 4.3 i 4.4 oraz pro jekt architektury oprogramowania opracowany w podrozdziale 4.5 i punkcie 4.6.2. Plan rozwoju oprogramowania może określać podział fazy konstrukcji na dwie dziesięciotygodniowe iteracje oraz wyodrębniać w fazie przekazania dwutygodniowy okres testowania akceptacyjnego, dwutygodniowy okres instalacji i strojenia systemu, a także równolegle szkolenie pracowników biblioteki. Każda iteracja fazy konstrukcji kończy się dostawą działającej wersji oprogramowania, realizującej funkcjonalność określoną przez następujące przypadki użycia. Ite ra c ja 1 FU1. FU 2. FU8. FU9. FU10.
P rz e g lą d a n ie k a ta lo g u R e je s tra c ja re z e rw a c ji R e je s tra c ja w y p o ż y c z e n ia O d c z y ta n ie k o d u k r e s k o w e g o R e je s tra c ja z w ro tu
Ite ra c ja 2 FU3. FU4. FU S . FU6. FU7. FU 11.
R e je s tra c ja o c z e k iw a n ia L o g o w a n ie c z y te ln ik a P rz e g lą d a n ie k o n ta U s u n ię c ie re z e rw a c ji U s u n ię c ie o c z e k iw a n ia R e je s tra c ja o p ła ty
1 Zaproponowany tu sposób podziału implementacji oprogramowania prowadzi do powstania już w pierwszej iteracji systemu o pewnej wartc|«ci biznesowej, który może być sprawdzony podczas próbnej eksploatacji i wykorzystany do szkolenia obsługi biblioteki. Celem podziału modelu przypadków użycia nie jest tu modularyzacja systemu. Funkcja Usunięcie rezerwacji (druga iteracja) jest ściśle związana z funkcją Rejestracja rezerwacji., przypisaną do pierwszej iteracji. Integracja produktów obydwu iteracji może więc wymagać refaktoryzacji wcześniej wytworzonego kodu.
4.7. Proces RU P -A----------------------
215
4.7.3. Faza konstrukcji Faza konstrukcji jest przede wszystkim okresem wykonania oprogramowania, w którym prace koncentrują się na projektowaniu, implementacji, testowaniu i inte gracji wszystkich komponentów programu. W tej fazie następuje też rozwinięcie brakujących przypadków użycia, uzupełnienie pominiętych szczegółów projektu, napisanie programów i skryptów konfiguracyjnych oraz przygotowanie testów. Kolej ną czynnością jest integracja bieżącej wersji oprogramowania oraz testowanie i po prawianie wszystkich wykrytych błędów. Równolegle z programami powstaje dokumentacja obejmująca podręczniki użytkownika i administratora. ’ Ze względu na iteracyjny sposób wykonania fazy konstrukcji wszystkie czynno ści są wykonywane wielokrotnie, w stosunku do kolejnych, coraz obszerniejszych wersji programu. Najważniejsze wyniki fazy konstrukcji, weryfikowane i zatwier dzane na jej końcu w punkcie kontroli zdolności operacyjnej oprogramowania (Initial Operalional Capability), obejmują: ■ * ■ ■ ■
działającą wersję oprogramowania; pełny model projektowy i implementacyjny wszystkich komponentów; pełny projekt danych (bazy danych); pliki źródłowe i konfiguracyjne; wstępną wersję podręczników użytkownika, opartą na scenariuszach przypad ków użycia; ■ pełny zestaw scenariuszy i przypadków testowych oraz raporty testowania; ■ plan fazy przekazania. Faza konstrukcji pochłania na ogól dwie trzecie zasobów i połowę czasu trwania projektu. Duża koncentracja zasobów w stosunkowo krótkim czasie wynika z możli wości równoległego prowadzenia prac nad wieloma komponentami przez niezależ nych ludzi lub zespoły. Faza konstrukcji jest zwykle okresem największego wysiłku i najwyższego zatrudnienia po stronie wykonawcy. Główny wysiłek kierownictwa projektu jest zwrócony na terminowe wytworzenie produktu o odpowiedniej jakości przy użyciu jak najmniejszych zasobów. W przykładowym projekcie oprogramowania systemu bibliotecznego czynności wykonywane w fazie konstrukcji są przedstawione - w zakresie ograniczonym do budowy modelu oraz implementacji komponentów - w punktach 4.5.4 i 4.6.3. Plan fazy przekazania może obejmować określenie osób odpowiedzialnych za przygotowa nie docelowego środowiska pracy systemu, harmonogram i sposób przeprowadzenia testowania akceptacyjnego (lub etapu testów beta), plan szkoleń oraz zakres i sposób dostawy finalnej wersji produktu. Jeśli wytworzone oprogramowanie ma być przeka zywane zleceniodawcy w sposób przyrostowy - np. przekazaniu podlega każda wersja
216
4. M etody obiektow e
4.8. Uw agi bibliograficzne
217
oprogramowania wytworzona w kolejnych iteracjach fazy konstrukcji - to plan prze kazania musi być przygotowany w każdej iteracji.
4 .8 .
Poza zakresem przykładu pozostaje problem przygotowania i przeprowadzenia testów, opisany w rozdziale 5, oraz opracowania dokumentacji użytkownika i admini stratora.
Bardzo dobry, choć krótki, przegląd języka UML oraz opis jego użycia w projekcie obiektowym podaje [57]. Bardziej kompletny opis stosowania metod obiektowych można znaleźć w książkach [56, 2, 3],
4 .7 .4 . Faza p rze k a za n ia Faza przekazania jest częścią wdrożenia systemu, obejmującą te działania, które są widoczne dla wykonawcy oprogramowania. Podstawowym celem fazy przekazania jest zatwierdzenie oprogramowania i upewnienie się, że jest gotowe do użycia przez użytkowników końcowych. Prace koncentrują się na testowaniu oprogramowania w docelowym s'rodowisku pracy, dostrajaniu jego wydajności i ergonomii do potrzeb użytkowników, szkoleniu użytkowników i konserwatorów oraz przygotowaniu nośni ków podlegających przekazaniu do klienta. Najważniejsze wyniki fazy przekazania, weryfikowane i zatwierdzane na jej końcu w punkcie kontroli wydania produktu (Product Relecise), obejmują: ■ wyniki testów akceptacyjnych; ■ handlową postać produktu, np. na nośnikach zewnętrznych lub na portalu centrum dystrybucji; D dokumentację instalacji oraz dokumenty wydania (release notes); ■ zaktualizowany komplet podręczników użytkownika i administratora; “ materiały pomocnicze, takie jak demo, systemy pomocy, przewodniki użyt kownika i konserwacji. Zarówno sposób wykonania, jak i złożoność działań wykonywanych w fazie przekazania istotnie zależą od charakteru przekazywanego do eksploatacji oprogra mowania. W przypadku programów ogólnodostępnych, przeznaczonych dla maso wego nabywcy, faza przekazania jest na ogół stosunkowo prosta. Obejmuje testowanie przez dystrybutorów i wybranych użytkowników (testy bettt), szkolenie pracowników odpowiadających za konserwację oprogramowania oraz/ przekazanie programów i dokumentacji dystrybutorom. ] W przypadku oprogramowania wielkich systemów budowanych na zamówienie, takich jak np. system ubezpieczeń społecznych lub system|kontrołi powietrznej kraju, faza przekazania jest złożona i długotrwała. Najważniejsze działania obejmują tu instalację w docelowym środowisku pracy, testowanie akceptacyjne z wykorzystaniem rzeczywistych danych systemu produkcyjnego, masowe szkolenie użytkowników, próbną eksploatację równolegle z działaniem dotychczasowego systemu, przeniesienie danych z dotychczasowego systemu i na końcu przejęcie całości pracy przez wdrażany system.
U w ag i b ib lio g ra fic z n e
M etody obiektowe. Trudno dziś mówić o różnych metodach obiektowych w ta leim sensie, w jakim opisuje się metody strukturalne. W okresie burzliwego rozwoju metodyki obiektowej, w latach dziewięćdziesiątych XX wieku, na rynku istniało kilkadziesiąt różnych metod wykorzystujących różne notacje modelowania. Dość szybko wyłoniły się z tego natłoku trzy komplementarne podejścia: Object Oriented Analysis and Design (OOAD - G. Booch [64]), Object Modeling Technique (OMT J. Rumbaugh [74]) i Object Oriented Software Engineering (OOSIi - I. Jacobson |66|). Z połączenia tych metod powstał najpierw zunifikowany język modelowania UML [76, 77], a następnie iteracyjny proces projektowy RUP [13, 19], który - dzięki pracom P. Kruchtena i S. Amblera - wyewoluował w skalowalną metodykę rozwoju oprogramowania [9, 10, 63]. Zarówno język UML, jak i podejście RUP zostały po wszechnie zaakceptowane przez rynek 1T. Metodyka RUP definiuje proces, określający ogólne ramy projektu, działania (actviti.es), które muszą być wykonane, artefakty (artifacts), które muszą powstać w ich wyniku, oraz role łudzi (roles) zaangażowanych w wykonanie projektu [18]. M odelow anie procesów biznesowych. Pojęcie procesu biznesowego narodziło się w naukach o zarządzaniu jako narzędzie opisywania sposobów organizowania działań przedsiębiorstw [238, 240, 242, 244, 245]. Inżynieria oprogramowania prze jęła ten sposób opisywania działań w dziedzinie zastosowania i wykorzystuje modele procesów biznesowych, przede wszystkim podczas analizy strategicznej, w analizie wymagań i podczas prac audytorskich. Przedstawiona w tej książce notacja diagramów czynności nie jest jedynym sposobem opisywania procesów biznesowych. Inną szeroko rozpowszechnioną notacją, dominującą w środowiskach biznesowych, jest BPMN (Business Process Modeling Notation) [246, 239, 241]. W łasną notację ma również popularna metoda i narzędzie Aris [247]. Za język modelowania procesów biznesowych można też uznać język BPEL (Business Process Execution Language), rozwijany jako-narzędzie opisu architektury usługowej SOA [243]. Przypadki użycia. Znakomitym podręcznikiem budowania i dokumentowania modelu przypadków użycia jest [54]. Solidny opis tego modelu oraz jego roli w pro jekcie obiektowym można znaleźć w [71, 73].
218
4. M etody obiektow e
Analiza nicwrażliwości. Opisana w punkcie 4.5.3 technika projektowania opro gramowania przez wydzielenie obiektów granicznych, encyjnych i kontrolerów zo stała opracowana przez Jacobsona jako element metody Objectory [66]. Rozwinięta w innych pracach, np. [65, 72], zyskała dużą popularność pod angielską nazwą robust, ness analysis. Kluczowy diagram metody - robustness diagram - byl początkowo odmianą diagramu komunikacji, obrazującego komunikacyjne powiązania obiektów Z czasem wyewoluował w diagram klas, na którym asocjacje oznaczone stereotypem «communicate» wyrażają możliwość komunikacji obiektów powiązanych klas a asocjacje ze stereotypem «subscribe» wyrażają możliwość notyfikowania obiektów klasy źródłowej przez obiekty klasy docelowej tej asocjacji. Odpowiednie stereotypy klas i asocjacji były włączone - jako profil Objectory - do standardu UML aż do wersjjJL4j_ W wersji UML 2.0 profil usunięto, lecz sama technika pozostała na rynku używana samodzielnie lub jako element niektórych metod, np. Select [56] lub Iconix [71]. ' , Wzorce projektowe. Pod tą nazwą kryją się sprawdzone, zbadane i udokumen towane konstrukcje architektury programu umożliwiające rozwiązanie pewnych typowych problemów projektowych. Nazwa pochodzi z fundamentalnego, w tym zakresie, dzieła [82], wydanego oryginalnie pod tytułem Design Patterns: Elements of Reusable Object-Oriented Software w 1995 r. Poznawanie wzorców projektowych można uznać za naukę dobrych, inżynierskich standardów projektowych. Szereg wzorców architektonicznych, opisujących architekturę na różnych poziomach abstrak cji, można znaleźć w licznych już dziś książkach [80, 81, 79, 84] oraz w Internecie. Technologie obiektowe. Być może jednym z powodów braku wyraźnego zróż nicowania metod obiektowych jest szybki rozwój technologii CASE, które z jednej strony oferują potężne wsparcie i gotowe rozwiązania wielu typowych problemów, a z drugiej - ograniczają i wymuszają pewien sposób działania projektanta. W tej sytuacji ciężar prac koncepcyjnych w trakcie projektu przesuwa się w stronę modelo wania wymagań, wybierania technologii realizacyjnej i projektowania architektury na wysokim poziomie abstrakcji. Konkretne rozwiązania niskiego poziomu wynikają z właściwości technologii. Dwie wiodące technologie opiektowe obejmują Enterprise Java Beans EJB 3.0 [78] oraz promowaną przez Microsdft technologię .NET [86, 83]. Poza książkami istnieje ogromna liczba darmowych źródle! w Internecie. Jest też sporo darniowych narzędzi wspomagających. Architektura sterowana modelem (M odel Driven Architecture - MDA). Pod tą nazwą kryje się otwarty nurt badawczy rozwijający pod auspicjami OMG koncepcję transformacyjnego wytwarzania oprogramowania w drodze budowania i przekształca nia kilku poziomów modeli. Są to: niezależny od realizacji (np. ręcznej lub automa
48. Uwagi bibliograficzne - — ---------------------
219
tycznej) model biznesowy (Computation Independent M odel - CIM), niezależny od konkretnej technologii implementacyjnej model analityczny (Platform Independent Model - PIM), dostosowany do konkretnej technologii model projektowy (Platform Specific Model - PSM). Ta atrakcyjna intelektualnie koncepcja nie ma na razie zbyt wielu osiągnięć praktycznych. Trudno też nie doszukać się w niej odniesienia do strukturalnej koncepcji rozdzielenia abstrakcyjnego modelu analitycznego od konkret nego modelu projektowego. Zainteresowany czytelnik może znaleźć informacje na ten temat w Internecie, przede wszystkim [248], oraz w licznych książkach, np. [68, 69].
5 J . Poziom y testow ania
2 21
już wykonanych testów po każdej zmianie poddanego testom programu. Takie powta rzane testy, których celem jest upewnienie się, że pomimo dokonanych zmian pro gram nadal działa, są nazywane testami regresji. Zaniechanie testów regresji może doprowadzić do pozostawienia błędów w działaniu programu. T e sto w a n ie o p ro g ra m o w a n ia je s t zło żo n y m
p ro cesem , p o ch ła n ia ją c y m
w iele
czasu i z a so b ó w o ra z w y m a g a ją c y m sta ra n n e g o p rz y g o to w a n ia . D la te g o ró żn e d z ia ła
Testow anie oprogram ow ania
nia zw ią z a n e z testo w an iem w y stę p u ją w ró żn y ch fazach p ro cesu w y tw ó rczeg o . P odstaw ow e d z iałan ia o b e jm u ją p rz y g o to w a n ie p lan u testó w , z a p ro je k to w a n ie p rz y padków testo w y ch , p rz y g o to w a n ie śro d o w isk a testo w eg o , testo w an ie, o c e n ę w y n ik ó w i usunięcie b łęd ó w w d z ia ła n iu p ro g ram u .
5 .1 . Testowanie jest procesem eksperymentalnego badania programu lub jego kompo nentu, polegającym na próbnym wykonywaniu w znanych warunkach, rejestrowaniu wyników i ocenianiu na ich podstawie właściwości tego programu lub komponentu. Przedmiotem oceny może być poprawność wytwarzanych przez program wyników, wydajność lub szybkość obliczeń albo inne właściwości określone w specyfikacji wymagań. Aby uzyskać gwarancję prawidłowego zachowania w każdej sytuacji, należałoby sprawdzić działanie programu dla wszystkich możliwych wartości danych wejścio wych. Astronomiczna liczba możliwych wartości danych, które w dodatku mogą być wprowadzane w różnej kolejności i w różnym czasie, sprawia,, że takie pełne spraw dzenie programu jest niemożliwe do wykonania. Dlatego w praktyce zastępuje się pełne sprawdzenie programu pewną liczbą eksperymentów polegających na wprowa dzeniu wybranych wartości danych wejściowych i porównaniu otrzymanych wyników z oczekiwaniami. Każdy eksperyment, który można opisać w kategoriach wartości wprowadzanych danych, akcji wykonywanej przez użytkownika i oczekiwanych wyników, jest nazywany przyp ad k iem testow ym (test case). s
P o z io m y te s to w a n ia
Podstawowym celem testowania jest znalezienie i usunięcie błędów w działaniu programu. Każdy błąd (error), czyli objaw błędnego działania programu ujawniony podczas testów, świadczy o jakim ś defekcie (fault) znajdującym się w kodzie testo wanego programu. Znalezienie tego defektu na podstawie zaobserwowanych objawów błędu jest tym trudniejsze, im dłuższa droga dzieli miejsce defektu od miejsca ujaw nienia się błędu. Aby skrócić tę drogę i ułatwić lokalizowanie defektów, można roz począć testowanie jeszcze przed integracją całości oprogramowania i testować naj pierw poszczególne jednostki programu, potem ich współdziałanie, a na końcu działanie całego systemu. Przyjęcie takiej organizacji tworzy kilka poziomów testo wania, przeznaczonych na ocenę różnych właściwości i różnych aspektów działania oprogramowania.
Liczba przypadków testowych oraz sposób doboru wartości danych mają decy dujący wpływ na jakość i wiarygodność procesu testowania. Dlatego ważną czynno ścią poprzedzającą etap testowania jest projektowanie tes|iw , mające na celu określe nie takiego zestawu przypadków testowych, który umożliwi efektywne sprawdzenie wszystkich aspektów poprawności programu w ograniczonym czasie. Wykonanie pewnego zestawu testów nie jest czynnością jednorazową. Każda zmiana ju ż przetestowanego fragmentu programu, związana z poprawianiem ujawnio nych błędów lub z ulepszaniem jego funkcji, może wprowadzić nowe błędy lub do prowadzić do ujawnienia się błędów istniejących od dawna, lecz niewidocznych w poprzedniej wersji programu. Dlatego dobrą praktyką jest powtarzanie wszystkich
Rysunek 5.1. M odel V procesu testow ania oprogram ow ania
222
5. T esto w an ie oprogram ow ania
5 1. Poziom y testow ania J Ą — -----------------------------
223
Model procesu testowania, pokazany na rys. 5.1, przedstawia kolejność (linie ciągle) oraz związki (linie przerywane) poziomów testowania z etapami lub działa niami procesu rozwoju oprogramowania. Dobrą praktyką inżynierską jest projektowa nie zestawu testów w tej fazie rozwoju, w której są rozważane te aspekty oprogramo wania, które będą podlegać testowaniu. Praktyka dowodzi, że opracowanie koncepcji testowania sprzyja lepszemu zrozumieniu i większej jednoznaczności sformułowania wymagań.
¿godności ich działania ze specyfikacją wynikającą z projektu architektury oprogra mowania. Celem testów jest sprawdzenie funkcjonowania interfejsów - sposobu wywoływania usług i przekazywania argumentów, postaci zwracanych rezultatów, ¿godności jednostek miary używanych we współpracujących jednostkach, zgodności wyjątków zgłaszanych w jednej, a obsługiwanych w innej jednostce itp. Wszystkie wykryte błędy są usuwane, a cały proces trwa aż do zintegrowania i przetestowania działania całości oprogramowania.
T e s to w a n ie je d n o s tk o w e
Projekt architektury oprogramowania powstaje w procesie kaskadowym w po czątkowej części fazy projektowania. W procesie iteracyjnym projekt taki powstaje fazie opracowania i podlega uszczegółowieniu podczas konstrukcji oprogramowa nia. Wraz z opracowywaniem architektury powinien też powstać plan testowania integracyjnego. W ykonanie czynności integracji i testowania programu tworzy na ogól osobny etap działań, wykonywany po zakończeniu implementacji: całości - w proce sie kaskadowym, lub części - w procesie iteracyjnym. Testow anie'm ogą przeprowa dzać deweloperzy lub wyspecjalizowany zespół testujący.
Przedmiotem testowania jednostkowego (unit testing, module testing) są podstawowe jednostki programu opisane w projekcie szczegółowym. Postać tych jednostek zależy od technologii implementacji - mogą być nimi podprogramy (procedury, funkcje) napisane w języku strukturalnym, skrypty SQL albo metody lub klasy zapisane w języku obiektowym. Celem testowania na tym poziomie jest: sprawdzenie zgodności działania wszystkich opracowanych jednostek z;-ich specyfikacją, wynikającą z pro jektu, oraz wykrycie i usunięcie jak największej liczby błędów. Szczegółowy projekt programu powstaje w procesie kaskadowym w końcowej części fazy projektowania. W procesie iteracyjnym projekt taki powstaje w każdej iteracji fazy konstrukcji i dotyczy tej części oprogramowania, która jest budowana w bieżącej iteracji. W tym też czasie powinny zostać zaplanowane testy jednostkowe. Sposób realizacji testowania jednostek zależy od wymaganej niezawodności pro gramu. W tych zastosowaniach, w których wymagania są wysokie, testowanie jed nostkowe tworzy odrębny etap procesu wytwórczego, wykonywany przez niezależny zespól testujący. W pozostałych przypadkach testowanie jednostkowe realizują na ogól deweloperzy, którzy opracowali testowane programy, a czynności testowania nakładają się na okres implementacji programów. Problemem tego poziomu testowania jest zależność testowanej jednostki od in nych jednostek programu, które np. wywołują testowany podprogram albo są przez niego wywoływane. Przeprowadzenie testów wymaga w takim przypadku użycia specjalnego oprogramowania wspomagającego albo opracowania sterowników testo wych, wywołujących badaną jednostkę z odpowiednimi argumentami, oraz namiastek, symulujących działanie brakujących jednostek wywoływanych. Przygotowane w ten sposób środowisko testowania powinno być zachowaiie i wykorzystane do testów regresji - po poprawkach związanych z usuwaniem blędpw oraz później, po zmianach wprowadzanych w kolejnych wersjach programu. T e s to w a n ie in te g ra c y jn e Połączenie dwóch współdziałających jednostek tworzy nową jednostkę, w której ujawniają się błędy związane z niedopasowaniem mechanizmów ich współpracy. Przedmiotem działań podejmowanych podczas testowania integracyjnego (interface testing) jest łączenie jednostek programu w coraz większe komponenty i sprawdzanie
Proces integracji programu może przebiegać w różny sposób. W metodzie „wiel kiego wybuchu” zakłada się złożenie wszystkich jednostek oprogramowania i testo wania od razu całości. Mankamentem tego podejścia jest trudność lokalizowania ujawnianych błędów. Doświadczenie pokazuje, że nakładające się na siebie wielo krotne błędy potrafią maskować swoje istnienie, sumować się w dziwny sposób lub wykazywać objawy sugerujące błędy w zupełnie innych częściach programu. Dlatego częściej stosowana - zwłaszcza w dużych projektach - jest metoda stopniowej inte gracji i testowania coraz większych grup jednostek, prowadząca na końcu do zbudo wania całości systemu. .Stopniową integrację programu można prowadzić w sposób wstępujący lub zstę pujący. Strategia wstępująca zaczyna od łączenia jednostek najniższego poziomu w większe komponenty, te w jeszcze większe aż do osiągnięcia poziomu całego progra mu. Zaletą takiego podejścia jest zredukowanie liczby koniecznych do opracowania namiastek - w każdym kroku zarówno testowany komponent, jak i wszystkie wywoływane przez niego podprogramy są już dostępne. Wadą jest brak dostępności interfejsu użytkownika, ulokowanego często w głównej części programu, w począt kowych krokach integracji. Strategia zstępująca przebiega w odwrotnym kierunku. Do programu głównego dołącza się podprogramy wywoływane, aż do poziomu najprost szych jednostek. Ta strategia wymaga opracowania większej liczby namiastek, ale w zamian zapewnia dostęp do interfejsu użytkownika od samego początku. W większości praktycznych przypadków testowanie integracyjne przeprowadza się stopniowo, łącząc elementy strategii zstępującej i wstępującej. Strategię jednoczes nej integracji całości stosuje się bardzo rzadko.
224
5. T estow anie oprogram ow ania
T e s to w a n ie s y s te m o w e Przedmiotem testowania systemowego (system testing) jest całość oprogramowania zintegrowana i zainstalowana w odpowiednim środowisku wykonawczym. Celem testów jest sprawdzenie zgodnos'ci sposobu działania wszystkich funkcji oprogramo wania ze specyfikacją oraz weryfikacja innych właściwości systemu określonych przez wymagania niefunkcjonalne. W iarygodność wyników testów wymaga, aby środowisko testowe było jak najbardziej zbliżone do przewidywanego środowiska pracy oprogramowania. Konstrukcja testów traktuje system jako całość i nie jest nastawiona na wnikanie w jego budowę. Specyfikacja oprogramowania określająca dokładnie, co oprogramowanie ma ro bić i w jakim zakresie (wydajność, niezawodność itp.), powstaje w procesie kaskado wym w fazie analizy. W procesie iteracyjnym dokładna specyfikacja funkcji oraz właściwości niefunkcjonalnych powstaje w fazie opracowania. Jeśli projekt jest pro wadzony z użyciem metod obiektowych, to rolę specyfikacji funkcji oprogramowania może pełnić systemowy model przypadków użycia. Wraz ze specyfikowaniem wyma ganego zachowania systemu powinien też powstać plan jego testowania. Przeprowa dzenie testów systemowych, możliwe dopiero po zakończeniu integracji oprogramo wania, tworzy osobny etap procesu wytwórczego. Zaprojektowanie i wykonanie testów nie wymaga znajomości szczegółów konstrukcji oprogramowania, wymaga natomiast specjalistycznej wiedzy dotyczącej sposobów sprawdzania właściwości niefunkcjonalnych. Z tego powodu etap testowania systemowego realizuje zazwyczaj wyspecjalizowany zespól testujący. Wykryte błędy i niezgodności ze specyfikacją są opisywane w raporcie problemów testowania i przekazywane deweloperom do usu nięcia. Etap testowania systemowego składa się zwykle z szeregu odrębnych kroków, w których sprawdzane są róże aspekty działania systemu. Szczegółowy wykaz testów zależy od dziedziny zastosowania i specyfikacji wymagań. Typowe przykłady testów systemu obejmują: B testy funkcjonalne (functional testing), obejmujące sprawdzenie poprawności wykonania wszystkich funkcji systemu (np. systemowych przypadków użycia); ■ testy wydajnościowe (performance testing), ohpjmujące sprawdzenie działa nia systemu (np. czasu przetwarzania) przy nominalnym obciążeniu; ■ testy przeciążeniowe (stress testing), sprawdzające zachowanie systemu w warunkach przekroczenia założonego obciążenia systemu; ■ testy bezpieczeństwa (security testing), których celem jest sprawdzenie sku teczności mechanizmów ochrony systemu przed nieuprawnionym użyciem; ■ testy odporności (recovery testing), sprawdzające działanie oprogramowania w warunkach awarii, np. nagłego wyłączenia, restartu komputera łub odłącze nia sieci;
5,1. Poziom y testow ania
»
225
testy z g o d n o ści ( compatibility testing), sp ra w d zające m o ż liw o ść p racy o p ro g ra m o w a n ia na ró żn y ch p latfo rm ach (np. ró żn e sy stem y o p e ra c y jn e lub bazy d an y c h itp.);
■ testy d o k u m en tacji ( documentation testing), o b e jm u ją c e sp ra w d z e n ie zg o d n o ści d z iałan ia o p ro g ra m o w a n ia z o p isem z aw arty m w d o k u m en tacji.
Testowanie akceptacyjne T estow aniu a k c e p tacy jn em u ( acceptance testing) p o d le g a o p ro g ram w tui sta n o wiące p rze d m io t d o staw y d la u ży tk o w n ik a, zain sta lo w a n e w d oce]o$ynT ~ 7t d ow isku pracy lub w śro d o w isk u im itu jący m d o c e lo w e śro d o w isk o p racy o p ro g ram o w an ia. Celem testó w jest sp ra w d z e n ie zg o d n o ści d z ia ła n ia z w y m ag an ia m i i p otrzebam i użytkow nika. F o rm a testó w m oże być p o d o b n a do testów sy ste m o w y c h , jed n ak pro ces testow ania nie je s t już zo rie n to w a n y na zn ajd o w a n ie i u su w a n ie d efek tó w , lecz raczej na zad em o n stro w an ie i z a tw ie rd zen ie p ro d u k tu p rz e z u ży tk o w n ik a o ra z ew en tu aln e dostrojenie d o je g o rz e c z y w isty c h potrzeb.
Teoretycznie testy akceptacyjne powinien zawsze przeprowadzać użytkownik. W praktyce jednak testy akceptacyjne przeprowadza często wykonawca pod bezpo średnim nadzorem użytkownika łub zewnętrznej firmy działającej na jego zlecenie. W takim przypadku użytkownik zatwierdza najpierw scenariusze testowania, a później kontroluje wiarygodność przeprowadzenia testów. Jeśli zostaną wykryte błędy lub niezgodności ze specyfikacją wymagań, to są one opisywane w raporcie problemów i usuwane w określonym umową terminie. W przypadku systemów ogólnodostępnych, które nie są przeznaczone dla kon kretnego odbiorcy, testowanie akceptacyjne może przybrać formę kontrolowanej eksploatacji w siedzibie wytwórcy (testy alfa) oraz u wytypowanych odbiorców lub dystrybutorów produktu (testy beta). Błędy i niezgodności wykryte podczas obu faz testów są raportowane do wytwórcy i usuwane przed ostatecznym wypuszczeniem produktu na rynek. Specyfikacja wymagań użytkownika, zapisana w umowie na opracowanie opro gramowania, jest zwykle zbyt mało dokładna, aby określić sposób testowania akceptacyjnego. Dokładniejsza wersja specyfikacji jest wynikiem analizy wymagań dokona nej już po zawarciu umowy lub podjęciu decyzji o opracowaniu oprogramowania. Jeśli projekt jest prowadzony z użyciem metod obiektowych, to rolę specyfikacji wymagań, prezentującej biznesowy punkt widzenia użytkownika, może pełnić bizne sowy model przypadków użycia. Scenariusze biznesowych przypadków użycia są naturalnymi kandydatami na scenariusze testowania akceptacyjnego. Wraz z opra cowaniem modelu biznesowych przypadków użycia powinien też powstać plan testo wania akceptacyjnego. Etap testowania akceptacyjnego dzieli się zwykle na kilka odrębnych kroków, w których sprawdzane są róże aspekty jego działania, np.:
T 226
5. T estow anie oprogram ow ania
■ testy funkcjonalne, sprawdzające dopasowanie funkcji systemu do potrzeb ■y - p r o cesów biznesowych użytkownika; * testy operacyjne, sprawdzające działanie funkcji wykorzystywanych przez administratorów systemu; n testy niefunkcjonalne, podobne lub identyczne z testami systemowymi.
5 .2 ,
O rg a n iz a c ja p ro c e s u te s to w a n ia
Skuteczne przeprowadzenie testów i usunięcie błędów oprogramowania wymaga zwłaszcza w dużym projekcie - całego szeregu działań przygotowawczych, związa nych z planowaniem, projektowaniem i wykonaniem testów. Wynikiem tych działań są odpowiednie dokumenty planistyczne, specyfikacje testów i raporty testowania. Przygotowane tych dokumentów i wdrożenie ich w praktyce jest przedmiotem procesu zarządzania testowaniem, które wchodzi w skład procesu zarządzania projektem programistycznym. Nie ma jednej standardowej organizacji procesu testowania i jednego standardo wego sposobu dokumentowania tego procesu. Różne metody zarządzania projektami, a nawet różne projekty, stosują własne rozwiązania, które w dużej mierze są pochodną wie!kos!ci projektu, konsekwencji ewentualnej awarii oprogramowania i posiadanego budżetu. W małych, kilkuosobowych, projektach testowanie prowadzą często dewelo perzy tworzący oprogramowanie. Proces testowania jest mało sformalizowany i ogra niczony do niezbędnego minimum. Zaletą takiego podejścia jest niski koszt, a w adąograniczony zakres testowania. W większych projektach testowaniem - zwłaszcza na wyższych poziomach - zajmują się niezależne zespoły testerów. Umożliwia to użycie lepszych metod i narzędzi, zapewnia bardziej wszechstronne i wiarygodne przeprowa dzenie testów, wymaga jednak poniesienia dodatkowych kosztów związanych z organizacją i formalnym dokumentowaniem całego procesu. Treść tego podrozdziału opisuje pewien model organizacji testowania, który wy znacza dominujący kierunek [176], ale od którego istnieją w praktyce liczne odstęp stwa. I
5 .2 .1 . P la n o w a n ie te s tó w
< i t r 1
W ymagania normy IEC 61508 dotyczące oprogram owania stosuje się do imple mentacji funkcji bezpieczeństwa, a jeśli oprogramowanie implementuje też inne funkcje, to do całego tego oprogramowania. Norma wymaga, aby metoda wybrana do projektowania oprogramowania ułatwiała zarządzanie złożonym projektem, umożli wiała opis funkcjonalności, przepływu danych między składnikami, struktury danych, przepływu sterowania oraz konfliktów dostępu i innych ograniczeń. Proces wytwórczy oraz procesy weryfikacji i zatwierdzania powinny przebiegać zgodnie z modelem V (podrozdział 5.1). Inne metody i techniki projektowe, zalecane (R), wysoce zalecane (HR) lub niezalecane (NR) przez tę normę, są wym ienione w lab. 10.2 i 10.3. Jak widać, norma zdecydowanie zaleca stosowanie metod analizy, projektowania i pro gramowania strukturalnego na wszystkich poziomach integralności bezpieczeństwa oraz niestosowanie metod i technik dynamicznych oraz wnoszących niepewność. Norma nie wspomina ani nie rekomenduje stosowania metod obiektowych. T abela 10.2. Zalecenia normy IEC 61508: metody projektowania architektury oprogramowania R y su n ek 10.5. D rzewo niezdatności reaktora z zabezpieczeniem SILI
SIL2
SIL3
S1L4
MR
HR
HR
HR
lub m e to d y p ó lfo rm a ln e (IE C 6 1 1 3 1 -3 )
R
R
11R
HR
lub m e to d y fo rm a ln e
-
R
R
HR
N a rz ę d z ia C A S E w s p o m a g a ją c e s p e c y fik a c ję
R
R
HR
HR
W y k ry w a n ie i d ia g n o z a d e fe k tó w
-
R
HR
HR
K o d y d e te k c y jn e i k o re k c y jn e
R
R
R
HR
P ły n n y u p a d e k
R
R
IIR
HR
K o re k c ja d e fe k tó w m e to d a m i s z tu c z n e j in te lig e n c ji
-
NR
NR
NR
R c k o n fig u ra c ja d y n a m ic z n a
-
NR
NR
NR
Technika/metoda
Podstawowym parametrem charakteryzującym pewność zabezpieczeń jest nienai uszalność bezpieczeństwa (safety inlegrity), określona jako prawdopodobieństwo zadowalającego wykonania funkcji bezpieczeństwa w razie potrzeby. Norma dyskretyzuje nienaruszalność bezpieczeństwa na czterech pozio)iiach (lab. 10.1), dla których formułuje rekom endacje dotyczące m.in. sposobów analizy i projektowania systemu. Określenie sytuacji, w których należy stosow ać zabezpieczenia o określonym pozio mie nienaruszalności bezpieczeństwa, powinno znaleźć się w normach branżowych konkretnych dziedzin zastosowania.
M e to d y s tru k tu ra ln e
376
J 0. S y stem y krytyczne
T a b e la 10.3. Zalecenia norm y IEC 61508: m etody projektow ania szczegółowego i im plem entacji
T e c h n ik a /m e to d a
S IL I
S IL 2
S IL 3
S1L 4
HR
HR
HR
HR
lub m e to d y p ó lfo rm a ln e (IE C 6 1 1 3 1-3 )
R
R
HR
HR
lu b m e to d y fo rm a ln e
-
R
R
HR
N a rz ę d z ia C A S E w sp o m a g a ją c e p ro je k to w a n ie
R
R
HR
HR
P ro g ra m o w a n ie s tru k tu ra ln e
HR
HR
HR
HR
P o d e jś c ie m o d u ło w e
HR
HR
HR
HR
R
HR
HR
HR
M e to d y s tru k tu ra ln e
B rak o b ie k tó w d y n a m ic z n y c h i s k o k ó w , o g ra n ic z o n e u ż y c ie p rz e rw a ń , w s k a ź n ik ó w i rc k u rsji
1 0 .3 . P ro je k to w a n ie s tru k tu ra ln e Metoda analizy i projektowania systemów wbudowanych, przedstawiona w tym podrozdziale, została opracowana przez P. W arda i S. Mellora [471jako rozszerzenie klasycznej metodyki strukturalnej o elementy umożliwiające precyzyjne definiowanie przepływu sterowania. M etoda wpisuje się w kaskadowy proces tworzenia oprogra mowania i obejmuje swym zasięgiem fazy analizy strategicznej i szczegółowej oraz projektu wstępnego i szczegółowego. W kolejno wykonywanych fazach procesu powstają standardowe modele strukturalne, przede wszystkim diagramy przepływu danych (rozdział 3), rozszerzone o przepływy i procesy sterujące. Te dodatkowe elementy wyróżnia się na diagramach linią przerywaną i definiuje za pomocą diagra mów' stanów, które można traktować jak wczesną wersję diagramów maszyny stano wej języka UM L (punkt 4 .4 .1).
1 0 .3 .1 . P ro c e s p ro je k to w y
;
Proces projektowy wspierany przez metodę W arda-M elłóra obejmuje pięć kroków, w których powstają kolejne modele programu. Dwa pierwsze kroki, których wynikiem jest model funkcjonalny, wypełniają fazę analizy. Trzy następne prowadzą do zbudo wania modelu implementacyjnego definiującego projekt systemu. Każdy z tworzo nych modeli opisuje budowany system w sposób kompletny na wybranym poziomie abstrakcji. M odel funkcjonalny pokazuje logikę działania i abstrahuje od techniki implementacji systemu. Model im plem entacyjny zachowuje logikę modelu funkcjo nalnego i uzupełnia ją o szczegółowy opis realizacji.
10.3. P ro jek to w an ie stru k tu raln e
3 77
_
M odel fu nkcjonalny (essential model) przedstawia koncepcję działania systemu. Składa się z dwóch elementów - tworzonych w dwóch następujących po sobie etapach - opisujących miejsce systemu w otoczeniu oraz sposób reagowania na zachodzące w tym otoczeniu zdarzenia. 1. Model otoczenia (environmental model) ustala granicę systemu z otoczeniem i określa zdarzenia, na które system musi odpowiadać. Elementem modelu otoczenia jest schemat kontekstu systemu. 2. Model zachowania (behavioral model) opisuje działania, wykonywane przez system w odpowiedzi na zdarzenia, oraz dane niezbędne dla realizacji tych działań. M odel im plem entacyjny (implementation model) przedstawia dokładnie tech nologie realizacji działań określonych w modelu funkcjonalnym. Składa się z trzech elementów - tworzonych w trzech następujących po sobie etapach - opisujących systematyczną dekompozycję działań między komputery systemu (jeśli jest ich kilka), współbieżne zadania wykonywane przez poszczególne komputery i sekwencyjne moduły wewnątrz programu każdego zadania. 1. Model procesorów (processor model) opisuje podział działań i danych między odrębne komputery systemu, współpracujące ze sobą za pom ocą łączy komu nikacyjnych, ale nieposiadające wspólnej pamięci, w której mogłyby znajdo wać się dane. 2. Model zadaii (task model) opisuje podział działań i danych każdego kompu tera systemu między współbieżne zadania, współdziałające z użyciem usług systemu operacyjnego i mające dostęp do wspólnej pamięci danych. 3. Model modułów (module model) opisuje strukturę, dane i przepływ sterowa nia wewnątrz programu sekwencyjnie wykonywanego zadania. Modele otoczenia, zachowania, procesorów i modułów uwzględniają możliwos'ć współbieżności wykonania działań i są budowane z wykorzystaniem notacji diagramu przepływu danych. Model modułów opisuje budowę sekwencyjnych programów zadań z wykorzystaniem notacji schematu struktury programu. .Struktury danych są przedstawiane przy użyciu diagramów encji. Dynamika systemu, związana z koniecz nością reagowania na zdarzenia, jest m odelowana za pomocą diagramów stanu. Silną stroną metody jest integralnie wbudowany proces weryfikacji poprawności rezultatów. Model funkcjonalny, który dość czytelnie opisuje sposób działania sys temu, może być oceniony i zatwierdzony przez ekspertów w dziedzinie zastosowania. Wszystkie dalsze modele nie są tworzone dowolnie przez projektanta, lecz powstają w drodze przekształcenia modelu poprzedniego, zgodnie z dość dobrze określonymi regułami. Każdy kolejny model podlega zatwierdzeniu, którego ważnym elementem jest porównanie z modelem poprzednim w celu znalezienia i uzasadnienia lub wyeli minowania wszelkich niezgodności.
10. S y stem y krytyczne
378
1 0 .3 .2 . B u d o w a m o d e lu fu n k c jo n a ln e g o Pierw otnym i dokumentami, które muszą być dostępne w chwili rozpoczynania analizy i projektowania systemu sterującego, są opisy instalacji sterowanej oraz wytyczne automatyki, określające wymagany sposób sterowania instalacją. Celem budowy modelu funkcjonalnego jest uściślenie i zbadanie tych wymagań oraz stworzenie koncepcji ich spełnienia. Techniki używane podczas budow ania modelu funkcjonalnego rozważymy na przykładzie systemu sterującego pracą rozlewni napojów, wyposażonej w zbiornik i cztery niezależne linie butelkowania. Każda linia (rys. 10.6) składa się z magazynu butelek, wyposażonego w śluzę otwieraną sygnałem impulsowym o długości 100 ms, transportera, wagi i zaworu napełniającego. Cykl napełniania butelki zaczyna się od otw arcia śluzy i przeniesienia zwolnionej butelki na platformę wagi. Po wykryciu butelki przez czujnik platformy transporter zatrzymuje się i otwierany jest zawór napełniający. Zawór należy zam knąć po zasygnalizowaniu przez wagę przekroczenia zadanej wartości ciężaru butelki. N apełniona butelka czeka teraz na usunięcie przez niezależny podajnik. Usunięcie butelki jest wykrywane przez czujnik wagi, którego wskazanie inicjuje nowy cykl pracy linii. System sterujący rozlewni ma sterować pracą wszystkich linii, kontrolować pH w zbiorniku i wstrzymywać pracę, jeśli jest za niskie, oraz wyświetlać stan instalacji dla dyspozytora. D yspozytor może zdalnie uruchomić albo zatrzymać pracę każdej
j 0.3. P ro je k to w an ie stru k tu raln e I_______________________
379
Û _______
■ schemat kontekstu (context schema), pokazujący obiekty współpracujące z systemem i definiujący w ten sposób granicę między systemem a jego oto czeniem; * lista zdarzeń (event list), opisująca wszystkie zdarzenia występujące w oto czeniu, na które system i jego oprogramowanie ma w pewien sposób odpo wiadać. Schem at kontekstu jest grafem przepływu danych, na którym cały system jest przedstawiony jako jeden proces, a jego otoczenie - instalacja sterowana - jest repre zentowane przez zbiór terminatorów, czyli obiektów dostarczających lub odbierającydh dane z systemu (rys. 10.7). Przepływy łączące system z terminatorami modelują przepływy danych. Model nie pokazuje zależności między terminatorami ani sposobu realizacji przepływów.
_ PH
Zbiornik
Wjąez/%lącz
- " "Bufela na wadze Butelka pełna
~~ Dyspozytor Instalacji
Stan instalacji
•
Linia butelkowania
O tw ó rz/za m kjjijJr ^ tS/UksT y /
a
STart-tianapuiJu_ Otwóp^liizę
linii. Rysunek 10.7. Schemat kontekstu .systemu sterującego pracą rozlewni napojów
J U
Najważniejszą decyzją podejmowaną podczas budowania schematu kontekstu jest wybór terminatorów, którymi mogą być obiekty instalacji sterowanej albo urzą dzenia sprzęgające system z otoczeniem. Na ogól lepszym wyborem jest pokazanie w modelu obiektów instalacji, a pominięcie konkretnych czujników i elementów wykonawczych. W ten sposób unika się wprowadzenia do modelu zależności od technologii realizacyj nej.
J L
CL
c l
Magazyn butelek Śluza
....:::
Transporter
T T
ZD
i Platforma wagi
~V G O twórz śluzę
W łącz transport
R B utelka naw adze
Butelka pełna
O twórz zaw ór
Rysunek 10.6. Linia butelkowania napojów M o d e l o to c z e n ia Pierwszy etap analizy koncentruje się na zbadaniu instalacji sterowanej. Wynikiem tych prac jest model otoczenia, w skład którego wchodzą dwa elementy, budowane w dowolnej kolejności:
Uzupełnieniem schematu kontekstu powinny być opisy przeznaczenia systemu, wymagań niefunkcjonalnych oraz struktury i objętości przepływów występujących na schemacie. Lista zdarzeń wylicza zdarzenia, czyli wszystkie sytuacje powstające w otocze niu, które wymagają zaplanowanej reakcji systemu. Pojęcie zdarzenia nie wiąże się ze sposobem przekazywania danych do systemu, lecz z naturą zjawisk zachodzących w otoczeniu. Na przykład, za zdarzenie należy uznać zarówno otrzymanie przez sys tem komunikatu z kom endą dyspozytora, jak i przekroczenie pH cieczy w zbiorniku, które nie jest sygnalizowane w żaden bezpośredni sposób, lecz jest wykrywane przez program porównujący zmierzoną wartość z zadanym progiem.
380
10. S y stem y krytyczne
Włączenie przez dyspozytora Wyłączenie przez dyspozytora pH niskie pH norma Przybycie butelki Usunięcie butelki Butelka pełna
-
dyspozytor włącza linię do pracy dyspozytor wyłącza linię z działania przekroczenie dopuszczalnego progu przez pH powrót pH do prawidłowej wartości ustawienie butelki na platformie wagi (czujnik R) usunięcie butelki z platformy wagi (czujnik R) napełnienie butelki (czujnik F)
Rysunek 10.8. Lista zdarzeń systemu sterującego pracą rozlewni napojów Opracowanie kompletnej listy zdarzeń jest krytycznym etapem projektu. Sposób jego wykonania zależy od przyjętej kolejności działań. Jeśli wcześniej został zbudo wany schem at kontekstu, to zdarzenia można odkryć, badając wszystkie przepływy wejściowe systemu (rys. 10.8). Jeśli schematu kontekstu jeszcze nie ma, to zdarzenia można odkryć, analizując zachowanie otoczenia i wyodrębniając wszystkie zmiany jego stanu - zarówno poprawne, jak i awaryjne. 1
10^3. P ro je k to w an ie stru k tu raln e
381
Tabela 10.4. Nieformalny opis reakcji na zdarzenia Z d a rz e n ie
R e a k c ja
W łą c z e n ie p rz e z d y s p o z y to ra
O d b lo k u j m o ż liw o ś ć sta rtu c y k lu p ra c y linii
W y łą c z e n ie p rz e z d y s p o z y to ra
Z a b lo k u j m o ż liw o ś ć p o n o w n e g o s ta rtu c y k lu p ra c y linii
pH n is k ie
Z a b lo k u j m o żliw o .ść p o n o w n e g o s ta rtu c y k lu p ra c y linii
pH n o rm a
O d b lo k u j m o ż liw o ś ć s ta rtu c y k lu p ra c y linii
P rz y b y c ie b u te lk i ( K )
W y łą c z tra n s p o rt ( T ) i o tw ó rz z a w ó r n a p e łn ia ją c y ( Z )
U su n ię c ie b u te lk i (->R )
J e ś li lin ia o d b lo k o w a n a , to w łą c z tra n s p o rt ( 7 ') i o tw ó rz ś lu z ę ( G ) J e ś li lin ia z a b lo k o w a n a , to n ie ró b n ic
B u te lk a p e łn a ( F )
Z a m k n ij z a w ó r n a p e łn ia ją c y ( Z )
M o d e l z a c h o w a n ia Drugi etap analizy ma za zadanie określenie reakcji systemu na wszystkie zdarzenia zachodzące w sterowanej instalacji i pokazanie sposobu przetwarzania danych wej ściowych w celu wypracowania takich reakcji. W ynikiem tej analizy jest model za chowania, na który składają się dwa elementy, budowane w dowolnej kolejności: ■ schemat transformacji (transformation schema), pokazujący działanie systemu w postaci grafu przepływu danych; B schemat danych (dala schema), opisujący struktury danych przenoszonych przez przepływy i przechowywanych w zbiorach istniejących wewnątrz sys temu. S ch em at tra n sfo rm a c ji jest grafem przepływu danych, przedstawiającym pro cesy przetwarzające dane wewnątrz systemu oraz przepływy danych między tymi procesami. Głównym zadaniem procesów przetwarzających jest wypracowanie odpo wiedniej reakcji na wszystkie zdarzenia zachodzące w otoczeniu. Dlatego pierwszym krokiem opracowania schematu transformacji jest identyfikacja tych reakcji i zapisa nie ich w nieformalnej postaci tabelarycznej (lab. 10.4). Lejwa kolumna tabeli zawiera kolejne zdarzenia z listy zdarzeń, w prawej kolumnie są W p is a n e reakcje systemu sterującego na te zdarzenia. j Reakcje systemu sterującego mogą prowadzić do powstawania w otoczeniu ko lejnych zdarzeń, na które system też musi ponownie zareagować. W ten sposób we wnętrzna logika działania instalacji sterowanej narzuca pewien porządek występowania zdarzeń i reakcji. Precyzyjnym sposobem uchwycenia i pokazania lego porządku jest narysowanie diagramu stanów, przedstawiającego wszystkie stany (tryby pracy) instala cji, zdarzenia powodujące przejścia między stanami oraz reakcje systemu (rys. 10.9).
Rysunek 10.9. Diagram stanów porządkujący zdarzenia i reakcje systemu sterującego pracą rozlewni napojów Pewnym problemem tego etapu modelowania może okazać się łączna liczba sta nów systemu. Można ją wydatnie zmniejszyć, dekom ponując cały diagram stanów na części komunikujące się za pomocą umownych sygnałów, które umożliwiają lub blokują pewne przejścia w grafie współpracującym. Zapis nie musi być ściśle for malny, gdyż celem tego etapu pracy jest czytelne pokazanie algorytmu działania, a nie pełna formalizacja modelu. Kolejnym krokiem analizy jest opracowanie grafu przepływu danych pokazują cego logikę działania systemu. Elementami tego modelu będą procesy sterujące, realizujące graf stanów, oraz procesy realizujące inne działania systemu, takie jak w tym przykładzie - kontrolowanie stanu pH lub wyświetlanie stanu instalacji dla dys-
382
10. S ystem y krytyczne
pozy lora (rys. 10.10). Następnym krokiem pracy jest rozwinięcie procesów przetwa rzających dane i przedstawienie ich działania w postaci hierarchicznego modelu, opisanego w rozdziale 3. Procesy sterujące nie podlegają hierarchizacji, a ich specyfi kacją są odpowiednie diagramy stanów (rys. 10.9).
10.3. Projektowanie strukturalne —& :-------------------------------
383
będący hierarchicznym schematem transformacji pokazującym na diagramie najwyż szego poziomu poszczególne procesory systemu, reprezentowane jako pojedyncze procesy. Na schematach niższego poziomu znajdują się procesy modelujące przetwa rzanie przypisane do konkretnego procesora. Podstawowymi kryteriami podziału modelu funkcjonalnego między różne procesory systemu są: * fizyczne rozmieszczenie instalacji sterowanej i pokoju sterowni oraz koszt komputerów i kanałów komunikacyjnych; * wymagania dotyczące specjalnych właściwości niektórych części systemu, ta kich jak niezawodność, potrzeba posiadania certyfikatów dopuszczających do > zastosowania lub wydajność wykonania określonych typów operacji; ■ częstotliwość wykonywania operacji - duża częstotliwość powtarzania pro stych operacji sugeruje celowość użycia urządzeń specjalizowanych.
R ysunek 10.10. Diagram przepływu .danych systemu sterującego pracą rozlewni napojów
S chem at d anych jest diagramem encji pokazującym obiekty danych przecho wywane i przepływające między procesami schematu transformacji. Sposób budowy diagramu encji byl dokładnie opisany w punkcie 3.1.3. W wielu systemach sterują cych model danych nie jest skomplikowany. W przykładowym systemie sterującym pracą rozlewni nie ma żadnych zbiorów, a przepływy między procesami można opisać w słowniku danych, określając dla każdego z nich przeznaczenie, typ danych i zakres wartości.
1 0 .3 .3. B ud ow a m odelu im p le m e n ta c y jn eg o Model funkcjonalny przedstawia najważniejsze działania (procesy) systemu, pokazuje zależności przyczynowo-skutkowe między tymi działaniami oraz opisuje ich interfejs na poziomic rodzaju przekazywanych między nimi danych. Model implementacyjny ma opisać sposób realizacji przetwarzania przez system komputerowy, który - w razie potrzeby - może składać się z wielu komputerów ł urządzeń specjalizowanych. Opro gramowanie komputerów może obejmować wiele zadań, wykonywanych współbież nie pod nadzorem wielozadaniowego systemu operacyjnego). Budowa modelu imple mentacyjnego obejmuje trzy kroki, w trakcie których nasjępuje stopniowy podział modelu funkcjonalnego między komputery, zadania i moduły programu. M o d e l p ro c e s o ró w Pierwszym krokiem pracy jest ustalenie sprzętowej struktury systemu i przypisanie procesów modelu funkcjonalnego do poszczególnych procesorów, tzn. komputerów lub urządzeń specjalizowanych wchodzących w skład systemu i wykonujących okre ślony rodzaj przetwarzania danych. Wynikiem tych działań jest model procesorów,
Sposób postępowania podczas budowania modelu procesorów polega na zstępu jącej analizie modelu funkcjonalnego i przypisywaniu kolejnych procesów do wybra nych komputerów systemu. Jeśli proces nie może być przypisany w całości, to ko nieczne jest przeniesienie analizy na niższy poziom hierarchii modelu i przypisanie różnych procesów składowych do różnych komputerów systemu. Po przypisaniu wszystkich procesów następuje przypisanie zbiorów, przy czym najczęściej umieszcza się zbiory w tych komputerach, do których przypisano procesy przetwarzające te zbiory. Jeśli jest to niemożliwe, to konieczne jest dodanie procesów, pośredniczących, pełniących rolę administratora zbioru, które udostępniają swoje zbiory procesom wykonywanym w innych komputerach. Podział modelu funkcjonalnego między komputery nie powinien powodować niepotrzebnych zniekształceń pierwotnego modelu zachowania. Jedynym źródłem zmian modelu może być konieczność podzielenia procesu między różne komputery systemu oraz konieczność organizacji dostępu procesów do zbioru umieszczonego w innym komputerze. Ostatnim krokiem budowy modelu procesorów powinna być weryfikacja nowego modelu względem modelu zachowania. Należy tu sprawdzić, np. zestawiając odpo wiednie odwzorowanie w tabeli, czy każdy element modelu zachowania został przypi sany do jednego z komputerów systemu oraz czy każdy element modelu procesorów można wyprowadzić z pewnych elementów modelu zachowania. Przykład. W systemie sterującym pracą rozlewni napojów w naturalny sposób wyod rębniają się niezależne sterowniki poszczególnych linii butelkowania oraz jeden komputer nadrzędny, pełniący rolę stacji dyspozytora rozlewni (rys. 10. II). Każdy sterownik obsługuje dwustanowe sygnały wejściowe i wyjściowe „swojej” linii butel kowania oraz przyjmuje z komputera nadrzędnego polecenie startu i sygnalizuje zwrotnie swój stan pracy. Ze względu na wymaganą niezawodność oraz dwustanowy charakter przetwarzania rolę sterowników mogą pełnić sterowniki PLC - specjalizowane
10. S ystem y krytyczne
384
komputery używane masowo do sterowania instalacjami przemysłowymi. Stacja dyspozytora wyświetla na ekranie stan instalacji i przyjmuje polecenia dyspozytora. Stacja może też oferować dodatkowe możliwości, takie jak ostrzeganie obsługi o sytuacjach alarmowych, archiwizacja danych procesowych i wizualizacja ich prze biegu w postaci wykresów czasowych. Rolę stacji może pełnić standardowy komputer PC wyposażony w odpowiednie oprogramowanie. * 4 sterowniki linii ^_I3utelka_ ^ butelkowania * ^ *•. r ” na wadze
_ _ — ______________________________________ Wlącz/wylącz "
Butelka pełna ""
.QtvjótóząrnJiiiijj^zawór Start transportu^" Otwórz
-►
. śluzę
►
R ysunek 10.11. Komputery systemu sterującego rozlewnią napojów
Rozwinięcie procesu Stacja dyspozytora na drugim poziomie hierarchii (rys. 10.12) pokazuje, że do tego komputera są przypisane wszystkie procesy modelu funkcjonalnego niezwiązane ze sterowaniem pracą linii butelkowania. Proces Nadzór linii nie musi być dalej rozwijany, gdyż jego działanie dokumentuje graf stanów pokazany w prawej części rys. 10.9. Sposób implementacji programu sterownika linii zostanie opisany w podrozdziale 10.4. Wlącz/wylącz
s
______ ^
11
pH niskie ~~ ^ y pi l norma
—"
N ^
start
"
Nadzór Y systemu j
praca
✓
/
1-3
itl stan pH
p’H
.......-
"
/
stan '"---jn sta la cp ,
1
R ysunek 10.12. Rozwinięcie procesów komputera Stacja dyspozytora
M odel zadań Kolejnym krokiem jest ustalenie struktury oprogramowania każdego procesora, na poziomie współbieżnych zadań widzianych przez jego system operacyjny. Wynikiem pracy jest model zadań, będący hierarchicznym schematem transformacji pokazują cym na diagramie najwyższego poziomu poszczególne zadania, reprezentowane jako
10.3. P rojektow anie strukturalne
-A
ggg
:----------------------------------------------------------------------------- —-----------------------i—L_
pojedyncze procesy. Na schematach niższego poziomu znajdują się procesy modelu jące przetwarzanie przypisane do konkretnego zadania. Przepływy między zadaniami modelują sposób komunikacji zadań z wykorzystaniem usług systemu operacyjnego, takich jak kolejki wiadomości, wspólne obszary pamięci, semafory itp. Podstawo wymi kryteriami, jakie powinny być stosowane podczas podziału modelu procesorów między różne zadania, są: ■ minimalizacja komunikacji zadań, przez grupowanie w tym samym zadaniu procesów silnie powiązanych ze sobą i jak najsłabiej powiązanych z procesa mi przypisanymi do innych zadań; ■ umieszczanie w tym samym zadaniu procesów wykonywanych okresowo z tą samą częstotliwością lub procesów wykonywanych w tym samym czasie; ■ grupowanie razem procesów wspólnie obsługujących te same fizyczne obiek ty instalacji. Sposób postępowania podczas budowy modelu zadań polega na zstępującej ana lizie modelu procesorów i przypisywaniu kolejnych procesów do wybranych zadań. Jeśli proces nie może być przypisany w całości, to konieczne jest przeniesienie analizy na niższy poziom hierarchii i przypisanie różnych procesów składowych do różnych zadań. Po przypisaniu wszystkich procesów następuje przypisanie zbiorów i określe nie sposobu komunikowania się zadań. W modelu mogą pojawić się również dodat kowe zadania, związane z dostępem do zbiorów lub obsługą urządzeń zewnętrznych i sieci łączących poszczególne komputery systemu. Ostatnim krokiem budowy modelu zadań powinna być weryfikacja nowego mo delu względem modelu procesorów. Należy tu sprawdzić, np. zestawiając odpowied nie odwzorowanie w tabeli, czy każdy element modelu procesorów został przypisany do jednego z zadań oraz czy każdy element modelu zadań można wyprowadzić z pewnych elementów modelu procesorów albo uzasadnić jego istnienie inaczej. W ten sposób proces projektowania systemu zawiera w sobie integralną weryfikację kolejno budowanych modeli względem siebie. Przykład. Proces Kontrola p H w komputerze dyspozytora rozlewni (rys. 10.12) jest procesem okresowym. Cyklicznie, np. co 100 ms, odczytuje z czujnika wartość pH, poddaje odczytaną wartość pewnej filtracji, której celem jest usunięcie wpływu zakłó ceń, i porównuje z zadanym progiem, generując - jeśli taka jest sytuacja - zdarzenie p H niskie lub pH norma. Proces Nadzór systemu jest procesem sporadycznym, wyko nywanym w chwili odebrania informacji o zdarzeniu od procesu Kontrola pH lub od dyspozytora. W tym ostatnim przypadku polecenie dyspozytora musi być odebrane od dyspozytora i przekazane dalej przez zadanie obsługujące graficzny interfejs użyt kownika, zawierające proces Wyświetl stan, rozszerzony o możliwość przyjmowania poleceń. W ten sposób w modelu zadań (rys. 10.13) pojawiają się trzy zadania, odpo wiadające trzem procesom modelu procesorów. Dodatkowo, stacja dyspozytora musi
386
10. S ystem y krytyczne
komunikować się z czterema sterownikami linii butelkowania. Ponieważ wybrane sterowniki komunikują się z otoczeniem wyłącznie za pomocą sieci przemysłowej więc dodatkowym zadaniem stacji jest zadanie Obsługi sieci. Porównując model zadań z modelem procesorów, można zauważyć duże zmiany wynikające z konieczności uwzględnienia mechanizmów komunikacji między zada niami, implementowanych przez system operacyjny, oraz komunikacji między kom puterami systemu. W tym przykładzie wybranym mechanizmem do przekazywania zdarzeń jest kolejka wiadomości, a wybranym mechanizmem komunikacji stanu jest wspólny obszar danych. Oczywiście zadania korzystające ze wspólnego zasobu muszą być odpowiednio synchronizowane. — — -►
Start k
->
¿raca k
,
►
Stan instalacji
10.4. A u tom atyczna generacja program ów ___________________________________ ^_________3 8 7
10.4 . A u to m a ty c z n a g e n e ra c ja p ro g ra m ó w Semantyka (znaczenie) diagramu stanów, używanego w metodzie W arda-Meilora do specyfikowania przetwarzania sygnałów dwustanowych, opiera się na formalnym modelu automatu skończonego. Elementami tego modelu są: zbiór stanów z wyróż nionym stanem początkowym, zbiór symboli wejściowych, zbiór symboli wyjścio wych oraz funkcja przejść i funkcja wyjść. Funkcja przejść określa następny stan automatu, w zależności od stanu bieżącego i wartości symbolu pojawiającego się na wejściu, funkcja wyjść określa symbol pojawiający się na wyjściu automatu. Działanie automatu rozpoczyna się w stanie początkowym, po czym automat: powtarzalnie odczytuje kolejne symbole wejściowe i pod ich wpływem przechodzi do następnych stanów, wytwarzając przy tym kolejne symbole wyjściowe. Odnosząc ten model do algorytmu sterowania, takiego jak pokazany na rys. I0.9, można zauważyć, że symbole wejściowe odpowiadają zdarzeniom określonym przez wartości sygnałów wejściowych sterownika, a symbole wyjściowe - wartościom sygnałów wyjściowych sterownika. W len sposób zmiana któregokolwiek sygnału jest równoznaczna ze zmianą symbolu wejściowego albo wyjściowego. Stany automatu opisują wewnętrzny stan sterownika, wyznaczony przez wartości zmiennych jego programu. Funkcje przejścia i funkcja wyjścia opisują działanie programu, polegające na wyznaczeniu nowego stanu i nowej wartości wyjścia sterownika, po zmianie sy gnałów wejściowych.
Włącz/wyłącz k
Skończona m aszyna czasow a Rysunek 10.13. Model zadań stacji dyspozytora M o d e l m o d u łó w Ostatnim krokiem pracy jest wykonanie szczegółowego projektu programów. Wyni kiem jest model modułów, na który składają się schematy struktury pokazujące bu dowę sekwencyjnych programów wszystkich zadań. Zasady tworzenia schematu struktury są dokładnie opisane w punkcie 3.1.4 i nie będą tu omawiane powtórnie. W rozważanym przykładzie zadania Nadzór systemu, Kontrola pH i Obsługa sieci mają wpiyw na poprawną pracę instalacji i dlatego powinny zostać starannie zapro jektowane i zaimplementowane w języku strukturalnym, aip. C. Zadanie Interfejs użytkownika nie ma bezpośredniego wpływu na pracę instalacji i dhitego może zostać napisane w dużo wygodniejszym do tego języku obiektowym, np. C++. Dużą częścią zadania Obsługa sieci będą zapewne standardowe drajwery urządzenia,'dostarczone przez producenta karty sieciowej.
Diagram stanów wychodzi jednak poza tradycyjny model automatowy, gdyż wprowa dza zależność od czasu. Przejście ze stanu Śluza otwarta do Transport, na rys. 10.9, nie następuje pod wpływem symbolu wejściowego, lecz po upływie pewnego czasu. Takiej zależności klasyczny model automatowy nie przewiduje.Jedną z prób rozsze rzenia modelu jest skończona maszyna czasowa, zbudowana z dziewięciu elementów [168, 170]: ■ ■ " ■ ■ *
skończonego zbioru stanów S\ stanu początkowego .v0 e S\ skończonego zbioru symboli wejściowych 27; skończonego zbioru symboli wyjściowych ił, skończonego zbioru symboli zegarowych F , funkcji zegarowej r : F —> S x R, która każdemu symbolowi zegarowemu przypisuje stan, w którym zegar działa, oraz okres czasu, po którym zegar ge neruje symbol; ■ funkcji przejścia 5 : ( S x 27u S x Z x F ) -> S, która wyznacza stan następny w zależności od stanu bieżącego, symbolu wejściowego i symbolu zegarowego;
10. S ystem y krytyczne
388
■ rozdzielczości pomiaru czasu ■ funkcji wyjścia tu : S —> f l
e
e R\
Działanie skończonej maszyny czasowej jest podobne do działania automatu, z tą różnicą że maszyna reaguje nie tylko na kolejne symbole wejściowe, ale także na symbole zegarowe, tak jak to ma miejsce podczas przejścia ze stanu -Śluza otwarta do Transport, na rys. 10.9.
10,4. Automatyczna generacja programów ----- —------------------------—h— ——
389
nianie (rys. 10.9) i wobec braku zamknięcia zaworu może prowadzić do wylania cieczy. Zabezpieczenie systemu przed taką awarią wymaga modyfikacji sterownika i wprowadzenia dodatkowego stanu zablokowania linii w razie zaniku sygnału obec ności butelki na wadze (R) lub przekroczenia maksymalnego czasu napełniania. Sko rygowany diagram stanów sterownika jest pokazany na rys. 10.15.
W e r y fik a c ja d ia g ra m u Określenie automatowej semantyki diagramu stanów umożliwia formalną weryfikację bezpieczeństwa, przez przeszukanie przestrzeni stanów i .sprawdzenie, czy zawiera siany niebezpieczne. W ykorzystanie tej techniki weryfikacji jest dość złożone i wy maga zbudowania modelu środowiska współpracującego ze sterownikiem, formalnego zdefiniowania sposobu współpracy automatów, a następnie przeszukania przestrzeni stanów tak stworzonego systemu i sprawdzenia obecności stanów niebezpiecznych. Na przykład, sterownik linii butelkowania współpracuje z ulcladem napełniania butelek, złożonym z zaworu napełniającego i wagi, którego działanie można opisać w sposób pokazany na rys. 10.14. Podstawowa pętla działania układu przyjmuje (od sterownika) sygnały otwarcia i zamknięcia zaworu Z i generuje - po pewnym czasie od otwarcia zaworu - sygnał napełnienia butelki F, odbierany przez sterownik. Dodatkowe przejście między stanami Napełnianie i Nadmiar odzwierciedla możliwość awarii polegającej na przewróceniu się lub rozbiciu butelki stojącej na wadze, w wyniku czego nie zostanie wygenerowany sygnał napełnienia. Wprowadzenie tego przejścia sprawia, że automat opisujący działanie otoczenia jest automatem niedeterministyeznym - nie wiadomo, które przejście wyprowadzi automat ze stanu Napełnianie. Przeszukanie przestrzeni stanów systemu, złożonego ze sterownika i jego otocze nia, umożliwiają specjalne narzędzia wspomagające znane pod angielską nazwą model checker, które mogą sprawdzić osiągalność stanów oraz właściwości takie jak brak zakleszczeń systemu. Niestety, nie ma dobrej nazwy tych narzędzi w języku polskim. Zawór zamknięty Z ’' Napełnianie
Rysunek 10.15. Diagram stanów sterownika linii butelkowania S te ro w n ik P L C Podstawowym rodzajem sprzętu komputerowego używanym w układach sterowania przemysłowego jest sterownik PLC (Programmable Logic Controller). Jest to specja lizowany komputer wyposażony w zestaw wejść i wyjść, umożliwiających połączenie z czujnikami i urządzeniami wykonawczymi instalacji sterowanej, oraz system opera cyjny, wymuszający cykliczny, powtarzalny sposób pracy. W każdym cyklu pracy sterownik wykonuje następujące operacje: " odczytanie wszystkich czujników wejściowych i znpnmię.innD- tyah danych jako wartości zmiennych wejściowych, ■ wykonanie programu użytkowego obliczającego nowy stan sterownika i nowe wartości zmiennych wyjściowych, * wyprowadzenie wartości zmiennych wyjściowych na fizyczne wyjścia ste rownika, ■ odebranie lub wysianie komunikatu sieciowego (w razie potrzeby).
Rysunek 10.14. Diagram stanów układu napełniania butelki
Programowanie sterownika PLC polega na napisaniu programu użytkowego w języku akceptowanym przez sterownik. Pozostałe działania, w tym również kon trola czasu trwania cyklu powtarzania operacji, są wykonywane przez system opera cyjny sterownika.
W rozważanym przypadku linii butelkowania nietrudno zauważyć, że wykonanie przejścia odpowiadającego awarii powoduje zatrzymanie sterownika w stanie Napeł
W tych zastosowaniach, w których zmienne wejściowe i wyjściowe są zmienny mi dwustanowymi - przykładem może być sterowanie linią butelkowania rozważaną w tym rozdziale - sterownik działa jak skończona maszyna czasowa. Wartości
At Ustaw F
t
Nadmiar
10. S ystem y krytyczne
390
zmiennych wejściowych odczytane w danym cyklu pracy tworzą symbol wejściowy. Wartości zmiennych wyjściowych wyprowadzone w tym cyklu tworzą symbol wyj ściowy. Programowe zegary zliczające czas w programie sterownika odpowiadają symbolom zegarowym maszyny. Program użytkowy sterownika implementuje funkcję przejścia, funkcję wyjścia oraz funkcję czasową, przy czym wszystkie te funkcje są funkcjami boolowskimi. Okres cyklu powtarzania programu sterownika określa roz dzielczość pomiaru czasu skończonej maszyny czasowej. Określenie semantyki diagramu stanów i programu sterownika PLC za pomocą skończonej maszyny czasowej umożliwia automatyczne przekształcenie diagramu w program sterownika. G e n e r a c ja k o d u Każdy cykl pracy sterownika odpowiada wykonaniu jednego przejścia między stanami. Wszystkie stany widoczne na diagramie stanów można zakodować w programie sterow nika za pomocą wartości pewnego zespołu bitów. Za pomocą n bitów można zakodować co najwyżej 2" stanów. Implementacja funkcji przejścia w programie sterownika polega teraz na wskazaniu w każdym cyklu pracy, które bity stanu są ustawiane, które zerowa ne, a które pozostają bez zmiany. Podobnie, implementacja funkcji zegarowej polega na wskazaniu, w których stanach poszczególne zegary zliczają czas. Program sterownika składa się więc z funkcji boolowskich, których argumentami są bity stanu, sygnały wejściowe i symbole zegarowe, a wartościami są sygnały usta wienia lub zerowania bitów, sygnały działania zegarów i sygnały wyjściowe. Proces generacji kodu programu składa się z następujących kroków: kodowanie stanów, implementacja funkcji zegarowej, implementacja funkcji przejść, implementacja funkcji wyjść, budowanie programu. Wracając do przykładu linii butelkowania, której sterownik opisuje diagram sta nów pokazany na rys. 10.15, można zauważyć, że zakodowanie pięciu stanów sterow nika wymaga użycia trzech bitów M l , M2, M3 (tab. 10.5). Tabela 10.5. Przykładowe kodowanie stanów sterownika linii butelkowania
10.4. Automatyczna generacja programów 4 --------------------------------- 1-----------------
Każdy symbol zegarowy występujący na diagramie stanów jest implementowany w programie sterownika przez programowany czasomierz, działający jak urządzenie, które mierzy upływ czasu tak długo, jak długo na jego wejściu utrzymuje się stan 1. Sygnał wyjściowy czasomierza pozostaje na poziomie 0 do chwili, ąż zmierzony czas przekroczy zadaną wartość. Tak więc sygnały włączające pomiar czasu w programie sterownika linii butelkowania można zapisać jako: Set tl= M 1 •~M2 •M3 Set 12 = M l ■M2 ■~M3 > Funkcja przejścia definiuje warunki ustawiania lub zerowania przerzutników podczas przejść między stanami. Na przykład, przejście ze stanu Napełniania do stanu Unia zablo kowana na rys. 10.15 wymaga wyzerowania przerzutników M l i M2 po zaniku sygnału R lub po upłynięciu czasu ńh- Przejście to opisują więc dwie funkcje boolowskie: Res M l = ( r + 1,2)-M l- M2 ■M3 Res M 2 = (R + (.2) •M l ■M2 ■M3 Tak zapisane funkcje nie zapewniają jednak atomowej realizacji przejścia - wy konanie pierwszej funkcji zmieni stan przerzutnika M l, uniemożliwiając wykonanie drugiej funkcji. Zapewnienie atomowej realizacji przejść wymaga wprowadzenia zbioru przerzutników pomocniczych, dublujących przerzutniki stanu. Przerzutniki te przecho wują następny stan sterownika aż do zakończenia całego obliczenia funkcji przejścia. Faktyczna zmiana stanu nastąpi w chwili przepisania przerzutników pomocniczych do przerzutników stanu. A zatem implementację funkcji przejść można zapisać następująco: Set U = M l -M2- M3 Set t.2 = M !-M 2 -M 3 S e iM U = S - W l - M - M 3 Set M12 = tl-M l-M 2 -M 3 Set M l 3 = S-~R- M I ■'M2-1A3
M l
M2
Stan j
M3
L in ia z a b lo k o w a n a ! ............. 1 L in ia z a trz y m a n a
0
0
0
1
0
0
1
0
1
Ś lu z a o tw a rta
1
1
i
T ra n s p o rt
1
1
0
N a p e łn ia n ie
391
Res M l 1 = (R + 12) ■M l ■M2 ■M3 Res M 12 = (Ti +12 + R- F ) ■M1 ■M2 ■~M3 Res M13 = R -M l-M 2 -M 3 M I = M il M2 = M l 2 M3 = M l 3
392
10. S ystem y krytyczne
Kodowanie stanów sterownika pozostawia pewne kombinacje bitów stanu nie wykorzystane. Na przykład, w tab. 10.5 wykorzystanych jest tylko pięć z ośmiu kombi nacji bitów. Zapewnienie wysokiej niezawodności sterownika wymaga również zapla nowania jego reakcji na. pojawienie się - na skutek błędu - jednej z tych kombinacji. Można to osiągnąć, modyfikując sekwencję funkcji boolowskich w sposób powodujący zatrzymanie programu w razie pojawienia się nieprawidłowej sekwencji bitów stanu:
10.5. Uw agi bibliograficzne i\ 2 .-----------:------------
393
Opracowanie modeli opisujących działanie sterownika i sterowanej instalacji musi być wykonane ręcznie. Pozostałe działania, tzn. weryfikacja z użyciem narzędzia model checker oraz generacja kodu, mogą być wykonane automatycznie f 169, 170).
10.5 . U w ag i b ib lio g ra fic z n e Obszerny przegląd dziedziny projektowania oprogramowania systemów czasu rze czywistego można znaleźć w książkach [ I6 l, 164, 165] oraz w skrypcie [159]. Mimo upływu czasu warte wzmianki są też książki [157, 158, 163].
M 4 = m ] -(M 2 + M 3) M l = M l 1 ■M4 M2 - M l 2 ■J44 M3 = M13- ~M4 Podobne funkcje boołowskie opisują funkcję wyjść. Sekwencja funkcji boolow skich wyznacza kompletny program sterownika PLG, który można zapisać w języku drabinkowym (ładder diagram), zdefiniowanym dla sterowników PLC w normie 1173]. Fragment tego programu, imitującego schemat układu przekaźnikowego, jest przedstawiony na rys. 10.16. 1
MI
i
Ml
\
S
M2
M2
Ml
Ml
M3
M2
M2
i_ |/|--- 1/(--- J/|-----l/l-----1
II
.
I I---- 1 |---- 1/|------ 1 |--------
!
s
;
Ml
U
M2
M-l
Ml
M2
Mli
| |---- 1/ | ----1 |------1/ | ---- 1/|_ R
Ml
M2
Mil
-0 0
M3
|---- 1 |----1/ |
---------
Ml 2
- ( '0 •
M13
M etody stru k tu ra ln e . Nieco na uboczu głównego nurtu metod strukturalnych rozwijały się badania nad metodami wytwarzania systemów czasu rzeczywistego, które wprowadziły szereg rozszerzeń związanych z koniecznością modelowania dynamiki systemu oraz zaakcentowały potrzebę precyzyjnego zdefiniowania wyma gań i rygorystycznej dyscypliny prowadzenia projektu. Przykładami mogą być metoda Warda-Mellora [47], metoda Hatley-Pirbhai [43] i używana w swoim czasie w brytyjskiej armii metoda MASCOT (M odular Approach 10 Software Constmction Operation and Test) [52], M etody obiektowe. Generalnie metody obiektowe nie zostały zaakceptowane w dziedzinie systemów krytycznych. Istnieje jednak szreg prac próbujących prze szczepić te metody na grunt systemów wbudowanych, np. [162]. Za obiektowy można też uznać model Statechart, opracowany przez Harela dla izraelskiego przemysłu lotniczego, który został zaadaptowany w postaci diagramu maszyny stanowej języka U M L [ 167 ].
-(* ) Mil
— ( R)
Sterow nik PLC. Języki programowania sterowników PLC, w tym język drabin kowy, definiuje norma [173]. Metody projektowania oprogramowania sterowników PLC, inne od opisanej w tym rozdziale, są opisane w książkach [155, 156].
; Ml
^i M25
k ) ,
Ml
M2
M3
i—I f-— l/l----1 h----------------------—
O