dwa elementy: wymagania funkcjonalne, opisujące cele przetwarzania i wymagane funkcje oraz wymagania niefunkcjonalne, określające dokładność i terminowość uzyskania wyników.
Celem projektu jest określenie takiej struktury p ro gramów, k tó ra zagw arantuje w ykonanie wszystkich funkcji w zadanym czasie i z zadaną dokładnością. Różne
K rótkie omówienie podstaw ow ych m etod projekto
w ania oprogram ow ania, wraz z przykładam i mini projek
tów, m ożna znaleźć w [17]. Dokładniejszy opis wy
branych m etod projektow ania będzie przedm iotem dal
szych artykułów tego cyklu. Celem tego artykułu jest ogólne naszkicowanie dziedziny projektow ania oprog
ram ow ania oraz przedstawienie problem u analizy proje
ktu. Zagadnienie to jest wspólne dla wszystkich projek
tów oprogram ow ania systemów czasu rzeczywistego i niemal nie zależy od rodzaju wykorzystanej metody projektowej.
Pierwsza część artykułu przedstaw ia miejsce etapu projektu w różnych układach procesu rozwoju oprog
ram ow ania. W jego drugiej części zostanie podana ogólna klasyfikacja m etod projektow ania, w prow adzona ze względu na rodzaj modelu m atem atycznego leżącego u podstaw dekom pozycji program u na m oduły i jednostki program ow e. Trzecia część przedstawi przykład zależno
ści między w ym aganiam i niefunkcjonalnymi, dotyczący
mi dokładności i term inowości obliczeń, podstawowe twierdzenie i praktyczne zalecenia dotyczące sposobu szeregowania gw arantującego term inowość wykonania zadań systemu.
P r o c e s ro z w o ju o p r o g r a m o w a n i a
Tradycyjny proces rozwoju oprogram ow ania, nazywany procesem kaskadow ym (ang. waterfall model), określa sekwencję następujących po sobie etapów, których wyni
kam i są kolejne dokum enty projektow e (rys. 1). Pierwszy etap - analiza w ym agań - ma na celu dokładne określenie wszystkich funkcji, które m a wykonywać projektow ane oprogram ow anie, oraz wszystkich wym agań niefunkc
jonalnych, dotyczących przede wszystkim czasu uzys
kania i dokładności wyników. W kolejnych etapach - projekcie wstępnym i szczegółowym - następuje okreś
lenie struktury całego oprogram ow ania, określenie al
gorytm ów działania wszystkich składników oraz o p tym alizacja całości zgodnie z wybranym kryterium ja k o ści, którym może być np. czas wykonania, zajętość pamięci lub przenośność i łatw ość modyfikacji.
R ys. 1. E ta p y o p ra c o w a n ia o p ro g ra m o w a n ia i ich p o d sta w o w e w yniki
Zaletą takiego układu działań jest zorganizow ana dyscyplina pracy, w której wszystkie późniejsze działania są podejm ow ane w dobrze określonym kontekście wym a
gań, oraz możliwość oceny postępu prac. W adą jest skupienie najważniejszych decyzji strukturalnych na p o
czątku projektu, kiedy ani n atu ra problem u, ani p o d stawowe algorytm y nie są jeszcze znane. W rezultacie początkow a stru k tu ra projektu musi być często korygo
wana w wyniku późniejszych ustaleń, czego rezultatem jest wzrost kosztu prac i nieprzejrzystość wielokrotnie zmienianej struktury program ów .
N iedostatki procesu kaskadowego wywołują naw raca
jące zainteresowanie inną organizacją prac nad rozwojem oprogram ow ania, określoną przez proces przyrostowy (ang. incremental model). Proces ten odw raca kolejność działań przewidzianą w procesie kaskadow ym i odsuwa w czasie najważniejsze decyzje strukturalne. W począt
kowej fazie prace koncentrują się na najlepiej znanych fragm entach, a przechodzenie do dalszych fragm entów następuje po opracow aniu szczegółów i zdobyciu pew
nych doświadczeń. Prow adzi to do innego podziału procesu projektowego, w którym zam iast sekwencyjnych etapów analizy, projektow ania, implementacji i testo
w ania całego oprogram ow ania występują przeplatające się czynności analizy, projektow ania i implementacji fragmentów program u.
Zaletą takiego układu działań jest odsunięcie najważ
niejszych decyzji strukturalnych do czasu lepszego po
znania problemu, naturalne wykorzystanie techniki makie
towania fragmentów program u i dobre dopasowanie kolej
ności prac do sposobu myślenia człowieka. W adą jest przede wszystkim trudność zarządzania przebiegiem proje
ktu - doświadczenie pokazuje, że fragmenty zaprojek
towane przed opracowaniem koncepcji całości często nie są z nią później zgodne i wymagają dużych zmian i modyfi
kacji. Problem ten jest ściśle związany z wrażliwością jednostek programowych na kontekst i jest pochodną ograniczonej możliwości łączenia jednostek.
Zakończenie implementacji umożliwia przejście do kolejnego etapu - weryfikacji zgodności oprogram ow a
nia ze specyfikacją wymagań. Podstaw ow ą techniką weryfikacji jest testowanie funkcji i wydajności progra
mów. Wykrycie błędu pociąga za sobą konieczność cofnięcia procesu projektowego do miejsca, w którym ten błąd powstał.
W adą takiego układu działań, wynikającą z cech zastosowanej techniki weryfikacji - testowania, jest ko
nieczność opóźnienia weryfikacji aż do chwili zakoń
czenia im plem entacji program ów . Uniemożliwia to bieżą
ce weryfikowanie błędnych decyzji projektow ych i przy
czynia się do znacznego wzrostu kosztów - popraw ienie błędów projektu po zakończeniu implementacji jest za
zwyczaj bardzo kosztowne, gdyż wymaga pow tórzenia części projektu, program ow ania i testowania. W adą testow ania jest również niemożliwość udow odnienia po
prawności program u.
P róbą przezwyciężenia tych niedostatków i zmiany zarów no techniki projektow ania, ja k i weryfikowania program ów jest proces formalnego konstruow ania p ro gram u (ang. fo rm a l program construction). Podejście to opiera się na spostrzeżeniu, że specyfikację wymagań i tekst program u m ożna traktow ać ja k o równoważne opisy przetw arzania, zapisane w różnych językach. Jeżeli obydw a opisy są zapisane formalnie, oparte na aks- jom atycznej semantyce, to konstrukcja program u spro
wadzi się do przetłum aczenia opisu z języka specyfikacji na język program ow ania. Proces ten wykonuje się w wielu krokach, przez kolejne tłumaczenie opisu na języki p o średnie, coraz bliższe ostatecznem u językowi program o
wania. Form alizacja tej procedury umożliwia udow od
nienie popraw ności każdego kroku przekształcenia.
M im o koncepcyjnej atrakcyjności, m etody formalne m ają wiele słabych stron. Po pierwsze, zapisana formalnie specyfikacja w ym agań jest niezrozum iała dla użytkow nika i tru d n a do oceny. Problem ten m ożna złagodzić przez m akietow anie specyfikacji. Po drugie, m etody for
m alne m ogą być efektywnie stosow ane tylko w tych dziedzinach, w których istnieje naturalny model m atem a
tyczny, np. w konstrukcji kom pilatorów lub baz danych.
W dziedzinie systemów czasu rzeczywistego, w której brak takiego modelu, m etody te nie są efektywne ze względu na trudność i koszt opracow ania odpowiedniej teorii m atematycznej. Po trzecie, dow ody popraw ności są trudne, a przy tym długie i przez to podatne na błędy.
O cen a różnych sposobów usytuow ania projektu p ro gram u w całym procesie rozwoju oprogram ow ania nie jest w pełni jednoznaczna. W obecnym stanie inżynierii oprogram ow ania praktyczne znaczenie m ają tylko proce
sy kaskadow y i przyrostowy. Proces kaskadow y dom inu
je w projektach dużych, realizowanych przez wieloosobo
we zespoły i wymagających zdyscyplinowanego nadzoru.
W mniejszych projektach prace przebiegają często w spo
sób mniej zdyscyplinowany, zgodnie z modelem przyros
towym.
Badania teoretyczne, dotyczące formalnych metod konstruow ania oprogram ow ania, nie osiągnęły jeszcze stadium dojrzałości niezbędnego dla zastosow ania ich na szerszą skalę. Powodzenie tych prac może jednak d o prow adzić do radykalnego podniesienia jakości i ograni
czenia kosztów rozwoju i konserwacji oprogram ow ania.
W obecnym stanie technologii program ow ych metody form alne znajdują fragm entaryczne zastosow anie przy opracow yw aniu wydzielonych fragm entów (lub pewnych aspektów) oprogram ow ania.
K la s y fik a c ja m e to d
p r o je k t o w a n ia o p r o g r a m o w a n i a
Niezależnie od sposobu i miejsca usytuow ania projektu w cyklu rozw oju oprogram ow ania, punktem wyjścia wszystkich prac projektow ych jest specyfikacja wymagań określona w wyniku analizy rozwiązywanego problem u.
Zależnie od rodzaju m etod w ykorzystanych podczas analizy wymagań, specyfikacja m oże być zapisana w róż
nej postaci. N a przykład [18]: tekstowej, grafu przepływu danych, schem atu obiektowego, form alnego zapisu abs
trakcyjnych typów danych lub m odelu sieciowego, np.
sieci Petriego lub zespołu sieci danych.
W ynikiem projektu jest zawsze definicja struktury oprogram ow ania, złożona z definicji podstaw ow ych m o
dułów program u oraz reguł ich współpracy. Rodzaj m odułów i łączących je sprzęgów zależy od struktury środow iska implementacyjnego. W środow isku złożo
nym z wielozadaniowego systemu operacyjnego i języka proceduralnego podstaw ow ym i m odułam i są jednostki akcji - współbieżne zadania, podzielone na sekwencyjnie wywoływane podprogram y. W środow isku złożonym z równoległego języka obiektowego, takiego ja k Ada lub M odula, podstaw ow e m oduły są inne. Pakiety (klasy) m ogą zawierać w sobie dowolne jednostki a k c ji- p o d p r o gram y lub zadania - i jednostki d anychl \
Celem projektu jest odw zorow anie w ym agań w stru k turę oprogram ow ania. O dw zorow anie to może być wy
konane w sposób intuicyjny, lub zgodnie z ja k ą ś mniej lub bardziej sform alizow aną m etodą. W iększość m etod bu
40
duje strukturę oprogram ow ania przez przekształcenie struktury m odelu wymagań, zachow ując przy tym naturę podstaw ow ych elementów obydwu struktur. W ten spo
sób model grafu przepływu danych, którego podstaw o
wymi elem entam i są akcje (transformacje), przekształca się naturalnie w hierarchię wywołań podprogram ów , z których każdy również opisuje pewną akcję. N atom iast model obiektowy, którego podstaw ow ym i elementami są obiekty opisywane przez akcje i dane, przekształca się naturalnie w hierarchię pakietów (klas), z których każdy zaw iera w sobie jednostki akcji i danych.
Specyfikacje wym agań zapisane w postaci tekstu, ze
społu sieci działań lub form uł m atem atycznych nie okreś
lają żadnej struktury i dlatego m ogą być przekształcone w dow olną strukturę program u. Z drugiej strony brak strukturalnego m odelu w ym agań nie ułatw ia prow adze
nia projektu i utrudnia weryfikację jego popraw ności względem specyfikacji.
ST A TEM A T E [5) SA /SD (W ard-M cllor) [23]
Sicci Pctri |8) SA /SD (H atlcy-Pirbhai) |6 | SA DT 1141 SSADM [21]
M A SC O T 120) DA RTS (3) TA G S [19]
HO O D [7]
Booch [1]
M cy cr[l2]
R um baugh [15]
C oad-Y ourdon [2]
VD M [9]
R ys. 2. K la sy fik a c ja m e to d p ro je k to w a n ia sy stem ó w czasu rzeczyw is
tego
Schem atyczną klasyfikację m etod projektow ania o p ro gram ow ania względem stosowanej zasady dekompozycji program u na m oduły pokazuje rys. 2, a zakres za
stosow ania poszczególnych m etod w różnych etapach procesu rozwoju oprogram ow ania rys. 3. Jak m ożna
STETEM ATE Model SA/SD SADT SSADM M ASCOT DARTS TAGS HOOD Booch M eyer Rumbaugh Coad-Yordon VDM
Analiza Projekt
wymagań wstępny
Projekt Implementacja szczegółowy
R y s. 3. Z a k re s z a s to so w a n ia m e to d p ro je k to w a n ia o p ro g ra m o w a n ia
11 Język C + + jest, w kontekście rozw ażanych zagadnień, niedojrzałym językiem obiektow ym ograniczonym do program ów sekwencyjnych - se
m antyka wspólbieżności (np. pow ołania procesów potom nych przez metodę) jest nieokreślona. S tru k tu ra klas i obiektów w yodrębnionych podczas analizy jest w projekcie o program ow ania w tórna w obec stru k tury zadań narzuconych przez kom prom is w ym agań i specyfiki systemu operacyjnego.
Inform atyka nr 3. 1996 r.
zauważyć z tych rysunków, dw om a grupam i metod o podstaw ow ym znaczeniu dla praktyki są m etody stru k turalne - oparte na modelu przepływu danych i metody obiektowe — oparte na m odelu struktury obiektów.
Przykładam i m etod form alnych są na rys. 2: m etoda VDM oraz m etody oparte na teorii sieci Petriego.
W dziedzinie systemów czasu rzeczywistego szczególne znaczenie m ają m etody korzystające z modelu kolorow a
nych sieci Petriego [13], stosowanego ja k o narzędzie weryfikacji i formalnego badania właściwości program ów zaprojektow anych m etodą SADT.