Podstawy modelowania w j zyku UML

Transkrypt

1 Podstawy modelowania w j zyku UML dr hab. Bo»ena Wo¹na-Szcze±niak Akademia im. Jan Dªugosza bwozna@gmail.com Wykªad 1

2 Cel J zyk UML to j zyk modelowania systemów informatycznych i ma w in»ynierii oprogramowania bardzo du»e znaczenie. W trakcie wykªadu zostan przedstawione nast puj ce zagadnienia: Denicja i historia UML Widoki modelu 4+1 Kruchtena Diagramy UML - obecny standard to wiczenia bed realizowane za pomoc narz dzia: Visual Paradigm Community Edition Osi glany z Przed przyst pieniem do wicze«nale»y zapozana si z wykªadem.

3 Literatura - strony, fora, blogi itp. I G. Booch, J. Rumbaugh, I. Jacobson I: The Unied Modeling Language User Guide (2nd Edition). Addison-Wesley Professional, Eric J. Naiburg, Robert A. Maksimchuk: UML dla zwykªych ±miertelników. PWN, Strona domowa UML: Specykacja j zyka: UML 2.5.1: Tutoriale: przedmiot:in»ynieria oprogramowania Notatki AGH: Autor: Beata Fr czek.

4 Modelowanie - zagadnienia zwi zane Denicja modelu i modelowania Znaczenie modelu

5 Model, modelowanie - denicja Model przedstawia pewien fragment rzeczywisto±ci w uproszczony, ale formalny i uporz dkowany sposób. Model poprzez system zaªo»e«(dotycz cych wygl du i zachowania), poj (zwi zanych z dan dziedzin i wymaganiami) oraz zale»no±ci mi dzy nimi pozwala lepiej zrozumie zªo»on rzeczywisto±. Modelowanie to proces prowadz cy do zdeniowania/skonstruowania modelu.

6 Znaczenie modelu Umo»liwia odzwierciedlenie/upraszczenie rzeczywisto±ci. Umo»liwia przejrzyst prezentacj projektu. Pozwala zapanowa nad zªo»ono±ci projektu Umo»liwia wychwycenie problemów projektowych, które mogªyby wypªyn podczas kodowania, znacznie utrudniaj c prac, b d¹ te» powoduj c konieczno± przeprojektowania zakodowanej ju» aplikacji. Uªatwia komunikacj pomi dzy klientem i realizatorem (twórc ). Podnosi jako± oprogramowania: niezawodno±, adaptacyjno±.

7 Znaczenie modelu ródªo:

8 Denicja UML UML znaczy UNIFIED MODELING LANGUAGE, czyli zunikowany j zyk modelowania. UML to znormalizowany graczny j zyk modelowania, sªu» cy do opisu projektu systemu informatycznego. UML mo»e by stosowany do wizualizacji, specykowania, tworzenia, analizy i dokumentowania procesu budowy (obiektowego) systemu informatycznego.

9 Denicja UML wedªug OMG The Unied Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The UML oers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components.

10 UML - zastosowania UML znajduje zastosowanie w nast puj cych obszarach: Systemy informatyczne dla przedsi biorstw Bankowo± i usªugi nansowe Telekomunikacja Obronno±, np. lotnicze systemy bojowe Transport Sprzeda» Nauka i badania Rozproszone usªug internetowych itp.

11 Twórcy UML Grady Booch Ivar Jacobson James Rumbaugh ródªo: wikipedia.org/ wiki/grady_booch ródªo: https: //en.wikipedia. org/wiki/ivar_ Jacobson ródªo: wikipedia.org/ wiki/grady_booch

12 Twórcy UML Grady Booch. Gªówny szef Rational Corp oraz redaktor magazynu Software Development. Opracowaª metod obiektow Object Oriented Analysis and Design (OOAD) zwan metod Boocha. Wi cej informacji: Ivar Jacobson. Szwedzki naukowiec, informatyk i in»ynier oprogramowania, znany jako gªówny twórca Object Oriented Software Engineering (OOSE) oraz RUP (Objectory, Rational Unied Process). Wi cej informacji: James Rumbaugh. Ameryka«ski naukowiec, informatyk i specjalista metodologii obiektowych. Znany jest jako twórca Object Modeling Technique (OMT). Wi cej informacji:

13 Historia UML I Wyczerpuj cy materiaª dotycz cy historii UML mo»na znale¹ w ksi»ce: James Rumbaugh, Ivar Jacobson, Grady Booch. The Unied Modeling Language Reference Manual. Second Edition. Addison Wesley, Oto wybrane informacje: poªowa lat istnieje ponad 50 konkurencyjnych metod obiektowych analizy i projektowania oprogramowania. Powszechnie stosowane metody obiektowe to metody Grady Boocha (metoda OOAD), James Rumbaugha (metoda OMT) oraz Ivara Jacobsona (metoda OOSE): Opracowanie ujednoliconego j zyka modelowania wydaje si niezb dne.

14 Historia UML II 1994, Grady Booch, Ivar Jacobson oraz James Rumbaugh rozpoczynaj prac w Rational Software Corporation Pa¹dziernik rma Rational Software Corporation (od lutego 2003 cz ± IBM) rozpocz ªa ocjalne prace nad UML opublikowanie roboczej wersji UML opublikowanie wersji UML 0.9; integracja metod obiektowych Boocha, metody OMT (ang. Object Modeling Technique, J. Rumbaugh), metody OOSE (ang. Object-Oriented Software Engineering, Ivar Jacobsen) oraz elementów innych istniej cych metod obiektowych powstaje konsorcjum rm (HewlettPackard, IBM, Microsoft, Oracle, Rational SC). Wynikiem wspóªpracy staje si UML 1.0.

15 Historia UML III UML 1.0 zostaje przekazany grupie Object Management Group (OMG), która do dzisiaj zajmuje si jego rozwojem. Kolejne lata - OMG wypracowuje wersje 1.1, 1.2, 1.3, 1.4, Wersja zostaªa poddana standaryzacji ISO/IEC i jest ostatni wersj z gaª zi 1.x oznaczon numerem 1.5. Czerwiec OMG publikuje UML 2.0 ª cz c wysiªki ponad stu organizacji (po raz pierwszy zastosowano konwencj dwóch uzupeªniaj cych si specykacji: Infastructure i Superstructure, znacznie usprawniono modelowanie dla systemów wbudowanych (ang. embedded system). Sierpie« OMG wydaje wersje 2.1.1

16 Historia UML IV Luty OMG publikuje UML 2.2. Maj OMG publikuje UML 2.3. Sierpie« OMG publikuje UML zostaje znormalizowana (ISO/IEC i ). Pa¹dziernik OMG publikuje UML 2.5 jako wersje "In process". Czerwiec OMG publikuje ocjaln wersj UML 2.5. Grudzie« OMG publikuje ocjaln wersj UML

17 Model UML systemu Model UML systemu jest wyra»any przy pomocy diagramów przedstawiaj cych rozmaite cz ±ci i aspekty modelu. Diagramy ró»ni si : rodzajem - ró»ne typy diagramów odpowiadaj ró»nym sposobom widzenia systemu stopniem szczegóªowo±ci - ka»dy diagram tworzony jest w konkretnym celeu w konkretnej fazie rozwijania oprogramowania; inny poziom szczegóªowo±ci zawiera b dzie konsultowany z u»ytkownikami diagram z fazy okre±lania wymaga«, a inny diagram maj cy by szczegóªow specykacj elementu systemu, przeznaczony do automatycznej generacji kodu na jego podstawie

18 Model UML systemu Diagramy UML pozwalaj na ilustracj rozmaitych aspektów systemu: struktury - diagramy deniuj ce wyª cznie statyczne aspekty systemu. zachowania - diagramy deniuj ce wyª cznie dynamiczne aspekty systemu. zachowania z uwzgl dnieniem struktury - diagramy ilustruj ce ª cznie aspekty dynamiczne i statyczne.

19 Obecna specykacja UML wyró»nia 13 rodzajów diagramów w nast puj cej hierarchii: Diagramy UML - obecna specykacja

20 Diagramy UML - obecna specykacja UML... Diagramy UML Diagramy UML - obecna specykacja Obecna specykacja UML wyró»nia 13 rodzajów diagramów w nast puj cej hierarchii: Omówione b d nast puj ce diagramy: Diagramy strukturalne (ang. Structure Diagram): Diagram klas (ang. class diagram), Diagram obiektów (ang. object diagram), Diagram pakietów (ang. package diagram), Diagram struktur zªo»onych (ang. composite structure diagram), Diagram komponentów (ang. component diagram), Diagram wdro»enia (ang. deployment diagram).

21 Diagramy UML - obecna specykacja UML... Diagramy UML Diagramy UML - obecna specykacja Obecna specykacja UML wyró»nia 13 rodzajów diagramów w nast puj cej hierarchii: Diagramy dynamiki/zachowania (ang. Behavior Diagram): Diagram przypadków u»ycia (ang. use case diagram); Diagram aktywno±ci (czynno±ci) (ang. activity diagram); Diagramy maszyny stanowej (ang. state machine diagram); Diagramy interakcji (ang. interaction diagram) - diagram sekwencji (ang. sequence diagram), diagram komunikacji (ang. communication diagram), diagramy czasowe (ang. timing diagram), przegl dowe diagramy interakcji (ang. interaction overview diagrams).

22 Elementy skªadowe specykacji UML Istniej cztery cz ±ci specykacji UML 2.x: Superstruktura - deniuje notacj i semantyk dla diagramów i elementów ich modelu. Istotna dla ka»dego, kto modeluje w UML'u i chce, aby model byª poprawnie rozumiany. Infrastruktura - deniuje metamodel j zyka UML, na którym opiera si superstruktura. Wa»na przede wszystkim dla konstruktorów oprogramowania do modelowania. J zyk OCL (ang. Object Constraint Language) - okre±la zasady dziaªania elementów modelu. Interakcja diagramów UML - deniuje wspóªdziaªanie pomi dzy ukªadami diagramów UML 2.x.

23 Perspektywa 4+1 I Autorzy UML rozró»niaj pi perspektyw spojrzenia na system informatyczny i przyporz dkowuj im odpowiednie rodzaje diagramów UML: perspektywa przypadków u»ycia (zakres i funkcjonalo± systemu) - opisuje funkcjonalno±, jak powinien dostarcza system, widzian przez jego u»ytkowników, czyli opisuje zachowanie systemu obserwowane z zewn trz; diagramy przypadków u»ycia, diagramy pakietów. perspektywa projektowa (logiczna, budowa systemu) - opisuje sposób realizacji funkcjonalno±ci, struktur systemu widzian przez projektanta (tj. klasy, interfejsy, kooperacje); diagramy klas, obiektów, pakietów, struktur zªo»onych.

24 Perspektywa 4+1 II perspektywa procesowa (dynamiczna, zachowanie)- zawiera podziaª systemu na procesy (czynno±ci) i procesory (jednostki wykonawcze) oraz opisuje wªa±ciwo±ci pozafunkcjonalne systemu i sªu»y przede wszystkim programistom i integratorom; diagramy aktywno±ci (czynno±ci), maszyny stanowej, pakietów sekwencji, komunikacji, czasowe oraz przegl dowe diagramy interakcji. perspektywa implementacyjna (software) - opisuje poszczególne moduªy i ich interfejsy wraz z zale»no±ciami; perspektywa ta jest przeznaczona dla programisty (komponenty i pliki, zarz dzanie konguracj ); diagramy komponentów, diagramy pakietów.

25 Perspektywa 4+1 III perspektywa wdro»eniowa (rozlokowanie, sprz t) - deniuje zyczny podziaª elementów systemu i ich rozmieszczenie w infrastrukturze, czyli dotyczy zycznej realizacji sprz towej systemu; perspektywa taka sªu»y integratorom i instalatorom systemu; diagramy wdro»enia, diagramy pakietów.

26 Diagram klas Diagramy klas przedstawiaj statyczny widok modelu, lub jego cz ±ci. Diagramy klas przedstawiaj struktur projektowanego systemu, lub jego cz ±ci jako zbiór klas i interfesów wraz z ich atrybutami, funkcjami, ograniczeniami oraz powi zaniami mi dzy nimi.

27 Diagram klas Denicja Klasa jest elementem, który okre±la cechy (wªasno±ci) i zachowanie, które obiekt jest w stanie wygenerowa. Zachowanie opisane jest przy pomocy komunikatów wraz z operacjami, które s odpowiednie dla ka»dego komunikatu. Klasy mog mie równie» denicje ogranicze«, oznaczonych warto±ci i stereotypów.

28 Notacja klas Klasa jest reprezentowana przez prostok t z wydzielonymi przedziaªami na: nazw atrybuty operacje (metody).

29 Notacja klas Dost pno± metod lub atrybutów: + publiczna - element jest widoczny z ka»dego miejsca w systemie # chroniona - element jest widoczny we wªasnej klasie i jej podklasach prywatna - element jest widoczny tylko we wlasnej klasie publiczny wewn trz pakietu - element jest widoczny tylko wewn trz wªasnego pakietu

30 Operacje (metody) Nazwy operacji mog wygl da nast puj co: [widoczno± ] nazwa [(parametry)] [: typ warto±ci zwracanej] [{ustawienia}] gdzie parametry: nazwa [: typa parametru] Poprawne nazwy metod to: display +display +display() +getposition : Point +getposition(): Point +setposition(pos: Point) +setposition(pos: Point): void

31 Interfejs (Klasy abstrakcyjne) Denicja Interfejs to klasa, która posiada jedn lub wi cej metod (operacji) nieposiadaj cych ciaªa, tzw. metod wirtualnych. Metody nieposiadaj ce ciaªa s jedynie deklaracjami, zapowiedziami,»e klasa dziedzicz ca po interfejsie (klasie abstrakcyjnej) dostarczy ciaªa takiej metody, w przeciwnym razie sama te» b dzie klas abstrakcyjn. Uwaga! nie mo»na tworzy instancji (obiektów) klas abstrakcyjnych.

32 Przykªad klasy abstrakcyjnej w C++ I #include <i o s t r e a m > using namespace s t d ; // K l a s a Podstawowa c l a s s Shape { public : // f u n k c j a c z y s t o w i r t u a l n a v i r t u a l i n t g e t A r e a ( ) = 0 ; void setwidth ( i n t w) { width = w ; } void s e t H e i g h t ( i n t h ) { h e i g h t = h ; } protected : i n t width ; i n t h e i g h t ; } ;

33 Przykªad klasy abstrakcyjnej w C++ II // K l a s y wyprowadzone c l a s s R e c t a n g l e : public Shape { public : i n t g e t A r e a ( ) { return ( width h e i g h t ) ; } } ; c l a s s T r i a n g l e : public Shape { public : i n t g e t A r e a ( ) { return ( width h e i g h t ) / 2 ; } } ;

34 Przykªad klasy abstrakcyjnej w C++ III i n t main ( void ) { R e c t a n g l e Rect ; T r i a n g l e T r i ; Rect. s etwidth ( 5 ) ; Rect. s e t H e i g h t ( 7 ) ; cout << " P ole c a l k o w i t e p r o s t o k a t a : " << Rect. g e t A r e a ( ) << e n d l ; T r i. s etwidth ( 5 ) ; T r i. s e t H e i g h t ( 7 ) ; cout << " P ole c a l k o w i t e t r o j k a t a : " << T r i. g e t A r e a ( ) << e n d l ; } return 0 ;

35 Interfejs (Klasy abstrakcyjne) W UML-u klasy abstrakcyjne niewiele ró»ni si od normalnych klas. Jedyn widoczn ró»nica jest ich nazwa, napisana kursyw.

36 Interfejs Klasy abstrakcyjne mog by równie» wizualizowane jako okr gi bez pokazywania jawnych operacji szczegóªowych.

37 Interfejs Interfejs wymaga, aby klasa realizuj ca (u nas klasa Triangle oraz klasa Rectangle) go dostarczyªa implementacji wszystkich okre±lonych w nim operacji. Co wi cej, operacje te musz w klasie mie takie same nazwy jak w interfejsie. Poª czenie pomi dzy Interfejsem a klas realizuj c przedstawiane jest na diagramie za pomoc strzaªki z przerywan lini i niezamalowanym grotem. W przypadku, gdy interfejs prezentowany jest w postaci kuli, zwi zek realizacji pomi dzy klas a interfejsem przedstawia si za pomoc linii ci gªej.

38 Zwi zki mi dzy klasami Asocjacja (ang. Associations) Uogólnienie, dziedziczenie (ang. Generalizations) Agregacja (ang. Aggregations) Kompozycja (ang. Composite aggregation) Zagnie»d»enia (ang. Nestings) Realizacja na kolejnym wykªadzie...