Modelowanie biznesowe Modelowanie analityczne Halina Taska Jolanta Sala

Modelowanie biznesowe Modelowanie analityczne Halina Tańska Jolanta Sala

1/3 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.

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

3/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 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.

1/5 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

2/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.

3/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.

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

5/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.

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 iteracyjnoprzyrostowego cyklu życia systemu w metodyce RUP.

1/4 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.

2/4 MB w metodyce RUP

3/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.

4/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.

Modelowanie biznesowe w procesie tworzenia systemu 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. BPU 1> 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: Waruki wstępne: Warunki końcowe: Przyjęcie produktu do reklamacji Wymagane dostarczenie produktu oraz dowodu zakupu (paragon lub f-ra) Wydanie nowego produktu lub nieuwzględnienie reklamacji 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ę Główny przepływ zdarzeń 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 2 a. Brak dowodu zakupu - odrzucenie przyjęcia reklamacji 2 b. Brak produktu - odrzucenie przyjęcia reklamacji Alternatywne przepływy danych 4 a. Pracownik obsługi reklamacji nie uwzględnia reklamacji i zwraca klientowi dowód zakupu oraz reklamowany produkt 6 a. Brak nowego produktu - wydanie pieniędzy klientowi Specjalne wymagania Termin dostarczenia nowego produktu klientowi nie może być dłuższy niż 14 dni 1. Obsługa reklamacji odbywa się zgodnie z procedurą zamieszczoną w dokumencie Procedura reklamacji. pdf Notatki i kwestie 2. Miejsca rozszerzenia 2 a. Pozytywne rozpatrzenie reklamacji 2 b. Żą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 2/4 • 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 3/4 • 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 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 • IDEF 0 (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 IDEF 0 to narzędzie komunikacji za sprawą znormalizowanych symboli graficznych i analizy ukazujące czynności do wykonania w celu prawidłowego wymodelowania procesu. • Norma IDEF 0 wspomaga ustalenie słabych i mocnych stron modelowanego systemu.

IDEF 0 • • • IDEF 0 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ę IDEF 0 składa się model kontekstowy i diagramy dekompozycji. Podstawową konstrukcję bloku funkcjonalnego – procesu IDEF 0 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.

sterowanie wejście wyjście PROCES A 0 mechanizm Rys. Funkcyjny blok IDEF 0

IDEF 0 W IDEF 0 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.

IDEF 0 Zasadą IDEF 0 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:

Misja firmy Wizja firmy Zamówienia produktów Dane zmian strategii Zamówienia usług Dostawy usług Reklamacje PROCESY Biznesowe firmy Dostawy Zwroty A 0 Informacje marketingowe perspektywy Finanse Procesy Klienci Rys. Przykładowy diagram kontekstowy firmy Firmy kooperujące Reklamacje Zwroty do dostawców

Rys. Zasady dekompozycji w modelu IDEF 0 Diagram kontekstowy A 0 Diagram dekompozycji A 1 A 1 Diagram dekompozycji Diagram dekompozycji B 1 B 1 B 1 Modele IDEF 0 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 IDEF 0 • IDEF 1 umożliwia zbudowanie modelu ukazującego strukturę przepływu informacji w systemie. • IDEF 2 ukazuje sposób zbudowania dynamicznego modelu pokazującego zależności czasowe pomiędzy funkcjami. • IDEF 1 X to rozwinięcie normy IDEF 1 do projektowania relacyjnych baz danych. • IDEF 3 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 IDEF 0 • IDEF 4 projektowanie obiektowe. • IDEF 5 strukturalizacji systemowych. • IDEF 6 projektowania koncepcyjnego. • IDEF 7 modelowania kosztów systemowych • IDEF 8 projektowania interfejsów użytkowników • IDEF 9 identyfikacji związków biznesowych • IDEF 10 modelowania architektur systemowych • IDEF 11 zaawansowanego modelowania informacji • IDEF 12 organizacji modelowania • IDEF 13 projektowania schematów systemowych • IDEF 14 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, IDEF 0/IDEF 3); – 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