docBiznesowy Diagram przypadków użycia
download 
Reklamacja Transkrypt
Biznesowy Diagram przypadków użycia
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 kategorie pojęciowe: główne – 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 rezerw acj i 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 Zw eryfikuj w iarygodność pałtności System obsługi kart kredytow ych Realizuj w ycieczkę 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 w ykł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 Bazow y przypadek użycia Dokonaj rezerw acj i «include» Zaw ierany przypadek użycia «include» Spraw dz listę dostępnych pokoi uc BDPU Dokonaj rezerw acj i «include» Spraw dz 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 Bazow y przypadek użycia Spraw dz listę dostępnych pokoi «extend» «extend» Rozszerzaj ący przypadek użycia 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 System obsługi płatności gotów kow ych System obsługi płatności bezgotów kow ych • Prowadzi to do powstania struktury hierarchicznej. System obsługi kart kredytow ych System rej estracj i przelew ów Diagram przypadków użycia Dekompozycja funkcjonalna • Dzieli problem (system biznesowy) na mniejsze, niezależne problemy (części) – Części współpracują ze sobą w celu dostarczenia pełnej funkcjonalności – Często izolacja nie ma sensu • UC: – 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 typ transferu Wybierz konto Klient Wprowadź kwotę Inne Określ wypłatę 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). Instrukcja Obsługi Rejestracja wypożyczenia 1. Rejestracja wypożyczenia (tu opis jak krok po kroku dokonad rejestracji) Dokonanie rezerwacji Sprawdzenie dostępności 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 Pełna nazwa przypadku użycia Numer: Numer identyfikacyjny przypadku użycia Twórca: Dane twórcy przypadku użycia (imię, nazwisko, stanowisko) Poziom ważności: Określenie poziomu ważności przypadku z perspektywy użytkownika Typ przypadku użycia: 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 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 przypadek Warunki koocowe: Charakterystyka stanu systemu po realizacji przypadku użycia Główny przepływ zdarzeo: Wypunktowana i scharakteryzowana lista przepływów zdarzeo zachodzących podczas realizacji przypadku użycia; scenariusz główny Alternatywne przepływy zdarzeo 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.
