Scenariusze atrybutów jakościowych

Marzec 30, 2010

W ramach niniejszego wpisu, chciałbym zapoznać czytelnika z techniką ułatwiającą identyfikację i opisywanie wymagań niefunkcjonalnych, jakim są scenariusze atrybutów jakościowych. Założenia tej techniki zostały przez mnie zaczerpnięte z książki Software Architecture in Practice (2nd) autorów Len Bass, Paul Clements, Rick Kazman.

Technikę opisu atrybutów jakościowych poprzez scenariusze staram się wykorzystywać w pracy zawodowej i stosuję ją w odniesieniu do elementów architektury korporacyjnej – a więc na trochę wyższym poziomie niż zaproponowany przez autorów poziom i zakres obejmujący pojedynczą aplikację monolityczną. Tym nie mniej, technika ta zdaje egzamin również i w takich przypadkach.

Czym jest atrybut jakościowy?

Atrybut jakościowy (ang. quality attribute) to wymaganie niefunkcjonalne opisujące oczekiwane i mierzalne zachowanie dowolnego elementu architektury. Przy czym w słowie mierzalny kryje się idea wyróżniająca wymaganie niefunkcjonalne od wymagania funkcjonalnego.

Czym jest scenariusz w kontekście atrybutu jakościowego?

Scenariuszem jest tekstowe wymaganie niefunkcjonalne zapisane w taki sposób, aby możliwe było określenie inicjatora scenariusza, warunków jego realizacji oraz spodziewanego możliwego do zmierzenia wyniku.

W zdaniu opisującym scenariusz wyróżnić należy sześć części tego opisu:

- źródło bodźca (ang. source of stimuli) – definiuje inicjatora scenariusza,

- bodziec (ang. stimuli) – opisuje warunek scenariusza,

- środowisko (ang. environment) – definiuje, w jakich warunkach wystąpi scenariusz,

- artefakt (ang. artifact)*– opisuje pojedynczy element systemu lub cały system objęty scenariuszem,

- odpowiedź (ang. response) – opis czynności podejmowanej w sytuacji wystąpienia bodźca,

- miara odpowiedzi (ang. response measure) – opisuje miarę sukcesu realizacji czynności.

Rysunek 1 Części scenariusza atrybutu jakościowego

Należy mieć na uwadze, że wartości dla poszczególnych części opisu będą inne dla różnych wymagań niefunkcjonalnych (dostępność, wydajność, konfigurowalność, odporność, itd.).

Przykładowo weźmy atrybut jakościowy Elastyczność (ang. Flexibility), który służy do określenia zdolności systemu lub całej organizacji do nanoszenia zmian, których źródłem najczęściej będzie użytkownik. Dla takiego atrybutu jakościowego przykładowe możliwe wartości dla części scenariusza przedstawia rys. 2.

Rysunek 2 Części scenariusza dla atrybutu jakościowego Elastyczność

Załóżmy, że udało nam się zebrać możliwe wartości dla każdej z części opisu scenariusza atrybutu jakościowego charakterystyczne dla zmian zgłaszanych w naszej firmie. Przykładowy scenariusz dla tego atrybutu w firmie działającej w branży usług telekomunikacyjnych mógłby wyglądać na przykład tak:

Żądanie dodania nowej promocji dla istniejącego produktu do systemu w okienku nocnym wdrożone w czasie nie dłuższym niż 2 tyg. od zgłoszenia zmiany przez departament marketingu.

Przy czym:

- źródło bodźca to departament marketingu,

- bodziec to żądanie dodania nowej promocji do istniejącego produktu,

- element architektury to system,

- środowisko to okienko nocne

- odpowiedź to wdrożenie (zmiany),

- miara odpowiedzi to czas nie dłuższy niż 2tyg. od daty zgłoszenia zmiany.

W jaki sposób opisywać atrybuty jakościowe poprzez scenariusze?

Aby móc posługiwać się sprawnie metodą opisu atrybutów jakościowych z wykorzystaniem scenariuszy sugeruję:

1. Zebrać krytyczne dla opisywanego systemu atrybuty jakościowe (dostępność, wydajność, elastyczność, odporność, niezawodność, itd.),
2. Dla każdego z atrybutów określić możliwe zbiory wartości dla poszczególnych fragmentów opisu scenariusza (źródła bodźca, bodziec, środowisko, elementy architektury, odpowiedź, miara odpowiedzi).

Dopiero mając zebrane możliwe wartości dla poszczególnych części scenariuszy (charakterystyczne dla opisywanej architektury), można sprawnie budować scenariusze atrybutów jakościowych, a tym samym lepiej i szybciej definiować możliwe do przetestowania wymagania niefunkcjonalne.

Co dalej?

Aby poza umiejętnościami nabrać również przekonania, co do użycia scenariuszy w pracy zachęcam do prób definiowania wymagań niefunkcjonalnych z użyciem techniki scenariuszy. Dla lepszego zrozumienia idei scenariuszy polecam zapoznanie się z przykładami opisu wymagań niefunkcjonalnych tą techniką, które można znaleźć na stronie: http://dogbert.mse.cs.cmu.edu/mse2006/wikis/Simulacrum-Wiki-03292006/quality_attributes.html.

(*) W swojej pracy nazwę artefakt zastąpiłem nazwą element architektury, ponieważ wydaje mi się że lepiej opisuje fragment architektury objęty wymaganiem zdefiniowanym przez scenariusz. Natomiast słowo artefakt często w literaturze ma węższe znaczenie i odnosi się do specyficznych fragmentów architektury pasywnej, jak np. plik wdrożeniowy, instrukcje DDL, itd.