Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00292 005849 13633911 na godz. na dobę w sumie
Język inżynierii systemów SysML. Architektura i zastosowania. Profile UML 2.x w praktyce - książka
Język inżynierii systemów SysML. Architektura i zastosowania. Profile UML 2.x w praktyce - książka
Autor: , Liczba stron: 176
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-2541-3 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> uml - programowanie
Porównaj ceny (książka, ebook, audiobook).

SysML, czyli System Modeling Language, to nowy obiektowy język modelowania systemów. W prostej linii wywodzi się on z języka UML, który stanowił do tej pory swego rodzaju standard w inżynierii oprogramowania. SysML został dostosowany do specyficznych potrzeb inżynierów systemowych, zajmujących się projektami w sposób całościowy. Pozwala na specyfikację, analizę, projektowanie i weryfikację złożonych systemów różnego rodzaju, a dzięki swoim dużym możliwościom i elastyczności w ciągu kilku lat zdołał zdobyć liczną rzeszę profesjonalnych użytkowników.

Opanowanie arkanów posługiwania się tym narzędziem ułatwi książka 'Język inżynierii systemów SysML. Architektura i zastosowania. Profile UML 2.x w praktyce'. Pierwsza na polskim rynku pozycja poświęcona SysML stanowi jednocześnie doskonałe wprowadzenie w zagadnienia inżynierii systemowej, zawiera szczegółowy opis architektury języka oraz prezentuje najważniejsze koncepcje związane z jego zastosowaniem. Książka niemal w całości przedstawia różnego typu diagramy, a zamieszczone w niej dodatki ułatwią zrozumienie nawet najbardziej skomplikowanych zagadnień i umożliwią sprawne poruszanie się po treści oraz uzupełnienie wiedzy w oparciu o publikacje innych autorów.

Poznaj język SysML, opierając się na wiedzy najlepszych specjalistów w tej dziedzinie!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Jêzyk in¿ynierii systemów SysML. Architektura i zastosowania. Profile UML 2.x w praktyce Autorzy: Stanis³aw Wrycza, Bartosz Marcinkowski ISBN: 978-83-246-2541-3 Format: 158235, stron: 176 SysML, czyli System Modeling Language, to nowy obiektowy jêzyk modelowania systemów. W prostej linii wywodzi siê on z jêzyka UML, który stanowi³ do tej pory swego rodzaju standard w in¿ynierii oprogramowania. SysML zosta³ dostosowany do specyficznych potrzeb in¿ynierów systemowych, zajmuj¹cych siê projektami w sposób ca³oœciowy. Pozwala na specyfikacjê, analizê, projektowanie i weryfikacjê z³o¿onych systemów ró¿nego rodzaju, a dziêki swoim du¿ym mo¿liwoœciom i elastycznoœci w ci¹gu kilku lat zdo³a³ zdobyæ liczn¹ rzeszê profesjonalnych u¿ytkowników. Opanowanie arkanów pos³ugiwania siê tym narzêdziem u³atwi ksi¹¿ka „Jêzyk in¿ynierii systemów SysML. Architektura i zastosowania. Profile UML 2.x w praktyce”. Pierwsza na polskim rynku pozycja poœwiêcona SysML stanowi jednoczeœnie doskona³e wprowadzenie w zagadnienia in¿ynierii systemowej, zawiera szczegó³owy opis architektury jêzyka oraz prezentuje najwa¿niejsze koncepcje zwi¹zane z jego zastosowaniem. Ksi¹¿ka niemal w ca³oœci przedstawia ró¿nego typu diagramy, a zamieszczone w niej dodatki u³atwi¹ zrozumienie nawet najbardziej skomplikowanych zagadnieñ i umo¿liwi¹ sprawne poruszanie siê po treœci oraz uzupe³nienie wiedzy w oparciu o publikacje innych autorów. • Struktura, historia i zastosowania jêzyka SysML • Diagram wymagañ systemowych • Diagram definiowania bloków • Diagram bloków wewnêtrznych • Diagram parametryczny • Rozszerzony diagram czynnoœci • Diagramy UML4SysML Poznaj jêzyk SysML, opieraj¹c siê na wiedzy najlepszych specjalistów w tej dziedzinie! Spis treĈci Wstöp .............................................................................................. 7 Rozdziaä 1. Architektura jözyka SysML ............................................................... 9 1.1. Wprowadzenie do jĊzyka SysML ............................................................................ 9 1.2. Powstanie i ewolucja jĊzyka SysML ...................................................................... 10 1.3. SysML a metodologie i narzĊdzia tworzenia systemów ........................................ 12 1.4. InĪynieria systemów .............................................................................................. 13 1.5. Struktura jĊzyka SysML ........................................................................................ 14 Rozdziaä 2. Diagram wymagaþ systemowych .................................................... 19 2.1. Znaczenie wymagaĔ w procesie tworzenia systemu .............................................. 19 2.1.1. Klasyfikacja wymagaĔ ................................................................................ 20 2.1.2. Metody dokumentowania wymagaĔ systemowych ..................................... 21 2.2. Elementy diagramu wymagaĔ systemowych ......................................................... 22 2.2.1. Kategorie modelowania .............................................................................. 22 2.2.2. Wymagania ................................................................................................. 23 2.2.3. Rodzaje związków pomiĊdzy wymaganiami .............................................. 24 2.2.4. ZagnieĪdĪenie ............................................................................................. 25 2.2.5. ZaleĪnoĞü wyprowadzania .......................................................................... 28 2.2.6. ZaleĪnoĞü realizacji .................................................................................... 28 2.2.7. ZaleĪnoĞü powielania .................................................................................. 30 2.2.8. ZaleĪnoĞü weryfikowania ........................................................................... 32 2.2.9. ZaleĪnoĞü precyzowania ............................................................................. 33 2.2.10.ZaleĪnoĞü Ğledzenia .................................................................................... 34 2.2.11.Analiza porównawcza zaleĪnoĞci ............................................................... 37 2.3. Zaawansowana specyfikacja wymagaĔ oraz związków ......................................... 39 2.3.1. Tabelaryczna specyfikacja wymagaĔ ........................................................... 40 2.3.2. Tabelaryczna specyfikacja związków .......................................................... 41 2.3.3. Rozszerzone wymagania systemowe ........................................................... 41 2.3.4. Stereotypowanie rozszerzonych wymagaĔ systemowych ............................ 42 Rozdziaä 3. Diagram definiowania bloków ......................................................... 45 3.1. Rola bloków w dokumentacji systemu .................................................................. 45 3.2. Elementy diagramu definiowania bloków .............................................................. 46 3.2.1. Kategorie modelowania .............................................................................. 46 3.2.2. Bloki ........................................................................................................... 48 3.2.3. Cechy bloku ................................................................................................ 48 3.2.4. Sekcje bloku ............................................................................................... 50 4 Jözyk inĔynierii systemów SysML. Architektura i zastosowania 3.2.5. Związki ....................................................................................................... 51 3.2.6. Typy wartoĞci ............................................................................................. 54 3.3. Zaawansowana specyfikacja bloków ..................................................................... 56 3.3.1. Dodatkowe sekcje bloku ............................................................................. 56 3.3.2. Bloki abstrakcyjne ...................................................................................... 58 3.3.3. Bloki asocjacyjne ........................................................................................ 59 3.3.4. Bloki ograniczeĔ ......................................................................................... 60 3.3.5. Alokacje ...................................................................................................... 60 Rozdziaä 4. Diagram bloków wewnötrznych ....................................................... 65 4.1. Elementy diagramu bloków wewnĊtrznych ........................................................... 65 4.1.1. Kategorie modelowania .............................................................................. 65 4.1.2. CzĊĞci ......................................................................................................... 67 4.1.3. Klasyfikacja portów .................................................................................... 67 4.1.4. Pojedyncze porty transmisyjne ................................................................... 68 4.1.5. Zagregowane porty transmisyjne ................................................................ 69 4.1.6. SprzĊganie zagregowanych portów transmisyjnych ................................... 71 4.1.7. Porty standardowe ...................................................................................... 71 4.2. Zaawansowane elementy diagramów bloków wewnĊtrznych ................................ 74 4.2.1. Przywoáanie bloku/czĊĞci ........................................................................... 74 4.2.2. WartoĞü początkowa ................................................................................... 76 4.2.3. WĊzeá bloku asocjacyjnego ........................................................................ 77 4.2.4. Przepáyw zasobów ...................................................................................... 78 4.2.5. Definiowanie portów w sekcjach czĊĞci/bloku ........................................... 79 Rozdziaä 5. Diagram parametryczny .................................................................. 81 5.1. Znaczenie parametrów w dokumentowaniu systemu ............................................. 81 5.2. Elementy diagramu parametrycznego .................................................................... 82 5.2.1. Kategorie modelowania .............................................................................. 82 5.2.2. Bloki ograniczeĔ ......................................................................................... 83 5.2.3. Cechy ograniczające ................................................................................... 86 5.2.4. Przypisywanie wartoĞci cechom ograniczającym ....................................... 86 5.2.5. Funkcje celowe ........................................................................................... 88 5.2.6. Miary efektywnoĞci .................................................................................... 91 Rozdziaä 6. Rozszerzony diagram czynnoĈci ....................................................... 95 6.1. Znaczenie czynnoĞci w modelowaniu systemów ................................................... 95 6.2. Elementy diagramu czynnoĞci ............................................................................... 96 6.2.1. Kategorie modelowania .............................................................................. 96 6.2.2. Charakterystyka pierwotnych kategorii modelowania ................................ 96 6.3. Rozszerzenia diagramów czynnoĞci w jĊzyku SysML ........................................ 103 6.3.1. Systemy ciągáe i strumieniowe ................................................................. 103 6.3.2. WartoĞci kontrolne i operatory sterowania ............................................... 104 6.3.3. Buforowanie danych i sterowania ............................................................. 106 6.3.4. Parametr opcjonalny ................................................................................. 109 6.3.5. PrzepustowoĞü .......................................................................................... 111 6.3.6. PrawdopodobieĔstwo ................................................................................ 112 6.3.7. Warunki wstĊpne i koĔcowe ..................................................................... 113 6.3.8. Blokowa notacja czynnoĞci ...................................................................... 116 Rozdziaä 7. Diagramy UML4SysML ................................................................. 119 7.1. Rodzaje diagramów UML4SysML ...................................................................... 119 7.2. Diagram przypadków uĪycia ............................................................................... 120 7.3. Diagram maszyny stanowej ................................................................................. 124 7.4. Diagram sekwencji .............................................................................................. 127 7.5. Diagramy pakietów .............................................................................................. 133 7.6. Diagramy UML 2.x nieujĊte w specyfikacji jĊzyka SysML ................................ 136 Spis treĈci 5 Dodatek A Säownik polsko-angielski .............................................................. 139 Dodatek B Säownik angielsko-polski .............................................................. 147 Dodatek C Spis rysunków .............................................................................. 155 Dodatek D Spis tabel .................................................................................... 159 Dodatek E Literatura ..................................................................................... 161 Skorowidz .................................................................................... 167 Rozdziaä 2. Diagram wymagaþ systemowych 2.1. Znaczenie wymagaþ w procesie tworzenia systemu Jednym z najbardziej newralgicznych etapów procesu tworzenia systemu jest groma- dzenie, specyfikacja, priorytetyzacja oraz akceptacja wymagaĔ wobec projektowanego bądĨ uĪytkowanego systemu. Wymagania są wyraĪonymi z sposób formalny potrze- bami klienta — funkcjonalnoĞciami lub cechami, które system winien speániaü (OMG, 2008). Pozyskiwanie wymagaĔ stanowi podstawĊ caáego procesu budowy systemów, a od rezultatów tego etapu uzaleĪniony jest dalszy sposób realizacji projektu; dobrze okreĞlone wymagania zapewniają lepszą jakoĞü przyszáego oprogramowania i, w kon- sekwencji, wyĪszy poziom satysfakcji zamawiającego (Wojciechowski, 2009). W inĪynierii oprogramowania specyfikacja wymagaĔ systemowych (ang. requirements specification) i ich dokumentowanie jest integralną czĊĞcią wszystkich cykli Īycia systemu informatycznego. Z podejĞciem obiektowym, jĊzykami UML i SysML ĞciĞle związana jest metodyka RUP (ang. Rational Unified Process), którą syntetyzuje itera- cyjno-przyrostowy cykl Īycia systemu, przedstawiony na rysunku 2.1. Jedną z dziewiĊ- ciu dyscyplin cyklu Īycia RUP — i zarazem jedną z szeĞciu dyscyplin podstawowych — jest wáaĞnie specyfikacja wymagaĔ. Poprawna specyfikacja wymagaĔ jest niezbĊdna w dalszych fazach pracy nad syste- mem, wszelkie báĊdy zaĞ, popeánione na tym etapie, są trudne — a w konsekwencji kosztowne — do usuniĊcia w przyszáoĞci. Wymagania mogą byü uzyskane bezpoĞred- nio od zleceniodawcy wykonania systemu w drodze wywiadu bądĨ analizy strategicznej dokumentacji firmy. 20 Jözyk inĔynierii systemów SysML. Architektura i zastosowania Rysunek 2.1. Rational Unified Process ħródáo: opracowanie wáasne na podstawie (RUP, 2003) 2.1.1. Klasyfikacja wymagaþ W literaturze funkcjonuje szereg klasyfikacji wymagaĔ. W branĪy informatycznej naj- bardziej rozpowszechniony jest model FURPS, opracowany w firmie Hewlett-Packard (Grady i Caswell, 1987). KlasyfikacjĊ wymagaĔ systemowych zgodnie z modelem FURPS przedstawiono na rysunku 2.2. Rysunek 2.2. Wymagania funkcjonalne i pozafunkcjonalne Wymagania F Wymagania funkcjonalne Wymagania pozafunkcjonalne U R UĪytecznoĞü (ang. usability) NiezawodnoĞü (ang. reliability) P WydajnoĞü (ang. performance) S PrzystosowalnoĞü (ang. supportability) ħródáo: opracowanie wáasne na podstawie (Grady i Caswell, 1987) Wymagania funkcjonalne okreĞlają zachowanie systemu (Leffingwel i Widrig, 2003) — reprezentują usáugi, które system musi oferowaü bez uwzglĊdniania uwarunkowaĔ Rozdziaä 2. i Diagram wymagaþ systemowych 21 technologicznych. Wymagania te są bezpoĞrednio przenoszone na kod Ĩródáowy sys- temu w postaci konkretnych usáug i funkcji. Z kolei wymagania pozafunkcjonalne odnoszą siĊ do cech, parametrów systemu oraz jego otoczenia, wyraĪonych w takich kategoriach, jak:  uĪytecznoĞü (ang. usability) — speánienie tych wymagaĔ skutkuje zwiĊkszeniem stopnia przyswajalnoĞci obsáugi systemu przez uĪytkowników dziĊki estetycznemu i ergonomicznemu interfejsowi uĪytkownika, zapewniającemu intuicyjną nawigacjĊ w systemie;  niezawodnoĞü (ang. reliability) — czyli wáasnoĞü systemu, okreĞlająca, czy pracuje on poprawnie; jej miernikami są miĊdzy innymi: Ğredni czas miĊdzyawaryjny, Ğredni czas wdroĪenia obejĞcia (ang. bypass), Ğredni czas naprawy, liczba báĊdów na tysiąc linii kodu;  wydajnoĞü (ang. performance) — wolumen pracy wykonanej przez system w okreĞlonym czasie i przy zaangaĪowaniu okreĞlonych zasobów; miernikami wydajnoĞci mogą byü miĊdzy innymi: czas odpowiedzi systemu, liczba transakcji w jednostce czasu, liczba jednoczeĞnie obsáugiwanych klientów zdalnych;  przystosowalnoĞü (ang. supportablity) — czyli áatwoĞü konfigurowania, aktualizowania, serwisowania systemu, rejestrowania zdarzeĔ systemowych w logach i przystosowywania oprogramowania do specyficznych potrzeb uĪytkownika przez help desk i personel wsparcia technicznego. 2.1.2. Metody dokumentowania wymagaþ systemowych W zaleĪnoĞci od zastosowanego podejĞcia metodologicznego wykorzystuje siĊ wiele sposobów specyfikowania wymagaĔ. Mogą one byü dokumentowane w formie teksto- wej, graficznej, tabelarycznej lub hierarchicznej. Jednym z popularnych sposobów spe- cyfikowania wymagaĔ systemowych jest dokument SRS (ang. System Requirements Specification), opracowany przez organizacjĊ standaryzacyjną IEEE (IEEE, 1998). Struktura szablonu specyfikacji wymagaĔ zgodnie z tym dokumentem skáada siĊ z trzech podstawowych sekcji:  wprowadzenia — ujmującego takie kwestie, jak cel, zakres, definicje, akronimy i skróty, odwoáania oraz ramy odpowiedzialnoĞci dostawcy;  opisu ogólnego — poruszającego takie kwestie, jak perspektywy produktu, funkcje produktu, charakterystyki uĪytkownika, ograniczenia ogólne oraz zaáoĪenia i zaleĪnoĞci;  wymagaĔ szczegóáowych — w tym wymagaĔ wobec interfejsów zewnĊtrznych, wymagaĔ funkcjonalnych, wymagaĔ wydajnoĞciowych, ograniczeĔ produktu, atrybutów oraz pozostaáych wymagaĔ. JĊzyk SysML wprowadza nowy rodzaj diagramu, tj. diagram wymagaĔ systemo- wych, dedykowany wyáącznie problematyce specyfikowania wymagaĔ. W ten sposób uzyskuje siĊ wizualny, czytelny w odbiorze sposób prezentacji wymagaĔ systemowych 22 Jözyk inĔynierii systemów SysML. Architektura i zastosowania oraz jednoznaczne powiązanie zgromadzonych wymagaĔ z realizującymi te wymaga- nia elementami dokumentacji systemowej, przygotowanej z wykorzystaniem szerokiego spektrum elementów modelowania w jĊzyku SysML. 2.2. Elementy diagramu wymagaþ systemowych 2.2.1. Kategorie modelowania Diagram wymagaĔ systemowych umoĪliwia graficzne przedstawienie wymagaĔ sys- temowych i ich związków z innymi kategoriami modelowania systemu. Wymagania specyfikuje siĊ w odniesieniu do nastĊpujących podstawowych kategorii modelo- wania diagramów wymagaĔ systemowych:  wymaganie (ang. requirement),  związek (ang. relationship),  blok (ang. block),  przypadek uĪycia (ang. use case),  testowy przypadek uĪycia (ang. test case),  pakiet (ang. package). Wymienione kategorie oraz logiczne zaleĪnoĞci miĊdzy nimi przedstawiono na rysunku 2.3. Punktem wyjĞcia w procesie tworzenia diagramu wymagaĔ jest identyfikacja poszcze- gólnych wymagaĔ funkcjonalnych i pozafunkcjonalnych. Wymagania systemowe scha- rakteryzowano w punkcie 2.2.2. Z kolei zaawansowane aspekty wymagaĔ ujĊto w pod- rozdziale 2.3. Wymagania wiąĪe siĊ na diagramach wymagaĔ systemowych jĊzyka SysML związ- kami zagnieĪdĪenia, umoĪliwiającymi tworzenie wielopoziomowej hierarchii wymagaĔ, oraz szerokim zakresem zaleĪnoĞci. Liczba stereotypów, które moĪna przypisaü zaleĪ- noĞciom, wiąĪącym dane wymaganie systemowe z inną kategorią modelowania, wynika z wszechstronnoĞci i bogactwa interpretacyjnego pojĊcia wymagania. Wpáywa ono bowiem na wiele aspektów systemu. Związkom na diagramach wymagaĔ systemowych poĞwiĊcono punkty od 2.2.3 do 2.2.11. Tabelaryczną notacjĊ związków omówiono w punkcie 2.3.2. Bloki, przypadki uĪycia i testowe przypadki uĪycia są kategoriami modelowania, istot- nymi z punktu widzenia ilustrowania kontekstu poszczególnych wymagaĔ oraz nadzoru nad sposobem ich implementacji w systemie. Na diagramach wymagaĔ systemowych stosuje siĊ je w poáączeniu z odpowiednimi rodzajami zaleĪnoĞci. Wymienione katego- rie modelowania wykorzystano w punktach 2.2.6, 2.2.8 i 2.2.9. Rozdziaä 2. i Diagram wymagaþ systemowych 23 Rysunek 2.3. Kategorie modelowania diagramu wymagaĔ systemowych Pakiety stanowią mechanizm ogólnego zastosowania, sáuĪący do organizowania ele- mentów, w tym wymagaĔ i innych kategorii modelowania diagramu wymagaĔ syste- mowych. Tym samym pakiety i omówione w podrozdziale 7.5 diagramy pakietów są uĪyteczne w zarządzaniu záoĪonoĞcią modelu wymagaĔ systemowych. 2.2.2. Wymagania W jĊzyku SysML wymagania (ang. requirements) symbolizują kontrakt pomiĊdzy organizacją, zamawiającą system, a jego wykonawcami. W zaleĪnoĞci od ustaleĔ zespoáu projektowego i zastosowanego narzĊdzia moĪna wykorzystywaü podstawową notacjĊ wymagaĔ bądĨ jedną z notacji alternatywnych, zaprezentowanych na rysunku 2.4. Podstawowymi charakterystykami kaĪdego wymagania są:  numer porządkowy (ang. id),  treĞü wymagania (ang. text). W praktycznych zastosowaniach wymagania systemowe mają charakter hierarchiczny. W związku z tym wskazane jest nadawanie im numeracji porządkowej zgodnie z kon- wencją, podkreĞlającą umiejscowienie danego wymagania w wielopoziomowej strukturze 24 Jözyk inĔynierii systemów SysML. Architektura i zastosowania Rysunek 2.4. Notacje wymagaĔ Notacja podstawowa Notacje alternatywne «requirement» Przechowywanie parametrów automatycznego zamawiania w kartach magazynowych id = 1.1 text = System winien umoĪliwiaü podawanie minimalnego poziomu magazynowego, maksymalnego poziomu magazynowego, poziomu odnowienia, iloĞci zamawianej oraz wspóáczynnika tolerowanego opóĨnienia dostowy podczas tworzenia karty magazynowej a) b) c) Monitorowanie poziomów magazynowych w czasie rzeczywistym «requirement» Automatyczne generowanie zamówieĔ zakupu «requirement» Zapewnienie ciągáoĞci sprzedaĪy wymagaĔ systemowych. Szczególnie uĪyteczna w tym kontekĞcie jest notacja Deweya. Z kolei treĞü wymagania zawiera spójny, syntetyczny opis wáaĞciwoĞci, jaką system powinien siĊ cechowaü. Jednym z parametrów oceny jakoĞci tworzonego diagramu wymagaĔ systemowych jest stosowanie konsekwentnego stylu treĞci poszczególnych wymagaĔ, najwáaĞciwiej rozpoczynającego siĊ od sformuáowania „System winien...”. Wymienione cechy mogą zostaü w sposób bezpoĞredni ujĊte na diagramie, jak zapre- zentowano na rysunku 2.4. Spotykane są takĪe zapisy uproszczone (por. rysunek 2.4a, 2.4b i 2.4c). Zapisy te wynikają ze znacznej liczby wymagaĔ, charakteryzujących wspóá- czeĞnie tworzone systemy — a w konsekwencji ze skali záoĪonoĞci diagramów, skáa- dających siĊ na kompletny model wymagaĔ systemowych. I tak na rysunku 2.4 przedstawiono cztery warianty opisu wymagaĔ. Najbardziej peána jest notacja wymagania Przechowywanie parametrów automatycznego zamawiania w kartach magazynowych, zawierająca oprócz nazwy takĪe numer porządkowy i treĞü wymagania. Wymaganie Zapewnienie ciągáoĞci sprzedaĪy (rysunek 2.4b) równieĪ jest stereotypowane tekstowo, lecz nie uwzglĊdniono w jego przypadku charakterystyk szczegóáowych. Z kolei wymagania Monitorowanie poziomów magazynowych w czasie rzeczywistym i Automatyczne generowanie zamówieĔ zakupu są stereotypowane graficz- nie (rysunek 2.4a i 2.4b). Wymaganiu Przechowywanie parametrów automatycznego zamawiania w kartach magazynowych przydzielono numer porządkowy 1.1. MoĪna z tego wywnioskowaü, Īe posiada ono wymaganie nadrzĊdne o numerze 1. 2.2.3. Rodzaje zwiñzków pomiödzy wymaganiami W diagramie wymagaĔ systemowych poszczególne wymagania áączy siĊ róĪnymi rodzajami związków (ang. relationships). Wskazują one na charakter logicznej zaleĪ- noĞci pomiĊdzy poszczególnymi wymaganiami. Specyfikacja jĊzyka SysML ujmuje 7 podstawowych odmian związków pomiĊdzy wymaganiami. Związki te wyszczególnia tabela 2.1. Wszystkie odmiany zaleĪnoĞci, ujĊte w specyfikacji jĊzyka SysML, przedstawiają powiązania pomiĊdzy parą wymagaĔ: Ĩródáowym i docelowym. Graficznie te dwa Rozdziaä 2. i Diagram wymagaþ systemowych 25 Tabela 2.1. Rodzaje związków na diagramach wymagaĔ systemowych Nazwa zagnieĪdĪenie zaleĪnoĞü wyprowadzania zaleĪnoĞü realizacji zaleĪnoĞü powielania zaleĪnoĞü weryfikowania zaleĪnoĞü precyzowania zaleĪnoĞü Ğledzenia Notacja «deriveReqt» «satisfy» «copy» «verify» «refine» «trace» wymagania áączy siĊ linią przerywaną, wzbogaconą o stereotyp tekstowy, wskazujący na rodzaj zaleĪnoĞci: «deriveReqt», «satisfy», «copy», «verify», «refine» lub «trace». Grot strzaáki skierowany jest do wymagania Ĩródáowego. Spotyka siĊ takĪe nastĊpujące okreĞlenia poszczególnych stron zaleĪnoĞci:  element Ĩródáowy: dostawca, mistrz, oryginaá;  element docelowy: klient, niewolnik, kopia. NaleĪy zaznaczyü, iĪ zaleĪnoĞci wyprowadzania, realizacji i precyzowania stanowią specyficzne formy alokacji bezpoĞredniej. CharakterystykĊ alokacji zawarto w punk- cie 3.3.5. 2.2.4. ZagnieĔdĔenie Związkiem najpowszechniej stosowanym w diagramach wymagaĔ systemowych jest zagnieĪdĪenie (ang. containment). UmoĪliwia ono poáączenie wymagaĔ nadrzĊdnych z podrzĊdnymi, przez co tworzona jest wielopoziomowa, hierarchiczna struktura wymagaĔ systemowych. Wymaganie na danym poziomie hierarchii moĪe mieü tylko jeden element nadrzĊdny. Zasada ta nie dotyczy wymagania, zamieszczonego na szczy- cie hierarchii, które naturalnie nie posiada wymagaĔ nadrzĊdnych. Wymaganie nadrzĊdne uznaje siĊ za speánione tylko i wyáącznie wtedy, gdy zostaną speánione wszystkie jego wymagania podrzĊdne — czyli podwymagania powiązane z danym wymaganiem w hierarchiĊ poprzez zastosowanie związków zagnieĪdĪenia. Wielokrotne uĪycie danego wymagania pomiĊdzy róĪnymi gaáĊziami hierarchii wyma- gaĔ jest moĪliwe dziĊki zaleĪnoĞci powielania «copy», omówionej w dalszej czĊĞci roz- dziaáu. Związek zagnieĪdĪenia przedstawia rysunek 2.5. W hierarchii wymagaĔ, zilustrowanej na rysunku 2.5, wymaganiem nadrzĊdnym jest wymaganie systemowe Obsáuga przelewów zdefiniowanych. Wymaganie to posiada kilka podwymagaĔ. NaleĪą do nich: 26 Jözyk inĔynierii systemów SysML. Architektura i zastosowania «requirement» Obsáuga przelewów zdefiniowanych «requirement» WyĞwietlanie listy przelewów zdefiniowanych «requirement» Tworzenie przelewu zdefiniowanego «requirement» UsuniĊcie przelewu zdefiniowanego «requirement» Wykonywanie przelewu zdefiniowanego «requirement» Modyfikowanie przelewu zdefiniowanego Rysunek 2.5. Związek zagnieĪdĪenia w diagramie wymagaĔ systemowych  WyĞwietlanie listy przelewów zdefiniowanych,  Wykonywanie przelewu zdefiniowanego,  Tworzenie przelewu zdefiniowanego,  Modyfikowanie przelewu zdefiniowanego,  UsuniĊcie przelewu zdefiniowanego. Kompletny diagram, ujmujący podstawowe wymagania funkcjonalne internetowej plat- formy transakcyjnej banku wraz z ich numerami porządkowymi oraz treĞciami, przed- stawia rysunek 2.6. Rysunek 2.6 ujmuje záoĪoną hierarchiĊ wymagaĔ. Na pierwszym poziomie hierarchii wystĊpują wymagania systemowe:  Obsáuga páatnoĞci bieĪących,  Obsáuga kart páatniczych,  Obsáuga lokat bankowych,  Obsáuga kredytów,  Obsáuga funduszy inwestycyjnych,  Obsáuga ubezpieczeĔ,  Obsáuga transakcji gieádowych. Rozdziaä 2. i Diagram wymagaþ systemowych 27 req Wymagania funkcjonalne internetowej platformy transakcyjnej banku «requirement» Zdalne zarządzanie finansami osobistymi id = B1 text = System winien zapewniaü niezawodne, bieĪące wykonywanie transakcji bankowych, obsáugĊ kart páatniczych, lokat bankowych, kredytów, ubezpieczeĔ, transakcji gieádowych i inwestycyjnych za poĞrednictwem przeglądarki internetowej «requirement» Obsáuga ubezpieczeĔ id = B1.5 text = System winien oferowaü funkcjonalnoĞü zakáadania ubezpieczeĔ na Īycie, komunikacyjnych, turystycznych, mieszkaniowych oraz ubezpieczeĔ z funduszem inwestycyjnym «requirement» Obsáuga funduszy inwestycyjnych id = B1.6 text = System winien umoĪliwiaü nabywanie, konwersjĊ oraz umarzanie jednostek uczestnictwa funduszy rynku pieniĊĪnego, obligacji, stabilnego wzrostu, zrównowaĪonych i akcji - w tym denominowanych w walutach obcych; system winien oferowaü usáugĊ asystenta inwestycyjnego oraz peáen podgląd historii zleceĔ i transakcji «requirement» Obsáuga transakcji gieádowych id = B1.7 text = System winien udostĊpniaü notowania ciągáe akcji i innych walorów gieádowych oraz umoĪliwiaü skáadanie i realizacjĊ zleceĔ zakupu i sprzedaĪy akcji w czasie rzeczywistym, w tym zleceĔ z limitem aktywacji, na gieádzie papierów wartoĞciowych «requirement» Obsáuga páatnoĞci bieĪących id = B1.1 text = System winien zapewniaü obsáugĊ transakcji páatniczych w ramach wielu rachunków, w tym tworzenie i wykonywanie przelewów zdefiniowanych, wykonywanie przelewów jednorazowych i specjalistycznych oraz obsáugĊ zleceĔ staáych «requirement» Obsáuga rachunków bankowych «requirement» Obsáuga kart páatniczych id = B1.1.1 id = B1.2 text = System winien umoĪliwiaü przeglądanie listy rachunków uĪytkownika, w tym sald oraz peánych historii operacji na rachunkach, z uwzglĊdnieniem zaawansowanego filtrowania oraz eksportu danych do pliku «requirement» Obsáuga przelewów id = B1.1.2 text = System winien umoĪliwiaü zlecanie i rejestracjĊ przelewów bankowych, w tym tworzenie i obsáugĊ przelewów zdefiniowanych i wycofywanie przelewów niezrealizowanych text = System winien wspieraü funkcjonalnoĞü wykonywania operacji bezgotówkowych oraz wypáat pieniĊĪnych, zamawiania nowych kart páatniczych, zmiany numerów PIN i blokowania kart uĪytkownika «requirement» Obsáuga lokat bankowych id = B1.3 text = System winien umoĪliwiaü zakáadanie, rozliczanie i wycofywanie Ğrodków pieniĊĪnych przed upáywem terminu lokaty «requirement» Obsáuga kredytów «requirement» Obsáuga zleceĔ staáych id = B1.4 id = B1.1.3 text = System winien przyjmowaü, realizowaü i wygaszaü staáe zlecenia páatnicze text = System winien zapewniaü zaciąganie oraz spáatĊ rat kredytów gotówkowych i hipotecznych, przeglądanie i aktualizacjĊ harmonogramów spáat, monitorowanie spáat, jak równieĪ monitowanie w przypadku nieterminowych spáat, naliczanie opáat karnych, prowadzenie rachunków bilansujących oraz zawieszanie spáat na uzgodniony okres Rysunek 2.6. Wymagania funkcjonalne internetowej platformy transakcyjnej banku 28 Jözyk inĔynierii systemów SysML. Architektura i zastosowania KaĪde z tych wymagaĔ moĪe podlegaü dalszej hierarchizacji z wykorzystaniem związku zagnieĪdĪenia. I tak na przykáad wymaganie Obsáuga páatnoĞci bieĪących jest wyma- ganiem nadrzĊdnym dla wymagaĔ systemowych:  Obsáuga rachunków bankowych,  Obsáuga przelewów,  Obsáuga zleceĔ staáych. 2.2.5. ZaleĔnoĈè wyprowadzania ZaleĪnoĞü wyprowadzania, wykorzystująca stereotyp «deriveReqt», pozwala na wypro- wadzenie wymagania docelowego z wymagania Ĩródáowego. Cechy systemu, reprezen- towane przez wymaganie docelowe, są pochodnymi cech systemu, reprezentowanych przez wymaganie Ĩródáowe. Zazwyczaj pojedyncze wymaganie Ĩródáowe wspierane jest przez szereg wymagaĔ docelowych, powiązanych osobnymi zaleĪnoĞciami wyprowa- dzania. I tak, jak przedstawiono na rysunku 2.7, z wymagania Wykonywanie przelewu jednorazowego wyprowadzono dwa wymagania: Wykonywanie przelewu do UrzĊdu Skarbowego oraz Wykonywanie przelewu do Zakáadu UbezpieczeĔ Spoáecznych. Z drugiej strony pojedyncze wymaganie docelowe moĪe korzystaü z funkcjonalnoĞci kilku róĪ- nych wymagaĔ Ĩródáowych. ZaleĪnoĞü wyprowadzania ma charakter bardziej uniwersalny od zagnieĪdĪenia, gdyĪ moĪe specyfikowaü związki pomiĊdzy wymaganiami, zamieszczonymi w róĪnych gaáĊ- ziach hierarchicznej struktury wymagaĔ. Obejmuje to takĪe wymagania ujĊte na tym samym poziomie hierarchii. JĊzyk SysML oferuje kilka alternatywnych konwencji graficznej prezentacji poszcze- gólnych odmian zaleĪnoĞci pomiĊdzy wymaganiami. WyróĪniü moĪna konwencje:  bezpoĞrednią,  notatkową,  notatkową zagregowaną. Egzemplifikacja poszczególnych rodzajów zaleĪnoĞci bĊdzie konsekwentnie prowa- dzona we wszystkich wymienionych konwencjach. I tak bezpoĞrednią notacjĊ zaleĪno- Ğci «deriveReqt» przedstawiono na rysunku 2.7a, notatkową — rysunku 2.7b, a notat- kową zagregowaną — na rysunku 2.7c. 2.2.6. ZaleĔnoĈè realizacji KaĪde wymaganie systemowe musi zostaü speánione poprzez konkretne kategorie mode- lowania, skáadające siĊ na ten system. Mogą byü to zarówno elementy o charakterze programowym (np. páatnoĞü, podsystem zamawiania), jak i sprzĊtowym (czytnik kart, przeáącznik sieciowy itd.). Obie wskazane odmiany najczĊĞciej przyjmują na diagramach postaü bloków lub kategorii modelowania grupujących bloki (systemy, podsystemy itp.). Rozdziaä 2. i Diagram wymagaþ systemowych 29 «requirement» Wykonywanie przelewu jednorazowego «deriveReqt» «requirement» Wykonywanie przelewu do Zakáadu UbezpieczeĔ Spoáecznych a) «deriveReqt» «requirement» Wykonywanie przelewu do UrzĊdu Skarbowego b) Deriv edFrom «requirement» Wykonywanie przelewu jednorazowego Deriv edFrom «requirement» Wykonywanie przelewu jednorazowego «requirement» Wykonywanie przelewu jednorazowego «requirement» Wykonywanie przelewu jednorazowego «requirement» Wykonywanie przelewu do UrzĊdu Skarbowego «requirement» Wykonywanie przelewu do Zakáadu UbezpieczeĔ Spoáecznych c) Deriv edFrom «requirement» Wykonywanie przelewu jednorazowego «requirement» Wykonywanie przelewu do Zakáadu UbezpieczeĔ Spoáecznych «requirement» Wykonywanie przelewu do UrzĊdu Skarbowego Deriv ed «requirement» Wykonywanie przelewu do Zakáadu UbezpieczeĔ Spoáecznych Deriv ed «requirement» Wykonywanie przelewu do UrzĊdu Skarbowego «requirement» Wykonywanie przelewu jednorazowego Deriv ed «requirement» Wykonywanie przelewu do Zakáadu UbezpieczeĔ Spoáecznych «requirement» Wykonywanie przelewu do UrzĊdu Skarbowego Rysunek 2.7. RóĪne konwencje graficznej prezentacji zaleĪnoĞci wyprowadzania Zadaniem projektanta systemu jest identyfikacja kluczowych elementów, niezbĊdnych do speánienia poszczególnych wymagaĔ, oraz wskazanie, które konkretnie wymagania są speániane przez wyspecyfikowane elementy. Przypisanie wymagania do speániającego je elementu moĪna osiągnąü dziĊki zaleĪnoĞci realizacji, bazującej na stereotypie «satisfy». ZaleĪnoĞü ta pozwala okreĞlaü skutki zmian w obrĊbie wymagania wobec elementów od niego zaleĪnych i zarazem wskazy- waü, które z kluczowych elementów projektu i implementacji systemu są podatne na zmiany w obrĊbie danego wymagania i jakie ma to implikacje dla tego wymagania. Jak zaprezentowano na rysunku 2.8a, zaleĪnoĞü realizacji na diagramie jest skierowana od elementu docelowego, odpowiedzialnego za realizacjĊ wymagania (Terminal POS, Czytnik kart, Kamera bezpieczeĔstwa), do wymagania Ĩródáowego (Realizacja páatnoĞci kartą). Alternatywne konwencje graficznej prezentacji omawianego związku przedsta- wia odpowiednio rysunek 2.8b oraz rysunek 2.8c. 30 a) «requirement» Realizacja páatnoĞci kartą id = B1.2.1 text = System winien realizowaü wyspecyfikowaną operacjĊ z uĪyciem karty páatniczej «satisfy» «block» Kamera bezpieczeĔstwa c) SatisfiedBy «block» Terminal POS «block» Czytnik kart «block» Kamera bezpieczeĔstwa «block» Terminal POS «block» Czytnik kart «block» Kamera bezpieczeĔstwa Jözyk inĔynierii systemów SysML. Architektura i zastosowania «satisfy» «block» Terminal POS «satisfy» «block» Czytnik kart «requirement» Realizacja páatnoĞci kartą «requirement» Realizacja páatnoĞci kartą «requirement» Realizacja páatnoĞci kartą Satisfies «requirement» Realizacja páatnoĞci kartą Satisfies «requirement» Realizacja páatnoĞci kartą Satisfies «requirement» Realizacja páatnoĞci kartą SatisfiedBy b) «block» Terminal POS SatisfiedBy «block» Czytnik kart SatisfiedBy «block» Kamera bezpieczeĔstwa «block» Terminal POS «block» Czytnik kart «block» Kamera bezpieczeĔstwa «requirement» Realizacja páatnoĞci kartą Satisfies «requirement» Realizacja páatnoĞci kartą Rysunek 2.8. RóĪne konwencje graficznej prezentacji zaleĪnoĞci realizacji 2.2.7. ZaleĔnoĈè powielania W róĪnych moduáach záoĪonych systemów bardzo czĊsto obowiązuje szereg toĪsamych wymagaĔ. Praktyka niezaleĪnego definiowania takich samych wymagaĔ w róĪnych moduáach jest niewskazana ze wzglĊdu na utratĊ moĪliwoĞci Ğledzenia zmian w modelu wymagaĔ oraz ryzyko powstania niespójnoĞci modelu wymagaĔ. Jest ona takĪe sprzeczna Rozdziaä 2. i Diagram wymagaþ systemowych 31 z uniwersalną zasadą ponownego wykorzystania (ang. reuse), konsekwentnie stoso- waną w systemach obiektowych. Z tego wzglĊdu twórcy jĊzyka SysML zaproponowali moĪliwoĞü powielania treĞci wymagaĔ. Przyjmuje ona formĊ zaleĪnoĞci powielania, oznaczanej stereotypem «copy». W momencie poprowadzenia zaleĪnoĞci powielania pomiĊdzy dwoma wymaganiami przyjmuje siĊ, Īe wymaganie docelowe ma charakter tylko do odczytu, tj. przyjmuje ono toĪsamą treĞü w stosunku do wymagania Ĩródáowego. Stąd jeĞli zamawiający sys- tem przeformuáuje treĞü wczeĞniej zdefiniowanego wymagania, zostanie ona automa- tycznie zaktualizowana we wszystkich powiązanych wymaganiach docelowych. Zasto- sowanie tego związku eliminuje zatem koniecznoĞü wyszukiwania wszystkich wymagaĔ o analogicznej treĞci i stosownego wprowadzania korekt. Z kolei numery porządkowe oraz nazwy wymagaĔ Ĩródáowych i docelowych mogą siĊ róĪniü. Przykáad zastosowania bezpoĞredniej konwencji graficznej prezentacji związków powie- lania zamieszczono na rysunku 2.9. «requirement» Obsáuga ubezpieczeĔ «requirement» Rejestracja umowy ubezpieczenia na Īycie «requirement» Rejestracja umowy ubezpieczenia turystycznego «requirement» Obsáuga transakcji gieádowych «requirement» Rejestracja umowy ubezpieczenia mieszkaniowego «requirement» Rejestracja umowy ubezpieczenia komunikacyjnego «copy» «copy» «copy» «copy» «requirement» Rejestracja umowy «copy» «requirement» Rejestracja umowy prowadzenia rachunku maklerskiego Rysunek 2.9. BezpoĞrednia konwencja graficznej prezentacji zaleĪnoĞci powielania I tak zaprezentowane na rysunku 2.9 wymaganie systemowe Obsáuga ubezpieczeĔ posiada kilka podwymagaĔ. Obejmują one:  RejestracjĊ umowy ubezpieczenia komunikacyjnego,  RejestracjĊ umowy ubezpieczenia na Īycie,  RejestracjĊ umowy ubezpieczenia turystycznego,  RejestracjĊ umowy ubezpieczenia mieszkaniowego. 32 Jözyk inĔynierii systemów SysML. Architektura i zastosowania Wszystkie te wymagania szczegóáowe powielają treĞü wymagania Rejestracja umowy. Wymaganie Rejestracja umowy stanowi takĪe wzorzec dla wymagania systemowego Rejestracja umowy prowadzenia rachunku maklerskiego. To ostatnie jest podwymaga- niem Obsáugi transakcji gieádowych. Z kolei konwencje notatkowe graficznej prezentacji zaleĪnoĞci powielania zilustrowano na rysunku 2.10. a) b) Master «requirement» Rejestracja umowy Master «requirement» Rejestracja umowy Master «requirement» Rejestracja umowy Master «requirement» Rejestracja umowy «requirement» Rejestracja umowy prowadzenia rachunku maklerskiego «requirement» Rejestracja umowy prowadzenia rachunku maklerskiego «requirement» Rejestracja umowy prowadzenia rachunku maklerskiego «requirement» Rejestracja umowy prowadzenia rachunku maklerskiego «requirement» Rejestracja umowy ubezpieczenia komunikacyjnego «requirement» Rejestracja umowy ubezpieczenia komunikacyjnego «requirement» Rejestracja umowy ubezpieczenia na Īycie «requirement» Rejestracja umowy ubezpieczenia turystycznego «requirement» Rejestracja umowy ubezpieczenia mieszkaniowego Master «requirement» Rejestracja umowy «requirement» Rejestracja umowy prowadzenia rachunku maklerskiego Slav e «requirement» Rejestracja umowy ubezpieczenia komunikacyjnego «requirement» Rejestracja umowy ubezpieczenia na Īycie «requirement» Rejestracja umowy ubezpieczenia turystycznego «requirement» Rejestracja umowy ubezpieczenia mieszkaniowego «requirement» Rejestracja umowy ubezpieczenia na Īycie «requirement» Rejestracja umowy ubezpieczenia turystycznego «requirement» Rejestracja umowy ubezpieczenia mieszkaniowego Slav e «requirement» Rejestracja umowy ubezpieczenia komunikacyjnego Slav e «requirement» Rejestracja umowy ubezpieczenia na Īycie Slav e «requirement» Rejestracja umowy ubezpieczenia turystycznego Slav e «requirement» Rejestracja umowy ubezpieczenia mieszkaniowego Rysunek 2.10. Konwencje notatkowe graficznej prezentacji zaleĪnoĞci powielania 2.2.8. ZaleĔnoĈè weryfikowania Dobrą praktyką modelowania systemów informatycznych jest weryfikowanie poszcze- gólnych wymagaĔ pod kątem tego, czy zostaáy one zrealizowane podczas kodowania systemu. W tym celu tworzy siĊ stosowne testy. Testy formalne charakteryzują siĊ posiadaniem konkretnego zestawu warunków wejĞciowych oraz oczekiwanego efektu testu po jego wywoáaniu. W jĊzyku SysML testy formalne wiąĪe siĊ z wymaganiami z wykorzystaniem zaleĪnoĞci weryfikowania, oznaczonej stereotypem «verify». Rozdziaä 2. i Diagram wymagaþ systemowych 33 ZaleĪnoĞü weryfikowania wyprowadzana jest od elementu docelowego, którym jest tzw. testowy przypadek uĪycia. Charakteryzuje on procedurĊ testu. Do pojedynczego wymagania przydzieliü moĪna szereg testowych przypadków uĪycia. KaĪdy przypadek moĪna osobno udokumentowaü diagramami dynamiki jĊzyka SysML, na przykáad dia- gramem sekwencji lub czynnoĞci. Testowe przypadki uĪycia moĪna na diagramach wyma- gaĔ systemowych stereotypowaü zarówno tekstowo (rysunek 2.11a), jak i graficznie (rysunek 2.11b). Testowemu przypadkowi uĪycia moĪna takĪe przypisaü dodatkowe stereotypy testowania, odpowiadające róĪnym metodom testowania. Przykáadami takich stereotypów mogą byü:  «analyze»,  «inspect»,  «demonstrate»,  «test». ZróĪnicowanie testowych przypadków uĪycia pozwala na realizacjĊ róĪnych proce- dur weryfikacyjnych. BezpoĞrednią konwencjĊ graficznej prezentacji zaleĪnoĞci wery- fikowania przedstawiono na rysunku 2.11. a) «requirement» Realizacja zlecenia sprzedaĪy akcji b) Realizacja zlecenia sprzedaĪy akcji «verify» «verify» «verify» «verify» «testcase» Weryfikuj datĊ obowiązywania zlecenia «testcase» Weryfikuj liczbĊ sprzedawanych jednostek Weryfikuj daty obowiązywania zlecenia Weryfikuj liczbĊ sprzedawanych jednostek Rysunek 2.11. BezpoĞrednia konwencja graficznej prezentacji zaleĪnoĞci weryfikowania I tak zamieszczone na rysunku 2.11 wymaganie systemowe Realizacja zlecenia sprze- daĪy akcji podlega weryfikacji przez testowe przypadki uĪycia Weryfikuj datĊ obowią- zywania zlecenia oraz Weryfikuj liczbĊ sprzedawanych jednostek. Rysunek 2.11b ujmuje alternatywną, graficzną notacjĊ poszczególnych kategorii modelowania. ZaleĪnoĞü weryfikowania nabiera szczególnego znaczenia w iteracyjno-przyrostowym cyklu Īycia systemu — w jego kolejnych iteracjach (minicyklach Īycia systemu) wykonuje siĊ bowiem zadania z zakresu poszczególnych dyscyplin, od modelowania biznesowego do wdroĪenia i testowania (por. rysunek 2.1). Konwencje notatkowe gra- ficznej prezentacji zaleĪnoĞci weryfikowania zilustrowano na rysunku 2.12. 2.2.9. ZaleĔnoĈè precyzowania ZaleĪnoĞü precyzowania, oznaczana stereotypem «refine», pozwala na wprowadzenie do diagramu wymagaĔ systemowych licznych detali, reprezentowanych poprzez doce- lowe elementy związku. Detale te mają na celu uáatwienie zrozumienia sensu wymagania 34 a) «testcase» Weryfikuj datĊ obowiązywania zlecenia «testcase» Weryfikuj liczbĊ sprzedawanych jednostek Jözyk inĔynierii systemów SysML. Architektura i zastosowania Verifies «requirement» Realizacja zlecenia sprzedaĪy akcji Verifies «requirement» Realizacja zlecenia sprzedaĪy akcji VerifiedBy «testcase» Weryfikuj daty obowiązywania zlecenia VerifiedBy «testcase» Weryfikuj liczbĊ sprzedawanych jednostek «requirement» Realizacja zlecenia sprzedaĪy akcji «requirement» Realizacja zlecenia sprzedaĪy akcji b) «testcase» Weryfikuj datĊ obowiązywania zlecenia «testcase» Weryfikuj liczbĊ sprzedawanych jednostek Verifies «requirement» Realizacja zlecenia sprzedaĪy akcji VerifiedBy «testcase» Weryfikuj daty obowiązywania zlecenia «testcase» Weryfikuj liczbĊ sprzedawanych jednostek «requirement» Realizacja zlecenia sprzedaĪy akcji Rysunek 2.12. Konwencje notatkowe graficznej prezentacji zaleĪnoĞci weryfikowania poprzez wzbogacenie go o elementy modelowania lub ich zestawy, takie jak kategorie modelowania jĊzyka SysML, projektowania interfejsu, osobne specyfikacje tekstowe lub standardy. ZwiĊzáa treĞü wymagania Ĩródáowego moĪe byü tym samym sformali- zowana lub bardziej precyzyjnie zdefiniowana. ZaleĪnoĞü ta stwarza moĪliwoĞü wyja- Ğnienia ogólnego tekstu zapisanego w wymaganiu Ĩródáowym. Przykáady zastosowania zaleĪnoĞci precyzowania zaprezentowano na rysunku 2.13. I tak zamieszczone na rysunku 2.13 wymaganie Ocena zdolnoĞci kredytowej klienta precyzowane jest poprzez wiele kategorii modelowania. W tym konkretnym zastoso- waniu są to nastĊpujące przypadki uĪycia:  Weryfikuj ogólną wiarygodnoĞü klienta,  Weryfikuj dane Biura Informacji Kredytowej,  Wylicz wskaĨniki na podstawie wniosku kredytowego klienta. 2.2.10. ZaleĔnoĈè Ĉledzenia ZaleĪnoĞü Ğledzenia, oznaczana stereotypem «trace», umoĪliwia zaprezentowanie nie- formalnego związku pomiĊdzy wymaganiem a dowolnym elementem modelu systemu, w tym innym wymaganiem. Dokumentacja jĊzyka SysML pozostawia znaczną swobodĊ stosowania tego typu związków. Na rysunku 2.14 wykorzystano zaleĪnoĞü Ğledzenia do podkreĞlenia nastĊpstwa czasowego realizacji usáug systemowych, wynikających z zaprezentowanych wymagaĔ. Rozdziaä 2. i Diagram wymagaþ systemowych 35 a) «requirement» Ocena zdolnoĞci kredytowej klienta «refine» Wylicz wskaĨniki na podstawie wniosku kredytowego klienta b) Wylicz wskaĨniki na podstawie wniosku kredytowego klienta Weryfikuj dane Biura Informacji Kredytowej Weryfikuj ogólną wiarygodnoĞü klienta RefinedBy «usecase» Wylicz wskaĨniki na podstawie wniosku kredytowego klienta RefinedBy «usecase» Weryfikuj dane Biura Informacji Kredytowej RefinedBy «usecase» Weryfikuj ogólną wiarygodnoĞü klienta Refines «requirement» Ocena zdolnoĞci kredytowej klienta Refines «requirement» Ocena zdolnoĞci kredytowej klienta Refines «requirement» Ocena zdolnoĞci kredytowej klienta «requirement» Ocena zdolnoĞci kredytowej klienta «requirement» Ocena zdolnoĞci kredytowej klienta «requirement» Ocena zdolnoĞci kredytowej klienta «refine» «refine» Weryfikuj dane Biura Informacji Kredytowej Weryfikuj ogólną wiarygodnoĞü klienta Wylicz wskaĨniki na podstawie wniosku kredytowego klienta c) Weryfikuj dane Biura Informacji Kredytowej Weryfikuj ogólną wiarygodnoĞü klienta Refines «requirement» Ocena zdolnoĞci kredytowej klienta «requirement» Ocena zdolnoĞci kredytowej klienta RefinedBy «usecase» Wylicz wskaĨniki na podstawie wniosku kredytowego klienta «usecase» Weryfikuj dane Biura Informacji Kredytowej «usecase» Weryfikuj ogólną wiarygodnoĞü klienta Rysunek 2.13. RóĪne konwencje graficznej prezentacji zaleĪnoĞci precyzowania I tak, zgodnie z rysunkiem 2.14, Wycofanie przelewu jest moĪliwe tylko za poĞred- nictwem listy transakcji oczekujących. JeĞli jakieĞ wymaganie znajduje siĊ na wspo- mnianej liĞcie, jego obsáugĊ zapewnia funkcjonalnoĞü systemu, zaimplementowana w konsekwencji wniesienia wymagania WyĞwietlanie listy transakcji oczekujących. Z kolei aby transakcja znalazáa siĊ na tej liĞcie, wczeĞniej naleĪy wykonaü funkcjonal- noĞü wynikającą z wymagania Wykonywanie przelewu jednorazowego bądĨ Wykony- wanie przelewu zdefiniowanego. 36 Jözyk inĔynierii systemów SysML. Architektura i zastosowania a) «requirement» WyĞwietlanie listy transakcji oczekujących «trace» «requirement» Wycofywanie przelewu «trace» «trace» «requirement» Wykonywanie przelewu zdefiniowanego «requirement» Wykonywanie przelewu jednorazowego b) TracedTo «requirement» WyĞwietlanie listy transakcji oczekujących TracedTo «requirement» Wykonywanie przelewu zdefiniowanego TracedTo «requirement» Wykonywanie przelewu jednorazowego c) TracedTo «requirement» Wycofywanie przelewu «requirement» WyĞwietlanie listy transakcji oczekujących «requirement» WyĞwietlanie listy transakcji oczekujących «requirement» WyĞwietlanie listy transakcji oczekujących TracedTo «requirement» Wykonywanie przelewu zdefiniowanego «requirement» Wykonywanie przelewu jednorazowego «requirement» WyĞwietlanie listy transakcji oczekujących «requirement» Wykonywanie przelewu zdefiniowanego «requirement» Wykonywanie przelewu jednorazowego «requirement» Wycofywanie przelewu «requirement» WyĞwietlanie listy transakcji oczekujących «requirement» Wykonywanie przelewu zdefiniowanego Rysunek 2.14. RóĪne konwencje graficznej prezentacji zaleĪnoĞci Ğledzenia «requirement» Wykonywanie przelewu jednorazowego TracedFrom «requirement» Wycofywanie przelewu TracedFrom «requirement» WyĞwietlanie listy transakcji oczekujących TracedFrom «requirement» WyĞwietlanie listy transakcji oczekujących TracedFrom «requirement» Wycofywanie przelewu TracedFrom «requirement» WyĞwietlanie listy transakcji oczekujących Rozdziaä 2. i Diagram wymagaþ systemowych 37 2.2.11. Analiza porównawcza zaleĔnoĈci Jak wynika z dokonanej w powyĪszych punktach charakterystyki szeĞciu odmian zaleĪ- noĞci, opisują one związki pomiĊdzy wymaganiami Ĩródáowymi oraz wymaganiami docelowymi bądĨ docelowymi elementami modelowania. Syntetycznie zagadnienie to podsumowuje tabela 2.2. Tabela 2.2. Porównanie zaleĪnoĞci na diagramach wymagaĔ systemowych Rodzaj zaleĔnoĈci Stereotyp zaleĪnoĞü wyprowadzania zaleĪnoĞü realizacji zaleĪnoĞü powielania zaleĪnoĞü weryfikowania zaleĪnoĞü precyzowania zaleĪnoĞü Ğledzenia «deriveReqt» «satisfy» «copy» «verify» «refine» «trace» Wymaganie Ēródäowe x x x x x x Wymaganie docelowe x Docelowa kategoria modelowania x x x x x x Zastosowanie wiĊkszoĞci z zaprezentowanych w tabeli 2.2 rodzajów zaleĪnoĞci zilu- strowano na rysunku 2.15. I tak rysunek 2.15 przedstawia zestaw wymagaĔ systemowych w odniesieniu do sys- temu transakcyjnego banku. Przedmiotem wymagaĔ jest obsáuga przelewów. NadrzĊd- nym wymaganiem w hierarchii jest wáaĞnie wymaganie Obsáuga przelewów. Posiada ono cztery bezpoĞrednie podwymagania:  ObsáugĊ przelewów zdefiniowanych,  ObsáugĊ przelewów jednorazowych,  ObsáugĊ transakcji oczekujących,  ObsáugĊ przelewów specjalnych. Z kolei podwymaganie Obsáuga przelewów zdefiniowanych dzieli siĊ na nastĊpujące wymagania szczegóáowe:  WyĞwietlanie listy przelewów zdefiniowanych,  Usuwanie przelewu zdefiniowanego,  Wykonywanie przelewu zdefiniowanego,  Tworzenie przelewu zdefiniowanego,  Modyfikowanie przelewu zdefiniowanego. Z tymi trzema ostatnimi wymaganiami zaleĪnoĞcią Ğledzenia powiązane jest wymaganie Kontrola poprawnoĞci wprowadzonych danych przelewu zdefiniowanego. Oznacza to, Īe wykonanie, tworzenie lub modyfikowanie przelewu wiąĪe siĊ z wywoáaniem funk- cjonalnoĞci, kontrolującej poprawnoĞü danych, wprowadzonych do poszczególnych formatek. 38 Jözyk inĔynierii systemów SysML. Architektura i zastosowania Rysunek 2.15. Studium diagramu wymagaĔ systemowych banku internetowego Rozdziaä 2. i Diagram wymagaþ systemowych 39 Z realizacją Obsáugi przelewów jednorazowych wiąĪą siĊ nastĊpujące wymagania szczegóáowe:  Wykonywanie przelewu jednorazowego,  Realizacja dewizowego polecenia wypáaty,  Kontrola poprawnoĞci danych przelewu jednorazowego. FunkcjonalnoĞü zaimplementowana wskutek sformuáowania tego ostatniego wymagania jest automatycznie wywoáywana zarówno przy Wykonywaniu przelewu jednorazowego, jak i Realizacji dewizowego polecenia wypáaty. Oba wymienione wyĪej wymagania, związane z weryfikacją spójnoĞci danych, powielają wzorcową funkcjonalnoĞü wyma- gania Kontrola poprawnoĞci danych, zamieszczonego z kolei w pakiecie Wymagania związane z obsáugą GUI. Obsáuga transakcji oczekujących dzieli siĊ na podwymagania Wycofywanie przelewu i WyĞwietlanie listy transakcji oczekujących, przy czym wycofywanie jest uzaleĪnione od wyĞwietlania. Wspomnianą relacjĊ obrazuje zaleĪnoĞü «trace», zamieszczona pomiĊdzy tymi wymaganiami. Analogiczna zaleĪnoĞü áączy wymaganie WyĞwietlanie listy transakcji oczekujących z wymaganiami Wykonywanie przelewu zdefiniowanego i Wykonywanie przelewu jednorazowego. Ostatnim z wymagaĔ, podlegających dalszej hierarchizacji, jest wymaganie systemowe Obsáuga przelewów specjalnych. Dzieli siĊ ono na Wykonywanie przelewu do Zakáadu UbezpieczeĔ Spoáecznych i Wykonywanie przelewu do UrzĊdu Skarbowego. Obydwa te wymagania wywodzą siĊ z wymagania Wykonywanie przelewu jednorazowego, co zobrazowano zaleĪnoĞcią wyprowadzania «deriveReqt». 2.3. Zaawansowana specyfikacja wymagaþ oraz zwiñzków Poza kluczowymi wáaĞciwoĞciami podstawowych kategorii modelowania diagramu wymagaĔ systemowych, tj. wymagaĔ oraz związków, istnieją nastĊpujące zaawanso- wane koncepcje, związane w jĊzyku SysML ze specyfikowaniem wymagaĔ:  tabelaryczna specyfikacja wymagaĔ,  tabelaryczna specyfikacja związków,  rozszerzone wymagania systemowe,  stereotypowanie rozszerzonych wymagaĔ systemowych. Wymienione koncepcje omówiono w kolejnych punktach niniejszego rozdziaáu. 40 Jözyk inĔynierii systemów SysML. Architektura i zastosowania 2.3.1. Tabelaryczna specyfikacja wymagaþ W przypadku obszernego opisu treĞci wymagaĔ uĪyteczna staje siĊ tabelaryczna repre- zentacja wymagaĔ systemowych. Obligatoryjnie musi zawieraü ona co najmniej trzy kolumny, tj. numer porządkowy, nazwĊ oraz treĞü wymagania. Numeracja porządkowa moĪe opieraü siĊ na systemie klasyfikacji dziesiĊtnej Deweya, wiernie oddającym hierarchiczne zaleĪnoĞci pomiĊdzy poszczególnymi wymaganiami systemowymi. W kolumnie Nazwa umieszcza siĊ naturalnie nazwĊ wymagania, podczas gdy TreĞü moĪe zawieraü nawet bardzo drobiazgowy opis wymagania. W miarĊ potrzeb wprowadza siĊ dodatkowe kolumny tabeli. Przykáad tabelarycznej specyfikacji wymagaĔ systemo- wych zaprezentowano w tabeli 2.3. Tabela 2.3. Tabelaryczna reprezentacja wymagaĔ systemowych Numer porzñdkowy Nazwa B1 Zdalne zarządzanie finansami osobistymi B1.1 B1.2 B1.3 B1.4 B1.5 B1.6 B1.7 Obsáuga páatnoĞci bieĪących Obsáuga kart páatniczych Obsáuga lokat bankowych Obsáuga kredytów Obsáuga ubezpieczeĔ Obsáuga funduszy inwestycyjnych Obsáuga transakcji gieádowych TreĈè System winien zapewniaü niezawodne, bieĪące wykonywanie transakcji bankowych, obsáugĊ kart páatniczych, lokat bankowych, kredytów, ubezpieczeĔ, transakcji gieádowych i inwestycyjnych za poĞrednictwem przeglądarki internetowej System winien zapewniaü obsáugĊ transakcji páatniczych w ramach wielu rachunków, w tym tworzenie i wykonywanie przelewów zdefiniowanych, wykonywanie przelewów jednorazowych i specjalistycznych oraz obsáugĊ zleceĔ staáych System winien wspieraü funkcjonalnoĞü wykonywania operacji bezgotówkowych oraz wypáat pieniĊĪnych, zamawiania nowych kart páatniczych, zmiany numerów PIN i blokowania kart uĪytkownika System winien umoĪliwiaü zakáadanie, rozliczanie i wycofywanie Ğrodków pieniĊĪnych przed upáywem terminu lokaty System winien zapewniaü zaciąganie oraz spáatĊ rat kredytów gotówkowych i hipotecznych, przeglądanie i aktualizacjĊ harmonogramów spáat, monitorowanie spáat, jak równieĪ monitowanie w przypadku nieterminowych spáat, naliczanie opáat karnych, prowadzenie rachunków bilansujących oraz zawieszanie spáat na uzgodniony okres System winien oferowaü funkcjonalnoĞü zakáadania ubezpieczeĔ na Īycie, komunikacyjnych, turystycznych, mieszkaniowych oraz ubezpieczeĔ z funduszem inwestycyjnym System winien umoĪliwiaü nabywanie, konwersjĊ oraz umarzanie jednostek uczestnictwa funduszy rynku pieniĊĪnego, obligacji, stabilnego wzrostu, zrównowaĪonych i akcji — w tym denominowanych w walutach obcych; system winien oferowaü usáugĊ asystenta inwestycyjnego oraz peáen podgląd historii zleceĔ i transakcji System winien udostĊpniaü notowania ciągáe akcji i innych walorów gieádowych oraz umoĪliwiaü skáadanie i realizacjĊ zleceĔ zakupu i sprzedaĪy akcji w czasie rzeczywistym, w tym zleceĔ z limitem aktywacji, na gieádzie papierów wartoĞciowych Rozdziaä 2. i Diagram wymagaþ systemowych 41 2.3.2. Tabelaryczna specyfikacja zwiñzków Podobnie jak w przypadku wymagaĔ, istnieje moĪliwoĞü posáugiwania siĊ tabelaryczną specyfikacją związków. Tabela taka jest bardziej záoĪona, gdyĪ prócz podstawowych cech wymagaĔ Ĩródáowych i docelowych — tj. numeru porządkowego i treĞci — wymaga wyspecyfikowania rodzaju związku. Tabelaryczną reprezentacjĊ związków ilustruje tabela 2.4. Tabela 2.4. Tabelaryczna reprezentacja związków Wymaganie docelowe Wymaganie Ēródäowe Numer porzñdkowy B1.1.2.1.5 B1.1.2.2.1 B1.1.2.3.1 B1.1.2.3.1 B1.1.2.3.2 B1.1.2.2.2 B1.1.2.2.3 Nazwa Wykonywanie przelewu zdefiniowanego Wykonywanie przelewu jednorazowego WyĞwietlanie listy transakcji oczekujących WyĞwietlanie listy transakcji oczekujących Wycofywanie przelewu Wykonywanie przelewu do Zakáadu UbezpieczeĔ Spoáecznych Wykonywanie przelewu do UrzĊdu Skarbowego Rodzaj zwiñzku zagnieĪdĪenie Numer porzñdkowy B1.1.2.1 zagnieĪdĪenie B1.1.2.2 B1.1.2.1.5 B1.1.2.2.1 B1.1.2.3.1 B1.1.2.2.1 zaleĪnoĞü Ğledzenia zaleĪnoĞü Ğledzenia zaleĪnoĞü Ğledzenia zaleĪnoĞü wyprowadzania zaleĪnoĞü wyprowadzania Nazwa Obsáuga przelewów zdefiniowanych Obsáuga przelewów jednorazowych Wykonywanie przelewu zdefiniowanego Wykonywanie przelewu jednorazowego WyĞwietlanie listy transakcji oczekujących Wykonywanie przelewu jednorazowego B1.1.2.2.1 Wykonywanie przelewu jednorazowego 2.3.3. Rozszerzone wymagania systemowe Dotychczasowe rozwaĪania skupiaáy siĊ na opisie ogólnych cech wymagaĔ oraz związ- ków. Cechy te w jĊzyku SysML moĪna swobodnie rozszerzaü poprzez przypisanie wymaganiom lub związkom dodatkowych stereotypów, a w przypadku wymagania — takĪe wáaĞciwoĞci i sekcji. Poszczególne wáaĞciwoĞci rozszerzonego wymagania systemowego (ang. extended requirement) mogą przybieraü nastĊpujące wartoĞci:  priorytet wymagania (ang. priority) — wskazujący na kolejnoĞü implementowania wymagaĔ, na przykáad niski/Ğredni/wysoki;  istotnoĞü wymagania (ang. obligation) — czyli wyspecyfikowanie, czy dane wymaganie moĪna pominąü w dalszych fazach tworzenia systemu ze wzglĊdu na czas lub koszty, na przykáad obligatoryjne/opcjonalne; 42 Jözyk inĔynierii systemów SysML. Architektura i zastosowania  stabilnoĞü wymagania (ang. stability) — prawdopodobieĔstwo redefinicji wymagania systemowego w trakcie implementowania systemu, na przykáad niestabilne/maáo stabilne/umiarkowanie stabilne/wysoce stabilne/caákowicie stabilne;  typ wymagania (ang. type) — Ĩródáo pochodzenia wymagania, na przykáad uĪytkownika/wzorcowe/wáasne;  róĪne rodzaje ryzyka implementacji wymagania (ang. risks) — zwiĊzáa lista podstawowych zagroĪeĔ, związanych z danym wymaganiem; poszczególne typy ryzyka charakteryzuje siĊ opisowo. Na rysunku 2.16 przedstawiono rozszerzone wymaganie systemowe. Dla odróĪnienia od wymagania standardowego zostaáo ono oznaczone stereotypem «extendedRequirement». Oprócz standardowych wáaĞciwoĞci, tj. numeru porządkowego i treĞci wymagania, zawiera ono wiele wáaĞciwoĞci dodatkowych. Rysunek 2.16. Rozszerzone wymaganie systemowe «extendedRequirement» Obsáuga funduszy inwestycyjnych id = B1.6 text = system winien umoĪliwiaü nabycie, konwersjĊ oraz umorzenie jednostek uczestnictwa funduszy rynku pieniĊĪnego, obligacji, stabilnego wzrostu, zrównowaĪonych i akcji - w tym denominowanych w walutach obcych; system winien oferowaü usáugĊ asystenta inwestycyjnego oraz peány podgląd historii priority = niski obligation = opcjonalne stability = umiarkowanie stabilne type = uĪytkownika risks = ryzyko wspóápracy miĊdzy systemami, ryzyko technologiczne, ryzyko prawne 2.3.4. Stereotypowanie rozszerzonych wymagaþ systemowych Do diagramów wymagaĔ systemowych powszechnie wprowadza siĊ dodatkowe stereo- typy, rozszerzające funkcjonalnoĞü wymagaĔ bazowych. Dobór dodatkowych stereo- typów jest ĞciĞle uzaleĪniony od dziedziny przedmiotowej i preferencji zespoáu, projek- tującego dany system. KaĪde wymaganie z przydzielonym niestandardowym stereotypem klasyfikuje siĊ jako rozszerzone wymaganie systemowe. Dodatek C dokumentacji jĊzyka SysML w wersji 1.1 proponuje zastosowanie stereotypów, wskazujących na specyfikĊ wymagaĔ systemowych. I tak dodatkowe odmiany rozszerzonych wymagaĔ systemo- wych obejmują: Rozdziaä 2. i Diagram wymagaþ systemowych 43  wymagania funkcjonalne,  wymagania interfejsowe,  wymagania wydajnoĞciowe,  wymagania fizyczne,  ograniczenia projektowe. Zostaáy one scharakteryzowane i zilustrowane w tabeli 2.5. Tabela 2.5. Dodatkowe stereotypy wymagania zaawansowanego Nazwa Wymaganie funkcjonalne Stereotyp «functional ´Requirement» Charakterystyka Reprezentuje usáugi, które system musi oferowaü bez uwzglĊdniania uwarunkowaĔ technologicznych Wymaganie interfejsowe «interface ´Requirement» Dotyczy wejĞciowych i wyjĞciowych interfejsów systemu Wymaganie wydajnoĞciowe «performance ´Requirement» Dotyczy wolumenu pracy wykonanej przez system w okreĞlonym czasie i przy zaangaĪowaniu okreĞlonych zasobów Wymaganie fizyczne «physical ´Requirement» Dotyczy charakterystyki sprzĊtowej oraz fizycznych ograniczeĔ systemu lub jego elementów skáadowych Przykäad «functionalRequirement» Zamieszczenie apletu czatu w systemie e-learningowym id = F2.1.6 text = System winien umoĪliwiaü przeprowadzanie czatu, dostĊpnego dla wszystkich uczestników zdefiniowanej grupy studenckiej oraz prowadzącego przy stopniu dostĊpnoĞci szacowanym na 99 «interfaceRequirements» Transmisja danych w czasie rzeczywistym id = I4.1.3 text = System winien zapewniaü transmisjĊ danych tekstowych, dĨwiĊkowych i graficznych w czasie rzeczywistym w systemie e-learningowym zgodnie z wewnĊtrzną specyfikacją AFS/23/2009 «performanceRequirement» Krótki czas nawiązywania poáączenia z systemem bankowym id = P12.1.3 text = System winien zapewniü maksymalny czas autoryzacji karty páatniczej nie wyĪszy niĪ 5 sekund «physicalRequirement» DostĊpnoĞü terminali bankowych id = F1.2.1 text = System winien bazowaü na infrastrukturze sieciowej, umoĪliwiającej podáączenie co najmniej 2500 terminali bankowych w regionie 44 Jözyk inĔynierii systemów SysML. Architektura i zastosowania Tabela 2.5. Dodatkowe stereotypy wymagania zaawansowanego — ciąg dalszy Nazwa Ograniczenie projektowe Stereotyp «design ´Constraint» Charakterystyka Dotyczy ograniczeĔ projektowych, takich jak wykorzystanie technologii wáasnoĞciowych Przykäad «designRequirement» Wykorzystanie bazy danych Oracle id = D1.1.23 text = Ze wzglĊdu na integracjĊ z innymi systemami firmy, system winien byü oparty na bazie danych Oracle W jĊzyku SysML moĪna w zaleĪnoĞci od potrzeb wprowadzaü wáasne, autorskie stereo- typy, tak jak w jĊzyku UML.
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Język inżynierii systemów SysML. Architektura i zastosowania. Profile UML 2.x w praktyce
Autor:
,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: