Modularyzacja jest przydatna w zarządzaniu dużymi i złożonymi argumentacjami assurance case. Pozwala na rozdzielenie odpowiedzialności za moduły oraz na zarządzanie uprawnieniami na poziomie poszczególnych modułów.
NOR-STA implementuje model argumentacji assurance case oparty o OMG SACM, który został rozszerzony dla implementacji trzech rodzajów powiązań zdefiniowanych w standardzie GSN.
Podział argumentacji na moduły umożliwia stosowanie diagramów modułowych dla prezentacji architektury assurance case. Poszczególne moduły mogą odpowiadać różnym komponentom lub funkcjom systemu, hazardom, zagrożeniom security, standardom lub innych właściwościom.
Podział argumentacji na moduły jest zwykle wykonywane w postulatach. Dowolny postulat może zostać określony jako element interfejsu między modułami. Widoczna na diagramie relacja wsparcia modułów jest w rzeczywistości relacją wsparcia pomiędzy postulatami. Kierunek strzałki określa relację ‘jest wspierany przez’ zgodnie z zasadami w GSN.
Powyższy diagram architektury przedstawia trzy moduły. Moduł nadrzędny opisuje obniżenie ryzyka hazardu. Dwa kolejne moduły zapewniają argumentację jak dwa komponenty wspierają to obniżenie ryzyka hazardu. Każdy z tych modułów może być niezależnie rozwijany.
Punktami połączenia pomiędzy modułami są postulaty. Jest to widoczne na kolejnym diagramie. Dwa postulaty w nadrzędnym module mają dodatkowe ikony modułu oraz nazwy wspierających modułów. Są one nazywane elementami zewnętrznymi (away elements) zgodnie z GSN. Są one po prostu linkami do postulatów w innych modułach.
Łączenie modułów może wyglądać na proste, ale zaimplementowany model formalny jest całkiem złożony. Po pierwsze należy odróżnić dwie role połączonych postulatów. Niektóre z nich wymagają wsparcia, a inne dostarczają wsparcie. Dwa postulaty w module nadrzędnym wymagają wsparcia, a główne postulaty modułów komponentów dostarczają wsparcie.
Kolejnym krokiem jest grupowanie postulatów w interfejsach. Interfejs to jest pojemnik na elementy argumentacji (postulaty) udostępniane dla innych modułów. Rozróżniamy dwa rodzaje interfejsów:
- Interfejs wymagany zawiera postulaty, dla których wsparcie mają zapewnić inne moduły argumentacji.
- Interfejs dostarczany zawiera postulaty, które dostarczają wsparcie dla innych modułów.
Nie jest dozwolone mieszanie postulatów wymaganych i dostarczanych w jednym interfejsie w NOR-STA. Osobne interfejsy są stosowane dla postulatów wymaganych, a osobne dla dostarczanych.
Gdy mamy już postulaty w interfejsach, to możemy je powiązać. Powiązanie to połącznie, które działa na dwóch poziomach:
- Powiązanie interfejsów łączy interfejs wymagany z interfejsem dostarczanym w innym module.
- Powiązanie elementów łączy dwa elementy (postulaty) będące w interfejsach, gdzie jeden postulat wymaga wsparcia, a drugi je dostarcza.
Diagramy GSN nie pokazują interfejsów. Standard GSN definiuje pojęcie interfejsu modułu (1:4.6) jako zbiór elementów wymaganych i dostarczanych. NOR-STA implementuje trochę bardziej zaawansowany model interfejsów określony przez OMG SACM, który pozwala na tworzenie więcej niż jednego interfejsu, które mogą być udostępniane dla różnych grup odbiorców. Rozszerzymy diagram GSN, aby pokazać na nim interfejsy oraz powiązania. Dodaliśmy też kolejny interfejs dla postulatu G0. To pokazuje, że w NOR-STA definiowane są osobne interfejsy dla elementów wymaganych i dostarczanych. To podejście różni się od standardu GSN, który definiuje tylko jeden interfejs moduły, który obejmuje wszystkie elementy, wymagane i dostarczane
Interfejs może zawierać dowolną liczbę elementów, a w module można utworzyć dowolną liczbę interfejsów. Zarządzanie interfejsami może wyglądać na złożone zadanie, ale często można je ignorować. NOR-STA może automatycznie tworzyć interfejsy, gdy są potrzebne.
Powiązanie elementów pokazane na diagramach powyżej to powiązanie typu ‘element zewnętrzny’ (away element). Sekcja Modular Extension w standardzie GSN określa trzy rodzaje powiązań interfejsów, które są też zaimplementowane w NOR-STA.
Element zewnętrzny (away element) – link do elementu z innego modułu utworzony w bieżącej argumentacji. To działa jako prosty link pomiędzy modułami. Nazwa i opis takiego elementu są pobierane wprost z moduły dostarczającego i nie podlegają edycji. Nazwa modułu na diagramie (patrz element obok) oznacza, że element zewnętrzny jest podłączony. Brak nazwy modułu oznacza brak powiązania.
Wspierany przez inny moduł – element w bieżącym module jest wspierany przez element w innym module. Taki typ powiązania jest sygnalizowany przez ikonkę modułu poniżej elementu postulatu. Gdy element jest powiązany, to obok ikony modułu jest wyświetlany jego symbol.
Wspierany przez kontrakt – element jest wspierany przez inny element w module wspierającym poprzez pośredniczący kontrakt. Kontrakt to jest dedykowany krok wnioskowania stwierdzający, że postulat dostarczany wspiera postulat wymagany z pełnym jego zakresie i kontekście. Celem stosowania kontraktów jest wymuszenie wykonania przez użytkownika przeglądu wszystkich powiązań.
Rozróżnienie trzech typów powiązań jest zgodne z ich definicjami w standardzie GSN Community Standard. Więcej informacji o typach powiązań można znaleźć w sekcji Modular Extension standardu.
Typ powiązania jest wybierany przez użytkownika NOR-STA podczas tworzenia interfejsu wymaganego. Interfejs dostarczany akceptuje powiązania z interfejsów wymaganych różnych typów.
Jak wybrać odpowiedni tym powiązania?
W skrócie:
- Jeżeli potrzebujesz po wprost postulat w innego modułu, to użyj ‘elementu zewnętrznego’ (away element). Jego nazwa i opis będą automatycznie odświeżone, gdy ktoś zmieni postulat dostarczany.
- Jeżeli potrzebujesz po prostu powiązań dwa postulaty, to użyj powiązania typu wspierany przez moduł. To jest najprostszy sposób na powiązanie postulatów.
- Jeżeli potrzebujesz sprawdzenia, czy powiązania są poprawnie zdefiniowane, to wybierz opcję wspierany przez kontrakt. Dla każdego powiązania postulatów będzie wymagane przeprowadzenie przeglądu i ocena.
W tym krótkim tekście jest wiele tematów, które nie zostały omówione, na przykład, jak zarządzać kontekstem w modułowych argumentach i jak upewnić się, że kontekst wspierających modułów pasuje.
Aby dowiedzieć się więcej o stosowaniu modularnych argumentacji w NOR-STA zachęcamy do zajrzenia do podręcznika NOR-STA oraz do udziału w naszym szkoleniu 18 maja.