Projektowanie w systemach UML

Prezentacja na temat: "Projektowanie w systemach UML"— Zapis prezentacji:

1 Projektowanie w systemach UML
1. Wprowadzenie dr inż. Sławomir Nowak

2 Wprowadzenie Sławomir Nowak emanuel@iitis.gliwice.pl
Wymagana wiedza Wprowadzenie Student… ...zna terminologię architektury komputerów i inżynierii programowania …zna i posługuje się obiektowym językiem programowania (C++. C#, Java) Prowadzący Program wykładów Sławomir Nowak Program przedmiotu obejmuje zagadnienia związane z teorią i zastosowaniem języka UML, w zakresie projektowania systemów, ze szczególnym uwzględnieniem projektowania i dokumentacji kodu źródłowego. Materiały do wykładu Literatura Egzamin UML 2.0 Wprowadzenie, Miles R., Hamilton K., Helion (O’Reilly) , 2007 UML 2.0, Almanach, Pilone D., Pitman N., Helion (O’Reilly) , 2007 UML 2.1 ćwiczenia, Wyrczy S., Helion 2006. Pisemny, obowiązkowy.

3 Wprowadzenie UML 2.0. Wprowadzenie Russ Miles, Kim Hamilton
Literatura: Wprowadzenie UML 2.0. Wprowadzenie Russ Miles, Kim Hamilton ISBN: Linki:

4 Literatura: Wprowadzenie Linki:

5 Założenia przedmiotu:
Wprowadzenie Przy omawianiu formatu języka ograniczamy stosujemy się do wersji 2.0/2.1 Wykorzystywane narzędzia projektowe są to narzędzia dostępne OpenSource. Zagadnienia dotyczą w większym stopniu zastosowania UML przy dokumentacji projektów programistycznych i kodu źródłowego. OSI - Open System Interconnection, model odniesienia łączenia systemów otwartych

6 Założenia przedmiotu:
Wprowadzenie Założeniem jest, że znane są podstawowe pojęcia z zakresu inżynierii programowania i programowania obiektowego jak klasa i klasa abstrakcyjna, obiekt, interfejs, dziedziczenie, implementowanie… OSI - Open System Interconnection, model odniesienia łączenia systemów otwartych

7 Wprowadzenie UML Źródło grafiki: Wikipedia

8 Historia UML Wprowadzenie Otwarty format UML (ang. Unified Modeling Language, czyli Ujednolicony Język Modelowania), to język formalny służący do opisu świata obiektów w analizie obiektowej oraz programowaniu obiektowym (Wikipedia) Model to „układ (...) możliwie mało skomplikowany, działający analogicznie do oryginału” (Słownik Języka Polskiego, PWN 1998)

9 Modelowanie obiektowe
Wprowadzenie System informatyczny powinien być jak najwierniejszym modelem otaczającego świata. W jaki więc sposób skonstruować model, aby spełniał to wymaganie? Klienci mają pewne wymagania w stosunku do systemu. Zamawiający znają problem i potrafią o niej opowiadać za pomocą specjalistycznego słownictwa. Nie potrafią jednak tworzyć technicznych opisów systemu. Programiści wiedzą, jak konstruować systemy. Programiści tworzą system korzystając z języka programowania. Są oni zorientowani w szczegółach platformy programowej. Nie są natomiast ekspertami w dziedzinie, dla której tworzą system.

10 Modelowanie obiektowe
Wprowadzenie Obiekty na danym poziomie abstrakcji ukrywają informacje nieistotne dla czytelnika modelu. Obiekty są zatem pewnego rodzaju czarnymi skrzynkami. Dopiero po „otwarciu” odkrywamy dalsze szczegóły. Obiekty z jednej strony obiekty odpowiadają pojęciom z modelowanej dziedziny problemu. Z drugiej strony są podstawą implementacji realizowanego systemu.

11 Wprowadzenie Modelowanie obiektowe
Korzystając z pojęcia obiektów tworzy się modele obiektowe (odwzorowanie rzeczywistych systemów). Modelowanie obiektowe polega więc na: wyodrębnianiu obiektów  opisywaniu struktury i dynamiki działania obiektów oraz klasyfikacji obiektów  opisywaniu struktury powiązań klas obiektów opisywaniu dynamiki współpracy obiektów Elementem, który pozwala pogodzić język użytkownika z językiem programisty jest obiekt. Obiekty z jednej strony obiekty odpowiadają pojęciom z modelowanej dziedziny problemu. Z drugiej strony są podstawą implementacji realizowanego systemu.

12 Wprowadzenie Modelowanie obiektowe
Modelowanie obiektowe polega na sporządzeniu opisu, odwzorowującego strukturę i dynamikę składających się na niego obiektów. Opis taki może być wykonany na różne sposoby, np: Opis słowny Opis w postaci rysunków i diagramów Modele obiektowe będziemy warto tworzyć za pomocą jednolitej notacji, wspólnej dla wszystkich. Dzięki temu mamy pewność, że model zostanie zrozumiany. Przykładem takiej notacji jest graficzny język UML.

13 Wprowadzenie Historia UML
W latach 70/80 wiele obiektowych języków programowania, wiele metod obiektowych, wiele metod obiektowego modelowania. Modelowanie obiektowe ma związek z podejściem obiektowym -> lata 80 Smalltalk, C++, projektowanie graficzne Wielu specjalistów – podobne podejście, drobne, ale upierdliwe różnice Czym różni się metodolog od terrorysty? – z terrorystą możesz negocjować… W połowie lat 90 opracowana została dokumentacja United Method i utworzono konsorcjum UML (m.in. HP, IBM, Oracle, Microsoft). Wynikiem prac konsorcjum był UML w wersji 1.0. Od 1997 roku rozwojem UML zajmuje się OMG (Object Management Group). Najnowsza wersja UML 2.3 pojawiła się w 2010 roku. Źródło: Wikipedia

14 Wprowadzenie do UML Wprowadzenie UML (ang. Unified Modeling Language, czyli Zunifikowany Język Modelowania) – uniwersalny język formalny wykorzystywany do modelowania systemów (różnego rodzaju). Służy do modelowania dziedziny problemu (opisywania fragmentu „rzeczywistości”). UML jest głównie używany wraz z jego reprezentacją graficzną – elementom przypisane są symbole, które wiązane są ze sobą na diagramach. UML był zaprojektowany, by definiować, wizualizować, konstruować i dokumentować systemy kładące nacisk na oprogramowanie, ale nie jest on ograniczony do modelowania oprogramowania. Jest używany także do modelowania procesów biznesowych, inżynierii systemów i reprezentowania struktur organizacyjnych. Pytania Scharakteryzuj ogólnie język UML. Źródło: Wikipedia

15 Charakterystyka Wprowadzenie UML – metodyka obiektowa. I tylko obiektowa. Zunifikowany – powstał z wielu Modelowania – służy do tworzenia modeli Język – bo służy do komunikowania się Obejmuje: Zbiór symboli graficznych gramatykę: sposób poprawnego łączenia i zestawiania ze sobą tych symboli. …co ciekawe – istnieje także metamodel tego języka, który opisuje specyfikację języka w języku…UML

16 Diagramy Wprowadzenie W wersji 2.2 wyróżnia się 14 diagramów głównych oraz 3 abstrakcyjne. Diagramy UML podzielone są na dwie klasy: strukturalne (opisują strukturę) i behawioralne (zachowanie). Źródło: Wikipedia

17 Diagramy Wprowadzenie W praktyce rzadko kiedy trzeba opracowywać wszystkie diagramy i w większości przypadków korzysta się z mniej niż połowy wyżej wymienionych. Nie powinno modelować się tylko dla samego modelowania, dlatego nie zawsze wszystkie rodzaje są potrzebne. Projektując system informatyczny, rozpoczyna się przeważnie od tworzenia diagramów w następującej kolejności: Przypadków użycia Sekwencji Klas Aktywności Są to najczęściej wykorzystywane diagramy. Pozostałe bywają pomijane, zwłaszcza przy budowaniu niedużych systemów informatycznych. Pytania Jakie diagramy stosowane są najczęściej w modelowaniu systemów informatycznych? Źródło: Wikipedia

18 Wprowadzenie Narzędzie UML można podzielić na dwie podstawowe grupy:
Narzędzia Wprowadzenie Narzędzie UML można podzielić na dwie podstawowe grupy: Narzędzia „wolne” (darmowe) Narzędzie komercyjne Wszystkie komercyjne (i wybrane darmowe) programy oferują możliwość generowania kodu programu na podstawie diagramów UML, a także generowanie diagramów na podstawie kodu (Reverse Engineering – inżynieria zwrotna). Szeroki przegląd narzędzi prezentowany jest m.in. na stronach Wikipedii: Stosowane w ramach zajęć: StarUML (popularny, lecz nierozwijany) -> ArgoUML (alternatywa, ciągle rozwijana) -> Visual Paradigm for UML ->

19 Wprowadzenie Zastosowanie UML Zakres stosowania UML Szkice projektowe
mało formalne selektywne dyskusja o koncepcji rysujemy na tablicy, a nawet na serwetce szkicowanie dla lepszego zrozumienia podczas nauki lub analizy istniejącego systemu, kodu itp Zastosowanie projektowe pełna specyfikacja a potem implementacja systemu z podziałem prac (projektanci – wykonawcy) całość lub fragment przedsięwzięcia można tworzyć projekt od nowa lub dokumentować istniejące projekty używa się specjalizowanych narzędzi Programowanie programowanie w UML -> wykonywalne programy (MDA – model driven architecture) PIM – platform independent model -> PSM – platform specified model Sprawdza się raczej tylko w teorii Executable UML

20 Wprowadzenie Zastosowanie UML Dlaczego warto stosować UML:
Oprogramowanie jest profesjonalnie zaprojektowane i udokumentowane, przed rozpoczęciem etapu kodowania. Dokładnie wiadomo co system będzie „robił” Większa efektywność i niższy koszt implementacji; Błędy „logiczne” projektu wychwycone na etapie modelu; Projekt systemu narzuca implementację, a nie odwrotnie (co się często zdarza); Zmiany w istniejącym systemie wprowadzane są łatwiej, gdy istnieje odpowiednia dokumentacja UML; Zarządzanie implementacją (zmiana organizacji wśród programistów) jest łatwiejsze, gdy istnieje dokumentacja UML; Dokumentacja UML ułatwia komunikację, zarówno na poziomie wykonawca-klient, jak i w ramach struktury wykonawcy. Źródło: Wikipedia

21 Wprowadzenie Inżynieria programowania
Proces wytwarzania oprogramowanie – kontekst dla UML Ciąg uporządkowanych (zaplanowanych) czynności, wytwórczy. Analiza Projektowanie Implementacja Testy Wdrażanie Metody (metodologie, modele) procesów wytwórczych oprogramowania: Kaskadowy Iteracyjny Zwinny (lekki) Źródło: Wikipedia

22 Wprowadzenie Inżynieria programowania
Kaskadowy – projekt podzielony na kolejne czynności Zalety: Uporządkowane działanie Brak niespodzianek (według planu) Określony harmonogram Wady: Mała elastyczność Ograniczony kontakt z klientem (wymagania zostały określone na samym początku) Dawniej etapy te następowały ściśle po kolei (waterfall method). Współczesne podejście do inżynierii programowania zakłada interakcję pomiędzy etapami, powracając na etapie kodowania ponownie do działań związanych z projektowanie. Źródło: Wikipedia

23 Wprowadzenie Inżynieria programowania
Proces iteracyjny (przyrostowy, spiralny, ewolucyjny) – podobne czynności jak w kaskadowym, ale w pierwszej kolejności otrzymujemy ograniczoną funkcjonalność, którą następnie rozwijamy. Zalety częste kontakty z klientem (skrócenie przerw w porównaniu z modelem kaskadowym) Wady Duże zaangażowanie klienta (jest to też zaleta) Potrzeba częsty zmian, także w istniejącym kodzie Źródło: Wikipedia

24 Wprowadzenie Inżynieria programowania
Proces zwinny (lekki) Najważniejsze są ludzie i ich kompetencje. Mniej ważne są narzędzia i metody. Krótkie iteracje. UML szkicowy. Extreem programing Scrum Feature Driven Development Dynamic System Development Method Manifest Zwinnego Tworzenia Oprogramowania (-> Wytwarzając oprogramowanie i pomagając innym w tym zakresie, odkrywamy lepsze sposoby wykonywania tej pracy. W wyniku tych doświadczeń przedkładamy: Ludzi i interakcje ponad procesy i narzędzia. Działające oprogramowanie ponad obszerną dokumentację. Współpracę z klientem ponad formalne ustalenia. Reagowanie na zmiany ponad podążanie za planem. Doceniamy to, co wymieniono po prawej stronie, jednak bardziej cenimy to, co po lewej. Źródło: Wikipedia

25 Wprowadzenie Inżynieria programowania
RUP – rational unified proces Szkielet procesu, szwedzki stół Przypadki – zbiór ogólnych przypadków, do których można się dostosować OpenUP – otwarty proces podobny do RUP Źródło: Wikipedia

26 Wprowadzenie Inżynieria programowania
Miejsce UML: UML dostarcza narzędzi do czynności związanych z procesem tworzenia oprogramowania, niezależnie od metodologii, np.: Analiza wymagań: diagram przypadków użycia na etapie analizy wymagań, diagramów czynności rozwijające przypadków użycia (co się dzieje). Diagram stanów. Dokumentowanie, np. dla projektowania zwinnego dokumentacja może być tworzona „po fakcie” Reverse engeeniering – tworzenie diagramów na podstawie kodu. Źródło: Wikipedia

27 Podstawy notacji Wprowadzenie Notatka Źródło: Wikipedia

28 Podstawy notacji Wprowadzenie Stereotyp - mechanizm rozszerzeń, który może być stosowany do dowolnego elementu UML. Przedstawianie stereotypu <<stereotyp>> Czasami do stereotypów stosuje się ikony: Źródło: Wikipedia

29 Podsumowanie Podsumowanie

30 Wprowadzenie Z dyskusji na forum UML – przykładowe wypowiedzi…
Czy diagramy UML (ogólniej - dokumentacja) muszą być zrozumiałe ? Jeśli tak - czym jest owa "zrozumiałość" i jak ją mierzyć ? Czy istnieją "współczynniki zrozumiałości" na podstawie których można stwierdzić, że dany zestaw diagramów jest "zrozumiały" ? Jeśli diagram zarówno dla autora tego diagramu, jak i odbiorcy / adresata (czytającego ten diagram) oznaczają to samo, to można chyba powiedzieć, że jest on dla tych dwóch osób zrozumiały :-) Matematyk pisze furę wzorów w dwóch celach: - aby przekazać innemu matematykowi swój pomysł - aby móc z duża pewnością powiedzieć laikowi, że prawdę jest ostateczny wniosek, który wyciągnął w pierwszym przypadku obaj musza się z równą biegłością posługiwać językiem matematyki, w drugim nie koniecznie. Jeżeli UML będzie językiem komunikacji pomiędzy projektantem a wykonawcą to obaj muszą go znać równie dobrze. W analizie systemowej pośrednim etapem są modele służące do testowania wariantów i hipotez a końcowym produktem analizy: rekomendacje (nawet proza z zaleceniami). Adresat musi zrozumieć rekomendacje, modeli - tu już nie musi... Tak wiec UML jest dla adresata zrozumiały bardzo dobrze albo nie jest mu potrzebny. Nie wyobrażam sobie sytuacji w której ktoś tylko "częściowo" zrozumiał np. projekt... a jak sobie wyobrażę to ciarki przechodzą :) Ważne rozróżnienie: - rozumienie języka jakim jest UML - rozumienie projektu osobiście przychylam się tezy, że programista nie musi rozumieć istoty projektu ale musi rozumieć treść "zamówienia". Musi rozumieć UML żeby implementować jakaś hierarchę klas ale faktycznie już nie musi rozumieć dlaczego ktoś zaprojektował właśnie taką. Jednak chyba gdzieś prawda leży po środku: murarz nie musi rozumieć tego dlaczego ja chcę mieć piec na środku kuchni ale musi zrozumieć projekt, rysunki, tej kuchni żeby to wykonać. Źródło:

31 Z dyskusji na forum UML – przykładowe wypowiedzi…
Wprowadzenie Wartościowe cytaty z forum: To że UML dopuszcza pewne konstrukcje nie znaczy ze wnoszą one coś do projektu i należy je stosować. Źródło:

32 Przykłady, problemy Przykłady z forum Dziedziną problemu jest internetowa aplikacja do tworzenia galerii zdjęć. Aplikacja ta przeznaczona jest dla szerokiego grona odbiorców, którzy chcę publikować swoje cyfrowe fotografie w Internecie. Aplikacja ma umożliwiać jej użytkownikom rejestrację i logowanie aby można było w pełni korzystać z jej funkcjonalności. Z aplikacji będą korzystać trzy grupy użytkowników. Będą to użytkownicy nie zarejestrowani, zarejestrowani i administratorzy aplikacji. Do przeglądania zawartości galerii zdjęć będą mogli mieć dostęp użytkownicy nie zarejestrowani (…). Uwagi ekspertów: Przypadek użycia to czasownik (wyrażenie odczasownikowe) mówiący o celu czynności (kontaktu z systemem). Jak rozumieć to, że Autor jest komponentem Administratora? Źródło: