Modelowanie biznesowe Modelowanie analityczne
Halina Tańska Jolanta Sala
Istota modelowania
• Modelowanie biznesowe (z ang. Business Modeling) to praktyka stosowana z powodzeniem przez wiele
współczesnych przedsiębiorstw.
– Służy do opisu wszystkiego, co składa się na daną organizację (dokumentacji, procedur i procesów biznesowych).
– Dzięki modelom biznesowym można odpowiedzieć na 6 kluczowych pytań dla każdej organizacji biznesowej: co, jak, dlaczego, kto, gdzie i kiedy.
• W procesie wytwarzania oprogramowania jest pierwszym etapem z jakim spotykają się twórcy oprogramowania,
gdyż model biznesowy to opis rzeczywistej firmy lub instytucji.
1/3
Istota modelowania
• Modelowanie biznesowe pozwoli zrozumieć czym zajmuje się dane przedsiębiorstwo, czemu akurat tym i czemu
akurat w taki sposób.
– Ponadto można stwierdzić za co odpowiedzialne są konkretne osoby w analizowanej firmie, jaka jest ich
rola, czy też zakres współpracy z innymi pracownikami.
• Zasadniczym celem budowy modelu biznesowego jest
utworzenie takiego obrazu organizacji, który będąc opisem rzeczywistości stanie się podstawą szkieletu aplikacji
(opisem tego szkieletu).
2/3
Istota modelowania
• Modelowanie biznesowe to wgląd w strukturę przedsiębiorstwa i procesy w nim zachodzące.
• Należy dbać o odpowiednią szczegółowość modelu – tak by nie pominąć żadnych ważnych elementów, ale
jednocześnie nie przesłonić istoty działania organizacji nadmiarem szczegółów.
• Priorytetem jest uzyskanie kompletnego, spójnego i wiarygodnego modelu.
3/3
Model firmy
• Model firmy ma w sposób jasny i zrozumiały opisywać firmę, jej cel rynkowy oraz wszelkie jej wewnętrzne i
zewnętrzne zachowania oraz reakcje.
• Jest on niezbędny do przewidywania zachowań firmy, a także do przygotowania jej do wdrożenia systemów
informacyjnych.
• Wdrażając nowy system informacyjny lub usprawniając
działanie starego, trzeba mieć pewność, że „pasuje” on do tego, co się w firmie dzieje.
Ważny a niedoceniany…
• Niestety modelowanie biznesowe przez długi czas było przez przedsiębiorców lekceważone.
• Główne powody to:
– koszty związane z tworzeniem modelu - związane z czasem, który należy poświęcić na stworzenie modelu oraz z aplikacjami wspomagającymi modelowanie
– proces tworzenia takiego modelu jest skomplikowany, zazwyczaj musi w nim uczestniczyć wiele osób, co może prowadzić do konfliktów i nieporozumień
– przy bardzo dużych organizacjach jedynym wyjściem jest czasem zatrudnienie firmy z zewnątrz – co stanowi duże obciążenie finansowe
1/5
Ważny a niedoceniany…
• Główny powód to także:
– niemożność zsynchronizowania modelu
biznesowego z informatycznym – integracja jest niezbędna, jeśli system informatyczny ma wspierać system biznesowy, jednakże takie ich
skonstruowanie, by były spójne i działały efektywnie, jest trudne.
2/5
Ważny a niedoceniany…
• Główny powód to także:
– zbyt szybkie zachodzenie zmian biznesowych – przekonanie, że zanim model organizacji zostanie stworzony, to będzie już nieaktualny, jest błędne, ponieważ właśnie szybkość zmian jest powodem modelowania;
– dzięki zbadaniu obecnego położenia firmy, będzie
można lepiej reagować na zmiany zachodzące w niej i w jej otoczeniu.
3/5
Ważny a niedoceniany…
• Główny powód to także:
– bezcelowość modelowania – myślenie, że skoro firma dobrze prosperuje, to nie potrzebne jest
wspomaganie jej systemem informatycznym, może doprowadzić do sytuacji, w której na skutek szybkich zmian w sektorze jej działań przestanie ona być
konkurencyjna i straci swoją dotychczasową pozycję.
– Posiadanie modelu pozwoli szybciej zareagować na zmiany, jego brak natomiast może dużo kosztować.
4/5
Ważny a niedoceniany…
• Główne powody to także:
– wybór techniki modelowania - z uwagi na ilość dostępnych rozwiązań i trudności z dobraniem odpowiedniej techniki do danej organizacji i jej potrzeb.
– wybór narzędzia modelowania – mnogość narzędzi odstrasza potencjalnych użytkowników, ponieważ
ciężko im przeanalizować każde i wybrać te idealne dla danej organizacji, przykładowo sam język UML oferuje 12 typów diagramów umożliwiających ujęcie zarówno statycznej jak i dynamicznej struktury
modelowanego przedsiębiorstwa.
5/5
Główne powody niedoceniania
modelowania biznesowego i modelu firmy
• Ile powodów omówiliśmy ?
• Powtórzmy:
1. koszty
2. niemożność zsynchronizowania modelu biznesowego z informatycznym
3. zbyt szybkie zachodzenie zmian biznesowych 4. bezcelowość modelowania
5. wybór techniki modelowania 6. wybór narzędzia modelowania
Uwarunkowania
• Koncepcja modelowania biznesowego uległa znaczącemu rozwinięciu w związku z szeregiem rozczarowań związanych z zakończonymi
niepowodzeniem wdrożeniami aplikacji biznesowych, szczególnie dotkliwymi dla użytkowników.
Elementy modelowania biznesowego
• Należy rozróżnić trzy główne elementy modelowania biznesowego organizacji:
– model biznesowy,
– mapa procesów biznesowych,
– mapa przepływu pracy dla poszczególnych procesów.
Model biznesowy
• Model biznesowy określa interakcje z otoczeniem rynkowym.
• Jest to zwięzły opis tego na czym i jak firma zarabia.
• Diagram powinien obrazować kluczowe podmioty na rynku biorące udział w tworzeniu wartości przez firmę, przepływy wartości i przepływy pieniędzy.
Mapa procesów biznesowych
• Mapa procesów biznesowych przedstawia wszystkie funkcje, jakie wewnątrz organizacji są realizowane w celu wytworzenia finalnego produktu.
• Przez proces biznesowy rozumiemy spójny zespół
działań, których celem jest osiągnięcie określonej wartości w postaci produktu.
– Do wytworzenia produktu wymagane są: zasoby, inne produkty lub półprodukty oraz reguły według których tworzony jest produkt.
– Produkt musi dać się opisać i musi być mierzalny.
Mapa przepływu pracy
• Mapa przepływu pracy (procedury) to opisy sposobu realizacji funkcji opisanych przez procesy.
• Procedurami definiuje się np. sposób pracy systemów obiegu dokumentów w firmach.
• Procedury są opisywane za pomocą symboli takich jak czynność, decyzja, dokument, interfejs itp.
Znaczenie modelowania biznesowego
• Modelowanie biznesowe jest sposobem odwzorowywania i dokumentowania procesów biznesowych.
• Zrozumienie istoty procesów biznesowych jest podstawą specyfikacji wymagań oraz analizy i projektowania
systemów informatycznych.
• Wiele metodyk przypisuje temu zagadnieniu wysoki priorytet.
• Modelowanie biznesowe to pierwszy etap iteracyjno- przyrostowego cyklu życia systemu w metodyce RUP.
MB w metodyce RUP
• Modele biznesowe znajdują zastosowanie przede wszystkim w pierwszej fazie cyklu życia RUP, fazie
rozpoczęcia, a w mniejszym zakresie także w kolejnych fazach (opracowaniu, budowie oraz przekształcaniu).
• Opracowany w tych fazach model biznesowy stanowi podstawę przyszłego modelowania systemu za pomocą różnorodnych diagramów UML.
• Biznesowe diagramy stworzone w ramach modelowania biznesowego są transformowane w kolejnych fazach
iteracyjno-przyrostowego cyklu RUP w analityczne lub systemowe diagramy języka UML.
1/4
MB w metodyce RUP
2/4
MB w UML
• Tworzenie modeli biznesowych istotnie przyczynia się do lepszego zrozumienia sposobu funkcjonowania organizacji poprzez precyzyjny opis procesów biznesowych.
• Nawiązując do modelowania języka UML, można wyróżnić:
– modelowanie systemowe — ukierunkowane na tworzenie systemu informatycznego, jego
oprogramowania oraz infrastruktury sprzętowej – modelowanie biznesowe.
3/4
MB w UML
• Zdefiniowane w dyscyplinie modelowania biznesowego procesy biznesowe są w naturalny sposób wspomagane przez system informatyczny, a ich część na pewnym etapie tworzenia systemów informatycznych ulega transformacji w procesy systemowe.
4/4
Modelowanie biznesowe w procesie tworzenia systemu
przykład przykład
Podstawowe pojęcia oraz notacja graficzna modeli
biznesowych w UML
Podstawowe pojęcia
• Model biznesowy jest przedstawiany w postaci
diagramów (tak jak model systemu informatycznego).
• Diagramy biznesowe technicznie odpowiadają diagramom systemowym, więc możliwe jest przystosowanie do potrzeb modelowania biznesowego większości diagramów
wymienionych w specyfikacji języka UML 2.0.
• Ze względu na specyfikę funkcjonowania organizacji największe zastosowanie mają następujące rodzaje diagramów biznesowych:
– biznesowe diagramy przypadków użycia, – biznesowe diagramy klas,
– biznesowe diagramy czynności, – biznesowe diagramy sekwencji, – biznesowe diagramy pakietów.
Kategorie modelowania
• Do prawidłowego modelowania biznesowego trzeba wprowadzić kategorie modelowania (stereotypy
graficzne), które nie są elementami diagramów opisujących oprogramowanie.
Aktor biznesowy (Business Actor)
• Rola pełniona przez użytkownika działającego w otoczeniu
organizacji.
• Rola kogoś lub czegoś, jaka występuje w interakcji z
organizacją.
Klient Student
Pracownik biznesowy
• Funkcjonujący w ramach organizacji pracownik lub system, pełniący określoną rolę lub zestaw ról wewnątrz procesu biznesowego.
• Współpracuje z innymi
pracownikami biznesowymi i wykonuje działania oparte na obiektach biznesowych klas przechowujących.
Kasjer
Recepcjonistka
Biznesowa klasa przechowująca
• Fizycznie istniejący byt
użytkowany i przetwarzany przez pracowników
biznesowych oraz
pracowników kontaktu.
• Operacje wykonywane na biznesowych klasach i
obiektach przechowujących obejmują dostęp, aktualizację, tworzenie, monitorowanie oraz kasowanie.
Pracownik kontaktu
• Pracownik biznesowy obsługujący proces
biznesowy i jednocześnie będący w bezpośredniej interakcji z aktorami
biznesowymi.
• Pracownik kontaktu nie może być systemem.
Biznesowy przypadek użycia
• Proces biznesowy,
dostarczający wyników
istotnych z punktu widzenia aktora biznesowego.
• Dostarcza aktorowi biznesowemu rezultat
działania, który powstał w wyniku sekwencji działań biznesowych.
Współdziałanie biznesowe
• Zestaw diagramów
przedstawiających elementy organizacji wspomagające proces biznesowy, takie jak pracownicy biznesowi czy biznesowe klasy lub obiekty przechowujące.
Pakiet biznesowy (Business System)
• Zawiera role (funkcje) i zasoby (byty) wykonujące wspólny cel oraz definiuje zakres działań, w wyniku których cel może być osiągnięty.
Jednostka organizacyjna
• Grupa pracowników
biznesowych, jednostek
przechowujących, związków między nimi, współdziałań biznesowych i innych
składników organizacji.
Czynność biznesowa
• Określone zachowanie złożone z logicznie
uporządkowanych ciągów podczynności, akcji oraz obiektów w celu wykonania pewnego procesu
biznesowego.
Modelowanie biznesowe na
przykładzie systemu księgarni
• DYNAMICZNE ASPEKTY SYSTEMU
MODELOWANIE KONTEKSTU BIZNESOWEGO
Modelowanie zaczynamy od analizy kontekstu biznesowego w celu zidentyfikowania aktorów biznesowych związanych z funkcjonowaniem księgarni. Są to:
o Klienci: Klient indywidualny oraz Biblioteka, o Wydawca,
o Hurtownia,
o Operator kart kredytowych, o Urząd Skarbowy.
Biznesowy kontekst systemu księgarni
Modelowanie biznesowe na
przykładzie systemu księgarni – cd
BIZNESOWY DIAGRAM PRZYPADKÓW UŻYCIA
Kolejny etap modelowania to poszerzenie kontekstu biznesowego o biznesowe przypadki użycia.
W przypadku księgarni mogą to być:
o dokonywanie zakupu wybranych książek,
o przyjmowanie reklamacji w przypadku produktów wadliwych,
o analiza oferty wydawcy, wykonywana standardowo oraz w przypadku reklamacji na zasadzie wyboru
ekwiwalentu książkowego za wadliwy produkt (zamiast zwrotu gotówki),
o inne niż gotówkowe rozliczanie transakcji zakupu, o okresowe rozliczanie działalności (US).
Biznesowy diagram przypadków użycia systemu księgarni
DOKUMENTACJA BIZNESOWYCH PRZYPADKÓW UŻYCIA
Każdy z tych przypadków musi być udokumentowany. Mogą do tego posłużyć następujące tabele: (Szablon 1 - dla nieskomplikowanych przypadków użycia)
Identyfikator BPU <etykieta, np. BPU1>
Nazwa <zdanie, kilka wyrazów skojarzonych z celem >
Cel <zdanie wyrażające cel PU, wynik, który powinien być osiągnięty>
Aktor | Zdarzenie
inicjujące <aktor rozpoczynający PU lub zdarzenie, które jest powodem rozpoczęcia>
Inni uczestnicy <inni aktorzy oraz „pracownicy widziani z zewnątrz” przy realizacji PU>
Warunek wstępny <stan otoczenia lub organizacji, który warunkuje rozpoczęcie PU (jeśli występuje)>
Opis Przebieg
PU rozpoczyna się kiedy < działanie aktora | zdarzenie | reguła biznesowa >
<Opis przebiegu i reguł w kilku zdaniach >
Warunek końcowy <poprawny stan organizacji po zakończeniu PU (jeśli wart zaznaczenia)>
Dokumenty <wejściowe>
<wyjściowe>
Uwagi
DOKUMENTACJA BIZNESOWYCH PRZYPADKÓW UŻYCIA
Szablon 2 (dla złożonych przypadków użycia – różnica w wierszu opis)
Opis Przebieg podstawowy
1. PU rozpoczyna się kiedy < działanie aktora | zdarzenie | reguła biznesowa >
2.<Aktor | System> <działanie>
...
N. PU kończy się.
Przebiegi alternatywne
<identyfikator> <Nazwa zdarzenia powodującego>
<Opis przebiegu, może być też w krokach>
<Identyfikator> <Nazwa zdarzenia powodującego>
<Opis przebiegu, może być też w krokach>
Przykład:dokumentacja przypadku użycia {Przyjmij reklamację} może wyglądać następująco:
Nazwa przypadku użycia: Przyjmij reklamację
Numer: 3
Twórca: Stanisław Wrycza
Aktorzy: Klient indywidualny, Biblioteka Krótki opis: Przyjęcie produktu do reklamacji
Waruki wstępne: Wymagane dostarczenie produktu oraz dowodu zakupu (paragon lub f-ra) Warunki końcowe: Wydanie nowego produktu lub nieuwzględnienie reklamacji
Główny przepływ zdarzeń
1. Klient zgłasza reklamację i przekazuje pracownikowi obsługi relamacji dowód zakupu (paragon lub fakturę) oraz reklamowany produkt
2. Pracownik obsługi reklamacji weryfikuje dowód zakupu oraz produkt 3. Klient uzasadnia reklamację
4. Pracownik obsługi reklamacji uwzględnia reklamację i przygotowywuje kartę reklamacji dla dostarczonego produktu
5. Klient udostępnia szczegółowe dane do karty reklamacji 6. Pracownik obsługi reklamacji dostarcza nowy produkt 7. Klient odbiera nowy produkt
Alternatywne przepływy danych
2a. Brak dowodu zakupu - odrzucenie przyjęcia reklamacji 2b. Brak produktu - odrzucenie przyjęcia reklamacji
4a. Pracownik obsługi reklamacji nie uwzględnia reklamacji i zwraca klientowi dowód zakupu oraz reklamowany produkt
6a. Brak nowego produktu - wydanie pieniędzy klientowi
Specjalne wymagania Termin dostarczenia nowego produktu klientowi nie może być dłuższy niż 14 dni
Notatki i kwestie
1. Obsługa reklamacji odbywa się zgodnie z procedurą zamieszczoną w dokumencie Procedura reklamacji.pdf 2. Miejsca rozszerzenia
2a. Pozytywne rozpatrzenie reklamacji 2b. Żądanie zwrotu gotówki
Mapa procesów biznesowych
• Biznesowy diagram przypadków użycia może być wykorzystany jako mapa procesów biznesowych związanych z funkcjonowaniem księgarni.
• W tym celu wskazuje się, którzy pracownicy biznesowi uczestniczą w realizacji danego przypadku użycia.
• Należy zauważyć, że pracownicy biznesowi są integralną częścią systemu i współdziałania biznesowego.
Mapa procesów biznesowych funkcjonowania księgarni
Biznesowy diagram czynności
W celu głębszego scharakteryzowania konkretnego
przypadku użycia można posłużyć się biznesowym
diagramem czynności.
Rysunek: Diagram czynności przypadku użycia {Dokonaj zakupu}
Diagramy sekwencji
• Scenariuszom przypadków użycia często towarzyszą stosowne diagramy interakcji.
• Szczególnie często stosowaną techniką ich specyfikowania są diagramy sekwencji.
• Oto diagram sekwencji dla przypadku użycia {Przyjmij reklamację} oparty na jego dokumentacji tabelarycznej.
Biznesowy diagram sekwencji
Statyczne aspekty systemu
• Statyczne aspekty funkcjonowania biznesu
odwzorowywane są na podstawie kategorii pojęciowej - biznesowej klasy przechowującej - przede wszystkim przy wykorzystaniu biznesowych diagramów klas.
Biznesowy diagram klas systemu księgarni
1/4
Biznesowy diagram klas systemu księgarni – dokumenty
• W działalności księgarni kluczowe znaczenie ma Dokument finansowy - kategoria abstrakcyjna, uogólniająca następujące dokumenty:
o Rozliczenie utargu, o Raport strat,
o Dowód zakupu – również abstrakcyjny, bo uogólnia Paragon oraz Fakturę.
• Paragon jest wystawiany dla każdego sprzedanego Produktu. Jeżeli klient wyrazi takie życzenie, wraz z Produktem otrzymuje także
Fakturę. Faktura jest zawsze opracowywana w dwóch egzemplarzach (oryginał i kopia).
• W przypadku reklamowania Produktu sporządza się Kartę reklamacji, której częścią jest Uzasadnienie wniesienia reklamacji przez klienta.
• Na podstawie dokumentu Rozliczenia utargu opracowywana jest Prognoza sprzedaży.
• Stosownie do niej sporządza się Zlecenie zakupu produktów, wysyłane do odpowiedniego wydawcy lub hurtowni książek.
2/4
Biznesowy diagram klas systemu księgarni – pracownicy biznesowi
• Biznesowe diagramy klas mają zastosowanie w tworzeniu ich systemowych odpowiedników oraz przy opracowywaniu modelu analitycznego.
• Analogicznie do biznesowych diagramów przypadków użycia, na biznesowych diagramach klas można zamieścić pracowników
biznesowych odpowiadających za poszczególne klasy przechowujące.
• W systemie księgarni będą to:
o Pracownik magazynu - odpowiedzialny za zaopatrzenie
(biznesowe klasy przechowujące Zlecenie zakupu produktów oraz Produkt);
o Pracownik obsługi klienta - odpowiedzialny za bieżącą obsługę klienta (Produkt);
o Kasjer - odpowiedzialny za przyjmowanie wpłat i wydawanie dowodów zakupu (Dowód zakupu oraz Produkt);
o Kontroler - odpowiedzialny za weryfikowanie finansów firmy (Dokumenty finansowe);
o Pracownik obsługi reklamacji - odpowiedzialny za przyjmowanie reklamacji klientów (Karta reklamacji).
3/4
Biznesowy diagram klas systemu księgarni z pracownikami
biznesowymi
4/4
Diagram pakietów
• Zidentyfikowany przez analityka procesów biznesowych układ jednostek biznesowych, zamieszcza się na
biznesowym diagramie pakietów (odpowiada on systemowemu diagramowi pakietów).
• Biznes księgarni można podzielić na następujące cztery różne działy:
o Dział Sprzedaży, o Kontroling,
o Magazyn,
o Dział Obsługi Reklamacji.
Jednostki organizacyjne księgarni.
Zależności między działami a pracownikami księgarni
• Ponownie jak dla wcześniejszych diagramów można dołączyć
odpowiednich pracowników.
Nie tylko UML…
• Przedsięwzięcia mające na celu standaryzację metod opisu procesów i sposobów modelowania działalności różnych organizacji są prowadzone już od wielu lat.
• Warto wspomnieć o dwóch innych notacjach służących do modelowania biznesowego:
– normach IDEF (Integration DEFinition language);
– notacji BPMN (Business Process Modeling Notation).
Modelowanie procesów - Normy IDEF
• Metodologia ta stanowi rodzinę metod i technik
obejmujących modelowanie danych użytecznych w modelowaniu przedsiębiorstw w aspekcie ich funkcji, przetwarzania informacji procesów charakteryzujących
przepływy pracy w informatyzowanych przedsiębiorstwach.
• Kolejne poszerzenia wykorzystania metod IDEF objęły ich implementacje w projektowaniu systemów
informatycznych.
Modelowanie procesów - Normy IDEF
• IDEF0 (Integration DEFinition language 0) to norma tworzenia przebiegu procesu opracowana przez
departament obrony USA w latach 70.
• Początkowo stosowana do programów komputerowych wspomagających produkcję, później przyjęła się do
modelowania innych organizacji.
• Norma IDEF0 to narzędzie komunikacji za sprawą znormalizowanych symboli graficznych i analizy -
ukazujące czynności do wykonania w celu prawidłowego wymodelowania procesu.
• Norma IDEF0 wspomaga ustalenie słabych i mocnych stron modelowanego systemu.
IDEF0
• IDEF0 stanowi graficzną dokumentację opisu funkcji biznesowych rozumianych jako zbiór wzajemnie zależnych aktywności.
• Tworzone są przez graficzną reprezentację „bloków i przepływów” w
diagramach pokazujących funkcję jako bloki i ich interfejsy wejść i wyjść.
• Tak tworzone bloki są wzajemnie powiązane realizując operacje sterowania i rozpoczynania kolejnych operacji.
• Koncepcja tworzenia diagramów zakłada ich hierarchiczną strukturę:
podstawowe funkcje sukcesywnie uszczegółowiane na niższych poziomach.
• Na reprezentację IDEF0 składa się model kontekstowy i diagramy dekompozycji.
• Podstawową konstrukcję bloku funkcjonalnego – procesu IDEF0 stanowi:
– wejście: rozumiane jako element wykorzystywany w procesie;
– sterowanie: rozumiane jako wymuszanie określonych operacji procesów;
– wyjście: rozumiane jako wynik procesu;
– mechanizm: operacja jaka powinna być dokonywana przez proces lecz nie wchodząca do procesu.
PROCES
A0
wejście wyjście
sterowanie
mechanizm
Rys. Funkcyjny blok IDEF0
IDEF0
W IDEF0 poszczególne funkcje składowe procesu zamieszcza się w prostokątnych ramkach.
o strzałki wchodzące z lewej strony to wejścia funkcji – nakłady materiałowe i informacyjne;
o strzałki wychodzące z prawej strony to wyjście funkcji – jej materialne i niematerialne efekty;
o strzałki wchodzące z góry to mechanizmy sterowania funkcją - np.
wewnętrzna polityka firmy lub czynniki zewnętrzne;
o strzałki wchodzące od dołu to mechanizmy niezbędne do wykonania funkcji – np. narzędzia, wykonawcy.
Modele zbudowane mogą być z wielu funkcji połączonych ze sobą za pomocą strzałek tak, że wyjścia jednej funkcji są wejściami dla innych funkcji.
IDEF0
Zasadą IDEF0 jest procesowe podejście do opisu przedsiębiorstwa.
Zatem podstawą jest założenie, że przedsiębiorstwo jest procesem.
Stąd przykładowy model firmy wygląda następująco:
PROCESY
Biznesowe firmy A0
Wizja firmy
perspektywy
Rys. Przykładowy diagram kontekstowy firmy
Zamówienia produktów Zamówienia usług
Reklamacje Dostawy Zwroty
Informacje marketingowe
Dane zmian strategii Dostawy usług
Firmy kooperujące Reklamacje
Zwroty do dostawców
Klienci
Finanse Procesy Misja
firmy
Diagram kontekstowy
A0
Diagram dekompozycji
A1
Diagram dekompozycji
A1
Diagram dekompozycji
A1
Diagram dekompozycji
B1
Diagram dekompozycji
B1
Diagram dekompozycji
B1
Diagram dekompozycji
B1
Diagram dekompozycji
B1
Rys. Zasady dekompozycji w modelu IDEF0
Modele IDEF0 systemów są tworzone krok po kroku w procedurach nie uwzględniających czasowych sekwencji aktywności (stosowane są inne
techniki). Najwyższy poziom stanowi diagram kontekstowy uszczegóławiany na kolejnych niższych poziomach diagramami dekompozycji.
Rozszerzenia IDEF0
•IDEF1 umożliwia zbudowanie modelu ukazującego strukturę przepływu informacji w systemie.
•IDEF2 ukazuje sposób zbudowania dynamicznego modelu pokazującego zależności czasowe pomiędzy funkcjami.
•IDEF1X to rozwinięcie normy IDEF1 do projektowania relacyjnych baz danych.
•IDEF3 to kompleksowa metoda modelowania procesów obrazująca łańcuch następujących po sobie działań.
Przesłankami jej stworzenia było zapotrzebowanie na zwiększenie wydajności analizy systemów biznesowych, ułatwienie opisu wymagań systemu, wspieranie procesu zarządzania projektami.
Rozszerzenia IDEF0
•IDEF4 projektowanie obiektowe.
•IDEF5 strukturalizacji systemowych.
•IDEF6 projektowania koncepcyjnego.
•IDEF7 modelowania kosztów systemowych
•IDEF8 projektowania interfejsów użytkowników
•IDEF9 identyfikacji związków biznesowych
•IDEF10 modelowania architektur systemowych
•IDEF11 zaawansowanego modelowania informacji
•IDEF12 organizacji modelowania
•IDEF13 projektowania schematów systemowych
•IDEF14 projektowanie sieci komputerowych.
BPMN
Standard przyjęty w 2004 roku z inicjatywy analityków i przedstawicieli firm informatycznych (np. Borland,
Casewise, IBM, IDS Scheer, Popkin) jako kompromis pomiędzy zrozumiałością modeli biznesowych i
wymaganiami modeli implementacji.
BPMN (Business Process Modeling Notation ) jest
graficzną notacją opisującą kroki w procesie biznesowym.
UML a BPMN
UML służy obiektowo zorientowanemu modelowaniu
aplikacji, BPMN procesowo zorientowanemu modelowaniu systemów.
Ponieważ BPMN skupia się na procesach biznesowych (i ich wsparciu przez systemy informatyczne), a UML na
projektowaniu oprogramowania można powiedzieć, że obie notacje się uzupełniają, gdyż pokazują różne punkty
widzenia modelowania systemów.
Fachowcy przypuszczają, że notacja BPMN stanie się kolejnym typem diagramów UML.
Modele w BPMN – składowe diagramu procesów biznesowych
• Zdarzenia – to stany pojawiające się podczas przebiegu procesu biznesowego; mają wpływ na przebieg procesu;
zazwyczaj coś wyzwalają lub są czegoś rezultatem;
wyróżniamy zdarzenia początkowe, pośrednie i końcowe.
• Czynności - to „prace” wykonywane podczas realizacji procesu biznesowego; mogą to być: procesy,
podprocesy, zadania.
• Bramki – służą do sterowania przebiegiem procesu np.
bramki decyzyjne.
• Artefakty - pokazują dodatkowe informacje; nie są bezpośrednio związane z przebiegiem procesu lub informacji; nie są czynnościami; do łączenia z innymi obiektami należy użyć powiązań.
Modele w BPMN – składowe diagramu procesów biznesowych
3 typy połączeń:
• Przebieg procesu – do pokazywania kolejności
wykonywania poszczególnych czynności w procesie.
• Przebieg wiadomości - do pokazywania
przekazywania informacji pomiędzy uczestnikami procesu uprawnionymi do ich wysyłania i odbierania.
• Powiązania - do połączenia informacji i artefaktów z czynnościami, zdarzeniami, bramkami i przebiegami.
• Tor – do pokazania z jaką rolą biznesową związana jest dana czynność,
• Uczestnik.
Przykład modelu w BPMN
Wybrane narzędzia
• Do identyfikacji, analizy i optymalizacji
procesów biznesowych w celu zapewnienia pełnej wiedzy o organizacji.
• System Architect v.9.0 to narzędzie do modelowania procesów biznesowych i
narzędzie programistyczne; wybrane metody modelowania:
– Modelowanie biznesowe (procesów, organizacji, IDEF0/IDEF3);
– UML (diagram przypadków użycia, klas, komponentów).
Modelowanie
analityczne
Znaczenie modelowania analitycznego
• Zainteresowanie językiem UML doprowadziło do powstania nowych diagramów lub rozszerzenia znaczenia już
istniejących.
• Przyczyniają się one do zwiększenia jakości, przejrzystości oraz szczegółowości procesu tworzenia systemów przy
wykorzystaniu języka UML i na podstawie metodyki RUP.
• Do najbardziej znanych i użytkowanych w praktyce technik należą:
– diagramy modelowania analitycznego, – diagramy modelowania biznesowego.
Definicja
• Modelowanie analityczne to technika wspomagająca język UML, która służy do dokumentowania wyników prac analitycznych i wczesnych prac projektowych.
Ojciec sukcesu
• Diagramy modelowania analitycznego wspomagają dyscyplinę analizy i
projektowania; zostały
zaproponowane przez Ivara Jacobsona.
• W praktyce diagramy te umożliwiają przejście od
diagramów przypadków użycia oraz ich scenariuszy do
diagramów klas oraz diagramów interakcji na poziomie
konceptualnym (dotyczącym pojęć) i implementacyjnym.
Ivar Jacobson
Czym zatem są diagramy MA??
• Diagramy modelowania analitycznego stanowią:
– element pośredni i opcjonalny w procesie tworzenia systemu
– minimalizują lukę semantyczną pomiędzy zrozumiałą dla większości odbiorców terminologią przypadków użycia a technicznymi aspektami projektu systemu informatycznego.
Diagramy MA w procesie tworzenia systemu
?
Podstawowe kategorie pojęciowe oraz notacja graficzna
• Konsekwentne posługiwanie się diagramami modelowania analitycznego jako pomocą w specyfikowaniu wymagań opartą na przypadkach użycia zwiększa
prawdopodobieństwo wiernego przeanalizowania i
odzwierciedlenia przyszłej funkcjonalności tworzonego systemu.
• Osiąga się to poprzez analizę scenariuszy danego przypadku użycia.
Model analityczny
• Model analityczny (ang. analysis model), grupujący diagramy analityczne, można traktować jako rodzaj wstępnego projektu. Jego celem jest wspomaganie
identyfikacji klas. Podstawowymi elementami diagramów modelowania analitycznego są:
– klasy analityczne, – aktorzy,
– związki.
Notacja oraz szczegółowa
charakterystyka klas analitycznych
• Diagramy analityczne modelowane są jako diagramy klas z zastosowaniem trzech stereotypowanych klas:
o granicznych (ang. boundary), o sterujących (ang. control),
o przechowujących (ang. entity).
• Podczas analizy scenariuszy przypadku użycia identyfikuje się obiekty analityczne.
• Podczas projektowania systemu ulegają przekształceniu w różne kategorie modelowania właściwe dla poziomu
implementacyjnego, takie jak atrybuty klas, operacje lub same klasy.
• Kategorie modelowania analitycznego w literaturze przedmiotu określane są często mianem obiektów analitycznych.
Klasa graniczna
• Wykorzystywana do modelowania interakcji aktora z systemem.
• Mimo że znajduje się na styku systemu z otoczeniem, jest jego integralną częścią.
• Reprezentuje takie elementy aplikacji jak formatki ekranowe, raporty, strony
internetowe, protokoły komunikacyjne, terminale i różnorodne interfejsy
wykorzystywane przez aktora. Stąd elementy te bywają również nazywane klasami
interfejsowymi.
• Klasa graniczna w praktyce może przybrać następujące postaci:
o interfejsu użytkownika, zapewniającego kontakt z aktorami osobowymi;
o interfejsu systemu, zapewniającego kontakt z aktorami – systemami informatycznymi;
o interfejsu urządzenia, kontaktującego się z urządzeniami spoza systemu.
Klasa sterująca
• Reprezentuje procesy, zawierając logikę aplikacji i określając przetwarzanie informacji.
• Klasy te pośredniczą pomiędzy wszystkimi
rodzajami klas analitycznych, a więc granicznymi, przechowującymi oraz innymi klasami
sterującymi.
• Klasa sterująca umożliwia koordynację,
operowanie na innych klasach i sterowanie nimi.
• Obiekty klas sterujących często istnieją wyłącznie w trakcie wykonywania przypadku użycia.
• Mogą być implementowane na etapie
projektowania zarówno w postaci samodzielnych klas, jak i operacji poszczególnych klas.
Klasa przechowująca
• Reprezentuje dane, które muszą być przechowywane przez dłuższy czas;
przykładem może być zawartość tablic baz danych oraz plików.
• Zazwyczaj związana jest z wieloma przypadkami użycia.
• Nie może samodzielnie inicjować interakcji.
• Klasa przechowująca może być implementowana na etapie
projektowania zarówno w postaci samodzielnej klasy, jak i atrybutów poszczególnych klas.
Aktor i asocjacja
• W trakcie opracowywania diagramów modelowania
analitycznego wykorzystywany jest również symbol aktora zaczerpnięty z diagramów przypadków użycia.
• Poszczególne typy klas są powiązane. Kluczowe
znaczenie odgrywa w tym kontekście związek asocjacji, przy czym asocjacje te mogą być dwukierunkowe lub mieć przypisany kierunek nawigacji uszczegóławiający
specyfikację sposobu przepływu informacji.
Diagram klas analitycznych systemu rozpatrywania podań
Opis diagramu
• Kandydat, wypełnia wszelkie pola zamieszczone na Formatce rejestracji, klikając następnie przycisk zatwierdzający złożenie podania.
• Po zatwierdzeniu sterowanie przejmuje obiekt klasy analitycznej Rejestrowanie danych.
• Udostępnione dane przechowywane są w formie podań.
• Za przygotowanie stosownych danych potrzebnych Decydentowi organizacji, odpowiadają następujące obiekty sterujące: Ocena podania oraz Przygotowanie zestawień syntetycznych.
• Decydent komunikuje się z systemem poprzez obiekt graniczny Interfejs decydenta.
• Fakt przyjęcia Kandydata bądź odmowy jego przyjęcia odnotowywany jest w obiekcie przechowującym Podanie.
• Rezultaty wygenerowane przez obiekt sterujący Przyjmowanie
dostępne są za pośrednictwem obiektu granicznego Lista przyjętych, udostępnionego Kandydatowi.
Zasady wzajemnej korespondencji klas
• Istnieją określone zasady, zaproponowane przez
D.Rosenberga – opisujące wzajemną korespondencję pomiędzy poszczególnymi
rodzajami klas analitycznych i aktorami.
• Zasady te opracowano w odniesieniu do związku asocjacji.
Zasady obowiązujące w diagramach modelowania analitycznego
Proces tworzenia modelu analitycznego
• Tworzenie diagramów modelowania analitycznego poprzedzone jest w ramach iteracyjno przyrostowego procesu RUP modelowaniem ‑
biznesu oraz specyfikacją wymagań tworzonego systemu w postaci systemowych diagramów przypadków użycia.
• Stąd proces ten można podzielić na następujące etapy:
1. wyselekcjonowanie, stosownie do złożoności dziedziny przedmiotowej odpowiednich:
diagramów modelu biznesowego,
diagramów przypadków użycia oraz ich scenariuszy, 2. przeniesienie aktorów z diagramów przypadków użycia na
diagramy analityczne,
3. identyfikację klas analitycznych i określenie ich rodzajów,
4. integrację poszczególnych zidentyfikowanych elementów w formie diagramów analitycznych składających się na model analityczny.
Kluczowe zasady
• W trakcie procesu tworzenia modelu analitycznego obowiązują określone zasady konwersji z modeli
biznesowych i systemowych diagramów przypadków użycia na kategorie diagramów modelowania
analitycznego.
Konwersja kategorii biznesowych na kategorie klas analitycznych
Kluczowe zasady – cd
• Analogicznie, należy zauważyć, że sporządzenie klas analitycznych na podstawie systemowych przypadków użycia nie polega na bezpośredniej zamianie notacji.
• Konwersja systemowego modelu przypadków użycia na modele analityczne obejmuje przekształcenie aktorów w klasy graniczne bądź ich bezpośrednie przeniesienie.
• Natomiast przypadki użycia są przekształcane w
odpowiednie rodzaje klas analitycznych – graniczne, sterujące i przechowujące.
• W dalszych iteracjach RUP klasy analityczne przekształcane są w klasy systemu.
Studium modelu analitycznego - przykład
Rejestrowanie uczestnika aukcji internetowej
Elementy przykładowego diagramu analitycznego
• Diagram analityczny zamieszczony na poprzednim slajdzie jest wysokopoziomową specyfikacją przypadku użycia rejestracji uczestnika na aukcji internetowej. Diagram ten zawiera dwóch aktorów:
o Uczestnika aukcji,
o System Poczty Elektronicznej,
• oraz osiem klas analitycznych:
o Ofertę Aukcji, o Rejestrację, o Formularz,
o Walidację Danych, o Autoryzację,
o Aktywację Sprzedaży, o Bazę Danych,
o Poczta.
Opis diagramu
• Aktor Uczestnik, chcąc uzyskać prawo do aktywnego uczestnictwa w licytacjach oraz wystawiania artykułów na licytację, musi zarejestrować się w systemie aukcji internetowej. Wykorzystuje w tym celu obiekt
klasy granicznej Oferta Aukcji, który uruchamia Formularz rejestracyjny poprzez obiekt klasy sterującej Rejestracja.
• Po wprowadzeniu danych następuje ich walidacja. Za realizację tej operacji odpowiada obiekt sterujący o nazwie Walidacja Danych.
Poprawne dane zostają zapisane do bazy danych reprezentowanej przez obiekt przechowujący Baza Danych.
• Następnie Uczestnik zamierzający uzyskać prawa sprzedającego
loguje się do systemu. Wykorzystuje w tym celu login i hasło uzyskane po wypełnieniu Formularza. Analityczny obiekt sterujący Aktywacja Sprzedaży generuje kod sprzedaży, zapisuje go w obiekcie
przechowującym Baza Danych i wysyła drogą elektroniczną wiadomość do rejestrującego się Uczestnika.
• Wiadomość jest wysyłana przez System Poczty Elektronicznej, który nie jest integralną częścią systemu aukcji internetowej. Pośredniczącą instancją klasy granicznej jest w tym przypadku obiekt graniczny
Poczta. Jest on wyspecjalizowanym modułem pozwalającym na
obsługę elektronicznych wiadomości w systemie aukcji internetowej.
Literatura:
• St. Wrycza, B. Marcinkowski, K. Wyrzykowski, Język UML 2.0 w modelowaniu systemów informatycznych, Helion, Gliwice 2005
• W. Dąbrowski, A. Stasiak, M. Wolski, Modelowanie systemów informatycznych w języku UML 2.1 w praktyce, MIKOM, Warszawa 2007
• L. Grochowski, Rozproszone systemy informatyczne, Dom Wydawniczy ELIPSA, Warszawa 2003
