Unified Modeling Language. Referat na seminarium magisterskie Zagadnienia Programowania Obiektowego Dymitr Pszenicyn

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

UML w Visual Studio. Michał Ciećwierz

Unified Modeling Language

INŻYNIERIA OPROGRAMOWANIA. laboratorium

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.

Podstawy programowania III WYKŁAD 4

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

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

Diagramy czynności Na podstawie UML 2.0 Tutorial

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

Michał Adamczyk. Język UML

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

Podstawy inżynierii oprogramowania

Wykład 1 Inżynieria Oprogramowania

WPROWADZENIE DO UML-a

Wprowadzenie do UML Rodzaje diagramów Przeglad oprogramowania Zadania Rozwiazania zadań Bibliografia. Warsaw Dziobax

Podstawy modelowania programów Kod przedmiotu

Język UML w modelowaniu systemów informatycznych

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

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

Inżynieria oprogramowania

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

UML cz. III. UML cz. III 1/36

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

Język UML w modelowaniu systemów informatycznych

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

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

Podstawy języka UML UML

Inżynieria oprogramowania Jarosław Kuchta. Modelowanie interakcji

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

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

Diagramy klas. dr Jarosław Skaruz

Technologie obiektowe. Plan. Ewolucja technik wytwarzania oprogramowania

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

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

Diagramy przypadków użycia

Modelowanie i analiza systemów informatycznych

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

Projektowanie systemów informatycznych. Diagramy przypadków użycia

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

TECHNOLOGIE OBIEKTOWE. Wykład 3

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

Diagramy zachowania. Diagramy struktury. przypadki użycia. Stanów. Przeglądu interakcji widoku interakcji (ang. interaction overview)

Tutorial prowadzi przez kolejne etapy tworzenia projektu począwszy od zdefiniowania przypadków użycia, a skończywszy na konfiguracji i uruchomieniu.

Modelowanie obiektowe - Ćw. 3.

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 3 Ćwiczenia w narzędziu CASE diagram sekwencji. Materiały dla nauczyciela

Diagramy zachowania. Diagramy struktury. Przypadków użycia. Stanów. Przeglądu interakcji widoku interakcji (ang. interaction overview)

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

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

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

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

UML. dr inż. Marcin Pietroo

Wprowadzenie do UML, przykład użycia kolizja

Diagramy UML, przykład problemu kolizji

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

UML. zastosowanie i projektowanie w języku UML

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 2 Ćwiczenia w narzędziu CASE diagram klas. Materiały dla nauczyciela

NIFIED M L ODELLING ANGUAGE. Diagramy czynności

Podstawy języka UML2 w realnych projektach

Inżynieria oprogramowania. Jan Magott

MODELOWANIE OBIEKTOWE

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne

Opis Architektury Systemu Galileo

UML - zarys 2007/2008

Podstawy języka UML UML

PRZEWODNIK PO PRZEDMIOCIE

Modelowanie i analiza systemów informatycznych Spis treści

Wykład 7 Metodyki wytwarzania oprogramowania internetowego (2) Wykładowca: dr inż. Mariusz Trzaska

Podstawy języka UML2 w realnych projektach

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

Zalety projektowania obiektowego

Narzędzia CASE dla.net. Łukasz Popiel

Specyfikowanie wymagań przypadki użycia

Dokument Detaliczny Projektu Temat: Księgarnia On-line Bukstor

Modelowanie klas i obiektów. Jarosław Kuchta Projektowanie Aplikacji Internetowych

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

Diagramy klas. WYKŁAD Piotr Ciskowski

UML- Unified Modeling Language Ujednolicony Język Modelowania

PRZEWODNIK PO PRZEDMIOCIE

TECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek

DIAGRAMY IMPLEMENTACYJNE

Faza analizy (modelowania) Faza projektowania

UML cz. II. UML cz. II 1/38

Inżynieria oprogramowania

Podstawy projektowania systemów komputerowych

Modelowanie aktywności. Jarosław Kuchta Programowanie Współbieżne

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

Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny

KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH

Rysunek 1: Przykłady graficznej prezentacji klas.

Oprogramowanie o wysokiej jakości to oprogramowanie spełniające następujące kryteria:

Diagram maszyny stanowej - POJĘCIA

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

Laboratorium z przedmiotu: Inżynieria Oprogramowania INEK Instrukcja 7

Transkrypt:

Unified Modeling Language Referat na seminarium magisterskie Zagadnienia Programowania Obiektowego Dymitr Pszenicyn

Po co UML? Duże przedsięwzięcia informatyczne wymagają modelowania. Istniało wiele metodologii modelowania systemów i trzeba było znać je wszystkie żeby się porozumieć. Wszystkie metodologie obiektowe miały wady i zalety UML połączył ich zalety.

Krótka historia UML Grady Booch, Ivar Jacobson i James Rumbaugh w 1995 roku stworzyli Unified Method v0.8 W 1997 powstał UML v1.0 i został przekazany pod opiekę Object Management Group Najnowsza wersja to UML v1.5 Trwają prace nad UML v2.0

Cechy UML Jest przystosowany do opisywania obiektowych systemów. Jest niezależny od przyjętego cyklu tworzenia oprogramowania. Jest ukierunkowany na przypadki użycia. Jest przystosowany do iteracyjnego i przyrostowego rozwijania systemu. Umożliwia stosowanie narzędzi do automatycznego tworzenia szkieletu programu z diagramów oraz automatycznego przetwarzania programu na diagramy UML.

Perspektywy Każdy duży projekt najlepiej oglądać z wielu prawie niezależnych perspektyw. W UML są to: perspektywa przypadków użycia perspektywa projektowa perspektywa procesowa perspektywa implementacyjna perspektywa wdrożeniowa

Perspektywa projektowa Perspektywa implementacyjna Perspektywa przypadków użycia Perspektywa procesowa Perspektywa wdrożeniowa

Perspektywa przypadków użycia Zachowanie systemu z punktu widzenia użytkowników i analityków. Aspekty statyczne wyraża się za pomocą diagramów przypadków użycia. Aspekty dynamiczne wyraża się za pomocą diagramów interakcji, diagramów stanów i diagramów czynności.

Perspektywa projektowa Przede wszystkim budowa systemu z klas i interfejsów. Aspekty statyczne wyraża się za pomocą diagramów klas i diagramów obiektów. Aspekty dynamiczne wyraża się za pomocą diagramów interakcji, diagramów stanów i diagramów czynności.

Perspektywa procesowa Przede wszystkim budowa systemu z wątków i procesów. Aspekty statyczne wyraża się za pomocą diagramów klas i diagramów obiektów. Aspekty dynamiczne wyraża się za pomocą diagramów interakcji, diagramów stanów i diagramów czynności. Bardzo ważną rolę na diagramach pełnią klasy aktywne które reprezentują procesy i wątki.

Perspektywa implementacyjna Przede wszystkim fizyczna budowa systemu z plików i komponentów. Aspekty statyczne wyraża się za pomocą diagramów komponentów. Aspekty dynamiczne wyraża się za pomocą diagramów interakcji, diagramów stanów i diagramów czynności.

Perspektywa wdrożeniowa Przede wszystkim węzły na których będzie uruchamian system. Aspekty statyczne wyraża się za pomocą diagramów instalacji. Aspekty dynamiczne wyraża się za pomocą diagramów interakcji, diagramów stanów i diagramów czynności.

Elementy UML Diagramy UML składają się z wielu elementów takich jak klasy, obiekty, komponenty, pakiety i powiązania między nimi. Elementy posiadają wiele atrybutów ale tylko nazwa jest wymagana.

Klasa: Osoba -id : Integer -nazwisko : String -stanowisko : String +odczytajadresykontaktowe() +odczytajdaneosobowe() +zapamiętajzdjęcie( z : Zdjęcie ) Interfejs: Obiekt: o : Osoba nazwisko = "Kowalski" id = 4362 stanowisko = Szef Sprzedaży Pakiet: Logika dla centrali Kooperacja: Obsługa zamówień Podsystem: <<subsystem>> Fakturowanie IUnknown Zależność: Powiązanie: 0..1 * Uogólnienie: Agregacja: Agregacja całkowita:

Komponent: Węzeł: adm.exe Komputer w centrali Instancja komponentu: Instancja węzła: adm.exe k : Konsola

UML jest rozszerzalny Notatki pozwalają na dopisywanie komentarzy, ograniczeń i wymagań. Stereotypy pozwalają na tworzenie nowych bloków konstrukcyjnych. Metki umożliwaiją rozszerzenie listy właściwości bloku konstrukcyjnego. Ograniczenia umożliwiają rozszerzanie znaczenia bloku konstrukcyjnego.

To jest notatka w HTML'u Człowiek -płeć : {mężczyzna, kobieta} 0..1 -mąż 0..1 -żona {self.żona.płeć=kobieta and self.mąż.płeć=mężczyzna} Przykłady stereotypow, metek i ograniczeń <<pojemnik>> Kolejka {wersja=1.8} +dodaj( element ) +usuń() <<subsystem>> Faktury {język=c++}

Z czego składa się UML 12 rodzajów diagramów podzielonych na 3 kategorie: 4 diagramy pokazują statyczną strukturę aplikacji 5 diagramów pokazuje dynamiczne zachowania systemu 3 diagramy pokazują organizację modelu

Statyczna struktura systemu (Structural Diagrams)

Diagram klas (Class Diagram) Pokazuje związki (uogólnienie, zależność, powiązanie i agregacja) pomiędzy klasami oraz interfejsami. Klasy na diagramie mogą być grupowane w pakiety. Klasy aktywne (w grubej ramce) reprezentują wątki i procesy. Nazwy klas abstrakcyjnych są pisane kursywą.

Przedsiębiorstwo 1 1 0..1 * 1..* Dział -nazwa : String Siedziba 1..* Biuro -adres : String -telefon : Number * pracownik 1..* -id : Integer -nazwisko : String -stanowisko : String * {podzbiór} kierownik 1 Osoba +odczytajadresykontaktowe() +odczytajdaneosobowe() +zapamiętajzdjęcie( z : Zdjęcie ) Centrala AdresyKontaktowe -adres : String DanePersonelu -historiapracy -nip -wynagrodzenie IPoufneInformacje

Diagram obiektów (Object Diagram) Pokazuje związki między obiektami oraz klasami. Przydatny do przedstawiania przykładów (rzut systemu w danej chwili) i analizowania działającego systemu. Nie powinien przedstawiać pełnego zbioru obiektów w systemie, a tylko interesujący nas wycinek.

p : Przedsiębiorstwo d : Dział nazwa = "Sprzedaż" d2 : Dział nazwa = "Badania i rozwój" d3 : Dział nazwa = "Sprzedaż w Polsce" kierownik o : Osoba nazwisko = "Kowalski" id = 4362 stanowisko = Szef Sprzedaży : AdresyKontaktowe adres = "Kluczowa 10"

Diagram komponentów (Component Diagram) Obrazuje fizyczne, wymienne komponenty systemu, takie jak: pliki, tabele, biblioteki obiektów. Bardzo często łączony z diagramem instalacji, pokazuje co gdzie zainstalować. Definiowanie interfejsów zapewnia wymienialność komponentów.

<<executable>> plot.exe <<executable>> viewer.exe interfejs graficzny <<library>> math.dll <<library>> opengl.dll <<library>> stat.dll

Diagram instalacji (Deployment Diagram) Trójwymiarowe bloki (tzw. węzły) reprezentują sprzęt, na którym ma działać system (serwery, urządzenia sieciowe itd). Prawie zawsze zawierają komponenty. Często są stereotypowane za pomocą specjalnych symboli graficznych (komputer albo cała sieć).

: KomputerKlienta : KomputerKlienta klient.exe klient_win.exe : MacierzRAID {10-FL Ethernet} k : Konsola adm.exe {RS-232} {10-T Ethernet} s : Serwer {prędkośćprocesora=300 MHz, pamięć=128 MB} konfig.exe admbd.exe admraid.exe

Komputer klienta agencji Przegladarka internetowa Komputer w centrali AT*CSS Apache Serwer WWW Logika ISS Serwer bazy danych Oracle Serwer plikow Centralny serwer sprzedazy Komputer w biurze regionalnym System sprzedazy Serwer autentyfikacji LSS

Dynamiczne zachowania systemu (Behavior Diagrams)

Diagram przypadków użycia (Use Case Diagram) Zawierają aktorów, przypadki użycia i związki pomiędzy nimi. Pozwalają prześledzić możliwości systemu są bardzo przydatne dla klienta który może zorientować się co naprawdę system będzie robić. Są bardziej statyczne od diagramów przebiegu lub czynności.

Przegladanie i wyszukiwanie w ofercie (LSS) Sprzedaz wycieczki (LSS) Sprzedawca Usuniecie klienta z listy uczestnikow wycieczki Logowanie do LSS Wprowadzenie wynikow ankiet do systemu Pracownik biurowy Przegladanie oferty przez Internet Klient Zakup wycieczki przez Internet Rezygnacja z uczestnictwa w wycieczce

Zarzadzanie kontami uzytkownikow Administrator CSS Zarzadzanie uprawnieniami uzytkownikow Logowanie do CSS Dodanie projektu wycieczki Projektant wycieczek Dodanie szkicu wycieczki Modyfikacja szkicu wycieczki Usuniecie szkicu wycieczki Modyfikacja projektu wycieczki Przegladanie bazy danych klientow

Wykryj oszustwo <<include>> Złóż zamówienie Zarządzanie zamówieniami Klient <<include>> Zweryfikuj tranzakcję Wystaw fakturę Klient internetowy Wyszukaj towar w bazie danych extension points wyszukiwanie według wielu kryteriów <<extend>> (wyszukiwanie według wielu kryteriów) Wyszukaj towar według wielu kryteriów

Diagram przebiegu (Sequence Diagram) Ułożenie linii na diagramie jest istotne, gdyż oś Y oznacza czas. Diagram przebiegu uwypukla kolejność komunikatów w czasie. Jeden diagram powinien przedstawiać tylko jedną sytuację (jeden przepływ sterowania). Dla pokazania prostych wariantów można używać iteracji i rozgałęzień.

k : NadawcaNotowańAkcji p1 : OdbiorcaNotowańAkcji p2 : OdbiorcaNotowańAkcji 1: zarejestruj( p1 ) 2: zarejestruj( p2 ) 3: zawiadom() 4: zaktualizuj() 5: odczytajstan() 6: zaktualizuj() 7: odczytajstan()

Diagram współpracy (Collaboration Diagram) Ułożenie obiektów względem siebie nie jest istotne. Diagram współpracy uwypukla organizację obiektów uczestniczących w interakcji. Komunikaty muszą być numerowane (zgodnie z notacją Deweya). Dla pokazania prostych wariantów można używać iteracji i rozgałęzień.

3: zawiadom() 1: zarejestruj( p1 ) 6: odczytajstan() p1 : OdbiorcaNotowańAkcji 4: zaktualizuj() k : NadawcaNotowańAkcji 2: zarejestruj( p2 ) 5: zaktualizuj() 7: odczytajstan() p2 : OdbiorcaNotowańAkcji

Diagram czynności (Activity Diagram) Jest to schemat blokowy, który przedstawia przepływ sterowania pomiędzy czynnościami. Często zawieraja tory, które pomagają grupować stany czynności oraz reprezentują jednostkę odpowiedzialną za przydzielone czynności. Dodatkowo można przedstawić przepływ obiektów oraz zmianę ich stanu. Można użyć diagramu czynności do rozpisania pojedyńczej operacji ale zwykle jest to bardzo podobne do kodu źródłowego.

Klient Dział Sprzedaży Hurtownia Zamów towary Zrealizuj zamówienie Kontynuuj pracę z : Zamówienie Zgromadź towary Wyślij zamówione towary Odbierz zamówienie Wystaw rachunek z : Zamówienie Zapłać rachunek r : Rachunek r : Rachunek Zakończ zamówienie

Diagram stanów (Statechart Diagram) Służy do opisu stanów pojedyńczego elementu (klasy, przypadku użycia, systemu). Można podać akcję wejściową i wyjściową. Stany mogą być zagnieżdżane. Można tworzyć podstany współbierzne (wtedy oba podstany muszą dojść do stanu końcowego zanim przepływy sterowania się połączą). Istnieją stany wznowienia, które służą do zapamiętania ostatnio przyjętego podstanu.

Bezczynność dzwonek entry / podnieśsłuchawkę exit / rozłącz Łączenie Odbieranie nagłówekok Przetwarzanie wyślijfaks odwieszonosłuchawkę Transmisja błąd / wydrukujraport Porządkowanie sumakontrolnaok

Organizacja modelu (Model Management Diagrams)

Diagram pakietów (Packages Diagram) Pakiety służą do grupowania bytów. Składnikami pakietu mogą być klasy, interfejsy, komponenty, węzły, operacje, przypadki użycia, diagramy i inne pakiety. W związku z tym, pakiety mogą wystąpić na prawie każdym diagramie. Każdy pakiet ma własną przestrzeń nazw. Na wszystkich diagramach, gdy używa się nazwy bytu (np. klasy), można podać pełną nazwę ścieżkowa (rozdzieloną podwójnymi dwukropkami :: ).

Przegladarka internetowa GUI LSS GUI CSS Warstwa prezentacji Apache Warstwa komunikacji Logika internetowego systemu sprzedazy Logika LSS Logika dla centrali Logika sprzedazy System kontroli dostepu Warstwa logiki biznesowej System tworzenia kopii zapasowych Baza danych Serwer plikow Warstwa dostepu do danych

Diagram Podsystemów (Subsystems Diagram) Podsystemy służą do grupowania pakietów. Są przydatne tylko w dużych systemach. Cały system jest zwykle agregacją podsystemów. Między podsystemami może zachodzić uogólnienie.

<<subsystem>> DostępDoRynkówZbytu {stan=oddany, wersja=2.5} <<subsystem>> Fakturowanie {wersja=3.2, stan=pobrany} <<subsystem>> Zobowiązania {stan=oddany, wersja=3.2.1} <<subsystem>> ObceWaluty {wersja=7.5, stan=oddany}

Narzędzia do UML MagicDraw http://www.magicdraw.com/ ArgoUML http://argouml.tigris.org/ Poseidon http://www.gentleware.com/

Źródła przedstawionych diagramów stworzone na prezentację (Dymitr Pszenicyn) z książki UML przewodnik użytkownika (Grady Booch, James Rumbaugh, Ivar Jacobson) z projektu na laboratorium Inżynieria Oprogramowania (Przemysław Rekucki, Dymitr Pszenicyn, Aleksander Grygiel, Andrzej Mizera, Krzysztof Kowalczyk) z projektu na Zespołowy Projekt Programistyczny (Aleksander Grygiel, Dymitr Pszenicyn, Stanisław Skonieczny, Andrzej Awramiuk)

Publikacje o UML G. Booch, J. Rumbaugh, I. Jacobson, UML przewodnik użytkownika. WNT, Warszawa 2002 Formalna specyfikacja UML http://www.omg.org/cgi-bin/doc?formal/03-03-01 Artykuł o historii UML http://www.omg.org/news/pr99/uml_2001_cac M_Oct99_p29-Kobryn.pdf Tutorial UML http://www.smartdraw.com/resources/centers/u ml/uml.htm

Publikacje o UML (cd.) Artykuł o UML http://www.rational.com/media/uml/intro_rd n.pdf Spis artykułów o UML http://www.rational.com/uml/resources/whi tepapers/index.jsp