Identyfikacja zdarzeń w przypadkach użycia

Politechnika Poznańska
Wydział Informatyki
Identyfikacja zdarzeń w przypadkach użycia
mgr inż. Jakub Jurkiewicz
Streszczenie rozprawy doktorskiej
Promotor: dr hab. inż. Jerzy Nawrocki
Promotor pomocniczy: dr inż. Mirosław Ochodek
Poznań 2013
1. Wstęp
Zbieranie wymagań jest jedną z faz w procesie wytwarzania
oprogramowania. Można wyróżnić dwa rodzaje wymagań: funkcjonalne
oraz pozafunkcjonalne. Wymagania funkcjonalne opisują funkcjonalne
możliwości
tworzonego
systemu,
podczas
gdy
wymagania
pozafunkcjonalne prezentują ograniczenia oraz oczekiwania dotyczące
wydajności, bezpieczeństwa, użyteczności, itp.
Wymagania są bardzo istotne w procesie tworzenia systemów IT.
Dane prezentowane przez Standish Group [3] wskazują, że 20%
projektów IT kończy się całkowitą porażką, a prawie 50% ma problemy
z dostarczeniem tworzonego systemu na czas i w ramach planowanego
budżetu. Według wspomnianego raportu niska jakość wymagań oraz
rozszerzający się zakres wymagań to dwie najważniejsze przyczyny
wyżej wymienionych problemów. Te obserwacje potwierdzają również
inne badania [6, 12, 19].
Jednym ze sposobów zapisu wymagań są scenariusze, które
opisują interakcje między aktorami, a w szczególnym przypadku między
aktorem – użytkownikiem, a tworzonym systemem. Można wyróżnić
dwa główne rodzaje scenariuszy: narracyjne oraz dialogowe. Scenariusze
narracyjne opisują wykorzystanie systemu w rzeczywistych sytuacjach
[7] i przedstawiają one wizję tworzonego systemu. Takie scenariusze
opisują tło i kontekst wykorzystania systemu oraz często opisują
konkretne
sytuacje
interakcji
między
użytkownikami
systemu.
Scenariusze narracyjne nie wykorzystują ściśle określonej struktury,
przedstawiają one system z bardzo wysokiego punktu widzenia, często
pomijając
szczegóły,
dlatego
też
nie
mogą
być
bezpośrednio
wykorzystywane przez programistów.
2 Najbardziej znanym sposobem zapisu scenariuszy dialogowych są
przypadki użycia, zaproponowane przez Jacobsona [10]. Przypadki
użycia mają 3-stopniową strukturę: nazwa przedstawia cel, który chce
osiągnąć
aktor;
scenariusz
główny
jest
sekwencją
kroków
przedstawiających interakcję między aktorami; zdarzenia prezentują
możliwe odchylenia od scenariusza głównego, które mogą prowadzić do
alternatywnych scenariuszy interakcji. Taki rodzaj scenariuszy pozwala
przedstawić więcej szczegółów dotyczących tworzonego systemu.
Niska kompletność zdarzeń może powodować dodatkowe koszty
wytwarzania oprogramowania [17]. Niestety brakuje badań dotyczących
efektywności identyfikacji zdarzeń. Z obserwacji wynika, że zdarzenia są
identyfikowane przed analityków za pomocą podejścia ad hoc. Do tej
pory nie zaproponowano również metod pozwalających na automatyczną
identyfikację
zdarzeń.
Jedyną
zbliżoną
metodą
jest
metoda
zaproponowana przez Sutcliffe’a i in. [18], ograniczona jest ona jednak
do identyfikacji naruszeń wymagań pozafunkcjonalnych oraz wymaga
znaczącego wkładu ze strony analityka.
1.1
Cel i zakres pracy
Główny cel pracy to znalezienie odpowiedzi na następujące pytania
badawcze:
• Czy możliwa jest automatyczna identyfikacja zdarzeń w
przypadkach użycia?
• Jaka byłaby skuteczność takiego podejścia?
W celu znalezienia odpowiedzi na te pytania, praca przedstawia:
• Metodę automatycznej identyfikacji zdarzeń w przypadkach
użycia.
3 • Eksperymentalną ocenę
skuteczności
oraz
wydajności
zaproponowanej metody automatycznej identyfikacji zdarzeń w
przypadkach użycia.
• Porównanie skuteczności oraz wydajności zaproponowanej
metody oraz metody ręcznych przeglądów ukierunkowanych na
identyfikację zdarzeń w przypadkach użycia.
Przypadki użycia zapisywane są za pomocą języka naturalnego, dlatego
też proponowana metoda automatyczna musi być w stanie analizować
przypadki użycia z wykorzystaniem metod i narzędzi przetwarzania
języka naturalnego. Zakłada się, że rozprawa nie ma na celu rozwijanie
metod
i
technik
przetwarzania
języka
naturalnego,
a
jedynie
wykorzystanie istniejących metod w celu analizy tekstów przypadków
użycia. Dodatkowo, zakłada się, że analizowane przypadki użycia
zapisane są w języku angielskim i narzędzia do przetwarzania tego języka
będą wykorzystywane.
2. Przypadki użycia jako sposób zapisu wymagań
Przypadki użycia zostały zaproponowane przez Ivara Jacobsona w
latach 80-tych XX wieku, a w pełni opisane w 1992 roku [11] jako część
obiektowego podejścia do wytwarzania oprogramowania. Przypadki
użycia występują w dwóch wersjach: diagramowej i tekstowej. Diagramy
przypadków użycia są częścią języka modelowania UML [15].
Rysunek 1. przedstawia przykładowy diagram przypadków użycia.
Diagramy
przypadków
użycia
przedstawiają
wyłącznie
ogólną
informację o aktorach oraz ich celach, dlatego też wykorzystuje się
tekstowe przypadki użycia, które pozwalają na przekazanie większej
ilości informacji.
4 Rysunek 1
Tekstowe przypadki użycia składają się z trzech głównych części:
• nazwy, która przedstawia cel aktora;
• scenariusza
głównego,
który
prezentuje
interakcję
między
aktorami, interakcja ta powinna prowadzić do celu określonego w
nazwie przypadku użycia;
• sekcji zawierającej scenariusze wyjątkowe oraz alternatywne –
sekcja ta opisuje dodatkowe sposoby osiągnięcia celu przez aktora
oraz
sytuacje
wyjątkowe,
które
mogą
wystąpić
podczas
wykonywania scenariusza głównego.
Przykład tekstowego przypadku użycia przedstawiony jest na Rysunku 2.
Rozprawa skupia się na zdarzeniach, które powodują przerwania
scenariusza głównego (np. Podany kod PIN jest niepoprawny z przykładu
podanego na Rysunku 2). Informacje o zdarzeniach nie są widoczne na
diagramach przypadków użycia, z tego powodu w rozprawie brane są pod
uwagę wyłącznie tekstowe przypadki użycia.
Należy zauważyć, że przypadki użycia zapisywane są w języku
naturalnym. Pozwala to na łatwiejsze zrozumienie wymagań przez
uczestników projektów, którzy nie znają terminologii z dziedziny IT.
Wadą wykorzystania języka naturalnego jest jednak trudność w
automatycznej analizie. Nie ma żadnej narzuconej składni przypadków
5 użycia, istnieją jednak pewne tzw. dobre praktyki [4,8], które pozwalają
na tworzenie przypadków użycia wysokiej jakości.
Rysunek 2
3. Proste metody zapewnienia jakości przypadków użycia
Jak wspominano wcześniej wysoka jakość przypadków użycia może
być zapewniona poprzez stosowanie tzw. dobrych praktyk. Takie
praktyki zostały zaproponowane m.in. przez Adolpha i in. [4].
Pogwałcenie tych praktyk można nazwać przykrymi zapachami.
Rozprawa przedstawia propozycję metod wykrywania przykrych
zapachów
w
przypadkach
użycia
przy
wykorzystaniu
narzędzi
przetwarzania języka naturalnego, takich jak Standford Parser [2] oraz
6 OpenNLP [1]. Zaproponowane metody są
w stanie automatycznie
wykrywać następujące przykre zapachy:
Za długi lub za krótki przypadek użycia. Jest zalecane [4], aby
scenariusze główne przypadków użycia miały miały między 3 a 9
kroków. Zaproponowana metoda opiera się na liczeniu kroków
przypadków użycia.
Powtarzające się akcje w sąsiadujących krokach. Według Adolpha i in.
[4] każdy krok scenariusza głównego powinien prowadzić interakcję do
przodu. W przypadku, jeśli podobne akcje (np. kroki „2. Użytkownik
wprowadza nazwę ulicy.“, „3. Użytkownik wprowadza numer domu“, „4.
Użytkownik wprowadza kod pocztowy“) występują w następujących po
sobie krokach to może to niepotrzebne wydłużać scenariusz główny. W
takim przypadku kroki powinny być złączone w jeden krok (np. „2.
Użytkownik podaje dane adresowe“). Sposób detekcji tego przykrego
zapachu opiera się na sprawdzeniu, czy w następujących po sobie
krokach powtarza się aktor (jako podmiot) oraz akcja (jako orzeczenie).
Niespójne nazewnictwo. W literaturze można spotkać wiele konwencji
nazywania przypadków użycia. Ciężko jest określi, która konwencja jest
najlepsza, ważne jednak, aby wybrana konwencja stosowana była
konsekwentnie w całej specyfikacji wymagań. W celu wykrywania tego
przykrego zapachu sprawdzana jest spójność formy czasownika, który
występuje w nazwie przypadku użycia.
Zbyt skomplikowana struktura kroku. Według Adolpha i in. [4] zdania
występujące w krokach przypadku użycia powinny być proste i powinny
7 składać się z trzech elementów: podmiotu, orzeczenia i dopełnienia.
Użycie tak prostej struktury utrudnia popełnienie błędu gramatycznego i
pozwala łatwiej zrozumieć dany krok. W celu detekcji tego przykrego
zapachu sprawdzane są liczby podmiotów, orzeczeń i dopełnień. Jeśli
któraś z tych liczb jest większa niż jeden to zakładane jest wystąpienie
przykrego zapachu.
Brak aktora. W każdym kroku powinien być jasno określony wykonawca
– aktor. Brak aktora powoduje, że krok może być zinterpretowany na
wiele sposobów. W celu identyfikacji tego przykrego zapachu
sprawdzane jest wystąpienie podmiotu w kroku wraz ze sprawdzeniem,
czy podmiot jest zdefiniowany w słowniku aktorów w danej specyfikacji
wymagań.
Używanie złych form czasowników oraz czasów. Dobre praktyki mówią,
że kroki przypadków użycia powinny być zapisywane w czasie Present
Simple oraz w aktywnej formie czasownika. Detekcja tego przykrego
zapachu opiera się na sprawdzeniu czasu oraz formy orzeczenia
występującego w kroku.
Używanie technicznego żargonu. Wykorzystanie w przypadkach użycia
słownictwa pochodzącego z dziedziny IT może skutkować brakiem
zrozumienia wymagań przez udziałowców projektu. W związku z tym
pisząc
przypadki
użycia
powinniśmy
unikać
wykorzystywania
technicznego żargonu. Metoda wykrywania tego przykrego zapachu
opiera się na przygotowanym słowniku terminów IT oraz sprawdzaniu,
czy słowa występujące w kroku występują jednocześnie w słowniku.
8 Kroki warunkowe. Różne scenariusze interkacji między aktorem a
system zależą od wielu warunków, naturalne więc wydaje się
wykorzystywanie struktury „jeśli warunek to akcja“. Jednak struktura
przypadków użycia jest tak zbudowana, że wszelkie warunki powinny
trafić do sekcji scenariuszy alternatywnych, a w scenariuszu głównym
powinna się znaleźć jedynie interkacja prowadząca do osiągnięcia celu
przez aktora. Sprawia to, że przypadek użycia jest łatwiejszy w czytaniu
oraz interpretacji. W celu wykrywania tego przykrego zapachu,
sprawdzane jest występowanie słów takich jak „if“, „whether“, „when“.
W
celu
zbadania
skuteczności
zaproponowanych
metod
został
przeprowadzony eksperyment z wykorzystaniem typowej specyfikacji
wymagań opartej na przypadkach użycia [5]. Zaproponowane metody
osiągnęły
następujące
wyniki
[13]:
• Dokładność (ang. accuracy) = 0.99
• Precyzja (ang. precision) = 0.80
Przeprowadzony eksperyment pozwala stwierdzić, że zaproponowane
metody mogą pomóc w skutecznej identyfikacji przykrych zapachów w
przypadkach użycia, a co za tym idzie mogą się przyczynić do
podniesienia jakości tworzonych przypadków użycia.
4. Ręczna metoda identyfikacji zdarzeń w przypadkach
użycia
W celu dokonania pełnej oceny automatycznej metody identyfikacji
zdarzeń w przypadkach użycia, skuteczność i wydajność podejścia
opartego na ręcznych przeglądach musiała zostać również zbadana. W
9 literaturze brakuje jednak metod służących identyfikacji zdarzeń, dlatego
też została zaproponowana metoda oparta na metodzie analizy ryzyka
systemów krytycznych HAZOP [16].
4.1. Wprowadzenie do metody HAZOP
HAZOP (Hazard and Operability Study) to ustrukturalizowana
technika
identyfikacji
i
analizy
ryzyka
w
istniejących
lub
projektowanych procesach i systemach. Pierwotnie metoda ta była
przeznaczona do analizy instalacji chemicznych. Później została
zaadopotowana również do innych dziedzin, w tym do analizy
komputerowych systemów krytycznych.
HAZOP angażuje grupę multidyscyplinarnych ekspertów, którzy
używają słów kluczowych analizują poszczególne elementy systemu, w
celu wykrycia ryzyka (ang. hazard). Wyróżnia się dwa rodzaje słów
kluczowych: pierwszorzędne odnoszą się do atrybutów (np. temperatura,
ciśnienie) i zależne są od rodzaju analizowanej instalacji/systemu;
drugorzędne to stała lista słów, które wskazują na ryzyka (np. NO,
MORE). Biorąc pod uwagę fragment instalacji, zespół ekspertów
interpretuje pary słów kluczowych i przy pomocy burzy mózgów próbuje
zidentyfikować jak najwięcej czynników ryzyka (np. para ciśnienieMORE może być zinterpretowana jako zbyt duże ciśnienie w probówce,
co może powodować stan zagrożenia w instalacji chemicznej). Na koniec
analizy powstaje raport ze wskazaniem zidentyfikowanych czynników
ryzyka oraz planowanymi akcjami eliminującymi dany czynnik.
4.2. Metoda H4U
Metoda H4U (HAZOP for Use Cases) oparta jest na słowach
kluczowych, które są fundamentem metody HAZOP. H4U wykorzystuje
10 te same drugorzędne słowa kluczowe co metoda HAZOP. Natomiast
pierwszorzędne słowa kluczowe dostosowane są do dziedziny jaką są
przypadki użycia. Następujące pierwszorzędne słowa kluczowe są
wykorzystane w metodzie H4U:
• Dane wejściowe i wyjściowe
• Dane przechowywane w systemie
• Czas
Eksperci analizą scenariusze główne przypadków użycia krok po kroku i
za pomocą par słów kluczowych identyfikują jak największa liczbę
możliwych zdarzeń, które mogą wystąpić w analizowanych krokach.
4.3. Eksperymentalna ocena metody H4U
Zostały przeprowadzone dwa eksperymenty, których celem była
ocena skuteczności oraz wydajności metody H4U. W eksperymentach
metoda H4U była porównywana z podejściem ad hoc, w którym
uczestnicy nie korzystają z żadnej konkretnej metody, a jedynie starają
się zindetyfikować jak największą liczbę zdarzeń czytając scenariusze
główne przypadków użycia. Eksperyment nr 1 przeprowadzony był
z osiemnastoma studentami specjalności Inżynieria Oprogramowania na
Politechnice Poznańskiej. Eksperyment nr 2 przeprowadzony był
z osiemdziesiącioma czterama pracownikami poznańskich firm IT.
Zadaniem uczestników eksperymentów była identyfikacja zdarzeń w
typowej specyfikacji opartej na przypadkach użycia [5].
Następujące miary zostały wykorzystane do oceny badanych
metod:
Wydajnosc( p) =
l.krokow( p)
[kroki /min]
T
11 €
gdzie:
• p to uczestnik eksperymentu;
• l.krokow(p) to liczba kroków przeanalizowanych przez kandydata
p;
• T to całkowity czas poświęcony na analizę specyfikacji (stała: 60
minut).
odleglosc( p )
∑ l.zdarzen( p,s)
Dokladnosc =
s=1
odleglosc( p )
∑ l.Zdarzen(s)
s=1
gdzie:
• p to uczestnik eksperymentu;
€
• odleglosc(p)
to najdalszy krok w specyfikacji przeanalizowany
przez uczestnika p;
• l.zdarzen(p,s) to liczba unikalnych zdarzeń zidentyfikowanych dla
kroku s przez uczestnika p;
• l.Zdarzen(p) to liczba unikalnych zdarzeń zidentyfikowanych dla
kroku s przez wszystkich uczestników eksperymentów.
Wyniki eksperymentu
Tabela 1 zawiera statystykę opisową eksperymentu nr 1, gdzie grupa G1
to grupa wykorzystująca podejście ad hoc, a grupa G2 to grupa
korzystająca z metody H4U.
Uczestnik
1
2
3
4
5
6
7
Wydajność
[kroki/min]
G1
G2
2,63
0,35
1,83
0,12
2,58
0,40
2,65
0,50
1,40
0,45
1,95
0,33
2,62
1,35
Dokładność
G1
0,25
0,22
0,18
0,09
0,13
0,09
0,25
G2
0,36
0,44
0,26
0,22
0,26
0,34
0,31
12 8
9
Min
Mediana
Średnia arytm.
Max
2,60
1,85
1,40
2,58
2,23
2,65
1,17
1,07
0,12
0,45
0,64
1,35
Tabela 1
0,14
0,19
0,09
0,18
0,17
0,25
0,05
0,12
0,05
0,26
0,26
0,44
Testowanie hipotez statystycznych W celu porównania wyników metody H4U oraz podejścia ad hoc
następujące hipotezy statystyczne zostały zbadane:
1.
H a 0 : ΘWydajnosc(G1) = ΘWydajnosc(G 2)
hipoteza alternatywna:
H a1 : ΘWydajnosc(G1) ≠ ΘWydajnosc(G 2)
2.
€
H b 0 : µDokladnosc(G1) = µDokladnosc(G 2)
hipoteza€alternatywna:
H b1 : µDokladnosc(G1) < µDokladnosc(G 2)
W celu €
sprawdzenia hipotezy dotyczącej wydajności został wykorzystany
test Wilcoxona, a w celu sprawdzenia hipotezy dotyczącej dokładności
€
test t-Studenta. W obu testach poziom istotności został ustalony na 0.05.
W wyniku przeprowadzenia procedury testującej obie hipotezy zerowe
zostały odrzucone.
Tabela 2 zawiera statystyka opisową eksperymentu nr 2, gdzie grupa G1
to grupa wykorzystująca podejście ad hoc, a grupa G2 to grupa
korzystająca z metody H4U.
13 Uczestnik
1
2
3
4
5
6
7
8
9
10
11
12
13
§4
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Min
Mediana
Średnia arytm.
Max
Wydajność
[kroki/min]
G1
G2
2,18
2,32
2,07
0,85
2,20
0,38
2,12
2,02
0,68
1,97
2,17
0,78
1,90
0,68
0,87
0,38
2,23
1,07
2,30
1,35
2,07
2,07
0,68
0,48
2,22
1,07
2,07
0,48
2,02
0,97
2,20
0,38
2,28
0,42
2,02
0,48
2,17
0,68
1,90
0,55
1,07
0,78
2,02
0,78
2,18
0,78
1,97
1,90
1,60
1,48
1,43
1,83
2,02
1,17
0,42
0,48
0,55
1,07
0,87
0,68
2,08
2,22
2,17
0,85
0,42
0,38
2,05
0,82
1,77
1,04
2,30
2,32
Tabela 2
Dokładność
G1
0,19
0,04
0,13
0,13
0,14
0,16
0,11
0,21
0,09
0,24
0,08
0,22
0,09
0,15
0,25
0,28
0,07
0,14
0,22
0,15
0,03
0,07
0,21
0,18
0,12
0,11
0,05
0,15
0,20
0,26
0,11
0,12
0,03
0,14
0,15
0,28
G2
0,13
0,36
0,45
0,05
0,03
0,23
0,09
0,08
0,10
0,28
0,11
0,23
0,07
0,22
0,19
0,14
0,23
0,09
0,35
0,18
0,26
0,17
0,36
0,14
0,08
0,07
0,31
0,26
0,14
0,15
0,23
0,30
0,03
0,17
0,26
0,45
14 Testowanie hipotez statystycznych W celu porównania wyników metody H4U oraz podejścia ad hoc
następujące hipotezy statystyczne zostały zbadane:
1.
H c 0 : ΘWydajnosc(G1) = ΘWydajnosc(G 2)
hipoteza alternatywna:
H c1 : ΘWydajnosc(G1) ≠ ΘWydajnosc(G 2)
2.
€
H d 0 : µDokladnosc(G1) = µDokladnosc(G 2)
hipoteza€alternatywna:
H d1 : µDokladnosc(G1) < µDokladnosc(G 2)
W wyniku
€ procedury testowania statystycznego obie hipotezy zerowe
zostały odrzucone.
€
Podsumowanie wyników eksperymentów
Wyniki
przeprowadzonych
eksperymentów
prowadzą
do
następujących wniosków:
• Maksymalna średnia dokładność identyfikacji zdarzeń w obu
przeprowadzonych eksperymentach wynosi 0,26. Pokazuje to, że
zadanie identyfikacji zdarzeń nie jest łatwe i że jest duże
zapotrzebowanie na nowe metody oraz narzędzia ukierunkowane
na pomoc w identyfikacji zdarzeń;
• Zaproponowana metoda H4U może pomóc w osiągnięciu większej
kompletności zdarzeń w przypadkach użycia w porównaniu do
podejścia ad hoc;
• Metoda H4U pomaga podnieść kompletność zdarzeń, jednak
wymaga ona znacznie więcej czasu niż podejście ad hoc.
15 5. Automatyczna identyfikacja zdarzeń w przypadkach
użycia
W celu poprawy dokładności oraz wydajności identyfikacji zdarzeń w
przypadkach użycia została zaproponowana metoda automatyczna, której
zadaniem jest wygenerowanie jak największej liczby możliwych zdarzeń
dla danego zbioru scenariuszy głównych.
Metoda automatyczna zakłada, że specyfikacja wymagań oparta na
przypadkach użycia składa się z następujących elementów:
• opisu aktorów, którzy biorą udział w przypadkach użycia;
• opisu obiektów informacyjnych, którymi operują aktorzy;
• przypadków użycia (do automatycznej identyfikacji zdarzeń
wystarczające są scenariusze główne).
Abstrakcyjny model kroku przypadku użycia
Metoda automatyczna zakłada, kroki przypadków użycia pisane są
w sposób prosty zgodnie z zasadą SVO (ang. Subject-Verb-Object). W
ten sposób dzięki analizie za pomocą dostępnych narzędzi przetwarzania
języka naturalnego możliwa jest automatyczna identyfikacja aktorów,
obiektów informacyjnych oraz aktywności, które występują w kroku.
Następujące abstrakcyjne byty mogą występować w krokach:
• Aktor – abstrakcyjny byt, który wykonuje akcje w kroku.
Wyróżniamy dwa typy aktorów: SYSTEM – reprezentuje
budowany system; USER – reprezentuje jednego z użytkowników
końcowych (jest zdefiniowany w specyfikacji wymagań).
• Aktywność – jest to akcja zainicjowana przez aktora, która operuje
na obiekcie informacyjnym. Na podstawie analizy istniejących
16 przypadków użycia zostało zidentyfikowanych 10 abstrakcyjnych
typów aktywności i są one zaprezentowane w Tabeli 3.
• Obiekty
infomacyjne
–
reprezentują
obiekty,
na
których
wykonywane są aktywności. Na podstawie analizy istniejących
przypadków użycia zostały zaproponowane właściwości, które
mogą być przypisane obiektom informacyjnym. Właściwości te
podzielone są na dwie grupy: AFP (ang. Activity-Free Properties)
oraz ASP (Activity-Sensitive Properties). Te pierwsze nie zależą
od aktywności wykonywanych na danym obiekcie informacyjnym,
te drugie natomiast zależą od tych aktywności. Tabela 4. zawiera
zaproponowane właściwości obiektów informacyjnych.
Abstrakcyjny typ aktywności
ADD
ENTER
LINK
READ
UPDATE
DELETE
SELECT
VALIDATE
CONFIRM
DISPLAY
Przykład kroku użycia
Autor dodaje nowy artykuł
Autor wprowadza tytuł artykułu
Autor łączy komentarz z artykułem
Autor przegląda dostępne artykuły
Autor zmienia tytuł artykuły
Autor usuwa artykuł
Autor wybiera artykuł
System sprawdza wprowadzony tytuł
Autor zatwierdza zmiany,
System prezentuje dostępne artykuły
Tabela 3
Właściwość
Przykład
AFP
SET
COMPOUND
AT_LEAST
NO_MORE_THAN
REMOTE
LONG_LASTING dla
aktywności X
TIMEOUTABLE dla
aktywności X
Artykuł
Karta kredytowa (składa się z nazwiska właściciela,
numeru, daty ważności, itp.)
Uczestnicy (których musi być nie mniej niż 10)
Uczestnicy (których nie może być więcej niż 50)
Karta kredytowa (której dane trzymane są w
zdalnym/zewnętrznym systemie)
ASP
Faktura (której eksport danych może trwać długi czas)
Przetarg (na który przyjmowanie niosków ma określony
termin)
Tabela 4
17 Dodatkowo wyróżnia się abstrakcyjne typy zdarzeń, które mogą
występować w przypadkach użycia. Zostało zaproponowanych 19
abstrakcyjnych typów zdarzeń, zaprezentowane są one w Tabeli 5.
Abstrakcyjny typ zdarzenia
WrongData
TooLittleLeft
Incomplete
AlreadyExist
ConnectionProblem
TooMuchSelected
NoObjectSelected
AlreadySelected
TooLittleSelected
DoesNotExist
LackOfConfirmation
NoDataDefined
WantsToInterrupt
TooLateForDoingThis
WantsToWithdraw
NoDataProvided
LateConfirmation
TooEarlyForDoingThis
TooMuchDataProvided
Przykład
Numer ISBN jest niepoprawny.
Saldo konta bankwego jest równe zero.
Nie został podany numer ISBN książki.
Książka z podanym numerem ISBN już istnieje
w systemie.
Nie można się było połączyć z operatorem karty
kredytowej.
Zaznaczono zbyt wiele książek
Nie zaznaczono żadnej książki.
Zaznaczone książki były już wybrane.
Wybrano zbyt mało książek.
Podany artykuł nie istnieje.
Autor nie potwierdził operacji usuwania.
Nie zdefiniowano żadnych książek.
Autor anuluje operację eksportu danych.
Termin na dodawanie podań minął.
Nie znaleziono w badanej bazie przypadków
użycia
Nie znaleziono w badanej bazie przypadków
użycia
Nie znaleziono w badanej bazie przypadków
użycia
Nie znaleziono w badanej bazie przypadków
użycia
Nie znaleziono w badanej bazie przypadków
użycia
Tabela 5
Reguły identyfikacji zdarzeń
Zostały zaproponowane dwie reguły wnioskowania o zdarzeniach w
przypadkach użycia. Następujące elementy występują w regułach:
• R – reprezentuję rolę (abstrakcyjny aktor)
• A – reprezentuje abstarkcyjny typ aktywności
• O – reprezentuje obiekt informacyjny
18 • P – reprezentuje właściwość obiektu informacyjnego
• S – reprezentuje krok, dla którego identyfikowane są zdarzenia
• E – reprezentuje abstrakcyjny typ zdarzeń
• Observed – to skończony zbiór aksjomatów w postaci <R,A,P,E>.
Każdy akcjomat oznacza, że aktywność A wykonywana przez
aktora R na obiekcie informacyjnym mającym właściwość P może
prowadzić do wystąpienia zdarzenia E. Zaproponowane elementy
zbioru Observed zaprezentowane są w Tabeli 6 (komórki z
gwiazdką oznaczają, że dany aksjomat jest ważny niezależnie od
właściwości obiektu informacyjnego).
• AFP - to funkcja, której dziedziną jest skończony zbiór obiektów
informacyjnych, a zbiorem wartości jest zbiór właściwości obiektu
informacyjnego.
Prosta reguła identyfikacji zdarzeń zakłada, że właściwości obiektów
informacyjnych zależą wyłącznie od obiektów informacyjnych, a nie od
aktywności na nich wykonywanych. Prosta reguła identyfikacji zdarzeń
ma następującą postać:
S =< R, A,O >,P ∈ AFP(O),< R, A,P, E >∈ Observed
S →◊E
Złożona
reguła
identyfikacji
zdarzeń
bierze
pod
uwagę
właściwości obiektów informacyjnych, które zależą nie tylko od samych
€
obiektów informacyjnych, ale również od aktywności, które są na nich
wykonywane. Reguła ta wykorzystuje funkcję ASP, która dla obiektu
informacyjnego zwraca skończony zbiór par <P,A>, gdzie P oznacza
właściwość, a A oznacza aktywność dla, której właściwość P jest
prawdziwa. Złożona reguła identyfikacji zdarzeń ma następującą postać:
19 S =< R, A,O >,< P, A >∈ ASP(O),< R, A,P, E >∈ Observed
S →◊E
Aktor (R)
Aktywność (A)
USER
USER
USER
USER
USER
SYSTEM
USER
USER
USER
USER
USER
USER
USER
USER
USER
SYSTEM
ENTER
ENTER
ENTER
ENTER
ENTER
DISPLAY
SELECT
SELECT
SELECT
SELECT
DELETE
READ
LINK
SELECT
CONFIRM
ADD
ENTER
LINK
READ
UPDATE
DELETE
SELECT
VALIDATE
CONFIRM
DISPLAY
ADD
ENTER
LINK
READ
UPDATE
DELETE
SELECT
VALIDATE
CONFIRM
DISPLAY
€
USER
Właściwość
Obiekty
Informacyjnego (P)
SET
COMPOUND
SET
REMOTE
AT_LEAST
SET
SET
SET
NO_MORE_THAN
*
*
*
*
AT_LEAST
*
LONG_LASTING
Ty zdarzenia (E)
WrongData
Incomplete
AlreadyExists
ConnectionProblem
TooLittleLeft
NoDataDefined
NoDataDefined
AlreadySelected
TooMuchSelected
NoObjectSelected
DoesNotExist
DoesNotExist
Incomplete
TooLittleSelected
LackOfConfirmation
WantsToInterrupt
TIMEOUTABLE
TooLateForDoingThis
Tabela 6
Generowanie opisów zdarzeń Przedstawione
reguły
identyfikacji
zdarzeń
pozwalają
na
identyfikację akstrakcyjnych typów zdarzeń. W celu wygenerowania
20 właściwych opisów zdarzeń, które mogą być umieszczone bezpośrednio
w specyfikacji wymagań zostało wykorzystane narzędzie do generowania
języka naturalnego (ang. NLG – Natural Language Generation)
SimpleNLG [9].
Eksperymentalna ocena automatycznej identyfikacji zdarzeń
Metody
zaprezentowane
w
tym
rozdziale
zostały
zaimplementowane w prototypowym narzędziu. Narzędzie to opiera się
na edytorze przypadków użycia UC Workbench [14]. Prototyp został
wykorzystany do zidentyfikowania możliwych zdarzeń w scenariuszach
głównych tej samej specyfikacji, która była wykorzystana przy ocenie
metod ręcznych.
W celu oceny dokładności oraz wydajności automatycznej
identyfikacji zdarzeń zostały wykorzystanane takie samie miary jak w
przypadku ocen metod ręcznych. Tabela 7. przedstawia wyniki
przeprowadzonych
eksperymentów.
Co
istotne,
po
pierwszej
automatycznej identyfikacji zdarzeń okazało się, że zbiór Observed
można poszerzyć o dodatkowe elementy, dzięki czemu dokładność
prototypu podniosła się z początkowego poziomu 0.73 do 0.89.
Dokładność
Wydajność
Jak
Prototyp
H4U Max
Ad hoc Max
(0.73) 0.89
10.8
0.44
2.32
0.28
2.65
widać
H4U
średnia
0.26
0.85
Tabela 7
z przeprowadzonych
ekperymentów
Ad hoc
średnia
0.18
2.58
metoda
automatyczna pozwala na osiągnięcie wysokiej skuteczności (0.89) przy
wysokiej wydajności (analiza 10.8 kroków na minutę).
21 Dodatkowo
został
przeprowadzony
ekperyment
oparty
na
założeniach testu Turinga. Celem eksperymentu było sprawdzenie, czy
jakość językowa wygenerowanych automatycznie zdarzeń jest na
odpowiednio wysokim poziomie. W tym celu uczestnicy eksperymentu
(studenci Inżynierii Oprogramowania) zostali poproszeni o ocenę par
zdarzeń, każda para zawierała zdarzenie wygenerowane przez prototyp
oraz zdarzenie zaproponowane przez człowieka w poprzednich
eksperymentach (oba zdarzenia dotyczyły tego samego kroku). Zadaniem
uczestników eksperymentu była ocena, które ze zdarzeń wydaje się
bardziej poprawne językowo. Eksperyment pokazał, że uczestnicy nie
byli w stanie odróżnić zdarzeń wygenerowanych przez narzędzie od
zdarzeń zaproponowanych przez człowieka.
6. Podsumowanie
W rozprawie doktorskiej zaprezentowano oraz porównano dwie
metody identyfikacji zdarzeń w przypadkach użycia, metodę ręcznych
przeglądów H4U oraz metodę automatyczną. Obie metody zostały
porównane
w
sposób
eksperymentalny.
Najważniejsze
wnioski
z przeprowadzonych badań:
• Zdarzenia w przypadkach użycia można traktować jak ryzyka w
systemach czasu rzeczywistego. Bazując na tym założeniu, została
zaproponowana
metoda
H4U,
która
pozwala
skuteczniej
identyfikować zdarzenia niż podejście ad hoc.
• Ręczne metody identyfikacji zdarzeń nie pozwalają na osiągnięcie
wysokiej dokładności w identyfikacji zdarzeń (maksymalna
dokładność na poziomie 0.45, a maksymalna średnia na poziomie
0.26).
22 • Została zaproponowana metoda automatycznej identyfikacji
zdarzeń w przypadkach użycia. Metoda została zaimplementowana
w postaci prototypowego narzędzia z wykorzystaniem narzędzia i
technik NLP oraz NLG. Prototyp był w stanie osiągnąć dokładność
na poziomie 0.89 przy analizowaniu ponad 10 kroków na minutę.
23 Bibliografia
[1] OpenNLP homepage http://opennlp.apache.org, dostępne: 4th June
2013.
[2]
The
Stanford
Parser:
A
http://nlp.stanford.edu/software/lex-parser.shtml,
2013.
statistical
parser
dostępne: 4th June
[3] Chaos: A recipe for success, 2004. Technical report, Standish Group,
2004.
[4] S. Adolph, P. Bramble, A. Cockburn, and A. Pols. Patterns for
Effective Use Cases. Addison-Wesley, 2002.
[5] B. Alchimowicz, J. Jurkiewicz, M. Ochodek, and J. Nawrocki.
Building benchmarks for use cases. Computing and Informatics,
29(1):27–44, 2010.
[6] David Baccarini, Geoff Salm, and Peter E. D. Love. Management of
risks in information technology projects. Industrial Management and Data
Systems, 104(4):286–295, 2004.
[7] John M. Carroll, Mary Beth Rosson, George Chin, Jr., and Jürgen
Koenemann. Requirements development in scenario-based design. IEEE
Trans. Softw. Eng., 24(12):1156–1170, December 1998.
[8] A. Cockburn. Writing Effective Use Cases. Addison-Wesley Boston,
2001.
[9] Albert Gatt and Ehud Reiter. Simplenlg: a realisation engine for
practical applications. In Proceedings of the 12th European Workshop on
Natural Language Generation, ENLG ’09, pages 90–93, Stroudsburg, PA,
USA, 2009. Association for Computational Linguistics.
[10] I. Jacobson. Concepts for modeling large real time systems. Royal
Institute of Technology, Dept. of Telecommunication Systems-Computer
Systems, 1985.
24 [11] I. Jacobson, M. Christerson, P. Jonsson, and G. Övergaard. ObjectOriented Software Engineering: A Use Case Driven Approach. Addison
Wesley Longman, Inc, 1992.
[12] Leon A. Kappelman, Robert McKeeman, and Lixuan Zhang. Early
warning signs of it project failure: The dominant dozen. EDPACS,
35(1):1–10, January 2007.
[13] K. Krawiec, J. Stefanowski, Uczenie maszynowe i sieci neuronowe,
Wydawnictwo Politechniki Poznańskiej 2004
[14] J. Nawrocki and Ł. Olek. UC Workbench - A tool for writing use
cases. In 6th International Conference on Extreme Programming and
Agile Processes, volume 3556 of Lecture Notes in Computer Science,
pages 230–234. Springer-Verlag, June 2005.
[15] OMG. OMG Unified Modeling LanguageTM(OMG UML),
superstructure, version 2.3, May 2010.
[16] F. Redmill, M. Chudleigh, J. Catmur. System safety : HAZOP and
software HAZOP. Wiley, 1999.
[17]George E. Stark, Paul W. Oman, Alan Skillicorn, Alan Ameele.An
examination of the effects of requirements changes on software
maintenance releases. Journal of Software Maintenance, 11(5):293–309,
1999.
[18] Alistair Sutcliffe, Neil Maiden, Shailey Minocha, Darrel Manuel.
Supporting scenario-based requirements engineering. IEEE Transactions
on Software Engineering, 24(12), December 1998.
[19] K. T. Yeo Critical failure factors in information system projects.
International Journal of Project Management, 20(3):241–246, April 2002.
25