Inżynieria wymagań I
Ian Sommerville
Software Engineering, 9.
wyd.
Inżynieria wymagań I
Ian Sommerville
Software Engineering, 9.
wyd.
Zawartość
Wymagania funkcjonalne i
niefunkcjonalne
Dokumentowanie wymagań
Specyfikacja wymagań
Proces inżynierii wymagań
Wydobywanie i analizowanie wymagań
Zatwierdzanie wymagań
Zarządzanie wymaganiami
Inżynieria wymagań
Proces ustalenia, analizowania oraz
dokumentowania usług i
ograniczeń stawianych
oprogramowaniu.
Same wymagania to opis usług i
ograniczeń oprogramowania
ustalonych w procesie inżynierii
wymagań.
W przemyśle informatycznym
pojęcie wymagania nie jest
stosowane konsekwentnie.
Czym jest wymaganie?
Z jednej strony, wymagania mogą być
postrzegane jako zapisane na wysokim
poziomie, abstrakcyjne określenie usług
oferowanych przez system albo ograniczeń
działania systemu.
Z drugiej strony, wymagania można
postrzegać jako szczegółową matematycznie
formalną definicję funkcji i ograniczeń
systemu.
Wybór jednego z powyższych poziomów opisu
zależy od kontekstu, w jakim sformułowano
wymagania.
Rodzaje wymagań (Davis
1993)
Jeśli firma chce podpisać kontrakt na wielkie
przedsięwzięcie budowy oprogramowania, to musi
najpierw określić swoje wymagania w odpowiednio
abstrakcyjny sposób, aby z góry nie definiować
rozwiązań. Wymagania muszą być spisane, aby
różni wykonawcy mogli ubiegać się o ten kontrakt,
być może oferując różne sposoby spełnienia
oczekiwań firmy zamawiającej. Gdy kontrakt jest już
podpisany, wykonawca musi zapisać dla klienta
dokładniejszą definicję systemu, podając więcej
szczegółów, aby klient mógł zrozumieć i
zweryfikować działanie systemu. Oba te dokumenty
mogą nosić nazwę dokumentacji wymagań
stawianych systemowi.
Rodzaje wymagań
Wymagania użytkownika
Opis w języku naturalnym oraz przy
użyciu diagramów usług i ograniczeń
systemu.
Wymagania systemowe
Szczegółowo definiują wymagania
użytkownika. Mogą służyć jako część
kontraktu między nabywcą systemu, a
jego wytwórcą.
Wymagania użytkownika i
wymagania systemowe
Definicja wymagań użytkownika
Specyfikacja wymagań systemowych
1.
System powinien generować miesięczny raport zawierający
sumaryczny koszt lekarstw zapisanych przez każdą przychodnię
obsługiwaną przez system
1.1
Ostatniego roboczego dnia każdego miesiąca należy wygenerować spis
wszystkich przepisanych leków i ich koszt . Z każdym lekiem należy związać
listę przychodni, które zapisywały ten lek.
1.2
O 17:30 ostatniego dnia miesiąca należy przygotować wydruk miesięcznego
raportu.
1.3
W raporcie, dla każdej przychodni należy podać : listę leków, które zostały
zapisane, liczbę przepisanych porcji każdego leku, i całkowity koszt każdego
leku.
1.4
Powyższe informacje należy rozdzielić na poszczególne dawki leku.
1.5
Dostęp do informacji o lekach będzie ograniczony do autoryzowanych
użytkowników.
Czytelnicy różnych rodzajów
specyfikacji
Wymagania
użytkownika
Mened
ż
erowie klienta
U
ż
ytkownicy systemu
Inżynierowie
klienta
Mened
ż
erowie
zleceniobiorcy
Architekci systemu
Wymagania
systemowe
U
ż
ytkownicy systemu
In
ż
ynierowie klienta
Architekci systemu
Twórcy oprogramowania
Wymagania funkcjonalne i
niefunkcjonalne
Wymagania funkcjonalne
Określają, jakie usługi ma ofiarować system, jak ma
reagować na określone dane wejściowe oraz jak ma się
zachowywać w określonych sytuacjach. W niektórych
przypadkach mogą określać, czego system nie powinien
robić.
Wymagania niefunkcjonalne
Ograniczają usługi i funkcje systemu. Obejmują
ograniczenia czasowe, sprzętowe, ograniczenia dotyczące
procesu tworzenia, standardy itp.
Wymagania dziedzinowe
Odzwierciedlają charakterystykę dziedziny systemu. Mogą
być funkcjonalne lub niefunkcjonalne.
Wymagania funkcjonalne
Opisują funkcjonalność lub usługi, które
system powinien oferować.
Zależą od rodzaju tworzonego
oprogramowania oraz spodziewanych
użytkowników.
Jeśli mają postać wymagań
użytkownika, ich opis jest stosunkowo
ogólny.
Jeśli są to wymagania systemowe,
szczegółowo definiują funkcje systemu,
jego wejścia, wyjścia, wyjątki itp.
Wymagania funkcjonalne (system
zarządzania przychodniami
leczniczymi
)
Użytkownik będzie mógł przeszukiwać
listy przyjęć we wszystkich
przychodniach.
Każdego dnia rano system będzie
generował, dla każdej przychodni, listę
zapisanych na ten dzień pacjentów.
Każdy użytkownik systemu będzie
identyfikowany przy użyciu 8-cyfrowego
numeru.
Niejednoznaczność
wymagań
Wymagania są często niejednoznaczne.
Często wykonawca sam rozwiązuje
niejednoznaczność tak, aby implementacja była
łatwiejsza.
Słowo „przeszukiwać” w wymaganiu pierwszym.
Intencja użytkownika: podaj nazwisko pacjenta
i szukaj
Interpretacja zespołu wytwórczego: wybierz
przychodnię, nazwiska pacjenta i szukaj
Kompletność i spójność
wymagań
Wymagania powinny być kompletne i spójne.
Kompletność:
Wszystkie potrzebne użytkownikowi usługi
powinny być zdefiniowane
Spójność:
Wymagania nie powinny mieć sprzecznych
definicji
W praktyce w wypadku wielkich systemów
osiągnięcie kompletności i spójności jest
niemożliwe.
Wymagania
niefunkcjonalne
Definiują właściwości systemu, takie jak
niezawodność, czas reakcji, wymagania
pamięciowe.
Mogą także definiować ograniczenia systemu, takie
jak możliwości urządzeń wejścia-wyjścia,
reprezentacje danych używane przez interfejsy
systemu, język programowania, metodologia
tworzenia oprogramowania.
Wymagania niefunkcjonalne na ogół dotyczą
całości systemu, a nie jego poszczególnych funkcji.
Oznacza to, że są one bardziej istotne niż
wymagania funkcjonalne. Niespełnienie wymagania
niefunkcjonalnego może często spowodować, że
system staje się całkowicie bezużyteczny.
Funkcjonalne vs.
niefunkcjonalne wymagania
Na ogół łatwo ustalić komponent systemu realizujący
konkretne wymaganie funkcjonalne.
W przypadku wymagania niefunkcjonalnego może to być
dużo trudniejsze.
Wymaganie niefunkcjonalne na ogół dotyczy wielu
komponentów. Na przykład wymogi niezawodności
systemu mogą wymuszać minimalizację komunikacji
pomiędzy komponentami.
Pojedyncze wymaganie niefunkcjonalne może generować
wiele wymagań funkcjonalnych. Np. wymóg
bezpieczeństwa systemu może wymusić konieczność
zapewnienia przywracania systemu.
Typy wymagań
niefunkcjonalnych
Wymagania
niefunkcjonalne
Wymagania
produktowe
Wymagania
organizacyjne
Wymagania
zewnętrzne
Wymagania produktowe
Określają zachowanie produktu.
Wymagania sprawnościowe. Dotyczą szybkości
działania produktu i jego zapotrzebowania na
pamięć.
Wymagania niezawodności. Dotyczą miar
związanych z awariami i dostępnością, np.
prawdopodobieństwa awarii przy zleceniu,
częstotliwości występowania awarii, średniego czasu
do awarii lub dostępności usługi.
Wymagania przenośności. Dotyczą możliwości
użycia systemu na różnych platformach
sprzętowych i systemach operacyjnych.
Wymagania użytkowe. Dotyczą wizualnych
aspektów oprogramowania, takich jak estetyka
interfejsu.
Wymagania organizacyjne
Wynikają ze strategii i procedur w firmie klienta i
firmie wytwórcy.
Wymagania standardów. Dotyczą standardów
obowiązujących w firmie, takich jak wygląd
interfejsu czy schematu dokumentacji.
Wymagania implementacyjne. Dotyczą
aspektów związanych z implementacją
systemu, takich jak język programowania czy
metoda projektowania.
Wymagania dostawy. Określają termin
dostarczenia oprogramowania i dokumentacji.
Wymagania zewnętrzne
Ta szeroka kategoria mieści wszystkie
wymagania wynikające z czynników
zewnętrznych dla systemu i procesu jego
tworzenia.
Wymagania współpracy. Definiują interakcje systemu
z systemami innych firm.
Wymagania prawne. Definiują wymagania, które
należy spełnić, aby system działał zgodnie z prawem,
takie jak ochrona prywatności czy wymagania
zabezpieczeń.
Wymagania etyczne. Zapewniają akceptację
systemu przez jego użytkowników i społeczeństwo.
Przykłady wymagań
niefunkcjonalnych
Wymaganie produktowe
System musi być dostępny od poniedziałku do
piątku od 8:00 do 20:00, a czas przestoju
systemu nie może przekroczyć 60 sekund
(wymaganie niezawodności)
Wymaganie organizacyjne
Końcowa dokumentacja powinna być zgodna
ze standardem D-STAN-35 (wymaganie
standardowe)
Wymaganie zewnętrzne
System nie powinien ujawniać poufnych
danych osobowych klientów (wymaganie
prawne)
Cele i wymagania
Wymagania niefunkcjonalne mogą być trudne do
formalnego zdefiniowania i często trudno je
zweryfikować.
Cel
Ogólna intencja użytkownika, np. łatwość
użycia
Weryfikowalne wymaganie niefunkcjonalne
Wymaganie zawierające jakąś miarę, którą
można przetestować
Cele, choć na ogół mało precyzyjne, są
wartościowe, ponieważ opisują ogólną intencję
użytkownika.
Cel i weryfikowalne
wymaganie
Cel systemu
System powinien być łatwy w użyciu dla
doświadczonych kontrolerów, a sposób jego
organizacji powinien minimalizować liczbę błędów
użytkownika.
Weryfikowalne wymaganie niefunkcjonalne
Doświadczeni użytkownicy powinni móc używać
wszystkich funkcji systemu po szkoleniu
trwającym 4 godziny. Po tym szkoleniu średnia
liczba błędów robionych przez doświadczonych
użytkowników nie powinna przekroczyć dwóch
dziennie
Miary do specyfikowania
wymagań niefunkcjonalnych
Właściwość
Miara
Szybkość
Liczba przetworzonych transakcji na sekundę
Czas reakcji na zdarzenie wywołane przez
użytkownika
Czas odświeżenia ekranu
Rozmiar
Kilobajty
Liczba układów pamięci RAM
Łatwość
użycia
Czas szkolenia
Liczba okien pomocy
Niezawodność Średni czas bez awarii
Częstość błędów
Prawdopodobieństwo niedostępności usługi
Solidność
Czas uruchomienia po awarii
Prawdopodobieństwo zniszczenia danych po awarii
Przenośność
Procent poleceń zależnych od platformy
Liczba docelowych platform sprzętowych
Wymagania dziedzinowe
Wynikają z dziedziny zastosowania systemu
Na przykład system wspomagający pracę
maszynisty musi uwzględnić różne
charakterystyki hamowania w zależności od
warunków atmosferycznych
Wymagania dziedzinowe mogą być nowymi
wymaganiami funkcjonalnymi, mogą
ograniczać istniejące wymagania funkcjonalne
lub ustalać sposób wykonywania konkretnych
obliczeń.
Jeśli wymagania dziedzinowe nie są spełnione,
system może się nie nadawać do użycia.
System bezpieczeństwa
ruchu pociągów
Tempo hamowania pociągu wyraża się wzorem
D
pociągu
= D
sterowania
+ D
nachylenia
przy czym
D
nachylenia
= 9.81*α, gdzie α zależy od
typu pociągu
Dla niespecjalisty powyższy wzór może być mało
zrozumiały. Ponadto może nie być jasne, jak wzór
oddziałuje na inne wymagania
Problemy z wymaganiami
dziedziny
Zrozumiałość
Wymagania dziedziny są często
wyrażane w języku tej dziedziny. Ten
język może być niezrozumiały dla
twórców systemu
Domyślność
Eksperci dziedziny dobrze ją
rozumieją. Dlatego może im nie
przyjść do głowy, aby pewne fakty
sformułować explicite.
Dokumentacja wymagań
stawianych oprogramowaniu
Dokumentacja wymagań (specyfikacja
wymagań) jest oficjalną deklaracją tego, co
jest wymagane od wytwórców
oprogramowania.
Powinna zawierać zarówno wymagania
użytkownika, jak i szczegółowy opis wymagań
systemowych.
Wymagania użytkownika stanowią na ogół
wstęp do wymagań systemowych.
Dokumentacja wymagań nie jest dokumentem
projektowym!! Powinna opisywać usługi
systemu, nie precyzując jak mają być
zrealizowane.
Wymagania w metodach
zwinnych
Większość metod zwinnych zakłada, że
dokumentacja wymagań jest zbędna,
ponieważ często się zmieniają.
Metody zwinne realizują przyrostową inżynierię
wymagań.
Takie rozwiązanie może być słuszne w
przypadku niewielkich systemów o charakterze
technologiczno-biznesowym. Staje się jednak
problematyczne w przypadku systemów
wymagających głębokiej analizy przed budową
(systemy krytyczne) lub wielkich systemów
tworzonych przez wiele zespołów.
Użytkownicy dokumentacji
wymagań
Użytkownicy
Sposób korzystania
Klienci systemu
Określają wymagania i czytają je, aby
sprawdzić, czy odpowiadają ich
potrzebom. Określają także zmiany
wymagań
Menedżerowie
Używają dokumentacji wymagań do
planowania oferty budowy systemu i do
planowania procesu jego tworzenia
Inżynierowie
systemów
Używają wymagań, aby zrozumieć, jaki
system ma być zbudowany
Inżynierowie
testów systemów
Używają wymagań, aby opracować testy
zatwierdzające system
Inżynierowie
pielęgnacji
systemów
Używają wymagań jako pomocy w
zrozumieniu systemu i związków między
jego częściami
Różnorodność dokumentacji
wymagań
Wielu potencjalnych czytelników dokumentacji
wymagań sprawia, że musi ona być pewnym
kompromisem pomiędzy komunikowaniem wymagań
użytkownikom, a ich dokładną definicją potrzebną
osobom tworzącym, testującym i pielęgnującym
oprogramowanie.
Informacje zawarte w dokumentacji wymagań zależą
również od rodzaju oprogramowania oraz metodologii
jego wytwórstwa. Dokumentacja wymagań dla
systemów budowanych przyrostowo jest często niezbyt
precyzyjna.
Istnieją standardy dokumentowania wymagań.
(Departament Obrony Stanów Zjednoczonych, IEEE)
Struktura dokumentacji
wymagań (IEEE 1998)
Rozdział
Opis
Przedmowa Należy w niej określić, dla jakich czytelników jest ten
dokument oraz opisać historię jego wersji wraz z
uzasadnieniem ich tworzenia oraz zmian wprowadzonych w
kolejnych wersjach
Wstęp
Należy w niej wyjaśnić, dlaczego ten system jest potrzebny.
Należy krótko opisać usługi systemu i sposób jego
współpracy z innymi systemami. Należy również wyjaśnić,
jak system przystaje do celów gospodarczych i
strategicznych firmy, która go kupuje.
Słownik
Należy tu zdefiniować techniczne pojęcia występujące w
dokumencie. Nie należy nic zakładać o doświadczeniu i
wiedzy czytelnika
Opis
wymagań
użytkownik
a
W tym punkcie należy opisać usługi dostarczane
użytkownikowi i wymagania niefunkcjonalne systemu. W
opisie można się posłużyć językiem naturalnym,
diagramami lub inną notacją zrozumiałą dla klientów.
Powinno się też określić wymagane standardy dotyczące
produktu i/lub procesu.
Struktura dokumentacji
wymagań (IEEE 1998)
Rozdział
Opis
Architektu
ra
systemu
W tym rozdziale należy podać krótki opis architektury
systemu z uwzględnieniem zależności pomiędzy
konkretnymi usługami a konkretnymi komponentami.
Należy wizualnie wyróżnić komponenty wielokrotnego
użycia.
Wymagan
ia
systemow
e
Tu należy bardziej szczegółowo opisać wymagania
funkcjonalne i niefunkcjonalne. Jeśli jest to konieczne
pewne wymagania niefunkcjonalne mogą zostać
uszczegółowione poprzez wprowadzenie miar.
Modele
systemu
Tu należy podać jeden lub więcej modeli systemu, w
których odzwierciedlono związki między systemem, jego
komponentami oraz środowiskiem. Mogą to być modele
obiektowe, modele przepływu danych lub modele
semantyczne.
Struktura dokumentacji
wymagań (IEEE 1998)
Rozdział
Opis
Ewolucja
systemu
Powinno się tu opisać główne założenia systemu i
przewidywane modyfikacje, które mogą wystąpić w
wyniku ewolucji sprzętu, zmiany potrzeb użytkowników
itd.
Dodatki
Należy tu przedstawić szczegółową, specyficzną
informację związaną z budowanym oprogramowaniem.
Przykładami dodatków są opisy sprzętu i opisy bazy
danych. W wymaganiach sprzętowych definiuje się
konfigurację minimalną i optymalną. W wymaganiach
bazy danych określa się logiczną organizację danych
używanych przez system i związki między tymi danymi
Skorowidz
Do dokumentu można dołączyć kilka skorowidzów.
Oprócz skorowidza alfabetycznego może to być
skorowidz diagramów, skorowidz usług itd.
Specyfikacja wymagań
Specyfikacja wymagań jest to proces
sformułowania funkcjonalnych i
niefunkcjonalnych wymagań systemu i
zapisania ich w dokumentacji wymagań.
Wymagania użytkownika powinny być
zrozumiałe dla osób bez przygotowania
technicznego.
Wymagania systemowe mogą być bardziej
formalne i mogą zawierać informacje
techniczne.
Dokumentacja wymagań stanowi często jeden
z fragmentów umowy między zleceniobiorcą i
zleceniodawcą. Dlatego ważna jest jej
kompletność.
Notacje specyfikacji
wymagań
Notacja
Opis
Język
naturalny
Wymagania zapisujemy używając numerowanych zdań w
języku naturalnym. Jedno zdanie odpowiada jednemu
wymaganiu.
Strukturalny
język
naturalny
Używamy języka naturalnego, ale używamy standardowych
formularzy do wyrażania wymagań. Każde pole formularza
dotyczy jednego aspektu opisu wymagania
Języki opisu
projektu
W tym podejściu używa się języka podobnego do języka
programowania, ale bardziej abstrakcyjnego. Notacja rzadko
używana, choć dobrze nadaje się do specyfikowania interfejsu
Notacje
graficzne
Wymagania zapisujemy w postaci diagramów. Obecnie
najbardziej znaną notacją graficzną są diagramy przypadków
użycia w języku UML
Specyfikacje
matematyczn
e
Są to notacje czysto formalne oparte na pojęciach
matematycznych takich jak maszyny stanowe czy zbiory.
Zapewniają jednoznaczność specyfikacji. Większość klientów
nie rozumie jednak formalnych specyfikacji i jest niechętna
przyjęciu ich jako fragmentu kontraktu na budowę
oprogramowania.
Wymagania i
projektowanie
Wymagania i projekt powinny być odseparowane.
Wymagania definiują usługi systemu, projekt
wskazuje, jak te usługi zostaną zrealizowane.
W praktyce rozdzielenie wymagań od projektu
jest bardzo trudne
Szkic architektury systemu może być
konieczny, aby ustrukturalizować wymagania
System może współpracować z innymi
systemami, co może prowadzić do wymagań
architektonicznych.
Użycie konkretnej architektury może wynikać z
wymagań dziedziny lub regulacji zewnętrznych
Wymagania w języku
naturalnym
Używamy języka naturalnego wspomaganego
tabelami, diagramami itp.
Język naturalny jest prawie zawsze używany w
przypadku wymagań użytkownika. Często
używa się go również do zapisu wymagań
systemowych.
Atrakcyjność języka naturalnego jako
narzędzia do opisu wymagań wynika z jego
uniwersalności intuicyjności i ogromnej sile
ekspresji.
Wskazówki dotyczące
definiowania wymagań w języku
naturalnym
Przyjmij jakiś standardowy format i używaj go
do opisu wszystkich wymagań.
Używaj języka w sposób spójny. Rozróżniaj
pomiędzy „powinien” (dotyczy pożądanych
wymagań) i „będzie” (dotyczy obligatoryjnych
wymagań).
Wyróżniaj najważniejsze fragmenty tekstu
(kursywa, pogrubienie, kolor itp.)
Unikaj żargonu informatycznego.
Jeśli możliwe, uzasadniaj dlaczego dane
wymaganie jest ważne.
Wady języka naturalnego
jako notacji do opisu
wymagań
Brak jednoznaczności
Bardzo trudno o precyzję, jeśli dokument
ma być łatwy do czytania.
Zrozumienie języka naturalnego w
ogromnej mierze zależy od tego, czy
czytelnicy autorzy specyfikacji używają
tych samych słów do oznaczenia tych
samych pojęć
Istnieje tendencja mieszania wymagań
funkcjonalnych z niefunkcjonalnymi.
Tendencja do łączenia
Często następuje nieświadome złączenie
kilku wymagań w jedno
Przykładowe wymagania
dotyczące pompy insulinowej
3.2 System będzie mierzył poziom cukru we krwi
co 10 minut i jeśli potrzeba wstrzykiwał insulinę.
(Zmiany poziomu cukru są relatywnie wolne,
zatem nie ma potrzeby mierzyć częściej.
Rzadsze pomiary mogłyby spowodować zbytnie
podwyższenie poziomu cukru.)
3.5 Co 1 minutę system będzie przeprowadzał
test aparatury i podejmował ewentualne
działanie, jak opisano w Tabeli 1. (To pozwoli
poinformować użytkownika o ewentualnej awarii
pompy.)
Strukturalny język naturalny
do opisu wymagań
Istotą tego podejścia jest
standaryzacja definiowania
wymagań poprzez stosowanie
odpowiednich formularzy.
To podejście dobrze działa dla
pewnych zastosowań, na przykład
w przypadku systemów
wbudowanych. Dla wielu
systemów o charakterze
biznesowym podejście to jest zbyt
sztywne.
Zawartość formularza
definiującego wymaganie
Opis specyfikowanej funkcji lub bytu
Opis jej danych wejściowych i źródło ich
pochodzenia
Opis jej danych wyjściowych i źródło ich
przeznaczenia
Określenie innych bytów z których korzysta funkcja
specyfikowana
Warunek początkowy, który musi być spełniony
przed wywołaniem funkcji (jeśli się stosuje)
Warunek końcowy, który będzie zachodził po
wywołaniu funkcji (jeśli się stosuje)
Opis efektów ubocznych (jeśli występują)
Specyfikacja wymagania dla
pompy insulinowej z użyciem
formularza
Pompa insulinowa W 3.2
Funkcja Oblicz dawkę
Opis Oblicza dawkę insuliny do podania w przypadku kiedy aktualny poziom
cukru we krwi jest w bezpiecznej strefie między 3 i 7 jednostek
Wejście Bieżący odczyt cukru (r2) i dwa odczyty poprzednie, r0 i r1
Źródło Źródłem r2 jest sensor; r0 i r1 pochodzą z pamięci pompy
Wyjście CompDose – dawka insuliny do wstrzyknięcia
Przeznaczenie Główna pętla sterująca pompą
Działanie Jeśli poziom cukru jest stabilny lub się obniża lub się podwyższa, ale
szybkość podwyższania się spada, to CompDose=0. W przeciwnym przypadku
podziel różnicę pomiędzy obecnym i poprzednim poziomem cukru przez 4 i
zaokrąglij do liczby całkowitej. Jeśli otrzymałeś 0, to CompDose= minimalna
dawka, którą można podać
Wymagania Dwa poprzednie odczyty
Warunek wstępny Zbiornik pompy zawiera co najmniej maksymalną
możliwą dawkę insuliny
Warunek końcowy r0 zostaje zastąpione przez r1; r1 zostaje zastąpione
przez r2
Efekty uboczne Brak
Tabelaryzacja specyfikacji
Uzupełnia tekst w języku naturalnym.
Szczególnie przydatna w przypadku,
kiedy mamy do czynienia z wieloma
alternatywnymi działaniami.
Pompa insulinowa opiera swoje
obliczenia na trzech pomiarach poziomu
cukru we krwi. Użycie tabeli znacznie
upraszcza rachunki opisane w języku
naturalnym.
Tabelaryczna specyfikacja
obliczenia dla pompy
insulinowej
Warunek
Działanie
Opadający poziom cukru (r2<r1)
CompDose=0
Stabilny poziom cukru (r2=r1)
CompDose=0
Poziom cukru rosnący i szybkość
wzrostu malejąca (r2>r1) i (r2-
r1)<(r1-r0)
CompDose=0
Poziom cukru rosnący i szybkość
wzrostu rosnąca lub stabilna
(r2>r1) i (r2-r1)≥(r1-r0)
CompDose= round((r2-r1)/4)
If CompDose=0 then
CompDose=MinDose
Podsumowanie
Wymagania definiują usługi systemu i właściwości
jakim musi podlegać.
Wymagania funkcjonalne określają usługi systemu.
Wymagania niefunkcjonalne określają właściwości
systemu.
Dokumentacja wymagań (specyfikacja wymagań)
jest oficjalną deklaracją tego, co jest wymagane od
wytwórców systemu. Powinna zawierać zarówno
wymagania użytkownika, jak i szczegółowy opis
wymagań systemowych.
Podstawowe notacje do opisu wymagań to język
naturalny, strukturalny język naturalny, języki opisu
projektu, notacje graficzne i języki formalne.
Inżynieria wymagań II
Ian Sommerville
Software Engineering, 9.
wyd.
Proces inżynierii wymagań
Procesy inżynierii wymagań mogą się różnić w zależności od
dziedziny tworzonego oprogramowania, przyjętej metodologii
tworzenia i firmy tworzącej. Tym niemniej cztery czynności
występują w każdym takim procesie.
Studium wykonalności – czy warto zaczynać budowę
systemu?
Określenie i analizowanie wymagań – wyodrębnienie
wszystkich istotnych wymagań
Specyfikowanie wymagań – zapisanie wyodrębnionych
wymagań w jakiejś standardowej postaci
Zatwierdzenie wymagań -- sprawdzenie, że wymagania
definiują system oczekiwany przez klienta
(Uproszczony) proces
inżynierii wymagań
Studium
wykonalności
Określania
I analiza
wymagań
Specyfikowanie
wymagań
Zatwierdzanie
wymagań
Raport o
wykonalności
Model
systemu
Wymagania użytkownika
I wymagania systemowe
Dokumentacja
wymagań
Studium wykonalności
Punktem startowym tego etapu jest ogólny opis systemu i jego
wykorzystanie w ramach przedsiębiorstwa zleceniodawcy.
Wynikiem studium wykonalności jest raport, który zaleca lub
odradza kontynuowanie prac związanych z procesem tworzenia
systemu. W raporcie można też zaproponować zmiany zakresu
systemu, budżetu lub harmonogramu.
W trakcie tego etapu należy odpowiedzieć na trzy pytania
Czy system przyczyni się do realizacji zakładanych celów
przedsiębiorstwa?
Czy system można zbudować z użyciem dostępnych
technologii, w ramach ustalonego budżetu i ograniczeń
czasowych?
Czy system może być zintegrowany z istniejącymi
systemami, które już zainstalowano?
Określanie i analizowanie
wymagań
W trakcie tego etapu inżynierowie budowy
oprogramowania pracują z klientami i
użytkownikami systemu nad badaniem
dziedziny zastosowania i usług, które system
ma oferować, pożądanej efektywności,
wymagań sprzętowych itd.
W etapie tym biorą udział osoby z różnych
stanowisk w firmie zlecającej: użytkownicy,
którzy będą pracować z systemem,
inżynierowie budujący lub pielęgnujący inne
powiązane systemy, menedżerowie
przedsiębiorstwa, eksperci z różnych dziedzin.
Wszystkie te osoby nazywamy
użytkownikami.
Problemy związane z
określaniem i analizą
wymagań
Użytkownicy często nie wiedzą czego oczekują od
systemu poza ogólnikami. Mogą stawiać nierealne
żądania efektywnościowe lub dotyczące kosztu.
Użytkownicy często używają własnej technicznej
terminologii.
Wymagania stawiane przez różnych użytkowników są
często sprzeczne.
Czynniki polityczne w firmie mogą mieć wpływ na
system. Mogą pochodzić od menedżerów żądających
konkretnych wymogów, które umożliwią zwiększenie ich
wpływów.
Środowisko ekonomiczne i gospodarcze, w którym
prowadzi się analizę jest dynamiczne. Mogą się pojawić
nowe wymagania pochodzące od nowych użytkowników.
Określanie i analiza
wymagań
Proces określania i analizy wymagań
może się nieznacznie różnić w różnych
firmach. Tym niemniej powinien
zawierać następujące etapy:
Rozpoznanie wymagań
Klasyfikacja i organizacja wymagań
Nadawanie priorytetów i usuwanie
sprzeczności
Specyfikacja wymagań
Proces określania i analizy
wymagań
Rozpoznanie
wymagań
Klasyfikacja
i organizacja
wymagań
Nadawanie priorytetów
i usuwanie sprzeczności
Specyfikacja
wymagań
Etapy procesu
Rozpoznanie wymagań
Współpraca z użytkownikami w celu rozpoznania
ich wymagań. Na tym etapie zbiera się również
wymagania dotyczące dziedziny.
Klasyfikacja i organizacja wymagań
Polega na podzieleniu nieustrukturalizowanego
zbioru wymagań na spójne grupy
Nadawanie priorytetów i usuwanie
sprzeczności
Wymagania formułowane przez wielu użytkowników
są zazwyczaj sprzeczne. Nadanie priorytetów
poszczególnym wymaganiom pozwala te
sprzeczności usunąć. Etap ten wymaga na ogół
negocjacji z użytkownikami.
Specyfikacja wymagań
Udokumentowanie dotychczas rozpoznanych
wymagań
Rozpoznanie wymagań
Rozpoznanie (wydobycie) wymagań polega na
zbieraniu informacji o tworzonym systemie i
podobnych działających systemach oraz użycie
tej informacji w celu zdefiniowania wymagań
użytkownika i wymagań systemowych.
Źródłem informacji służącej do specyfikacji
wymagań są użytkownicy oraz dokumentacje
podobnych
systemów informatycznych.
Użytkownicy systemu
wspomagającego pracę kliniki
medycznej
Pacjenci, których dane znajdują się w systemie.
Lekarze odpowiedzialni za diagnozowanie i leczenie
pacjentów.
Pielęgniarki koordynujące konsultacje pacjentów z
lekarzami i wykonujące zabiegi.
Pracownicy rejestracji zapisujący pacjentów na wizyty.
Zespół techniczny odpowiedzialny za zarządzanie
sprzętem i oprogramowaniem w klinice.
Osoba odpowiedzialna za przestrzeganie norm
etycznych związanych z pacjentami.
Dyrekcja kliniki, wykorzystująca system do zarządzania
kliniką.
Zespół archiwizujący odpowiedzialny za
przechowywanie informacji
Rozmowy z użytkownikami
Mniej lub bardziej formalne rozmowy z
użytkownikami są częścią większości procesów
inżynierii wymagań.
Rodzaje rozmów
Zamknięte, oparte na liście wcześniej
przygotowanych pytań
Otwarte, gdzie pytania tworzone są dynamicznie
Cechy dobrego prowadzenia rozmowy
Otwartość na nowe pomysły, umiejętność
słuchania innych
Umiejętne zachęcanie do dyskusji (poprzez
formułowanie ciekawych pytań lub precyzowania
gotowych wymagań).
Rozmowy w praktyce
W praktyce rozmowy z użytkownikami są
mieszanką rozmów zamkniętych i otwartych.
Rozmowy stanowią dobrą technikę uzyskania
ogólnego obrazu na temat działalności
użytkowników i ich potencjalnej interakcji z
systemem.
Rozmowy nie są dobrym narzędziem do
wyrobienia opinii o wymaganiach dziedziny
.
Eksperci z firmy zamawiającej na ogół używają
terminologii niezrozumiałej dla osób z zewnątrz
Co gorsze, na ogół nie są w stanie tego zmienić
Scenariusze
Scenariusze modelują rzeczywiste użycie
systemu.
Są szczególnie przydatne przy
uszczegółowianiu istniejących wymagań.
Scenariusz powinien opisywać jedną
(wyjątkowo kilka) interakcji użytkownik-
system.
Scenariusz powinien zawierać:
Opis stanu systemu na początku
scenariusza
Opis normalnego następstwa zdarzeń
scenariusza
Opis tego, co może pójść źle, i jak to jest
obsługiwane
Informacje o innych czynnościach, które
można wykonywać w tym samym czasie
Opis stanu systemu po zakończeniu
scenariusza
Scenariusz edycji karty
pacjenta
Stan początkowy. Pacjent widział jak rejestratorka
tworzy jego kartę choroby, wprowadzając dane
osobowe: imię, nazwisko, adres itd. Do systemu
zalogowana jest aktualnie pielęgniarka, której zadaniem
jest uzupełnienie karty o dane medyczne.
Działanie normalne. Pielęgniarka wyszukuje kartę
pacjenta posługując się nazwiskiem. W przypadku kilku
pacjentów o tym samym nazwisku, bierze pod uwagę
imię i ewentualnie datę urodzenia.
Po znalezieniu karty pacjenta, pielęgniarka wybiera
zakładkę
„dodaj informacje medyczne”.
Scenariusz edycji karty
pacjenta
Działanie normalne (cd.) Wybierając odpowiednie
zakładki, pielęgniarka wprowadza różne informacje:
informacje dotyczące aktualnego stanu pacjenta
(formularz), konsultacje w innych klinikach (formularz),
alergie (zwykły tekst), lista przyjmowanych leków
(wybór z listy)
Co może się nie udać. W bazie nie ma karty pacjenta.
Pielęgniarka powinna utworzyć nową kartę i zapisać w
niej dane osobowe.
Lek przyjmowany przez pacjenta nie znajduje się na
liście. Należy wybrać zakładkę „brak leku” i wpisać jako
zwykły tekst.
Scenariusz edycji karty
pacjenta
Co może się nie udać (cd.) Pacjent nie chce podać
istotnych informacji. Należy wydrukować standardowe
pismo o odmowie, które pacjent musi podpisać.
Inne czynności. Podczas wprowadzania informacji,
inne upoważnione osoby mogą przeglądać kartę
pacjenta, ale nie mogą jej edytować.
Stan końcowy. Użytkownik jest zalogowany. Dane
medyczne zostały wprowadzone. W rejestrze zdarzeń
systemu zapisano godzinę rozpoczęcia, godzinę
zakończenia sesji oraz identyfikator pielęgniarki
wprowadzającej dane.
Przypadki użycia
Wchodzą w skład języka UML. Stanowią bardzo
popularną graficzną technikę rozpoznawania
wymagań.
W najprostszej postaci przypadek użycia
definiuje aktora zaangażowanego w interakcję
z systemem nadaje tej interakcji nazwę. Aktor
to człowiek lub inny system.
Nie ma jednoznacznej zgody, czy przypadek
użycia jest scenariuszem, czy zbiorem
scenariuszy.
Przypadki użycia kliniki
medycznej
Rejestratorka
Pielęgniarka
Lekarz
Kierownik
kliniki
Rejestracja
Ogląd danych
osobowych
Ogląd karty
pacjenta
Edycja karty
pacjenta
Zapis na
wizytę
Generowanie
karty wypisu
Generowanie
raportu
zewnętrznego
Etnografia
Systemy informatyczne nie istnieją w izolacji. Są
użytkowane w środowisku społecznym i organizacyjnym.
Etnografia to metoda obserwacji, która może służyć do
rozpoznawania wymagań społecznych i
organizacyjnych.
Zaletą etnografii jest to, że pomaga rozpoznać niejawne
wymagania systemowe odzwierciedlające rzeczywiste, a
nie formalne procesy, w których biorą udział ludzie.
Te niejawne wymagania są bardzo trudne do uzyskania
inną drogą niż obserwacja. Wynika to z faktu, że wiele
czynności związanych z pracą wykonuje się w sposób
automatyczny.
Zakres etnografii
Etnografia jest szczególnie przydatna do znajdowania dwóch
typów wymagań
Wymagania wynikające z rzeczywistego sposobu pracy osób,
a nie ze sposobu zalecanego przez formalne definicje
procesów. Kontrolerzy lotów mogą wyłączać pewne
podsystemy używanego systemu, pomimo, że procedury
tego zabraniają.
Wymagania, które wynikają z kooperacji i świadomości
czynności innych osób. Kontrolerzy lotów mogą
zmodyfikować swoją strategię na podstawie liczby
samolotów w sąsiednich sektorach. W takim przypadku
system kontroli lotów powinien umożliwiać kontrolerom
podglądanie sąsiednich sektorów.
Etnografia jest użyteczna, aby zrozumieć i poprawić szczegóły
istniejących procesów. Nie nadaje się do wykrycia zupełnie
nowych wymagań.
Zatwierdzanie wymagań
Polega na sprawdzeniu, że wymagania
definiują system zgodny z oczekiwaniami
klienta.
Koszt błędów związanych z wymaganiami jest
dużo większy niż błędy implementacyjne.
Dzieje się tak, ponieważ duże zmiany
wymagań często pociągają duże zmiany
projektowo-implementacyjne i dodatkowo
konieczność ponownego testowania.
Sprawdzanie wymagań
Trafność.
Czy zbiór wymagań jest optymalny z punktu
widzenia wszystkich użytkowników mających często różne ,
być może sprzeczne, potrzeby.
Niesprzeczność.
Czy istnieją konflikty pomiędzy
wymaganiami?
Kompletność.
Czy uwzględniono wszystkie istotne
wymagania?
Realność.
Czy zdefiniowane wymagania mogą być
zaimplementowane biorąc pod uwagę stan współczesnej
technologii oraz przeznaczony czas i budżet?
Weryfikowalność.
Czy opracowano metodę sprawdzenia, że
zdefiniowane wymagania zostały poprawnie
zaimplementowane?
Techniki zatwierdzania
wymagań
Przegląd wymagań.
Systematyczna ręczna analiza wymagań
Prototypowanie.
Konstruowanie wykonywalnego modelu
systemu
Generowanie testów.
Częścią zatwierdzania wymagań może być
przygotowanie testów dla wymagań. Jeśli
sprawia to trudność, istnieje duże
prawdopodobieństwo, że będą problemy w
czasie implementacji.
Przeglądy wymagań
Jest to ręczny proces, w którym przedstawiciele
klienta oraz wytwórców sprawdzają ręcznie
dokumentację wymagań w celu znalezienia błędów.
Przegląd powinien mieć miejsce od razu po
zdefiniowaniu wymagań.
Przeglądy mogą być nieformalne i formalne.
Podczas przeglądu nieformalnego wytwórcy
rozmawiają z jak największą grupą użytkowników.
W czasie przeglądu formalnego zespół wytwórczy
prezentuje klientowi wszystkie wymagania
systemowe i wyjaśnia konsekwencje każdego
wymagania.
Formalne przeglądy
wymagań
W czasie formalnego przeglądu wymagań, poza
niesprzecznością i kompletnością, należy
sprawdzić:
Możliwość weryfikacji.
Czy wymaganie
zdefiniowano tak, że będzie można je
sprawdzić?
Zrozumiałość.
Czy użytkownicy właściwie
zrozumieli wymaganie?
Pochodzenie.
Czy jawnie zaznaczono źródło, z
którego pochodzi wymaganie? Źródło może być
istotne, gdy chcemy ocenić wpływ zmiany.
Elastyczność.
Czy wymaganie może być
zmienione bez znaczącego wpływu na inne
wymagania?
Zarządzanie wymaganiami
Jest to proces rozpoznawania i panowania nad
zmianami wymagań systemowych.
Nowe wymagania mogą pojawić się w trakcie
tworzenia systemu i na ogół zawsze pojawiają
się w czasie jego użytkowania.
Należy ustawicznie śledzić powiązania
pomiędzy wymaganiami, aby je uwzględnić
przy zmianach.
Powody zmian wymagań
Z wielkich systemów korzystają na ogół różni
użytkownicy, przypisujący wymaganiom różne
priorytety. Ostateczne wymagania systemowe są z
konieczności pewnym kompromisem. W miarę
tworzenia/użytkowania systemu może się okazać, że
bilans wspomagania różnych użytkowników musi być
zmieniony.
Ludzie płacący za system i użytkownicy faktyczni to na
ogół różni klienci. Wymagania osób płacących mogą
być sprzeczne z wymaganiami użytkowników z powodu
ograniczeń organizacyjno-budżetowych.
Zmienia się otoczenie technologiczne i gospodarcze
mogące wymuszać zmiany wymagań.
Wymagania stałe i
zmienne
Wymagania stałe
to względnie stabilne
wymagania systemowe, które wynikają z
podstawowej działalności firmy i bezpośrednio
odnoszą się do dziedziny systemu. W szpitalu
zawsze będą wymagania dotyczące lekarzy,
pielęgniarek, pacjentów, terapii itp.
Wymagania zmienne
to wymagania, które
łatwo mogą ulec zmianie w trakcie tworzenia
systemu lub w trakcie jego pielęgnacji. Takimi
wymaganiami są na przykład wymagania,
które wynikają z polityki zdrowotnej rządu.
Ewolucja wymagań
Wstępne
rozumienie
problemu
Wstępne
wymagania
Zmienione
rozumienie
problemu
Zmienione
wymagania
Czas
Planowanie zarządzania
wymaganiami
W trakcie tej fazy zarządzania wymaganiami należy
podjąć decyzje dotyczące następujących zagadnień:
Identyfikowanie wymagań.
Każde wymaganie musi
być unikatowo oznakowane, tak aby można się było
do niego odwoływać.
Proces zarządzania zmianami.
Jest to zbiór czynności
szacowania wpływu i kosztu zmian.
Strategia śledzenia pochodzenia.
Definiują zależności
między wymaganiami oraz między wymaganiami a
systemem oraz sposób gromadzenia tych zależności.
Użycie narzędzi CASE.
Narzędzia, które mogą być
użyte to wyspecjalizowane systemy zarządzania
wymaganiami, arkusze kalkulacyjne czy proste bazy
danych.
Pochodzenie wymagań
Warto gromadzić trzy typy informacji o pochodzeniu
wymagań
Informacje o pochodzeniu
wiążą wymaganie z
użytkownikiem, które je zaproponował. Warto z nim
skonsultować zmianę.
Informacje o uzależnieniu wymagań
definiują związki
pomiędzy wymaganiami, które od siebie zależą. Ta
informacja pozwala oszacować koszt zmiany.
Informacje o uzależnieniu projektu
wiążą wymagania z
modułami, które je implementują. Ta informacja jest
używana do oszacowania wpływu zmian na projekt systemu
i jego implementację.
Zarządzanie zmianami
wymagań
Analiza problemu
i specyfikacja
zmiany
Analiza zmiany
i ocena kosztów
Implementacja
zmiany
Rozpoznany
problem
Skorygowane
wymagania
Zarządzanie zmianami
wymagań
Kroki procesu zarządzania zmianami
Analiza problemu i specyfikacja zmiany
. Proces
rozpoczyna się od rozpoznania problemu z
wymaganiem lub od konkretnej propozycji zmiany.
Postulat jest sprawdzany pod względem słuszności.
Analiza zmiany i ocena kosztów.
Korzystając z
informacji o uzależnieniu wymagania szacuje się
wpływ zmiany na system i jej koszt. W kroku tym
podejmuje się decyzję, czy kontynuować zmianę.
Implementacja zmiany.
Modyfikuje się dokumentację
wymagań oraz, jeśli potrzeba, również projekt i
implementację systemu.
Podsumowanie
Proces inżynierii wymagań ma charakter
iteracyjny. Składa się z określenia i analizy
wymagań, specyfikowania wymagań
,zatwierdzenia wymagań i zarządzania
wymaganiami.
Analizowanie wymagań obejmuje rozpoznanie
wymagań, ich klasyfikację i strukturalizację,
nadawanie priorytetów i usuwanie
sprzeczności.
Zatwierdzanie wymagań polega na
sprawdzeniu, że wymagania definiują system
zgodny z oczekiwaniami klienta.
Inżynieria wymagań III
(Specyfikacja formalna)
Ian Sommerville
Software Engineering, 9
wyd.
Zawartość
Specyfikacja formalna w procesie
tworzenia oprogramowania
Specyfikacja interfejsu
Specyfikacja zachowania
Metody formalne
Specyfikacja formalna wchodzi w skład
technik występujących pod nazwą metody
formalne.
Podstawą metod formalnych jest
matematyka.
Metody formalne obejmują kilka czynności
związanych z wytwarzaniem
oprogramowania
.
Formalne specyfikowanie systemu
Analizowanie i weryfikację specyfikacji
Proces tworzenia programowania z
przekształceniem
Dowodzenie poprawności programów
Metody formalne w inżynierii
oprogramowania
W latach osiemdziesiątych ubiegłego wieku panowało
przekonanie, że metody formalne wyprą inne techniki
wytwarzania oprogramowania. Tak się jednak nie stało.
Inne techniki okazały się skuteczne dla poprawienia jakości
oprogramowania (programowanie strukturalne, zarządzanie
konfiguracjami, ukrywanie informacji).
O ile kiedyś głównym problemem było zapewnienie jakości
oprogramowania, o tyle dzisiaj często ważniejsza jest
szybkość jego dostarczenia. Metody formalne zwiększają
czas utworzenia oprogramowania.
Zakres metod formalnych jest ograniczony. Metody te nie są
dobrze dostosowane do specyfikowania interfejsu
użytkownika, który jest kluczowy w wielu zastosowaniach.
Ponadto metody formalne nie skalują się dobrze.
Zakres metod formalnych
Główną korzyścią ze metod formalnych jest
redukcja błędów. Zaobserwowano to we
wszystkich udanych przedsięwzięciach, w
których zastosowano te metody.
Naturalną dziedziną dla metod formalnych jest
wytwórstwo systemów krytycznych.
Jest to prawdopodobnie jedyna dziedzina,
gdzie koszt błędów jest większy niż koszt
związany ze stosowaniem metod formalnych.
Specyfikowanie i
projektowanie
Rosnący udział zleceniobiorcy
Malejący udział klienta
Definiowanie
wymagań
użytkownika
Specyfikowanie
wymagań
systemowych
Projektowanie
architektury
Specyfikowanie
formalne
Projektowanie
szczegółowe
Specyfikowanie
Projektowanie
Zalety i wady specyfikacji
formalnej
W miarę opracowywania szczegółów
specyfikacji zwiększa się jej zrozumienie przez
autora. Skorzystanie ze specyfikacji formalnej
zmusza do drobiazgowej analizy systemu,
ponieważ wszystkie wymagania muszą być
opisane językiem formalnym o dobrze
zbadanych i zrozumiałych właściwościach
matematycznych.
Ta drobiazgowa analiza redukuje liczbę błędów
podczas specyfikowania systemu.
Wadą tego podejścia jest zwiększony koszt
specyfikowania, częściowo zredukowany
mniejszymi nakładami na zatwierdzanie
oprogramowania.
Koszty budowy oprogramowania ze
specyfikacją normalną
Koszt
S -- Specyfikowanie
S
PiI
Z
PiI
S
Z
PiI -- Projektowanie
i implementacja
Z -- zatwierdzanie
Bez specyfikacji formalnej
Ze specyfikacją formalną
Techniki specyfikacji
formalnej
Podejście algebraiczne
W którym zapisuje się system w
kategoriach operacji i ich związków
Podejście oparte na modelach
W którym 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
Specyfikacja interfejsu
Wielkie systemy składają się z
podsystemów. Aby podsystemy te mogły
być budowane niezależnie wymagane są
interfejsy między nimi.
Interfejsy podsystemów zwykle definiuje
się jako zbiór abstrakcyjnych typów danych
lub obiektów, które opisują dane i operacje
dostępne przez interfejsy tych
podsystemów.
Jasne i jednoznaczne specyfikacje
interfejsów podsystemów zmniejszają
prawdopodobieństwo nieporozumień
między podsystemami oferującymi pewne
usługi a podsystemami korzystającymi z
tych usług.
Interfejsy podsystemów
Podsystem
A
Podsystem
B
Obiekty
interfejsu
Struktura specyfikacji
algebraicznej
<NAZWA SPECYFIKACJI>{<PARAMETRY>}
typ <nazwa>
imports <LISTA NAZW SPECYFIKACJI>
Nieformalny opis typu i jego operacji
Sygnatury operacji zdefiniowanych typie
<nazwa> ustalające
ich nazwy i typy parametrów
Aksjomaty definiujące operacje typie <nazwa>
Składniki specyfikacji
Wstęp
Określa nazwę typu i inne typy, które będą
używane
Opis typu
Nieformalny opis operacji związanych ze
specyfikowanym typem
Sygnatury
Definiuje składnię tych operacji i ich
parametry
Aksjomaty
Definiują semantykę poprzez podanie
aksjomatów charakteryzujących
poszczególne operacje
Proces budowy specyfikacji
formalnej interfejsu
Strukturalizacja specyfikacji
Uporządkuj nieformalną specyfikację interfejsu,
nadając jej formę zbioru abstrakcyjnych typów
danych lub klas obiektów. Nieformalnie zdefiniuj
operacje związane z każdą klasą
Nazwanie specyfikacji
Nadaj nazwę każdej specyfikacji abstrakcyjnego
typu. Ustal, czy powinna mieć parametry ogólne i
nadaj nazwę każdemu zidentyfikowanemu typowi.
Wybór operacji
Określ zbiór operacji dla każdej specyfikacji na
podstawie rozpoznanej funkcjonalności interfejsu.
Powinieneś uwzględnić operacje do tworzenia
egzemplarzy, do modyfikowania wartości
egzemplarzy. Być może, będziesz musiał dodać
nowe operacje do tych zdefiniowanych nieformalnie
wcześniej
Proces budowy specyfikacji
formalnej interfejsu
Specyfikowanie nieformalne operacji
Napisz specyfikację nieformalną każdej operacji.
Powinna ona opisywać wpływ operacji na
definiowany typ.
Definiowanie składni
Zdefiniuj składnię operacji i ich parametrów. Będzie
to część sygnaturowa specyfikacji formalnej. Jeśli to
konieczne, zaaktualizuj specyfikację nieformalną
Definiowanie aksjomatów
Zdefiniuj semantykę operacji, opisując warunki ,
które są zawsze prawdziwe dla różnych kombinacji
operacji
Prosta specyfikacja listy
LISTA(Elem)
typ Lista
imports INTEGER
Definiuje listę, do której dodaje się elementy na końcu, a usuwa na początku.
Operacje to
Utwórz
, która powoduje utworzenie pustej listy,
Cons
, która dodaje
element na koniec listy,
Długość
, która oblicza 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.
Niezdefiniowane
reprezentuje niezdefiniowaną wartość typu Elem.
Utwórz Lista
Cons(Lista, Elem) Lista
Głowa(Lista) Elem
Długość(Lista) Integer
Ogon(Lista) Lista
Głowa(Utwórz)= Niezdefiniowane exception (lista pusta)
Głowa(Cons(L,w))= if L=Utwórz then w else Głowa(L)
Długość(Utwórz)=0
Długość(Cons(L,w))= Długość(L)+1
Ogon(Utwórz)=Utwórz
Ogon(Cons(L,w))=if L=Utwórz then Utwórz else Cons(Ogon(L),w)
Operacje specyfikacji
Operacje konstruktorowe (konstruktory)
Tworzą lub modyfikują byty typu definiowanego w
specyfikacji. W przykładzie listy są to Utwórz, Cons i
Ogon
Operacje inspekcyjne
Obliczają atrybutu typu zdefiniowanego w
specyfikacji. W przykładzie listy są to Głowa i
Długość.
Należy zdefiniować aksjomaty dla każdej operacji
inspekcyjnej względem każdego konstruktora
podstawowego, czyli konstruktora, którego nie można
zdefiniować przy użyciu innych konstruktorów. Dla
konstruktorów nie podstawowych należy dodać
odpowiednie definicje. W przykładzie z listami Utwórz i
Cons są konstruktorami podstawowymi. Przy ich
pomocy można zdefiniować Ogon.
Specyfikacja interfejsu w
systemie krytycznym
W systemie kontroli lotów
zaproponowano obiekty reprezentujące
sektory kontrolowanej przestrzeni
powietrznej.
Każdy sektor może zawierać kilka
samolotów, ale muszą być one
oddzielone.
W przykładzie przyjmujemy odległość co
najmniej 300 metrów w pionie.
System powinien zawiadomić kontrolera
lotów jeśli umieszczenie samolotu
łamałoby tę regułę.
Obiekt sektor
Na obiekcie określone są operacje:
Wejdź.
Dodaje samolot do sektora na
podanej wysokości (obowiązuje reguła 300
m)
Wyjdź.
Usuwa samolot z sektora
Przesuń.
Przesuwa samolot z jednej
wysokości na inną (obowiązuje reguła 300
m)
Znajdź.
Podaje wysokość samolotu
Parametrem (jednym z parametrów) każdej
operacji jest identyfikator reprezentujący
samolot.
Operacje pomocnicze
W celu uproszczenia specyfikacji wprowadzamy
operacje pomocnicze.
Utwórz.
Tworzy pusty sektor
Umieść.
Uproszczona wersja operacji Wejdź. Dodaje
samolot do sektora nie sprawdzając warunku 300 m
W-przestrzeni.
Dla zadanego sektora zwraca
wartość true jeśli samolot jest w sektorze (wpp
false)
Zajęta.
Dla zadanej wysokości zwraca wartość true
jeśli w trzystumetrowym otoczeniu znajduje się jakiś
samolot (wpp false)
Specyfikacja kontrolowanego
sektora
SEKTOR
typ Sektor
imports INTEGER,BOOLEAN
Wejdź – dodaje samolot do sektora, o ile spełniona jest reguła trzystu metrów
Wyjdź – usuwa samolot z sektora
Przesuń – zmienia wysokość samolotu, o ile spełniona jest reguła trzystu
metrów
Znajdź – podaje wysokość samolotu w sektorze
Utwórz
– tworzy pusty sektor
Umieść
– dodaje samolot do sektora bez sprawdzania reguły trzystu metrów
W_przestrzeni
– sprawdza, czy samolot jest w sektorze
Zajęta
– sprawdza, czy podana wysokość jest dostępna
Wejdź(Sektor, Samolot, Wysokość) Sektor
Wyjdź(Sektor, Samolot) Sektor
Przesuń(Sektor, Samolot, Wysokość) Sektor
Znajdź(Sektor, Samolot) Wysokość
Utwórz Sektor
Umieść(Sektor, Samolot, Wysokość) Sektor
W_przestrzeni(Sektor, Samolot) Boolean
Zajęta(Sektor, Wysokość) Boolean
Specyfikacja kontrolowanego
sektora
Wejdź(sek, sam, w)= if W-przestrzeni(sek, sam) then sek
else if Zajęta(sek,w) then sek) else Umieść(sek,sam,w)
Wyjdź(Utwórz, sam)=Utwórz
Wyjdź(Umieść(sek,sam1,w1),sam)= if sam=sam1 then sek
else Umieść(Wyjdź(sek,sam),sam1,w1)
Przesuń(sek,sam,w)= if sek=Utwórz then Utwórz else if not W_przestrzeni
(sek,sam) then
sek else if Zajęta(sek,w) then sek else Umieść(Wyjdź(sek,sam),sam,w)
Znajdź(Utwórz,sam)=0 (oznacza, że samolotu nie ma w sektorze)
Znajdź(Umieść(sek,sam1,w1),sam)=
if
sam=sam1
then
w1
else
Znajdź(sek,sam)
Zajęta(Utwórz, W)=false
Zajęta(Umieść(sek,sam1,w1),w)=
if abs(w1-w)≤300 then true else Zajęta(sek,w)
W_przestrzeni(Utwórz, sam)= false
W_przestrzeni(Umieść,(sek,sam1,w1),sam)=
if sam=sam1 then true else W_przestrzeni(sek,sam)
Specyfikacja zachowania
Specyfikacje algebraiczne są niewygodne, jeśli
wyniki operacji zależą od wyników
poprzednich operacji.
W takim przypadku można użyć specyfikacji
opartej na modelach. W tym podejściu
specyfikacja modelu ma postać stanu
systemu, a operacje systemu definiuje się
przez ich wpływ na stan systemu.
Jedną z formalnych specyfikacji modelowych
jest notacja Z (ang. Z notation).
Strukura schematu Z
Zbiornik
zawartość: N
pojemność: N
zawartość ≤ pojemność
Nazwa schematu
Sygnatura schematu
Predykat schematu
Diagram blokowy pompy
insulinowej
Igła
Pompa
Zegar
Miernik
Sterownik
Alarm
Wyświetlacz
1
Wyświetlacz
2
Schemat pompy
insulinowejo
POMPA INSULINOWA
odczyt? : N //wartość poziomu glukozy odczytana z miernika
dawka, dawka_min, dawka_całkowita: N //dawka do wstrzyknięcia,
dawka minimalna i dawka z pewnego okresu
r0,r1,r2: N // ostatnie trzy odczyty
zapas: N // zapas insuliny w zbiorniku pompy
alarm! : {włączony, wyłączony} // reprezentuje stan wyjątkowy
pompa! : N // liczba reprezentująca sygnał wysłany do zestawu
pompującego
wyświetlacz1!, wyświetlacz2!: STRING // pierwszy wyświetla
komunikaty; drugi
podawaną dawkę
insuliny
(dawka ≤ zapas) Ʌ (dawka ≤ 5) Ʌ (dawka_całkowita ≤ 50)
(zapas ≥ 40) => wyświetlacz1! = ` `//komunikat pusty
(zapas < 40) Ʌ (zapas ≥ 10) => wyświetlacz1! =` Niski poziom
insuliny’
(zapas < 10) => (alarm! = włączony) Ʌ wyświetlacz1! =` Bardzo
niski poziom insuliny’
o2 = odczyt
Schemat DAWKOWANIE
DAWKOWANIE
Δ POMPA INSULINOWA
(r2<r1) => dawka = 0
r2 = r1 => dawka = 0
[(r2 > r1) Ʌ [(r2-r1) < (r1-r0)]] => dawka=0
[(r2 > r1) Ʌ [(r2-r1) < (r1-r0)] Ʌ round((r2-r1)/4)=0] =>
dawka=dawka_min
[(r2 > r1) Ʌ [(r2-r1) < (r1-r0)] Ʌ round((r2-r1)/4)>0] => dawka=
round((r2-r1)/4)
zapas’ =zapas – dawka
dawka_całkowita = dawka_całkowita + dawka
(r0’ = r1) Ʌ (r1’ = r2)
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
Podsumowanie
Metody specyfikacji formalnej uzupełniają
metody specyfikacji nieformalnej.
Specyfikacje formalne są dokładne i
jednoznaczne. Niespecjaliści mogą mieć
jednak trudności z ich zrozumieniem. Ponadto
łatwo jest popełnić błędy.
Zasadniczą korzyścią ze stosowania metod
formalnych w procesie budowy
oprogramowania jest wymuszenie analizy
wymagań systemowych już we wczesnej fazie.
Podsumowanie
Metody specyfikacji formalnej najbardziej przydają się przy
budowie systemów krytycznych.
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ływać się do stanu systemu, co
upraszcza niektóre rodzaje specyfikacji zachowania.