Inżynieria oprogramowania 9788301161798

Citation preview

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