Modelowanie biznesowe

Modelowanie analityczne

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

.

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).

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

.

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. Ponieważ

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.

Ważny a niedoceniany…

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.

Ważny a niedoceniany…

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

.

Ważny a niedoceniany…

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ć.

Ważny a niedoceniany…

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.

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: 

o model biznesowy,
o mapa procesów biznesowych, 
o 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.

MB w metodyce RUP

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ć:

o modelowanie systemowe — ukierunkowane na

tworzenie systemu informatycznego, jego
oprogramowania oraz infrastruktury sprzętowej;

o modelowanie biznesowe.

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.

Modelowanie biznesowe w
procesie tworzenia systemu

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

:

o biznesowe diagramy przypadków użycia,
o biznesowe diagramy klas,
o biznesowe diagramy czynności,
o biznesowe diagramy sekwencji,
o 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

Studen
t

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

Recepcjonistk
a

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
scharakteryzowa
nia 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.

B

iz

n

e

s

o

w

y

d

ia

g

ra

m

s

e

k

w

e

n

c

ji

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

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.

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).

Biznesowy diagram klas
systemu księgarni z
pracownikami biznesowymi

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:

o

normach IDEF (Integration DEFinition

language);

o

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:
o

wejście: rozumiane jako element

wykorzystywany w procesie

;

o sterowanie: rozumiane jako wymuszanie

określonych operacji

procesów

;

o

wyjście: rozumiane jako

wynik procesu

;

o

mechanizm: operacja jaka powinna być dokonywana przez proces

lecz

nie wchodząca do procesu.

PROCES

A0

wejście

wyjście

sterowan
ie

mechaniz
m

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

perspekty
wy

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

Finans
e

Proces
y

Misja
firmy

Diagram

konteksto

wy

A0

Diagram

dekompozyc

ji

A1

Diagram

dekompozyc

ji

A1

Diagram

dekompozyc

ji

A1

Diagram

dekompozycj

i

B1

Diagram

dekompozycj

i

B1

Diagram

dekompozycj

i

B1

Diagram

dekompozycj

i

B1

Diagram

dekompozy

cji

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żą:

o diagramy modelowania analitycznego,
o 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ą:

o klasy analityczne,
o aktorzy,
o 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 Pocztą.

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