Specyfikacja formalna

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 9 Slide 1

Specyfikacja formalna

Przedstawienie metod specyfikacji formalnej, których można użyć do uszczegóławiania specyfikacji wymagań systemowych,


Cele Wiedzieć, dlaczego metody specyfikacji formalnej

pomagają w znajdowaniu błędów w wymaganiach systemowych.

Znać ryzyko związane z używaniem metod algebraicznych specyfikacji formalnej do definiowania specyfikacji interfejsów.

Wiedzieć, jak do specyfikacji zachowania można użyć metod formalnych opartych na modelach.


Zawartość Specyfikacja formalna w procesie tworzenia

oprogramowania Specyfikacja interfejsu Specyfikacja zachowania


Metody formalne Analiza matematyczna stanowi rutynową składową procesu

opracowywania i zatwierdzania projektu produktu. Tak zwane „metody formalne” budowy oprogramowania

nie są szeroko stosowane w przemysłowym wytwórstwie oprogramowania.

Pojęcie „metod formalnych” obejmuje: • specyfikowanie formalne systemu,

• analizowanie i dowodzenie specyfikacji,

• proces tworzenia z przekształceniem,

• weryfikowanie programów.


Problemy z akceptacją Przewidywania, że w XXI wieku duża część

oprogramowania powstaje z użyciem metod formalnych nie sprawdziła się z powodów:• sukcesów inżynierii oprogramowania,• zmiany rynku,• ograniczonego zasięgu metod formalnych,• ograniczonej skalowalności metod formalnych.


Użycie metod formalnych Specyfikacja formalna jest doskonałym sposobem na

wykrycie błędów w specyfikacji i przedstawienie specyfikacji systemu w sposób jednoznaczny.

W systemach, w których nie można dopuścić do awarii, użycie metod formalnych może być uzasadnione i opłacalne.

Metody formalne są coraz częściej stosowane w wyspecjalizowanej dziedzinie tworzenia systemów krytycznych.


Specyfikacja formalna w procesie tworzenia oprogramowania

Nie obejmuje detali implementacyjnych, ale powinna stanowić pełny model matematyczny systemu.

We wczesnych etapach procesu najważniejsza jest specyfikacja nastawiona na użytkownika.

Końcowy etap procesu, który obejmuje stworzenie pełnej, spójnej i precyzyjnej specyfikacji, jest jednak zasadniczo zadaniem zleceniobiorcy. Stanowi on podstawę implementacji systemu. Ta precyzyjna specyfikacja może być specyfikacja formalną.


Specyfikowanie i projektowanie Rosnący udział zleceniobiorcy

Malejący udział klienta

Definiowaniewymagań

użytkownika

Specyfikowaniewymagań

systemowych

Projektowaniearchitektoniczne

Specyfikowanieformalne

Projektowaniena wysokim

poziomie

Specyfikowanie

Projektowanie


Specyfikowanie formalne w procesie budowania oprogramowania

Definiowaniewymagań

użytkownika

Modelowanie systemu

Specyfikowanieformalne

Specyfikowaniewymagań

systemowych

Projektarchitektoniczny

Projektowanie nawysokim poziomie


Dwa podejścia do specyfikacji formalnej

Podejście algebraiczne

• Opisuje się system w kategoriach operacji i związków.

Podejście oparte na modelach• Buduje się model systemu za pomocą pojęć

matematycznych, takich jak zbiory i ciągi. Operacje systemu definiuje się przez wywoływane przez nie zmiany stanu systemu.


Języki specyfikacji formalnej

Sekwencyjne Współbieżne

Algebraiczne Larch (Guttag i inni, 1995, 1993) Lotos (Bolognesi OBJ (Futatsugi i inni, 1995) i Brinksma, 1987)

Oparte na Z (Spivey, 1992) CSP (Hoare, 1995)

modelach VDM (Jones, 1980) Sieci Petriego (Peterson, 1981)

B (Wordsworth, 1996)


Użycie specyfikacji formalnej Zwiększa początkowe koszty budowy oprogramowania. Gdy zastosuje się konwencjonalny proces, koszty

zatwierdzania stanowią 50% kosztu budowania, a koszty implementacji i projektowania są wyższe niż koszty specyfikowania.

Jeżeli użyje się specyfikacji formalnych, to koszty specyfikowania i implementacji są porównywalne, ale koszty zatwierdzania są znacząco obniżone.

Opracowanie specyfikacji formalnej umożliwia wykrycie błędów w wymaganiach, unika się więc powtarzania prac w celu poprawienia tych błędów po zaprojektowaniu systemu.


Koszty budowania oprogramowania ze specyfikacją formalną

Bez specyfikacji formalnej

Ze specyfikacją formalną

Koszt

Specyfikowanie

Projektowaniei implementacja

Zatwierdzanie

Specyfikowanie

Projektowaniei implementacja

Zatwierdzanie


Składowe specyfikacji Wstęp

• Deklaruje się rodzaj (nazwę typu) specyfikowanego bytu. Część opisowa

• Nieformalnie przedstawia się operacje. Część sygnaturowa

• Definiuje składnię interfejsu klasy obiektów lub abstarkcyjnego typu danych.

Część aksjomatyczna• Definiuje znaczenie operacji przez podanie zbioru aksjomatów,

które charakteryzują zachowanie abstrakcyjnego typu danych.


Struktura specyfikacji algebraicznej

< NAZWA SPECYFIKACJI>

rodzaj < nazwa>imports <LISTA NAZW SPECYFIKACJI>

Nieformalny opis rodzaju i jego operacji

Sygnatury operacji ustalające ich nazwy i typy parametrów

Aksjomaty definiujące operacje na tym rodzaju


Klasy operacji na abstrakcyjnym typie danych

Operacje konstruktorowe, które tworzą lub modyfikują byty rodzaju definiowanego w specyfikacji. Zwykle maja nazwy takie jak Utwórz, Zmień, Dodaj albo tak jak w tym wypadku Kons znaczące konstruuj.

Operacje inspekcyjne, które obliczają atrybuty rodzaju zdefiniowanego w specyfikacji. Zwykle ich nazwy odpowiadają nazwom atrybutów lub mają nazwy takie jak Oblicz, Pobierz.


Specyfikacja listy Operacjami konstruktorowymi są Utwórz, Kons i Ogon,

które budują listy.

Operacjami inspekcyjnymi są Głowa i Długość, które służą do odczytu atrybutów listy.

Nie ma więc potrzeby definiowania aksjomatów operacji Ogon dla operacji Głowa i Długość, natomiast operacja Ogon musi być zdefiniowana za pomocą konstruktorów podstawowych.


Prosta specyfikacja listyLISTA (Elem)

rodzaj Lista imports INTEGERDefiniuje listę, do której dodaje się elementy na końcu, a usuwa na początku.Operacjami są Utwórz, która powoduje utworzenie pustej listy, Kons, która tworzy nową listę z dodatkowym elementem, Długość, która wyznacza długość listy, Głowa, która podaje pierwszy element na liście, i Ogon, która tworzy nową listę przez usunięcie głowy ze swojej listy wejściowej. Niezdefiniowane reprezentuje niezdefiniowaną wartość typu Elem.Utwórz ListaKons (Lista, Elem) ListaGłowa (Lista) ElemDługość (Lista) IntegerOgon (Lista) ListaGłowa (Utwórz) = Niezdefiniowane exception (lista pusta)Głowa (Kons (L, w)) = if L = Utwórz then w else Głowa (L)Długość (Utwórz) = oDługość (Kons(L, w)) = Długość (L) + 1Ogon(Utwórz) = UtwórzOgon (Kons (L, w)) = if L = Utwórz then Utwórz else kons (Ogon (L), w)


Specyfikacje rekurencyjne

W specyfikacjach algebraicznych często używa się rekurencji. Wartością operacji Ogon jest lista utworzona przez wzięcie listy

wejściowej i usunięcie jej głowy. W definicji operacji Ogon pokazano, jak używać rekurencji do

budowy specyfikacji algebraicznych.Ogon ([5, 7, 9]) = Ogon (Kons ([5, 7], 9)) =

Kons (Ogon ([5, 7, 9])) = Kons (Ogon (Kons ([5]), 7)), 9)

= Kons (Kons (Ogon ([5]), 7, 9) =

Kons (Kons (Ogon (Kons ([], 5)), 7), 9) =

Kons (Kons (Utwórz, 7), 9) = Kons ([7], 9) = [7, 9]


System kontroli lotów

Załóżmy, że w systemie kontroli lotów zaprojektowano obiekt reprezentujący sektor kontrolowanej przestrzeni powietrznej.

Każdy taki sektor może zawierać kilka samolotów, z których każdy ma inny identyfikator.

Ze względów bezpieczeństwa samoloty muszą być od siebie oddalone o co najmniej 300 metrów w pionie.

System ma ostrzec kontrolera, gdy nastąpi próba umieszczenia samolotu, który łamie te ograniczenia.


Operacje na obiekcie-sektorze Krytyczne operacje, które można na tym obiekcie

wykonywać:• Wejście. Ta operacja dodaje samolot (reprezentowany

przez identyfikator) do przestrzeni powietrznej na podanej wysokości.

• Wyjście. Ta operacja usuwa wskazany samolot z kontrolowanego sektora.

• Przestrzeń. Ta operacja przesuwa samolot z jednej wysokości na inną.

• Znajdź. Ta operacja podaje bieżący pułap samolotu o zadanym identyfikatorze w podanym sektorze.


Proste operacje Łatwiej będzie wyspecjalizować te operacje, jeśli

wprowadzimy kilka innych operacji interfejsu:• Utwórz. Reprezentuje on sektor, w którym nie ma ani jednego

samolotu.• Umieść. Dodaje samolot do sektora bez sprawdzania

skojarzonych z nim ograniczeń.• W-przestrzeni. Dla zadanego sygnału rozpoznawczego samolotu

ta operacja przekazuje wartość logiczna prawdy, jeśli samolot jest w kontrolowanym sektorze, i fałsz w przeciwnym wypadku.

• Zajęta. Dla zadanej wysokości ta operacja przekazuje wartość logiczną prawdy, jeśli w trzystumetrowym otoczeniu tej wysokości znajduje się jakikolwiek samolot, i fałsz w przeciwnym wypadku.

Specyfikacja kontrolowanego sektora

SEKTORrodzaj Sektorimports INTEGER, BOOLEAN

Wejście - dodaje samolot do sektora, o ile zachowane są ograniczenia bezpieczeństwaWyjście - usuwa samolot z sektoraPrzesuń - przenosi samolot z jednej wysokości na inną, o ile jest to bezpiecznieZnajdź - podaje wysokość samolotu w sektorze

Utwórz – tworzy pusty sektorUmieść – dodaje samolot do sektora bez sprawdzania ograniczeńW-przestrzeni – sprawdza, czy samolot jest już w sektorzeZajęta – sprawdza, czy podana wysokość jest dostepna

Wejście (Sektor, Sygnał, Wysokość) SektorWyjście (Sektor, Sygnał) SektorPrzesuń (Sektor, Sygnał, Wysokość) SektorZnajdź (Sektor, Sygnał) Sektor

Utwórz SektorUmieść (Sektor, Sygnał, Wysokość) SektorW-przestrzeni (Sektor, Sygnał) BooleanZajęta (Sektor, Wysokość) Boolean

Wejście (Sek, Syg, W) = if W-przestrzeni (Sek, Syg) then Sek exception (Samolot już jest w sektorze elsif Zajęta (Sek, W) then Sek exception (Komunikat wysokości) else Umieść (Sek, Syg, W)

Wyjście (Utwórz, Syg) = Utwórz exception (Samolotu nie ma w sektorze)Wyjście (Umieść (Sek, Syg1, W1), Syg) = if Syg = Syg1 then Sek else Umieść (Wyjście (Syk, Syg), Syg1, W1)

Przesuń (Sek, Syg, W) = if Sek = Utwórz then Utwórz excepition (w sektorze nie ma żadnego samolotu) elsif not W-przestrzeni (Sek, Syg) then Sek exception (Samolotu nie ma w sektorze) elsif Zajęta (Sek, W) then Sek exception (Konflikt wysokości) else Umieść (Wyjście (Sek, Syg), Syg, W)

-NIE-WYSOKOŚĆ oznacza, że nie da się przekazać sensownej wysokości

Znajdź (Utwórz, Syg) = NIE-WYSOKOŚĆ exception (Samolotu nie ma w sektorze)Znajdź (Umieść (Sek, Syg1, W1), Syg) = if Syg = Syg1 then W1 else Znajdź (Sek, Syg)

Zajęta (Utwórz, W) = falseZajęta (Umieść (Sek, Syg1, W1), W) = if (W1 > W and W1 – W <=300) or (W > W1 and W – W1 <= 300) then true else Zajęta (Sek, W)

W-przestrzeni (Utwórz, Syg) = falseW-przestrzeni (Umieść (Syk, Syg1, W1), Syg) = if Syg = Syg1 then true else W-przestrzeni (Sek, Syg)


Specyfikacje oparte na modelach

Alternatywnym podejściem do specyfikacji formalnych, które powszechnie stosowano już w przedsięwzięciach przemysłowych, są specyfikacje oparte na modelach.

W notacji Z system jest modelowany za pomocą zbiorów i relacji między zbiorami. Z rozszerza pojęcia matematyczne o konstrukcje szczególnie przydatne w specyfikacji oprogramowania.


Struktura schematu Z

Nazwa schematu Sygnatura schematu Predykat schematu

Zbiornik

zawartość: N pojemność: N

zawartość ≤ pojemność


Diagram blokowy pompy insulinowej

Zbiornik insuliny

Zasilanie

Sterownik

Pompa

Miernik

Igła

Alarm

Wyświetlacz 2

Wyświetlacz 1

Zegar


Modelowanie pompy insulinowej Stan wymodelowano za pomocą kilku zmiennych

stanowych:• odczyt?• dawka, dawka_całkowita• o0, o1, o2• zapas• alarm!• pompa!• wyświetlacz1!, wyświetlacz2!


Niezmienniki schematu Z schemat definiuje niezmienniki, które są zawsze

spełnione. Warunki nałożone na schemat pompy insulinowej, które

musza być zawsze spełnione to:• Dawka nie może być większa niż zapas, tzn. nie da podać

więcej insuliny niż obecnie jest w zbiorniku.

• Żadna dawka nie może być większa niż 5 jednostek insuliny, a całkowita dawka podana w okresie nie może przekroczyć 50 jednostek. Są to warunki bezpieczeństwa.

• Wartość zmiennej wyświetlacz1! Jest komunikatem o stanie zbiornika insuliny.


Schemat pompy insulinowejPompa insulinowa

odczyt? : Ndawka, dawka_całkowita : No0, o1,o2 : N // służą do przechowywania ostatnich trzech odczytówzapas : Nalarm! : {włączony, wyłączony}pompa! : Nwyświetlacz1!, wyświetlacz2! : STRING

dawka <= zapas ^ dawka ,<= 5 ^ dawka_całkowita <= 50zapas >= 40 wyświetlacz1! = ” ”zapas >= 39 ^ zapas >= 10 wyświetlacz1! = „Niski poziom insuliny”zapas <= 9 alarm! = „włączony” ^ wyświetlacz1! = „Bardzo niski poziom insulinyo2 = odczyt?


Obliczanie dawkowania

Pompa insulinowa sprawdza poziom glukozy we krwi co 10 minut i (w uproszczeniu) podaje insulinę, jeśli tempo zmiany poziomu glukozy rośnie.

Ilość insuliny do wstrzyknięcia jest obliczana, tak jak pokazano na schemacie DAWKOWANIE.

Jeśli tempo zmiany jest stałe, to podaje się stałą ilość insuliny.

Na podstawie tego schematu można wywnioskować, że istnieją różne sytuacje wpływające na wielkość dawki.


Schemat DAWKOWANIE

DAWKOWANIEΔPompa_insulinowa

(dawka = 0 ^ ( ((o1 >= o0) ^ (o2 = o1)) v ((o1 > o0) ^ (o2 <= o1)) v ((o1 < o0) ^ ((o1 – o2) > (o0 – o1)) ) vdawka = 4 ^ ( ((o1 <= o0) ^ (o2 = o1) v ((o1 < o0) ^ ((o1 – o2) <= (o0 – o1))) ) vdawka = (o2 – o1) * 4 ^ ( ((o1 < o0) ^ (o2 > o1)) v ((o1 < o0) ^ ((o1 – o2) >= (o0 – o1))) ))zapas’ = zapas – dawkadawka_całkowita’ = Dawka_całkowita + dawkao0’ = o1 ^ o1’ = o2


Schematy opisujące dane wyjściowe

Wymodelowano wyświetlacze maszyny i wbudowany alarm.

W schemacie WYŚWIETLANIE stwierdzono, że wyświetlacz2! Pokazuje obliczoną dawkę (Liczba_na_napis to funkcja konwersji)

Wyświetlacz1! Pokazuje komunikat ostrzegawczy, albo słowo „OK”.

W schemacie ALARM ustalono warunki, w których alarm jest uruchamiany. Włącza się go, gdy odczyt poziomu glukozy jest zbyt niski (mniej niż 3) lub zbyt wysoki (więcej niż 30).


Schematy wyjściowe WYŚWIETLANIEΔPompa_insulinowa

wyświetlacz2!’ = Liczba_na_napis(dawka) ^odczyt? <3 wyświetlacz1! = „Niski poziom cukru”odczyt? <30 wyświetlacz1! = „Wysoki poziom cukru”odczyt? >= 3 ^ odczyt? <= 30 wyświetlacz1! = „OK”

ALARMΔPompa_insulinowa

(odczyt? < 3 v odczyt? > 30) alarm!’ = włączony(odczyt? >= 3 ^ odczyt? <= 30) alarm!’ = wyłączony


Sprawdzenie wewnętrznej zgodność systemu W ogólnym schemacie Pompa_insulinowa napisano, że

wyświetlacz1! Powinien wskazywać stan zbiornika insuliny.

W schemacie WYŚWIETLANIE stwierdzono jednak, że ten wyświetlacz ma pokazywać różne komunikaty ostrzegawcze lub informację, że poziom glukozy we krwi mieści się w akceptowalnym przedziale. Występuje tu konflikt.

Wyjawienie problemów, które należy rozwiązać, jest jedną z głównych zalet stosowania specyfikacji formalnych.


Główne tezy Metody specyfikacji formalnej systemów uzupełniają metody

specyfikacji nieformalnej. Można ich użyć do udoskonalenia szczegółowej, ale specyfikacji nieformalnej wymagań systemowych. Pomagają zatem w zasypaniu przepaści między wymaganiami, a projektowaniem.

Specyfikacje formalne są dokładne i jednoznaczne. Usuwają ze specyfikacji obszary wątpliwe i pozwalają uniknąć niektórych problemów z niewłaściwą interpretacją języka. Niespecjaliści mogą mieć jednak trudności ze zrozumieniem specyfikacji formalnych.

Zasadniczą korzyścią z zastosowania metod formalnych w procesie budowania oprogramowania jest wymuszanie analizy wymagań systemowych już we wczesnej fazie. Poprawianie błędów w tej fazie jest tańsze niż modyfikacja gotowego systemu.


Główne tezy Metody specyfikacji formalnej najbardziej przydają się przy

budowaniu systemów krytycznych, w których bezpieczeństwo, niezawodność i zabezpieczenia są szczególnie istotne. Można ich także użyć do określania standardów.

Metody algebraiczne specyfikacji formalnej są szczególnie przydatne do specyfikowania interfejsów, przy czym przez interfejs rozumie się zbiór klas obiektów lub abstrakcyjny typ danych. W tych metodach ukrywa się stan systemu, a system specyfikuje się w kategoriach związków między operacjami interfejsu.

W metodach opartych na modelach system przedstawia się za pomocą pojęć matematycznych, takich jak zbiory i funkcje. Można w nich odwołać się do stanu systemu, co upraszcza niektóre rodzaje specyfikacji zachowania.

Specyfikacja formalna

Documents

Transcript of Specyfikacja formalna