2007.07_Wykorzystanie przypadków użycia do modelowania zachowania_[Inzynieria Oprogramowania].pdf

Inżynieria

oprogramowania

Rafał Kasprzyk

Wykorzystanie przypadków użycia

do modelowania zachowania

tycznego pierwszym krokiem stanowiącym

podstawę dalszych działań jest próba zro-

zumienia strony klienta, co do zakresu funkcjonal-

ności, jaką ma oferować system. Klient ma pewne

wyobrażenie, co do sposobu funkcjonowania sys-

temu (ang. mental model ), a naszym zadaniem

jest zrozumienie, często niejasnych życzeń klienta.

W tym celu tworzony jest model wymagań (ang.

requirements model ). W zależności od wielkości

przedsięwzięcia, aby model taki zbudować, nie-

kiedy wystarczy krótka pogawędka, ale często ko-

nieczne jest wielomiesięczne studium wykonalno-

ści. Zawsze jednak dążymy do zrozumienia za-

chowania systemu wykorzystując przypadki użycia

i scenariusze przypadków użycia.

oczywistą, że nie warto o niej mówić, okazuje

się, że dla dużych systemów o wielu złożonych

i wzajemnie powiązanych funkcjach tego rodza-

ju podejście ma ogromny sens. Pozwala ono za-

pomnieć o detalach technicznych (nawet abs-

trahować od architektury) i skoncentrować się

na logice systemu. Podejście do projektowa-

nia od strony przypadków użycia jest uważane

za znacznie bardziej zdrowe od podejść „tech-

nokratycznych”, ponieważ sprzyja ono punktowi

widzenia, w którym centralnym ośrodkiem zain-

teresowania staje się człowiek – przyszły użyt-

kownik systemu. Jak pokazały doświadczenia

wielu projektów, jedną z głównych przyczyn ich

niepowodzeń było zbytnie skoncentrowanie się

projektantów na detalach technicznych, z pomi-

nięciem lub brakiem dostatecznej uwagi dla in-

terakcji użytkownik – system informatyczny.

Reasumując – przypadek użycia można deinio-

wać na wiele sposobów. Oto kilka przykładowych

deinicji:

Pochodzenie przypadków użycia

Przypadki użycia były w sposób intuicyjny sto-

sowane w tradycyjnym projektowaniu systemów

informatycznych na długo przed pojawieniem

się metodyk obiektowych i języka UML. Zasłu-

gą Ivar’a Jacobsona jest zarówno wyodrębnie-

nie przypadków użycia, jak i stworzenie meto-

dyki i notacji graficznej dla tego paradygmatu.

Jak często bywa z powszechnie stosowanymi,

lecz nie nazwanymi rzeczami, kariera przypad-

ków użycia w literaturze z zakresu projektowa-

nia systemów informatycznych zaczęła się od

wprowadzenia dla nich specjalnej nazwy, przy-

pisaniu tej nazwie określonej semantyki i roz-

propagowaniu tego pojęcia jako sposobu mode-

lowania zachowania.

• Przypadek użycia to wycinek funkcjonalności,

którą system musi realizować, aby spełnić wyma-

gania;

• Przypadek użycia jest zbiorem ciągów akcji

wykonywanych przez system w celu dostar-

czenia określonemu aktorowi godnego uwagi

wyniku;

• Przypadek użycia to zbiór scenariuszy powiąza-

nych wspólnym celem użytkownika. Przez sce-

nariusz rozumiany jest tu ciąg kroków opisują-

cych interakcje między użytkownikiem a syste-

mem.

Semantyka przypadków użycia

Przypadek użycia jest to pewna nazwana, do-

brze określona interakcja pomiędzy użytkowni-

kiem a systemem komputerowym. Przypadek

użycia odwzorowuje pewną funkcjonalność sys-

temu w taki sposób, w jaki będą ją widzieć jego

przyszli użytkownicy. Jakkolwiek w tym stwier-

dzeniu można podejrzewać banał, rzecz tak

Diagramy przypadków użycia są bardzo proste i głów-

nie dzięki temu tak użyteczne. Pomiędzy przypad-

kami użycia można wyróżnić trzy podstawowe za-

leżności.

Zawieranie

• Pozwala na współdzielenie fragmentu funkcjonal-

ności pomiędzy kilkoma przypadkami użycia. Do

relacji zawierania dochodzi wówczas, gdy kilka

przypadków użycia ma wspólną sekwencję po-

dobnych kroków, której nie warto wciąż kopiować

z jednego przypadku użycia do drugiego.

Autor jest absolwentem Wydziału Cybernetyki WAT,

gdzie od 2 lat zajmuje stanowisko asystenta w Instytu-

cie Systemów Informatycznych. Pracuje w irmie ISO-

LUTION będąc odpowiedzialnym za przygotowywa-

nie, prowadzenie i audyt szkoleń obejmujących analizę

i projektowanie systemów informatycznych z użyciem

notacji UML.

Kontakt z autorem: rafal.kasprzyk@wat.edu.pl

Rozszerzanie

• Pozwala na warunkowe rozszerzenie funkcjo-

nalności przypadku użycia „osadzone” w punk-

cie rozszerzenia. Rozszerzenie przypadku użycia

www.sdjournal.org Software Developer’s Journal 07/2007

R ozpoczynając budowę systemu informa-

Wykorzystanie przypadków użycia do modelowania zachowania

Bibliograia

• [1] Marin Fowler UML Distilled: A Brief Guide To The Standard

Object Modeling Language , 3rd ed., Addison-Weslay Professio-

nal, 2004;

• [2] Grady Booch, James Rumbaugh, Ivar Jacobson, Uniied

Modeling Language User Guide , 2nd ed., Addison-Weslay

Professional, 2005;

• [3] Michał Śmiałek, Zrozumieć UML 2.0. Metody modelowania

obiektowego , Helion, 2005;

• [4] http://www.holub.com/goodies/uml/;

• [5] http://www.agilemodeling.com/essays/umlDiagrams.htm

Rysunek 2 . Strona główna holub.com

może więc wzbogacić go o dodatkowe zachowanie, ale

w takiej sytuacji podstawowy przypadek użycia musi okre-

ślić pewne punkty rozszerzenia, a rozszerzający przypa-

dek użycia może dodać nowe zachowanie tylko w tych

punktach. Przypadek użycia może mieć wiele punktów

rozszerzeń, a rozszerzający przypadek użycia może roz-

szerzać podstawowy przypadek użycia w kilku z tych

punktów. Relacja rozszerzania służy do opisywania opcjo-

nalnego przepływu zdarzeń i pozwala na minimalizację

liczby zmian wprowadzanych do podstawowego przypad-

ku użycia.

Do czego wykorzystywane są przypadki użycia

Podejście przypadków użycia ma przede wszystkim na wzglę-

dzie określenie wymagań funkcjonalnych na projektowany

system.

Celem tej metody jest

• Identyikacja wymagań funkcjonalnych;

• Każdy przypadek użycia powinien opisywać realizację

jakiegoś celu biznesowego opisanego z punktu widze-

nia aktora używającego system;

• Zbiór przypadków użycia stanowi podstawę do umowy

między klientem, a dostawcą;

• Przypadki użycia ułatwiają zadanie ustalenia prioryte-

tów dla wymagań funkcjonalnych;

• Odpowiedź na pytanie, co system ma robić bez określania

sposobu realizacji;

• Umożliwienie interakcji zespołu projektowego z użytkowni-

kami systemu;

• Określenie granic systemu;

• Ustalenie praw dostępu do zasobów;

• Ustalenie składowych systemu i związanego z nimi planu

konstrukcji systemu;

• Przygotowanie podstaw do szczegółowej analizy i projek-

towania:

• Podstawa do identyikacji klas i obiektów;

• Określenie odpowiedzialności i współpracy obiektów;

• Deinicja przepływu komunikatów miedzy obiektami;

• Weryikacja poprawności i kompletności projektu;

• Dostarczenie podstaw do sporządzenia planu testów

systemu.

Uogólnienie

• Pozwala na zilustrowanie różnych wariantów realizacji te-

go samego przypadku użycia. W istocie jest bardzo po-

dobne do rozszerzania, jest jednak mniej formalne. Re-

lacji uogólnienia używa się wówczas, gdy dany przypa-

dek użycia jest podobny do innego, ale jest nieco obszer-

niejszy. Specjalizowany przypadek użycia może przesło-

nić dowolną część podstawowego przypadku użycia, ale

zawsze powinien dotyczyć osiągnięcia tego samego celu

użytkownika, co podstawowy przypadek użycia. Relacja

uogólniania może być traktowana jako sposób na przed-

stawienie szczególnej realizacji uogólnionego przypadku

użycia.

��

Podsumowanie

Przypadki użycia stały się podstawowym elementem współ-

czesnych metodyk wytwarzania oprogramowania. Mówi się,

że dobra metodyka winna być ukierunkowana właśnie na

przypadki użycia. Oznacza to, że przypadki użycia powinny

stanowić podstawowe narzędzie do zbierania i odkrywania

wymagań funkcjonalnych systemu (określanie pożądanego

zachowania systemu), planowania prac w projekcie (podsta-

wowe i stanowiące ryzyko przypadki użycia implementowa-

ne są w pierwszej kolejności), zarządzania projektem oraz do

testowania systemu. Przypadki użycia są niezbędne przy wy-

borze architektury i jej weryikacji. Wykorzystuje się je rów-

nież do komunikacji wewnątrz zespołu projektowego pracują-

cego nad projektem, jak i przy rozmowie z klientem. n

��

Rysunek 1 . Diagram przypadków użycia

Software Developer’s Journal 07/2007

www.sdjournal.org

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: