ROZDZIAŁ 99 KOMPLEKSOWY SYSTEM POOWEGO WYKORZYSTAIA MODELI OPROGRAMOWAIA

Wzrastająca złożoność systemów oprogramowania, spowodowana złożonością wymagań i zmiennością technologii, powoduje problemy związane z ponownym wykorzystaniem zgromadzonych konkretnych rozwiązań. Niniejszy rozdział przedstawia metodę ponownego wykorzystania tzw. „przypadków oprogramowania” opartą na ogólnej metodzie CBR. W przedstawionej metodzie, re-użyciu podlegają specyfikacje wymagań powiązane w sposób jednoznaczny z modelami projektowymi i kodem. Wyszukiwanie przypadków oprogramowania następuje poprzez porównanie specyfikacji wymagań zapisanych przy pomocy języka modelowania RSL o dobrze określonej składni i semantyce. Modele projektowe oraz kod w ramach przypadków oprogramowania pochodzą bezpośrednio z modelu wymagań. Przejście między wymaganiami a projektem następuje zgodnie z regułami transformacji, które umożliwiają częściową automatyzację procesu. Elementy projektu i kodu możliwe do ponownego wykorzystania oznaczane są w sposób jednoznaczny na podstawie śladów łączących je ze znalezionymi elementami modelu wymagań. Taka metodyka postępowania została poddana ewaluacji i oceniona pozytywnie przez kilka zespołów deweloperów.

1. WPROWADZEIE Współczesne systemy oprogramowania cechuje wzrastająca złożoność. Ta złożoność związana jest ściśle ze złożonością i zmiennością rozwiązywanych problemów specyfikowanych przy pomocy wymagań. Złożone problemy prowadzą do jeszcze bardziej złożonych rozwiązań w przestrzeni technologicznej, która zmienia się jeszcze szybciej niż stawiane problemy. Pomimo tego, a może właśnie – z tego powodu – większość projektów wydaje się ignorować wcześniej zgromadzoną wiedzę na temat wytworzonych systemów oprogramowania [7]. Dużym problemem jest brak standardowych metod zapisu tej złożonej wiedzy. W szczególności, brakuje metod jednoznacznego powiązania postawionych problemów i ich rozwiązań, które pozwoliłyby na szybkie wyszukiwanie i porównywanie do rozwiązanych już wcześniej przypadków. W niniejszym rozdziale zajmiemy się metodą na rozwiązanie powyżej postawionej kwestii, która została zilustrowana na rysunku 1. Typowy projekt programistyczny wytwarza określone „artefakty” w postaci specyfikacji wymagań, dokumentów projektowych, kodu i innych. Dodatkowo, gromadzona jest pewna wieMichał Śmiałek: Politechnika Warszawska, Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej, ul. Koszykowa 75, 00-662 Warszawa, [email protected]

M. Śmiałek

dza nieartykułowana (w umysłach wytwórców). Czasami, tworzone są pewne uogólnione rozwiązania w postaci wzorców projektowych. Niestety, wspomniane artefakty są trudne do ponownego wykorzystania, nawet jeśli nowo postawiony problem jest bardzo podobny do poprzednio już rozwiązanego. Spowodowane jest to tym, że wiedza ta nie jest uporządkowana w sposób umożliwiający łatwe porównywanie i odzyskiwanie. Problemem jest, jak pokazano na rysunku 1, przeniesienie do aktualnego środowiska pracy projektu, właściwych artefaktów lub ich fragmentów, wybranych spośród zgromadzonej wcześniej wiedzy. Środowisko pracy projektu Produkty wymagań

Produkty projektowe i implementacyjne

?

Początkowe Potrzeby klienta

Istniejąca Wiedza Dokumenty wymagań

Dokumenty projektowe

Gotowy kod

Wzorce

Wiedza nieartykuowana

Rys. 1. Uporządkowanie istniejącej wiedzy o oprogramowaniu

W niniejszym rozdziale przedstawimy metodę, w której gromadzenie oraz odzyskiwanie zgromadzonej wiedzy w dziedzinie systemów oprogramowania jest potraktowane w sposób kompleksowy. Podstawowym założeniem jest oparcie się podczas wytwarzania wszystkich artefaktów na dokładnie wyspecyfikowanych językach. W szczególności, dotyczy to języków modelowania wymagań, modelowania systemu (jego architektury i szczegółowych rozwiązań projektowych) oraz języków programowania. Równocześnie, bardzo istotna jest możliwość jednoznacznego powiązania wszystkich wytwarzanych artefaktów z poszczególnymi elementami specyfikacji wymagań. W podrozdziale 2 zostaną zdefiniowane tzw. przypadki oprogramowania, które stanowią jednostki gromadzenia wiedzy o systemie oprogramowania powiązanej w jednoznaczny sposób i zapisanej w dobrze zdefiniowanym języku. Ta wiedza bierze swoje źródło w specyfikacji zapisanej w języku specyfikacji wymagań przedstawionym w podrozdziale 3. Z kolei, w podrozdziale 4 przedstawiono sposób przekształcenia specyfikacji wymagań w projekt techniczny systemu, a następnie w kod. Tworzy to konkretną ścieżkę postępowania (wspomaganą odpowiednimi narzędziami), której efektem jest wytworzenie w projekcie wiedzy dającej się w łatwy sposób przeszukiwać i odzyskiwać. Odpowiednie mechanizmy wyszukiwania i odzyskiwania zostaną przedstawione w podrozdziale 5.

2. PRZYPADKI OPROGRAMOWAIA Pragnąc efektywnie odzyskać wiedzę programistyczną chcielibyśmy mieć możliwości porównania zgromadzonej już wiedzy z aktualnie postawionym problemem. Oznacza to, że gromadzona wiedza musi posiadać definicje wcześniej postawionych konkretnych problemów sformułowane w taki sam sposób, jak aktualny problem. Zauważmy, że takie podejście zgodne jest z bardzo rozpowszechnioną obecnie metodą 2

Kompleksowy system ponownego wykorzystania …

CBR (ang. case based reasoning) [1] polegającą na odzyskiwaniu wiedzy sformułowanej w postaci rozwiązań konkretnych przypadków. Dla odzyskiwania oprogramowania musimy zatem zdefiniować „przypadki oprogramowania”. Definicja Przypadek oprogramowania to zestaw powiązanych modeli oraz kodu stanowiących produkty przedsięwzięcia budowy systemu oprogramowania realizującego pewną, chociażby minimalną, lecz kompletną dla użytkowników tego systemu funkcjonalność. Modele oraz kod zapisane są w językach tekstowych lub graficznych, których składnia określona jest przy pomocy formalnie zadanej gramatyki lub meta modelu. Powiązania między modelami oraz modelami i kodem zdefiniowane są na zasadzie wskazania par zależności między poszczególnymi elementami tych modeli i kodu. Każdy element kodu w ramach przypadku oprogramowania powinien posiadać ciąg powiązań, który prowadzi do co najmniej jednego elementu modelu wymagań. Przypadek oprogramowania Model wymagań

Model architektoniczny

«map»

Model projektowy

«map»

Kod

«map»

Rys. 2. Struktura przypadku oprogramowania

Ta definicja została zilustrowana na rysunku 2. Widzimy, że każdy przypadek oprogramowania posiada model wymagań oraz powiązane z nim (mapowane) artefakty projektowe (architektura, projekt szczegółowy) i implementacyjne (kod, scenariusze testów). Ważne z punktu widzenia możliwości odzyskiwania przypadków oprogramowania są dwa elementy: precyzyjne formułowanie wymagań oraz jednoznaczne powiązanie elementów wymagań z pozostałymi elementami. W przypadku zrealizowania tych dwóch postulatów, odzyskiwanie można zorganizować na bazie porównywania wymagań i wskazywania możliwych do odzyskania elementów projektu i kodu, wynikających z powiązań z porównywanymi wymaganiami. Zostanie to omówione dokładniej w podrozdziale 5. Należy w tym miejscu podkreślić, że o ile specyfikacje języków programowania posiadają wystarczająco dobrze określoną składnię oraz semantykę, o tyle brakuje języków specyfikowania wymagań oraz projektowania systemów, które można wykorzystać do formułowania przypadków oprogramowania. Język UML [8], powszechnie wykorzystywany w tych celach posiada co prawda odpowiednią gramatykę (składnię abstrakcyjną i konkretną), ale brakuje dobrze określonej semantyki. Szczególnie jest to widoczne dla modelu przypadków użycia, którego sposób definicji w języku UML jest bardzo niejednoznaczny i zdecydowanie zbyt mało szczegółowy w stosunku do potrzeb zasygnalizowanych w poprzednich akapitach. Dotyczy to również języka SysML [9], mimo, że ten posiada fragment dedykowany do opisu wymagań. Dedykowane języki specyfikacji wymagań (np. Tropos [15], Triskell RDL [14]) dostarczają odpowiednich formalnych specyfikacji, ale nie zapewniają możliwości jednoznacznego powiązania z modelami projektowymi zapisanymi np. w języku UML oraz nie posiadają elementów umożliwiających porównywanie w celu odzyskania. 3

M. Śmiałek

3. JĘZYK SPECYFIKACJI WYMAGAŃ Językiem specyfikacji wymagań, który posiada cechy wspomagające ponowne wykorzystanie przypadków oprogramowania jest język RSL (ang. requirements specification language). Dokładna specyfikacja składni oraz semantyki tego języka została zawarta w [3]. Tutaj przedstawimy zasadnicze elementy tego języka, które stanowią podstawę przedstawionych w tym rozdziale mechanizmów ponownego wykorzystania oprogramowania. () Każdy klient może zapisać się : na : ćwiczenia przy terminalu lub online poprzez Internet. Po rejestracji, klient musi otrzymać : potwierdzenie : rezerwacji. Podczas dokonywania rezerwacji, system powinien sprawdzić dostępność : ćwiczeń. ()

W001

Obsługa ćwiczeń

Rys. 3. Przykład wymagania i jego reprezentacji w języku RSL

Tworzenie specyfikacji wymagań w języku RSL oparte jest na fundamentalnej zasadzie rozdziału „wymagań jako takich” od reprezentacji wymagań (patrz [10]). Ilustruje to rysunek 3. „Wymaganie jako takie” posiada swoją nazwę, identyfikator (tu: W0001) oraz odpowiednie atrybuty, jak termin zgłoszenia czy priorytet (niewidoczne na rysunku). Tak określone wymaganie stanowi w projekcie programistycznym jednostkę zarządzania (śledzenie realizacji wymagań, zmiany wymagań itp.). Jednocześnie, dla tak określonego wymagania należy wyspecyfikować jego reprezentację. Język RSL dopuszcza różne rodzaje reprezentacji: graficzne i tekstowe (patrz [11]). Tutaj skoncentrujemy się na reprezentacjach tekstowych. Słowa

Czasownik

Przymiotnik

Rzeczownik

Przyimek

Rzeczownik

zapisać

zarejestrowany

klient

na

ćwiczenia

Fraza

zarejestrowany klient zapisać zarejestrowany klient

Prosta Fraza Czasownikowa Złożona Fraza Czasownikowa

zapisać zarejestrowany klient na ćwiczenia

Rys. 4. Słowa i frazy w języku RSL

Na rysunku 3 przedstawiono reprezentację wymagania w postaci tekstu z hiperłączami. W tekście tym znajdują się frazy (np. zapisać się : na : ćwiczenia), które powiązane są ze słownikiem omówionym w dalszej części tego podrozdziału. Frazy zbudowane są zgodnie z wbudowaną w język RSL gramatyką. Rysunek 4 przedstawia przykłady fraz oraz pokazuje ich budowę. Najprostsza fraza składa się z rzeczownika lub z rzeczownika z przymiotnikiem (np. zarejestrowany : klient). Po dodaniu czasownika i ew. drugiego rzeczownika uzyskujemy frazy czasownikowe. Zauważmy, że przedstawione na rysunku frazy nie zawierają odmiany słów. W języku RSL, fraza w słowniku pisana jest w formie podstawowej. Dopiero umieszczenie danej frazy w reprezentacji wymagania umożliwia dodanie konkretnej odmiany. 4

Kompleksowy system ponownego wykorzystania …

Klient Zapisanie się na ćwiczenia

1. 2. 3. 4. 5. 6.

Klient : chce : zapisać się : na : ćwiczenia. System : sprawdza : dostępność : ćwiczeń. System : pokazuje : harmonogram. Klient : wybiera : termin : z : harmonogramu. System : pokazuje : okno podsumowania rezerwacji. System : zapisuje : klienta : na : ćwiczenia.

Rys. 5. Scenariusze przypadków użycia w gramatyce PDO

Reprezentacja wymagania z rysunku 3 zawiera frazy zagnieżdżone w swobodnym tekście. Wymagania zapisane jako swobodny tekst nie stwarzają niestety warunków do jednoznacznego ich przekształcania w modele projektowe. Brakuje również metod na porównywanie tego typu tekstów (metody rozpoznawania języka naturalnego) w celu odzyskania powiązanych artefaktów projektowych i implementacyjnych. Dlatego też, w języku RSL wprowadzono reprezentacje wymagań, które składają się jedynie ze zdań w języku ograniczonym do przedstawionych powyżej fraz. Przykład takiej reprezentacji znajduje się na rysunku 5. Wymaganiem jest tam przypadek użycia, czyli jednostka funkcjonalności budowanego systemu. Dla przypadku użycia został przedstawiony scenariusz składający się ze zdań POD (Podmiot-OrzeczenieDopełnienie). Każde z tych zdań zawiera podmiot odpowiadający frazie prostej oraz predykat (orzeczenie z dopełnieniem) odpowiadający frazie czasownikowej. Scenariusz z rysunku 5 składa się z 6 takich zdań przedstawiających kolejne akcje podejmowane przez użytkownika (aktora przypadku użycia) oraz system. Kolejne akcje dla danego przypadku użycia, zapisane w kilku scenariuszach jak na rysunku 5 tworzą pewną sieć akcji. Tą sieć można przedstawić na diagramie czynności podobnym do tego zdefiniowanego w języku UML (patrz [11]). Należy zauważyć, że w języku UML nie ma zdefiniowanej składni a tym bardziej semantyki akcji dla specyfikacji wymagań. Język RSL definiuje składnię języka akcji w postaci zdań POD. Zdefiniowana jest również semantyka tych akcji. Jest ona określona na dwa sposoby. Pierwszy sposób związany jest z łączami do modelu słownikowego. Drugi sposób polega na mapowaniu elementów modelu wymagań na model projektowy i zostanie przedstawiony w podrozdziale 4.

Rys. 6. Notacja dla słownika; przykład łączy do elementów scenariusza

Zasady działania łączy do słownika oraz jego budowę zaprezentowano na rysunku 6. Słownik składa się z elementów dziedziny (pojęć słownikowych). Pojęcia na 5

M. Śmiałek

diagramach oznaczane są jako prostokąty z nazwą (np. ćwiczenia lub klient na rysunku 6). Wewnątrz oznaczenia pojęcia znajdują się oznaczenia wszystkich fraz związanych z tym pojęciem. Można zauważyć, że diagramy pojęć zapisane w języku RSL podobne są do diagramów klas zapisanych w języku UML, co ułatwia ich zrozumienie. Jednocześnie, w wyraźny sposób przeniesiony jest akcent z dziedziny projektowania systemów (UML) w dziedzinę specyfikowania wymagań (RSL). Słownik stanowi dla danego przypadku oprogramowania centralne miejsce, gdzie definiowane są wszystkie pojęcia i frazy występujące w reprezentacjach wymagań. Taka centralizacja prowadzi do zwiększenia spójności specyfikacji wymagań. Na przykład fraza pokazać : harmonogram (patrz rys. 6) może być wykorzystana jako łącze w wielu scenariuszach przypadków użycia. Jednocześnie, zapobiega to używaniu wielu terminów na oznaczenie tego samego pojęcia (por. frazę przedstawić : plan zajęć), co zostało omówione m.in. w [10]. Centralny słownik umożliwia również łatwe porównywanie różnych specyfikacji wymagań dla ponownego wykorzystania. W tym celu, terminy użyte w nazwach pojęć i treści fraz tłumaczone są na globalną terminologię (np. opartą na systemie WordNet [2]).

4. TWORZEIE PRYPADKÓW OPROGRAMOWAIA PRZY POMOCY TRASFORMACJI MODELI Kolejnymi, po zapisaniu specyfikacji wymagań, etapami budowy systemu są etapy projektowania i implementacji. Projekt budowanego systemu powinien opisywać jego strukturę oraz dynamikę (sposób działania). Na poziomie opisu architektury często do tego celu wykorzystywane są diagramy komponentów i diagramy sekwencji pisane w języku UML. Architekt, tworząc odpowiednie modele posługuje się specyfikacją wymagań oraz swoją wiedzą na temat rozwiązań architektonicznych. Taką wiedzę można częściowo zawrzeć w zestawie reguł przekształcania wymagań zapisanych w języku RSL w modele architektoniczne zapisane w języku UML. ćwiczenia Zapisanie się na ćwiczenia

Warstwa prezentacji

chcieć zapisać się na ćwiczenia sprawdzić dostępnoś ć ćwiczenia

1. 2. 3. 4. 5. 6.

Klient : chce : zapisać się : na : ćwiczenia. System : sprawdza : dostępność : ćwiczeń. System : pokazuje : harmonogram. Klient : wybiera : termin : z : harmonogramu. System : pokazuje : okno podsumowania rezerwacji. System : zapisuje : klienta : na : ćwiczenia.

pokaż

zapisać klienta na ćwiczenia

klient

Logika aplikacji sprawdź

przelicz

harmonogram pokazać harmonogram

Logika biznesu

wybrać termin z harmonogramu

Rys. 7. Transformacja przypadków użycia i pojęć słownikowych w model architektury

Na rysunku 7 przedstawiono ogólne zasady transformacji, omówione dokładnie w [12]. Podstawowym założeniem architektonicznym jest zastosowanie architektury 6

Kompleksowy system ponownego wykorzystania …

warstwowej z wydzieleniem dwóch warstw logiki: aplikacji i biznesu. Warstwa logiki aplikacji odpowiada za realizację scenariuszy przypadków użycia, czyli nadzoruje kolejność wykonywania akcji na tym poziomie. Z kolei warstwa logiki biznesowej odpowiada za wykonywanie akcji biznesowych, czyli przetwarzanie danych związane z frazami czasownikowymi pojęć słownikowych. W związku z tym, podstawowe reguły transformacji określają sposób przekształcenia modelu przypadków użycia w komponenty warstwy logiki aplikacji i modelu słownikowego w komponenty warstwy logiki biznesowej. Bardziej szczegółową ilustrację reguł transformacji zawarto na rysunku 8. Widzimy, że grupy przypadków użycia przekształcane są w interfejsy warstwy logiki aplikacji. Grupowanie to zależne jest od tego, w jaki sposób przypadki użycia pakietyzowane są na poziomie specyfikacji wymagań. Każdy przypadek użycia odpowiada jednej operacji interfejsu odpowiadającego pakietowi przypadków użycia. Można zauważyć, że takie rozwiązanie jest prawidłowe tylko dla niektórych platform technologicznych. Dla platform, w których działanie interfejsu użytkownika oparte jest na zdarzeniach, bardziej odpowiednia byłaby reguła generacji osobnego interfejsu dla każdego przypadku użycia. Grupy pojęć słownikowych przekształcane są w odpowiednie komponenty. Tutaj również obowiązuje reguła przekształcania pakietu pojęć w jeden komponent – warstwy logiki biznesowej. Dla każdego pojęcia generowany jest jeden interfejs, który zawiera operacje odpowiadające frazom czasownikowym zawartym w tym pojęciu. IRezerwowanie Zrezygnowanie z ćwiczeń

UIOkna

ćwiczenia

klient

harmonogram

Prezentacja

Rezerwowanie

Zapisanie się na ćwiczenia

ICwiczenia IKlient

IHarmonogram

PlanyCwiczen

Rys. 8. Generacja interfejsów dla przypadków użycia i pojęć słownikowych

Na bazie wygenerowanej struktury systemu możemy również wygenerować diagramy definiujące jego dynamikę. Reguły w tym przypadku są bardziej złożone, gdyż dotyczą poziomu opisu scenariuszy i zdań POD. Ogólnie, przekształcenie polega na zamianie ciągu zdań w języku POD w sekwencję komunikatów na diagramie sekwencji, co zilustrowano na rysunku 9. Na diagramie występują linie życia odpowiadające komponentom oraz interfejsom zawartym w modelu statycznym (por. rys. 8 i rys 9). Każde zdanie scenariusza tłumaczone jest na jeden lub dwa komunikaty między odpowiednimi warstwami systemu. Pełne sygnatury komunikatów tworzone są bezpośrednio na podstawie treści zdania. Zauważmy, że reguły tłumaczenia zdań PDO stanowią drugi element definicji semantyki akcji języka RSL. 7

M. Śmiałek 1. 2. 3. 4. 5. 6.

Klient : chce : zapisać się : na : ćwiczenia. System : sprawdza : dostępność : ćwiczeń. System : pokazuje : harmonogram. Klient : wybiera : termin : z : harmonogramu. System : pokazuje : okno podsumowania rezerwacji. System : zapisuje : klienta : na : ćwiczenia.

:Prezentacja

:UIOkna :IRezerwowanie :ICwiczenia

Klient

Rys. 9. Generacja diagramów sekwencji na podstawie scenariuszy

Ostatnim etapem (etap projektu szczegółowego pominiemy ze względu na brak miejsca) jest wygenerowanie kodu. Rysunek 10 przedstawia szkic klasy wygenerowanej jako implementacja jednego z interfejsów z rysunku 8. Jest tu również pokazany kod metody odpowiadającej logice aplikacji realizującej przypadek użycia Zapisanie się na ćwiczenia. Nie podajemy dokładnych reguł transformacji, jednakże porównanie z rysunkami 8 i 9 dowodzi, że możliwe jest jednoznaczne przekształcenie odpowiednich diagramów w kod. class RezerwowanieFactory implements IRezerwowanie { ICwiczenia icw; UIOkna iokna; HarmonogramDTO harm; void zapisanieSieNaCwiczenia() { harm = icw.sprawdzDostepnosc(); if (harm != null) { term = iokna.wybierzTermin(harm); iokna.pokazOknoPodsumowania(term); icw.zapiszKlienta(term) // ... itd.

Rys. 10. Kod jako rezultat ciągu transformacji (uproszczenie)

Aby wykonać automatycznie, przedstawione powyżej w sposób nieformalny reguły transformacji zapisano je w odpowiednim języku formalnym. Wybrano do tego celu język MOLA [4], który jako jeden z niewielu podobnych języków posiada pełną swoją implementację. Dokładną specyfikację wszystkich powyższych reguł zapisaną w języku MOLA można znaleźć w [5].

5. MECHAIZMY DLA POOWEGO WYKORZYSTAIA PRZYPADKÓW OPROGRAMOWAIA Zapisanie przypadków oprogramowania w sposób przedstawiony w poprzednich podrozdziałach umożliwia ich łatwe przeszukiwanie oraz znajdowanie elementów możliwych do ponownego wykorzystania. Dokładne przedstawienie zasad znajdowania podobieństw przekracza zakres tego rozdziału. Tutaj przedstawimy ogólne reguły służące do budowy odpowiedniego narzędzia wyszukującego. 8

Kompleksowy system ponownego wykorzystania …

Tak jak wspomniano w podrozdziale 2, znajdują tutaj zastosowanie ogólne reguły CBR (patrz [13]). Dla przypadków oprogramowania sprowadza się to do cyklu zilustrowanego na rysunku 11. W pierwszym kroku (1) porównujemy specyfikację wymagań (być może niekompletną) dla aktualnego przypadku oprogramowania ze specyfikacjami zgromadzonymi w bibliotece. Po znalezieniu podobieństw, reużywamy (2) znalezione elementy poprzednich przypadków. Następnie uzupełniamy brakujące elementy, wykorzystując techniki przedstawione wcześniej w tym rozdziale(3). Na koniec, gotowy przypadek oprogramowania zapisujemy do biblioteki (4). Można zauważyć, że przy takim podejściu zapisanie przypadku oprogramowania jest czynnością bardzo prostą i polegającą na zwykłym jego skopiowaniu. Reusable SW Reusable SWCase Case Reużywalny Prz. Opr. (w bibliotece)

Requirements Requirements Model Model Model wymagań

Model architekt.

«map»

Model projekt.

«map»

2. «re-użyj»

Kod

4. «zapisz»

Aktualny Prz. Opr (w przestrzeni roboczej) Model wymagań

Model architekt.

Model projekt.

3. «map»

«map»

3. «map»

Kod

3. «map»

1. «porównaj»

Rys. 11. Schemat działania „fabryki oprogramowania” opartej na przypadkach oprogramowania

Porównanie wymagań polega na znalezieniu podobieństw, przede wszystkim w dwóch obszarach: dziedzina zastosowania oraz funkcjonalność. Zostało to przedstawione na rysunku 12. Porównanie dziedzin polega na porównaniu występujących w scenariuszach przypadków użycia dopełnień. Odpowiadają one pojęciom w słowniku, sprowadzonym do wspólnej terminologii. Porównanie funkcjonalności polega na analizie podmiotów i orzeczeń. Ważna jest tutaj zarówno kolejność akcji, jak i znaczenie słów, ponownie sprowadzonych do wspólnej terminologii. Scenariusz 1. Podmiot Orzecz.

Dopełn.

2. Podmiot

Orzecz.

Dopełn.

3. Podmiot

Orzecz.

Dopełn.

porównanie dziedzin

porównanie funkcjonalności

Scenariusz 1. Podmiot Orzecz.

Dopełn.

2. Podmiot

Orzecz.

Dopełn.

3. Podmiot

Orzecz.

Dopełn.

Rys. 12. Ilustracja mechanizmów porównywania wymagań

Rys. 13. Ilustracja mechanizmów wskazywania różnic modeli

9

M. Śmiałek

Bazując na porównaniu scenariuszy przypadków użycia możemy skonstruować określoną metrykę podobieństwa, co zostało dokładnie omówione w [16]. Stanowi to podstawę do zobrazowania przypadku oprogramowania z punktu widzenia możliwych do ponownego wykorzystania elementów. Na rysunku 13 widzimy zestaw takich elementów dla przykładowego zapytania. Zaznaczone są elementy wymagań (przypadki użycia, pojęcia) podobne do tych znajdujących się w zapytaniu. Na tej podstawie zaznaczone są powiązane elementy rozwiązania (architektury, projektu, kodu), które można ponownie wykorzystać. Należy zauważyć, że zaznaczone elementy stanowią pewnego rodzaju przekrój (ang. slice) przez wyszukany przypadek oprogramowania. Ten przekrój można przenieść (skopiować) do aktualnej przestrzeni roboczej w celu dalszej obróbki.

6. PODSUMOWAIE Przedstawione w niniejszym rozdziale języki oraz metodyka wytwarzania oprogramowania konstytuują pewien paradygmat, który możemy nazwać „tworzeniem oprogramowania zorientowanym na przypadki” (ang. case oriented software development). Podstawowa idea wywodzi się ze znanej, ogólnej metody CBR. Dla tej metody został zdefiniowany sposób reprezentowania wiedzy w postaci przypadków oprogramowania. Wiedza ta została uporządkowana w ten sposób, aby umożliwić porównywanie przypadków na poziomie wymagań i wskazywanie powiązanych z nimi rozwiązań projektowych do ponownego użycia. Należy tutaj zaznaczyć, że zaprezentowaną metodykę można stosować w pewnym ograniczonym zakresie nawet używając standardowych narzędzi CASE. Może to stanowić istotną wskazówkę dla zespołów projektowych odnośnie dobrych praktyk w zakresie kształtowania tworzonych modeli. Aby jednak umożliwić pełny cykl CBR, konieczne jest stworzenie zintegrowanego narzędzia CASE. Narzędzie to obecnie jest testowane w ramach projektu ReDSeeDS1 (www.redseeds.eu). Powstał edytor języka RSL oraz narzędzie transformacji modeli. Narzędzia te zostały poddane ewaluacji przez kilka zespołów deweloperskich (patrz [6]). Wyniki tej ewaluacji wskazują na dobrą stosowalność zaprezentowanej metodyki w praktyce, przy zastosowaniu odpowiednich narzędzi. W następnym etapie prac planowane jest sprawdzenie efektywności różnych metod wyszukiwania i zaznaczania różnic w przypadkach oprogramowania.

______________ 1

Praca ta jest finansowana częściowo w ramach projektu ReDSeeDS finansowanego przez UE w ramach 6PR Badań Naukowych. Projekt jest nadzorowany naukowo przez Politechnikę Warszawską i biorą w nim udział Politechnika Wiedeńska, Uniwersytet Koblencja-Landau, Uniwersytet Łotewski, Uniwersytet w Hamburgu (HiTeC), Fraunhofer IESE, Uniwersytet Heriot-Watt oraz Infovide-Matrix, Algoritmu Sistemos, Cybersoft i ProDV Software.

10

Kompleksowy system ponownego wykorzystania … LITERATURA DO ROZDZIAŁU

[1] Agnar Aamodt, Enric Plaza: Case-based reasoning: Foundational issues, methodological variations, and system approaches. Artificial Intelligence Communications, Vol. 7, No 1, pp. 39–59, 1994. [2] C. Fellbaum (ed.): WordNet: An Electronic Lexical Database, MIT Press, 1998. [3] H. Kaindl, M. Śmiałek, D. Svetinovic, et al.: Requirements specification language definition. Project Deliverable D2.4.1, ReDSeeDS Project, www.redseeds.eu, 2007. [4] Audris Kalnins, Janis Barzdins, Edgars Celms: Model transformation language MOLA. Lecture Notes in Computer Science, Vol. 3599, pp. 14–28, 2004. [5] A. Kalnins, E. Kalnina, E. Celms et al.: Reusable case transformation rule specification, Project Deliverable D3.3, ReDSeeDS Project, www.redseeds.eu, 2007. [6] T. Krebs, W. Nowakowski, A. Kalnins et al.: Modelling and transformation language validation report, Project Deliverable D3.4, ReDSeeDS Project, www.redseeds.eu, 2007. [7] Maurizio Morisio, Michel Ezran, Colin Tully: Success and failure factors in software reuse. IEEE Transactions on Software Engineering, Vol. 28, No. 4, pp. 340–357, 2002. [8] Object Management Group: Unified Modeling Language: Superstructure, version 2.1.1, formal/0702-05, 2007. [9] Object Management Group: Systems Modeling Language (SysML) Specification, version 1.0, ptc/2006-05-03, 2006. [10]Michał Śmiałek: Accommodating informality with necessary precision in use case scenarios. Journal of Object Technology, Vol. 4, No 6, pp. 59–67, 2005. [11]M. Śmiałek, J. Bojarski, W. Nowakowski, A. Ambroziewicz, T. Straszak: Complementary use case scenario representations based on domain vocabularies. Lecture Notes in Computer Science, Vol. 4735, pp. 544–558, 2007. [12]Michał Śmiałek: Software Development with Reusable Requirements Based Cases, Oficyna Wydawnicza Politechniki Warszawskiej, 2007. [13]Carsten Tautz, Klaus-Dieter Althoff: Using case-based reasoning for reusing software knowledge. Lecture Notes in Computer Science, Vol. 1266, pp. 156–165, 1997. [14]Triskell project, http://www.irisa.fr/triskell/Softwares/protos/r2a/rdl, 2008. [15]Tropos project, http://www.troposproject.org/papers_files/tropos.pdf, 2008. [16]K. Wolter, T. Krebs, D. Bildhauer: Software case similarity measure, Project Deliverable D4.2, ReDSeeDS Project, www.redseeds.eu, 2007.

11