Tomasz Szmuc '05

1

Przypadki użycia

Przypadki użycia

(

(

use cases

use cases

)

)

Tomasz Szmuc '05

2

Podstawowe pojęcia

Podstawowe pojęcia

Aktor – spójny zbiór ról odgrywanych przez

użytkowników przypadku użycia w czasie interakcji z tym

przypadkiem użycia.

Aktorzy mogą występować w wielu modelach, nie należą jednak do

systemu, lecz stanowią elementy otoczenia.

Rys. Przykład aktora

AnalitykKredytowy

Tomasz Szmuc '05

3

Przypadek użycia (use case) – opis zbiorów ciągów akcji (i ich

wariantów) wykonywanych przez system w celu dostarczenia

określonemu aktorowi godnego uwagi wyniku.

Nazwy są w zasadzie dowolnym tekstem (bez dwukropka), najczęściej

jest to krótkie wyrażenie z czasownikiem w trybie rozkazującym na

początku. Czasownik ten określa czynność ze słownika modelowanego

systemu.

Przyznaj kredyt

Sensors:: Reset

Rys. Nazwa prosta i ścieżkowa w przypadkach użycia

Tomasz Szmuc '05

4

Między aktorami a przypadkami użycia mogą być związki typu

powiązania.

Oznacza to, że aktor i przypadek użycia porozumiewają się ze sobą

wysyłając i odbierając komunikaty.

Przypadek użycia opisuje co system (podsystem, klasa, operacja)

realizuje, nie określa natomiast jak to robi.

Ciąg zdarzeń przypadku użycia może być określony tekstowo

(nieformalny tekst z ogranicznikami początku i końca), lub, zazwyczaj

w kolejnym kroku, przez diagramy interakcji.

Tomasz Szmuc '05

5

Przypadek użycia może być zapisany w formie (strukturyzowanego)

tekstu .

Przykład przypadku

WeryfikujUzytkownika

.

Główny ciąg zdarzeń.

1.

Pytanie klienta o PIN.

2.

Klient wprowadza PIN.

3.

Klient potwierdza wprowadzony PIN (Enter).

4.

System sprawdza poprawność PIN-u.

5.

Jeśli PIN jest poprawny – system informuje o tym klienta.

Tomasz Szmuc '05

6

Nadzwyczajny ciąg zdarzeń 1.

Klient może w każdym momencie nacisnąć przycisk Cancel.

Przypadek użycia wraca wówczas do stanu początkowego.

Nadzwyczajny ciąg zdarzeń 2.

Jeśli klient wprowadził błędny PIN, to przypadek użycia wraca do

punktu początkowego.

Gdy zdarzy się to 3 razy z rzędu, system anuluje całą transakcję

i przez 90 sekund nie reaguje na działania klienta.

Tomasz Szmuc '05

7

Przypadki użycia można uporządkować przez zdefiniowanie uogólnień i

związków zawierania i rozszerzania.

Uogólnienie oznacza, że przypadek użycia-potomek dziedziczy całe

zachowanie i znaczenie po przypadku-przodku.

Potomek może wprowadzać nowe elementy do odziedziczonego

zachowania. Potomek może zastąpić przodka, np. różny sposób

weryfikacji klienta w bankomacie.

Tomasz Szmuc '05

8

Zawieranie (<<include>>) oznacza, że bazowy przypadek użycia

jawnie włącza się w zachowanie innego przypadku użycia, w miejscu

przez siebie określonym.

Włączany przypadek użycia nie występuje samodzielnie - jego

egzemplarze mogą być tylko częścią większego, zawierającego go

przypadku użycia.

Tomasz Szmuc '05

9

Samodzielne wystąpienie bazowego przypadku użycia jest możliwe,

jeśli, pod pewnymi warunkami, jego zachowanie może być

rozszerzone przez zachowanie innego przypadku użycia.

Związku zawierania używa się w celu uniknięcia wielokrotnego

definiowania tego samego ciągu zdarzeń.

Jest to przykład delegowania - pewien zbiór zobowiązań

jest specyfikowany przez składnik systemu, a inne elementy systemu

(pozostałe przypadki użycia) włączają ten zbiór zobowiązań, jeśli

zachodzi taka potrzeba.

Tomasz Szmuc '05

10

Rozszerzenie (<<extends>>) oznacza, że bazowy przypadek użycia

w sposób domniemany włącza zachowanie innego przypadku użycia w

określonym miejscu.

Rozszerzenie służy do modelowania fragmentów przypadków użycia

postrzeganych przez użytkownika jako opcjonalne zachowanie

systemu.

Można tym samym określić pewien podciąg zdarzeń, które mogą

zachodzić pod pewnymi warunkami.

Można również dołączyć wskazany podciąg w konkretnym miejscu.

Tomasz Szmuc '05

11

Złóż zamówienie

Extension points

określ priorytet

Złóż zamówienie

ekspresowe

Śledź zamówienie

Weryfikuj

użytkownika

Sprawdź hasło

Porównaj
siatkówkę

<<inc

lude>>

<<in

clud

e>>

<<e

xten

d>>

(okr

eśl p

riory

tet)

Rys. Uogólnienie, zawieranie i rozszerzanie przypadków użycia

Tomasz Szmuc '05

12

Wytyczne względem modelowania

Wytyczne względem modelowania

przypadków użycia

przypadków użycia

1.

Identyfikacja aktorów będących w interakcji z dana jednostką.

2.

Uporządkuj aktorów przez wyznaczenie ról ogólnych i szczegółowych.

3.

Dla każdego aktora rozważ podstawowe sposoby jego komunikacji
z daną jednostką.

4.

Analizuj i określ sytuacje wyjątkowe, w których dochodzi do
interakcji aktora z daną jednostką.

5.

Usystematyzuj przypadki użycia - uogólnienie, zawieranie,
rozszerzenie.

Tomasz Szmuc '05

13

Identyfikacja aktorów

Kto lub co używa lub jest w interakcji z systemem?

1.

Kto lub co używa systemu?

2.

Jakie role pełnią w interakcji?

3.

Kto instaluje, kto startuje, kto pielęgnuje system?

4.

Jakie inne systemy są w interakcji z danym?

5.

Kto dostarcza, kto pobiera informację?

6.

Czy coś może zdarzyć się w otoczeniu w czasie działania systemu?

Tomasz Szmuc '05

14

Właściwości aktorów

•

aktorzy są poza systemem;

•

aktorzy są w bezpośredniej interakcji z systemem – to pozwala

wyznaczenie granicy systemu;

•

aktorzy reprezentują role pełnione przez ludzi lub elementy

(przedmioty) – nie są to jednak konkretne osoby/przedmioty;

•

jedna osoba może pełnić wiele ról względem systemu współbieżnie

lub w czasie;

•

każdy aktor ma krótką nazwę odnoszącą się do jego perspektywy

biznesowej;

•

każdy aktor powinien mieć krótki opis (1-2 linijki) określający

czym jest z perspektywy biznesowej;

•

podobnie jak klasa aktor może mieć atrybuty i listę sygnałów

przyjmowanych – rzadko stosowane.

Tomasz Szmuc '05

15

Zdarzenia związane z upływem czasu mogą być modelowane

przez aktora:

Time

Tomasz Szmuc '05

16

Co to są przypadki użycia?

Przypadek użycia opisuje widzialne zachowanie systemu na korzyść

jednego lub większej ilości aktorów.

Jest to przypadek (case) użycia (use) systemu przez pewnego

aktora (aktorów):

•

przypadki użycia zawsze są inicjowane przez aktora;

•

przypadki użycia są zawsze pisane z punktu widzenia aktora.

Tomasz Szmuc '05

17

Identyfikacja przypadków użycia

Jak każdy aktor używa systemu ?
Co realizuje system dla każdego aktora?

1.

Jakie charakterystyczne funkcje są żądane przez poszczególnych

aktorów?

2.

Czy system przechowuje i wyszukuje informację – jeśli tak, to

którzy

aktorzy wzbudzają takie zachowanie?

3.

Czy istnieją aktorzy powiadamiani o zmianie stanu systemu?

4.

Czy istnieją zewnętrzne zdarzenia oddziałujące na system i jak

system

reaguje na te zdarzenia?

Tomasz Szmuc '05

18

Słownik projektu

Słownik projektu jest jednym z ważniejszych artefaktów artefaktów

projektu.

Każda dziedzina ma swój język (żargon) – pierwszy krok

inżynierii wymagań polega na analizie i zrozumieniu tego języka.

UML nie definiuje standardów w tej dziedzinie – zazwyczaj jest to

zestaw podstawowych terminów i ich określeń uporządkowany

alfabetycznie – słownik w formacie HTML, XML.

Tomasz Szmuc '05

19

Diagramy przypadków użycia

Diagramy przypadków użycia

Diagram przypadków użycia przedstawia zbiór przypadków użycia

i aktorów oraz związki między nimi.

Diagramy przypadków użycia są stosowane do obrazowania statycznych

aspektów perspektywy przypadków użycia systemu.

W ogólności dotyczy to realizacji 2 celów:
1.

Modelowanie otoczenia systemu - granica system-otoczenie,

wskazanie aktorów i znaczenia ich ról.

2.

Modelowanie wymagań stawianych systemowi - co system

powinien „robić” z punktu widzenia otoczenia.

Tomasz Szmuc '05

20

Modelowanie otoczenia systemu

Modelowanie otoczenia systemu

Realizuj

transakcje kartą

Rozlicz

transakcję

Uzgodnij

transakcję

Obsługuj

rachunek klienta

Klient

Klient

indywidualny

Instytucja

Jednostka handlu

detalicznego

Organizacja

finansowa

System kart kredytowych

Rys. Modelowanie otoczenia systemu

Tomasz Szmuc '05

21

Wytyczne modelowania granicy

Wytyczne modelowania granicy

system

system

-

-

otoczenie

otoczenie

1.

Zidentyfikuj aktorów działających w otoczeniu systemów.

2.

Uporządkuj podobnych aktorów za pomocą uogólnień.

3.

Jeśli potrzeba - utwórz stereotypy aktorów dla zwiększenia czytelności.

4.

Połącz aktorów z odpowiednimi przypadkami użycia.

Tomasz Szmuc '05

22

Modelowanie wymagań stawianych

Modelowanie wymagań stawianych

systemowi

systemowi

Wytyczne

Wytyczne

1.

Zidentyfikuj aktorów systemu (określ jego otoczenie).

2.

Dla każdego aktora rozważ działania, których oczekuje (wymaga) od

systemu.

3.

Znajdź powtarzające się fragmenty działań i uporządkuj przypadki

użycia.

4.

Uwzględnij zmodyfikowane przypadki użycia w definiowaniu

związków z aktorami.

5.

Dodaj notatki określające wymagania niefunkcjonalne.

Tomasz Szmuc '05

23

Realizuj

transakcje kartą

Rozlicz

transakcję

Uzgodnij

transakcję

Obsługuj

rachunek klienta

Klient

Jednostka handlu

detalicznego

Organizacja

finansowa

System kart kredytowych

Podaj stan

konta

Wykryj oszustwo

kartą

<<

inc

lud

e>>

<<inclu

de>>

<<include>>

Rys. Dodatkowe przypadki użycia, niewidoczne dla klienta

Tomasz Szmuc '05

24

MailOrderSystem

PlaceOrder

CancelOrder

CheckOrderStatus

SendCatalog

ShipProduct

Customer

ShippingCompany

Dispatcher

Przykład systemu zdalnego zamawiania towarów

Tomasz Szmuc '05

25

Uściślanie przypadków użycia

use case model

[outlined]

Glossary

Supplementary

requirements

Nie ma UML-standardu dotyczącego
postaci uściśleń – podana dalej notacja
jest powszechnie używana.

use case

[detailed]

Tomasz Szmuc '05

26

Use Case: PayVAT

ID: EU2

Actors:
Time
Goverment

Preconditions:
1. It is the end of a business quarter.

Flow of events:
1.

The use case starts when it is the end of the
business quarter.

2.

The systems determines the amount of VAT
owed to the Goverment.

3.

The system sends an electronic payment to
the Goverment.

Postconditions:
1.

The Goverment receives the correct
amount of VAT.

Prewarunek – ograniczenie
dotyczące stanu startu systemu.

Kroki realizacji przypadku
użycia.

Postwarunek – ograniczenie
stanu po wykonaniu przypadku
użycia.

Tomasz Szmuc '05

27

Kroki realizacji przypadku użycia

Określenie początku realizacji:

1. The use case starts when an <actor> <function>.

Określenie sekwencji kroków w postaci:

<number> The <something><some action>.

Przykład

1. The use case starts when customer selects place order.
2. The customer enters his name and address into the form.
3. ...

Tomasz Szmuc '05

28

Rozgałęzienia przebiegów

1.

Użycie słowa kluczowego if

Use case: ManageBasket

Actors:
Customer

Preconditions:
1. The shopping basket contents are visible

Flow of events:
1.

The use case starts when Customer selects

an item in the basket.

2.

if the customer selects „delete item”
2.1 The system removes the item from

the basket.

3.

if the Customer types in a new quantity
3.1 The system updates the quantity of

the item in the basket.

Postconditions:
1. The basket contents have been updated.

Tomasz Szmuc '05

29

Use case: DisplayBasket

Actors:
Customer

Preconditions:
1. The Customer is logged on the system

Flow of events:
1.

The use case starts when Customer selects

”display basket”.

2.

if there are no items in the basket
2.1 The system informs the Customer that

there are no items in the basket.

2.2 The use case terminates.

3.

The system displays a list of all items in
the Customer’s shopping basket including
product ID, name, quantity, and item price.

Postconditions:

Alternative flow 1:
1. At any time the Customer may leave the

shopping basket screen.

Postconditions:

Alternative flow 2:
1. At any time the Customer may the system.

Postconditions:

2. Alternatywne przebiegi

Niekiedy trzeba wyspecyfikować
alternatywne przebiegi, które być
spowodowane zdarzeniem
zachodzącym w dowolnym czasie.

Tomasz Szmuc '05

30

Use case: FindProduct

Actors:
Customer

Preconditions:

Flow of events:
1.

The Customer selects ”find product”.

2.

The system asks Cutomer for search criteria.

3.

The enters request criteria.

4.

The system searches for product that match
the Customer’s criteria.

5.

if the system finds some matching products
then
5.1 for each product found

5.1.1 The system displays a thumbnail

sketch of the product

5.1.2 The system displays summary

of the product details

5.1.3 The system displays the product

price.

6.

Else
The system tells the Customer that no
matching products could be fiund.

Postconditions:
Alternative flow:
1. At any point the Customer may move to

differnet page.

Zastosowanie pętli for

Tomasz Szmuc '05

31

Use case: ShowCompanyDetails

Actors:
Customer

Preconditions:

Flow of events:
1.

The use case starts when Customer selects

„”show company details”.

2.

The system displays a web page showing
the company details.

3.

while the Customer is browsing the
company details
3.1 The system plays some background

music.

3.2 The system displays special offers in

a banner.

Postconditions:

Zastosowanie pętli while

Tomasz Szmuc '05

32

Śledzenie wymagań

Istniejące narzędzia, np. Requisite Pro lub DOORS dostarczają

narzędzi do wspomagania śledzenia wymagań. Najczęściej są

to tzw. Traceability Matrices.

Przypadki użycia

Wyma-

gania

UC1 UC2 UC3

UC4

R1 X

R2 X

X

R3 X

R4

X

R5 X

Tomasz Szmuc '05

33

Złożone przypadki użycia

Ogólna zasada – przypadki użycia winny być proste – czasami jednak

nie jest możliwa sensowna dekompozycja.

Scenariusz – pojedyncza (bez rozgałęzień) ścieżka w przypadku użycia.

Przypadek użycia może mieć jeden główny scenariusz i wiele

drugorzędnych.

Tomasz Szmuc '05

34

Use case: Checkout

Actors:
Customer

Preconditions:

Primary scenario:
1.

The use case starts when Customer selects ”go to checkout”.

2.

The system displays the customer order.

3.

The system asks for the customer identifier.

4.

The Customer enters a valid customer indentifier.

5.

The system retrieves and displays the Customer’s details.

6.

The system asks for credit card information:name on card,
card number and expire date.

7.

The Customer enters the credit card information.

8.

The system asks for confirmation of the order.

9.

The Customer confirms the order.

10.

The system debits the credit card.

11.

The system displays an invoice.

Secondary scenarios:
InvalidCustomerIdentifier
InvalidCreditCardDetails
CreditCardLimitExceeded
CreditCardExpired

Postconditions:

Główny scenariusz

Tomasz Szmuc '05

35

Scenariusz drugorzędny

Use case: Checkout
Secondary scenario: InvalidCustomerIdentifier

Actors:
Customer

Preconditions:

Primary scenario:
1.

The use case begins in step 3 of the use case Checkout
when the Customer enters an invalid customer identifier.

2.

For three invalid entries
2.1 The system asks the Customer to enter the customer

identifier again.

3.

The system informs the Customer that their customer
identifier was not recognized.

Postconditions:

Tomasz Szmuc '05

36

Scenariusze drugorzędne są znajdowane w trakcie przeglądu

głównych, w szczególności przez szukanie:

•

alternatywnych przebiegów;

•

błędów, które mogą wystąpić;

•

przerwań, które mogą się pojawić w dowolnym momencie.

Tomasz Szmuc '05

37

Podsumowanie: kiedy modelowanie przez przypadki użycia

jest efektywne?

•

system jest „zdominowany” przez wymagania funkcjonalne;

•

system ma wiele rodzajów użytkowników, dla których dostarcza

odmienna funkcjonalność;

•

system ma wiele interfejsów (aktorów).

Raczej nie należy stosować gdy:

•

system jest „zdominowany” przez wymagania niefunkcjonalne;

•

system ma kilku użytkowników;

•

system ma niewiele inferfejsów.

Tomasz Szmuc '05

38

Uogólnienie aktorów

Uogólnienie aktorów łączy zachowanie wspólne dla dwóch lub więcej

aktorów. Jest realizowane dla uproszczenia specyfikacji.

Tomasz Szmuc '05

39

Sales system

ListProducts

OrderProducts

AcceptPayment

CalculateCommision

Customer

SalesAgent

Tomasz Szmuc '05

40

Abstrakcyjny aktor

Sales system

ListProducts

OrderProducts

AcceptPayment

CalculateCommision

Purchaser

SalesAgent

Customer

Tomasz Szmuc '05

41

Uogólnienie przypadków użycia

Uogólnienie przypadków użycia – dzieci mogą:

•

dziedziczyć właściwości od rodzica;

•

dodawać nowe właściwości;

•

przeciążać (przeładować) właściwości dziedziczone.

Tomasz Szmuc '05

42

Element przypadku

użycia

Dziedziczenie Dodanie Przeciążenie

Związek (relacja)

Tak

Tak

Nie

Prewarunek Tak

Tak

Tak

Postwarunek Tak

Tak

Tak

Krok w głównym
przebiegu

Tak Tak Tak

Alternatywny przebieg

Tak

Tak

Tak

Atrybut Tak

Tak

Nie

Operacja Tak

Tak

Tak

Ograniczenia dziedziczenia/dodania/przeciążenia

Tomasz Szmuc '05

43

Standardowa konwencja – zapisu (nie zdefiniowana w UML)

Właściwość jest:

Konwencja zapisu

dziedziczona bez zmian

normalny tekst

przeciążona

pochyły (italic) tekst

dodana

wytłuszczony (bold) tekst

Tomasz Szmuc '05

44

SaleSystem

FindProduct

FindBook

FindCD

Customer

Tomasz Szmuc '05

45

Use case: FindProduct

Actors:
Customer

Preconditions:

Flow of events:
1.

The Customer selects ”find product”.

2.

The system asks Cutomer for search criteria.

3.

The enters the requested criteria.

4.

The system searches for products that match
the Customer’s criteria.

5.

if the system finds some matching products
then
5.1 The system displays a list of the

matching products.

6.

Else
6.1 The system tells the Customer that no

matching products could be found.

Postconditions:

Alternative flow:
1. At any point the Customer may move to

different page.

Tomasz Szmuc '05

46

Use case: FindBook

Actors:
Customer

Preconditions:

Flow of events:
1.

The Customer selects ”find book”.

2.

The system asks Cutomer for book search
criteria: author name, title, ISBN or topic.

3.

The enters the requested criteria.

4.

The system searches for books that match
the Customer’s criteria.

5.

If the system finds some matching books
then
5.1 The system displays a page showing

details of a maximum 5 books.

5.2 For each book on the page the system

displays the title, author, price and
ISBN.

5.3 While there are more books

5.3.1 The system gives the Customer

option to display the next page
of books.

6.

Else
6.1 The system redisplays the ”find book”

search page.

6.2 The system tells the Customer that no

matching products could be found.

Use case: FindCD

Actors:
Customer

Preconditions:

Flow of events:
1.

The Customer selects ”find CD”.

2.

The system asks Cutomer for CD search
criteria: artists, title, or genre.

3.

The enters the requested criteria.

4.

The system searches for CDs that match
the Customer’s criteria.

5.

If the system finds some matching CDs then
5.1 The system displays a page showing

details of maximum 10 CDs.

5.2. For each CD on the page the system

displays the title, artist, and price.

5.3 While there are more CDs

5.3.1 The system gives the Customer

option to display next page
of CDs.

6.

Else
6.1 The system redisplays the ”find CD”

search page.

6.2 The system tells the Customer that no

matching products could be found.

Tomasz Szmuc '05

47

Przykład – system alarmowy

DeactivateSystem

ActivateAll

ActivateFireOnly

TriggerSensor

SecurityGuard

Fire

SecuritySystem

Burglar

Tomasz Szmuc '05

48

Use Case: DeactivateSystem

Aktorzy:
SecurityGuard

Prewarunki:
SecurityGuard ma klucz do aktywacji

Przepływ zdarzeń:
1.

SecurityGuard używa klucza do aktywacji
w celu wyłączenia systemu.

2.

System system przestaje monitorować
czujniki bezpieczeństwa i czujniki ognia.

Postwarunki:
System jest wyłączony.
System nie monitoruje czujników.

Tomasz Szmuc '05

49

Use Case: ActivateAll

Aktorzy:
SecurityGuard

Prewarunki:
SecurityGuard ma klucz do aktywacji

Przepływ zdarzeń:
1.

SecurityGuard używa klucza do aktywacji
w celu włączenia systemu.

2.

System system zaczyna monitorować
czujniki bezpieczeństwa i czujniki ognia.

3.

System uruchamia sygnał syreny (pip) w celu
sygnalizacji, że jest uzbrojony.

Postwarunki:
System jest włączony.
System monitoruje czujniki.

Tomasz Szmuc '05

50

Use Case: TriggerSensor

Aktorzy:
Fire
Burglar

Prewarunki:
SecuritySystem jest włączony.

Przepływ zdarzeń
1.

if aktor Fire wzbudza FireSensor
1.1. Syrena (Siren) sygnalizuje alarm

ogniowy.

2.

if aktor Burglar wzbudza SecuritySensor
2.1. Syrena (Siren) sygnalizuje alarm

bezpieczeństwa.

Postwarunki:
Syrena alarmuje.

Tomasz Szmuc '05

51

Przykład II

Przykład II

-

-

biblioteka

biblioteka

ReturnBook

BorrowBook

FindBook

IssueFine

Librarian

<<

exte

nd>

>

Rys. Przypadki użycia dla systemu bibliotecznego

Tomasz Szmuc '05

52

Use Case: ReturnBook

Aktorzy:
Librarian

Prewarunki:
Właściwy Librarian jest zalogowany w systemie.

Przepływ zdarzeń
1.

Librarian wprowadza numer ID
wypożyczającego .

2.

System wyświetla informacje o
wypożyczającym, łącznie z listą
wypożyczonych książek.

3.

Librarian znajduje książkę do zwrotu na
liście pożyczonych.

<overdueBook>
4.

Librarian zwraca książkę.

5.

...

Postwarunki:
Książka została zwrócona.

ReturnBook

extension points

overdueBook

<<extend>>

(overdueBook)

IssueFine

nazwa punktu

rozszerzenia

punkt

rozszerzenia

Tomasz Szmuc '05

53

ReturnBook

extension points

overdueBook

<<extend>>

(overdueBook)

IssueFine

Extension use case: IssueFine

Insertion segment:
1.

Librarian korzysta z systemu aby zapisać

karę i wydrukować rachunek.

Pojedynczy punkt rozszerzenia

Pojedynczy segment rozszerzenia w IssueFine jest włączany
do <overdueBook> w punkcie rozszerzenia w przypadku
ReturnBook.

Tomasz Szmuc '05

54

ReturnBook

extension points

overdueBook

payFine

<<extend>>

(overdueBook, payFine)

IssueFine

Extension use case: IssueFine

Insertion segment 1:
1.

Librarian korzysta z systemu aby zapisać

karę i wydrukować rachunek.

Insertion segment 2:
1.

if wypożyczający decyduje się
zapłacić na miejscu.
1.1. Librarian przyjmuje zapłatę kary.
1.2. ...

Wielokrotne segmenty rozszerzenia

Pierwszy segment jest włączany

W miejsce

overdueBook

, drugi w miejsce

payFine

.

Tomasz Szmuc '05

55

Warunkowe rozszerzenie

ReturnBook

extension points

overdueBook

payFine

<<extend>>

(overdueBook)

[firstOffence]

IssueWarning

IssueFine

<<extend>>

(overdueBook, payFine)

[!firstOffence]