Moduły assurance case można łączyć za pomocą interfejsów. Standard GSN w wersji 3 definiuje trzy rodzaje interfejsów:
- obcy element (cytowanie),
- wsparcie przez moduł,
- wsparcie przez kontrakt.
W naszym majowym poście zaprezentowaliśmy diagram porównujący typy interfejsów, ale przedstawiony tam schemat był zbyt uproszczony. Brakowało ważnej cechy kontraktów. Aby to skorygować, zaktualizowaliśmy ten diagram. Dodaliśmy symbol kontraktu pomiędzy modułami oraz dodatkowo ikony ocen.
Graphical argument representation in NOR-STA is only available for GSN argument notation. An example of a GSN diagram containing the base types of elements is shown below.
Kontrakt argumentacji jest ważny, gdy postulat opublikowany w jednym module wspiera postulat w innym module w pełnym jego kontekście. Gdy ten warunek nie jest spełniony, kontrakt staje się nieważny. Status kontraktu prezentowany jest w NOR-STA za pomocą oceny.
- Kontrakt, który nie został jeszcze zweryfikowany, ma status „nieznany” i żółtą ikonę oceny.
- Gdy kontrakt zostanie zweryfikowany i zaakceptowany, ikona oceny otrzymuje kolor zielony. Oznacza to, że kontrakt jest ważny, a moduły są skutecznie powiązane.
- Brak weryfikacji kontaktu powoduje jego odrzucenie. Ikona staje się czerwona, a kontrakt jest nieważna.
Moduły uważa się za połączone tylko wtedy, gdy kontrakt został zweryfikowany i potwierdzono, że jest ważny.
Kontrakty są narzędziem do kontrolowania powiązań modułów. Przede wszystkim powiązanie modułów nie jest automatyczne, a wymaga weryfikacji kontraktu. Dodatkowo w przypadku modyfikacji któregokolwiek z powiązanych postulatów kontrakt automatycznie staje się nieaktualny i wymaga ponownej weryfikacji.
Weryfikacja kontraktu opiera się na prostym wzorcu z dwoma postulatami powiązanymi poprzez element strategii. Dla obu postulatów powinny być określone powiązane elementy kontekstu i założenia.
Wzorzec ten wygląda na prosty, jednak weryfikacja kontekstu może być w niektórych przypadkach trudna. Można to częściowo zautomatyzować, wymieniając odziedziczone elementy kontekstu, gdy są one określone dla postulatów wyższego poziomu. To może zredukować pracę ręcznego sprawdzenia jaki jest dziedziny kontekst. Problemy pojawiają się, gdy kontekst jest określony w opisie postulatu, a nie jako osobny element. Można wtedy łatwo pominąć informacje kontekstowe podczas weryfikacji umowy. Zalecaną praktyką jest określenie pełnego kontekstu postulatów w argumentacji, gdy planowane jest użycie kontraktów w interfejsach.
Osobnym tematem jest porównanie zakresu kontekstu obu powiązanych postulatów. Zwykle jest to łatwe, gdy oba moduły argumentacji są opracowane przez ten sam zespół o odwołują się do tych samych pojęć kontekstowych i dokumentacji. Jednak gdy moduły są rozwijane niezależnie przez różne zespoły, weryfikacja spójności kontekstu może być trudna. Aby uniknąć problemu lub zmniejszyć jego dotkliwość, można uzgodnić kontekst dla każdego modułu argumentacji przed rozpoczęciem jego opracowywania.
Rozwiązaniem opisanego problemu jest zastosowanie współdzielonego modelu kontekstu, który definiuje terminy stosowane we wszystkich powiązanych modułach assurance case. Przykładem takiego modelu może być ODD (Operational design domain), który jest stosowany w przemyśle motoryzacyjnym. Modelowanie kontekstowe to ciekawy temat i będziemy o tym pisać w jednym z naszych kolejnych wpisów.