POISKIE TOWARZYSTW) INFORMATYCZNE
CZTERNASTE JESIENNE SPOTKANIA PTI
Problemy jakości i niezawodności środków informatyki
Mrągowo, 16-20 listopada 1998r,
C z t e r n a s t e J e s i e n n e S p o t k a n i a PTI
M
r ą g o w o‘9 8 - 1 6 -2 0
l i s t o p a d a1998
P r o b l e m y j a k o ś c i i n i e z a w o d n o ś c i ś r o d k ó w i n f o r m a t y k i
XIV JESIENNE SPOTKANIA PTI - M RĄGOW O ’98 16.11.98 - 20.11.98
A n na C e tn a r o w icz -J u tk ie w icz Narodowy Bank Polski
Warszawa
c
...
Szanowni Państwo
Trzydzieści trzy godziny wykładów, prezentacji i dyskusji to dwa sem estry studiow ania jed n eg o przedm iotu. W dodatku, m etodą „kilka w je d n y m " będą Państwo m ieli okazją postudiow ać kilka przedm iotów na raz. Tegoroczne M rągowo jest: sesją INSPIRE, sem inarium pośw ięconym dokumentom, zajęciam i z praktyki niezaw odności systemów informatycznych, cyklem m onograficznych wykładów na temat baz danych, grafiki i typografii komputerowej, wreszcie przeglądem platform system owych oraz technik stosow anych w zarządzaniu przedsiębiorstwem .
Układ konferencji je s t próbą realizacji wszystkich postulatów , które zgłosili Uczestnicy oceniający poprzednie spotkania. M am y nadzieję, że tegoroczni odbiorcy wspom ogą naszą inwencję nowym i propozycjam i.
Nasze spotkanie odbywa się kilkanaście dni p rzed drugim Kongresem Inform atyki Polskiej. N a Kongresie będą znaczące postaci życia publicznego, wielu znajomych, z którym i warto się spotkać, będzie m ożna podpisać się p o d Paktem o Społeczeństw ie Informacyjnym, każdy chętny będzie upoważniony do przedstaw ienia swoich opinii na temat naszych
-informatyków
-interesów. Mam nadzieję, że m rągowskie dyskusje oficjalne
-a zwłaszcza kuluarowe - będą dobrym przygotow aniem do Kongresu. Tych, którzy się je szc ze nie zdecydow ali pośw iecić dwóch dni bardziej aktywnym, niż samo słuchanie wykładów, form om uczestnictwa w życiu środowiska, gorąco do udziału
wKongresie zachęcam.
Jak zaw sze w M rągowie będziem y m ówić o sprawach PTI. Rośnie nam ono w oczach od je sien i do jesien i: Oddział W ielkopolski właśnie przekroczył stu członków, reaktywow ał się O ddział M ałopolski, coraz aktyw niej działa koło w Gdańsku, rozwija się Europejskie Kom puterow e Prawo Jazdy. Przyszłoroczna szkoła w Szczyrku będzie w części naukową, recenzow aną Pierwszą Krajową K onferencją Inżynierii Oprogramowania. D wudziestego drugiego maja przyszłego roku zbierzem y się na siódm ym w historii Towarzystwa Zjeździe. N igdy je d n a k nie je s t tak dobrze, żeby nie m ożna było czegoś poprawić. Tych z Państwa, którzy przez niedopatrzenie nie są je szc ze członkam i P T I nam awiam do naprawienia tej pomyłki.
Pech, a tak naprawdę nasze błędy, sprawiły, że w trakcie naszego spotkania będzie się odbywać w Poznaniu SEES'98 (Software Engineering Education Symposium). Do tej konferencji P T I też przyłożyło rękę - w tym przypadku rękę Jurka Nawrockiego.
Przepraszam y Jerzy, będzie nam Cię w M rągowie brakow ać tak samo ja k Tobie nas w Poznaniu.
Pozdrawiam z przedw czesnym i życzeniam i świątecznymi. Jakoś trzeba będzie przetrw ać
do następnego listopada.
Czternaste Jesienne Spotkania P T I M rągowo ’98 — 16-20 listopada 1998 1
Tomasz Byzia
Narzędzia zapewnienia i kontroli jakości oprogramowania
W stęp
T ruizm em je s t stw ierdzenie, że dla użytkow ników , dostaw ców oraz producentów , jak o ść system ów inform atycznych je s t rzeczą najw ażniejszą. Dla użytkow nika w ysoka jakość oznacza satysfakcję, rozw iązanie rzeczyw istych problem ów z przetw arzaniem dużej ilości danych, zaufanie do zastoso
w anych rozw iązań, niezaw odność, bezpie
czeństw o i „spokój” na długie lata. Dla dostaw ców w ysoka ja k o ść oznacza satysfakcję z dostarczonego system u, uznanie w oczach klienta, niskie koszty konserw acji i w ysokie zyski teraz i w przyszłości. W ysoka jak o ść je st hasłem , które tam gdzie się pojaw ia, przyciąga do siebie ludzi biznesu, bo w ysoka jakość broni się sam a i zaw sze się opłaca.
T ruizm em je s t także stw ierdzenie, że jak o ść dzisiejszych system ów inform aty
cznych pozostaw ia w iele do życzenia. M im o iż pierw sze objaw y „kryzysu oprogram o
w ania” zauw ażono ju ż pod koniec lat 60-tych, niew iele udało się zrobić przez ostatnie 30 lat.
Rozwój inżynierii oprogram ow ania pozw olił w ypracow ać w iele m etod, narzędzi, zaleceń, m odeli i paradygm atów , które zbliżały nas do m om entu w którym chciało się pow iedzieć:
„oto w iem y ja k produkow ać niezaw odne oprogram ow ania wysokiej ja k o śc i”.
W ystarczy jed n ak przejrzeć tytuły artykułów w kilku z w spółczesnych tygodników pośw ięconych zagadnieniom w ytw arzania oprogram ow ania i inform atyzacji, aby bez trudu odkryć, że daw ne problem y s ą obecne i dzisiaj. W pływ a na to w iele czynników . D ecydują o tym zarów no bardziej złożone architektury w spółczesnych system ów jak i w yższe w ym ag an ia klientów oczekujących w ysokiej niezaw odności, w iększej
elastyczności i podatności na zm iany. B rakuje w drożonych i skutecznych m etodyk szacow a
nia projektów , brakuje zasobów , czasu, pieniędzy, a jeśli naw et są to źle się nim i zarządza.
Ż yjąc w takim św iecie od dziesięcioleci, p rzyzw yczailiśm y się do tego, że przystępując do projektów inform atycznych robim y to z pew nego rodzaju „podw ójną m oralnością” . T eoria - teorią, a praktyka - praktyką. Każdy kierow nik przedsięw zięcia podpisze się pod stw ierdzeniem , że należy stosow ać zasady inżynierii oprogram ow ania, zapobiegać pro blem om , a nie „gasić pożary”, kontrolow ać jak o ść, przeprow adzać przeglądy projektu, pracow ać dobrze, a nie źle, itd. Z drugiej strony dla w iększości zalecenia te pozostają czym ś złudnym , niepraktycznym czy w ręcz niew y ko naln ym . Stąd tylko krok do budow ania teorii uspraw iedliw iających w łasny brak konsekw encji. M etody są nieadekw atne, ludzie om ylni, reguły niepraktyczne. W życiu osobistym zaw sze spodziew am y się w ysokiej jak o ści produktów i usług z których będziem y korzystać. W życiu zaw odow ym czasem zado w alam y się „bylejakością” i oczekujem y, że ja k a ś „m agiczna siła” napraw i nasze błędy i poskleja rozpadające się przedsięw zięcie.
P oruszony przeze m nie tutaj problem je st jed y n ie w ierzchołkiem góry lodowej. Jest skutkiem pew nego ogólnego i tajem niczego m echanizm u kom plikow ania sobie życia przez odrzucanie oczyw istych zasad racjonalnego działania w m iarę w zrostu złożoności i sk o m pliko w ania przedsięw zięć inform aty
cznych. Jest to bardzo w ażny i trudny problem znany zapew ne każdem u. N ie chcę go jed n ak tłu m aczy ć i jed n o zn aczn ie w yjaśniać. K ażdy m usi je g o znam ion a odkryć w sobie sam ym
POLSKIE TOW ARZYSTW O INFORMATYCZNE — ODDZIAŁ GÓRNOŚLĄSKI
2 TomaszByzia — Info V iD E— Narzędzia zapewnienia i kontroli jakości oprogramowania
i sam znaleźć w łaściw e lekarstw o. M oja rola polega na dostarczeniu słuchaczom „m ateriału do przem yśleń” . W tym celu przedstaw iając szerokie spektrum narzędzi w spierających te procesy zapew nienia i kontroli jak o ści pragnę skłonić w szystkich do osobistej refleksji i uczciw ej odpow iedzi na następujące pytania:
• czy w iedziałem o w ym ienionych narzę
dziach i m etodach zapew nienia jak o ści?
• czy w iedziałem , że są takie proste i łatw e w stosow aniu?
® czy je stosow ałem ?
• dlaczego ich nie stosow ałem ?
• kiedy zacznę je stosow ać?
Jak pow staje jak ość?
Jakość je st to w edług norm ISO 9000:
„ogół cech i w łaściw ości w yrobu/produktu lub usługi decydujących o jeg o /jej zdolności do zaspokojenia stw ierdzonych lub przew idyw a
nych potrzeb” . Pożądane cechy w yrobu kształtow ane są w cyklu w ytw órczym , który nosi nazw ę koła (spirali) jakości i obejm uje następujące procesy:
• m arketing i badanie rynku
• tw orzenie projektu/specyfikacji i kon
struow anie w yrobu
• zaopatrzenie
• planow anie i rozwój procesów
• produkcja
• kontrola i badania jakościow e
• pakow anie i m agazynow anie
• zbyt i dystrybucja
• instalow anie i urucham ianie
• pom oc techniczna, konserw acja i obsługa
• likw idacja
Jakość końcow a je s t w ięc w y pad kow ą jak o ści w ym agań, jak o ści projektow ania, jak o ści w ykonania i jak o ści użytkow ania.
D ziałania te są ściśle zw iązane z procesam i transform acji idei i w ym agań użytkow nika na
działający system inform atyczny. O kreślają jak b y horyzontalny w ym iar procesów
w ytw órczych. W ym iar w ertykalny zw iązany je st natom iast z różnym i poziom am i zarządzania procesam i w przedsięw zięciu.
O bejm uje w szystkie planow ane i syste
m atyczne działania, niezbędne do uzyskania w ysokiego stopnia ufności, że w yrób lub usługa spełni ustalone w ym agania jakościow e.
Poziom y te tradycyjnie dzielim y na:
• zarządzanie jako ścią,
• zapew nienie jako ści,
• kontrolę jak o ści.
H istorycznie pierw sza była kontrola jakości. S prow adza się ona do spraw dzania, m ierzenia lub testo w ania jednej lub kilku charakterystyk produktu i odnoszenia w yni
ków do w yspecyfikow anych w ym agań w celu potw ierdzenia zgodności. Zadanie to w ykony
wane zw ykle przez w yspecjalizow any perso
nel nie w chodzi w zakres obow iązków pracow ników produkcyjnych. Produkty nie
zgodne ze specyfikacjam i są odrzucane lub przekazyw ane do popraw ienia. Klasycznym przykładem sposobu kontroli jak ości je st testow anie oprogram ow ania.
K olejny krok w procesie ew olucji system ów jak o ści zaw dzięczam y klientom . Ruchy ko nsu m enck ie lat 70-tych spraw iły, że produkty m usiały lepiej pasow ać do w ym agań rynku - klienta. Z apew nienie jak ości było naturalnym rozw inięciem poprzednich prak
tyk. Jakość zaczęto w budow yw ać w produkt od początku przez prow adzenie system aty
cznych i zaplanow anych działań prow adzą
cych do w ytw arzania produktów zgodnych ze specyfikacją. W celu ciągłego zapew nienia jako ści dokonyw ano regularnych inspekcji, przeglądów , aud ytó w i zew nętrznych ocen.
R ozbudow yw ano d ziały m arketingu i analizy w ym agań, odpow iedzialne za dostarczanie w iarygodnych i uzgodnionych z przyszłym użytkow nikiem specyfikacji w ym agań.
N ajno w szą koncepcją, która nie neguje pozostałych lecz uzupełnia je o globalizację działań pro jako ścio w y ch , je st zarządzanie przez jak o ść. Jest to skoncentrow ane na jako ści zarządzanie przedsiębiorstw em , przy w spółudziale w szystkich je g o członków , w którym d ług ofalo w e korzyści przedsiębior
POLSKIE TOW ARZYSTW O INFORMATYCZNE — ODDZIAŁ GÓRNOŚLĄSKI
Czternaste Jesienne Spotkania P T I M rągowo ‘98 — 16-20 listopada 1998 3
stw a oraz korzyści społeczeństw a osiągane są poprzez spełnienie oczekiw ań klientów .
Przegląd narzędzi
N a każdym poziom ie zw iązanym z zarządzaniem ja k o ś c ią dysponujem y określonym zestaw em narzędzi, m etod i technik, które pozw alają na spraw ne i efektyw ne realizow anie zadań. N arzędzia są tutaj rozum iane bardzo szeroko ja k o w szelkie środki pom ocne w osiąganiu celów.
W dalszej części zostaną om ów ione w ybrane narzędzia w raz z krótką charakterystyką celu i zakresu ich stosow ania.
N arzędzia zarządzania jak ością o P olityka jakości
• M etryki jakości
• A udyt system u jakości
N arzędzia zapew nienia jak ości
• Praca zespołow a
• Inżynieria w ym agań
• M etodyka projektow ania
• W eryfikacja i w alidacja
• Z arząd zan ie zm ianam i
N arzęd zia kontroli jak ości
• D iagram y procesów
• H istogram y
• D iagram y Pareto
• W ykresy korelacji
• K arty kontrolne
• Listy kontrolne
• D iagram y Ishikaw y
P od sum ow anie
P rzedstaw ione narzędzia są bardzo proste i łatwe w użyciu. O panow anie każdego z nich zajm uje najw yżej 1 godzinę. M im o swojej prostoty do starczają bogatych m ożliw ości oceny, w eryfikacji i kształtow ania jakości produktów . Ich konsekw entne stosow anie tam , gdzie rzeczyw iście m a m iejsce przynosi znaczne korzyści. W racam y jed n ak tutaj do problem u postaw ionego na początku: dlaczego takie proste i „tan ie” narzędzia nie są w praktyce stosow ane. C zy są za proste, w ręcz tryw ialne, czasochłonne, pracochłonne, nieefektyw ne, nieefektow ne? Zapraszam do dyskusji.
POLSKIE TOW ARZYSTW O INFORMATYCZNE — OD D ZIA Ł GÓRNOŚLĄSKI
4 Tomasz Byzia — Info ViDE — Narzędzia zapewnienia i kontroli jakości oprogramowania
POLSKIE TOWARZYSTWO INFORM ATYCZNE — ODDZIAŁ GÓRNOŚLĄSKI
Czternaste Jesienne Spotkania P T I M rągowo ’98 — 16-20 listopada 1998 5
Piotr Dembiński
Instytut Podstaw Informatyki Polskiej Akademii Nauk
ul. Ordona 21, Warszawa e-mail: piotrd@ipipan. waw.pl
Metody formalne w projektowaniu oprogramowania:
mity i rzeczywistość *
1. W stęp
M etody form alne obecne są w inform atyce od jej początku, ale term in ten w inżynierii oprogram ow ania pojaw ia się dopiero, gdy je g o burzliw y rozwój i rosnąca złożoność w yw ołały w y raźn ą potrzebę bardziej uporządkow anego i zorganizow anego podejścia do całego procesu produkcji softwaru. Już w latach sześćdziesiątych podjęto próby w skazania reguł i konstrukcji, które program ista (zespół program istów ) powinien stosow ać, a które om ijać. Pojaw iły się propozycje m etod znanych pod chw ytliw ym i nazw am i, jak : program ow anie strukturalne (structured programming), system atyczne (rygorystyczne) program ow anie (systematic (rigorous) programming), projektow anie poprzez sto
pniow e przekształcania opisu problem u do je g o rozw iązania program istycznego (step
wise program refinement, top-down design) itp. M etody te próbowano coraz bardziej form alizow ać, łącząc naturalną konieczność pewnej system atyzacji inżynierskiego postępo
w ania z pok u są w ykorzystania rosnących
m ożliw ości kom puterów do autom atyzacji tego postępow ania.
A kadem ickie rozw ażania na tem at form alnych specyfikacji i w eryfikacji zadań program istycznych zderzyły się z rzeczyw isto
ścią końca lat siedem dziesiątych, które zw ykło się uw ażać za lata postępującego kryzysu w dziedzinie projektow ania softw aru. W łaśnie w tedy zauw ażono ogrom nie szybko w zrasta
ją c e koszty oprogram ow ania (przy taniejącym ciągle sprzęcie) szczególnie odczuw alne w zestaw ieniu z je g o rosnącą zaw odnością.
N iektóre z w ielkich projektów nie zostały ukończone, m nożyły się spektakularne przykłady błędów , które w ym agały nadm ier
nych nakładów na ich popraw ianie, a to z kolei często w prow adzało now e usterki, nad którym i, po pew nym czasie, nikt nie panował.
Szybko obliczono, że w cyklu ży cia o progra
m ow ania najw ięcej k o sztu ją błędy pow stające w początkow ej fazie projektow ania. D latego w łaśnie zainteresow ano się bardzo pow ażnie m etodam i form alnym i. W ydaw ało się niektórym , że ich zastosow anie w praktyce m oże być rem edium na p o w s ta łą k ry zy sow ą
* Niniejsza praca stanowi zmodyfikowaną wersję wykładu wygłoszonego na plenarnej sesji Krajowego Sympozjum Telekomunikacji, które odbywało się w dniach 9-11 września 1998 r. w Bydgoszczy..
POLSKIE TOW ARZYSTW O INFORM ATYCZNE — ODDZIAŁ GÓRNOŚLĄSKI
6 P io tr D em biń ski — Metody formalne w> projektowaniu oprogramowania: mity ł rzeczywistość
sytuację. Te nadzieje były, niestety, podtrzy
m ywane przez w iele nieodpow iedzialnych obietnic, które tw orzyły niebezpieczny m it nie m ający pokrycia ani w rzeczyw istych m ożliw ościach m etod form alnych, ani w m ożliw ościach dostępnej w tedy technologii kom puterow ej tam , gdzie m etody te m ogłyby mieć zastosow anie. Po kilku latach nastąpiło zniechęcenie, które utrw aliło poglądy zdecydow anie sceptyczne (naw et jeśli głośno nie w yrażane), co do praktycznej przydatności metod form alnych. Powstał zatem drugi niebezpieczny m it głoszący, że m etodam i tym i nie w arto się pow ażnie zajm ow ać.
W poniższym szkicu spróbujem y przeko
nać czytelnika, że odpow iednio rozważnie rozum iane m etody form alne zaw sze m iały i m ają sw oje w łasne m iejsce w całym złożonym procesie w ytw arzania oprogram o
wania. W skażem y na konieczne w arunki, które m uszą zaistnieć, żeby ich użyteczność była dostrzeżona, a w szczególności zw rócim y uw agę na potrzebę istnienia efektyw nych narzędzi autom atyzujących w iele żm udnych czynności w system atycznym projektow aniu.
W tym kontekście pokażem y też, ja k postęp technologiczny um ożliw ia realizację niektórych pom ysłów , których (pozorna) prostota i spektakularność otrzym yw anych w yników m oże pom óc w przełam yw aniu obiegow ych poglądów . Z w rócim y też uwagę na to, że m etody „specjalizow ane”, ograniczone do danej dziedziny zastosow ań w ydają się spełniać łatwiej oczekiw ania odbiorców . Tę tezę zilustrujem y ogólną charakterystyką m etod form alnych i stoso
w anych narzędzi w projektow aniu protokołów kom unikacyjnych oraz w nioskam i z realizacji projektu europejskiego, którego jednym z zadań było w spom agana kom puterow o specyfikacja i im plem entacja protokołu XTP (EXpress Transport Protocol).
2. Inżynieria op rogram ow ania i jej form alne m etody
Inżynieria oprogram ow ania operuje term i
nem cyklu życia system u inform atycznego, obejm ującego je g o różne etapy (fazy). Liczba tych etapów , ich nazw y i pow iązania różnią się w zależności od autora, ale zasadniczo panuje
zgoda, że cykl taki zaw iera interesujące nas tutaj etapy:
• specyfikacji,
• projektow ania,
• im plem entacji.
Każdy z nich m ożna podzielić na podetapy.
Z akłada się zw ykle, że w yniki uzyskane w kolejnym (pod)etapie m ogą spow odow ać konieczność pow rotu do etapów poprzednich.
W tym sensie, na przykład, uzyskujem y w kolejnych iteracjach cyklu prototypow ą, a nie o stateczną im plem entację.
Przejście z etapu na etap m oże być mniej lub bardziej sform alizow ane i w odpow iednim zakresie w spom agane przez specjalistyczne narzędzia program istyczne. N a każdym etapie pracujem y z ja k ą ś form ą opisu projektow a
nego system u, przy jednym założeniu niezm iennym : w w yniku fazy im plem entacji otrzym any opis je s t gotow y do w ykonania przez kom puter lub szerzej - w środow isku kom puterow ym , np. w sieci. Znaczy to, że je g o kształt je s t całkow icie sform alizow any.
Jeżeli taki sform alizow any opis otrzym ujem y autom atycznie z opisu pow stałego na w cześniejszym etapie, to w arto pam iętać, że rów nież ten w cześniejszy opis m usi być całkow icie form alny. Tak więc stopień autom atyzacji procesu w ytw arzania system u inform atycznego (oprogram ow ania) w bezpo
średni sposób zależy od stopnia jeg o sform alizow ania. W tym sensie pow iedzieć m ożem y, że m etody form alne to w arzyszą inform atyce (inżynierii oprogram ow ania) od jej początku, chociaż zakres ich zainteresow ań zm ieniał się, w m iarę ja k uzyskiw ano zadow a
lającą autom atyzację pew nych etapów projektow ania.
W bardzo w czesnym etapie rozwoju inform atyki problem y inżynierii oprogram o
w ania w tym schem atycznym ujęciu koncentrow ały się w okół relacji pom iędzy:
• programami w językach programowania,
• programami asemblerowymi,
• bezpośrednim kodem komputerowym (kto dziś odróżnia te dwie ostatnie kategorie!).
POLSKIE TOW ARZYSTW O INFORMATYCZNE — ODDZIAŁ GÓRNOŚLĄSKI
C zternaste Jesienne Spotkania P T I M rągow o ’98 — 16-20 listopada 1998 1
Przez lata zajm ow ano się składnią i sem an
ty k ą ję z y k ó w form alnych w poszukiw aniu efektyw ny ch m etod autom atyzacji przejścia od opisu program u (w języ k ach takich ja k Algol, PL1, Pascal, Algol 68 i wielu dziesiątkach innych) do je g o kodu kom puterow ego. Te często bardzo m atem atycznie w yrafinow ane rozw ażania zaow ocow ały tym , że dzisiaj istnieją efektyw ne kom pilatory, a języ ki program ow ania, takie jak C, spełniają rolę asem blerów z przeszłości.
Z biegiem lat program ow anie zm ieniło swój charakter, poniew aż skala i stopień złożoności problem ów , które rozw iązuje się za p om ocą kom puterów , w ym agają zaangażow a
nia i w spółdziałania wielu ludzi, bogatego i często rozproszonego terytorialnie środo
w iska obliczeniow ego oraz w yrafinow anych narzędzi, w spom agających cały proces proje
ktow ania, urucham iania i utrzym yw ania system ów inform atycznych. Jednym z p rz e ja w ó w tych zm ian, a także w yników
w cześniejszych prób jest fakt, że w schem acie, którym posługujem y się pow yżej, uw aga skoncentrow ana je s t na etapach poprze
dzających kodow anie w w ybranym języ k u program ow ania. O kazuje się bow iem , że w ybory dokonane w tych fazach są decydujące dla pow odzenia dużych przedsięw zięć progra
m istycznych. W tym sensie niesłychanie istotna je st faza sform ułow ania w ym agań projektow ych (requirement specification), a następnie przełożenie tych w ym agań na specyfikację sy stem ow ą (system level specification), tzn. ta k ą która w znacznie w iększej m ierze zajm uje się "logiką"
i "architekturą" proponow anego rozw iązania niż oprogram ow aniem poszczególnych funkcji i ich efektyw nością. Tak więc w spółczesna inżynieria program ow ania, w schem atycznym ujęciu fragm entu jej zainteresow ań, który przedstaw iliśm y pow yżej, koncentruje się wokół relacji pom iędzy:
• specyfik acją w ym agań,
• specyfikacją sy ste m o w ą
• program am i w językach program ow ania.
Stw orzenie m etod i narzędzi w spom aga
jący ch proces w ytw arzania system ów inform atycznych na tych etapach - w ym aga precyzyjnego określenia, czego oczekujem y
i ja k rozum iem y specyfikację w ym agań, a ja k specyfikację na poziom ie system ow ym . N ieuchronnie w ięc m ów im y o form alizacji i m etodach form alnych, co najm niej w stopniu i części, w której zakładam y pom oce au tom atyzujące w pew nym zakresie k on ieczn ą do w ykonania pracę.
W tym ogólnym w stępie nie będziem y naw et próbow ali dokonyw ać przeglądu proponow anych form alizm ów , opartych o nie m etod i zw iązanych z nim i narzędzi.
O dsyłam y zainteresow anego czy teln ika np. do [5] lub popularnego artykułu [11] i podanych tam referencji. Bardziej istotne je s t w yjaśnienie, czego po tych m etodach i narzędziach oczekujem y i na ja k ie trudności w ich stosow aniu napotykam y.
S pecyfikacja w ym agań, to zbiór tego, czego spodziew am y się po projektow anym system ie, ja k ie funkcje m a on spełnić i ja k ie w ym ierne efekty przynieść. Jest to w ięc, z grubsza rzecz biorąc, określenie problem u, który chcem y rozw iązać, poprzez zd efinio w anie je g o najw ażniejszych atrybutów . R ozw iązań w takim sform ułow aniu m oże nie być w cale (tzn. problem je st źle sfo rm u ło w any), m oże ich być kilka istotnie różnych, a naw et nieskończenie wiele. W ażne jest, żeby sform ułow anie w ym agań nie og raniczało nadm iernie m ożliw ości w yboru rozw iązania, ale też by w ykluczało rozw iązania, w sposób oczyw isty, nierozsądne. Jak się okazuje, je s t to trudne w potocznym rozum ieniu, czego dow odzą liczne przypadki nieporozum ień pom iędzy odbiorcam i, a projektantam i syste
m ów (nie tylko) inform atycznych. S form alizo
w anie w ym agań - to problem znacznie trudniejszy.
S pecyfikacja system ow a to, ja k pow ied zie
liśm y w yżej, określenie zasadniczej koncepcji rozw iązania problem u, zadanego poprzez specyfikacje w ym agań. O pis rozw iązania zależy w ogrom nym stopniu od ję z y k a , którym się p osługujem y. Pow iedzm y w ięc tylko, że taki opis chcielib yśm y traktow ać poniekąd, ja k program w ysokiego poziom u, w którym - w pierw szym przybliżeniu - nie zw racam y uwagi na szczegóły i ry g o ry realizacyjne, natom iast przyw iązujem y szc zeg ó ln ą w agę do w ypełnienia w szystkich w ym agań. P odejm u
je m y także zasadnicze decyzje ustalające:
POLSKIE TOWARZYSTW O INFORMATYCZNE — ODDZIAŁ GÓRNOŚLĄSKI
8 P io tr D em biń ski — Metody form alne w projektowaniu oprogramowaniu: mity i rzeczywistość
strukturę i h ie ra rc h ie elem entów pro jektow a
nego system u, rodzaj kom unikacji pom iędzy nim i itp.
Program (program y) w języ k u program o
w ania (takim , jak np. C lub C ++), to konkretna im plem entacja specyfikacji system ow ej, biorąca pod uwagę docelow y system kom pu
terow y i inne w ym ogi realizacyjne. M am y w ięc tutaj do czynienia ze zbiorem w ym agań im plem entacyjnych, np. dotyczących ograni
czeń czasow ych, różnych od tych z poziom u specyfikacji problem u. N iespełnienie tych w ym agań przez im plem entację m oże pow odo
wać konieczność zm iany specyfikacji system ow ej, a naw et niekiedy i w stępnych w ym agań, dotyczących definicji problem u.
Stąd iteracja etapów projektow ania.
M ając określone "produkty" poszczegól
nych etapów, łatw o je st przew idzieć to, w czym oczekujem y pom ocy i co chcielibyśm y autom atyzow ać. O ile trudno w yobrazić sobie, że sform ułow anie w ym agań m ogłoby autom atycznie generow ać specyfika
cję system ow ą - konieczne są tutaj zasadnicze w ybory i koncepcje, które nie m o g ą się obyć bez interwencji projektanta - to przejście od specyfikacji system ow ej do konkretnej reali
zacji program istycznej w ydaje się krokiem bliskim takiej (w spom aganej i, być m oże, niekom pletnej) autom atyzacji.
Podsum ow ując, m etody i narzędzia, których oczekujem y to:
• bogate, a jednocześnie łatw o czytelne i "przyjazne", form alizm y (techniki) definiow ania specyfikacji w ym agań i specyfikacji system ow ych oraz narzędzia w spom agające form ułow anie poprawnych i spójnych specyfikacji (edytory tekstow e i graficzne, anali
zator)' składni i sem antyki, system y w spom agające uzyskiw anie i dokum en
tację kolejnych wersji specyfikacji itp.);
• m etody i narzędzia w spom agające w eryfikację w ym agań (sform ułow anych na poziom ie specyfikacji w ym agań) przez specyfikacje system ow e;
• m etody i narzędzia generow ania kodu w docelow ym języ k u program ow ania bezpośrednio z zadanej specyfikacji system ow ej;
• m etody i n arzędzia w spom agające instalację, op tym alizację i testow anie otrzym anego kodu w konkretnej konfi
guracji kom puterow ej i program ow ej (system operacyjny, oprogram ow anie kom unikacyjne itp.). W dużym zakresie tego rodzaju narzędzia istnieją i są zw iązane z konkretnym językiem pro
gram ow ania (kom pilatory, debuggery, itp.) - w fazie urucham iania potrzebne są jed n ak na ogół dodatkow e zabiegi (często w ym ag ające interw encji czło
wieka, który system urucham ia) i specjalizow ane biblioteki procedur potrafiące skom pilow ane części specyfi
kacji system ow ej połączyć w je d n ą w yk on yw alną całość, w łączoną do istniejącego środow iska.
Jeżeli m ów im y o skom plikow anym opro
gram ow aniu system ow ym (protokole kom u
nikacyjnym , pow ażnej aplikacji itd.), to dodatkow e zabiegi - o których mowa w ostatnim punkcie pow yżej - oraz w m iarę kom pletne testo w an ie w rzeczyw istym środow isku, m o g ą pow ażnie w ydłużyć i podrożyć proces uzyskania zadow alającej im plem entacji. S pełnienie w ym agań im ple
m entacyjnych, np. w ydajnościow ych, jest, na ogół, bardzo trudne. W ym aga często w ielo
krotnego pow rotu i zm ian we w cześniejszych fazach projektow ania. W ydaje się więc zasadne dążenie do skrócenia każdego cyklu, poprzez m ożliw ość uzyskania estym acji param etrów im plem entacyjnych jeszcze przed w łaściw ą im p lem en tacją (w ykonyw alną instalacją) oprogram ow ania. Myśl to nie nowa, a osiągnięcie teg o celu m ożna uzyskać m odelując (specyfik ując) projektow any system razem ze środow iskiem , w którym przew idyw ane je s t je g o w ykonanie, a nastę
pnie analizując w ym agania im plem entacyjne bezpośrednio w tym m odelu za pom ocą środków anality czny ch lub sym ulacyjnych.
Jeżeli p rzyjm iem y takie rozw iązanie za istotny elem ent w y po sażenia projektanta, to do powyżej w ym ien io ny ch punktów dodam y:
• m etody i narzędzia analizy w ym agań im plem entacyjnych, np. czasow ych i w ydajnościow ych, na poziom ie specyfikacji system ow ych, lub na poziom ie pośrednim pom iędzy tak ą specyfikacją, a im plem entacją.
POLSKIE TOWARZYSTWO INFORMATYCZNE — O DDZIAŁ GÓRNOŚLĄSKI
Czternaste Jesienne Spotkania P T I M rągow o ’98 — 16-20 listopada 1998 9
W spółczesna inżynieria oprogram ow ania próbuje sprostać oczekiw aniom krótko scharakteryzow anym pow yżej. Istnieje wiele m odeli, form alizm ów , m etod i narzędzi.
T echnologiczny postęp, jaki dokonał się w ostatnim dziesięcioleciu, pozw ala realizo
wać zam ysły, o których nie m ożna było m arzyć jeszc ze niedaw no. Przykładem na to m oże być postęp jak i dokonał się w zastosow aniu tzw. m etody spraw dzania (w) m odelu (model checking), która służy autom atycznej w eryfikacji w łasności projekto
w anego system u zadanych w postaci pew nych form uł logicznych. M etoda ta, do pew nego stopnia, spełnia naiw ne m arzenie, które m ożna w ysłow ić następująco:
• "gdyby istniały niesłychanie szybkie i pojem ne (w sensie pam ięci) kom pute
ry, to dla każdego system u (program u) m ożna by spraw dzić za d an ą w łasność, przeglądając je g o pełny g ra f stanów ".
Taka rzeczyw iście je st zasadnicza m yśl tej m etody. M odelam i, o których tutaj m ow a, są zbiory (lub drzew a) obliczeń definiow ane przez taki g ra f stanów . Skończoność zbioru stanów daje się (częściow o) uzasadnić, jeśli pam iętam y, że zbiór w artości, które m ożem y reprezentow ać w kom puterze, je s t zaw sze ograniczony. Ł atw o jed n ak zauw ażyć, że liczba stanów rośnie bardzo szybko (w ykładni
czo) w stosunku do rozm iaru system u, szczególnie jeśli m ów im y o m odelach dla system ów rozproszonych i w spółbieżnych.
Czy więc m etoda je st zupełnie nierealna?
Okazuje się, że nie. Stosując w yrafinow ane techniki reprezentacji danych i redukcji przestrzeni stanów , w połączeniu z niew iary
godnym postępem technologicznym , obserw o
wanym ostatnio, okazuje się, że m ożna mieć nadzieję na praktyczne stosow anie tej m etody.
Dość pow iedzieć, że udaje się w eryfikow ać, w rozsądnym czasie, system y o liczbie stanów sięgającej lO2 ® (zob. np. [2]). Dla m etody w eryfikacji w m odelu naturalnym i p rzykła
dam i testującym i były układy logiczne i proste protokoły kom unikacyjne. W łasności w postaci form uł logicznych (tem poralnych, czy ogólniej m odalnych) stosunkow o dobrze pasują do definicji w ym agań w takich przykładach.
N ie będziem y tego tem atu tutaj rozw ijać i zainteresow anego czytelnika odsyłam y np.
do książki [7], gdzie znajdzie potrzebne referencje i przykłady dotyczące protokołów . Takie przykłady m o g ą napaw ać pew nym o ptym izm em , chociaż m etody form alne inżynierii op rogram ow ania dalekie są od pow szechnego stosow ania.
3. M etody form alne w projektow aniu protok ołów kom unikacyjnych
W krótkiej charakterystyce oczekiw anych m etod i narzędzi, w spom agających w ytw a
rzanie oprogram ow ania na początkow ych je g o etapach, skupiono uwagę na tych, które m ają charakter uniw ersalny, niezależny od d zie
dziny zastosow ań. Jak słusznie zauw ażają różni autorzy (np. P. Z ave w [4]), w ydaje się dzisiaj zupełnie niem ożliw e stw orzenie m etod i narzędzi rów nie pom ocnych w produkcji oprogram ow ania we w szystkich dziedzinach.
O gólne zasady, pow szechnie słuszne, nie zastąp ią w iedzy i dośw iadczenia inżynier
skiego, zw iązanego z w ybranym i zastosow a
niam i. Projektow anie protokołów' potw ierdza, naszym zdaniem , ten pogląd. W iele czynni
ków m iało w pływ na to, że m etody form alne dość w cześnie pojaw iły się w projektow aniu protokołów . N ie bez znaczenia je st tutaj fakt, że ta dziedzin a w ym aga, ja k m ało która, kodyfikacji i norm alizacji. N ie do przecenie
nia w tym kontekście je s t rola bazow ego m odelu (Basic Reference Model) OSI (Open Systems Interconnectioń) [10], nad którym pracę w ISO (International Standards Organization) rozpoczęto w połow ie lat siedem d ziesiątych, a ostatecznie upow szech
niono w form ie norm y w roku 1979. Za tym m odelem nastąpiło szybkie norm alizow anie protokołów' różnego poziom u.
W ysiłek norm alizacyjny spow odow ał, że w gronie specjalistów w ytw orzył się w m iarę w spólny zestaw pojęć, term inów , notacji i sposobów na w yrażanie podobnych w łasności. W standardach kom unikacyjnych stosuje się zestaw tych znanych środków', dobrze (na ogół) dostosow anych do sytuacji, co pow oduje, że zapis norm , w dużej części przecież nie form alny, stanow i dobry punkt odniesienia z chw ilą przejścia do definicji sform alizow anych. M odel OSI m a tę
POLSKIE TOW ARZYSTW O INFORMATYCZNE — ODDZIA Ł GÓRNOŚLĄSKI
10 P io tr D em biń ski — Metody form alne w projektowaniu oprogramowania: mity i rzeczywistość
w łaściw ość, że sytuuje i definiuje protokół kom unikacyjny - centralny obiekt sw ego zainteresow ania - w kontekście otoczenia (w arstw ow ego środow iska), w którym on będzie działał i jednocześnie określa je g o w yabstrahow aną rolę w tym kontekście, a m ianow icie usługę, którą protokół danej w arstw y, w raz z kontekstem niższych w arstw , oferuje użytkow nikow i w arstw y w yższej.
M am y więc w tym przypadku sytuację (z punktu w idzenia m etod inżynierii oprogram ow ania, w tym metod form alnych) koncepcyjnie niesłychanie klarowną: specyfi
kacja usługi protokolarnej pełni rolę specyfikacji w ym agań, a sam protokół, sprzężony z niższym i w arstw am i, m a stanow ić rozw iązanie spełniające te w ym agania.
D odatkow ym ułatw ieniem na tym poziom ie koncepcyjnym je s t fakt, że protokoły skupiają uwagę na sam ej kom unikacji (i jej jakości), nie w nikając w treść przesyłanej inform acji.
O brazow o rzecz ujm ując, w przesyłanych w iadom ościach pom iędzy użytkow nikam i i w interfejsach m iędzyw arstw ow ych intere
suje nas, jak postępow ać, spraw dzać i uzupełniać inform acje, podaw ane na kopercie listu, a nie to, co je st zaw artością koperty. W ym agania, dotyczące treści i form y inform acji na kopercie, m ogą być skodyfikow ane i znorm alizow ane, poniew aż ich interpretacja nie zależy od poszczególnego użytkow nika. Protokół, a także usługa protokolarna, określone zostają w zasadzie poprzez w ym ianę tak znorm alizow anych kom unikatów .
O pisy protokołów i ich usług - znorm alizo
wanych lub nie - w języku naturalnym (angielskim ), stanow ią podstaw ę specyfikacji w ym agań. M ożna pow iedzieć, że nic nie m oże ich całkow icie zastąpić na tym poziom ie i że zaw sze takie opisy będą dla człow ieka (a więc projektanta) punktem odniesienia i źródłem rozum ienia jakichkolw iek form alizm ów . Stosuje się tutaj także pew ne specyficzne notacje, tablice i diagram y stanów i przejść oraz przepływ u w iadom ości w czasie MSC (Message Sequence Charts) [6], C ałkow ita form alizacja w ym agań potrzebna je st w tedy, gdy m am y m ożliw ość ich w eryfikacji (najchętniej autom aty cznie - np. poprzez spraw dzanie m odelu, o którym w spom nieliśm y w cześniej) w tw orzonym
oprogram ow aniu. Próby takiej form alizacji są czynione i najczęściej w ykorzystuje się tutaj języ k i dla różnych odm ian logiki tem poralnej, tzn. takiej, w której m ożna w yrazić w łasności w iążące zdarzenia obliczeń w ich przeszłości, teraźniejszości i przyszłości. T rzeba od razu jed n ak zaznaczyć, że form alizm y logik tem poralnych tylko w pew nym stopniu w yrazić m o gą ograniczenia czasow e, które chcielibyśm y m óc reprezentow ać. Jednakże dośw iadczenia zdobyte przy w ykorzystaniu np. system u w eryfikacji SPIN [2] s ą w ielce obiecujące.
Prace norm alizacyjne i pojaw iające się przy nich trudności spraw iły, że stosunkow a w cześnie pow stał w ISO pom ysł zaprojekto
w ania specjalnych języ k ó w dla form ułow ania standardów usług i protokołów - języków ' w olnych od niejednoznaczności i niejedno
rodności, dotychczas używ anej m ieszaniny ję z y k a naturalnego z tw orzonym i ad hoc specjalnym i notacjam i. O koło 1980 roku pow stała w ISO, w której podjęto prace nad dw om a takim i języ k am i, reprezentującym i dwa różne podejścia do problem u specyfikacji:
jednym (E stelle) opartym na rozszerzonym pojęciu (kom unikujących się) autom atów i drugim (Lotos), którego podstaw ę stanow i algebra (kom unikujących się) procesów . W cześniej znany był ję z y k SDL - znorm a
lizow any przez C1TT - którego m odel m iał tę sam ą podstaw ę, co Estelle. W szystkie trzy razem w ystępują często pod w sp ólną nazw ą FDTs (Formal Description Techniques) [13], chociaż ostatnio ta nazw a staje się gen ery czn ą dla wielu innych, nie znorm alizow anych formalizmów'.
W końcu lat osiem dziesiątych zakończono prace norm alizacyjne nad tym i trzem a języ k am i (ostatnia w ersja SDL w roku 1992).
R ów nolegle, wokół tych języ k ó w , pow staw ał)' m niej lub bardziej prototypow e narzędzia, ułatw iające ich używ anie. O kazało się jedn ak, że przypisyw any początkow a cel po w itan ia FDTs polegający na chęci stopniow ego elim inow ania ję z y k a naturalnego z opisów norm , nie da się łatwo zrealizow ać, albo też nie je st to w istocie cel podstaw ow y. W coraz w iększym stopniu eksperym entow ano z tym i języ k am i, ja k niegdyś z języ k a m i program o
w ania w ysokiego poziom u. Traktow ano j e ja k o takie, na które w ygodnie je s t tłu m aczy ć
P O L S K IE T O W A R Z Y S T W O IN F O R M A T Y C Z N E — O D D Z IA Ł G Ó R N O Ś L Ą S K I
Czternaste Jesienne Spotkania P T I M rągowo '98 — 16-20 listopada 1998 11
nieform alne zapisy norm i jed n o cześn ie w ykorzystać, jak o podstaw ę do otrzym ania prototypow ych im plem entacji, których d ziałanie m ożna spraw dzić w środow isku rzeczyw istym lub sym ulacyjnym . Stąd też postulow ane przez nas usytuow anie tej klasy jęz y k ó w w kategorii specyfikacji system ow ej dla odróżnienia zarów no od języ k ó w specyfikacji w ym agań, jak też od pow szechnie używ anych języ k ó w program ow ania.
Jak pow iedzieliśm y uprzednio, języ k i poziom u system ow ego tylko w tedy będą praktycznie stosow ane jeżeli d ają się przekształcić (skom pilow ać) w w yrażenia ję z y k a program ow ania, takiego ja k C. Taka kom pilacja je s t potrzebna nie tylko, gdy chcem y protokół rzeczyw iście uruchom ić w w ęźle sieci, ale także gdy chcem y go w ykonyw ać, poprzez sym ulację w środow isku m odelow anym . Jednocześnie, nie m ożna w ym agać, by taka kom pilacja prow adziła do efektyw nych im plem entacji, poniew aż m echa
nizm y definicyjne na poziom ie specyfikacji system u nastaw ione są raczej na m odelow anie, a nie w ykonanie. Przy założeniu, że kom pila
to r działa popraw nie, otrzym ujem y je d n a k - w dużej części autom atycznie - działający popraw nie prototyp protokołu.
N a ogół, o efektyw ności im plem entacji przekonać się m ożem y dopiero po zainsta
low aniu otrzym anego oprogram ow ania w konkretnym środow isku kom puterow ym (sieciow ym ). Co m ożna zrobić, by przew id y
wać jeg o efektyw ność w cześniej, na etapie projektow ania? K lasyczną m eto d ą w takim przypadku je s t stw orzenie m odelu kolejko
w ego (queuing networks) dla środow iska im plem entacyjnego, zaw ierającego projekto
w any m oduł (np. protokół) i poddanie go analizie istniejącym i na rynku narzędziam i, specjalnie dostosow anym i do tego m odelu. To podejście m a swoje zalety, poniew aż m odel kolejkow y i stw orzone dla niego m etody analizy m ają ugruntow aną pozycję. M a jed n ak i tę w adę, że nie w ykorzystuje m odelu, w którym po w itała specyfikacja system ow a.
Z m u sza w ięc do pracy z dw om a m odelam i, których w zajem ną relację ustala, na ogół, intuicja i dośw iadczenie projektanta(ów ).
Istn ieją więc próby by istniejące narzędzia pracujące bezpośrednio na specyfikacjach w konkretnym język u (Estelle, SDL, Lotos
itp.), takie jak sym ulator, uzupełnić specjalnym i funkcjam i, na w zór tych przysto
sow anych do m odelu kolejkow ego, które pozw alają na różne oceny w ydajnościow e sym ulow anego system u. Takie narzędzia zaprojektow ano dla Estelle (ED T) [1]
i w pewnym stopniu dla SDL (S D T ) (zob.
[6]). W tym pierw szym przypadku stw-orzone były i następnie używ ane w projekcie COP 62, 0 którym piszem y w ięcej poniżej.
Proces projektow ania i im plem entacji protokołów zaw iera specyficzne zadania, których rozw iązanie w ym aga zarów no form alizacji, ja k i autom atyzacji. D w a takie specyficzne zadania charakteryzujem y poniżej.
Protokoły k om u nikacyjne słu żą w ym ianie inform acji zrozum iałej dla obu stron naw et wtedy, gdy m ó w ią one - stosując term inologię p otoczną - innym i języ k a m i. Aby to osiągnąć, trzeba pewnej um ow y, precyzującej sposób, w którym inform acje są zapisyw ane
1 jedn ozn aczn ego system u ich kodow ania (dekodow ania) w ciągi bitów, które ostatecznie przesyłane b ęd ą poprzez łącza fizyczne. Te w y m ag an ia w y m u szają ustalenie ogólnie przyjm ow anego standardu obu tych elem entów : zapisu na poziom ie struktury danych (abstract syntax) i na poziom ie kodu binarnego (concrete syntax). Elem entem łączącym te zapisy je s t jed n o zn aczn y system kodujący. Istnieje taki standard dla definio
w ania struktur danych, tzn. ję z y k A SN .l (Abstract Syntax Notation One - cyfra na końcu m a w yrażać m ożliw ość pow staw ania różnych, znorm alizow anych notacji) [8]
i sposób kodow ania je g o w yrażeń (Basic Encoding Rules) [9]. Jeżeli m yślim y 0 pew nym środow isku w spom agającym projektow anie protokołów , to nie m oże zabraknąć narzędzi w łaściw ego kodow ania 1 dekodow ania. Istn ieją próby integracji takich narzędzi z narzędziam i zw iązanym i z im ple
m entacją języ k ó w specyfikacji system ow ej.
Inną specy fik ą definicji protokołów i usług telekom unikacyjnych je s t dobre rozgranicze
nie pom iędzy ty m , co je s t w każdej im plem entacji danego protokołu konieczne, a tym , co pozostaw ione je s t do decyzji projektanta konkretnej jeg o w ersji (tzw.
profilu). T estow anie protokołu, na poziom ie
POLSKIE TOW ARZYSTW O INFORMATYCZNE — ODDZIAŁ GÓRNOŚLĄSKI
12 P iotr D em biń ski — Metody formalne w projektowaniu oprogramowania: mity i rzeczywistość
jego specyfikacji system ow ej, dotyczy spraw dzenia sem antycznej poprawności prze
kształcenia norm y, zapisanej nieform alnie w w yrażenie sform alizow ane. N a poziom ie im plem entacji m am y do czynienia z testam i, które w iążą się z n o rm alną praktyką progra
m istyczną i w y m ag a ją spraw dzenia jakości kodu w yprodukow anego przez kom pilator oraz tym i (conformance tests), które spraw dzają czy im plem entacja je st zgodna z deklarow anym profilem . Z naszego punktu w idzenia w ażne jest, że zaproponow ano sform alizow aną notację TTCN (Tree and Tabuiar Com bined Notation), służącą opisowi testów tego rodzaju i określono w ym agania na ich pow staw anie i stosow anie. Istnieją także pow ażne próby generacji testów w notacji TTCN bezpośrednio ze specyfikacji protokołu w wyżej w ym ienionych językach poziom u system ow ego. Podobnie ja k w poprzednim przypadku, stw arzając środow isko projektow a
nia protokołów kom unikacyjnych nie m ożna pom inąć zadania autom atyzacji pow staw ania, reprezentacji i generacji testów zgodności (zob. np.[12]).
W ym ienić m ożna je szc ze inne specyficzne cechy i w ym agania na specjalistyczne oprogram ow anie w interesującej nas dziedzinie. W ydaje się jednak, że krótka charakterystyka, którą przeprow adziliśm y, przekonuje do tego, że poprzez ograniczenie
się do projektow ania protokołów kom unikacyjnych otrzym ujem y istotne inform acje szczegółow e, które p o zw alają m ieć nadzieje, że m etody form alne kom puterow o w spom agane, m ogą dać efekty, na które trudno je s t liczyć, jeżeli m ów im y o oprogram ow aniu w ogóle, nie odnosząc się do specyficznej dziedziny zastosow ań. T rzeba jed n ak ja sn o pow iedzieć, że odległa je st jeszc ze perspektyw a stosow ania takiego system aty czn ego podejścia w pow szechnej praktyce.
N a zakończenie tego paragrafu pokazujem y na Rys. 3.1 schem at hipotetycznego, zintegrow anego system u, w spom agającego projektow anie i im plem entację protokołów kom unikacyjnych, który' byłby niejako próbą połączenia form alizm ów , m etod i narzędzi, opisanych krótko powyżej. Ze znanych autorow i system ów jed y n ie kilka zaw iera zaledw ie fragm enty tego schem atu o znacznym stopniu zintegrow ania. S ą to przede w szystkim narzędzia w okół ję z y k a SDL, np. SDT oferow any przez T elelogic ze Szw ecji i francuski GEOD E firm y Veri log (o narzędziach SDL zob. np. [6]) a także, w pew nym stopniu, EDT (Estelle Development Toolset) [1], W wielu innych system ach rozw inięte są tylko pojedyncze elem enty prezentow anego na rysunku schem atu.
PO L S K IE T O W A R Z Y S T W O IN F O R M A T Y C Z N E — O D D Z I A Ł G Ó R N O Ś L Ą SK I
Czternaste Jesienne Spotkania P T I M rągow o ’98 — 16-20 listopada 1998 13
Rys. 1. Schem at zintegrow anego system u projektow ania protokołów .
4. Przykład zastosow ania
C hcielibyśm y zakończyć te z natury rzeczy ogólne uwagi krótkim opisem etapów i w yników zakończonego ju ż projektu, m ającego na celu otrzym anie prototypow ej im plem entacji protokołu XTP (EXpress Transfer Protocol), w wersji 4.0 [14], bezpośrednio i (praw ie) autom atycznie otrzym anej z jeg o formalnej specyfikacji system ow ej, rów nież stworzonej w ram ach tego projektu. M ów im y tutaj o projekcie Kom isji Europejskiej Copernicus 62 pod nazw ą "High Speed Communication Systems Supporting M ultimedia Applications - Selected Issues" i realizow anym przez sześciu partnerów z czterech krajów (1T PW, 1P1 PAN i A lcatel z Polski. 1NT z Francji, PUB z Rum unii i UTC ze Słowacji). Projekt trw ał
dw a lata i zakończył się w kw ietniu 1997 roku.
Podajem y tutaj odw ołanie tylko do raportu końcow ego [3] tego projektu, w którym m ożna znaleźć dokładny opis jeg o w yników , listę raportów i ogólnie dostępnych publikacji na je g o tem at.
Pierw szym z zadań projektu było zainstalow anie na P olitechnice W arszaw skiej i Politechnice w Ż ilinie (S łow acja) szybkiej sieci typu FDDI, ja k o rzeczyw istego środow iska, w którym przeprow adzono by końcow e eksperym enty z przesyłaniem infor
macji m ultim edialnych pom iędzy w ęzłam i sieci z zain stalo w an ą w nich proto ty po w ą im plem entacją XTP, o której była m ow a powyżej.
POLSKIE TOWARZYSTWO INFORMATYCZNE — ODDZIAŁ GÓRNOŚLĄSKI
14 P iotr D em biń ski — Metody form alne w projektowaniu oprogramowania: mity i rzeczywistość
Specyfikacje w yjściow e protokołu pow sta
ły zarów no w Estelle ja k i SDL. Tw orzone były za pom ocą narzędzi z pakietu EDT (częściow o uzupełnianych w trakcie trw ania projektu) i SDT. P rzew agą specyfikacji w Estelle był fakt, że jej pierw sza wersja istniała w cześniej. Z a le tą specyfikow ania w SDL były rozbudow ane pom oce pakietu SDT dla tw orzenia opisu w form ie graficznej i jeg o dokum entacji. Z pow odu zbyt krótkiego czasu trw ania projektu eksperym ent, aż do uzyskania im plem entacji, kontynuow any był jedynie dla specyfikacji w wersji Estelle.
Specyfikacje w SDL, i w znacznie pow ażniejszym stopniu w Estelle, poddane zostały w eryfikacji m etodam i sym ulacyjnym i (a więc poniekąd testow aniu na poziom ie specyfikacji). Punktem odniesienia był doku
ment na tem at protokołu [14] oraz rów nolegle prow adzone prace studyjne nad zapropono
waniem definicji usług XTP (XTP service). Na tym etapie struktura specyfikacji bardziej odpow iadała logicznej i funkcjonalnej kon
strukcji sam ego protokołu niż potrzebom im plem entacji.
Prototypow a im plem entacja XTP została w ygenerow ana przy użyciu narzędzi EDT dla środow iska U N IX -ow ego. E ksperym enty przeprow adzono na stacjach roboczych typu SPARC 5/110.
Podstaw ow ym założeniem projektow ym była teza, że otrzym ana (praw ie) autom aty
cznie im plem entacja z oryginalnej specyfikacji będzie całkow icie nieefektyw na, w szczegól
ności dla potrzeb ruchu m ultim edialnego. Stąd zrodziło się drugie w ażne zadanie projektu:
zaproponow ać i przetestow ać m etodologię analizy w ydajnościow ej protokołu na pozio
mie jeg o specyfikacji, tak by jeszc ze przed im plem entacją przew idzieć je g o zachow anie, przy różnej intensyw ności ruchu w danym w ęźle i przy różnych obciążeniach pozostałych części sieci. Takie podejście w ym agało w ym odelow ania całego środow iska, w którym im plem entacja protokołu jest przew idziana (w tym przypadku w Estelle). W szczegól
ności w tym projekcie obejm ow ało to w ym odelow nie strum ieni ruchu m ultim e
dialnego po stronie aplikacji i ruchu w sieci pom iędzy jej w ęzłam i. Jako m odel ruchu m ultim edialnego przyjęto kom binację
strum ieni audio i video, przy czym dla tego drugiego w zorzec stanow ił znany form at M PEG.
O gólne w arunki m etodologiczne, dotyczące pow yższych w ym agań, zostały sform ułow ane najpierw m ak sym alnie niezależnie od rodzaju FDT i je g o narzędzi. Bardziej szczegółow y ich opis oraz dokum entacja przeprow adzonych analiz d oty czy ła specyfikacji XTP w Estelle.
W ażne w tym eksperym encie było przeko
nanie się, że przeprow adzone sym ulacje m ożna stosow ać (choć nie bez trudności) do rzeczyw istych protokołów i uzyskać pew ne inform acje, do tyczące zachow ania się im ple
m entacji w e w czesnym etapie projektow ania.
W w yniku przeprow adzonych sym ulacji (oraz w cześniej znanych cech języ k a Estelle), pierw otna specyfikacja XTP w kolejnych iteracjach była zm ien ian a i dostosow yw ana do w ym ogów im plem entacyjnych. O statecznie otrzym an o p ro to ty po w ą im plem entację znacznie efek ty w n iejszą (co nie znaczy, że efektyw ną) od tej, k tó rą m ożna by uzyskać ze specyfikacji w w-ersji oryginalnej. Co w ięcej, okazała się ona porów nyw alna efektyw nością z d o stęp ną im plem entacją XTP otrzy m an ą poprzez b ezpośrednie program ow anie w C.
U zyskano także cenne w skazów ki, dotyczące stosow anej m etodologii i jakości używ anych narzędzi.
P odsum ow ując, w ydaje się, że w yniki tego m iędzynarodow ego projektu są zachęcające i w skazują, że praktyczne rezultaty, które m ożna uzyskać, stosując form alne m etody inżynierii program ow ania, są w arte zainteresow ania.
5. Uwagi końcow e
N iniejszy artykuł próbow ał usytuow ać m etody form alne zarów no w kontekście historycznym , ja k i w odniesieniu do w spółczesnych uw arunkow ań. Celem tych uw ag było w skazanie w łaściw ego m iejsca tych m etod i rozw ażnej oceny m ożliw ości ich stosow ania. S kupienie uwagi na w ykorzysta
niu m etod form alnych w praktyce projektow ania protokołów kom unikacyjnych pokazuje, że szczególne potrzeby każdej dziedziny i uw zględnienie w iedzy zgrom adzo
nej latam i przez specjalistów prowadzi do
P O LS KIE T O W A R Z Y S T W O IN F O R M A T Y C Z N E — O D D Z IA Ł G Ó R N O Ś L Ą S K I
Czternaste Jesienne Spotkania PTI M rągow o ’98 — 16-20 listopada 1998 15
metod bardziej przydatnych i efektyw nych.
Z drugiej strony, obserw acja rozw oju inżynierii oprogram ow ania w tej szczególnej dziedzinie potw ierdza ogólne tendencje.
W coraz w iększym stopniu uwaga projektantów dużych system ów skupia się na początkow ych fazach projektow ania - one są bow iem decydujące dla jeg o żyw otności
i jak o ści - a więc elem entach, które decydują także o efektach ekonom icznych.
N aw iązując na koniec do tytułu tej pracy, m ożna pow iedzieć, że mity', ja k zw ykle, nie zn ajd u ją potw ierdzenia w rzeczyw istości, ale jed n o cz eśn ie trzeba jeszcze w iele w ysiłku,
żeby rzeczyw istość nie ulegała m itologii.
POLSKIE TOWARZYSTW O INFORMATYCZNE — ODDZIAŁ GÓRNOŚLĄSKI
16 P io tr D em biń ski — Metody form alne k> projektowaniu oprogramowania: mity i rzeczywistość
L iteratura
[1], S. B udkow ski, Estelle D evelopm ent T oolset, C o m puter N etw orks and ISDN System s, Vol.
25, N o 1, 1992
[2]. R. Burcb, E. M. Clarke, K. L. M cM illan, D. L. Dill, L. J. H w ang, Sym bolic M odel C hecking: 10-0 states and beyond, Inform ation and C om putation, 98(2). 1992 [3], C O P 62, High Speed C om m unication S ystem s S upporting M ultim edia A pplications -
Selected Issues, Final Project R eport C O P 62/5, EC INCO Program m e, 1997 [4], J-P. C ourtiat, P. D em biński, G.J. H olzm ann, L. L ogrippo, H. Rudin, P. Zave, Form al
m ethods after 15 years: Status and trends, C o m puter N etw ork and ISDN System s, Vol. 28.
N o 13, 1996
[5]. M. Flasiński, W stęp do analitycznych m etod projektow ania system ów in form atycznych, W N T W arszaw a, 1997
[6]. O. Haugen (ed.), SDL and M SC, Special Issue, C om puter N etw orks and ISDN System s, V ol. 29, N o ¡3, 1996
[7], G. J. H olzm ann, Design and V alidation o f C om puter Protocols. Prentice-H all International, 1991
[8]. ISO 8824, Inform ation processing system s - O pen S ystem s Interconnection - S pecification o f A bstract Syntax N otation O ne (A S N .l), G eneva 1987
[9], ISO 8825, Inform ation processing system s - O pen System s Interconnection - S pecification o f Basic E ncoding Rules for A bstract Syntax N otation O ne (A S N .l), G eneva 1987 [10]. ISO 7498, Inform ation processing system s - O pen System s Interconnection - Basic
Reference M odel, G eneva 1984
[11], M. Piechów ka, S. Szejko, CA SE, ja k i je st, każdy w idzi. In form atyka 4, 1998
[12]. 0 . Rafiq, A. R. Cavalli (eds.), P rotocol T esting, Special Issue, C om puter N etw o rk s and ISDN System s, Vol. 28, N o 1, 1996
[13]. K. J. T urner (ed.) U sing Formal D escription T echniques. An Introduction to Estelle, Lotos and SDL, W iley 1993
[14]. XTP Forum , Xpress Transport Protocol Specification. XTP R e v is io n 4 .0 , 1995
P OLS KIE T O W A R Z Y S T W O IN F O R M A T Y C Z N E — O D D Z I A Ł G Ó R N O Ś L Ą S K I
Czternaste Jesienne Spotkania P T I M rągowo ’98 — 16-20 listopada 1998 17
Janusz Zalewski
Dept, o f Electrical & Computer Engineering University o f Central Florida
Orlando, FL 32816, USA (407)823-6171 jza@ ece. engr. ucf.edu
Systemy czasu rzeczywistego -projektow anie i aspekty praktyczne
Streszczenie. W artykule przedstawiono wybrane elementy charakterystyki
systemów czasu rzeczywistego z punktu widzenia projektowania. Omówiono metody specyfikówania i projektowania oraz implementacji tych systemów, uwzględniając elementy języków programowania czasu rzeczywistego, właściwości ją d ra systemu operacyjnego czasu rzeczywistego i architektury sprzętowe stosowane w takich systemach.
1. W prow adzenie
System czasu rzeczyw istego je s t to system kom puterow y o ograniczonym , narzuconym z góry, czasie reakcji. Jego istotą są ograni
czenia czasow e, term iny (ang. deadline), na w ykonanie odpow iednich operacji obliczenio
wych. Ten fakt pow oduje, że konstruow anie system ów czasu rzeczyw istego je s t zasadniczo odm ienne od konstruow ania system ów przeznaczonych do innych zastosow ań, np. w zarządzaniu lub handlu. N iezbędne je st więc opracow anie nowych m etod w ytw arzania system ów , uw zględniających uw arunkow ania czasow e.
O statnia znana mi książka w języ k u polskim na ten tem at została opublikow ana w 1988 roku [17], a bieżące publikacje w m iesięczniku Informatyka, znakom ite w' pom yśle i w treści, aczkolw iek nie zaw sze aktualne, dow odzą, że je st duże zapotrzebow a
nie na w iedzę z tej dziedziny. Z pew nością, w arto więc polskim czytelnikom przedstaw ić
uzupełniające inform acje o aktualnym stanie technologii system ów czasu rzeczyw istego.
Z praktycznego punktu w idzenia, do przedstaw ienia w iedzy o system ach czasu rzeczyw istego w ygodne je s t podejście hierar
chiczne. Punktem w yjścia je s t stw ierdzenie i zrozum ienie faktu, że w ytw arzanie system ów czasu rzeczyw istego odbyw a się zgodnie z zasadam i tradycyjnego cyklu istnienia system ów kom puterow ych (ang. system lifecycle): od specyfikow ania, przez projekto
wanie, do im plem entow ania itd.
Na każdym z tych etapów potrzebny jest.
jed n ak , zasadniczo odm ienny rodzaj techn o
logii. D latego celow e w ydaje się p rzedstaw ie
nie ich w sposób zstępujący, jak na tys. 1, gdzie oprócz poziom u specyfikow ania i proje
ktow ania, w yróżniono trzy poziom y im plem entacyjne: języ k i program ow ania czasu rzeczyw istego, jąd ro system u operacyjnego czasu rzeczy w isteg o i architektury sprzętow e.
POLSKIE TOW ARZYSTWO INFORMATYCZNE — ODDZIAŁ GÓRNOŚLĄSKI
18 Jan u sz Z alew ski — S ystem y czasu rzeczyw istego - p ro jek to w a n ie i aspekty p ra k tyczn e
Specyfikow anie i p ro jek tow an ie
Języki p rog ram o w an ia system ów cz.rz.
J ą d ro system u operacyjnego cz. rz.
A rc h ite k tu ry sprzętow e
Fig. 1. H ierarchiczne podejście do system ów czasu rzeczyw istego.
Taki podział tem atyki odpow iada rzeczy
wistym problem om spotykanym w w ytw arza
niu system ów czasu rzeczyw istego do poszczególnych zastosow ań. W praktyce bo
w iem , w szystkie rodzaje zastosow ań w czasie rzeczyw istym , np. system y kom unikacyjne czasu rzeczyw istego, bazy danych czasu rzeczyw istego, system y ekspertow e czasu rzeczyw istego itp., w ym agają bardzo podobnych technologii w ytw arzania. Zgodnie z tym podziałem hierarchicznym , artykuł podzielono na części przedstaw iające w ybrane zagadnienia technologii odpow iadające każdem u z w ym ienionych poziom ów .
2. S pecyfik ow an ie i projektow anie
Celem specyfikacji jest, na ogół, w yrażenie w łaściw ości funkcjonalnych konstruow anego system u. W system ach czasu rzeczyw istego, chodzi dodatkow o o w yrażenie w łaściw ości odm iennych od funkcjonalnych, głów nie czasow ych (zw anych rów nież tem poralnym i), a także niezaw odnościow ych, bezpieczeństw a itp. A czkolw iek, pow stało dotychczas w iele m etod specyfikow ania system ów czasu rzeczyw istego, w szczególności, w iele tzw . m etod form alnych [8, 13], niewiele z nich nadaje się do zastosow ań praktycznych
i w w iększości pozostają one w stadium eksperym entalnym .
Spośród m etod, które uczyniły stosunkow o najw iększy postęp w ostatnich latach warto w ym ienić następujące:
• logika tcm poralna [ 16]
• m etody synchroniczne [7]
• system y hybrydow e [5],
Inne m etody form alne, naw et te od dawna rozw ijane, ja k sieci Petriego lub CCS, dosto
so w u ją się do w ym agań sy stem ów czasu rzeczyw istego bardzo powoli [10, 14],
Z anim jed n ak m etody form alne zaczną odgryw ać w ięk szą rolę w specyfikow aniu i projektow aniu system ów czasu rzeczyw iste
go, co niew ątpliw ie nastąpi w przyszłości, inżynierom i projektantom potrzebne są techniki praktyczne. A utor artykułu jest zw olennikiem podejścia inżynierskiego, opartego na pojęciach techniki sterow ania, uw zględniającego także m etody form alne.
C entralnym elem entem tego podejścia jest potraktow anie system u czasu rzeczyw istego ja k o system u sterow ania [9], W szystkie znane dotąd autorow i system y czasu rzeczyw istego d adzą się um ieścić w tym schem acie, przedstaw ionym szkicow o na rys. 2.
POLS KIE T O W A R Z Y S T W O I N F O R M A T Y C Z N E — O D D Z I A Ł G Ó R N O Ś L Ą S K I
Czternaste Jesienne Spotkania P T I M rągowo '98 — 16-20 listopada 1998 19
Rys. 2. Ilustracja podstaw ow ego problem u sterow ania: (1) w artość zadana; (2) kom endy kontrolera;
(3) w ielkości sterow ane; (4) inne w ielkości m ierzone; (5) sprzężenie ze środow iskiem
G łów ne kategorie system ów czasu rzeczy
w istego pozostają w pełnej zgodności ze schem atem na rys. 2. w zależności od połącze
nia kontrolera z obiektem , tzn.:
• system y zbierania danych, gdzie połą
czenie oznaczone przez (2) nie istnieje, p o n ie w a ż brakuje na ogół elem entów sterow ania (np. w system ie m onitorow ania pacjenta na sali operacyjnej)
• system sterow ania program ow ego, gdzie połączenia oznaczone przez (3) i (4) nie istnieją, g d y ż brakuje sprzężenia z w ro tn e go (np. w sterow niku św iateł uliczn y ch )
• pełny system sterow ania, g d zie w szy stk ie połączenia są konieczne (np. w system ie sterow ania lotem sam olotu).
Z takiego przedstaw ienia system u czasu rzeczyw istego łatw o w yw nioskow ać, że kontroler kom unikuje się z otoczeniem , za pośrednictw em co najwyżej (zależnie od zastosow ania) czterech rodzajów urządzeń zew nętrznych, którym i są:
• w ejścia/w yjścia z/do obiektu
• term inal użytkow y
• pam ięć m asow a
• sieć kom puterow a.
W szystkie te elem enty trzeba odpow iednio uw zględnić w projektow aniu, co prow adzi do ogólnego schem atu kontekstu kontrolera, przedstaw ionego na rys. 3.
Sieć kom p u tero w a
Rys. 3. O gólny schem at kontekstu kontrolera w system ie czasu rzeczyw istego.
POLSKIE TOWARZYSTWO INFORM ATYCZNE— ODDZIAŁ GÓRNOŚLĄSKI
