MiASI. Modelowanie systemów biznesowych. Piotr Fulmański. 7 stycznia 2010. Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska



Podobne dokumenty
MiASI. Modele, perspektywy, diagramy UML. Piotr Fulmański. 7 grudnia Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska

Podstawy programowania III WYKŁAD 4

Podstawy inżynierii oprogramowania

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu

INŻYNIERIA OPROGRAMOWANIA. laboratorium

UML w Visual Studio. Michał Ciećwierz

Diagramy czynności Na podstawie UML 2.0 Tutorial

Wprowadzenie do UML, przykład użycia kolizja

koniec punkt zatrzymania przepływów sterowania na diagramie czynności

Modelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych

UML. dr inż. Marcin Pietroo

Spis treúci. 1. Wprowadzenie... 13

Diagramy UML, przykład problemu kolizji

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON

Modelowanie. Wykład 1: Wprowadzenie do Modelowania i języka UML. Anna Kulig

Wykorzystanie standardów serii ISO oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)

Modelowanie obiektowe - Ćw. 3.

Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska

UML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne.

NIFIED M L ODELLING ANGUAGE. Diagramy czynności

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

Analiza procesów: notacja UML, modele przypadków użycia, Rich Picture

MiASI. Modelowanie integracji systemów. Piotr Fulma«ski. 26 stycznia Wydziaª Matematyki i Informatyki, Uniwersytet Šódzki, Polska

Naśladować Rynek Użytkownik Pomysł Koncepcja Ocena. Kim są docelowi użytkownicy koncepcji?

Wykład 1 Inżynieria Oprogramowania

Unified Modeling Language

Graficzna notacja procesów biznesowych BPMN. Porównanie z notacja UML. Jakub Morkis, Piotr Chmielewski

Diagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

Obieg akceptacji kosztów w organizacji

Michał Adamczyk. Język UML

TECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek

SPECYFIKACJA WYMAGAŃ

Język UML w modelowaniu systemów informatycznych

Faza analizy (modelowania) Faza projektowania

1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI

Analiza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji

Partnerzy w biznesie wg Business Model Canvas. Współpraca z partnerami. Wskaźniki jakościowe realizowanych usług.

Opis. Liczba godzin zajęć dydaktycznych z

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Narzędzia CASE dla.net. Łukasz Popiel

Narzędzia Informatyki w biznesie

Zakres wykładu. Podstawy InŜynierii Oprogramowania

Identyfikacja i modelowanie struktur i procesów biologicznych

Piotr Kulicki Katolicki Uniwersytet Lubelski Jana Pawła II Instytut Filozofii Teoretycznej Katedra Podstaw Informatyki

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 5 Ćwiczenia w narzędziu CASE diagram przypadków uŝycia. Materiały dla nauczyciela

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla studenta

Model przypadków użycia - rola diagramów aktywności Część 2 Wykładowca Dr inż. Zofia Kruczkiewicz

UML cz. I. UML cz. I 1/1

Informatyczny system wspomagania reinżynierii procesów gospodarczych (BPR) na przykładzie wykorzystania modelu referencyjnego SAP R3

MiASI. Modelowanie analityczne. Piotr Fulma«ski. 18 stycznia Wydziaª Matematyki i Informatyki, Uniwersytet Šódzki, Polska

Diagram Przepływu Danych - podstawowe bloki składowe i reguły konstrukcji

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 3 Identyfikacja przypadków użycia

Modelowanie diagramów klas w języku UML. Łukasz Gorzel @stud.umk.pl 7 marca 2014

Diagramy przypadków użycia

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

Informatyzacja przedsiębiorstw WYKŁAD

Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD

Inżynieria oprogramowania

Inżynieria oprogramowania Jarosław Kuchta. Modelowanie interakcji

Krzysztof Wawrzyniak Quo vadis BS? Ożarów Mazowiecki, styczeń 2014

Architektura oprogramowania w praktyce. Wydanie II.

Projektowanie systemów informacyjnych: język UML

Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1

Inżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia

ZARZĄDZANIU. Wykład VI. dr Jan Kazimirski

Uniwersytet w Białymstoku Wydział Ekonomiczno-Informatyczny w Wilnie SYLLABUS na rok akademicki 2012/2013

Modelowanie i analiza systemów informatycznych

Procesowa specyfikacja systemów IT

Spis treści. Analiza i modelowanie_nowicki, Chomiak_Księga1.indb :03:08

Techniki i rozwiązania IT w optymalizacji procesów

Diagramy czynności tworzenie modelu przypadków użycia Wykład 2

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 6 Wskazówki i sugestie

Diagram przypadków użycia

Podyplomowe Studium Informatyki w Bizniesie Wydział Matematyki i Informatyki, Uniwersytet Łódzki specjalność: Tworzenie aplikacji w środowisku Oracle

Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP

Diagramy przypadków użycia. WYKŁAD Piotr Ciskowski

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Diagramy przypadków użycia

UML. zastosowanie i projektowanie w języku UML

Podstawy języka UML UML

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

Modelowanie i analiza systemów informatycznych Spis treści

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Przypadki użycia (use cases) Po co są przypadki użycia? Próby definicji Podstawowe pojęcia Notacje Relacje Dokumentacja Kroki metody Przykłady

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 1 Wprowadzenie do narzędzia CASE. Materiały dla nauczyciela

Algorytm. Krótka historia algorytmów

Automatyzacja procesu i zarządzanie zespołem

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Inżyniera wymagań

Diagramy interakcji. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania

Tworzenie programów równoległych cd. Krzysztof Banaś Obliczenia równoległe 1

Bazy danych 2. dr inż. Tadeusz Jeleniewski

Systemy informatyczne. Modelowanie danych systemów informatycznych

Identyfikacja i modelowanie struktur i procesów biologicznych

Transkrypt:

MiASI Modelowanie systemów biznesowych Piotr Fulmański Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska 7 stycznia 2010

Spis treści 1 Czym jest system biznesowy? Po co model bizensowy? Czym jest proces biznesowy? Czym jest system biznesowy? 2 Analiza systemu biznesowego Poziomy analizy Perspektywa zewnętrzna Perspektywa wewnętrzna

Po co model bizensowy? Po co model bizensowy? Komercyjne systemy informatyczne są wykorzystywane głównie do obsługi systemów bizensowych. W konsekwencji, tworzenie i integracja systemów informatycznych są uzależnione od perspektyw systemów biznesowych. Za fundament systemu informatycznego służy model systemu biznesowego oraz jego procesów.

Po co model bizensowy? Po co model bizensowy? Komercyjne systemy informatyczne są wykorzystywane głównie do obsługi systemów bizensowych. W konsekwencji, tworzenie i integracja systemów informatycznych są uzależnione od perspektyw systemów biznesowych. Za fundament systemu informatycznego służy model systemu biznesowego oraz jego procesów.

Po co model bizensowy? Po co model bizensowy? Komercyjne systemy informatyczne są wykorzystywane głównie do obsługi systemów bizensowych. W konsekwencji, tworzenie i integracja systemów informatycznych są uzależnione od perspektyw systemów biznesowych. Za fundament systemu informatycznego służy model systemu biznesowego oraz jego procesów.

Po co model bizensowy? Po co model bizensowy? Komercyjne systemy informatyczne są wykorzystywane głównie do obsługi systemów bizensowych. W konsekwencji, tworzenie i integracja systemów informatycznych są uzależnione od perspektyw systemów biznesowych. Za fundament systemu informatycznego służy model systemu biznesowego oraz jego procesów.

Czym jest proces biznesowy? Czym jest proces biznesowy? (intuicja) Proces biznesowy procedura lub zdarzenie realizowane z myślą o osiągnięciu konkretnego celu. Procesy biznesowe bardzo często realizowane są wieloetapowo. Etapy określane są mianem aktywności. Zwykle aktyności muszą odbywać się w określonej kolejności i mogą być realizowane sekwencyjnie lub równolegle.

Czym jest proces biznesowy? Czym jest proces biznesowy? (intuicja) Proces biznesowy procedura lub zdarzenie realizowane z myślą o osiągnięciu konkretnego celu. Procesy biznesowe bardzo często realizowane są wieloetapowo. Etapy określane są mianem aktywności. Zwykle aktyności muszą odbywać się w określonej kolejności i mogą być realizowane sekwencyjnie lub równolegle.

Czym jest proces biznesowy? Czym jest proces? (definicja według WMC) Proces jest skoordynowanym (równoległym lub sekwencyjnym) zbiorem aktywności wykonywanych z myślą o osiągnięciu wspólnego celu. Tego typu aktywności mogą być manualne oraz (lub) zautomatyzowane. Worklow Reference Model http://www.wfmc.org

Czym jest proces biznesowy? Czym jest proces biznesowy? (definicja według WMC) Proces biznesowy jest formą procesu występującego w ramach struktury organizacyjnej i podporządkowanego osiągnięciu celów biznesowych. Worklow Reference Model http://www.wfmc.org

Czym jest system biznesowy? System biznesowy System biznesowy to połączenie elementów dynamicznych (proces biznesowy) i statycznych (obiekty biznesowe, obiekty informacyjne, struktura organizacyjna). Miejsce UML-a Do modelowania procesów i systemów bizensowych wykorzystujemy UML, gdyż zgodnie z definicją: Unified Modeling Language jest wizualnym językiem służącym do specyfikowania, konstruowania i dokumentowania artefaktów systemu. UML Unified Modeling Language: Infrastructure, Version 2.o, Final Adopted Specifications, wrzesień 2003

Czym jest system biznesowy? System biznesowy System biznesowy to połączenie elementów dynamicznych (proces biznesowy) i statycznych (obiekty biznesowe, obiekty informacyjne, struktura organizacyjna). Miejsce UML-a Do modelowania procesów i systemów bizensowych wykorzystujemy UML, gdyż zgodnie z definicją: Unified Modeling Language jest wizualnym językiem służącym do specyfikowania, konstruowania i dokumentowania artefaktów systemu. UML Unified Modeling Language: Infrastructure, Version 2.o, Final Adopted Specifications, wrzesień 2003

Poziomy analizy Poziomy analizy System biznesowy można analizować biorąc pod uwagę różne punkty widzenia (perspektywy). Najogólniejszy podział związany z perspektywami wyodrębina, dwie perspektywy, tj. perspektywę zewnętrzną, perspektywę wewnętrzną.

Perspektywa zewnętrzna Perspektywa zewnętrzna Najczęściej klient lub partner biznesowy organizacji nie jest zainteresowany szczegółami jej funkcjonowania (np. takimi jak to czy przepływ informacji odbywa się w niej na drodze informatycznej czy też nie, czy też liczba i zawartość używanych formularzy). Dlatego perspektywa zewnętrzna (perspektywa klienta) opisuje interakcję systemu z obiektami zewnętrznymi, takimi jak klienci i partnerzy biznesowi, a system biznesowy jest przez nią interpretowany jak czarna skrzynka.

Perspektywa zewnętrzna Perspektywa zewnętrzna Najczęściej klient lub partner biznesowy organizacji nie jest zainteresowany szczegółami jej funkcjonowania (np. takimi jak to czy przepływ informacji odbywa się w niej na drodze informatycznej czy też nie, czy też liczba i zawartość używanych formularzy). Dlatego perspektywa zewnętrzna (perspektywa klienta) opisuje interakcję systemu z obiektami zewnętrznymi, takimi jak klienci i partnerzy biznesowi, a system biznesowy jest przez nią interpretowany jak czarna skrzynka.

Perspektywa zewnętrzna Perspektywa zewnętrzna Klienic i partnerzy biznesowi są zainteresowani wyłącznie tym, jakie rodzaje towarów lub usług oferuje organizacja i jaki mogą mieć z nich pożytek

Perspektywa zewnętrzna Problem W praktyce okazuje się, że perspektywa zewnętrzna jest trudna do zobrazowania, jeśli model jest opracowywany przez pracowników organizacji, którzy z natury rzeczy są jej wewnętrznymi obserwatorami. Osobie obserwującej system biznesowy od środka, znającej wewnętrzne zależności, trudno jest wczuć się w rolę klienta, który z kolei nie bierze pod uwagę żadnych wewnętrznych powiązań. Dlatego do pracy nad perspektywą zewnętrzną systemu warto zaangażować uczestników systemu o niskim stopiu nasycenia szczegółami dotyczącymi wewnętrznych mechanizmów biznesowych (np. pracowników innych działów lub zewnętrznych konsultantów). W rzeczywistości często spotyka się diagramy zbyt zbliżone w swej szczegółowości do poziomu systemu informatycznego. W efekcie użytkownicy docelowi (biznesowi) nie rozumieją go, co nie pozwala na weryfikację modelu pod kątem poprawności.

Perspektywa zewnętrzna Problem W praktyce okazuje się, że perspektywa zewnętrzna jest trudna do zobrazowania, jeśli model jest opracowywany przez pracowników organizacji, którzy z natury rzeczy są jej wewnętrznymi obserwatorami. Osobie obserwującej system biznesowy od środka, znającej wewnętrzne zależności, trudno jest wczuć się w rolę klienta, który z kolei nie bierze pod uwagę żadnych wewnętrznych powiązań. Dlatego do pracy nad perspektywą zewnętrzną systemu warto zaangażować uczestników systemu o niskim stopiu nasycenia szczegółami dotyczącymi wewnętrznych mechanizmów biznesowych (np. pracowników innych działów lub zewnętrznych konsultantów). W rzeczywistości często spotyka się diagramy zbyt zbliżone w swej szczegółowości do poziomu systemu informatycznego. W efekcie użytkownicy docelowi (biznesowi) nie rozumieją go, co nie pozwala na weryfikację modelu pod kątem poprawności.

Perspektywa zewnętrzna Problem W praktyce okazuje się, że perspektywa zewnętrzna jest trudna do zobrazowania, jeśli model jest opracowywany przez pracowników organizacji, którzy z natury rzeczy są jej wewnętrznymi obserwatorami. Osobie obserwującej system biznesowy od środka, znającej wewnętrzne zależności, trudno jest wczuć się w rolę klienta, który z kolei nie bierze pod uwagę żadnych wewnętrznych powiązań. Dlatego do pracy nad perspektywą zewnętrzną systemu warto zaangażować uczestników systemu o niskim stopiu nasycenia szczegółami dotyczącymi wewnętrznych mechanizmów biznesowych (np. pracowników innych działów lub zewnętrznych konsultantów). W rzeczywistości często spotyka się diagramy zbyt zbliżone w swej szczegółowości do poziomu systemu informatycznego. W efekcie użytkownicy docelowi (biznesowi) nie rozumieją go, co nie pozwala na weryfikację modelu pod kątem poprawności.

Perspektywa zewnętrzna Problem W praktyce okazuje się, że perspektywa zewnętrzna jest trudna do zobrazowania, jeśli model jest opracowywany przez pracowników organizacji, którzy z natury rzeczy są jej wewnętrznymi obserwatorami. Osobie obserwującej system biznesowy od środka, znającej wewnętrzne zależności, trudno jest wczuć się w rolę klienta, który z kolei nie bierze pod uwagę żadnych wewnętrznych powiązań. Dlatego do pracy nad perspektywą zewnętrzną systemu warto zaangażować uczestników systemu o niskim stopiu nasycenia szczegółami dotyczącymi wewnętrznych mechanizmów biznesowych (np. pracowników innych działów lub zewnętrznych konsultantów). W rzeczywistości często spotyka się diagramy zbyt zbliżone w swej szczegółowości do poziomu systemu informatycznego. W efekcie użytkownicy docelowi (biznesowi) nie rozumieją go, co nie pozwala na weryfikację modelu pod kątem poprawności.

Elementy perspektywy zewnętrznej Diagramy przypadków użycia Przedstawia aktorów, biznesowe przypadki użycia oraz ich wzajemne zwiazki. Nie opisują procedur. Nie zawierają informacji o chronologi podejmowanych działań. Diagramy tego typu dają dobry przegląd funkcji systemu biznesowego a mówiąc w skrócie dają informację o tym kto i co może zrobić.

Elementy perspektywy zewnętrznej Diagramy przypadków użycia Przedstawia aktorów, biznesowe przypadki użycia oraz ich wzajemne zwiazki. Nie opisują procedur. Nie zawierają informacji o chronologi podejmowanych działań. Diagramy tego typu dają dobry przegląd funkcji systemu biznesowego a mówiąc w skrócie dają informację o tym kto i co może zrobić.

Elementy perspektywy zewnętrznej Diagramy przypadków użycia Przedstawia aktorów, biznesowe przypadki użycia oraz ich wzajemne zwiazki. Nie opisują procedur. Nie zawierają informacji o chronologi podejmowanych działań. Diagramy tego typu dają dobry przegląd funkcji systemu biznesowego a mówiąc w skrócie dają informację o tym kto i co może zrobić.

Elementy perspektywy zewnętrznej Diagramy przypadków użycia Przedstawia aktorów, biznesowe przypadki użycia oraz ich wzajemne zwiazki. Nie opisują procedur. Nie zawierają informacji o chronologi podejmowanych działań. Diagramy tego typu dają dobry przegląd funkcji systemu biznesowego a mówiąc w skrócie dają informację o tym kto i co może zrobić.

Elementy perspektywy zewnętrznej Diagramy przypadków użycia Przedstawia aktorów, biznesowe przypadki użycia oraz ich wzajemne zwiazki. Nie opisują procedur. Nie zawierają informacji o chronologi podejmowanych działań. Diagramy tego typu dają dobry przegląd funkcji systemu biznesowego a mówiąc w skrócie dają informację o tym kto i co może zrobić.

Elementy perspektywy zewnętrznej Diagramy aktywności Opisują procedury (procedury biznesowe obowiązujące w systemie). Podmiotami tych diagramów są interakcje pomiędzy aktorami a systemem biznesowym. Są szczególnie użyteczne do ilustrowania sekwencji zdarzeń (w sensie kolejności), alternatyw i zdarzeń odbywających się równolegle. Na bazie diagramów aktywności zewnętrzni uczestnicy mogą zidentyfikować sposoby interakcji z systemem biznesowym.

Elementy perspektywy zewnętrznej Diagramy aktywności Opisują procedury (procedury biznesowe obowiązujące w systemie). Podmiotami tych diagramów są interakcje pomiędzy aktorami a systemem biznesowym. Są szczególnie użyteczne do ilustrowania sekwencji zdarzeń (w sensie kolejności), alternatyw i zdarzeń odbywających się równolegle. Na bazie diagramów aktywności zewnętrzni uczestnicy mogą zidentyfikować sposoby interakcji z systemem biznesowym.

Elementy perspektywy zewnętrznej Diagramy aktywności Opisują procedury (procedury biznesowe obowiązujące w systemie). Podmiotami tych diagramów są interakcje pomiędzy aktorami a systemem biznesowym. Są szczególnie użyteczne do ilustrowania sekwencji zdarzeń (w sensie kolejności), alternatyw i zdarzeń odbywających się równolegle. Na bazie diagramów aktywności zewnętrzni uczestnicy mogą zidentyfikować sposoby interakcji z systemem biznesowym.

Elementy perspektywy zewnętrznej Diagramy aktywności Opisują procedury (procedury biznesowe obowiązujące w systemie). Podmiotami tych diagramów są interakcje pomiędzy aktorami a systemem biznesowym. Są szczególnie użyteczne do ilustrowania sekwencji zdarzeń (w sensie kolejności), alternatyw i zdarzeń odbywających się równolegle. Na bazie diagramów aktywności zewnętrzni uczestnicy mogą zidentyfikować sposoby interakcji z systemem biznesowym.

Elementy perspektywy zewnętrznej Diagramy aktywności Opisują procedury (procedury biznesowe obowiązujące w systemie). Podmiotami tych diagramów są interakcje pomiędzy aktorami a systemem biznesowym. Są szczególnie użyteczne do ilustrowania sekwencji zdarzeń (w sensie kolejności), alternatyw i zdarzeń odbywających się równolegle. Na bazie diagramów aktywności zewnętrzni uczestnicy mogą zidentyfikować sposoby interakcji z systemem biznesowym.

Elementy perspektywy zewnętrznej Diagramy sekwencji Opisują chronologiczny przebieg interakcji. Skupiają się na informacji przekazywanej pomiędzy stronami interakcji. Nie opisują poszczególych zdarzeń wraz z ich rozgałęzieniami i zrównolegleniem operacji.

Elementy perspektywy zewnętrznej Diagramy sekwencji Opisują chronologiczny przebieg interakcji. Skupiają się na informacji przekazywanej pomiędzy stronami interakcji. Nie opisują poszczególych zdarzeń wraz z ich rozgałęzieniami i zrównolegleniem operacji.

Elementy perspektywy zewnętrznej Diagramy sekwencji Opisują chronologiczny przebieg interakcji. Skupiają się na informacji przekazywanej pomiędzy stronami interakcji. Nie opisują poszczególych zdarzeń wraz z ich rozgałęzieniami i zrównolegleniem operacji.

Elementy perspektywy zewnętrznej Diagramy sekwencji Opisują chronologiczny przebieg interakcji. Skupiają się na informacji przekazywanej pomiędzy stronami interakcji. Nie opisują poszczególych zdarzeń wraz z ich rozgałęzieniami i zrównolegleniem operacji.

Elementy perspektywy wewnętrznej Diagramy pakietów Opisują jednostki organizacyjne.

Elementy perspektywy wewnętrznej Diagramy klas Opisują powiązania i związki między współpracownikami i obiektami biznesowymi.

Elementy perspektywy wewnętrznej Diagramy aktywności Opisują procesy biznesowe w ramach systemu biznesowego. Obrazują wewnętrzne procesy systemu biznesowego.

Elementy perspektywy wewnętrznej Diagramy aktywności Opisują procesy biznesowe w ramach systemu biznesowego. Obrazują wewnętrzne procesy systemu biznesowego.