metoda oceny efektywności oprogramowania na etapie jego

XII International PhD Workshop
OWD 2010, 23–26 October 2010
METODA OCENY EFEKTYWNOŚCI OPROGRAMOWANIA
NA ETAPIE JEGO PROJEKTOWANIA
PERFORMANCE EVALUATION OF SOFTWARE
DURING DESIGN STAGE
Arkadiusz Wrzosk, Wojskowa Akademia Techniczna
Abstract
Software performance estimation should be
applied on early stages. Correction of errors in
software architecture detected too late can be very
expensive. This paper describes an approach based
on simulation to performance prediction of software
system.
Performance is estimated during design stage
when software architecture is specified by UML.
UML is an industry standard used as a common OO
modeling language. Process-oriented simulation
model is derived from annotated diagrams: Use
Case, Sequence, Activity and Deployment.
UML diagrams are annotated using standard
UML extensions mechanisms aggregated in
performance profile. This profile allows designer to
include quantitative information, which are used to
build a simulation program.
Performance evaluation process can be
automated. This paper describes created IBM
Software Architect extensions used to automate
transformations and run simulation. UML profile,
diagrams transformation, and standard plugin
extension mechanism were used. Results are
reported using Business Intelligence and Reporting
Tools (BIRT).
This paper describes steps required to evaluate
performance using proposed approach. This steps
are defined in the context of Rational Unified
Process. Performance analysis is a role responsible
for performance evaluation.
Streszczenie
W pracy zaprezentowano metodę badania
efektywności oprogramowania na wczesnym etapie
jego wytwarzania, jakim jest projektowanie.
Zaproponowano
podejście
umożliwiające
przeprowadzenie badań z wykorzystaniem symulacji
komputerowej. W ramach pracy opisane zostało
narzędzie, pozwalające na przeprowadzenie badań
i stanowiące część platformy IBM Rational Software
Architect.
1. Wprowadzenie
Wczesna
ocena
poprawności
wymagań
funkcjonalnych i niefunkcjonalnych jest ważnym
aspektem procesu wytwarzania oprogramowania.
Szczególne
znaczenie
mają
wymagania
niefunkcjonalne takie, jak efektywność czy
niezawodność. Poprawienie późno wykrytych
błędów w projekcie architektury może być
kosztowne. Dlatego ocena parametrów systemu
powinna być wykonywana możliwie najwcześniej.
W niniejszej pracy opisano metodę oceny
architektury na etapie projektowania.
Językiem wybranym do zapisu architektury jest
Unified Modeling Language (skrót UML). Jest on
językiem
znormalizowanym,
służącym
do
dokumentowania projektu architektury. Może być
stosowany do obrazowania, specyfikowania,
tworzenia i dokumentowania artefaktów powstałych
podczas procesu budowy systemu informatycznego.
Jest on powszechnie akceptowanym i stosowany
w środowisku inżynierów. UML dostarcza
wygodnych
mechanizmów,
umożliwiających
rozszerzenie jego semantyki. Zbiór rozszerzeń może
być agregowany w tzw. profilu.
W oparciu o [1] i [4] zaproponowano profil, który
jest zbiorem stereotypów i notek umożliwiających
uzupełnienie projektu architektury o informacje
wymagane do przeprowadzenia badań.
Jako technikę oceny projektu architektury
zapisanego w języku UML wybrano symulację
dyskretno - zdarzeniową. Nie wymaga ona budowy
prototypu i pozwala na przeprowadzenie badań na
etapie
projektowania..
Symulacja
umożliwia
wyznaczenie ilościowych charakterystyk pracy oraz
badanie
wpływu
zmiany
parametrów
na
charakterystyki systemu, co w przypadku badań
architektury pozwala na ocenę i porównanie różnych
decyzji podjętych na etapie projektowania.
W oparciu o [1] opracowano kroki transformacji
modelu
architektury
oprogramowania
61
zgłoszenia pojawiają się co losowy czas. Aby
zdefiniować strumień zamknięty aktorowi należy
nadać stereotyp <<OpenWorkload>>. Rozkład czasu
pomiędzy kolejnymi zgłoszeniami definiujemy
z wykorzystaniem atrybutu occurence. Przypadki użycia
(skrót PU) reprezentują zbiór scenariuszy, które są
symulowane po nadejściu zgłoszenia. Dodatkowo do
asocjacji aktora z PU dodano informację o liczbie
wykonań PU (atrybut executions stereotypu
<<Transition>>),
co
umożliwia
szacowanie
prawdopodobieństwa jego uruchomienia.
*
*
udokumentowanej z wykorzystaniem języka UML do
modelu symulacyjnego. Zaproponowano następujące
diagramy UML opisujące architekturę wymagane do
jej oceny: przypadków użycia, sekwencji, aktywności,
komponentów i wdrożenia.
W ramach pracy powstała lista rozszerzeń
środowiska Rational Software Architekt wspierająca
proces oceny architektury oprogramowania.
Opisana w pracy metoda ma zastosowanie
w przypadku badań własności oprogramowania
modelowanego
z
wykorzystaniem
metod
obiektowych. Została ona opisana w kontekście
metodyki RUP i powinna stanowić kroki dyscypliny
analizy i projektowania.
*
2. Transformacja projektu
architektury do modelu
symulacyjnego
Niestety w obecnej chwili nie istnieje język
umożliwiający modelowanie dowolnej dziedziny
systemu. Dlatego twórcy języka UML zapewnili
możliwość kontrolowanego rozszerzania jego
notacji. W celu modelowania dziedziny badania
efektywności systemów zdefiniowany został profil
UML. Umożliwia on dodanie do diagramów
informacji niezbędnych do przeprowadzenia badań
z wykorzystaniem symulacji. Na poniższym rysunku
przedstawiono, na jakie elementy modelu
symulacyjnego będą transformowane poszczególne
diagramy.
Diagramy UML
Model symulacyjny
Przypadków użycia
Obciążenie
Wdrożenia
Zasoby
Komponentów
Komponenty
Aktywności
Akcje
Stereotypy
Parametry
Rys. 1. Mapowanie elementów UML na model
symulacyjny
Fig. 1. UML diagrams to simulation model mapping
2.1 Adnotacje UML
Obciążenie
systemu
modelowane
jest
z wykorzystaniem diagramów przypadków użycia.
Aktorzy reprezentują strumień napływających do
systemu zgłoszeń. W pracy zdefiniowano dwa typy
strumieni.
Skończony
strumień
zgłoszeń
i nieskończony strumień zgłoszeń. W skończonym
strumieniu zgłoszeń, każde zgłoszenie po
zakończeniu scenariusza, zanim ponownie uruchomi
kolejny, spędza określony czas poza systemem.
Skończony strumień zgłoszeń definiujemy nadając
aktorowi stereotyp <<ClosedWorkload>>. Wielkość
populacji definiowana jest atrybutem population,
natomiast rozkład czasu spędzonego poza systemem
przez atrybut extDelay. W nieskończonym strumieniu
Rys. 2. Diagram przypadków użycia z adnotacjami
Fig.2. Annotated Use Case diagram
Diagramami,
które
zawierają
informacje
o
scenariuszach,
są
diagramy
interakcji.
W proponowanym podejściu wykorzystane zostały
diagramy sekwencji. W prawdzie służą one do
pozyskiwania informacji o klasach, ich metodach
i powiązaniach między nimi, ale zawierają również
informacje o kolejnych krokach scenariusza PU. Do
problemu uzupełnienia diagramów o informacje
wymagane do przeprowadzenia badań, możemy
podejść w dwojaki sposób. Możemy wkomponować
informacje w diagramy sekwencji, bądź utworzyć na
podstawie
diagramów
sekwencji,
diagramy
aktywności i dopiero na nie nanieść potrzebne
adnotacje. Ze względu na to, że stereotypy wnoszą
na diagram informacje dodatkowe, wybrano
podejście drugie, tj. generacja diagramów aktywności
na podstawie diagramów sekwencji. Dzięki temu,
użytkownik dokumentacji nie będzie miał
problemów z jej czytelnością.
Aktywności na utworzonych diagramach
reprezentują żądanie dostępu do zasobu.
Podstawowym typem aktywności jest akcja prosta,
reprezentująca krok obliczeniowy i związana
z żądaniem wykorzystania zasobu aktywnego. W celu
zdefiniowania takiej akcji do aktywności należy
dodać stereotyp <<SimpleAction>>. Podstawowym
atrybutem tej akcji jest atrybut demand, który definiuje
czas żądania dostępu do zasobu aktywnego.
Dodatkowo może ona przeprowadzić dowolne
obliczenia zanim zażąda dostępu do zasobów
(atrybut delay) oraz może być wykonana wielokrotnie,
w określonych odstępach czasu (atrybuty: repetitions,
interval). Kolejnym typem akcji jest akcja informująca
o zakończeniu wywołania akcji prostej, która jest
z nią powiązana (stereotyp <<CommStep>>).
Ostatnimi typami akcji są akcje związane z alokacją
i zwalnianiem zasobów pasywnych. Definiujemy je
62
z wykorzystaniem stereotypów: <<AcquireAction>>
oraz <<ReleaseAction>>. Podstawowym atrybutem
tych akcji jest atrybut quantity, który w zależności od
typu akcji, reprezentuje liczbę tokenów zasobu do
zaalokowania
lub
zwolnienia.
Specjalnymi
stereotypami są: <<ForkAction>>, <<JoinAction>>.
Służą one do modelowania współbieżnego
wykonania akacji i są nanoszone na diagramach
sekwencji. Ma to ułatwić automatyczne tworzenie
współbieżnych ciągów akcji na diagramach
aktywności. Podczas transformacji komunikatów
z diagramu sekwencji zachowywana jest informacja
o klasie implementującej metodę. Będzie ona
wykorzystywana na etapie automatycznego wiązania
zasobów z akcjami.
o1:Klasa1
o2:Klasa2
<<SimpleAction>>
Komunikat 1
Komunikat 1
<<CommStep>>
Komunikat 1
Komunikat 2
<<SimpleAction>>
Komunikat 2
<<CommStep>>
Komunikat 2
Rys. 4. Diagram wdrożenia z adnotacjami
Fig. 4. Annotated deployment diagram
Na diagramach wdrożenia należy dodatkowo
nanieść informacje o komponentach, które są na
nich uruchomione.
Dodatkowym
diagramem,
który
jest
wykorzystywany w proponowanym podejściu jest
diagram komponentów. Powinien on zawierać
informacje o klasach implementujących dany
komponent
oprogramowania.
Asocjacja
komponentu z pakietami lub klasami wspomaga
jednoznaczną identyfikację powiązania akcji
z komponentem (na podstawie sygnatury metody
przypisanej do akcji).
Mając na diagramie aktywności informacje
o
klasie
implementującej
metodę,
której
reprezentacją jest dana akcja, komponencie, który
jest implementowany z wykorzystaniem tej klasy
i węźle, na którym uruchomiony jest wybrany
komponent możemy automatycznie uzyskać
informację o zasobie, na którym uruchomiona jest
akcja. Jest to istotne, ponieważ przy dużych
systemach nanoszenie na diagramy aktywności
informacji o zasobie, na którym jest uruchomiona
definiowana akcja, może być bardzo czasochłonne.
2.2 Transformacja modeli
Rys. 3. Diagramy sekwencji i aktywności z adnotacjami
Fig. 3. Annotated sequence and activity diagram
Zasoby modelowane są z wykorzystaniem
diagramów wdrożenia. Rozróżniamy dwa rodzaje
zasobów: aktywne i pasywne. Zasoby aktywne
definiujemy
z
wykorzystaniem
stereotypu
<<ActiveResource>>.
Reprezentują
one
wieloprocesorowe maszyny obsługujące zgłoszenia.
Założono, że wszystkie procesory są jednakowe
i charakteryzują się taką samą mocą obliczeniową.
Liczbę procesorów definiujemy z wykorzystaniem
atrybutu procNum, natomiast częstotliwość pracy
zegara, z wykorzystaniem atrybutu rate. Zasoby
pasywne definiujemy z wykorzystaniem stereotypu
<<PassiveResource>>. Reprezentują one zasoby, które
są alokowane. Dostępna jest skończona ilość danego
zasobu (określona przez liczbę tokenów). Liczbę
dostępnych tokenów definiujemy z wykorzystaniem
atrybutu capacity, natomiast czas potrzebny na zajęcie
zasobu, definiowany jest atrybutem accessTime.
Zwalnianie zasobu nie powoduje upływu czasu.
Każdy zasób obsługuje akcje zgodnie z określonym
algorytmem. W przypadku zasobu pasywnego
zaimplementowano algorytmy: LIFO i FIFO.
W
przypadku
zasobów
aktywnych
zaimplementowano dodatkowo algorytm Time
Sparing (atrybut schedPolicy).
Ogólny algorytm transformacji modelu systemu
zapisanego w języku UML na model symulacyjny jest
następujący:
- każdy aktor tłumaczony jest na obciążenie
systemu,
- każda akcja na diagramie aktywności
tłumaczona jest na krok symulacji,
- węzły na diagramach aktywności mapowane są
na zasoby,
- komponenty transformowane są na obiekty
komponentów w modelu symulacyjnym.
Diagramy przypadków użycia służą do uzyskania
informacji o obciążeniu. W zależności od stereotypu
przypisanego do aktora tworzona jest instancja klasy
reprezentującej
strumień
skończony
lub
nieskończony. Z każdym aktorem powiązana jest
pewna liczba przypadków użycia. Każdy z nich
agreguje zbiór scenariuszy, które zobrazowane są na
diagramie aktywności. Dla każdego przypadku użycia
tworzona jest akcja złożona.
Dla każdej akcji z diagramu aktywności, bazując
na jej stereotypie, tworzona jest instancja klasy,
odpowiadająca krokowi symulacji. Akcje wiązane są
następnie w relacji poprzednik – następnik.
Na podstawie zawartości diagramów wdrożenia
tworzone są instancje zasobów aktywnych
i pasywnych, na których działają akcje.
63
Na podstawie
tworzone
są
oprogramowania.
diagramów
instancje
komponentów
komponentów
3. Metoda badania własności
oprogramowania
wartość analityczną. Artefakty stanowią dane
wejściowe i wyjściowe czynności. Poza tym
określona jest również rola za nie odpowiedzialna.
W poniższej tabeli przedstawiono powiązania
opisywanego artefaktu.
Tab. 1.
Powiązania raportu o wydajn ości systemu
Opracowana metoda ma zastosowanie tylko
Software a rchitect ure per for mance repor t associations
w przypadku badań wydajności architektury na etapie
Odpowiedzialna:
Modyfikuje:
projektowania, modelowanej z wykorzystaniem Role
analityk
wydajności
analityk wydajności
metod obiektowych. Powinna zostać umiejscowiona
w dyscyplinie analizy i projektowania procesu, jakim
Zadania Wejście dla:
Wyjście z:
jest Rational Unified Process (RUP). Konkretna
udoskonalenie
ocena wydajności
konfiguracja zależy od specyfiki organizacji
architektury
architektury
i projektu.
3.2. Kroki metody badania oprogramowania
3.1 Charakterystyka podstawowych
elementów metody
Opracowana metoda stanowi fragment metodyki
RUP. Omówiona jest w kontekście ról, artefaktów
i czynności. Kolejne punkty zawierają szczegółowy
opis tych elementów.
W celu przeprowadzenia badań oprogramowania
należy wyznaczyć rolę, odpowiedzialną za ich
wykonanie. Utworzona rola to: analityk wydajności.
Jest
ona
odpowiedzialna
za
koordynacje
i przeprowadzenie badań wydajnościowych. Każda
rola związana jest ze zbiorem artefaktów oraz
kroków, za których wykonanie jest odpowiedzialna.
Na poniższym rysunku przedstawiono powiązania
roli analityka wydajności.
Rys. 5. Powiązania roli analityka wydajności
Fig. 5. Performance analyst associations
Osoba w roli analityka odpowiedzialna jest za
poprawne
przeprowadzenie
następujących
czynności:
- wzbogacenie diagramów UML o informacje
wymagane do przeprowadzenie badań,
- przeprowadzenie badań,
- przeprowadzenie analizy uzyskanych wyników,
- poinformowanie o stanie architektury
wszystkich ról za nią odpowiedzialnych.
Osoba pełniąca rolę analityka powinna posiadać
wiedzę na temat języka UML oraz zagadnień
związanych z badaniem wydajności.
Do artefaktów powstałych w trakcie prowadzenia
oceny
wydajności
należy
raport
o wydajności systemu, zawierający wyniki badań.
Celem utworzenia tego artefaktu jest prezentacja
wyników badania systemu w postaci posiadającej
Czynność oceny wydajności wiąże się z realizacją
pewnych kroków, w konsekwencji których powstaje
raport o wydajności. Omówiono je kolejno
w punktach poniżej.
1. Określenie celów badania.
Cel: Określenie elementów architektury, które
będą badane ze szczególną uwagą.
Na tym etapie należy określić główne cele
badania oraz ewentualnie zmodyfikować projekt
systemu, w celu poprawnego przeprowadzenia badań
w ich kontekście.
2. Uzupełnienie modelu przypadków użycia.
Cel: Definiowanie parametrów obciążenia.
Jednym z podstawowych elementów związanych
z badaniami wydajności jest obciążenie systemu. Dla
każdego aktora należy zdefiniować typ strumienia
generowanych
zgłoszeń.
Typ
strumienia
identyfikujemy w następujący sposób:
- jeśli liczba użytkowników systemu jest
ograniczona, to modelujemy to za pomocą
strumienia zamkniętego,
- w przeciwnym wypadku będzie to strumień
otwarty.
Każdy aktor związany jest z uruchamianymi
przypadkami użycia. Przypadki użycia opisują
dostarczane usługi i agregują scenariusze interakcji
użytkownika z systemem. Należy określić to, ile razy
podczas współpracy użytkownika z systemem
wykonywany jest określony przypadek użycia.
3. Utworzenie perspektywy wydajnościowej.
Cel: Utworzenie modelu wydajnościowego
zawierającego scenariusze działania systemu.
Jedną z danych wejściowych wymaganych do
przeprowadzenia badań oprogramowania są
scenariusze interakcji użytkownika z systemem.
Modelują one zachowanie systemu podczas
działania. Należy utworzyć model opisujący
scenariusze działania systemu, na którym zostaną
naniesione
informacje,
wymagane
do
przeprowadzenia
badań.
Należy
pamiętać
o poprawnym modelowaniu współbieżności
i punktów decyzyjnych.
64
4. Uzupełnienie diagramów aktywności
Cel: Określenie obciążenia generowanego przez
poszczególne akcje.
Każda akcja wykonywanego scenariusza wiąże się
z wykorzystaniem do jej realizacji pewnych zasobów.
Należy określić obciążenie, jakie akcja generuje.
5. Uzupełnienie modelu wdrożenia.
Cel: Definiowanie typu zasobów.
W ramach badań wydajnościowych wyróżniane są
różne typy zasobów. W tym kroku należy
zdefiniować i sparametryzować zasoby aktywne
i pasywne. Identyfikacji typu zasobu można dokonać
w następujący sposób:
- zasób aktywny - maszyna wieloprocesorowa
udostępniająca usługi obliczeniowe,
- zasób pasywny - część systemu, którego ilość
jest ograniczona np. pula połączeń do bazy danych.
Po identyfikacji typu zasobu należy zdefiniować
parametry opisujące dany typ.
6. Dobór metryk.
Cel: Wybór metryk umożliwiających porównanie
różnych rozwiązań architektonicznych.
Należy dobrać metryki tak, aby możliwe było
porównanie różnych rozwiązań architektonicznych
z różnych badań.
7. Przeprowadzenie badań.
Cel:
Przygotowanie
danych
do
oceny
architektury.
Podstawą do oceny wydajności architektury są
wyniki
przeprowadzonych
badań.
Danymi
wejściowymi do analizy są następujące elementy:
- model przypadków użycia, przedstawiający
obciążenie systemu i usługi dostarczone przez
system,
- model wdrożenia, przedstawiający zasoby
udostępnione przez system,
- scenariusze działania systemu z perspektywy
wydajnościowej,
model
przedstawiający
komponenty,
pozwalający na powiązanie zasobów z akcjami na
nich wykonywanymi.
Na podstawie powyższych danych powinny
zostać przeprowadzone badania wydajnościowe.
Wyniki tych badań powinny zostać zarchiwizowane
i przygotowane do dalszej analizy. Na podstawie
uzyskanych wyników powinien zostać stworzony
raport,
przedstawiający
obraz
wydajności
architektury.
8. Analiza wyników symulacji.
Cel: Ocena wydajności architektury.
Wyniki uzyskane podczas przeprowadzonych
badań powinny zostać przeanalizowane. Na ich
podstawie powinna zostać przygotowana lista
ewentualnych uwag dotyczących wydajności
architektury. O wszelkich problemach związanych
z wydajnością powinny zostać poinformowane
wszystkie osoby odpowiedzialne za architekturę
systemu.
3.3. Listy kontrolne
W ramach metodyki RUP udostępniono
mechanizm list kontrolnych, umożliwiających
weryfikację poprawności wykonanej czynności.
Poniżej przedstawiono listę kontrolną dla czynności
oceny wydajności architektury. Zawiera ona
następujące punkty:
- dla każdego aktora został określony typ
strumienia,
- dla każdego przypadku użycia określono liczbę
jego wykonań,
- dla każdego przypadku użycia zdefiniowano
jego realizacje,
- na diagramach obrazujących realizacje
przypadku użycia zaznaczono punkty rozwidleń
i scaleń,
- komponenty powiązane są z artefaktem
opisującym zasób, na którym jest on uruchomiony,
- komponenty powiązane są z pakietami i klasami,
które je implementują,
- określono typ każdego zasobu,
- każda akcja modelu wydajnościowego zawiera
informacje o generowanym obciążeniu zasobów.
4. Rozszerzenie środowiska Rational
Software Architect (RSA)
Opisana w punkcie 3 metoda jest wspierane przez
zbiór rozszerzeń środowiska RSA. W celu
umożliwienia przeprowadzenia badań na podstawie
diagramów opisujących architekturę, rozszerzenie
środowiska
powinno
umożliwić
stworzenie
i uruchomienie modelu symulacyjnego badanego
oprogramowania. Na rysunku został przedstawiony
proces, jaki musi zostać zrealizowany, aby osiągnąć
wyżej postawiony cel. Zaznaczono również na nim
wykorzystane metody rozszerzenia platformy RSA.
Rys. 6. Rozszerzenie platformy IBM Rational Software
Architekt
Fig. 6. IBM Rational Software Architect extensions
W
celu
implementacji
oprogramowania
umożliwiającego
przeprowadzenie
badań
skorzystano
z
następujących
mechanizmów
rozszerzeń środowiska RSA: profilu UML,
transformacji, wtyczek.
Profil UML został stworzony w celu
modelowania dziedziny problemowej badań
systemów z wykorzystaniem symulacji. W punkcie
65
2.1 zostały omówione podstawowe elementy tego
profilu.
Mechanizm transformacji wykorzystany został
w dwóch przypadkach. Pierwszy z nich rozwiązuje
problem scenariuszy działania oprogramowania.
W opisywanym podejściu należy dokonać
transformacji diagramów sekwencji na diagramy
aktywności. Zastosowanie ma tutaj mechanizm
transformacji jednego modelu do drugiego. Drugim
punktem, w którym zostały wykorzystane
transformacje, jest konwersja modelu stworzonego w
UML na model symulacyjny. Generowany jest plik
interpretowany później przez oprogramowanie
implementujące program symulacyjny.
Ostatnim mechanizmem rozszerzenia, jaki został
wykorzystany,
jest
standardowa
wtyczka,
umożliwiający uruchomienie symulacji i archiwizację
wyników.
Podstawową
jej
częścią
jest
zaimplementowana
biblioteka,
umożliwiająca
uruchomienie symulacji. Nazwano ją UMLSimKit.
Do jej implementacji wykorzystana została biblioteka
do symulacji zorientowanej procesowo o nazwie
DESKit.
Wyniki prezentowane są z wykorzystaniem
systemu raportowego o nazwie Business Intelligence
and Reporting Tools (BIRT) dostarczony wraz
z platformą IBM.
Rozszerzenie środowiska dostarczone jest jako
zbiór wtyczek, realizujących wyżej opisaną
funkcjonalność.
Conclusion
This paper describes approach for performance
evaluation of a system on early developing process
stages. UML as an OO modeling language was used.
Performance evaluation process is supported by
Rational Software Architect extensions.
Future research should focus on other diagrams
and their possible use for performance evaluation.
State diagrams are especially interesting. Other
problem which should be considered is reliability of
passive and active resources. This is an important
issue in high availability systems.
Provided RSA extensions should be furtherly
developed. They should support a designer in
making decision about changes on an architectural
level.
Literatura
1. M. Marzolla, Simulation-Based Performance Modeling
of UML Software Architectures, Universita
Ca'Foscari, Wenecja 2004
2. P. Kruchten, Rational Unified Process od strony
teoretycznej, WNT, Warszawa 2000
3. G. Booch, J. Rumbaugh, I.Jacobson, UML
przewodnik użytkownika, WNT, Warszawa 2000
4. Object Management Group (OMB), UML profile
for schedulability, performance and time specification,
OMG Adopted Specification ptc/07-08-04,
OMG 2007
Adres służbowy autora:
5. Wnioski
W pracy przedstawiono metodę oceny
architektury oprogramowania oraz narzędzie
wspierające ten proces. Jako język modelowania
wykorzystano UML oraz dostarczone wraz
z nim mechanizmy rozszerzenia jego semantyki.
Wybór symulacji jako techniki oceny, pozwolił
odzwierciedlić działanie systemu na wybranym
poziomie. Proces oceny architektury wspierany jest
przez zaimplementowany zestaw wtyczek do
środowiska Rational Software Architect. Wyniki
badań są archiwizowane i mogą być prezentowane
w
zrozumiałej
formie
zainteresowanym
użytkownikom.
Elementem do dalszej analizy jest włączenie do
badań kolejnych diagramów. Szczególną uwagę
należałoby zwrócić na diagramy stanów, które
modelują zachowanie obiektu i jego reakcje na
zdarzenia. Dodatkowym zagadnieniem, które
należałoby włączyć do analizy, jest niezawodność
zasobów aktywnych i pasywnych. Może mieć to
szczególne znaczenie w systemach, w których
wymaga się dużej dostępności. Należałoby również
zaimplementować
mechanizm,
wspierający
podejmowanie decyzji o zmianach w architekturze.
66
mgr inż. Arkadiusz Wrzosk
Wojskowa Akademia Techniczna
ul. gen. Sylwestra Kaliskiego 2
00-908 Warszawa 49
tel. 600 263 093
email: [email protected]