Modelowanie Procesów Biznesowych Wykład 3 Notacja UML cz. 1 Konrad Markowski
Plan wystąpienia Biznesowy diagram przypadków użycia Konstruowanie biznesowego diagramu przypadków użycia Przykład
Wprowadzenie Czego dotyczy ten wykład? Podczas modelowania biznesowego jednym z najważniejszych elementów jest właściwe stworzenie biznesowego diagramu przypadków użycia. Poprawne konstrukcja tego diagramu stanowi pierwszy krok do właściwej analizy rozpatrywanego systemu biznesowego.
Biznesowy Diagram przypadków użycia Definicja Biznesowy diagram przypadków użycia, to graficzne przedstawienie: przypadków użycia, aktorów oraz związków między nimi, występujących w danej dziedzinie przedmiotowej BDPU, chod jest zbudowany z kilku elementów, odgrywa najważniejszą rolę w procesie modelowania biznesowego
BDPU zawiera następujące główne kategorie pojęciowe: Biznesowy przypadek użycia Aktor (aktor biznesowy lub pracownik biznesowy) Związek
Biznesowy Diagram przypadków użycia Biznesowy Przypadek użycia Biznesowy przypadek użycia (ang. business use case) to zbiór scenariuszy powiązanych ze sobą wspólnym celem użytkownika Biznesowe przypadki użycia są stosowane w całej analizie modelowania biznesowego Biznesowy przypadek użycia musi byd w interakcji chociaż z jednym aktorem. Wyjątek stanowi sytuacja, gdy BPU jest połączony z innym BPU
Każdy BPU można opisad za pomocą takich cech jak: Nazwa; Opis; Przepływ zdarzeo (scenariusz); Zależności i relacje; Jedną z najważniejszych cech, jaką opisuje BPU, jest przepływ zdarzeo scenariusze, które wskazują zestaw, sekwencji kolejno wykonywanych czynności
Nazwę BPU stanowi zwięzłe polecenie wykonania funkcji w modelowanym systemie biznesowym, sformułowane w trybie rozkazującym. Na Rysunku pokazano oznaczenie przypadku użycia zgodne ze standardem UML 2.1. uc BDPU Rezerw uj w ycieczkę Sprzedaj tow ar
Biznesowy Diagram przypadków użycia Identyfikacja BPU Jaki cel mogę osiągnąd używając tego systemu? CEL 1 Aktor CEL 2
Jakie są cele dla każdego aktora? Co aktor robi w modelowanym systemie biznesowym? Czy aktor wykonuje operacje na danych? Dlaczego wykonuje takie operacje? Czy aktor wchodzi w interakcję z zewnętrznymi systemami biznesowymi? Czy aktor potrzebuje byd informowany o zdarzeniach zachodzących w systemie biznesowym? Czy system wspiera proces biznesowy w sposób prawidłowy?
Biznesowy Diagram przypadków użycia Cykl życia BPU
Diagram przypadków użycia Aktor Z każdym modelowanym systemem biznesowym komunikują się związani z nim aktorzy. Aktor (ang. Actor) to spójny zbiór ról odgrywanych przez użytkowników biznesowego przypadku użycia w czasie interakcji z tym przypadkiem użycia.
Aktorzy mogą byd osobowi lub nieosobowi: Rolę aktora osobowego może pełnid: osoba, zespół, dział, instytucja, organizacja, zrzeszenie. Nazwy aktorów osobowych często pokrywają się z nazwami stanowisk pełnionych w organizacji, projekcie czy przedsięwzięciu. Aktorami nieosobowymi są: systemy zewnętrzne, Urządzenia, czas
Przykłady aktorów zgodnie ze standardem UML 2.3 uc BDPU Konsultant System rezerwacji miej sc hotelow ych Dział sprzedaży Bank hipoteczny Nazwę aktora wyraża się rzeczownikiem lub określeniem rzeczownikowym w liczbie pojedynczej. Aktor może użytkowad jeden lub więcej BPU w danym procesie biznesowym, natomiast BPU może byd użytkowany przez jednego bądź wielu aktorów.
Podsumowując: Aktor nie jest częścią systemu Reprezentuje rolę w jaką może wcielid się użytkownik Może reprezentowad człowieka, urządzenie bądź inny system
Diagram przypadków użycia Związek Każdy aktor umieszczony w BDPU powinien byd bezpośrednio powiązany z co najmniej jednym przypadkiem użycia Każdy BPU powinien byd użytkowany przez co najmniej jednego aktora Związek (ang. relationship) stanowi semantyczne powiązanie pomiędzy elementami modelu
Do łączenia diagramów z aktorami najczęściej stosuje się powiązania poprzez asocjację. Poniższy rysunku pokazano tego typu powiązania uc BDPU Zweryfikuj wiarygodność pałtności Realizuj w ycieczkę System obsługi kart kredytow ych Klient Wysłuchaj w ykład Student
Bardzo często jest to asocjacja skierowana, która wskazuje, kto inicjuje usługę. Taki typ Asocjacji pokazano na poniższym rysunku. uc BDPU Zapisz się na wykład Student Student - inicjator usługi Element inicjujący (Student) zna element inicjowany (Wykład) Element inicjowany (Wykład) nie na elementu inicjującego (Studenta) Zatem: Student wie o możliwości zapisania się na wykład natomiast rejestracja na wykład nic nie wie o istnieniu Studenta.
Diagram przypadków użycia Związek zawierania Zawieranie (<<include>>) powiązanie pomiędzy biznesowym przypadkiem zawierającym tj. bazowym przypadkiem użycia, a przypadkiem zawieranym Związek zawierania umożliwia uniknięcie sytuacji, w której ta sama funkcjonalnośd będzie opisywana wielokrotnie
Zawierany przypadek użycia stanowi tzw. blok wielokrotnego użycia, który wskazuje tę częśd rozwiązania, do której można będzie odwoład się wielokrotnie. Związek zawierania skierowany jest grotem w stronę zawieranego przypadku użycia uc BDPU Bazowy przypadek użycia «include» Zawierany przypadek użycia Dokonaj rezerw acj i «include» Sprawdz listę dostępnych pokoi
uc BDPU Dokonaj rezerw acj i «include» Sprawdz listę dostępnych pokoi Dokonanie rezerwacji pociąga za sobą koniecznośd zweryfikowania dostępności pokoi Po wykonaniu przypadku "Sprawdź listę dostępnych pokoi" następuje wykonanie funkcjonalności przypadku "Dokonaj rezerwacji". "Sprawdź listę dostępnych pokoi" może byd wykorzystywany przez inne przypadki zawierające, które go przywołują.
Diagram przypadków użycia Związek rozszerzania Rozszerzanie (<<extend>>) powiązanie pomiędzy rozszerzanym biznesowym przypadkiem użycia tj. bazowym przypadkiem użycia, a przypadkiem rozszerzającym Związek rozszerzania ma charakter opcjonalny Tworzenie zależności rozszerzania ma uzasadnienie, o ile funkcjonalnośd przypadku bazowego ma zostad uzupełniona o kilka dodatkowych kroków
Przykład uc BDPU Bazowy przypadek użycia «extend» Rozszerzający przypadek użycia Sprawdz listę dostępnych pokoi «extend» Zarządzaj pokoj ami
Diagram przypadków użycia Uogólnienia Uogólnienie to związek o charakterze taksonomicznym pomiędzy klasyfikatorem ogólnym a specjalizowanym. Uogólnienie może dotyczyd: Aktorów Biznesowych przypadków użycia
Za pomocą związku uogólnienia można wyrazid zależności o znacznie wyższym stopniu złożoności poprzez wskazanie dalszych elementów dziedziczących uc BDPU System obsługi płatności gotów kow ych System obsługi płatności System obsługi płatności bezgotów kow ych Prowadzi to do powstania struktury hierarchicznej. System obsługi kart kredytow ych System rejestracji przelew ów
Diagram przypadków użycia Dekompozycja funkcjonalna Dzieli problem (system biznesowy) na mniejsze, niezależne problemy (części) UC: Części współpracują ze sobą w celu dostarczenia pełnej funkcjonalności Często izolacja nie ma sensu NIE są dekompozycją funkcjonalną Opisują w sposób pełny system biznesowy Nie są oderwane od kontekstu
Diagram przypadków użycia Dekompozycja funkcjonalna - przykład Włóż kartę Process Transaction Bank Wprowadź PIN Wybierz konto Wybierz typ transferu Klient Wprowadź kwotę Określ wypłatę Inne Wybierz saldo
Diagram przypadków użycia Dekompozycja funkcjonalna - cechy Cechy Bardzo małe BPU Zbyt dużo BPU BPU bez rezultatu Nazwy niskopoziomowych operacji Operacja + obiekt Funkcja + dane przykład: Włóż kartę Trudności w zrozumieniu modelu Jak poprawid Poszukuj większego kontekstu Po co budujemy ten system biznesowy? Postaw się w roli aktora Co chcesz osiągnąd? Jakie cele spełni ten BPU? Co uzyskasz? Jak wygląda scenariusz tego BPU?
Diagram przypadków użycia Wzorzec opisu Przypadek użycia powinien byd dokładnie opisany. Na opis składają się np.: zdarzenie inicjujące przypadek (dokładnie jedno), lista aktorów biorących udział w realizacji przypadku użycia, stan systemu przed i po wykonaniu przypadku (warunki początkowe i warunki zakooczenia), specyfikacja komunikatów i danych wymienianych z aktorami, główny scenariusz przebiegu przypadku, scenariusze poboczne, sytuacje wyjątkowe.
Diagram przypadków użycia Biznesowe przypadki użycia a instrukcja obsługi Istnieje ścisły związek między systemowymi przypadkami użycia a instrukcją obsługi systemu. Analiza wymagao jest bowiem, tak na dobrą sprawę, pisaniem takiej instrukcji. Dobrze określone przypadki użycia stanowią tytuły rozdziałów (czy podrozdziałów) podręcznika użytkownika. Opis przypadku użycia stanowi treśd takich rozdziałów. Dobrą analogią jest pisanie scenariuszy filmowych dla określonych aktorów (ról). Rejestracja wypożyczenia Dokonanie rezerwacji Sprawdzenie dostępności Instrukcja Obsługi 1. Rejestracja wypożyczenia (tu opis jak krok po kroku dokonad rejestracji) 2. Dokonanie rezerwacji (tu opis jak krok po kroku dokonad rezerwacji) 3. Sprawdzenie dostępności (tu opis jak krok po kroku sprawdzid dostępnośd)
Nazwa Numer: Twórca: Poziom ważności: Typ przypadku użycia: Aktorzy: Krótki opis: Warunki wstępne: Warunki koocowe: Główny przepływ zdarzeo: Alternatywne przepływy zdarzeo Pełna nazwa przypadku użycia Numer identyfikacyjny przypadku użycia Dane twórcy przypadku użycia (imię, nazwisko, stanowisko) Określenie poziomu ważności przypadku z perspektywy użytkownika Określenie typu przypadku użycia z punktu widzenia jego złożoności oraz ważności dla zaspokojenia potrzeb użytkownika, np.: Ogólny / szczegółowy / niezbędny / istotny / przeciętnie istotny / mało istotny Lista aktorów będących w związku z przypadkiem użycia Krótka, ogólna charakterystyka przypadku użycia Charakterystyka koniecznych warunków inicjujących przypadek Charakterystyka stanu systemu po realizacji przypadku użycia Wypunktowana i scharakteryzowana lista przepływów zdarzeo zachodzących podczas realizacji przypadku użycia; scenariusz główny Wypunktowana i scharakteryzowana lista możliwych, alternatywnych przepływów zdarzeo przypadku użycia
Perspektywy System biznesowy możemy analizowad biorąc pod uwagę różne punkty widzenia (różne perspektywy). Powszechnie stosuje się dwie perspektywy: Perspektywa Wewnętrzna Zewnętrzna
Perspektywa zewnętrzna. Patrząc na system biznesowy z perspektywy zewnętrznej wcielamy się w rolę klienta, partnera, dostawcy lub innego systemu biznesowego. W perspektywie tej interesują nas tylko i wyłącznie obiekty zewnętrzne w stosunku do modelowanego systemu biznesowego. Dzięki perspektywie tej uzyskujemy opis środowiska biznesowego w jaki funkcjonuje przedsiębiorstwo. Przedsiębiorstwo postrzegane jest jako czarna skrzynka z którą komunikują się obiekty zewnętrzne. W perspektywie zewnętrznej stosujemy następujące diagramy: biznesowy diagram przypadków użycia, biznesowy diagram czynności, biznesowy diagram sekwencji. Perspektywa wewnętrzna. W perspektywie tej patrzymy na system od wewnątrz. Zatem widzimy w niej pracowników oraz narzędzia biorące udział w zaspokajaniu potrzeb otoczenia. Zatem interesuje nas obsługa procesów biznesowych. Perspektywa wewnętrzna w warunkach wolnorynkowych ukryta jest przed światem zewnętrznym. W perspektywie wewnętrznej stosujemy następujące diagramy: biznesowy diagram czynności, biznesowy diagram pakietów, biznesowy diagram klas, biznesowy diagram czynności
W zależności od perspektywy mamy: Aktora biznesowego Aktor biznesowy pełni on role użytkownika, który działa w otoczeniu modelowanego systemu biznesowego. Aktor biznesowy istnieje w perspektywie zewnętrznej Pracownika biznesowego. Pracownik biznesowy istnieje w ramach modelowanej organizacji. Pracownikiem biznesowym może byd: pracownik lub system. Pracownik biznesowy istnieje w perspektywie wewnętrznej.
Asocjacja Uogólnienie
Zawieranie <<include>> Rozszerzanie <<extend>>
Konstruowanie BDPU W celu poprawnego skonstruowania biznesowego diagramu przypadków użycia należy postępowad zgodnie z zaleceniami podanymi poniżej: Krok 1: Zgromadzenie odpowiedniej liczby źródeł informacji. W kroku tym należy dobrad właściwych dostawców wiedzy, którzy wraz z analitykiem będą dalej współpracowali aż do zakooczeniu etapu modelowania procesów biznesowych
Krok 2: Identyfikacja aktorów biznesowych. W kroku tym powinniśmy zidentyfikowad aktorów biznesowych w przypadku perspektywy zewnętrznej oraz pracowników biznesowych w przypadku perspektywy wewnętrznej. Zidentyfikowani aktorzy będą wykorzystywani na kolejnych etapach pracy nad biznesowym diagramem przypadków użycia. Należy zawsze pamiętad iż lista zidentyfikowanych aktorów na kolejnych etapach może się zmieniad (aktorzy mogą byd redukowani).
Krok 3: Identyfikacja biznesowych przypadków użycia. W kroku tym poszukujemy i identyfikujemy potencjalne biznesowe przypadki użycia. Praktyka pokazuje, ze najlepszym sposobem identyfikacji biznesowych przypadków użycia jest technika obserwacji. W wyniku obserwacji powinna powstad lista aktywności, które stanowią punkt wejścia do budowy biznesowych przypadków użycia.
Krok 4: Łączenie biznesowych przypadków użycia Przyporządkowujemy biznesowe przypadki użycia do odpowiednich aktorów biznesowych w przypadku perspektywy zewnętrznej oraz do pracowników biznesowych w przypadku perspektywy wewnętrznej. W kroku tym tworzymy pierwszy szkic biznesowego diagramu przypadków użycia. W oparciu o powstały szkic prowadzimy dalsze prace, które doprowadza do udoskonalenia biznesowego diagramu przypadków użycia.
Krok 5: Udokumentowanie biznesowych przypadków użycia W kolejnym kroku dokonujemy udokumentowania biznesowych przypadków użycia. Dokumentacja biznesowych przypadków użycia stanowi bardzo ważny element, który jest podstawa budowania kolejnych biznesowych diagramów: czynności i sekwencji. Udokumentowanie może odbywad się w postaci tekstu bądź w formie bardziej sformalizowanej.