Model przypadków użycia

(1)

Model przypadków użycia

Jolanta Sala Halina Tańska

2018/2019

(2)

Model przypadków użycia

• Wymagania użytkowników systemu informacyjnego można przedstawić w:

– postaci listy zdań, które chcą oni za pomocą tego systemu wykonać. Każde z zadań można opisać podając kolejność działań, w toku których użytkownik wybierze zadanie poda dane niezbędne do jego realizacji i odbierze potrzebne mu wyniki.

• Opis wymagań przyjmuje postać opisu wszystkich sposobów używania systemu przez użytkowników.

• Przykładowo zadania wykonywane przez firmę firmę ubezpieczeniową

ubezpieczeniową obejmują:

– zawarcie ubezpieczenia OC lub AC

– wypłacenie odszkodowania, nazwane likwidacją szkody.

(3)

Przykład – firma ubezpieczeniowa

• Zawarcie ubezpieczenia jest wykonywane na zlecenie

klienta, któremu przynosi korzyść w postaci ochrony przed odpowiedzialnością cywilną lub rozbiciem własnego

samochodu. Wykonanie zadania obejmuje wypełnienie danych na formularzu, dołączenie kopi dokumentów samochodu, opłacenie składki i odebranie polisy

ubezpieczeniowej.

• Likwidacja szkody następuje na wniosek klienta, któremu przynosi korzyść w postaci zwrotu poniesionych kosztów.

Wykonanie zadania obejmuje wypełnienie formularza zgłoszenia szkody, przedstawienie polisy

ubezpieczeniowej, ocenienie przez firmę zasadności

roszczenia i wartości szkody oraz dokonanie przelewu na konto klienta.

(4)

Model przypadków użycia

• Graficzną reprezentacją modelu jest diagram

przypadków użycia (use case diagram), którego podstawowymi elementami są ikony aktorów, owale reprezentujące przypadki użycia oraz linie przedstawiające zachodzące między nimi relacje.

• Istnienie relacji łączącej aktora z przypadkiem

użycia wskazuje na zaangażowanie tego aktora w realizację danego przypadku.

powtórzenie powtórzenie

(5)

uc Use Case View

System ubezpieczeń

Klient

Likw idator System bankow y zaw arcie

ubezpieczenia w ypłata

odszkodow ań

likw idacj a szkody

Diagram przypadków użycia firmy ubezpieczeniowej

Aktorzy diagramu PU modelują zewnętrzne obiekty współpracujące z budowanym systemem.

Aktora inicjującego wykonanie przypadku

użycia można wyróżnić dodatkową strzałką umieszczoną na końcu linii relacji.

2/5

(6)

Diagram przypadków użycia

Diagram przypadków użycia (Use Case

Diagram) ukazuje system z punktu widzenia

użytkownika.

(7)

Diagram przypadków użycia

• Diagram przypadków użycia (ang. Use Case Diagram) jest diagramem, który przedstawia

funkcjonalność systemu wraz z jego otoczeniem

• Diagramy przypadków użycia pozwalają na

graficzne zaprezentowanie własności systemu tak, jak są one widziane po stronie użytkownika

• Diagramy przypadków użycia służą do

zobrazowania usług, jakie są widoczne z zewnątrz systemu

(8)

Diagramy przypadków użycia

• specyfikują wymagania stawiane systemowi

• obrazują zachowanie systemu

• modelują otoczenie systemu

• nie definiują sposobu implementacji systemu

• opisują jedynie najważniejsze aspekty zachowania systemu

• nie są przesadnie szczegółowe

• są platformą do komunikacji analityka z

klientem

(9)

Diagram przypadków użycia

Kluczowymi elementami są:

• aktorzy (actor)

• przypadki użycia (use case)

• związki (association)

Dodatkowo diagram może zwierać:

• notatki (note)

• ograniczenia (constraints)

• pakiety (packages)

?

(10)

Modelowanie konceptualne

System informatyczny (czarna skrzynka) Otoczenie = Aktorzy

(11)

Aktor

• Aktor (ang. actor) jest funkcją, jaką pełni użytkownik w stosunku do systemu oraz przypadków użycia.

• Aktor reprezentuje spójny zbiór ról, które są

odgrywane przez użytkowników przypadku użycia w czasie interakcji z tym przypadkiem.

• Aktorem może być człowiek, urządzenie, inny system lub czas.

• Aktor nie musi być fizycznym obiektem. Istotne by pełnił określoną funkcję wobec systemu i przypadku użycia, którego używa.

(12)

Aktor

Aktor to użytkownik lub inny system, który wchodzi w interakcję z naszym systemem.

Najczęściej używany

symbol powtórzeniepowtórzenie

(13)

Aktor

• Aktorzy stanowią otoczenie systemu

^{(nie są}

częścią systemu)

• Aktor może aktywnie wymieniać informacje z systemem

(dostarczać informacje i pobierać)

• Aktor może wywoływać akcje w systemie

• Aktorami mogą być:

• człowiek

• urządzenie

• inny system

(14)

Aktor

Aktor reprezentuje rolę w jakiej człowiek,

inny system bądź urządzenie może się wcielić w interakcji z naszym systemem.

Jeden Kowalski w wielu rolach

(15)

Aktor

Relacje między aktorami – uogólnienie (generalization)

Potomek dziedziczy całe zachowanie i znaczenie po przodku oraz posiada własne zachowania i cechy.

Klient indywidualny i klient instytucjonalny są szczególnym

rodzajem klienta.

(16)

Generalizacja

Student Użytkownik potomek przodek

Grot strzałki wskazuje na przodka (klasę ogólną)

Związek generalizacji to związek pomiędzy elementem ogólnym (nadklasa lub przodek) a specyficznym jego rodzajem zwanym podklasą lub potomkiem. Element specyficzny jest całkowicie zgodny z elementem ogólnym i zawiera dodatkową informację.

Egzemplarz elementu specyficznego może być użyty wszędzie tam, gdzie dopuszcza się egzemplarz elementu ogólnego.

Potomek zawsze może zastąpić przodka

uc aktorzy

Wypożyczaj ący (from Use Case View) Student

Pracow nik naukow y

(17)

Aktor

Pojazd Uogólnienie

Człowiek

ogólnie

szczególnie

(18)

Modelowanie konceptualne

System informatyczny (czarna skrzynka) Otoczenie =

Aktorzy

Wymagania

funkcjonalne Aktorów

A1

W1 W2 W3

…

A2

W1 W2 W3

An

W1 W2 W3

= zdefiniowani A1, A2, …, An

(19)

Przypadek użycia

• Przypadek użycia (PU) jest graficzną

reprezentacją wymagań funkcjonalnych

• Definiuje zachowanie systemu bez

informowania o wewnętrznej strukturze i narzucania sposobu implementacji

• Przypadek użycia pozwala na zdefiniowanie przyszłego, spodziewanego zachowania

systemu

Dodaj słuchacza

Przypadek użycia jest …?

(20)

Przypadek użycia

• Kwant funkcjonalności systemu

dostarczający aktorowi usług o mierzalnej wartości (I. Jacobson).

• Czynność, której wykonanie bezpośrednio świadczy o efektywności pracy

• Nazwana lub dobrze określona interakcja pomiędzy użytkownikiem a systemem

komputerowym

(21)

Przypadek użycia

• Przypadek użycia musi być w interakcji,

chociaż z jednym aktorem. Wyjątek stanowi sytuacja, gdy przypadek użycia jest

połączony z innym przypadkiem użycia związkiem rozszerzenie lub zawierania.

• Przypadek użycia to zbiór scenariuszy powiązanych ze sobą wspólnym celem użytkownika.

Sprawdź ocenę

(22)

Przypadek użycia

Przypadek użycia opisuje, co system robi, lecz nie określa, jak to robi.

(23)

Przypadek użycia

Przypadek użycia to opis zbioru akcji wykonywanych przez system w celu dostarczenia aktorowi wyniku.

W UML przypadek użycia jest przedstawiony w postaci elipsy z nazwą po środku.

Sprawdź stan konta

Klient banku

(24)

Przypadek użycia

Elementy żyjące wewnątrz systemu (przypadki użycia) są odpowiedzialne za wykonanie

działań, których elementy zewnętrzne (aktorzy) oczekują od systemu.

Nazwa przypadku użycia musi być czynnością.

(25)

Przypadek użycia

• Budując model należy pamiętać o oddzieleniu pojęć – tego, co dotyczy pracy systemu, od tego, co dotyczy jego realizacji.

• Informacyjna zawartość DPU jest dość uboga i nie opisuje wystarczająco dokładnie sposobu

używania systemu przez użytkowników.

• Podstawowym środkiem dokumentowania modelu jest tekstowy zapis scenariuszy, opisujących krok po kroku sposób wykonania wszystkich

przypadków użycia.

(26)

Przykład – firma ubezpieczeniowa

• Zawarcie ubezpieczenia jest wykonywane na zlecenie

klienta, któremu przynosi korzyść w postaci ochrony przed odpowiedzialnością cywilną lub rozbiciem własnego

samochodu. Wykonanie zadania obejmuje wypełnienie danych na formularzu, dołączenie kopi dokumentów samochodu, opłacenie składki i odebranie polisy

ubezpieczeniowej.

• Likwidacja szkody następuje na wniosek klienta, któremu przynosi korzyść w postaci zwrotu poniesionych kosztów.

Wykonanie zadania obejmuje wypełnienie formularza zgłoszenia szkody, przedstawienie polisy

ubezpieczeniowej, ocenienie przez firmę zasadności

roszczenia i wartości szkody oraz dokonanie przelewu na konto klienta.

(27)

PU przykład – scenariusz główny

Likwidacja szkody

1. Przyjmujący rejestruje zgłoszenie szkody w systemie.

Zgłoszenie obejmuje numer polisy, dane zgłaszającego, datę wypadku i datę zgłoszenia.

2. System tworzy sprawę likwidacji szkody i nadaje jej unikalny numer identyfikacyjny.

3. Przyjmujący wprowadza dane określające charakter szkody, obejmujące opis wypadku i opis uszkodzeń, oraz podpisuje dokument zgłoszenia.

4. System przypisuje likwidatora szkody, który ocenia zasadność zgłoszenia i prowadzi postępowanie

odszkodowawcze.

5. Likwidator oblicza wartość odszkodowania i przekazuje zlecenie wypłaty do działu księgowości.

(28)

PU przykład – scenariusz alternatywny

Likwidacja szkody – duplikat zgłoszenia 1. Jak w scenariuszu głównym.

2. System powiadamia o istniejącym zgłoszeniu i odmawia utworzenia sprawy.

Likwidacja szkody – nieważna polisa 1–5. Jak w scenariuszu głównym.

6. Likwidator powiadamia klienta o odmowie odszkodowania i zamyka sprawę

(29)

PU – poziomy abstrakcji

• Pojedynczy PU reprezentuje zbiór scenariuszy, w których istnieje

– scenariusz główny opisujący typowy sposób postępowania prowadzący do osiągnięcia celu użytkownika,

– scenariusze alternatywne, opisujące sposoby postępowania w razie niemożności wykonania scenariusza głównego.

• Modelowanie wymagań za pomocą PU może przebiegać na różnych poziomach abstrakcji. Przypadki użycia Zawarcie ubezpieczenia i Likwidacja szkody tworzą całościowy opis sposobów obsługiwania klientów przez przedsiębiorstwo ubezpieczeniowe.

– Taki model jest bardzo użyteczny w początkowym stadium projektu.

– Dalsza analiza reguł działania i wymagań użytkownika może prowadzić do wyodrębnienia przypadków użycia opisujących sposoby używania systemu do poszczególnych kroków obsługi klienta przez pracowników firmy takich jak: Rejestracja dokumentu, Rejestracja zgłoszenia szkody, Utworzenie sprawy szkody, Wycena wartości szkody, Obliczanie

odszkodowania itp.

(30)

Związki

Związki w diagramach przypadków użycia:

• powiązania

(tylko między aktorem a przypadkiem użycia)

• uogólnienia

• zawierania – include

• rozszerzenia - extend

Jakie…?

(31)

Związki

Związek zawierania stosuje się w celu

uniknięcia wielokrotnego opisywania tego samego ciągu zdarzeń.

Przyjmij towar... zawsze zawiera Czytaj kod...

<< include >>

(32)

Związek zawierania

Bazowy PU include Zawierany PU

Zobacz prezentację

Wysłuchaj wykładu include

Związek zawierania (ang. Include) polega na tym, że bazowy przypadek użycia rozszerza swoją funkcjonalność o

zachowanie innego przypadku użycia. Zawierany przypadek użycia nie jest autonomiczny.

(33)

przeanalizuj ryzyko określ w artość

w yceń kontrakt

«include»

Do relacji zawierania dochodzi wtedy, gdy kilka przypadków użycia ma wspólną sekwencję podobnych kroków, której nie warto ciągle

kopiować z jednego przypadku do drugiego.

Przykładowo „przeanalizuj ryzyko” i „wyceń kontrakt” wymagają, aby określić wartość kontraktu.

Opisanie określenia wartości kontraktu wymaga sporo pracy, stąd należy utworzyć oddzielny przypadek użycia „określ wartość

kontraktu” i odwołać się do niego z innych PU.

Zawieranie

(34)

Uogólnienie

uc zw iązek uogolnienia

zarej estruj transakcj e

limit przekroczony

Uogólnienia używa się wówczas, gdy dany przypadek użycia jest podobny do innego, ale jest nieco obszerniejszy. Jest to jeszcze jeden ze sposobów uchwycenia

scenariuszy alternatywnych.

W przykładzie podstawowym PU jest „zarejestruj transakcję”. Jest to przypadek użycia systemu, w sytuacji gdy wszystko się powiodło. Coś mogło jednak

przeszkodzić pomyślnej rejestracji transakcji, np. przekroczenie limitu, który biuro maklerskie ustaliło dla konkretnego kontrahenta.

W takiej sytuacji nie wykonuje się typowych kroków związanych z tym PU, lecz alternatywny przypadek użycia. Specjalistyczny PU może przesłonić dowolną część podstawowego PU, ale zawsze powinien dotyczyć osiągnięcia tego samego celu użytkownika co podstawowy PU.

(35)

Relacja rozszerzenia

Jest ta relacja podobna do uogólnienia, jednak bardziej formalna.

Rozszerzenie PU może wzbogacić go o dodatkowe zachowania, ale w takiej sytuacji podstawowy PU musi określić pewne punkty rozszerzenia, a rozszerzający PU

może dodać nowe zachowania tylko w tych punktach.

Przypadek użycia może mieć wiele punktów rozszerzeń, a rozszerzający PU może rozszerzać podstawowy PU w kilku z tych punktów.

PU pożycz książkę można podzielić na zwykły PU, w którym użytkownik może pożyczyć książkę, i wyjątkowy PU, w którym użytkownik nie może jej pożyczyć, ponieważ wypożyczył już maksymalną dopuszczalną liczbę książek.

uc zw iazek extend

pozycz ksiazke

odmow a pozyczki

«extend»

(36)

Związki

Związek rozszerzenia służy do modelowania fragmentów przypadku użycia postrzeganych

przez użytkownika jako opcjonalne zachowanie systemu.

Ekspresowa... opcjonalnie rozszerza Przesyłkę...

<< extend >>

(37)

Bazowy PU extend Rozszerzający PU

Wykonaj ćwiczenie

Wysłuchaj wykładu extend

Związek rozszerzania (ang. Extend) wskazuje, że dany przypadek użycia opcjonalnie rozszerza funkcjonalność bazowego przypadku użycia. Funkcjonalność bazowego

przypadku użycia jest rozszerzana o inny przypadek użycia po spełnieniu określonego warunku.

Związek rozszerzania

Warunek: {standard

nauczania wymaga ćwiczeń}

(38)

Student Użytkownik

Związek zawierania i rozszerzania

Sprawdź ocenę

Zobacz zaległości finansowe

Wyświetl

wszystkie oceny

extend include

(39)

Extension points

Extension Points pozwalają na dokładniejsze

określenie jakie rozszerzające przypadki użycia mają być wywołane.

(40)

Punkt rozszerzania

Punkt rozszerzania (extension points)

wskazuje na to miejsce w zachowaniu (scenariuszu) przypadku użycia, które jest rozszerzone o inny przypadek użycia za pomocą związku

rozszerzenia.

Przelicz kwotę zamówienia

Złóż zamówienie

Extension points wymagana zmiana waluty

extend

(41)

Extension points

Rozszerzający przypadek użycia

Warunek rozszerzenia

Miejsce rozszerzenia

(42)

Przykład

od Analysis View

Moduł rezerwacji

rezerw acj a

czasopisma rezerw acj a ksiązki czytelnik

w yszukanie

pow iadomienie

«include»

«extend»

Uogólnienie Zawieranie

Rozszerzenie

Jaki to związek?

(43)

Zasady (reguły) dla PU

• Gdy trzeba powtórzyć coś w kilku różnych PU, a jednocześnie chce się uniknąć powtórzyć, należy używać relacji zawierania.

• Gdy trzeba opisać warianty typowego postępowania przy zachowaniu opisu nieformalnego, należy używać relacji uogólnienia.

• Gdy trzeba opisać warianty typowego

postępowania, ale jest potrzebny bardziej formalny opis ze zdefiniowaniem punktów

rozszerzeń w przypadku podstawowym, należy używać relacji rozszerzania.

(44)

Pakiety

Pakiety pomagają dzielić usługi (przypadki użycia) logicznie w systemie.

(45)

Diagram przypadków użycia

Siec telefonii komorkowej

Uzytkownik

Zainicjuj polaczenie

Zaakceptuj polaczenie

Uzyj programu wybierajacego

Zainicjuj

telekonferencje

Zaakceptuj dodatkowe polaczenie

<< extend >>

Telefon komorkowy

Granica systemu

(46)

Diagram przypadków użycia

Dobre rady przy budowaniu diagramu:

• nazwij diagram zgodnie z przeznaczeniem

• tak rozmieść przypadku użycia i aktorów żeby zminimalizować liczbę przecinających się

związków

• poukładaj przypadki użycia blisko siebie, które są podobne pojęciowo

• korzystaj z notatek

• nie musisz przedstawiać wszystkich

przypadków użycia na jednym diagramie

(47)

Diagram przypadków użycia

• Przypadki użycia służą do modelowania oczekiwanego zachowania systemu

(bez zgłębiania sposobu implementacji systemu)

.

• Dobrze zbudowane przypadki użycia

reprezentują jedynie najważniejsze aspekty

zachowania systemu

(nie są przesadnie szczególne ani zbyt ogólne)

.

(48)

Proces tworzenia DPU

• Proces tworzenia diagramu przypadków użycia jest procesem iteracyjnym składającym się z takich etapów jak:

– Identyfikacji aktorów

– Opcjonalnemu opracowaniu diagramu kontekstowego – Identyfikacji przypadków użycia

– Opracowaniu związków – w szczególności asocjacji – Wykorzystaniu wszystkich kategorii zaawansowanych

do opracowania diagramów przypadków użycia – Udokumentowaniu przypadków użycia z

wykorzystaniem szablonów

(49)

Szablon dokumentacji PU

Nazwa Pełna nazwa przypadku użycia

Numer PU Numer identyfikacyjny przypadku użycia Twórca Dane twórcy PU (nazwisko, imię, stanowisko)

Poziom ważności Określenie poziomu ważności PU z perspektywy użytkownika np. niski, średni, wysoki Typ przypadku Określenie typu PU z punktu widzenia jego złożoności oraz ważności dla zaspokojenia

potrzeb użytkownika ogólny/szczegółowy; niezbędny/istotny/przeciętnie istotny Aktorzy Lista aktorów będących w związku z przypadkiem użycia

Krótki opis Krótka ogólna charakterystyka przypadku użycia

Warunki wstępne Charakterystyka koniecznych warunków inicjujących PU Warunki końcowe Charakterystyka stanu systemu po realizacji PU

Główny przepływ

zdarzeń Wypunktowana i scharakteryzowana lista przypadków zdarzeń zachodzących podczas PU;

scenariusz główny Alternatywne

przepływy zdarzeń

Wypunktowana i scharakteryzowana lista możliwych, alternatywnych przepływów zdarzeń PU

Specjalne

wymagania Wypunktowana i scharakteryzowana lista dodatkowych zidentyfikowanych wymagań niefunkcjonalnych, które mogą być istotne podczas projektowania czy kodowania Notatki Lista wszelkich komentarzy dotyczących PU

(50)

Dokumentacja przypadku użycia {Anuluj rezerwację}

Nazwa przypadku użycia: Anuluj rezerwację

Numer: 5

Twórca: Anna Krotoszyńska - projektant

Aktorzy: Recepcjonista, Kierownik recepcji

Krótki opis: Anulowanie istniejącej rezerwacji pokoju lub apartamentu

Waruki wstępne: Co najmniej jeden pokój lub apartament hotelowy musi być zarezerwowany Warunki końcowe: System odnotowuje pokój lub (i) apartament jako dostępny

Główny przepływ zdarzeń

1. Recepcjonista weryfikuje rezerwacje, uruchamiając funkcję „Rezerwacje”

2. System wyświetla okno z informacjami o rezerwacjach

3. Pracownik recepcji zaznacza rezerwacje do anulowania i uruchamia funkcje „Anuluj rezerwacje”

4. System wyświetla komunikat „Czy anulować zaznaczone rezerwacje?”

5. Pracownik recepcji potwierdza operację anulowania zaznaczonych rezerwacji

6. System potwierdza wykonanie operacji komunikatem „Anulowano wybrane rezerwacje” i odświeża ekran monitora

Alternatywne przepływy danych

2a. System wyświetla komunikat „Brak rezerwacji”

3a. Pracownik recepcji rezygnuje z anulowania rezerwacji

3b. Jeżeli podczas rezerwacji podany został adres e-mail, pracownik może wysłać do klienta informację o anulowaniu rezerwacji

Specjalne wymagania 1. Wysoka niezawodność systemu

2.Czas przetwarzania operacji anulowania rezerwacji nie może przekroczyć 5 sekund

Notatki Brak

(51)

Diagram przypadków użycia

(52)

System maklerski

Kierownik sali

System księgow y ustal limity

przeanalizuj ryzyko

w yceń kontrakt

zarej estruj transakcj e

limit przekroczony

zaktualizuj rachunki

określ w artość

Sprzedawca Makler

«include»

Niektóre przypadki użycia dla systemu maklerskiego

(53)

Zarządzaj ący zbiorami

Wypożyczaj ący

System biblioteki głów nej w prow adź now y

egzemplarz

dodaj istniej ący egzemplarz

w yszukaj książkę

rej estruj rezerw acj ę

rej estruj rezerw acj ę zdalnie w ypozycz ksiazke

«include»

«extend»

(54)

uc obsługa realizacj i szkoleń

System obsługi szkoleń

Koordynator szkoleń (from Aktorzy)

Trener (from Aktorzy) (from Obsługa realizacji szkoleń)

Rej estruj Trenera

(from Obsługa realizacji szkoleń) Przej rzyj moj e

szkolenia

(from Obsługa realizacji szkoleń) Przypisz zasoby

do szkolenia

(from Obsługa realizacji szkoleń) Oceń

zrealizow ane szkolenie

(from Obsługa realizacji szkoleń) Przypisz Trenera

do szkolenia

Wprow adź dane uczestnika

(from Obsługa realizacji szkoleń) Przej rzyj listę

uczestników przypisanych do

szkolenia

Prezentuj informacj ę o

szkoleniu

Prezentuj informacj e o

szkoleniu zrealizow anym

Prezentuj informacj e o

szkoleniu otw artym Przypisz

uczestnika do szkolenia

Abstrakcyjny przypadek użycia. Nie jest implementowany w systemie niemniej jednak jego istnienie można zaznaczyć w modelu

«include»

«extend»

«include»

«extend»

«include»

(55)

System wspierający pracę kancelarii prawniczej

Praw nik

Szef kancelarii

anuluj spraw ę rej estruj spraw ę rej estruj rozpraw ę

przydziel praw nika do spraw y

Podsystem czasu

usuń spraw ę podaj listę spraw

zakończonych sukcesem

spraw dź czy praw nik j est w olny

odsuń praw nika od spraw y

«extend»

«include»

(56)

Kiedy stosować PU systemu

• Podstawowe narzędzie w uchwyceniu wymagań systemu oraz w planowaniu i zarządzaniu iteracyjnym projektem

tworzenia oprogramowania.

• PU reprezentują spojrzenie z zewnątrz na system i dlatego nie istnieją korelacje

między nimi a klasami wewnątrz systemu.

(57)

Ćwiczenie

Automat do sprzedaży napojów

Automat sprzedaje kawę, herbatę i czekoladę. Do kawy i herbaty można dodatkowo zażyczyć sobie cukier. Do herbaty opcjonalnie można zamówić cytrynę, a do kawy śmietankę.

Spragniony klient wrzuca monety do automatu i wybiera napój z opcjonalnymi dodatkami. Kiedy zakończy komponowanie napoju naciska przycisk „Wydaj napój” i czeka na napój. Do momentu

wciśnięcia przycisku wydającego napój klient może zrezygnować z zakupu wciskając przycisk „Zwrot monet”, pieniądze zostaną

zwrócone.

(58)