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 10

2 Diagramy wdro»enia I Diagramy wdro»enia - stosowane do modelowania zycznej architektury (w przypadku sieci i systemów rozproszonych) i topologii rozwijango systemu komputerowego. Diagramy wdro»enia opisuj : urz dzenia sprz towe (tzw. w zªy), skªadniki oprogramowania, które dziaªaj na w zªach (tzw. artefakty), ª cza komunikacyjne mi dzy poszczególnymi w zªami i artefaktami. Diagramy wdro»enia mog by wykorzystywane do modelowania zarówno lokalnych sieci jak i systemów rozproszonych. Diagramy wdro»enia mog by równie» wykorzystywane do modelowania systemów wbudowanych.

3 Diagramy wdro»enia II W najbardziej trywialnym przypadku, "system" mo»e skªada si z pojedynczego pliku wykonywalnego (.exe), który dziaªa na jednym komputerze. Poni»szy diagram wdro»enia pokazuje taki scenariusz. Artefakt jest rysowany wewn trz w zªa, aby pokaza,»e artefakt jest wdra»any w tym w ¹le.

4 W zªy I W zeª jest albo sprz tem komputerowym albo oprogramowaniem. W zeª jest reprezentowany przez trójwymiarowy ksztaªt w postaci skrzynki (prostopadªo±cian).

5 W zªy II Tworzenie w zªa w visual-paradigm: Aby utworzy w zeª, nale»y wybra Node na pasku narz dzi, a nast pnie klikn na diagram.

6 W zªy sprz towe Aby wskaza,»e dany w zeª jest w zªem reprezentuj cym sprz t, np. Desktop, nale»y oznaczy go przez stereotyp device. Przykªady w zªów sprz towych: komputery stacjonarne, stacje robocze, serwery, dyski, mikrokontrolery itp.

7 W zªy oprogramowania Przykªady w zªów oprogramowania: systemy operacyjne, oprogramowanie serwera WWW (np. Apache, Microsoft Internet Information Server), ±rodowiska programistyczne (np. Java Runtime Environment -JRE). W zeª reprezentuj cy oprogramowanie posiada stereotyp execution environment.

8 Zagnie»d»anie w zªów I Poniewa» ±rodowisko wykonania samo musi dziaªa na danym sprz cie, to cz sto w diagramach wdro»eniowych w zeª oprogramowania zagnie»d»a si w obr bie w zªa sprz towego. Np.

9 Zagnie»d»anie w zªów II Tak jak w zeª oprogramowania (lub inny w zeª sprz towy) mog by zagnie»d»one w obr bie w zªa sprz towego, równie» w zeª oprogramowania mo»e by zagnie»d»ony w innym w ¹le oprogramowania. Na przykªad, w zeª oprogramowania Apache HTTP Server jest zagnie»d»ony w w ¹le oprogramowania Debian Linux 8.2.

10 Zagnie»d»anie w zªów III Zagnie»d»enie w w ¹le sprz towym, w zeª oprogramowania, w którym zagnie»d»ony jest inny w zeª oprogramowania:

11 Zagnie»d»anie w zªów IV W zeª oprogramowania web server jest zagnie»d»ony w w ¹le oprogramowania OS, a ten jest zagnie»d»ony w w ¹le sprz towym. Uwaga! W obydwu w zªach oprogramowania stereotyp execution environment zostaª zast piony przez stereotyp specyczny dla aplikacji i zdeniowany przez u»ytkownika!.

12 The execution environment can also be shown outside of the hardware node, with a composition arrow linking it back to the hardware node (note that the same notations can be used to model a nested hardware node, such as a graphics card or a hard disk drive inside a computer). The relationship between the device Linux Server and the execution environment Apache HTTP Server could be modeled as shown below. Note that the UML specication encourages users to dene their own stereotypes for standard execution environments. The examples given in the UML Superstructure document include OS, database system, and J2EE container. These stereotypes could be dened in a prole (see the page on prole diagrams).

13 Relacja kompozycji I W zeª reprezentuj cy oprogramowanie mo»e by równie» powi zany z w zªem sprz towym poprzez relacje kompozycji. Relacja kompozycji reprezentowana jest przez strzaªk zako«czon wypeªnionym rombem i skierowan ku w zªowi sprz towemu. Uwaga! Te same zapisy mog by stosowane do modelowania zagnie»d»onych w zªów sprz towych, takich jak karta graczna czy wewn trzny dysk twardy komputera.

14 Relacja kompozycji II Zale»no± pomi dzy urz dzeniem Linux Server i ±rodowiskiem wykonawczym HTTP Apache Server mo»e by modelowana nast puj co:

15 W zeª instancji I W zeª instancji - mo»na go odró»ni od "zwykªego" w zªa po tym,»e jego nazwa jest podkre±lona i ma po dwukropku okre±lony typ w zªa, tzn. node-name : node-type

16 W zeª instancji II W zeª instancji mo»e mie okre±lon nazw, ale nie musi.

17 W zeª instancji III Diagram wdro»enia dla farmy serwerów webowych:

18 W zeª instancji IV Tworzenie instancji w zªa w visual-paradigm: Aby utworzy instancje w zªa, nale»y: wybra Instance Specication na pasku narz dzi, a nast pnie klikn na diagram:

19 W zeª instancji V Tworzenie instancji w zªa w visual-paradigm, cd.: ustali klasykator dla instancji poprzez wybranie polecenia Select Classier > Select Classier z, np., menu podr cznego:

20 W zeª instancji VI Tworzenie instancji w zªa w visual-paradigm, cd.: Pojawi si okno dialogowe Instance Specication Specication z domy±lnie otwart zakªadk Classiers. Wybierz przycisk Add

21 W zeª instancji VII Tworzenie instancji w zªa w visual-paradigm, cd.: Pojawi si okno dialogowe Select Classier. Wybierz klasykator i zatwerd¹ OK.

22 Artefakty I Artefakt - dowolny rodzaj pliku, który stanowi cz ± projektowanego oprogramowania lub jest przez nie wykorzystywany. Przykªady artefaktów: skrypty, pliki konguracyjne, pliki tekstowe, pliki pomocy, pliki ¹ródªowe, pliki wykonawcze (np. skompilowany wersja komponentu), pliki bibliotek, pliki bazy danych, itp. Artefakt, podobnie jak klasa, mo»e posiada atrybuty i operacje.

23 Artefakty II Artefakt jest reprezentowany przez prostok t zawieraj cy nazw artefaktu, stereotyp artefakt oraz maª ikon dokumentu.

24 Wdro»enie artefaktu I Istniej dwie alternatywne metody pokazuj ce wdro»enie artefaktu przez w zeª: I Artefakt jest umieszczony poza w zªem i wskazywana jest zale»no± pomi dzy artefaktem i w zªem (linia przerywana biegn ca od artefaktu do w zªa z otwart strzaªk wskazuj c na w ¹le). Stereotyp deploy jest u»ywany, aby podkre±li zwi zek.

25 Wdro»enie artefaktu II II Artefakt jest umieszczony wewn trz w zªa:

26 Zale»no± miedzy artefakatmi W przypadku, gdy wi cej ni» jeden artefakt jest wdro»ony na danym w ¹le sprz towym, lub nawet w przypadkach, gdy artefakty s rozmieszczone na ró»nych docelowych w zªach sprz towych, mo»e istnie zale»no± mi dzy nimi (czyli jeden artefakt opiera si na usªugach ±wiadczonych przez inny artefakt). Zale»no± t reprezentuje si przy pomocy strzaªki prowadz cej od artefaktu, który wymaga usªugi do artefaktu, który j dostarcza.

27 Relacja ze stereotypem manifest Je±li artefakt oznacza zyczne wdro»enie elementu pakietowego takiego jak np. komponent, to mówi si,»e artefakt reprezentuje (ang. manifest) ten element. Uwaga! nazwa artefaku nie musi koniecznie by takie same jak nazwa elementu pakietowego, który reprezentuje (chocia» nazwy s cz sto podobne).

28 Stereotypy artefaktów Stereotypy artefaktów: script - skrypty systemowe document - dokumenty wykorzystywane w systemie file - pliki source - pliki z kodem ¹ródªowym executable - programy wykonywalne library - biblioteki programów table - zyczne bazy danych i tabele baz danych subsystem - podsystemy service - komponenty przetwarzaj ce

29 Instancja artefaku Artefakt po wdro»eniu do w zªa sprz towego lub okre±lonego ±rodowiska wykonawczego staje si instancj. Instancje rozpoznajemy, podobnie jak w przypadku instancji w zªa, po tym,»e nazwa artefaktu jest podkre±lona, a po dwukropku podany jest typ.

30 Relacja Kompozycji dla artefaktu Artefakty mog by poª czone ze sob za pomoc relacji kompozycji, ze znaczeniem jak w diagramie klas. Kompozycja jest przedstawiony za pomoc linii ci gªej, który ª czy artefakt zawierany z artefaktem zawieraj cym, zako«czonej strzaªk w ksztaªcie rombu skierowan ku artefaktowi zawieraj cemu.

31 cie»ki komunikacyjne (ang. communication paths) W zeª mo»e by poª czony z innym w zªem za pomoc zwi zków reprezentuj cych ±cie»ki komunikacyjne, co oznacza,»e w zªy mog si komunikowa. cie»ka komunikacyjna jest przedstawiona jako linia ci gªa ª cz ca dwa w zªy. cie»ka komunikacyjna mo»e by równie» u»ywana, aby pokaza,»e komunikacja odbywa si pomi dzy w zªami oprogramowania.

32 Specykacja wdro»enia (ang. deployment specication) Specykacja wdro»enia - szczególny przypadek artefaktu, który okre±la parametry maj ce by u»ywane przez inny artefakt (zwykle jest to plik wykonywalny lub skrypt) w czasie jego wykonywania, albo w celu ustalenia konguracji danego artefaktu na w ¹le (zarówno sprz towym jak i oprogramowania). Specykacja wdro»enia - reprezentowana przez prostok t i wygl da jak artefakt, z tym»e stereotyp artifact jest zast piony przez stereotyp deployment spec.

33 Specykacja wdro»enia (ang. deployment specication) Inny sposób na modelowanie zale»no±ci z poprzedniego slajdu: