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

Save this PDF as:
 WORD  PNG  TXT  JPG

Wielkość: px
Rozpocząć pokaz od strony:

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

Transkrypt

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

2 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

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

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

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

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

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

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

9 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

10 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

11 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

12 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

13 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ą.

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

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

16 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MiASI. Modele, perspektywy, diagramy UML. Piotr Fulmański. 7 grudnia 2009. Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska MiASI Modele, perspektywy, diagramy UML Piotr Fulmański Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska 7 grudnia 2009 Spis treści 1 Modele, perspektywy, diagramy Czym jest model? Do czego

Bardziej szczegółowo

Podstawy programowania III WYKŁAD 4

Podstawy programowania III WYKŁAD 4 Podstawy programowania III WYKŁAD 4 Jan Kazimirski 1 Podstawy UML-a 2 UML UML Unified Modeling Language formalny język modelowania systemu informatycznego. Aktualna wersja 2.3 Stosuje paradygmat obiektowy.

Bardziej szczegółowo

Podstawy inżynierii oprogramowania

Podstawy inżynierii oprogramowania Podstawy inżynierii oprogramowania Modelowanie. Podstawy notacji UML Aleksander Lamża ZKSB Instytut Informatyki Uniwersytet Śląski w Katowicach aleksander.lamza@us.edu.pl Zawartość Czym jest UML? Wybrane

Bardziej szczegółowo

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

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2 Wyższa Szkoła Menedżerska w Legnicy Systemy informatyczne w przedsiębiorstwach Zarządzanie, ZIP, sem. 6 (JG) Modelowanie wymagań Wykład 2 Grzegorz Bazydło Cel wykładu Celem wykładu jest przekazanie wiedzy

Bardziej szczegółowo

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

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki

Bardziej szczegółowo

INŻYNIERIA OPROGRAMOWANIA. laboratorium

INŻYNIERIA OPROGRAMOWANIA. laboratorium INŻYNIERIA OPROGRAMOWANIA laboratorium UML 1/4 UML (Unified Modeling Language) - język modelowania obiektowego systemów i procesów [Wikipedia] Spojrzenie na system z różnych perspektyw dzięki zastosowaniu

Bardziej szczegółowo

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

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 5 Definicja systemu Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use

Bardziej szczegółowo

Wprowadzenie do UML, przykład użycia kolizja

Wprowadzenie do UML, przykład użycia kolizja Bogdan Kreczmer bogdan.kreczmer@pwr.wroc.pl Zakład Podstaw Cybernetyki i Robotyki Instytut Informatyki, Automatyki i Robotyki Politechnika Wrocławska Kurs: Copyright c 2012 Bogdan Kreczmer Niniejszy dokument

Bardziej szczegółowo

Diagramy czynności Na podstawie UML 2.0 Tutorial

Diagramy czynności Na podstawie UML 2.0 Tutorial Diagramy czynności Na podstawie UML 2.0 Tutorial http://sparxsystems.com.au/resources/uml2_tutorial/ Zofia Kruczkiewicz 1 Diagramy czynności 1. Diagramy czyności UML http://sparxsystems.com.au/resources/uml2_tutorial/

Bardziej szczegółowo

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

koniec punkt zatrzymania przepływów sterowania na diagramie czynności Diagramy czynności opisują dynamikę systemu, graficzne przedstawienie uszeregowania działań obrazuje strumień wykonywanych czynności z ich pomocą modeluje się: - scenariusze przypadków użycia, - procesy

Bardziej szczegółowo

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

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017 Wykład 12 7 czerwca 2017 Czym jest UML? UML składa się z dwóch podstawowych elementów: notacja: elementy graficzne, składnia języka modelowania, metamodel: definicje pojęć języka i powiazania pomiędzy

Bardziej szczegółowo

UML w Visual Studio. Michał Ciećwierz

UML w Visual Studio. Michał Ciećwierz UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować

Bardziej szczegółowo

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

Spis treúci. 1. Wprowadzenie... 13 Księgarnia PWN: W. Dąbrowski, A. Stasiak, M. Wolski - Modelowanie systemów informatycznych w języku UML 2.1 Spis treúci 1. Wprowadzenie... 13 2. Modelowanie cele i metody... 15 2.1. Przegląd rozdziału...

Bardziej szczegółowo

Diagramy UML, przykład problemu kolizji

Diagramy UML, przykład problemu kolizji Bogdan Kreczmer bogdan.kreczmer@pwr.edu.pl Katedra Cybernetyki i Robotyki Wydział Elektroniki Politechnika Wrocławska Kurs: Copyright c 2015 Bogdan Kreczmer Niniejszy dokument zawiera materiały do wykładu

Bardziej szczegółowo

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

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Opis szkoleń z obszaru INFORMATYKA planowanych

Bardziej szczegółowo

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

Modelowanie. Wykład 1: Wprowadzenie do Modelowania i języka UML. Anna Kulig Modelowanie Obiektowe Wykład 1: Wprowadzenie do Modelowania i języka UML Anna Kulig Wprowadzenie do modelowania Zasady Pojęcia Wprowadzenie do języka UML Plan wykładu Model jest uproszczeniem rzeczywistości.

Bardziej szczegółowo

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

Modelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych Modelowanie przypadków użycia Jarosław Kuchta Podstawowe pojęcia Przypadek użycia jest formalnym środkiem dla przedstawienia funkcjonalności systemu informatycznego z punktu widzenia jego użytkowników.

Bardziej szczegółowo

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

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych dr inż. Adam Iwaniak Infrastruktura Danych Przestrzennych w Polsce i Europie Seminarium, AR Wrocław

Bardziej szczegółowo

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

Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Modelowanie biznesowe jest stykiem między

Bardziej szczegółowo

NIFIED M L ODELLING ANGUAGE. Diagramy czynności

NIFIED M L ODELLING ANGUAGE. Diagramy czynności U M L NIFIED ODELLING ANGUAGE Diagramy czynności 1 Czym jest diagram czynności? Jeden z pięciu rodzajów diagramów UML służących do modelowania dynamicznych aspektów systemu. Przedstawia przepływ sterowania

Bardziej szczegółowo

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

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 związków encji (ERD) 1 Projektowanie bazy danych za pomocą narzędzi CASE Materiał pochodzi ze strony : http://jjakiela.prz.edu.pl/labs.htm Diagramu Związków Encji - CELE Zrozumienie struktury

Bardziej szczegółowo

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

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language) Zagadnienia (1/3) Rola modelu systemu w procesie analizy wymagań (inżynierii wymagań) Prezentacja różnego rodzaju informacji o systemie w zależności od rodzaju modelu. Budowanie pełnego obrazu systemu

Bardziej szczegółowo

Modelowanie obiektowe - Ćw. 3.

Modelowanie obiektowe - Ćw. 3. 1 Modelowanie obiektowe - Ćw. 3. Treść zajęć: Diagramy przypadków użycia. Zasady tworzenia diagramów przypadków użycia w programie Enterprise Architect. Poznane dotychczas diagramy (czyli diagramy klas)

Bardziej szczegółowo

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

UML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne. 45. UML, jego struktura i przeznaczenie. Przeznaczenie UML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne. Pozwala obrazować, specyfikować, tworzyć

Bardziej szczegółowo

Unified Modeling Language

Unified Modeling Language Unified Modeling Language Wprowadzenie do UML Igor Gocaliński Odrobina historii Połowa lat 70-tych i koniec 80-tych to początek analizy obiektowej Wiele opracowanych metod w połowie lat 90-tych Metoda

Bardziej szczegółowo

Wykład 1 Inżynieria Oprogramowania

Wykład 1 Inżynieria Oprogramowania Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI

Bardziej szczegółowo

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA Przygotował: mgr inż. Radosław Adamus Wprowadzenie Podstawą każdego projektu, którego celem jest budowa oprogramowania są wymagania, czyli warunki,

Bardziej szczegółowo

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

MiASI. Modelowanie integracji systemów. Piotr Fulma«ski. 26 stycznia Wydziaª Matematyki i Informatyki, Uniwersytet Šódzki, Polska MiASI Modelowanie integracji systemów Piotr Fulma«ski Wydziaª Matematyki i Informatyki, Uniwersytet Šódzki, Polska 26 stycznia 2010 Spis tre±ci 1 Czym jest integracja systemów informatycznych? 2 Integracja

Bardziej szczegółowo

Obieg akceptacji kosztów w organizacji

Obieg akceptacji kosztów w organizacji Obieg akceptacji kosztów w organizacji automatyczne sterowanie obiegiem akceptacji monitorowanie stanu obiegu faktur podział kosztów z jednej faktury na centra kosztów szybka rejestracja faktur obsługa

Bardziej szczegółowo

Michał Adamczyk. Język UML

Michał Adamczyk. Język UML Michał Adamczyk Język UML UML I. Czym jest UML Po co UML II.Narzędzia obsługujące UML, edytory UML III.Rodzaje diagramów UML wraz z przykładami Zastosowanie diagramu Podstawowe elementy diagramu Przykładowy

Bardziej szczegółowo

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

Naśladować Rynek Użytkownik Pomysł Koncepcja Ocena. Kim są docelowi użytkownicy koncepcji? Użytkownik Kim są docelowi użytkownicy koncepcji? Określ 3-5 różnych grup użytkowników twojej koncepcji i opisz osoby w każdej z grup. Przykład poniżej. Profile użytkowników powinny stworzyć żywy obraz

Bardziej szczegółowo

Faza analizy (modelowania) Faza projektowania

Faza analizy (modelowania) Faza projektowania Faza analizy (modelowania) Faza projektowania Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie: co i przy jakich ograniczeniach system ma robić? Wynikiem tej analizy jest zbiór wymagań

Bardziej szczegółowo

Język UML w modelowaniu systemów informatycznych

Język UML w modelowaniu systemów informatycznych Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 3 Diagramy przypadków użycia Diagramy przypadków użycia (ang. use case)

Bardziej szczegółowo

Narzędzia Informatyki w biznesie

Narzędzia Informatyki w biznesie Narzędzia Informatyki w biznesie Przedstawiony program specjalności obejmuje obszary wiedzy informatycznej (wraz z stosowanymi w nich technikami i narzędziami), które wydają się być najistotniejsze w kontekście

Bardziej szczegółowo

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

Graficzna notacja procesów biznesowych BPMN. Porównanie z notacja UML. Jakub Morkis, Piotr Chmielewski Graficzna notacja procesów biznesowych BPMN. Porównanie z notacja UML Jakub Morkis, Piotr Chmielewski BPMN - Historia Formowanie grumy tworzącej notację Sierpień 2001, 58 członków reprezentujących 35 firm,

Bardziej szczegółowo

SPECYFIKACJA WYMAGAŃ

SPECYFIKACJA WYMAGAŃ SPECYFIKACJA WYMAGAŃ Autorzy: Wersja: 2 Historia zmian dokumentu Osoba

Bardziej szczegółowo

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

Analiza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji Analiza i programowanie obiektowe 2016/2017 Wykład 6: Projektowanie obiektowe: diagramy interakcji Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Przejście

Bardziej szczegółowo

Opis. Liczba godzin zajęć dydaktycznych z

Opis. Liczba godzin zajęć dydaktycznych z Załącznik nr 5 do Uchwały nr 1202 Senatu UwB z dnia 29 lutego 2012 r. Elementy składowe sylabusu Nazwa jednostki prowadzącej kierunek Nazwa kierunku studiów Poziom kształcenia Profil studiów Forma studiów

Bardziej szczegółowo

Zakres wykładu. Podstawy InŜynierii Oprogramowania

Zakres wykładu. Podstawy InŜynierii Oprogramowania Zakres wykładu Pojęcia podstawowe InŜynierii Oprogramowania Proces wytwarzania oprogramowania Artefakty procesu wytwarzania i ich modele Jakość oprogramowania Literatura: [1] Sacha K., InŜynieria oprogramowania,

Bardziej szczegółowo

Narzędzia CASE dla.net. Łukasz Popiel

Narzędzia CASE dla.net. Łukasz Popiel Narzędzia CASE dla.net Autor: Łukasz Popiel 2 Czym jest CASE? - definicja CASE (ang. Computer-Aided Software/Systems Engineering) g) oprogramowanie używane do komputerowego wspomagania projektowania oprogramowania

Bardziej szczegółowo

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty przedmiotu Stopień studiów i forma: Rodzaj przedmiotu Kod przedmiotu Grupa kursów Zaawansowane techniki analizy

Bardziej szczegółowo

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

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM

Bardziej szczegółowo

Identyfikacja i modelowanie struktur i procesów biologicznych

Identyfikacja i modelowanie struktur i procesów biologicznych Identyfikacja i modelowanie struktur i procesów biologicznych Laboratorium 2: Wprowadzenie do UML-a. mgr inż. Urszula Smyczyńska AGH Akademia Górniczo-Hutnicza 1. Cel zajęć Celem zajęć jest zapoznanie

Bardziej szczegółowo

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

Inżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia Inżynieria oprogramowania Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia Punkt widzenia (Point of View) Systemy oprogramowania mają zwykle kilku różnych użytkowników. Wielu

Bardziej szczegółowo

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

Informatyczny system wspomagania reinżynierii procesów gospodarczych (BPR) na przykładzie wykorzystania modelu referencyjnego SAP R3 Informatyczny system wspomagania reinżynierii procesów gospodarczych (BPR) na przykładzie wykorzystania modelu referencyjnego SAP R3 Wyzwania stawiane procesom restrukturyzacji przedsiębiorstw pociągają

Bardziej szczegółowo

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

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla studenta Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Laboratorium modelowania oprogramowania w języku UML Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram

Bardziej szczegółowo

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

Diagram Przepływu Danych - podstawowe bloki składowe i reguły konstrukcji Diagramu Przepływu danych - CELE Określenie kluczowych obiektów zewnętrznych będących w interakcji z firmą (systemem); Określenie kluczowych procesów występujących w firmie; Określenie sposobu przepływu

Bardziej szczegółowo

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

UML cz. I. UML cz. I 1/1 UML cz. I UML cz. I 1/1 UML cz. I 2/1 UML - Unified Modeling Language ujednolicony można go współdzielić z wieloma pracownikami modelowania służy do opisu projektowanego modelu język posiada opisaną strukturę

Bardziej szczegółowo

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

Modelowanie diagramów klas w języku UML. Łukasz Gorzel 244631@stud.umk.pl 7 marca 2014 Modelowanie diagramów klas w języku UML Łukasz Gorzel 244631@stud.umk.pl 7 marca 2014 Czym jest UML - Unified Modeling Language - Rodzina języków modelowania graficznego - Powstanie na przełomie lat 80

Bardziej szczegółowo

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

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 3 Identyfikacja przypadków użycia Inżynieria wymagań Wykład 2 Proces pisania przypadków użycia Część 3 Identyfikacja przypadków użycia Opracowane w oparciu o materiały IBM (kurs REQ570: Writing Good Use Cases) Znajdowanie przypadków użycia

Bardziej szczegółowo

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

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Modelowanie danych Diagramy ERD Modelowanie danych dlaczego? Od biznesowego gadania do magazynu na biznesowe

Bardziej szczegółowo

Diagramy przypadków użycia

Diagramy przypadków użycia Instytut Informatyki Uniwersytetu Śląskiego 10 października 2010 Spis treści 1 Wprowadzenie do UML 2 3 4 5 6 Diagramy UML Język UML definiuje następujący zestaw diagramów: diagram przypadków użycia - służy

Bardziej szczegółowo

Architektura oprogramowania w praktyce. Wydanie II.

Architektura oprogramowania w praktyce. Wydanie II. Architektura oprogramowania w praktyce. Wydanie II. Autorzy: Len Bass, Paul Clements, Rick Kazman Twórz doskonałe projekty architektoniczne oprogramowania! Czym charakteryzuje się dobra architektura oprogramowania?

Bardziej szczegółowo

Projektowanie systemów informacyjnych: język UML

Projektowanie systemów informacyjnych: język UML Programowanie obiektowe w C++ Projektowanie systemów informacyjnych: język UML mgr inż. Witold Dyrka 4.01.2010 Projektowanie systemów informacyjnych: język UML Projektowanie systemów informacyjnych wprowadzenie

Bardziej szczegółowo

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

Partnerzy w biznesie wg Business Model Canvas. Współpraca z partnerami. Wskaźniki jakościowe realizowanych usług. 2012 Partnerzy w biznesie wg Business Model Canvas. Współpraca z partnerami. Wskaźniki jakościowe realizowanych usług. Przemysław Kułyk E-usługa utrzymanie Kraków, 23 października 2012 Wykształcenie Akademia

Bardziej szczegółowo

Inżynieria oprogramowania

Inżynieria oprogramowania Inżynieria oprogramowania Wykład 8 Inżynieria wymagań: analiza przypadków użycia a diagram czynności Patrz: Stanisław Wrycza, Bartosz Marcinkowski, Krzysztof Wyrzykowski, Język UML 2.0 w modelowaniu systemów

Bardziej szczegółowo

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN Podziękowania REQB Poziom Podstawowy Przykładowy Egzamin Dokument ten został stworzony przez główny zespół Grupy Roboczej REQB dla Poziomu Podstawowego. Tłumaczenie

Bardziej szczegółowo

Procesowa specyfikacja systemów IT

Procesowa specyfikacja systemów IT Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office

Bardziej szczegółowo

Modelowanie i analiza systemów informatycznych

Modelowanie i analiza systemów informatycznych Modelowanie i analiza systemów informatycznych MBSE/SysML Wykład 11 SYSMOD Wykorzystane materiały Budapest University of Technology and Economics, Department of Measurement and InformaJon Systems: The

Bardziej szczegółowo

Techniki i rozwiązania IT w optymalizacji procesów

Techniki i rozwiązania IT w optymalizacji procesów Techniki i rozwiązania IT w optymalizacji procesów dr inż. amber.zarz.agh.edu.pl/amaciol Cel przedmiotu Zapoznać się z problemami informacyjnodecyzyjnymi zarządzania organizacjami Nauczyć się wykorzystywać

Bardziej szczegółowo

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

Uniwersytet w Białymstoku Wydział Ekonomiczno-Informatyczny w Wilnie SYLLABUS na rok akademicki 2012/2013 SYLLABUS na rok akademicki 01/013 Tryb studiów Studia stacjonarne Kierunek studiów Informatyka Poziom studiów Pierwszego stopnia Rok studiów/ semestr III/VI Specjalność Bez specjalności Kod katedry/zakładu

Bardziej szczegółowo

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

MiASI. Modelowanie analityczne. Piotr Fulma«ski. 18 stycznia Wydziaª Matematyki i Informatyki, Uniwersytet Šódzki, Polska MiASI Modelowanie analityczne Piotr Fulma«ski Wydziaª Matematyki i Informatyki, Uniwersytet Šódzki, Polska 18 stycznia 2010 Spis tre±ci 1 Czym jest modelowanie analityczne? 2 Podstawowe kategorie poj ciowe

Bardziej szczegółowo

Informatyzacja przedsiębiorstw WYKŁAD

Informatyzacja przedsiębiorstw WYKŁAD Informatyzacja przedsiębiorstw WYKŁAD dr inż. Piotr Zabawa IBM/Rational Certified Consultant pzabawa@pk.edu.pl wersja 0.1.0 07.10.2010 Wykład 1 Modelowanie procesów biznesowych Przypomnienie rodzajów narzędzi

Bardziej szczegółowo

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

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Diagramy przypadków użycia Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Diagramy przypadków użycia Diagramy przypadków użycia jako narzędzie modelowania wymagań Nazwa diagramu

Bardziej szczegółowo

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

Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP Załącznik Nr 3 KDPW_CCP Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP Wersja 1.0 Warszawa, czerwiec 2012 Spis treści Wstęp... 3 Budowa komunikatów XML... 3 Przestrzenie

Bardziej szczegółowo

Modelowanie i analiza systemów informatycznych Spis treści

Modelowanie i analiza systemów informatycznych Spis treści Modelowanie i analiza systemów informatycznych Spis treści Modelowanie i analiza systemów informatycznych...1 Ćwiczenia 1...2 Wiadomości podstawowe:...2 Ćwiczenia...8 Ćwiczenia 1 Wiadomości podstawowe:

Bardziej szczegółowo

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

Podyplomowe Studium Informatyki w Bizniesie Wydział Matematyki i Informatyki, Uniwersytet Łódzki specjalność: Tworzenie aplikacji w środowisku Oracle Podyplomowe Studium Informatyki w Bizniesie Wydział Matematyki i Informatyki, Uniwersytet Łódzki specjalność: Tworzenie aplikacji w środowisku Oracle EFEKTY KSZTAŁCENIA Wiedza Absolwent tej specjalności

Bardziej szczegółowo

Podstawy języka UML UML

Podstawy języka UML UML Podstawy języka UML UML Plan prezentacji Wprowadzenie do modelowania Wprowadzenie do języka UML Diagram klas Diagram pakietów Diagram przypadków użycia Diagram czynności Terminologia Terminologia Aplikacja

Bardziej szczegółowo

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

ZARZĄDZANIU. Wykład VI. dr Jan Kazimirski INFORMATYKA W ZARZĄDZANIU Wykład VI dr Jan Kazimirski jankazim@mac.edu.pl http://www.mac.edu.pl/jankazim MODELOWANIE SYSTEMÓW UML Literatura Joseph Schmuller UML dla każdego, Helion 2001 Perdita Stevens

Bardziej szczegółowo

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. 2/34 Modelowanie CRC Modelowanie CRC (class-responsibility-collaborator) Metoda identyfikowania poszczególnych

Bardziej szczegółowo

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

Krzysztof Wawrzyniak Quo vadis BS? Ożarów Mazowiecki, styczeń 2014 1 QUO VADIS.. BS? Rekomendacja D dlaczego? Mocne fundamenty to dynamiczny rozwój. Rzeczywistość wdrożeniowa. 2 Determinanty sukcesu w biznesie. strategia, zasoby (ludzie, kompetencje, procedury, technologia)

Bardziej szczegółowo

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

Spis treści. Analiza i modelowanie_nowicki, Chomiak_Księga1.indb :03:08 Spis treści Wstęp.............................................................. 7 Część I Podstawy analizy i modelowania systemów 1. Charakterystyka systemów informacyjnych....................... 13 1.1.

Bardziej szczegółowo

Inżynieria oprogramowania Jarosław Kuchta. Modelowanie interakcji

Inżynieria oprogramowania Jarosław Kuchta. Modelowanie interakcji Inżynieria oprogramowania Jarosław Kuchta Modelowanie interakcji Podstawowe pojęcia Interakcja (interaction) Przepływ komunikatów pomiędzy obiektami konieczny dla wykonania określonego zadania. Interakcja

Bardziej szczegółowo

Algorytm. Krótka historia algorytmów

Algorytm. Krótka historia algorytmów Algorytm znaczenie cybernetyczne Jest to dokładny przepis wykonania w określonym porządku skończonej liczby operacji, pozwalający na rozwiązanie zbliżonych do siebie klas problemów. znaczenie matematyczne

Bardziej szczegółowo

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

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 1 Wprowadzenie do narzędzia CASE. Materiały dla nauczyciela Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Laboratorium modelowania oprogramowania w języku UML Ćwiczenie 1 Wprowadzenie do narzędzia CASE

Bardziej szczegółowo

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

Piotr Kulicki Katolicki Uniwersytet Lubelski Jana Pawła II Instytut Filozofii Teoretycznej Katedra Podstaw Informatyki Piotr Kulicki Katolicki Uniwersytet Lubelski Jana Pawła II Instytut Filozofii Teoretycznej Katedra Podstaw Informatyki Modalności w praktyce informatycznej Lublin, 17 listopada 2009 Interesująca opinia

Bardziej szczegółowo

Wprowadzenie do zarządzania procesami biznesowymi

Wprowadzenie do zarządzania procesami biznesowymi Wprowadzenie do zarządzania procesami biznesowymi Definicja procesu Proces jest jednostką pracy obejmującą wiele czynności, wykonywanych w ogólności przez różnych wykonawców i w sposób współbieżny. Proces

Bardziej szczegółowo

Identyfikacja i modelowanie struktur i procesów biologicznych

Identyfikacja i modelowanie struktur i procesów biologicznych Identyfikacja i modelowanie struktur i procesów biologicznych Laboratorium 2: Wprowadzenie do UML-a. mgr inż. Urszula Smyczyńska AGH Akademia Górniczo-Hutnicza 1. Cel zajęć Celem zajęć jest zapoznanie

Bardziej szczegółowo

Inżynieria oprogramowania. Jan Magott

Inżynieria oprogramowania. Jan Magott Inżynieria oprogramowania Jan Magott Literatura do języka UML G. Booch, J. Rumbaugh, I. Jacobson, UML przewodnik użytkownika, Seria Inżynieria oprogramowania, WNT, 2001, 2002. M. Fowler, UML w kropelce,

Bardziej szczegółowo

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2 Modelowanie i analiza systemów informatycznych 1. Warstwowa budowa systemów informatycznych 2. Model procesu wytwarzania oprogramowania - model cyklu życia oprogramowania 3. Wstęp do modelowania systemów

Bardziej szczegółowo

UML. zastosowanie i projektowanie w języku UML

UML. zastosowanie i projektowanie w języku UML UML zastosowanie i projektowanie w języku UML Plan Czym jest UML Diagramy przypadków użycia Diagramy sekwencji Diagramy klas Diagramy stanów Przykładowe programy Visual Studio a UML Czym jest UML UML jest

Bardziej szczegółowo

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

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 6 Wskazówki i sugestie Inżynieria wymagań Wykład 2 Proces pisania przypadków użycia Część 6 Wskazówki i sugestie Opracowane w oparciu o materiały IBM (kurs REQ570: Writing Good Use Cases) Wyzwania podczas pisania przypadków

Bardziej szczegółowo

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

Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP Warszawa, lipiec 2012 Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP Wersja 1.1 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw

Bardziej szczegółowo

KARTA PRZEDMIOTU. 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA. 2) Kod przedmiotu: ROZ-L3-20

KARTA PRZEDMIOTU. 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA. 2) Kod przedmiotu: ROZ-L3-20 Z1-PU7 WYDANIE N2 Strona: 1 z 5 (pieczęć wydziału) KARTA PRZEDMIOTU 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA 3) Karta przedmiotu ważna od roku akademickiego: 2014/2015 2) Kod przedmiotu:

Bardziej szczegółowo

Analiza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas

Analiza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas Analiza i projektowanie obiektowe 2016/2017 Wykład 10: Tworzenie projektowego diagramu klas Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Projektowy

Bardziej szczegółowo

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

Diagramy przypadków użycia. WYKŁAD Piotr Ciskowski Diagramy przypadków użycia WYKŁAD Piotr Ciskowski Diagram przypadków użycia definiowanie wymagań systemowych graficzne przedstawienie przypadków użycia, aktorów, związków między nimi występujących w danej

Bardziej szczegółowo

KARTA MODUŁU KSZTAŁCENIA

KARTA MODUŁU KSZTAŁCENIA KARTA MODUŁU KSZTAŁCENIA I. Informacje ogólne 1 Nazwa modułu kształcenia Inżynieria 2 Nazwa jednostki prowadzącej moduł Instytut Informatyki, Zakład Informatyki Stosowanej 3 Kod modułu (wypełnia koordynator

Bardziej szczegółowo

Tytuł pracy: PRACA MAGISTERSKA AUTOR: KRAKÓW, Marzec 2011 Promotor pracy :

Tytuł pracy: PRACA MAGISTERSKA AUTOR: KRAKÓW, Marzec 2011 Promotor pracy : Politechnika Krakowska im Tadeusza Kościuszki Wydział Fizyki, Matematyki i Informatyki Stosowanej Kierunek: Informatyka; specjalność Informatyka Stosowana PRACA MAGISTERSKA AUTOR: KRAKÓW, Marzec 2011 Promotor

Bardziej szczegółowo

Modelowanie Procesów Biznesowych Wykład 3 Notacja UML cz. 1

Modelowanie Procesów Biznesowych Wykład 3 Notacja UML cz. 1 Modelowanie Procesów Biznesowych Wykład 3 Notacja UML cz. 1 Konrad Markowski Plan wystąpienia Biznesowy diagram przypadków użycia Konstruowanie biznesowego diagramu przypadków użycia Przykład Wprowadzenie

Bardziej szczegółowo

Projekt i implementacja narzędzia do analizy modeli spójności F R Y D E R Y K R A C Z Y K K O N R A D S Z A Ł K O W S K I

Projekt i implementacja narzędzia do analizy modeli spójności F R Y D E R Y K R A C Z Y K K O N R A D S Z A Ł K O W S K I Projekt i implementacja narzędzia do analizy modeli spójności P R O M O T O R : D R I N Ż. A N N A K O B U S I Ń S K A F R Y D E R Y K R A C Z Y K K O N R A D S Z A Ł K O W S K I Plan prezentacji Zadanie

Bardziej szczegółowo

Język UML w modelowaniu systemów informatycznych

Język UML w modelowaniu systemów informatycznych Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 6 Diagramy komunikacji Diagram komunikacji (ang. communication diagram),

Bardziej szczegółowo

Inżynieria oprogramowania

Inżynieria oprogramowania Inżynieria oprogramowania Instrukcja do laboratorium rok akad. 2014/2015 Informacje podstawowe: Celem laboratorium jest nabycie przez studentów praktycznej umiejętności wykonywania modeli analitycznych

Bardziej szczegółowo

Systemy informatyczne. Modelowanie danych systemów informatycznych

Systemy informatyczne. Modelowanie danych systemów informatycznych Modelowanie danych systemów informatycznych Diagramy związków encji Entity-Relationship Diagrams Modelowanie danych diagramy związków encji ERD (ang. Entity-Relationship Diagrams) diagramy związków encji

Bardziej szczegółowo

Język UML w modelowaniu systemów informatycznych

Język UML w modelowaniu systemów informatycznych Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 4 Diagramy aktywności I Diagram aktywności (czynności) (ang. activity

Bardziej szczegółowo

IO - inżynieria oprogramowania. dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl

IO - inżynieria oprogramowania. dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl IO - inżynieria oprogramowania dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl Metody porządkowania wymagań funkcjonalnych Liczba wymagań funkcjonalnych może być bardzo duża; konieczne jest pewnego rodzaju

Bardziej szczegółowo

Szczegółowy harmonogram rzeczowy realizacji prac systemu B2B

Szczegółowy harmonogram rzeczowy realizacji prac systemu B2B Szczegółowy harmonogram rzeczowy realizacji prac systemu B2B NAZWA ZADANIA ZADANIE CZĄSTKOWE TECHNOLOGIA ILOŚĆ OSÓB ILOŚĆ GODZIN TERMIN REALIZACJI 1 2 4 5 6 7 Zadanie 1 - wersji alfa 1 systemu B2B 3 723

Bardziej szczegółowo

PROJEKT INTERFEJSU UśYTKOWNIKA PROJEKT WERSJA

PROJEKT INTERFEJSU UśYTKOWNIKA PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU> Załącznik nr 4.5 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PROJEKT INTERFEJSU UśYTKOWNIKA PROJEKT WERSJA numer wersji

Bardziej szczegółowo

Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania

Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania dr inż. Marcin Szlenk Politechnika Warszawska Wydział Elektroniki i Technik Informacyjnych Wprowadzenie O mnie dr inż. Marcin

Bardziej szczegółowo