Specyfikacja formalna

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

2. 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.

3. Zawartość • Specyfikacja formalna w procesie tworzenia oprogramowania • Specyfikacja interfejsu • Specyfikacja zachowania

4. 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.

5. 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.

6. 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.

7. 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ą.

8. Specyfikowanie i projektowanie Rosnący udział zleceniobiorcy Malejący udział klienta Definiowanie wymagań użytkownika Specyfikowanie wymagań systemowych Projektowanie architektoniczne Specyfikowanie formalne Projektowanie na wysokim poziomie Specyfikowanie Projektowanie

9. Specyfikowanie formalne w procesie budowania oprogramowania Specyfikowanie wymagań systemowych Specyfikowanie formalne Definiowanie wymagań użytkownika Projektowanie na wysokim poziomie Modelowanie systemu Projekt architektoniczny

10. 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.

11. 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)

12. 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.

13. Koszty budowania oprogramowania ze specyfikacją formalną Koszt Zatwierdzanie Projektowanie i implementacja Zatwierdzanie Projektowanie i implementacja Specyfikowanie Specyfikowanie Bez specyfikacji formalnej Ze specyfikacją formalną

14. 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.

15. 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

16. 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.

17. 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.

18. Prosta specyfikacja listy LISTA (Elem) rodzaj Lista imports INTEGER Definiuje 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 Lista Kons (Lista, Elem) Lista Głowa (Lista) Elem Długość (Lista) Integer Ogon (Lista) Lista Gł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) = o Długość (Kons(L, w)) = Długość (L) + 1 Ogon(Utwórz) = Utwórz Ogon (Kons (L, w)) = if L = Utwórz then Utwórz else kons (Ogon (L), w)

19. 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]

20. 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.

21. 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.

22. 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.

23. SEKTOR Specyfikacja kontrolowanego sektora rodzaj Sektor imports INTEGER, BOOLEAN Wejście - dodaje samolot do sektora, o ile zachowane są ograniczenia bezpieczeństwa Wyjście - usuwa samolot z sektora Przesuń - przenosi samolot z jednej wysokości na inną, o ile jest to bezpiecznie Znajdź - podaje wysokość samolotu w sektorze Utwórz – tworzy pusty sektor Umieść – dodaje samolot do sektora bez sprawdzania ograniczeń W-przestrzeni – sprawdza, czy samolot jest już w sektorze Zajęta – sprawdza, czy podana wysokość jest dostepna Wejście (Sektor, Sygnał, Wysokość) Sektor Wyjście (Sektor, Sygnał) Sektor Przesuń (Sektor, Sygnał, Wysokość) Sektor Znajdź (Sektor, Sygnał) Sektor Utwórz Sektor Umieść (Sektor, Sygnał, Wysokość) Sektor W-przestrzeni (Sektor, Sygnał) Boolean Zaję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) = false Zaję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) = false W-przestrzeni (Umieść (Syk, Syg1, W1), Syg) = if Syg = Syg1 then true else W-przestrzeni (Sek, Syg)

24. 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.

25. Struktura schematu Z Nazwa schematu Sygnatura schematu Predykat schematu Zbiornik zawartość: N pojemność: N zawartość ≤ pojemność

26. Diagram blokowy pompy insulinowej Zbiornik insuliny Igła Pompa Zegar Miernik Sterownik Alarm Wyświetlacz 2 Wyświetlacz 1 Zasilanie

27. 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!

28. 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.

29. Schemat pompy insulinowej Pompa insulinowa odczyt? : N dawka, dawka_całkowita : N o0, o1,o2 : N // służą do przechowywania ostatnich trzech odczytów zapas : N alarm! : {włączony, wyłączony} pompa! : N wyświetlacz1!, wyświetlacz2! : STRING dawka <= zapas ^ dawka ,<= 5 ^ dawka_całkowita <= 50 zapas >= 40 wyświetlacz1! = ” ” zapas >= 39 ^ zapas >= 10 wyświetlacz1! = „Niski poziom insuliny” zapas <= 9 alarm! = „włączony” ^ wyświetlacz1! = „Bardzo niski poziom insuliny o2 = odczyt?

30. 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.

31. Schemat DAWKOWANIE DAWKOWANIE ΔPompa_insulinowa ( dawka = 0 ^ ( ((o1 >= o0) ^ (o2 = o1)) v ((o1 > o0) ^ (o2 <= o1)) v ((o1 < o0) ^ ((o1 – o2) > (o0 – o1)) ) v dawka = 4 ^ ( ((o1 <= o0) ^ (o2 = o1) v ((o1 < o0) ^ ((o1 – o2) <= (o0 – o1))) ) v dawka = (o2 – o1) * 4 ^ ( ((o1 < o0) ^ (o2 > o1)) v ((o1 < o0) ^ ((o1 – o2) >= (o0 – o1))) ) ) zapas’ = zapas – dawka dawka_całkowita’ = Dawka_całkowita + dawka o0’ = o1 ^ o1’ = o2

32. 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).

33. 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

34. 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.

35. 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.

36. 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.