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

Table of contents :
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)
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)
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)

Citation preview

Spis treści Wstęp .............................................................................................. 7 Rozdział 1. Architektura języka SysML ............................................................... 9 1.1. 1.2. 1.3. 1.4. 1.5.

Wprowadzenie do języka SysML ............................................................................ 9 Powstanie i ewolucja języka SysML ...................................................................... 10 SysML a metodologie i narzędzia tworzenia systemów ........................................ 12 Inżynieria systemów .............................................................................................. 13 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. 7.2. 7.3. 7.4. 7.5. 7.6.

Rodzaje diagramów UML4SysML ...................................................................... 119 Diagram przypadków użycia ............................................................................... 120 Diagram maszyny stanowej ................................................................................. 124 Diagram sekwencji .............................................................................................. 127 Diagramy pakietów .............................................................................................. 133 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

6

Język inżynierii systemów SysML. Architektura i zastosowania

Wstęp Modelowanie systemów informatycznych ma swoją długą historię, w której znaczące miejsce zajmują paradygmaty: strukturalny, społeczny, obiektowy i adaptacyjny. Obecnie szczególną pozycję w tej dziedzinie osiągnął reprezentujący paradygmat obiektowy język UML (ang. Unified Modeling Language), który stał się swoistym standardem w inżynierii oprogramowania. Język ten jest nieustannie rozwijany, aktualnie przygotowywana jest jego wersja 2.3. Popularność, precyzja i elastyczność tego języka sprawiły, że zainteresowały się nim inne niż informatycy grupy zawodowe, których reprezentanci tworzą systemy, wspierające różne sfery biznesu, technologii i administracji. Grupy te zajmują się modelowaniem i wdrażaniem szerokiego spektrum typów systemów, tj. inżynierią systemów. Jest to w istocie wielodyscyplinarne podejście do przekształcania zestawu potrzeb i wymagań interesariuszy w zharmonizowane rozwiązania systemowe, zaspokajające te wymagania. Przekształcaniem tym zajmują się inżynierowie systemowi. Inżynier systemów jest ogniwem łączącym różne, często odległe dyscypliny w projekcie, ujmując projekt całościowo, holistycznie — niezależnie od uwarunkowań sprzętowych, kadrowych czy poszczególnych perspektyw. Ta grupa zawodowa, skupiona w organizacji INCOSE, postanowiła zaadaptować język UML do swoich specyficznych potrzeb i uwarunkowań. W ten sposób rozpoczęły się prace nad nowym językiem — językiem SysML, które wspólnie koordynowały trzy organizacje:  OMG (ang. Object Management Group),  INCOSE (ang. International Council on System Engineering),  ISO (ang. International Organization for Standardization).

Owocem prac zespołów roboczych tych grup stał się adekwatny do potrzeb inżynierii systemów język modelowania systemów SysML (ang. Systems Modeling Language), czyli język modelowania ogólnego przeznaczenia, służący do specyfikowania, analizy, projektowania i weryfikacji złożonych systemów. Formalnie został on opublikowany w 2006 roku, a od tego czasu został zaktualizowany do wersji 1.1, co nastąpiło pod koniec 2008 roku.

8

Język inżynierii systemów SysML. Architektura i zastosowania

Ponieważ język SysML stał się w zaawansowanych technologicznie krajach rodzajem nieformalnego standardu w inżynierii systemów, autorzy postanowili go spopularyzować również w Polsce. Podstawowym materiałem źródłowym niniejszej książki jest specyfikacja języka SysML w postaci dokumentu OMG Systems Modeling Language (SysML), wersja 1.1, z dnia 1 listopada 2008 r. Inne materiały, które w istotny sposób przyczyniły się do przygotowania treści niniejszej książki, to:  nieliczne międzynarodowe publikacje, traktujące o języku SysML — w tym

książki, formalne dokumenty i artykuły osób, zaangażowanych w tworzenie specyfikacji SysML;  opracowania autorów, dotyczące języka UML — w tym (Wrycza, Marcinkowski

i Wyrzykowski, 2005), (Wrycza, red., 2007) — oraz liczne artykuły i referaty, publikowane na konferencjach zagranicznych i krajowych;  doświadczenia autorów, związane z analizą, projektowaniem, weryfikacją

i testowaniem systemów na podstawie języka SysML. Układ książki podporządkowano koncepcjom, diagramom i kategoriom modelowania charakterystycznym dla standardu SysML. Stąd niniejsza książka składa się z 7 rozdziałów, zorganizowanych wokół następujących zagadnień:  architektura języka SysML,  diagram wymagań systemowych,  diagram definiowania bloków,  diagram bloków wewnętrznych,  diagram parametryczny,  rozszerzony diagram czynności,  diagramy UML4SysML.

Książkę podsumowują dodatki, na które składa się angielsko-polski i polsko-angielski słownik najistotniejszych terminów języka SysML, spis rysunków oraz spis tabel. Intencją autorów jest rozpowszechnienie języka SysML poprzez prezentację jego architektury i zilustrowanie zasad użytkowania tego języka na licznych i zróżnicowanych przykładach praktycznych. Książka adresowana jest w szczególności do informatyków. Oferuje ona jednak również obszerny materiał dla wielu grup, zawodowo związanych z inżynierią: materiałową, elektryczności, procesową, mechaniczną i innymi. W związku z tym przykłady zawarte w niniejszej książce dotyczą przede wszystkim biznesowych zastosowań informatyki, lecz także zagadnień technicznych, przede wszystkim z zakresu sieci komputerowych.

Rozdział 1.

Architektura języka SysML 1.1. Wprowadzenie do języka SysML Opracowany i rozwinięty już w latach 90. XX wieku język UML (ang. Unified Modeling Language) stał się powszechnie akceptowanym rozwiązaniem w zakresie tworzenia systemów informatycznych, uzyskując pozycję standardu w dziedzinie inżynierii oprogramowania. Stał się on jednocześnie rodzajem lingua franca w modelowaniu obiektowych systemów informatycznych. Popularność ta została zauważona w środowiskach profesjonalnych, tworzących innego rodzaju systemy. W ten sposób język UML stał się inspiracją do zaproponowania założeń języka inżynierii systemów SysML, użytecznego w takich obszarach, jak inżynieria oprogramowania, inżynieria procesowa, inżynieria chemiczna, inżynieria mechaniczna, inżynieria elektryczna i innych dziedzinach inżynierii. W opinii niektórych autorów zajmujących się tym zagadnieniem (Friedenthal, Moore i Steiner, 2008) język modelowania systemów SysML jest językiem modelowania ogólnego przeznaczenia, służącym do specyfikowania, analizy, projektowania i weryfikacji złożonych systemów. Systemy te obejmować mogą sprzęt, oprogramowanie, zasoby informacyjne i ludzkie, procedury oraz urządzenia. Jest to więc graficzny język modelowania, oparty na semantyce, umożliwiającej reprezentowanie wymagań, dynamiki, struktury oraz cech systemu. Poza zastosowaniami ściśle informatycznymi język ten użyteczny jest w wielu dziedzinach, wykorzystujących szeroko pojętą inżynierię systemów. Należą do nich m.in.:  kosmonautyka,  automatyka,  przemysł zbrojeniowy,  telekomunikacja,  służba zdrowia,

10

Język inżynierii systemów SysML. Architektura i zastosowania  biotechnologia,  nanotechnologia,  energetyka,  chemia,  inne dziedziny techniczne,  biznes i modelowanie przedsiębiorstw.

1.2. Powstanie i ewolucja języka SysML Stowarzyszeniem zrzeszającym profesjonalistów z dziedziny inżynierii systemów jest INCOSE (ang. International Council on System Engineering). Powstało ono w 1995 roku z przekształcenia amerykańskiej organizacji NCOSE (ang. National Council on System Engineering). Organizacja ta liczy obecnie ponad 5000 członków z wielu zaawansowanych technologicznie krajów — głównie z USA, a także Francji, Wielkiej Brytanii, Holandii, RPA, Niemiec, Izraela, Australii i krajów skandynawskich. Grupa robocza tej organizacji MDSE (ang. Model-Driven Systems Design) zdecydowała w styczniu 2001 roku o zasadności adaptacji rozwijającego się języka UML do zastosowań inżynierii systemów. Skutkowało to podjęciem współpracy z organizacją standaryzacyjną, wspierającą rozwój języka UML — czyli OMG (ang. Object Management Group). W związku z tym ta ostatnia powołała w lipcu 2001 roku OMG SE DSIG (ang. OMG Systems Engineering Domain Special Interest Group). Współpracą nad opracowaniem założeń nowego języka zajęły się w konsekwencji trzy grupy robocze, reprezentujące różne organizacje:  OMG SE DSIG,  INCOSE,  ISO AP 233 (ISO Application Protocol 233).

Owocem tej współpracy było opublikowanie w marcu 2003 roku dokumentu RFP (ang. Request for Proposal), którego przedmiotem było zaprojektowanie nowego języka, użytecznego w inżynierii systemów. Język ten roboczo nazwano UML for Systems Engineering. Dokument RFP rozumieć należy w kategoriach zaproszenia potencjalnych, zainteresowanych partnerów do zgłaszania konkretnych propozycji, związanych z architekturą, składnią i semantyką przyszłego języka. W tym samym roku odbyło się spotkanie inicjujące partnerów pod kierunkiem S. Friedenthala oraz C. Kobryna. Spotkanie to przyczyniło się do rozpoczęcia 3-letnich prac nad wersją 1.0 języka z udziałem trzech głównych inicjatorów oraz wielu bardzo aktywnych partnerów, którzy pozytywnie odnieśli się od RFP. Wśród nich znaleźli się członkowie organizacji OMG, zarówno z sektora przemysłowego, jak i administracji — a także dostawcy narzędzi oraz podmioty zewnętrzne. Najważniejsi z nich to:

Rozdział 1. ♦ Architektura języka SysML

11

 American Systems,  Boeing,  Raytheon,  Lockheed Martin,  oose.de,  IBM,  Sparx Systems,  NASA Jet Propulsion Laboratory,  Georgia Institute of Technology.

Wstępne założenia języka, już pod docelową nazwą SysML (ang. Systems Modeling Language), zostały sformalizowane w styczniu 2004 roku. Ta wstępna specyfikacja była przedmiotem kompleksowej ewaluacji przez reprezentantów profesjonalnej grupy docelowej użytkowników, czyli inżynierów systemowych z organizacji INCOSE. Uwagi INCOSE i prace partnerów konsorcjum miały wpływ na doskonalenie pierwotnej formy języka SysML i publikowanych kolejnych wersji specyfikacji tego języka:  SysML 0.8 — w sierpniu 2004 r.;  SysML 0.85 — w październiku 2004 r.;  SysML 0.9 — w styczniu 2005 r.

Od sierpnia 2005 roku kolejne oceny ze strony INCOSE oraz uzupełnienia specyfikacji języka prowadziły bezpośrednio do jego finalizacji. Wersja 1.0 standardu SysML, wieńcząca intensywny okres 3-letnich prac nad specyfikacją, została ukończona w maju 2006 roku. Wersję tę opublikowano w formie oficjalnego standardu we wrześniu 2007 roku. Opublikowanie oficjalnej wersji języka nie zamyka naturalnie drogi jego ewolucji. Bieżące prace nad udoskonalaniem języka powierzono, podobnie jak w przypadku języka UML, zespołowi RTF (ang. Revision Task Force), funkcjonującemu w ramach organizacji OMG. Efektem tych prac było opublikowanie przez OMG w grudniu 2008 roku wersji 1.1 języka SysML. W maju 2009 roku ogłoszono założenia programu certyfikacyjnego z zakresu SysML — CSMP (ang. Certified Systems Modeling Professional). Program ten realizowany jest przez OMG wspólnie z INCOSE. Jednocześnie, w czerwcu 2009 roku, rozpoczęto intensywne zbieranie informacji, ukierunkowanych na wypracowanie mapy drogowej wsparcia metodologii inżynierii systemów zorientowanych na model (ang. Model-Based Systems Engineering Methodologies) przez język SysML. Zakres zbieranych danych wskazuje na plany wprowadzenia istotnej rewizji języka SysML.

12

Język inżynierii systemów SysML. Architektura i zastosowania

1.3. SysML a metodologie i narzędzia tworzenia systemów Język SysML, podobnie jak język UML, naturalnie nie stanowi sam w sobie metodologii tworzenia systemów informatycznych. Zapewnia on notację, która może zostać wykorzystana w połączeniu z dowolną istniejącą metodologią lub procesem tworzenia systemów. Należy zauważyć, że występuje wiele zaawansowanych metodologii inżynierii oprogramowania i metodologii z grupy MBSE, jawnie wykorzystujących elementy UML/SysML. Do metodologii, które mogą być stosowane w połączeniu z językiem SysML, należą między innymi:  Telelogic Harmony SE,  INCOSE Object-Oriented Systems Engineering Method,  IBM Rational Unified Process for Systems Engineering,  Vitech MBSE Methodology,  State Analysis.

Na potrzeby języka SysML opracowano lub zaadaptowano komputerowe narzędzia CASE. Ze względu na to, że język SysML jest relatywnie krótko dostępny na rynku, zasoby narzędzi CASE są w jego przypadku znacznie bardziej ograniczone niż w przypadku języka UML. Część użytkowanych w licznych firmach narzędzi ma charakter rozszerzeń do pakietów, które były oryginalnie zaprojektowane w celu wsparcia języka UML. Przykładowe narzędzia, dedykowane modelowaniu z wykorzystaniem SysML, to:  Enterprise Architect — moduł rozszerzający MDG Technology for SysML;  Magic Draw — moduł rozszerzający SysML;  Rational Software Modeler — zasobnik SysML;  Rational Software Architect — zasobnik SysML;  Rhapsody;  TAU G2.

Szczególnie intensywną działalność w zakresie pozyskiwania nowych użytkowników oferowanych narzędzi prowadzi koncern IBM. Jednym ze środków osiągania tego celu jest przejmowanie firm, oferujących wyróżniające się konkurencyjne produkty. I tak producenci dwóch ostatnich z wymienionych narzędzi funkcjonują pod marką IBM.

Rozdział 1. ♦ Architektura języka SysML

13

1.4. Inżynieria systemów Język SysML zaprojektowano jako język służący ogólnie pojętej inżynierii systemów, wspomagającej szeroki zakres sektorów technologicznych, biznesowych i administracji. Niektóre z tych dziedzin wymieniono w podrozdziale 1.1. Inżynieria systemów uzyskuje coraz większe znaczenie w wielu zaawansowanych technologicznie krajach. Dziedzina ta pojawiła się w latach 50., w związku z koniecznością sprostania złożoności realizowanych projektów militarnych, zbrojeniowych i kosmicznych. Dziś znajduje ona zastosowanie jako kluczowa praktyka do złożonych problemów, będących technologicznymi wyzwaniami. Autorzy (Friedenthal, Moore i Steiner, 2008) definiują inżynierię systemów jako wielodyscyplinarne podejście do przekształcania zestawu potrzeb i wymagań interesariuszy w zharmonizowane rozwiązania systemowe, zaspokajające te wymagania. Wspomniane problemy rozwiązywane są poprzez wielodziedzinowe zespoły, ukierunkowane na zróżnicowane perspektywy postrzegania systemu przez interesariuszy, co sprzyja osiągnięciu zharmonizowanego rozwiązania. Inżynieria systemów intensywnie wykorzystuje zróżnicowane przepływy pracy i narzędzia do rozwiązywania złożonych problemów, posiadając punkty wspólne z dziedziną zarządzania projektem. Inżynieria systemów wyznacza holistyczny, kompleksowy sposób myślenia o rozwiązaniu, począwszy od koncepcji systemu, poprzez jego tworzenie, aż do zastosowania. Inżynier systemów jest ogniwem łączącym różne, często odległe dyscypliny w projekcie. Myśli on o projekcie całościowo, niezależnie od uwarunkowań sprzętowych, kadrowych czy poszczególnych perspektyw. Proces inżynierii systemów może przebiegać zgodnie z modelem SIMILAR (Bahill i Gissing, 1998):  sformułowanie problemu (ang. State the problem);  wyszczególnienie alternatyw (ang. Investigate alternatives);  modelowanie systemu (ang. Model system);  integracja (ang. Integrate);  uruchomienie systemu (ang. Launch the system);  oszacowanie osiągów (ang. Assess performance);  ponowna ocena (ang. Re-evaluate).

Język SysML służy szerokiemu zakresowi inżynierii, takich jak inżynieria mechaniczna, elektroniczna, materiałowa czy procesowa (rysunek 1.1). Jednak najważniejszym obszarem jego zastosowania pozostaje inżynieria oprogramowania. Profesjonalna organizacja inżynierów systemów INCOSE rekomenduje SysML jako podstawowe narzędzie modelowania w wyżej wymienionych obszarach. Zgodnie z zaleceniami (INCOSE, 2007) 20 – 30% całego budżetu realizowanego projektu powinno przeznaczać się na inżynierię systemową. Przykładowe odmiany inżynierii zilustrowano na rysunku 1.1.

16

Język inżynierii systemów SysML. Architektura i zastosowania

Diagram SysML

Diagram wymag ań systemowych

Diagram zachowania

Diagram przypad ków użycia

Rozszerzon y diagram czynności

Diagram struktury

Diagram definiowania blo ków

Diagram sekwencji

Diagram maszyny stanowej

Diagram bloków wewnętrznych

Diagram pakietów

Diagram parametryczny

Diagramy identyczne jak w UM L 2.x Zm odyfikowane diagramy UML 2.x Now e rodzaje diagram ów

Źródło: (OMG, 2008)

Rysunek 1.3. Hierarchia diagramów języka SysML

diagramów. Mając na uwadze czytelników, legitymujących się przynajmniej podstawową znajomością standardu UML, przyporządkowano diagramy SysML do ich odpowiedników w języku UML 2.x. Tabela 1.1. Diagramy języka SysML i ich odpowiedniki w języku UML Rodzaj diagramu języka SysML

Dyscyplina zastosowań

Odpowiednik w języku UML 2.x

req

Inżynieria wymagań

(brak)

Graficzne przedstawienie przypadków użycia, aktorów oraz związków między nimi, występujących w danej dziedzinie przedmiotowej

uc

Specyfikowanie i precyzowanie wymagań funkcjonalnych

Diagram przypadków użycia

Graficzne przedstawienie sekwencyjnych i (lub) współbieżnych przepływów sterowania oraz danych pomiędzy uporządkowanymi ciągami czynności, akcji oraz obiektów

act

Analiza funkcjonalna

Diagram czynności

Charakterystyka

Wyróżnik

Diagram wymagań systemowych

Graficzne przedstawienie wymagań systemowych i ich relacji z innymi kategoriami modelowania systemu

Diagram przypadków użycia

Rozszerzony diagram czynności

Rozdział 1. ♦ Architektura języka SysML

17

Tabela 1.1. Diagramy języka SysML i ich odpowiedniki w języku UML — ciąg dalszy Rodzaj diagramu języka SysML

Dyscyplina zastosowań

Odpowiednik w języku UML 2.x

sd

Analiza i projektowanie

Diagram sekwencji

Graficzne odzwierciedlenie dyskretnych, skokowych zachowań skończonych systemów stan-przejście

stm

Projektowanie systemów, symulacje i generowanie szkieletowego kodu źródłowego

Diagram maszyny stanowej

Diagram definiowania bloków

Graficzne przedstawienie struktury systemu w postaci bloków, ich cech i związków

bdd

Analiza i projektowanie

Diagram klas

Diagram bloków wewnętrznych

Graficzne przedstawienie wewnętrznej struktury bloku, wyrażanej poprzez wzajemnie powiązane części bloków

ibd

Analiza i projektowanie

Diagram struktur połączonych

Diagram parametryczny

Graficzne przedstawienie ograniczeń parametrycznych pomiędzy kategoriami modelowania struktury systemu

par

Analiza wydajnościow a i ilościowa

(brak)

Diagram pakietów

Graficzne przedstawienie logicznej struktury systemu w postaci zestawu pakietów, połączonych zależnościami i zagnieżdżeniami

pkg

Zarządzanie modelami

Diagram pakietów

Charakterystyka

Wyróżnik

Diagram sekwencji

Graficzne przedstawienie interakcji pomiędzy aktorami, blokami, częściami bloków i obiektami w postaci sekwencji komunikatów wymienianych między poszczególnymi kategoriami modelowania

Diagram maszyny stanowej

(brak)

(nie dotyczy)

Diagram obiektów

(brak)

(nie dotyczy)

Diagram komunikacji

(brak)

(nie dotyczy)

Diagram harmonogramowania

(brak)

(nie dotyczy)

Diagram sterowania interakcją

(brak)

(nie dotyczy)

Diagram komponentów

(brak)

(nie dotyczy)

Diagram rozlokowania

Źródło: opracowanie własne na podstawie (SysMLForum, 2009)

18

Język inżynierii systemów SysML. Architektura i zastosowania

Rozdział 2.

Diagram wymagań systemowych 2.1. Znaczenie wymagań w procesie tworzenia systemu Jednym z najbardziej newralgicznych etapów procesu tworzenia systemu jest gromadzenie, specyfikacja, priorytetyzacja oraz akceptacja wymagań wobec projektowanego bądź użytkowanego systemu. Wymagania są wyrażonymi z sposób formalny potrzebami 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 konsekwencji, 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 iteracyjno-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 systemem, 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średnio od zleceniodawcy wykonania systemu w drodze wywiadu bądź analizy strategicznej dokumentacji firmy.

Rozdział 2. ♦ Diagram wymagań systemowych

21

technologicznych. Wymagania te są bezpośrednio przenoszone na kod źródłowy systemu 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 tekstowej, graficznej, tabelarycznej lub hierarchicznej. Jednym z popularnych sposobów specyfikowania 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ń systemowych, 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 wymagania 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ń systemowych i ich związków z innymi kategoriami modelowania systemu. Wymagania specyfikuje się w odniesieniu do następujących podstawowych kategorii modelowania 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 poszczególnych wymagań funkcjonalnych i pozafunkcjonalnych. Wymagania systemowe scharakteryzowano w punkcie 2.2.2. Z kolei zaawansowane aspekty wymagań ujęto w podrozdziale 2.3. Wymagania wiąże się na diagramach wymagań systemowych języka SysML związkami 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, istotnymi 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 kategorie modelowania wykorzystano w punktach 2.2.6, 2.2.8 i 2.2.9.

Rozdział 2. ♦ Diagram wymagań systemowych

23

Rysunek 2.3. Kategorie modelowania diagramu wymagań systemowych

Pakiety stanowią mechanizm ogólnego zastosowania, służący do organizowania elementów, w tym wymagań i innych kategorii modelowania diagramu wymagań systemowych. 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 konwencją, podkreślającą umiejscowienie danego wymagania w wielopoziomowej strukturze

Rozdział 2. ♦ Diagram wymagań systemowych

25

Tabela 2.1. Rodzaje związków na diagramach wymagań systemowych Nazwa

Notacja

zagnieżdżenie zależność wyprowadzania zależność realizacji zależność powielania zależność weryfikowania zależność precyzowania zależność śledzenia

«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 punkcie 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 szczycie 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 wymagań jest możliwe dzięki zależności powielania «copy», omówionej w dalszej części rozdział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:

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 wymaganiem 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 wyprowadzenie wymagania docelowego z wymagania źródłowego. Cechy systemu, reprezentowane 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 wyprowadzania. 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 poszczegó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 prowadzona we wszystkich wymienionych konwencjach. I tak bezpośrednią notację zależności «deriveReqt» przedstawiono na rysunku 2.7a, notatkową — rysunku 2.7b, a notatkową zagregowaną — na rysunku 2.7c.

2.2.6. Zależność realizacji Każde wymaganie systemowe musi zostać spełnione poprzez konkretne kategorie modelowania, 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. ♦ 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

Wymaganie źródłowe

Wymaganie docelowe

zależność wyprowadzania

«deriveReqt»

x

x

zależność realizacji

«satisfy»

x

zależność powielania

«copy»

x

zależność weryfikowania

«verify»

x

zależność precyzowania

«refine»

x

zależność śledzenia

«trace»

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 zilustrowano na rysunku 2.15. I tak rysunek 2.15 przedstawia zestaw wymagań systemowych w odniesieniu do systemu transakcyjnego banku. Przedmiotem wymagań jest obsługa przelewów. Nadrzędnym 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 funkcjonalności, kontrolującej poprawność danych, wprowadzonych do poszczególnych formatek.

Rozdział 2. ♦ 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ść wymagania 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 zaawansowane 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 reprezentacja 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ń systemowych zaprezentowano w tabeli 2.3. Tabela 2.3. Tabelaryczna reprezentacja wymagań systemowych Numer porządkowy

Nazwa

Treść

B1

Zdalne zarządzanie finansami osobistymi

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

B1.1

Obsługa płatności bieżących

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

B1.2

Obsługa kart płatniczych

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

B1.3

Obsługa lokat bankowych

System winien umożliwiać zakładanie, rozliczanie i wycofywanie środków pieniężnych przed upływem terminu lokaty

B1.4

Obsługa kredytów

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

B1.5

Obsługa ubezpieczeń

System winien oferować funkcjonalność zakładania ubezpieczeń na życie, komunikacyjnych, turystycznych, mieszkaniowych oraz ubezpieczeń z funduszem inwestycyjnym

B1.6

Obsługa funduszy inwestycyjnych

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

B1.7

Obsługa transakcji giełdowych

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. ♦ 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 Numer porządkowy

Nazwa

Wymaganie źródłowe Rodzaj związku

Numer porządkowy

Nazwa

B1.1.2.1.5

Wykonywanie przelewu zdefiniowanego

zagnieżdżenie

B1.1.2.1

Obsługa przelewów zdefiniowanych

B1.1.2.2.1

Wykonywanie przelewu jednorazowego

zagnieżdżenie

B1.1.2.2

Obsługa przelewów jednorazowych

B1.1.2.3.1

Wyświetlanie listy transakcji oczekujących

zależność śledzenia

B1.1.2.1.5

Wykonywanie przelewu zdefiniowanego

B1.1.2.3.1

Wyświetlanie listy transakcji oczekujących

zależność śledzenia

B1.1.2.2.1

Wykonywanie przelewu jednorazowego

B1.1.2.3.2

Wycofywanie przelewu

zależność śledzenia

B1.1.2.3.1

Wyświetlanie listy transakcji oczekujących

B1.1.2.2.2

Wykonywanie przelewu do Zakładu Ubezpieczeń Społecznych

zależność wyprowadzania

B1.1.2.2.1

Wykonywanie przelewu jednorazowego

B1.1.2.2.3

Wykonywanie przelewu do Urzędu Skarbowego

zależność wyprowadzania

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ązkó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;

Rozdział 3.

Diagram definiowania bloków 3.1. Rola bloków w dokumentacji systemu Współcześnie tworzone systemy, w tym systemy informatyczne, techniczne czy też organizacyjne, cechują się rozbudowaną strukturą wewnętrzną. Kategorie modelowania oraz diagramy, służące definiowaniu struktury systemu, należą do najczęściej stosowanych w praktyce elementów modelu systemu. Pojęcia klasy i obiektu są fundamentem paradygmatu obiektowego, a specyfikacje systemów informatycznych, tworzone w różnych obiektowych językach modelowania (np. w języku UML), intensywnie wykorzystują wspomniane kategorie modelowania w licznych diagramach, zarówno struktury, jak i dynamiki. Język SysML jest w znacznej mierze kontynuatorem opisanych tendencji. Dla inżynierów, wykorzystujących podejście systemowe, potrzebne było bardziej elastyczne rozumienie klasy. W języku tym opis architektury sprzętowej i programowej zorganizowano zatem wokół pojęcia bloku, otwierającego szersze pole modelowania dla innych niż inżynieria oprogramowania dziedzin inżynierii systemów. Dokumentowanie struktury systemów w oparciu o bloki możliwe jest z wykorzystaniem dwóch rodzajów diagramów:  diagramu definiowania bloków (ang. block definition diagram),  diagramu bloków wewnętrznych (ang. internal block diagram).

Drugi z wymienionych diagramów omówiono w rozdziale 4.

46

Język inżynierii systemów SysML. Architektura i zastosowania

3.2. Elementy diagramu definiowania bloków 3.2.1. Kategorie modelowania Diagramy definiowania bloków służą do precyzyjnej charakterystyki struktury systemu. W konkretnym projekcie po opracowaniu tych diagramów można przedstawić zastosowanie poszczególnych zidentyfikowanych bloków za pomocą diagramów bloków wewnętrznych. Podstawowe kategorie modelowania diagramów definiowania bloków to:  blok (ang. block),  związek (ang. relationship),  typ wartości (ang. value type),  aktor (ang. actor),  port (ang. port),  pakiet (ang. package).

Wymienione kategorie oraz logiczne zależności między nimi przedstawiono na rysunku 3.1. Kluczową kategorię modelowania w diagramach definiowania bloków są naturalnie bloki. Posiadają one unikatową tożsamość, zespół cech oraz zestaw opcjonalnych sekcji. Wprowadzeniu do bloków poświęcono punkty od 3.2.2 do 3.2.4, podczas gdy zaawansowanym aspektom specyfikacji bloku — podrozdział 3.3. Bloki łączy się szerokim spektrum związków: asocjacjami, uogólnieniami, zależnościami, realizacjami i zagnieżdżeniami. Szczególną rolę w aspekcie związków między blokami odgrywa jedna z cech asocjacji, tj. agregacja, opisująca związek całość-część pomiędzy blokami. Wynika to z konieczności modelowania struktury wielu składających się z komponentów składowych urządzeń i procesów technicznych. W odniesieniu do nich cecha agregacji pozwala odzwierciedlić złożoną strukturę projektowanego systemu. Mniejszą, choć pomocną i użyteczną rolę na diagramach definiowania bloków odgrywają uogólnienia, zależności, realizacje i zagnieżdżenia. Wymienione rodzaje związków zostały zaczerpnięte bez istotnych modyfikacji z języka UML, toteż w niniejszym opracowaniu pominięto ich szczegółową charakterystykę, ujętą w tekstach źródłowych (Wrycza, Marcinkowski i Wyrzykowski, 2005a). Dostęp do bloków, z racji ich obiektowej natury, uzyskiwany jest w zastosowaniach programistycznych na zasadzie referencji. Codzienna praktyka programistyczna i inżynierska wykorzystuje równolegle wobec typów referencyjnych typy danych, przechowywane i przekazywane przez wartość. W związku z tym diagramy definiowania bloków wprowadzają odpowiadające im kategorie modelowania, określane mianem typów wartości. Typom wartości oraz ich podstawowym charakterystykom — miarom oraz jednostkom miar — poświęcono punkt 3.2.6.

Rozdział 3. ♦ Diagram definiowania bloków

47

Rysunek 3.1. Kategorie modelowania diagramów definiowania bloków

W diagramach definiowania bloków zastosowanie znajduje również kategoria aktora osobowego bądź nieosobowego, wywodząca się z diagramów przypadków użycia UML/SysML. Wskazuje ona na spójny zbiór ról odgrywanych przez użytkowników przypadku użycia w czasie interakcji z tym przypadkiem użycia. W kontekście diagramów definiowania bloków kategorię aktorów wykorzystuje się do zidentyfikowania zasobów zewnętrznych, istotnych z punktu widzenia struktury systemu. Kolejną z podstawowych grup kategorii modelowania, którą można wykorzystać w diagramach definiowania bloków, są porty — wraz z towarzyszącymi im interfejsami, specyfikacjami oraz przepływami. Idea portów również ma swoje źródło w języku UML (a konkretnie diagramach komponentów), lecz w języku SysML istotnie poszerzono jej zakres merytoryczny i zastosowanie. Kategorię modelowania portu omówiono w rozdziale 4. Pakiety stanowią mechanizm ogólnego zastosowania, służący do organizowania elementów, w tym bloków i innych kategorii modelowania diagramu definiowania bloków. Tym samym pakiety i omówione w podrozdziale 7.5 diagramy pakietów są użyteczne w zarządzaniu złożonością modelu struktury systemu.

48

Język inżynierii systemów SysML. Architektura i zastosowania

3.2.2. Bloki Punktem wyjścia tworzenia diagramu definiowania bloków jest identyfikacja poszczególnych bloków (ang. blocks), z których dany system się składa. Blok zgodnie z dokumentacją języka (OMG, 2008) stanowi modularną jednostkę, która opisuje strukturę systemu lub elementu. Jak uzasadniają autorzy opracowań (Friedenthal, Moore i Steiner, 2008), blok pozwala na modelowanie dużej grupy bytów, które posiadają strukturę — takich jak systemy, sprzęt, oprogramowanie, obiekty fizyczne i byty logiczne. A zatem blok reprezentuje dowolny konkretny lub konceptualny byt, który można modelować jako jednostkę strukturalną z jedną lub więcej niż jedną z wyróżnialnych cech. Blok jest uogólnieniem zestawu identyfikowalnych instancji, które odpowiadają definicji bloku. Bloki są używane do identyfikowania ponownie używanych komponentów, które mogą mieć potem zastosowanie w wielu innych systemach. Analitycy i projektanci oprogramowania komputerowego, stanowiący jedną z grup zawodowych, do których język SysML jest adresowany, będą niewątpliwie utożsamiać pojęcie bloku z pojęciem klasy obiektu. W istocie bowiem blok jest rozwinięciem koncepcji klasy. Konieczność tej modyfikacji wynika z tego, że bloki znajdują zastosowanie w szeroko rozumianej inżynierii systemów, wykraczającej poza inżynierię oprogramowania. Tak więc diagramy struktury języka SysML powinny stwarzać również możliwość modelowania specyficznych kategorii z zakresu inżynierii procesowej, mechanicznej, materiałowej i innych. Diagramy klas w ich oryginalnej postaci, bardzo przydatne chociażby w modelowaniu architektury obiektowych baz danych, okazały się tu niewystarczającym instrumentarium modelowania. Bloki mogą w szczególności mieć charakter: a) sprzętowy — reprezentują fizycznie istniejące kompletne urządzenia,

poszczególne części lub zestawy tych urządzeń (do tej kategorii należy zaliczyć zwłaszcza różnego rodzaju sprzęt komputerowy i urządzenia sieciowe — por rysunek 3.2a); b) programowy — symbolizują zasoby danych, moduły oprogramowania

czy też usługi (rysunek 3.2b); c) organizacyjny — wskazują na jednostki organizacyjne, sformalizowane

procedury, pomieszczenia bądź dokumenty (rysunek 3.2c).

3.2.3. Cechy bloku Bloki uszczegóławia się poprzez identyfikację cech i sekcji bloków. I tak bloki definiują zestaw wspólnych pierwotnych cech, którymi musi charakteryzować się instancja bloku. Cechy te obejmować mogą:  wartości (ang. values) — czyli opisowe bądź liczbowe atrybuty bloku, takie

jak częstotliwość taktowania zegara, zasoby pamięci, rodzaj zastosowanego szyfrowania czy też data złożenia zamówienia;

50

Język inżynierii systemów SysML. Architektura i zastosowania

Tabela 3.1. Składnia cech bloku Cecha

Przykład

Komentarz

Wartość

algorytmSzyfrujący : String

Wartość wraz z typem danych

algorytmSzyfrujący : String = "MD5"

Jw., uzupełniona o wartość domyślną

/łącznaLiczbaPortów : int

Wartość o charakterze pochodnym, która wyliczana jest na podstawie innych wartości

ISBN : String {unique}

Ograniczenie przypisane do konkretnej wartości

stawkaGodzinowa : real {readOnly}

Wartość statyczna z ograniczeniem wskazującym, że wartość ma charakter stałej

inicjujAlarm()

Operacja identyfikowana wyłącznie przez nazwę

zablokujPort(idPortu, czas, czyLog)

Operacja ze wskazaniem listy parametrów

zmieńStatus(status : String)

Operacja parametryzowana z uwzględnieniem typu danych

szyfruj(: String) : int

Operacja z podaniem typu danych parametru i wartości zwrotnej

{maxCzasTrwaniaEgzaminu = 120}

Formalny zapis ograniczenia

{dane wejściowe zgodnie z normą HX}

Werbalny zapis ograniczenia

WIC-2T : Karta rozszerzeń

Nazwa części wraz z definiującym ją blokiem

a : Adres [1..3] {ordered}

Część z uwzględnieniem liczebności oraz ograniczenia

: Reklamacja

Odniesienie poprzez wskazanie nazwy bloku

platforma : Router

Odniesienie poprzez wskazanie nazwy cechy i bloku

Operacja

Ograniczenie Część

Odniesienie

3.2.4. Sekcje bloku Kolejną charakterystyką bloków są ich sekcje (ang. compartments). Graficzna notacja bloku w języku SysML przewiduje jawne wyszczególnienie przynajmniej jednej sekcji — mianowicie sekcji nazwy. Naturalnie w zależności od potrzeb można uzupełniać listę sekcji poszczególnych bloków. I tak dowolny blok na diagramie definiowania bloków może charakteryzować się posiadaniem: a) wyłącznie sekcji nazwy (rysunek 3.3a); b) standardowego kanonu opcjonalnych sekcji, będących konsekwencją

uzupełnienia sekcji nazwy o jawne wskazanie przynajmniej jednej cechy bloku (rysunki 3.3b i 3.3c); c) sekcji o charakterze zaawansowanym, w tym sekcji alokacji, sekcji przestrzeni

nazw oraz sekcji struktury wewnętrznej (por. podrozdział 3.3); d) sekcji zdefiniowanych przez użytkownika w miarę pojawiania

się szczegółowych potrzeb.

52

Język inżynierii systemów SysML. Architektura i zastosowania

Tabela 3.2. Związki w diagramach definiowania bloków Rodzaj związku

Notacja

Charakterystyka

Asocjacja

Opisuje związek pomiędzy dwoma elementami (w diagramach definiowania bloków — blokami). Podstawowe cechy asocjacji obejmują:  nazwę;  rolę odgrywaną przez dany blok w stosunku do innego bloku i odwrotnie;  liczebność, czyli określenie liczby instancji danego elementu, które wiążą się z pojedynczą instancją innego elementu (np. bloku);  nawigację, czyli specyfikację kierunku efektywnego przesyłania informacji w ramach asocjacji;  agregację, charakteryzującą związek całość-część między blokami

Uogólnienie

Specyfikuje związek o charakterze taksonomicznym pomiędzy ogólną a specjalizowaną kategorią modelowania

Zależność

Wskazuje na związek pomiędzy dwiema kategoriami modelowania, w którym zmiana jednego z nich, niezależnego, wpływa na drugi, zależny. W szczególności wskazuje na sytuację, w której dany blok wymaga funkcjonalności oferowanej przez powiązany interfejs

Realizacja

Związek znaczeniowy między elementami, z których jeden określa kontrakt, a drugi zapewnia wywiązanie się z niego. Na diagramach definiowania bloków funkcjonuje on jako szczególny przypadek zależności, wskazujący, że dany blok definiuje i oferuje funkcjonalność wskazaną przez powiązany interfejs

Zagnieżdżenie

Związek łączący bloki nadrzędne z podrzędnymi, dzięki czemu powstaje wielopoziomowa, hierarchiczna struktura bloków

W stosunku do związków, zdefiniowanych w specyfikacji języka UML, w języku SysML dokonano następujących istotnych zmian i modyfikacji:  zrezygnowano z asocjacji n-arnych, ze względu na to, że ich funkcję pełnić

może blok zamieszczony centralnie w strukturze innych wzajemnie powiązanych asocjacjami bloków; w ten sposób upraszcza się składnię języka, nie rezygnując jednocześnie z pełni możliwości;  zredukowano złożoność cech asocjacji poprzez wyłączenie cechy kwalifikacji

i zaawansowanych aspektów nawigacji,  umożliwiono bardziej intensywne zastosowanie związku zagnieżdżenia

w diagramach definiowania bloków; w języku UML 2.x związek ten wykorzystywany był głównie w diagramach pakietów. Diagram definiowania bloków, demonstrujący zastosowanie związków, przedstawia rysunek 3.4.

54

Język inżynierii systemów SysML. Architektura i zastosowania

Każdy produkt należy do jednej z Kategorii, ułożonych tematycznie i hierarchicznie. Kategorie mogą mieć dowolną liczbę podkategorii. Alternatywnie lub komplementarnie, Klient może użyć Wyszukiwarki do odnalezienia interesujących go Produktów. Pomocną rolę w opisie Produktu odgrywają Zdjęcia produktów. Po sfinalizowaniu Zamówienia Klient przystępuje do dokonania Płatności, którą może zrealizować w formie:  Płatności pobraniowej,  Płatności w terminalu POS dostawcy,  Płatności kartą kredytową,  Płatności bonami.

Możliwość dokonania płatności bonami wiąże się z uczestnictwem Klienta w Programie lojalnościowym.

3.2.6. Typy wartości Typy wartości (ang. value types) są koncepcją, wywodzącą się bezpośrednio z dziedziny programowania komputerów. W języku SysML typy wartości stosuje się do opisu poszczególnych cech bloków i parametrów operacji. Wyszczególnienie osobnej kategorii modelowania wiąże się z odmiennym sposobem obsługi danych, reprezentowanych przez typy wartości. W momencie utworzenia instancji typu wartości — na przykład zadeklarowania zmiennej — na potrzeby tej instancji alokowany jest pojedynczy obszar pamięci. Wszelkie dalsze działania odnoszące się do tej instancji (takie jak zmiana wartości danych czy skasowanie jej) mają charakter bezpośredniego manipulowania danymi. Stanowi to zasadniczą różnicę w stosunku do obsługi bloków. Utworzenie instancji bloku wiąże się bowiem z alokowaniem dwóch osobnych obszarów pamięci — jednego na potrzeby właściwych danych, a drugiego — na potrzeby referencji, wskaźnika do tych danych, pośredniczącego w dalszych działaniach. Referencja oznacza dane, które zawierają informację o położeniu innych danych. W momencie przypisania uprzednio utworzonej instancji typu wartości do innej instancji wartość, reprezentowana przez instancję pierwotną, zostaje skopiowana do osobnego obszaru pamięci. Kopia jest całkowicie niezależna od danych pierwotnych, stąd zmiana wartości kopii nie wpływa w żadnym stopniu na wartość pierwotną. Z kolei przypisanie uprzednio utworzonej instancji bloku do nowej instancji powiela jedynie referencję — nowa referencja wskazuje na dokładnie ten sam obszar w pamięci (zawierający dane właściwe) co referencja pierwotna. Stąd ewentualna zmiana wartości kopii zmieni także wartość pierwotną. Po zdefiniowaniu własnych typów wartości można je wykorzystać przy definiowaniu bloków, jak zaprezentowano na rysunku 3.5. Na rysunku 3.5 zdefiniowano blok Płatność kartą kredytową. Wartości tego bloku obejmują datę płatności i datę ważności. Typ danych, wykorzystywany przez obie wymienione daty, zdefiniowano z wykorzystaniem typu wartości Data krótka. Z kolei

56

Język inżynierii systemów SysML. Architektura i zastosowania

Rysunek 3.6. Różne rodzaje typów wartości

częstotliwość (herce), ciśnienie (paskale), opór prądu elektrycznego (omy). Również w informatyce występuje wiele popularnych miar i jednostek miar, które w formie stereotypowanych przedstawiono na rysunku 3.7. I tak wybranymi jednostkami miar Przepustowości sieci są kB/s, Mb/s i Gb/s. Z kolei jednostki miar Rozdzielczości drukarki obejmują DPI (Dots per Inch — liczba punktów na cal), podczas gdy Rozdzielczość ekranu wyraża się poprzez Liczbę pikseli. Spośród licznych miar Wydajności sprzętu komputerowego wymienić należy FLOPS (Floating Point Operations per Second — liczba operacji zmiennoprzecinkowych na sekundę) oraz Liczba operacji na wat. Ta druga miara popularyzuje się w związku z przetwarzaniem ekologicznym (ang. Green Computing).

3.3. Zaawansowana specyfikacja bloków 3.3.1. Dodatkowe sekcje bloku Poza wymienionymi wyżej najbardziej popularnymi sekcjami standard OMG SysML dopuszcza wykorzystanie następujących, rzadziej używanych sekcji:  struktury (ang. structure), umożliwiającej zaprezentowanie bloku w postaci

tzw. białej skrzynki (ang. white box); zastosowanie sekcji struktury polega na jawnym zamieszczeniu kompletnego lub wycinkowego diagramu bloków

Rozdział 3. ♦ Diagram definiowania bloków Rysunek 3.7. Miary oraz jednostki miar

wewnętrznych wewnątrz modelowanego bloku; tym samym sekcja struktury może zawierać dowolne kategorie modelowania, właściwe dla diagramu bloków wewnętrznych (rysunek 3.8);  przestrzeni nazw (ang. namespace), pozwalającej na graficzne wyszczególnienie

wszystkich podrzędnych bloków modelowanego bloku w ramach sekcji tego bloku; w hierarchii zagnieżdżeń każda podrzędna, unikatowo nazwana kategoria modelowania musi być składnikiem przestrzeni nazw danej kategorii modelowania; w ten sposób można jednoznacznie identyfikować poszczególne kategorie modelowania w ramach przestrzeni nazw;  alokacji (ang. allocation), umożliwiającej mapowanie jednego zestawu kategorii

modelowania na inny zestaw kategorii podczas projektowania, co szerzej omówiono w punkcie 3.3.5.

57

Rozdział 3. ♦ Diagram definiowania bloków

61

SysML. Umożliwia ona luźne powiązanie elementów modelu, obejmującego różne rodzaje diagramów, w celu ich powiązania przed podjęciem precyzyjnego projektowania, opracowywania ścisłej specyfikacji tworzonego systemu. Jest to zatem bardziej abstrakcyjna forma niż efekt technicznego projektowania systemu, który powinien zawierać wszystkie ograniczenia. Alokacja stosowana jest we wczesnej fazie projektowania, przed podjęciem projektowania właściwego. Po określeniu alokacji w specyfikacji systemu następuje uściślanie, precyzowanie modelu. I tak alokacja może być później wykorzystana w procesie doskonalenia systemu, gdy wraz z postępem procesu projektowania pojawiają się nowe reguły i ograniczenia. W ten sposób alokacja staje się czynnikiem integrującym proces projektowania poprzez:  specyfikację poszczególnych kategorii modelowania różnych diagramów;  wykazanie związków między nimi;  wykazanie wzajemnego oddziaływania, sprzyjającego precyzowaniu specyfikacji

tych kategorii modelowania. Staje się ona więc metodą, swoistym spoiwem kluczowych składników modelu systemu. Tak jak istnieją zróżnicowane rodzaje diagramów SysML, przeznaczone dla różnych celów, tak istnieją różne formy alokacji. Należą do nich:  alokacja zachowania,  alokacja struktury,  alokacja przepływów.

Alokacja zachowania dotyczy alokowania elementów diagramów dynamiki systemu — czynności, akcji, stanów, przepływu obiektów, przepływu sterowania, przejść międzystanowych, komunikatów itd. — do elementów strukturalnych, tj. bloków, cech, części, portów, konektorów. Autorzy (Friedenthal, Moore i Steiner, 2008) podkreślają znaczenie alokacji funkcjonalnej — tj. szczególnego przypadku alokacji zachowania w postaci alokacji czynności do bloków — jako typowego przykładu alokacji w języku SysML. Z kolei alokacja struktury odnosi się do alokowania kategorii modelowania jednego modelu strukturalnego do kategorii modelowania innego modelu strukturalnego. Są to więc zależności pomiędzy kategoriami modelowania diagramów definiowania bloków i diagramów bloków wewnętrznych. Przykładem jest alokowanie oprogramowania na określonym sprzęcie; kwestia te wiąże się w ścisły sposób z diagramami komponentów i rozlokowania języka UML. Alokacja przepływów pozwala na wskazanie, w jakim zakresie przepływy zasobów (materii, energii czy też informacji) na diagramach bloków wewnętrznych wynikają z przepływów obiektów na diagramach czynności. W kontekście diagramów definiowania bloków języka SysML alokację można przedstawić za pomocą kilku różnych notacji:  bezpośredniej,  sekcyjnej,

64

Język inżynierii systemów SysML. Architektura i zastosowania

Tabela 3.3. Tabelaryczna specyfikacja alokacji Rodzaj kategorii modelowania

Nazwa kategorii modelowania

Typ

Związek

Rodzaj kategorii modelowania

Nazwa kategorii modelowania

Typ

blok

Lista zakupowa

źródło

alokacja

blok

Koszyk

cel

blok

Lista zakupowa

cel

alokacja

czynność

Utwórz szablonowe zamówienie

źródło

blok

Koszyk

cel

alokacja

blok

Lista zakupowa

źródło

blok

Koszyk

cel

alokacja

czynność

Skoryguj liczebność zamawianych towarów

źródło

blok

Koszyk

cel

alokacja

czynność

Dodaj do koszyka

źródło

blok

Wyszukiwarka zaawansowana

cel

alokacja

czynność

Zawęź kryteria wyszukiwania

źródło

blok

Wyszukiwarka zaawansowana

cel

alokacja

czynność

Wyszukaj substytuty produktu

źródło

bloki-czynności czy też części-akcje. Notacja macierzowa jest szczególnie użyteczna dla wyspecyfikowania wielokrotnych alokacji pomiędzy elementami — dzięki zastosowaniu formy macierzy unika się powtórzeń. Strzałki w macierzy wskazują kierunek alokacji. Należy podkreślić ogólny, przeglądowy charakter metody tabelarycznej, gdyż nie zawiera ona wielu szczegółów alokacji.

Rozdział 4.

Diagram bloków wewnętrznych 4.1. Elementy diagramu bloków wewnętrznych 4.1.1. Kategorie modelowania Diagramy bloków wewnętrznych umożliwiają zdefiniowanie zastosowania bloków w określonym kontekście poprzez wskazanie, jakie zasoby fizyczne, informacyjne oraz usługi systemowe są użytkowane przez poszczególne części bloków. Umożliwia to bardziej precyzyjne modelowanie wewnętrznej struktury bloku niż proste, tekstowe wyszczególnienie listy części w odpowiedniej sekcji bloku na diagramach definiowania bloków. Diagramy bloków wewnętrznych bazują na diagramach struktur połączonych języka UML. Główną wartością dodaną diagramów bloków wewnętrznych jest możliwość odzwierciedlenia aspektów dynamicznych bloku w systemie. Podstawowym instrumentarium, stosowanym do tego celu, są różne odmiany portów, definiujące zasady interakcji części bloków z ich otoczeniem. Główne kategorie modelowania, wykorzystywane na diagramach bloków wewnętrznych, to:  część (ang. part),  port (ang. port),  związek (ang. relationship).

Wymienione kategorie oraz logiczne zależności między nimi ujęto na rysunku 4.1.

66

Język inżynierii systemów SysML. Architektura i zastosowania

Rysunek 4.1. Kategorie modelowania diagramów definiowania bloków

Tak więc diagram bloków wewnętrznych zorientowany jest na wewnętrzną strukturę konkretnego bloku, która wyrażana jest poprzez wzajemnie powiązane części, elementy składowe bloków. Częściom poświęcono punkt 4.1.2. Zaawansowane koncepcje, związane z praktycznym wykorzystaniem części, omówiono w podrozdziale 4.2. Diagramy bloków wewnętrznych intensywnie wykorzystują kategorię modelowania portu. W odróżnieniu od diagramów definiowania bloków, w których porty występowały głównie w kontekście definiowania bloku jako „białej skrzynki”, w diagramach bloków wewnętrznych jest to rutynowo stosowana kategoria modelowania. Oprócz powszechnie wykorzystywanych przez analityków i projektantów systemów informatycznych portów standardowych oraz interfejsów udostępniających i pozyskujących język SysML wyszczególnia porty transmisyjne oraz wiążące się z nimi specyfikacje przepływu. Kategorie te omówiono szczegółowo w punktach od 4.1.3 do 4.1.7. Merytorycznie powiązane przepływy zasobów scharakteryzowano z kolei w punkcie 4.2.4. Dla zachowania jednoznaczności relacji pomiędzy poszczególnymi portami części, interfejsami i samymi częściami wiąże się je z wykorzystaniem kilku rodzajów związków. Podstawowym rodzajem związku na diagramach bloków wewnętrznych są konektory. Prezentacja interfejsów z wykorzystaniem stereotypów tekstowych wiąże się z zastosowaniem związków zależności i realizacji.

Rozdział 4. ♦ Diagram bloków wewnętrznych

67

4.1.2. Części Części (ang. parts), obok wartości, operacji, ograniczeń, odniesień i cech uniwersalnych, należą do pierwotnych cech bloku. Część opisuje lokalne zastosowanie bloku, definiującego część, w określonym kontekście, do którego ta część należy. Przykładowo, blok definiujący czytnik kart może być użytkowany na wiele sposobów — inne będzie bowiem wykorzystanie wspólnej definicji czytnika w przypadku modułu rejestracji czasu pracy, a inne w przypadku modułu nadzoru bezpieczeństwa firmy. Blok macierzysty przyjmuje na diagramie postać ramy diagramu bloków wewnętrznych. Ramy wykorzystuje się w odniesieniu do dowolnego diagramu języka SysML, lecz w przypadku kompletnych diagramów bloków wewnętrznych ma ona charakter obligatoryjny. Składnia nazwy diagramu powinna zawierać nazwę bloku, którego części diagram opisuje. Z kolei składnia nazwy części zawiera nazwę właściwą oraz nazwę bloku, definiującego tę część. Elementy te oddziela się dwukropkiem; wymagany jest tylko jeden z nich. Częstą praktyką jest zamieszczanie na diagramach anonimowych części, poprzez wskazanie jedynie ich bloków definiujących. I tak poszczególne części bloku macierzystego Serwis transakcyjny sklepu internetowego zaprezentowano na rysunku 4.2. Rysunek 4.2. Wybrane części bloku Serwis transakcyjny sklepu internetowego

ibd [block] Serwis transakcyjny sklepu internetowego [przykłady części]

: Koszyk

kat04/2010 : Katalog produktów

zaaw : Wyszukiwarka

: Lista zakupowa

W celu bardziej precyzyjnego odzwierciedlenia cech części najbardziej powszechny zapis części z ujęciem wyłącznie sekcji nazwy można uzupełniać o kolejne sekcje, charakteryzujące te części — podobnie jak w przypadku bloku (por. rozdział 3.). Dobór i kolejność sekcji pozostaje w gestii projektanta systemu.

4.1.3. Klasyfikacja portów Port (ang. port) stanowi punkt interakcji z otoczeniem na krawędzi bloku lub jego części. Wskazuje na aspekty dynamiczne części bądź jej bloku macierzystego poprzez umożliwienie przepływu zasobów lub przywoływanie usług systemowych. Podstawową motywacją definiowania portów w odniesieniu do kategorii modelowania systemu

68

Język inżynierii systemów SysML. Architektura i zastosowania

jest tendencja do projektowania modularnych bloków, które dzięki jednoznacznej definicji interfejsów mogą być wielokrotnie wykorzystywane — zgodnie z dobrymi praktykami projektowania. Pojedyncza część lub blok mogą być wyposażone w wiele portów, wspierających różnego rodzaju interakcje tej części/bloku. Porty, mimo że są bezpośrednio przypisane do wyspecyfikowanych kategorii modelowania systemu i są integralną częścią ich definicji, mogą być powiązane konektorami (ang. binding connectors) tylko z innymi portami danego rodzaju. W języku SysML wyróżnia się dwa rodzaje portów:  port standardowy (ang. standard port) — który wiąże się z usługami

systemowymi, świadczonymi lub wymaganymi przez blok; usługi te określane są przez interfejsy — interfejs udostępniający i pozyskujący,  port transmisyjny (ang. flow port) — określający, co może wpływać i co może

wypływać z bloku. Kombinacja portów transmisyjnych i standardowych może być stosowana w każdym modelu, lecz nie można łączyć portów transmisyjnych z portami standardowymi i odwrotnie. Porty transmisyjne są dedykowane modelowaniu powtarzalnego przepływu bytów fizycznych pomiędzy częścią bądź blokiem a otoczeniem. Stanowią one punkty interakcji, przez które kategoria modelowania systemu jest zasilana zasobami materialnymi, energetycznymi lub informacyjnymi — bądź przez które wspomniane zasoby ją opuszczają. Wyróżnia się następujące odmiany portów transmisyjnych:  pojedyncze (ang. atomic) — w których przepływ dotyczy wyselekcjonowanego,

niepodzielnego zasobu — na przykład prądu elektrycznego, gazu czy też bitów;  zagregowane (ang. non-atomic) — w których przepływ ma charakter złożony,

tj. przez jeden port przepływa kilka różnych zasobów, a poszczególne z tych zasobów mogą przepływać w odmiennych kierunkach.

4.1.4. Pojedyncze porty transmisyjne Przepływy transmisyjne graficznie przyjmują postać stereotypowanego portu standardowego. Stosuje się szereg stereotypów, wskazujących na kierunek przepływu zasobu. I tak w przypadku pojedynczych portów transmisyjnych wyróżnić można następujące stereotypy graficzne: 

oraz

, wskazujące na jednokierunkowy charakter transmisji;



, wskazujący na transmisję dwukierunkową.

Standardowe nazewnictwo pojedynczych portów transmisyjnych oparte jest na pojedynczym typie, stąd do specyfikacji portu wystarczy wyszczególnienie jego pełnej bądź cząstkowej nazwy. Składnia ta przedstawia się tak jak poniżej: [] :

Rozdział 4. ♦ Diagram bloków wewnętrznych

71

fikuje przesłane dane i transmituje komunikat o pomyślnej autoryzacji. W tym momencie jest on gotowy do otrzymywania poleceń o charakterze zarządczym. Po unieruchomieniu pojazdu do Modułu zarządzającego przekazywana jest aktualna lokalizacja pojazdu. Port Modułu zarządzającego (IZdalny) również posiada specyfikację przepływu. Naturalnie poszczególne elementy specyfikacji są w jego przypadku analogiczne do specyfikacji portu ILokalny, różniąc się jedynie kierunkami transmisji.

4.1.6. Sprzęganie zagregowanych portów transmisyjnych W sytuacji, gdy specyfikacja identyfikatorów kierunku w jednym zagregowanym porcie transmisyjnym jest dokładną odwrotnością w innym porcie zagregowanym, można wykorzystać pojęcie portu sprzężonego (ang. conjugated port). W praktyce taka sytuacja występuje zawsze przy wzajemnie powiązanych portach zagregowanych. Dzięki zastosowaniu portu sprzężonego związek taki wymaga zastosowania specyfikacji przepływu tylko po jednej stronie konektora łączącego porty, gdyż przez porty te wymieniane są analogiczne zasoby. Odwróceniu ulegają jedynie kierunki przepływu tych zasobów (in zostaje zamienione na out i odwrotnie; inout, oznaczający przepływ dwukierunkowy, nie ulega zmianie). I tak zagregowane porty transmisyjne mogą przyjmować jedną z dwóch notacji (por. rysunek 4.5): 

, gdy danemu portowi z pary powiązanych portów przypisano specyfikację przepływu;



, gdy dany port ma charakter portu sprzężonego — a co za tym idzie, jego specyfikacja przepływu została intencjonalnie pominięta.

Przykład zastosowania portu sprzężonego zilustrowano na rysunku 4.5. Rysunek 4.5, podobnie jak rysunek 4.4, ujmuje wewnętrzną strukturę bloku Kontroler alarmowy pojazdu. W tym jednak przypadku w odniesieniu do portu IZdalny wykorzystano notację portu sprzężonego. Pozwoliło to zrezygnować z zamieszczania na diagramie specyfikacji przepływu tego portu, jako że jest ona odwróceniem specyfikacji przepływu portu ILokalny.

4.1.7. Porty standardowe Porty standardowe wywodzą się bezpośrednio z języka UML (Wrycza, Marcinkowski i Wyrzykowski, 2005a). Umożliwiają one udostępnianie i pozyskiwanie usług systemowych poprzez interfejsy portu. Porty standardowe stosowane są w kontekście architektury opartej na usługach. Port standardowy może użytkować dwa rodzaje interfejsów:  interfejs pozyskujący, określający usługi (operacje), wymagane przez blok

lub jedną z jego części w celu wykonywania funkcjonalności tego bloku lub jego części;

74

Język inżynierii systemów SysML. Architektura i zastosowania

Po wyliczeniu indeksu zmieniana jest wartość w części : Indeks (IAktualizacja), która swoją aktualną wartość oferuje innym kategoriom modelowania dzięki wykorzystaniu interfejsu IWartość. Część : ZapisDanych odpowiedzialna jest za odpowiednie przygotowanie formatu danych, dotyczących indeksów (IPrzekalkulowany) pod kątem zapisu w bazie danych. Usługi swe udostępnia poprzez interfejs IZapis. W części sesja przechowywane są wszystkie parametry indeksu (poza algorytmem), które dostarczane są innym częściom (: KalkulatorIndeksu, : AplikacjaWprowadzaniaIndeksu) poprzez interfejs IParametry. Prowadzi to do sytuacji, w której część indeksowanie dostarcza swoje usługi innym częściom poprzez interfejs IAlgorytm. Podobnie jak interfejs IAlgorytm, interfejs IParametry stereotypowano tekstowo. Moduł Indeksator umożliwia również modyfikację parametrów indeksu oraz algorytmu wyliczania. Częścią odpowiedzialną za interakcję z użytkownikiem jest część GUI, definiowana przez blok StykStacjiRoboczej. Część ta oferuje funkcjonalność dzięki interfejsom IWprowadzanie oraz IKomunikaty. Użytkownik może przejrzeć istniejące indeksy (IPrzeglądanieIndeksów), jak również wprowadzić nowy, bądź modyfikować już istniejący indeks dzięki interfejsowi IWprowadzanie. Część : AplikacjaWprowadzaniaIndeksów odpowiedzialna jest za całą logikę implementowania zmian w indeksach. W tym celu wymaga informacji z interfejsów o istniejących parametrach (IParametry) oraz algorytmie (IAlgorytm). Część sama udostępnia interfejsy INowyAlgorytm oraz INoweParametry, dostarczające usług, modyfikujących bieżący algorytm oraz parametry indeksu.

4.2. Zaawansowane elementy diagramów bloków wewnętrznych 4.2.1. Przywołanie bloku/części W praktycznych aplikacjach często zachodzi konieczność odwołania się do bloków oraz części, niestanowiących elementów składowych danego bloku. Wspomniane kategorie modelowania należy wyszczególnić na diagramie bloków wewnętrznych podczas specyfikowania lokalnego zastosowania części bloku macierzystego w określonym kontekście. Określa się to mianem przywołania (ang. reference) bloku lub części. Przywoływany blok lub część może jawnie wyszczególniać wszystkie swoje cechy w postaci odpowiednich sekcji. Notacja przywoływanych kategorii modelowania, które projektant systemu zamierza wykorzystać w ramach tworzonego właśnie diagramu bloków wewnętrznych, nieznacznie różni się od standardowej notacji bloku bądź części. Zewnętrzne krawędzie danej kategorii modelowania są bowiem szkicowane z wykorzystaniem linii przerywanej, jak zaprezentowano na rysunku 4.7.

80

Język inżynierii systemów SysML. Architektura i zastosowania

Rozdział 5.

Diagram parametryczny 5.1. Znaczenie parametrów w dokumentowaniu systemu Diagram parametryczny koncentruje się na ograniczeniach cech bloków, określonych na diagramie definiowania bloków. W istocie jest on sformalizowaną odmianą diagramu bloków wewnętrznych. Diagramy i modele parametryczne pozwalają na formalne wyspecyfikowanie ograniczeń (ang. constraints) cech systemu, które następnie mogą być ocenione i zweryfikowane przez odpowiednie narzędzia analityczne. Ograniczenia są wyrażone jako równania, których parametry są przypisane kategoriom modelowania struktury systemu. W projektach systemów opartych na inżynierii systemów parametry stosuje się w celu wspomagania studiów nad różnymi wersjami produktu lub procesu pod kątem analizy i wyboru wariantów (ang. trade-off), analizy wrażliwości i optymalizacji projektu na zasadzie symulacji. Diagram parametryczny może ujmować tak istotne charakterystyki, jak kwestie wydajnościowe, niezawodność i cechy fizyczne systemu. Praca inżyniera uwzględnia różne typy analizy wariantowej, które pozwalają na wybranie rozwiązania kompromisowego, optymalnego. Dzięki zastosowaniu diagramów parametrycznych można takie wieloaspektowe analizy przeprowadzić w praktyce. Punktem wyjścia dla szacunków są różne, alternatywne wersje projektu (prototypu).

82

Język inżynierii systemów SysML. Architektura i zastosowania

5.2. Elementy diagramu parametrycznego 5.2.1. Kategorie modelowania Diagram parametryczny opiera się na użyciu bloków ograniczeń, w których zdefiniowane są reguły, równania dotyczące aspektów technicznych, mechanicznych czy automatyki modelowanych systemów. Definicja bloku ograniczeń jest reprezentowana na diagramie definiowania bloków, a użycie bloku ograniczeń — na diagramie parametrycznym. Jako że zagadnienia te są ściśle powiązane, w niniejszej książce są one konsekwentnie opisywane łącznie. I tak podstawowe kategorie, stosowane w modelowaniu parametrów systemu, obejmują:  blok ograniczeń (ang. constraint block),  cechę ograniczającą (ang. constraint property),  konektor (ang. binding connector),  miarę efektywności (ang. measure of effectiveness).

Wymienione kategorie oraz logiczne zależności między nimi przedstawiono na rysunku 5.1.

Rysunek 5.1. Kategorie modelowania diagramów parametrycznych

I tak punktem wyjścia do tworzenia diagramów parametrycznych jest zdefiniowanie bloków ograniczeń. W tym celu stosuje się diagramy definiowania bloków. Bloki ograniczeń scharakteryzowano w punkcie 5.2.2. Szczególnym przypadkiem bloków ograniczeń są funkcje celowe, ujęte w punkcie 5.2.5.

Rozdział 5. ♦ Diagram parametryczny

83

Zastosowanie bloku ograniczającego w określonym kontekście przyjmuje postać cechy ograniczającej. Połączone konektorami cechy ograniczające tworzą diagram parametryczny. Cechom ograniczającym poświęcono punkty 5.2.3 i 5.2.4. Jeśli zakres projektu przewiduje przeprowadzenie analizy wariantowej, do diagramów parametrycznych wprowadza się funkcje celowe, operujące na tych cechach wartościowych poszczególnych bloków, które zostały sklasyfikowane jako miary efektywności. Miary te szerzej omówiono i egzemplifikowano w punkcie 5.2.6.

5.2.2. Bloki ograniczeń Bloki ograniczeń (ang. constraint blocks) są zapisanymi w postaci formalnej równaniami matematycznymi. Bloki ograniczeń wskazują na ograniczenia i reguły występujące w strukturze systemu oraz niezbędne do wykonania tych formuł parametry. Kategoria bloku ograniczeń ma fundamentalne znaczenie dla tworzenia diagramów parametrycznych. Ponieważ bloki ograniczeń zawierają jedynie opis formalny, niezależny od kontekstu, mogą one być ponownie użyte (ang. reused) w innych systemach i projektach. W praktyce blok ograniczeń jest definiowany raz, a później wielokrotnie użyty w różnych kontekstach. Język SysML nie ma wbudowanego własnego języka ograniczeń. Stąd ograniczenia, formalizowane do postaci bloku, mogą być wyrażane w dowolnym języku, posiadającym ściśle zdefiniowaną składnię. Najczęściej wykorzystuje się w tym celu zewnętrzne, zdefiniowane języki ograniczeń, takie jak OCL, Schematron, Alloy, MathML itd. Zapisane w bloku ograniczeń parametry są odpowiednikami atrybutów z diagramów klas UML. Ograniczenie może być zawarte w każdym elemencie, które jest przestrzenią nazw — taką jak pakiet lub blok — i może być bezpośrednio zależne od czasu. Bloki ograniczeń oznacza się najczęściej stereotypem «constraintBlock». Zawierają one trzy sekcje:  nazwy;  ograniczeń — w której zamieszcza się formułę ograniczenia bądź wyszczególnia

bloki ograniczeń, będące blokami podrzędnymi danego bloku;  parametrów — niezbędnych do wyrażenia formuły ograniczenia.

Przykładowe bloki ograniczeń ilustruje rysunek 5.2. Rysunek 5.2 przedstawia definicję bloku ograniczeń Optymalne zamówienie na potrzeby optymalizacji wolumenu składanych zamówień towarowych. Wykorzystuje się tu reguły, występujące w sterowaniu zapasami, będącym istotnym zagadnieniem badań operacyjnych. Na rysunku tym występuje złożony blok ograniczeń (Optymalne zamówienie), składający się z dwóch bloków podrzędnych, tj. Prognozy sprzedaży i Reguły pierwiastka kwadratowego. Blok ograniczeń Optymalne zamówienie, poza sekcją nazwy, zawiera dwie sekcje merytoryczne:

86

Język inżynierii systemów SysML. Architektura i zastosowania

5.2.3. Cechy ograniczające Tworzenie diagramu parametrycznego zazwyczaj obejmuje zrealizowanie czterech ściśle powiązanych etapów:  zdefiniowanie bloków ograniczeń na podstawie reguł diagramu definiowania

bloków;  utworzenie właściwego diagramu bądź diagramów parametrycznych;  przypisanie wartości cechom ograniczającym;  przeprowadzenie właściwej analizy, studiów alternatywnych wariantów.

Diagramy parametryczne zorganizowano wokół pojęcia cechy ograniczającej (ang. constraint property). Cecha ograniczająca jest w istocie zastosowaniem bloku ograniczającego w określonym kontekście, analogiczne jak części stanowią zastosowanie bloku. Stąd, podobnie jak w przypadku bloku ograniczającego, cechom ograniczającym można przypisywać formuły ograniczeń i parametry. Dla rozróżnienia parametrów bloku ograniczającego i parametrów cech ograniczających te ostatnie określa się mianem parametrów ograniczających (ang. constraint parameter). Cecha ograniczająca przybiera graficznie postać prostokąta o zaokrąglonych narożnikach, podczas gdy parametr ograniczający jest zamieszczany po wewnętrznej stronie krawędzi cechy. Na rysunku 5.4 ujęto diagram parametryczny bloku ograniczeń Optymalne zamówienie. Wiąże on wzajemnie dwie cechy ograniczające: ps (zastosowanie bloku Prognoza sprzedaży) oraz rpk (zastosowanie bloku Reguła pierwiastka kwadratowego) z wykorzystaniem konektora. Obie cechy ograniczające zawierają wejściowe i wyjściowe parametry ograniczające, zgodne z parametrami bloków ograniczających, zdefiniowanymi na rysunkach 5.2 oraz 5.3. Cecha ograniczająca ps przesyła wartość parametru ograniczającego Sº(t) do cechy ograniczającej rpk. Wynikiem zastosowania reguł, wywodzących się z obu powiązanych cech ograniczających, jest wyjściowy parametr ograniczający Q (optymalna partia zakupu).

5.2.4. Przypisywanie wartości cechom ograniczającym Diagramy parametryczne są dogodnym narzędziem studiów i analiz funkcjonowania procesów i produktów. Aby analiza taka mogła zostać przeprowadzona, parametry ograniczające muszą przyjmować dobrany zestaw wartości. Wartości te mogą zostać przypisane na dwa sposoby:  w sposób jawny na diagramie parametrycznym;  dynamicznie, w czasie rzeczywistym, przez zastosowane narzędzie analityczne.

W obu przypadkach uzasadnione jest wyspecyfikowanie, jakie części, bloki czy też cechy ograniczające są źródłem wartości poszczególnych parametrów ograniczających. I tak źródła wartości parametrów ograniczających cechy ograniczającej wygładzona prognoza przedstawia rysunek 5.5

Rozdział 5. ♦ Diagram parametryczny

91 «block» c2960-8TC-L

«block» Analiza w ariantow a values

⎧ ⎡ ⎪⎪ ⎢⎣ ⎨ocena = ⎪ ⎩⎪

(

/ wariant1 : real / wariant2 : real / wariant3 : real

)

⎫ wydajnosc ⎤ ⎥⎦ + cechyIOS ⎪⎪ 2 ⎬ 10 + moc ⎪ ⎭⎪

«block» c2960-48TC-S

portyFE ∗ 2 + portyGE *

fos2

fos3

«block» c2960G-24TC-L

fos1 «objectiveFunction» Funkcj a oceny sprzętu constraints

parameters ocena : real portyFE: int portyGE : int cechyIOS : Ranga wydajnosc : Mp/s moc : W

Rysunek 5.8. Specyfikacja funkcji celowej na potrzeby analizy wariantowej — diagram definiowania bloków

W konsekwencji wcześniejszej preselekcji wszystkie rozpatrywane modele przełączników pochodzą od konkretnego dostawcy rozwiązań sprzętowych — korporacji Cisco. Krok ten podyktowany był m.in. renomą sprzętu i aktualnym wyposażeniem serwerowni firmy w dominującą liczbę urządzeń tego producenta, co minimalizuje ryzyko ewentualnych konfliktów sprzętowych przy wprowadzaniu nowych urządzeń. Firma Cisco dostarcza sprzęt z systemami operacyjnymi o zróżnicowanych możliwościach, które to możliwości uwzględniono w formule.

5.2.6. Miary efektywności Parametrom bloków, które pełnią kluczową rolę z punktu widzenia zastosowania funkcji celowej, można przypisać stereotyp «moe». Tak więc miary efektywności (ang. measures of effectiveness) wskazują na te parametry bloków, które mogą być naturalnym źródłem wartości z punktu widzenia analizy wariantowej. Dobrymi kandydatami na miary wartości są te cechy bloków, które wyrażane są liczbowo — na przykład ogniskowa, czas reakcji, przekątna ekranu, przepustowość sieci. Miary efektywności specyfikuje się na

92

Język inżynierii systemów SysML. Architektura i zastosowania

Rysunek 5.9. Diagram parametryczny analizy wariantowej

diagramach definiowania bloków, a następnie wykorzystuje w diagramach parametrycznych, opisujących lokalne zastosowanie funkcji celowych w analizie wariantowej. Przykład zastosowania miar efektywności w definiowaniu bloków zaprezentowano na rysunku 5.10. Ujęty na rysunku 5.10 diagram szczegółowo definiuje parametry, zastosowane w formule funkcji celowej, omawianej w punkcie 5.2.5. Parametry te odpowiadają poszczególnym wartościom bloku Przełącznik sieciowy. Jak wspomniano, zdecydowana większość spośród nich ma charakter liczbowy. Regule tej generalnie nie poddają się cechy systemu operacyjnego przełącznika (parametr cechyFunkcjonalneIOS), stąd na jego potrzeby zdefiniowano niezależnie typ wartości Ranga, przyjmujący arbitralnie przydzielane wartości z zakresu . Im wyższa funkcjonalność systemu operacyjnego, tym wyższa Ranga. Należy zwrócić uwagę, że definiujący funkcję celową intencjonalnie nie uwzględnił istotnej potencjalnej miary efektywności — tj. ceny danego rozwiązania sprzętowego. Zamawiający stawia bowiem na jakość sprzętu, który będzie użytkowany w firmie przez wiele lat, traktując tym samym koszt jako charakterystykę o drugorzędnym znaczeniu. Omawiany diagram od razu definiuje wartości domyślne parametrów dla poszczególnych modeli przełączników. Zostały one zamieszczone w poszczególnych blokach, powiązanych z blokiem nadrzędnym z wykorzystaniem związku uogólnienia. Stąd

Rozdział 5. ♦ Diagram parametryczny

93

Rysunek 5.10. Szczegółowa specyfikacja wartości bloków stanowiących przedmiot analizy wariantowej

można bezpośrednio przejść do przeliczania poszczególnych wariantów z użyciem diagramu parametrycznego Analizy wariantowej, zaprezentowanego na rysunku 5.9. I tak wyniki wartościowania poszczególnych wariantów ilustruje diagram parametryczny, zamieszczony na rysunku 5.11. W wyniku przeprowadzenia analizy wariantów rozpatrywanych modeli przełączników ustalono, że poszczególne modele uzyskały następujące oceny:  model c2960-8TC-L, stanowiący wariant1 — ocena 0,53;  model c2960-48TC-S, stanowiący wariant2 — ocena 1,12;  model c2960-24TC-L, stanowiący wariant3 — ocena 2,31.

Tym samym ostatni z rozpatrywanych wariantów jest zdecydowanie najbliższy oczekiwaniom firmy i powinien zostać zrealizowany.

Rozdział 6.

Rozszerzony diagram czynności 6.1. Znaczenie czynności w modelowaniu systemów Podstawową metodą szczegółowego specyfikowania procesów systemowych i wyrażania algorytmiki systemu są diagramy czynności. Diagramy te są niezwykle elastyczne, będąc użytecznymi w rozwiązywaniu rozmaitych problemów z zakresu modelowania systemowego, a zarazem stanowiąc podstawę wielu rozwiązań dedykowanych modelowaniu biznesowemu. Diagramy czynności zostały docenione zarówno przez praktyków, jak i środowisko studenckie, konsekwentnie stanowiąc jeden z elementów uproszczonych, specjalizowanych wersji języka UML, tj. Light UML, minimUML i innych. Diagramy czynności, obok diagramów definiowania bloków i bloków wewnętrznych, należą do grona diagramów, które istotnie zmodyfikowano przy ich importowaniu do języka SysML. W języku tym nie zmieniły one formalnie swojej nazwy. Poważny zakres rozszerzeń i modyfikacji (por. podrozdział 6.3) uzasadnia jednak określanie ich mianem rozszerzonych diagramów czynności. Taką terminologię przyjęto w niniejszym opracowaniu. W pozostałych dwóch przypadkach twórcy języka SysML zdecydowali się na jawne wprowadzenie nowego nazewnictwa. I tak, diagramy definiowania bloków są zmodyfikowanymi diagramami klas, podczas gdy diagramy bloków wewnętrznych — zmodyfikowanymi diagramami struktur połączonych.

96

Język inżynierii systemów SysML. Architektura i zastosowania

6.2. Elementy diagramu czynności 6.2.1. Kategorie modelowania Rdzeń rozszerzonego diagramu czynności stanowią kategorie modelowania, wywodzące się z języka UML. Niniejsza praca zakłada podstawową znajomość tych kategorii, objaśnionych szczegółowo w licznych książkach i opracowaniach, dotyczących bezpośrednio standardu UML 2.x. Jedną z takich pozycji jest książka (Wrycza, Marcinkowski i Wyrzykowski, 2005a), której rozdział 4. ujmuje następujące aspekty diagramów czynności:  terminologię diagramów czynności w języku polskim i angielskim;  wyszczególnienie podstawowych kategorii modelowania;  wyszczególnienie zaawansowanych kategorii modelowania;  opartą na formalnych standardach i literaturze interpretację wyszczególnionych

kategorii;  liczne przykłady zastosowania tych diagramów;  złożone studium przypadku;  zadania i problemy do rozwiązania.

Kategorie modelowania diagramów czynności, z uwzględnieniem rozszerzeń, wprowadzonych w języku SysML, wyszczególnia rysunek 6.1.

6.2.2. Charakterystyka pierwotnych kategorii modelowania Syntetyczne omówienie pierwotnych kategorii modelowania rozszerzonego diagramu czynności zaprezentowano w tabeli 6.1. Dla każdej kategorii wyspecyfikowano jej:  nazwę,  stosowaną notację,  charakterystykę.

Z kolei nowym koncepcjom i kategoriom modelowania poświęcono podrozdział 6.3. Przykład kompletnego diagramu czynności, zawierającego wyłącznie pierwotne kategorie modelowania diagramów czynności, przedstawia rysunek 6.2. Jak zaprezentowano na rysunku. 6.2, rejestrujący się klient w pierwszej kolejności specyfikuje adres e-mail, hasło oraz potwierdza wprowadzone hasło w formularzu rejestracji użytkownika. Mail służy później w charakterze loginu do systemu. Jeśli oba wprowadzone hasła są różne, system zgłasza ten fakt poprzez realizację czynności Wyświetl „Niezgodność haseł. Proszę wprowadzić ponownie” i powraca do formularza,

Rozdział 6. ♦ Rozszerzony diagram czynności

101

Tabela 6.1. Pierwotne kategorie modelowania diagramów czynności — ciąg dalszy Nazwa kategorii modelowania

Notacja

Charakterystyka

Obszar rozszerzenia

Ściśle zdefiniowany fragment diagramu czynności z jednoznacznie wyspecyfikowanymi wejściami i wyjściami, wykonywany wielokrotnie, stosownie do liczby elementów na wejściu

Obszar przerwania

Zgrupowanie czynności, które ulegają bezzwłocznemu przerwaniu w wyniku działania przepływu przerwania, zainicjowanego przez wyspecyfikowany sygnał odbiorczy

Manipulator wyjątków

Specyficzny przepływ, wskazujący czynności, które należy wykonać, jeśli określony wyjątek wystąpi w trakcie wykonania czynności chronionej Źródło: opracowanie własne na podstawie (Wrycza, Marcinkowski i Wyrzykowski, 2005a)

czyszcząc przy tym stosowne pola. Podanie już istniejących i zarazem poprawnych danych prowadzi do modyfikacji profilu użytkownika. Taka procedura zachodzi tylko i wyłącznie wtedy, gdy wprowadzone hasło jest zgodne z hasłem przechowywanym w profilu, a zarazem rejestrujący wyraża wolę modyfikacji. W przeciwnym przypadku następuje powrót do Wyświetlania formularza rejestracji użytkownika. Klient jest zobowiązany zarejestrować się albo jako KlientIndywidualny, albo Firma. Niezależnie od rodzaju klienta specyfikowane są dane osobowe i adresowe użytkownika (ich przechowywanie zapewnia przekaźnik danych Klient) oraz — na osobnej zakładce — dane związane z posiadanymi kartami płatniczymi. Klient ma prawo zarejestrować dowolną liczbę KartPłatniczych. Wcześniej zasygnalizowana aktualizacja

Rozdział 6. ♦ Rozszerzony diagram czynności

103

transakcji. Jeżeli klient zaakceptuje taką sytuację (bądź podane informacje były kompletne), realizowana jest czynność Wyświetl „Profil użytkownika został zaktualizowany”. W przeciwnym przypadku system Wyróżnia błędnie wprowadzone pola i oczekuje na ich uzupełnienie. Na dowolnym etapie rejestracji można ten proces przerwać, co zobrazowano przez zastosowanie obszaru przerwania, aktywowanego sygnałem odbiorczym Anulowanie. Przerwanie rejestracji użytkownika pociąga za sobą powrót do katalogu.

6.3. Rozszerzenia diagramów czynności w języku SysML Diagramy czynności należały do najbardziej rozbudowanych diagramów języka UML pod względem liczby oferowanych kategorii modelowania. W wersji 2.0 wprowadzono bardzo wiele nowych koncepcji i elementów. Mimo tych znaczących zmian podczas przygotowywania specyfikacji języka SysML zaistniała potrzeba zaproponowania dodatkowych kategorii modelowania diagramów czynności. Wynika to ze specyfiki tego języka, przeznaczonego do szerszej palety zastosowań w porównaniu do inżynierii oprogramowania. I tak grupa robocza opracowująca standard SysML wprowadziła następujące nowe kategorie modelowania:  operator sterowania (ang. control operator), zarządzający wartościami

kontrolnymi (ang. control values);  rozszerzone buforowanie (ang. buferring) danych i sterowania;  parametr opcjonalny (ang. optional);  przepustowość (ang. rate);  prawdopodobieństwo (ang. probability);  warunek wstępny (ang. precondition) i końcowy (ang. postcondition);  blokową notację czynności.

Znaczna część z wymienionych kategorii została zaproponowana w celu wspierania specyficznej funkcjonalności systemów ciągłych i strumieniowych.

6.3.1. Systemy ciągłe i strumieniowe Standardowa interpretacja pojęcia czynności zakłada, że jedynym działaniem o charakterze zarządczym jest zainicjowanie tej czynności. Przetwarzanie danej czynności będzie bowiem trwało dopóty, dopóki czynność nie zostanie samoistnie zakończona, zapewniając przy tym uzyskanie zamierzonych rezultatów. Semantyka taka jest wystarczająca w systemach, które nie przewidują przetwarzania o charakterze strumieniowym lub ciągłym. Jako że współcześnie strumienie stają się integralnym elementem coraz liczniejszych systemów, chociażby ze względu na rozwój multimediów, do języka SysML włączono wiele wspierających je elementów i koncepcji. Elementy te są ukierunkowane na precyzyjne modelowanie przetwarzania strumieniowego, bardzo ogólnie

108

Język inżynierii systemów SysML. Architektura i zastosowania

Jak zaprezentowano na rysunku 6.6, router w sieci jest odpowiedzialny m.in. za Przygotowywanie aktualizacji routingu, dzięki którym inne routery mogą uzupełniać własne tablice routingu i poprawnie realizować funkcję doboru tras dla transmitowanych pakietów sieciowych. W zależności od zastosowanego protokołu aktualizacje takie mogą być rozsyłane periodycznie albo w wyniku wykrycia zmiany topologii sieci. Omawiany rysunek opisuje czynności, realizowane w tej drugiej sytuacji. I tak router wymienia ze swoimi sąsiadami specyficzne komunikaty hello. Pozwalają one urządzeniom nawzajem stwierdzać, że sąsiedzi są aktywni i poprawnie podłączeni fizycznie. Strumień takich komunikatów z różnych urządzeń trafia do czynności Weryfikuj nadawcę. Jako że domyślnie komunikaty takie są transmitowane cztery razy częściej niż wynosi zdefiniowany czas, po jakim router przyjmuje, że sąsiad przestał być dostępny, nieobsłużone w czasie rzeczywistym komunikaty hello nie są buforowane. Osiągnięto to dzięki zastosowaniu niebuforującego przekaźnika danych. Router wykrywa pojawienie się nowego urządzenia w sieci dzięki otrzymaniu komunikatu hello od routera, który nie był zarejestrowany w dedykowanej tablicy, tj. tablicy sąsiadów. W takiej sytuacji niezwłocznie uwzględnia nowe urządzenie we własnych tablicach. Następnie wywoływana jest czynność Wygeneruj aktualizację routingu, skutkująca Rozesłaniem aktualizacji. Z kolei po upłynięciu określonego czasu od przesłania ostatniego komunikatu hello przez danego sąsiada router zakłada permanentną utratę komunikacji i w konsekwencji wykreśla tego sąsiada z własnych tablic. Proces ten nadzoruje czynność Analizuj tablicę sąsiadów. Czynność ta aktywowana jest przy okazji otrzymania komunikatu hello od dowolnego nadawcy. Czas na podjęcie reakcji przechowywany jest jako wartość RouterDeadInterval i może być zmieniany. Domyślnie wynosi on 40 sekund, co zaznaczono na diagramie notatką. Nadpisujące przekaźniki danych są bardziej złożoną odmianą niebuforujących przekaźników danych. W ich przypadku przyjmuje się istnienie wewnętrznego bufora o określonej wielkości. W momencie osiągnięcia maksymalnego rozmiaru bufora napływające dane lub sterowanie zastępuje dane lub sterowanie aktualnie obecne w buforze. Język SysML pozwala na określenie dwóch podstawowych cech nadpisującego przekaźnika danych. Są to:  rozmiar bufora, reprezentowanego w postaci ograniczenia, zawierającego słowo kluczowe upperBound;  mechanizmu obsługi kolejki, wyspecyfikowanego ograniczeniem ze słowem kluczowym ordering.

Domyślną wartością rozmiaru bufora jest 1, co oznacza, że na wejściu do danej czynności zawsze znajdują się najbardziej aktualne dane. Należy zauważyć, że ustawienie rozmiaru bufora na 0 da efekt identyczny z tym, jaki uzyskuje się w przypadku niebuforującego przekaźnika danych — dane nie będą bowiem buforowane w ogóle. Z kolei domyślnym mechanizmem obsługi kolejki jest FIFO (First In First Out), co oznacza, że napływające dane będą obsługiwane przez czynność zgodnie z kolejnością ich napływania. Alternatywnie można zastosować mechanizm obsługi kolejki LIFO lub dowolny algorytm porządkujący, zdefiniowany przez projektanta systemu.

Rozdział 6. ♦ Rozszerzony diagram czynności

113

 w sytuacji gdy siła wiatru jest mniejsza, lecz wciąż przekracza 39 km/h,

inicjowana jest czynność Ogłoś ostrzeżenie; w przypadku rozpatrywanej stacji pomiarowej taka reakcja konieczna była w odniesieniu do 6,9% Pomiarów znormalizowanych;  w każdym innym przypadku nie jest podejmowana żadna dalsza aktywność;

prawdopodobieństwo realizacji takiego wariantu szacowane jest na 90,8%.

6.3.7. Warunki wstępne i końcowe Język SysML umożliwia jawne wskazanie tzw. lokalnych warunków wstępnych i końcowych wykonania czynności. Lokalność w tym kontekście odnosi się do pojedynczej czynności złożonej lub diagramu czynności, definiującego wnętrze takiej czynności. I tak:  warunki wstępne oznaczają, że określona lista kryteriów musi zostać

spełniona, aby czynność mogła zostać zainicjowania;  warunki końcowe wskazują na kryteria, których spełnienia oczekuje się

wskutek wywołania czynności. Warunki można formułować nieformalnie — tekstowo — oraz w dowolnym języku ograniczeń, na przykład w języku OCL. Jeśli warunki przypisuje się do pojedynczej czynności, zastosowanie znajduje notacja notatkowa (rysunek 6.11). Z kolei przypisanie warunków do kompletnego diagramu można osiągnąć poprzez ich wyspecyfikowanie w prawym górnym fragmencie ramy diagramu (rysunek 6.12) lub poprzez indywidualne przypisywanie notatek do poszczególnych czynności. Zaprezentowany na rysunku 6.11 diagram opisuje przypadek użycia Zarządzaj przeglądami. Koncentruje się on na wybraniu, a następnie zmianie parametrów konkretnego przeglądu samochodowego. Przegląd ten musi być wcześniej umówiony. Czynnością inicjującą diagram jest czynność Weryfikuj uprawnienia inicjującego funkcjonalność, która odpowiada za weryfikację, czy identyfikator użytkownika uruchamiającego przypadek użycia należy do klienta stacji obsługi, czy też pracownika. Jest to o tyle istotne, że klient posiada ograniczoną liczbę umówionych przeglądów (w szczególności 0 lub 1, jeśli posiada tylko jeden pojazd o zbliżonym terminie przeglądu). Reguła ta nie jest naturalnie spełniona w przypadku pracownika, który może weryfikować listę umówionych przeglądów wszystkich klientów. Stąd niezbędne było zaimplementowanie funkcjonalności wyszukiwania w ramach omawianego przypadku użycia. I tak po zweryfikowaniu tożsamości pracownika inicjowana jest czynność Wyświetl formatkę wyszukiwania przeglądów. Po wypełnieniu poszczególnych pól formatki następuje Pobranie wartości z pól oraz Przeprowadzenie wyszukiwania. Jeśli udało się jednoznacznie ustalić klienta na podstawie wyspecyfikowanych parametrów, obiekt zawierające jego dane przekazywany jest do czynności Pobierz listę umówionych przeglądów z bazy danych, która wykorzystuje je w charakterze parametru zapytania do bazy danych. Jeśli nie znaleziono klienta bądź dane nie zawężają listy do pojedynczej pozycji, wyświetlany jest stosowny komunikat. Po wykonaniu zapytania (czynność Pobierz listę umówionych przeglądów z bazy danych) system weryfikuje, czy dany klient posiadał jakikolwiek wcześniej umówiony przegląd.

116

Język inżynierii systemów SysML. Architektura i zastosowania

Rysunek 6.12 ilustruje sposób przypisywania warunków wstępnych i końcowych do diagramu jako całości. Ich kompletną listę wyszczególniono w narożniku diagramu. Są to naturalnie warunki zbieżne z wyspecyfikowanymi na rysunku 6.11. Czynność złożona Modyfikuj parametry wybranego przeglądu inicjowana jest Wyświetleniem szczegółów przeglądu, ujmującym datę, miejsce, planowany czas i zakres oraz dane pojazdu. W przypadku wyboru wariantu usuwania przeglądu system upewnia się, czy opcję tę wybrano intencjonalnie (czynność Wyświetl „Na pewno usunąć przegląd?”). W przypadku odpowiedzi pozytywnej następuje Usunięcie planowanego przeglądu z bazy danych. Zaprzeczenie powoduje z kolei opuszczenie danego diagramu i realizowanie kolejnych czynności diagramu nadrzędnego. Jeśli wybrana zostanie opcja modyfikacji przeglądu, system Wyświetla kalendarz, z którego wybrać można dowolny przyszły dzień. System realizuje podczynność Weryfikuj wolne terminy w kolejnym tygodniu, a następnie Wyświetla grafik przeglądów. Horyzont harmonogramowania przeglądu nie ogranicza się do pojedynczego tygodnia (licząc od dnia bieżącego), gdyż można swobodnie przesuwać wprzód daty w kalendarzu. Po wybraniu terminu system prosi o potwierdzenie, a po jego uzyskaniu — inicjuje podczynność Aktualizuj datę przeglądu w bazie danych. Brak potwierdzenia skutkuje zignorowaniem wprowadzonych zmian i powrotem do kolejnych czynności diagramu nadrzędnego. Naturalnie proces Modyfikowania parametrów wybranego przeglądu może zostać przerwany w dowolnym momencie, jako że do całego wnętrza czynności złożonej, specyfikowanej na omawianym diagramie, odnosi się obszar przerwania diagramu macierzystego.

6.3.8. Blokowa notacja czynności W języku SysML dopuszcza się graficzne odzwierciedlenie poszczególnych czynności jako stereotypowanych bloków. Umożliwia to stosowanie czynności w sposób bezpośredni na diagramach struktury, chociażby w celu specyfikowania alokacji. Kolejną wartością dodaną jest możliwość ilustrowania hierarchii czynności z wykorzystaniem asocjacji, podobnie jak na diagramach definiowania bloków. W tym celu wykorzystuje się jedną z cech asocjacji, umożliwiającą modelowanie struktur całość-część — jaką jest agregacja. Zapis taki jest korzystny w kontrolowaniu wielopoziomowej dekompozycji czynności. Zakończenie wykonania czynności-całości ma miejsce po zakończeniu wykonania wszystkich jej czynności-części. Liczebność podczynności jest przyjmowana domyślnie jako 0..* — oznacza to, że w szczególnym przypadku żadna z nich może nie być wykonana. Tak zdefiniowane i powiązane czynności przedstawia rysunek 6.13. Jak wskazano na rysunku 6.13, czynność złożona Wprowadź dane osobowe ulega dekompozycji na poszczególne podczynności. Są to:  Wskaż rodzaj klienta,  Wprowadź nazwisko,  Wprowadź adres,

118

Język inżynierii systemów SysML. Architektura i zastosowania

Rozdział 7.

Diagramy UML4SysML 7.1. Rodzaje diagramów UML4SysML Z punktu widzenia pokrewieństwa z językiem UML 2.x diagramy języka inżynierii systemów SysML można podzielić na 3 kategorie:  diagramy specyficzne dla języka SysML;  zmodyfikowane diagramy UML 2.x;  diagramy przeniesione bezpośrednio z języka UML 2.x.

Dwie pierwsze kategorie diagramów zostały szczegółowo omówione w rozdziałach 2 – 6. Spośród 13 diagramów UML 2.x język SysML zaadaptował bezpośrednio, bez wprowadzania zmian innych niż redakcyjne, cztery rodzaje diagramów. Popularnym określeniem tej grupy diagramów języka SysML jest UML4SysML (Unified Modeling Language for Systems Modeling Language). Zostały one scharakteryzowane od strony teoretycznej i zilustrowane licznymi przykładami w książce (Wrycza, Marcinkowski i Wyrzykowski, 2005a). I tak:  diagramy przypadków użycia zaprezentowano w rozdziale 2. przytoczonej pracy;  diagramy maszyn stanowych — w rozdziale 5;  diagramy sekwencji — w rozdziale 7;  diagramy pakietów — w rozdziale 13.

Syntetyczna, skrótowa prezentacja wymienionych diagramów została przedstawiona w podrozdziałach od 7.2 do 7.5 niniejszej książki.

120

Język inżynierii systemów SysML. Architektura i zastosowania

7.2. Diagram przypadków użycia Diagramy przypadków użycia (ang. use case diagrams) opisują funkcjonalność projektowanego i implementowanego systemu oraz sposób komunikowania się interesariuszy (ang. stakeholders) systemu. Umożliwiają one zatem precyzowanie funkcjonalnych wymagań systemowych i są ściśle powiązane z diagramami wymagań systemowych SysML. Autorzy (Wrycza, Marcinkowski i Wyrzykowski, 2005a) definiują diagram przypadków użycia jako graficzne przedstawienie przypadków użycia, aktorów oraz związków między nimi, występujących w danej dziedzinie przedmiotowej. W diagramach tych występują trzy podstawowe kategorie modelowania, wsparte szeregiem kategorii zaawansowanych. Ujęto je zbiorczo w tabeli 7.1. Naturalnie przygotowywanie kompletnego modelu przypadków użycia systemu nie ogranicza się wyłącznie do tworzenia diagramów przypadków użycia. W zależności od przyjętej metodologii tworzenia systemu, generuje się szereg dodatkowych dokumentów i diagramów o charakterze precyzującym oraz pomocniczym. I tak, w języku SysML w aktualna pozostaje w szczególności problematyka dokumentowania scenariuszy przypadków użycia (por. Wrycza, Marcinkowski i Wyrzykowski, 2005a). Przykład diagramu przypadków użycia zamieszczono na rysunku 7.1. Diagram ten ujmuje funkcjonalność informatycznego repozytorium projektów studenckich, które podlegają ocenie wykładowcy. I tak aktorami niniejszego systemu są:  Autor,  Student,  Wykładowca,  Administrator.

Funkcję Administratora sprawuje w istocie wybrany Wykładowca, któremu udostępniono dodatkowo funkcjonalność, reprezentowaną przez przypadek użycia Zarządzaj użytkownikami. Wykładowca ma możliwość zakładania, usuwania, edytowania i przeglądania klas studenckich (przypadek użycia Zarządzaj klasami) oraz Zarządzania kategoriami projektów, do których to kategorii muszą przynależeć tworzone przez autorów projekty. W stosunku do poszczególnych przypadków użycia werbalnie wyspecyfikowano pewne ograniczenia, konsekwentnie nanoszone na diagram z wykorzystaniem notatek. Zwiększa to precyzję gotowego diagramu. W momencie zdefiniowania przez Wykładowcę stosownej kategorii i utworzenia klas przez Administratora Autorzy (albo zespoły autorów) uzyskują dostęp do przypadku użycia Zgłoś projekt. Do każdego zgłoszenia Wykładowca może się odnieść, wykorzystując ekran Zarządzaj aktualizacjami. W szczególności zgłoszenie może zostać odrzucone z przyczyn merytorycznych lub zostać odfiltrowane automatycznie (np. w sytuacji gdy zostało ono dokonane po terminie). Pełna historia przetworzonych zgłoszeń jest

124

Język inżynierii systemów SysML. Architektura i zastosowania

możliwość modyfikacji układu graficznego protokołu w dowolnym momencie przez podmianę pliku, zawierającego strukturę dokumentu. Dostęp do opcji Generuj protokoły uzyskuje się za pośrednictwem zakładki Przeglądania projektów gotowych. Wykładowca ma naturalnie możliwość przeglądania wszystkich zamkniętych projektów. Dostęp do projektów uzyskują także Studenci (niekoniecznie związani z danym projektem lub w ogóle przedmiotem). Dotyczy to jednak tylko projektów, które oznaczono jako publiczne z wykorzystaniem przypadku użycia Udostępnij projekty. Z założenia status taki mogą uzyskać tylko projekty najlepsze, które mogą stać się cenną referencją dla kolejnych roczników studentów.

7.3. Diagram maszyny stanowej Szczególnie użyteczne w zastosowaniach technicznych, a więc także w inżynierii systemów, są diagramy maszyny stanowej (ang. state machine diagrams). Przez maszynę stanową rozumieć należy zachowanie, określające sekwencje stanów, przez które przechodzi kategoria modelowania systemu w odpowiedzi na zdarzenia zachodzące w czasie swojego cyklu życia, wraz z jej reakcjami na te zdarzenia. Maszyny stanowe są w języku SysML dokumentowane właśnie z wykorzystaniem diagramu maszyny stanowej. Diagram ten umożliwia śledzenie zachowania się użytkowanego obiektu podczas wykonywania jednego lub kilku przypadków użycia. Diagram maszyny stanowej odzwierciedla dyskretne, skokowe zachowanie skończonych systemów stan-przejście. Zatem podstawę diagramu maszyny stanowej stanowią stany i przejścia między nimi, zorganizowane w sekwencję przez projektanta systemu. Kategorie modelowania diagramu maszyny stanowej zamieszczono w tabeli 7.2. Przykład diagramu maszyny stanowej, ilustrujący poszczególne stany faktury, zamieszczono na rysunku 7.2. Faktura Zarejestrowana w systemie może być później edytowana do czasu jej zatwierdzenia lub anulowania. Sam fakt Zarejestrowania faktury w systemie wiąże się z aktualizacją statusu zamówienia. Każda Zatwierdzona faktura musi być opłacona w ciągu 30 dni — w innym przypadku przechodzi do stanu Przeterminowania, co wiąże się z wysłaniem ponaglenia i konsekwentnym naliczaniem odsetek. System nie przewiduje windykacji — jest to zadanie zlecane przez firmę na zewnątrz i tym samym nie wyodrębniono na jego potrzeby odrębnego stanu. Zatwierdzone faktury nie mogą być edytowane. W momencie uregulowania zobowiązania wynikającego z faktury trafia ona do stanu Opłacona. Każda zmiana stanu wiąże się z aktualizacją statusu przedmiotowej faktury. Opłacone faktury są automatycznie usuwane z systemu po 5 latach. Ma to podłoże efektywnościowe — tego typu faktury nie są ujmowane w raportach i wyświetlane w podglądach, a jednocześnie mogą zostać w razie potrzeby odzyskane z archiwum kopii zapasowych.

Rozdział 7. ♦ Diagramy UML4SysML

129

Tabela 7.3. Kategorie modelowania diagramu sekwencji — ciąg dalszy

Rodzaje komunikatów

Nazwa kategorii modelowania

Notacja

Charakterystyka

Synchroniczny

Wywołanie operacji przez nadawcę, powiązane z przekazaniem sterowania do odbiorcy; przepływ sterowania nadawcy jest zawieszany do momentu wykonania operacji przez odbiorcę

Asynchroniczny

Zlecenie wykonania operacji przez odbiorcę bez oczekiwania na odpowiedź; nadawca pozostaje w stanie aktywności, co umożliwia mu dalsze przetwarzanie bądź wysyłanie komunikatów

Zwrotny

Powrót sterowania do nadawcy po wykonaniu operacji, zleconej uprzednio poprzez przesłanie komunikatu synchronicznego

Utracony

Komunikat cechujący się jednoznacznym wskazaniem nadawcy i niesprecyzowanym odbiorcą (w szczególności odbiorcą spoza diagramu)

Znaleziony

Komunikat cechujący się niesprecyzowanym nadawcą i jednoznacznie wskazanym odbiorcą

Opcjonalny

Komunikat, który powinien zostać niezwłocznie obsłużony przez odbiorcę; jeżeli komunikat nie może zostać przyjęty bezpośrednio po wysłaniu, nadawca nie podejmuje dalszych prób jego przesyłania

Oczekujący

Komunikat, który powinien być obsłużony przez odbiorcę w określonym odcinku czasu; do specyfikacji wspomnianego czasu można wykorzystać ograniczenie

Fragment wyodrębniony

Logicznie spójny podobszar diagramu sekwencji, podzielony na operandy i charakteryzujący się specyficznymi właściwościami, określonymi przez operator interakcji; 12 operatorów interakcji można podzielić na 3 grupy (Weilkiens, 2007):  rozgałęzienia i pętle (alt, opt, break i loop)  współbieżność i porządek (strict, seq, par)  filtry i ograniczenia (critical, neg, assert, consider, ignore)

130

Język inżynierii systemów SysML. Architektura i zastosowania

Tabela 7.3. Kategorie modelowania diagramu sekwencji — ciąg dalszy Nazwa kategorii modelowania Alternatywa

Notacja alt [liczbaZgłoszeń < 2] [else]

Opcja

opt [port == GigabitEthernet]

Przerwanie

break

Rodzaje fragmentów wyodrębnionych

[status == "wstrzymane"]

Charakterystyka Wybór jednego i tylko jednego spośród wszystkich operandów danego fragmentu wyodrębnionego na podstawie kryterium spełnienia warunków, przypisanych do poszczególnych operandów fragmentu wyodrębnionego alt Wykonanie lub niewykonanie operandu fragmentu wyodrębnionego opt, stosownie do spełnienia przypisanego warunku Skrócona forma alternatywny, skutkująca pominięciem dalszej części diagramu w przypadku wywołania operandu fragmentu wyodrębnionego break

Iteracja

loop

Powtórzenie operandu określoną liczbę razy; liczbę powtórzeń zdefiniować można jako parametr nagłówka fragmentu wyodrębnionego loop

Funkcjonalność nieprawidłowa

neg

Wskazanie na działanie nieprawidłowe, wyjątek do obsłużenia w systemie

Współbieżność

par

Równoległe wykonywanie wszystkich operandów fragmentu wyodrębnionego par

Obszar krytyczny

critical

Zamknięta całość, której zawartość uzyskuje najwyższy priorytet w realizacji interakcji

Formuła

assert

Podkreślenie sformalizowanego twierdzenia, algorytmu

132

Język inżynierii systemów SysML. Architektura i zastosowania

Źródło: (Friedenthal, Moore i Steiner, 2008)

Rysunek 7.3. Konceptualny diagram sekwencji dla PU „Obsługa sygnału z czujnika alarmowego”

komunikat powiadamiający jest komunikatem asynchronicznym, nie musi być obsłużony przez Pracownika ochrony, aby alarm został zainicjowany. Sama procedura alarmowania została zawarta w osobnym przypadku użycia, do którego prowadzi brama formalna Alarmowanie. Powiadomienie można obsłużyć automatycznie bądź manualnie. W tym pierwszym przypadku Pracownik ochrony przeprowadza Aktywację automatycznego śledzenia. W przypadku utraty namiaru na intruza przez system bezpieczeństwa firmy system ten przesyła komunikat Powiadom o utracie namiaru. W praktyce taka sytuacja wyklucza możliwość wyłączenia alarmu przez Pracownika ochrony. W przypadku manualnej obsługi powiadomienia pracownik ma możliwość sterowania kamerą (komunikaty

Rozdział 7. ♦ Diagramy UML4SysML

133

Powiększ obraz oraz Obróć kamerę). Czynności te mogą być wykonywane zarówno równolegle, jak i w sposób powtarzalny. Po zidentyfikowaniu zagrożenia i stosownej reakcji, która odbywa się poza systemem, pracownik Anuluje alarm. Zlecenie anulowania jest przekazywane dalej, do przypadku użycia bezpośrednio obsługującego Alarmowanie.

7.5. Diagramy pakietów W trakcie tworzenia systemów powstaje obszerna dokumentacja w formie drukowanej lub elektronicznej. Tworzenie dokumentacji w formie elektronicznej stało się możliwe dzięki popularyzacji narzędzi CASE. Zagadnienie złożoności modelu systemu występuje we wszystkich metodykach tworzenia systemów, w tym metodykach strukturalnych, obiektowych, społecznych i adaptacyjnych (ang. agile). Istnieje zatem potrzeba porządkowania i logicznego grupowania dokumentacji systemowej. Rolę tę odgrywają pakiety, będące podstawowym mechanizmem zarządzania złożonością modelu. Pakiety integrowane są na diagramach pakietów (ang. package diagrams). Składnikiem pakietu mogą być dowolne kategorie modelowania systemu. I tak, przykładowo, rozbudowane modele wymagań reprezentuje się w postaci wzajemnie powiązanych pakietów, zawierających wymagania (por. rozdział 2.). W miarę potrzeb analogicznie można postąpić z przypadkami użycia czy też elementami strukturalnymi systemu. Syntetycznie charakterystykę kategorii modelowania diagramu pakietów prezentuje tabela 7.4. Diagram pakietów, ujmujący kompletny model wymagań systemowych internetowej platformy transakcyjnej banku, zaprezentowano na rysunku 7.4. Wymagania internetowej platformy transakcyjnej banku na aktualnym etapie jej tworzenia podzielono na dwie kategorie:  Wymagania zaakceptowane,  Wymagania negocjowane.

W obu przypadkach posiłkowano się standardowym zestawem wymagań dotyczących systemów webowych oraz bezpieczeństwa, ujętych w pakiecie Repozytorium wymagań projektowych. Z kolei wśród Wymagań zaakceptowanych rozróżniono wymagania funkcjonalne od pozafunkcjonalnych, ujmując poszczególne kategorie wymagań odpowiednio w pakietach zagnieżdżonych:  Wymagania funkcjonalne internetowej platformy transakcyjnej banku;  Wymagania pozafunkcjonalne internetowej platformy transakcyjnej banku.

Z kolei zawartość pakietu Wymagania funkcjonalne internetowej platformy transakcyjnej banku, zaprezentowanego w postaci ramy diagramu, ujęto na rysunku 7.5. Pakiet ten jest zarazem jedną z kategorii modelowania, pokazanych na rysunku 7.4.

138

Język inżynierii systemów SysML. Architektura i zastosowania

Dodatek A

Słownik polsko-angielski W przypadku nowych technologii, standardów oraz specyfikacji zachowanie spójności terminologicznej pomiędzy poszczególnymi opracowaniami w różnych językach staje się problematyczne. Potencjalny czytelnik musi uwzględniać także dynamiczny rozwój wspomnianych specyfikacji, niejednokrotnie skutkujący wyrywkowymi zmianami w zakresie terminologii. Język SysML jest przedmiotem zainteresowania rozmaitych środowisk, z których wywodzą się autorzy, niejednokrotnie oferujący charakterystyczne dla reprezentowanych przez nich specjalności tłumaczenia poszczególnych pojęć. Poniżej zamieszczono uznane przez autorów za najtrafniejsze tłumaczenia polskich terminów, związanych z językiem SysML, na ich angielskie odpowiedniki. Agregacja całkowita

Part association

Agregacja częściowa

Shared association

Akcja

Action

Aktor

Actor

Alokacja

Allocation

Analiza wariantowa

Trade-off analysis

Asocjacja

Association

Biała skrzynka

White box

Biblioteka

Model library

Blok

Block

Blok abstrakcyjny

Abstract block

Blok asocjacyjny

Association block

Blok ograniczeń

Constraint block

Brama

Gate

Brama formalna

Formal gate

Brama właściwa

Actual gate

140

Język inżynierii systemów SysML. Architektura i zastosowania

Brama wyrażeniowa

Expression gate

Bufor centralny

Central buffer node

Cecha

Property

Cecha ograniczająca

Constraint property

Czarna skrzynka

Black box

Czas

Time

Część

Part

Czynność wewnętrzna

Internal activity

Czynność

Activity

Decyzja

Decision node

Diagram bloków wewnętrznych

Internal block diagram

Diagram definiowania bloków

Block definition diagram

Diagram maszyny stanowej

State machine diagram

Diagram pakietów

Package diagram

Diagram parametryczny

Parametric diagram

Diagram przypadków użycia

Use case diagram

Diagram sekwencji

Sequence diagram

Diagram wymagań systemowych

Requirements diagram

Dyscyplina

Discipline

Dziedziczenie

Inheritance

Faza

Phase

Fragment wyodrębniony

Combined fragment

Funkcja celowa

Objective function

Głębokie wznowienie

Deep history pseudo state

Interakcja

Interaction

Interesariusz

Stakeholder

Interfejs

Interface

Interfejs pozyskujący

Required interface

Interfejs udostępniający

Provided interface

Jednostka miary

Unit

Język modelowania systemów

Systems Modeling Language

Język opisu ograniczeń

Object Constraint Language

Dodatek A ♦ Słownik polsko-angielski

141

Komunikat

Message

Komunikat asynchroniczny

Asynchronous message

Komunikat oczekujący

Timeout message

Komunikat opcjonalny

Balking message

Komunikat synchroniczny

Synchronous message

Komunikat utracony

Lost message

Komunikat znaleziony

Found message

Komunikat zwrotny

Return message

Konektor

Binding connector

Konektor składany

Assembly connector

Koniec

Activity final

Liczebność

Multiplicity

Linia życia

Lifeline

Manipulator wyjątków

Exception handler

Maszyna stanowa

State machine

Miara

Dimension

Miara efektywności

Measure of effectiveness

Nadpisujący przekaźnik danych

Overwrite

Nawigacja

Navigability

Niebuforujący przekaźnik danych

No buffer

Niezawodność

Reliability

Obejście

Bypass

Obiekt

Object

Obszar przerwania

Interruptible activity region

Obszar rozszerzenia

Expansion region

Obszar współbieżny

Orthogonal region

Odniesienie

Reference

Ograniczenie

Constraint

Operacja

Operation

Operand interakcji

Interaction operand

Operator interakcji

Interaction operator

Operator sterowania

Control operator

142

Język inżynierii systemów SysML. Architektura i zastosowania

Ośrodek sterowania

Execution specification

Pakiet

Package

Parametr czynności

Activity parameter node

Parametr ograniczający

Constraint parameter

Parametr opcjonalny

Optional

Partycja diagramu czynności

Activity partition

Perspektywa

View

Perspektywa postrzegania

Viewpoint

Płytkie wznowienie

Shallow history pseudo state

Początek

Initial node

Podczynność

Subactivity

Podmaszyna stanowa

Submachine state

Podstan

Substate

Podsystem

Subsystem

Port pojedynczy

Atomic port

Port sprzężony

Conjugated port

Port standardowy

Standard port

Port transmisyjny

Flow port

Port zagregowany

Non-atomic port

Prawdopodobieństwo

Probability

Przejście

Transition

Przejście wewnętrzne

Internal transition

Przejście zwrotne

Self-transition

Przekaźnik danych

Pin

Przekaźnik rozszerzenia

Expansion node

Przepływ danych

Data flow

Przepływ przerwania

Interrupting edge

Przepływ sterowania

Control flow

Przepływ strumieniowy

Stream

Przepływ zasobu

Item flow

Przepustowość

Rate

Przestrzeń nazw

Namespace

Dodatek A ♦ Słownik polsko-angielski

143

Przypadek rozszerzany

Extended use case

Przypadek użycia

Use case

Przypadek zawierający

Including use case

Przystosowalność

Supportability

Przywoływane wystąpienie interakcji

Interaction use

Pseudostan

Pseudo state

Pseudostan decyzji

Choice pseudo state

Pseudostan początkowy

Initial pseudo state

Punkt wejścia

Entry point

Punkt węzłowy

Junction pseudo state

Punkt wyjścia

Exit point

Punkt zniszczenia

Terminate node

Rama

Frame

Realizacja

Realization

Rola

Role property

Rozszerzone wymaganie systemowe

Extended requirement

Rozszerzony diagram czynności

Activity diagram

Rozwidlenie

Fork node

Scalenie

Join node

Scenariusz

Use case description

Sekcja

Compartment

Sekcja nazwy

Name compartment

Sekcja struktury

Structure compartment

Składnica danych

Data store node

Specyfikacja przepływu

Flow specification

Specyfikacja scalenia

Join specification

Stan

State

Stan końcowy

Final state

Stan początkowy

Initial state

Stan prosty

Simple state

Stan złożony

Composite state

Stereotyp

Stereotype

144

Język inżynierii systemów SysML. Architektura i zastosowania

Subpartycja diagramu czynności

Activity subpartition

Sygnał

Send signal action

System zewnętrzny

External system

Testowy przypadek użycia

Test case

Typ wartości

Value type

Ujednolicony język modelowania

Unified Modeling Language

Uogólnienie

Generalization

Urządzenie

Device

Użyteczność

Usability

Waga

Weight

Wartość

Value

Wartość kontrolna

Control value

Wartość pochodna

Derived value

Wartość początkowa

Initial value

Warunek

Guard condition

Warunek końcowy

Postcondition

Warunek wstępny

Precondition

Węzeł bloku asocjacyjnego

Participant property

Wydajność

Performance

Wyliczeniowy typ wartości

Enumeration

Wymaganie funkcjonalne

Functional requirement

Wymaganie pozafunkcjonalne

Non-functional requirement

Wymaganie systemowe

Requirement

Zagnieżdżenie

Containment

Zakończenie przepływu

Flow final

Zależność

Dependency

Zależność powielania

Copy dependency

Zależność precyzowania

Refine dependency

Zależność realizacji

Satisfy dependency

Zależność rozszerzania

Extend dependency

Zależność śledzenia

Trace dependency

Zależność weryfikowania

Verify dependency

Dodatek A ♦ Słownik polsko-angielski

145

Zależność wyprowadzania

Derive dependency

Zależność zawierania

Include dependency

Zdarzenie

Accept event action

Zestaw przekaźników danych

Parameter set

Złączenie

Merge node

Znacznik sterowania

Token

Zrąb

Framework

Związek

Relationship

146

Język inżynierii systemów SysML. Architektura i zastosowania

Dodatek B

Słownik angielsko-polski Jako że liczba polskojęzycznych publikacji drukowanych i elektronicznych, traktujących o języku SysML, pozostawia wiele do życzenia, czytelnik często pogłębia swoją wiedzę, korzystając ze źródeł anglojęzycznych. Zalecanym sposobem tego typu studiów jest zwłaszcza analiza oficjalnej dokumentacji języka SysML, dostępnej na stronach organizacji Object Management Group. W takiej sytuacji niezwykle przydatny staje się słownik w układzie angielsko-polskim, analogiczny do zamieszczonego w dodatku A. Abstract block

Blok abstrakcyjny

Accept event action

Zdarzenie

Action

Akcja

Activity

Czynność

Activity diagram

Rozszerzony diagram czynności

Activity final

Koniec

Activity parameter node

Parametr czynności

Activity partition

Partycja diagramu czynności

Activity subpartition

Subpartycja diagramu czynności

Actor

Aktor

Actual gate

Brama właściwa

Allocation

Alokacja

Assembly connector

Konektor składany

Association

Asocjacja

Association block

Blok asocjacyjny

Asynchronous message

Komunikat asynchroniczny

Atomic port

Port pojedynczy

Balking message

Komunikat opcjonalny

148

Język inżynierii systemów SysML. Architektura i zastosowania

Binding connector

Konektor

Black box

Czarna skrzynka

Block

Blok

Block definition diagram

Diagram definiowania bloków

Bypass

Obejście

Central buffer node

Bufor centralny

Choice pseudo state

Pseudostan decyzji

Combined fragment

Fragment wyodrębniony

Compartment

Sekcja

Composite state

Stan złożony

Conjugated port

Port sprzężony

Constraint

Ograniczenie

Constraint block

Blok ograniczeń

Constraint parameter

Parametr ograniczający

Constraint property

Cecha ograniczająca

Containment

Zagnieżdżenie

Control flow

Przepływ sterowania

Control operator

Operator sterowania

Control value

Wartość kontrolna

Copy dependency

Zależność powielania

Data flow

Przepływ danych

Data store node

Składnica danych

Decision node

Decyzja

Deep history pseudo state

Głębokie wznowienie

Dependency

Zależność

Derive dependency

Zależność wyprowadzania

Derived value

Wartość pochodna

Device

Urządzenie

Dimension

Miara

Discipline

Dyscyplina

Entry point

Punkt wejścia

Enumeration

Wyliczeniowy typ wartości

Dodatek B ♦ Słownik angielsko-polski

149

Exception handler

Manipulator wyjątków

Execution specification

Ośrodek sterowania

Exit point

Punkt wyjścia

Expansion node

Przekaźnik rozszerzenia

Expansion region

Obszar rozszerzenia

Expression gate

Brama wyrażeniowa

Extend dependency

Zależność rozszerzania

Extended requirement

Rozszerzone wymaganie systemowe

Extended use case

Przypadek rozszerzany

External system

System zewnętrzny

Final state

Stan końcowy

Flow final

Zakończenie przepływu

Flow port

Port transmisyjny

Flow specification

Specyfikacja przepływu

Fork node

Rozwidlenie

Formal gate

Brama formalna

Found message

Komunikat znaleziony

Frame

Rama

Framework

Zrąb

Functional requirement

Wymaganie funkcjonalne

Gate

Brama

Generalization

Uogólnienie

Guard condition

Warunek

Include dependency

Zależność zawierania

Including use case

Przypadek zawierający

Inheritance

Dziedziczenie

Initial node

Początek

Initial pseudo state

Pseudostan początkowy

Initial state

Stan początkowy

Initial value

Wartość początkowa

Interaction

Interakcja

Interaction operand

Operand interakcji

150

Język inżynierii systemów SysML. Architektura i zastosowania

Interaction operator

Operator interakcji

Interaction use

Przywoływane wystąpienie interakcji

Interface

Interfejs

Internal activity

Czynność wewnętrzna

Internal block diagram

Diagram bloków wewnętrznych

Internal transition

Przejście wewnętrzne

Interruptible activity region

Obszar przerwania

Interrupting edge

Przepływ przerwania

Item flow

Przepływ zasobu

Join node

Scalenie

Join specification

Specyfikacja scalenia

Junction pseudo state

Punkt węzłowy

Lifeline

Linia życia

Lost message

Komunikat utracony

Measure of effectiveness

Miara efektywności

Merge node

Złączenie

Message

Komunikat

Model library

Biblioteka

Multiplicity

Liczebność

Name compartment

Sekcja nazwy

Namespace

Przestrzeń nazw

Navigability

Nawigacja

No buffer

Niebuforujący przekaźnik danych

Non-atomic port

Port zagregowany

Non-functional requirement

Wymaganie pozafunkcjonalne

Object

Obiekt

Object Constraint Language Język opisu ograniczeń Objective function

Funkcja celowa

Operation

Operacja

Optional

Parametr opcjonalny

Orthogonal region

Obszar współbieżny

Overwrite

Nadpisujący przekaźnik danych

Dodatek B ♦ Słownik angielsko-polski

151

Package

Pakiet

Package diagram

Diagram pakietów

Parameter set

Zestaw przekaźników danych

Parametric diagram

Diagram parametryczny

Part

Część

Part association

Agregacja całkowita

Participant property

Węzeł bloku asocjacyjnego

Performance

Wydajność

Phase

Faza

Pin

Przekaźnik danych

Postcondition

Warunek końcowy

Precondition

Warunek wstępny

Probability

Prawdopodobieństwo

Property

Cecha

Provided interface

Interfejs udostępniający

Pseudo state

Pseudostan

Rate

Przepustowość

Realization

Realizacja

Reference

Odniesienie

Refine dependency

Zależność precyzowania

Relationship

Związek

Reliability

Niezawodność

Required interface

Interfejs pozyskujący

Requirement

Wymaganie systemowe

Requirements diagram

Diagram wymagań systemowych

Return message

Komunikat zwrotny

Role property

Rola

Satisfy dependency

Zależność realizacji

Self-transition

Przejście zwrotne

Send signal action

Sygnał

Sequence diagram

Diagram sekwencji

Shallow history pseudo state Płytkie wznowienie

152

Język inżynierii systemów SysML. Architektura i zastosowania

Shared association

Agregacja częściowa

Simple state

Stan prosty

Stakeholder

Interesariusz

Standard port

Port standardowy

State

Stan

State machine

Maszyna stanowa

State machine diagram

Diagram maszyny stanowej

Stereotype

Stereotyp

Stream

Przepływ strumieniowy

Structure compartment

Sekcja struktury

Subactivity

Podczynność

Submachine state

Podmaszyna stanowa

Substate

Podstan

Subsystem

Podsystem

Supportability

Przystosowalność

Synchronous message

Komunikat synchroniczny

Systems Modeling Language Język modelowania systemów Terminate node

Punkt zniszczenia

Test case

Testowy przypadek użycia

Time

Czas

Timeout message

Komunikat oczekujący

Token

Znacznik sterowania

Trace dependency

Zależność śledzenia

Trade-off analysis

Analiza wariantowa

Transition

Przejście

Unified Modeling Language

Ujednolicony język modelowania

Unit

Jednostka miary

Usability

Użyteczność

Use case

Przypadek użycia

Use case description

Scenariusz

Use case diagram

Diagram przypadków użycia

Value

Wartość

Dodatek B ♦ Słownik angielsko-polski

153

Value type

Typ wartości

Verify dependency

Zależność weryfikowania

View

Perspektywa

Viewpoint

Perspektywa postrzegania

Weight

Waga

White box

Biała skrzynka

154

Język inżynierii systemów SysML. Architektura i zastosowania

Dodatek C

Spis rysunków Rysunek 1.1.

Klasyfikacja inżynierii systemów ................................................................ 14

Rysunek 1.2.

Źródła i główne elementy języka SysML ..................................................... 15

Rysunek 1.3.

Hierarchia diagramów języka SysML .......................................................... 16

Rysunek 2.1.

Rational Unified Process .............................................................................. 20

Rysunek 2.2.

Wymagania funkcjonalne i pozafunkcjonalne ............................................. 20

Rysunek 2.3.

Kategorie modelowania diagramu wymagań systemowych ......................... 23

Rysunek 2.4.

Notacje wymagań ........................................................................................ 24

Rysunek 2.5.

Związek zagnieżdżenia w diagramie wymagań systemowych ..................... 26

Rysunek 2.6.

Wymagania funkcjonalne internetowej platformy transakcyjnej banku ...... 27

Rysunek 2.7.

Różne konwencje graficznej prezentacji zależności wyprowadzania .......... 29

Rysunek 2.8.

Różne konwencje graficznej prezentacji zależności realizacji ..................... 30

Rysunek 2.9.

Bezpośrednia konwencja graficznej prezentacji zależności powielania ....... 31

Rysunek 2.10.

Konwencje notatkowe graficznej prezentacji zależności powielania ........... 32

Rysunek 2.11.

Bezpośrednia konwencja graficznej prezentacji zależności weryfikowania ............................................................................ 33

Rysunek 2.12.

Konwencje notatkowe graficznej prezentacji zależności weryfikowania ..... 34

Rysunek 2.13.

Różne konwencje graficznej prezentacji zależności precyzowania .............. 35

Rysunek 2.14.

Różne konwencje graficznej prezentacji zależności śledzenia ..................... 36

Rysunek 2.15.

Studium diagramu wymagań systemowych banku internetowego ............... 38

Rysunek 2.16.

Rozszerzone wymaganie systemowe ........................................................... 42

Rysunek 3.1.

Kategorie modelowania diagramów definiowania bloków .......................... 47

Rysunek 3.2.

Bloki o charakterze sprzętowym, programowym i organizacyjnym ............ 49

Rysunek 3.3.

Sekcje bloków .............................................................................................. 51

Rysunek 3.4.

Diagram definiowania bloków serwisu transakcyjnego sklepu internetowego ................................................................................... 53

156

Język inżynierii systemów SysML. Architektura i zastosowania Rysunek 3.5.

Definiowanie typów wartości ...................................................................... 55

Rysunek 3.6.

Różne rodzaje typów wartości ..................................................................... 56

Rysunek 3.7.

Miary oraz jednostki miar ............................................................................ 57

Rysunek 3.8.

Blok w postaci „białej skrzynki” .................................................................. 58

Rysunek 3.9.

Blok abstrakcyjny i bloki konkretne ............................................................ 59

Rysunek 3.10.

Zastosowanie bloku asocjacyjnego .............................................................. 59

Rysunek 3.11.

Blok ograniczeń ........................................................................................... 60

Rysunek 3.12.

Notacja sekcyjna alokacji ............................................................................. 62

Rysunek 3.13.

Alternatywne graficzne notacje alokacji na diagramach definiowania bloków .................................................................................... 63

Rysunek 4.1.

Kategorie modelowania diagramów definiowania bloków .......................... 66

Rysunek 4.2.

Wybrane części bloku Serwis transakcyjny sklepu internetowego .............. 67

Rysunek 4.3.

Pojedyncze porty transmisyjne .................................................................... 69

Rysunek 4.4.

Zagregowane porty transmisyjne oraz specyfikacje przepływu ................... 70

Rysunek 4.5.

Zastosowanie portów sprzężonych .............................................................. 72

Rysunek 4.6.

Porty standardowe i interfejsy ...................................................................... 73

Rysunek 4.7.

Przywołanie części ....................................................................................... 75

Rysunek 4.8.

Wartości początkowe ................................................................................... 76

Rysunek 4.9.

Węzły bloku asocjacyjnego ......................................................................... 77

Rysunek 4.10.

Przepływ zasobów pomiędzy pojedynczymi portami transmisyjnymi ......... 78

Rysunek 4.11.

Sekcyjna notacja portów standardowych i transmisyjnych .......................... 79

Rysunek 5.1.

Kategorie modelowania diagramów parametrycznych ................................ 82

Rysunek 5.2.

Definiowanie bloków ograniczeń ................................................................ 84

Rysunek 5.3.

Definiowanie bloków ograniczeń z dodatkową specyfikacją parametrów .............................................................................. 85

Rysunek 5.4.

Diagram parametryczny dla bloku ograniczeń Optymalne zamówienie ...... 87

Rysunek 5.5.

Przyporządkowanie cech bloków do cech ograniczających ......................... 88

Rysunek 5.6.

Specyfikowanie wartości cech bloków na diagramie parametrycznym ....... 89

Rysunek 5.7.

Skrócony zapis pobierania wartościowań cech bloków zewnętrznych ........ 90

Rysunek 5.8.

Specyfikacja funkcji celowej na potrzeby analizy wariantowej — diagram definiowania bloków ................................................................. 91

Rysunek 5.9.

Diagram parametryczny analizy wariantowej .............................................. 92

Rysunek 5.10.

Szczegółowa specyfikacja wartości bloków stanowiących przedmiot analizy wariantowej ..................................................................................... 93

Rysunek 5.11.

Przeliczanie poszczególnych wariantów analizy wariantowej ..................... 94

Rysunek 6.1.

Kategorie modelowania rozszerzonych diagramów czynności .................... 97

Dodatek C ♦ Spis rysunków

157

Rysunek 6.2.

Diagram czynności rejestrowania użytkownika ......................................... 102

Rysunek 6.3.

Czynności strumieniowe i niestrumieniowe ............................................... 104

Rysunek 6.4.

Zastosowanie wartości kontrolnych ........................................................... 105

Rysunek 6.5.

Specyfikacja operatora sterowania ............................................................. 106

Rysunek 6.6.

Niebuforujący przekaźnik danych .............................................................. 107

Rysunek 6.7.

Nadpisujący przekaźnik danych o zdefiniowanym rozmiarze bufora ........ 109

Rysunek 6.8.

Zastosowanie parametrów opcjonalnych ................................................... 110

Rysunek 6.9.

Specyfikowanie przepustowości na rozszerzonych diagramach czynności ................................................................................ 111

Rysunek 6.10.

Wprowadzanie prawdopodobieństwa do rozszerzonych diagramów czynności ................................................................................. 112

Rysunek 6.11.

Notatkowa notacja warunków wstępnych i końcowych ............................. 114

Rysunek 6.12.

Warunki wstępne i końcowe kompletnego diagramu ................................. 115

Rysunek 6.13.

Asocjacje z agregacją wiążące czynności w postaci bloków ..................... 117

Rysunek 7.1.

Diagram przypadków użycia systemu repozytorium projektów ................ 123

Rysunek 7.2.

Diagram maszyny stanowej dla faktury ..................................................... 127

Rysunek 7.3.

Konceptualny diagram sekwencji dla PU „Obsługa sygnału z czujnika alarmowego” ................................................ 132

Rysunek 7.4.

Diagram pakietów internetowej platformy transakcyjnej banku ................ 136

Rysunek 7.5.

Pakiet „Wymagania funkcjonalne internetowej platformy transakcyjnej banku” i jego zawartość ...................................... 137

158

Język inżynierii systemów SysML. Architektura i zastosowania

Dodatek D

Spis tabel Tabela 1.1.

Diagramy języka SysML i ich odpowiedniki w języku UML ............................ 16

Tabela 2.1.

Rodzaje związków na diagramach wymagań systemowych .............................. 25

Tabela 2.2.

Porównanie zależności na diagramach wymagań systemowych ........................ 37

Tabela 2.3.

Tabelaryczna reprezentacja wymagań systemowych ......................................... 40

Tabela 2.4.

Tabelaryczna reprezentacja związków ............................................................... 41

Tabela 2.5.

Dodatkowe stereotypy wymagania zaawansowanego ........................................ 43

Tabela 3.1.

Składnia cech bloku ........................................................................................... 50

Tabela 3.2.

Związki w diagramach definiowania bloków ..................................................... 52

Tabela 3.3.

Tabelaryczna specyfikacja alokacji .................................................................... 64

Tabela 6.1.

Pierwotne kategorie modelowania diagramów czynności .................................. 97

Tabela 6.2.

Porównanie właściwości przetwarzania standardowego i strumieniowego ...... 104

Tabela 7.1.

Kategorie modelowania diagramu przypadków użycia .................................... 121

Tabela 7.2.

Kategorie modelowania diagramu maszyny stanowej ...................................... 125

Tabela 7.3.

Kategorie modelowania diagramu sekwencji ................................................... 128

Tabela 7.4.

Kategorie modelowania diagramu pakietów .................................................... 134

160

Język inżynierii systemów SysML. Architektura i zastosowania

Dodatek E

Literatura Źródła drukowane: Bahill i Gissing, 1998

Bahill A. T., Gissing B. (1998), Re-evaluating systems engineering concepts using systems thinking, „IEEE Transaction on Systems, Man and Cybernetics, Part C: Applications and Reviews”, no. 28.

Bajaj i Wrycza, 2009

Bajaj A., Wrycza S. (2009, eds.), Systems Analysis and Design for Advanced Modeling Methods. Best Practices, Information Science Reference, New York: IGI Global.

Bock, 2006

Bock C. (2006), SysML and UML 2 Support for Activity Modeling, „Systems Engineering”, vol. 9.

Booch, 2004

Booch G., Rumbaugh J., Jacobson I. (2004), The UML Reference Manual 2nd Edition, Boston: Addison-Wesley.

Dennis, 2005

Dennis A. (2005), Systems Analysis and Design with UML Version 2.0, New York: Wiley.

Eriksson, Penker, Lyons i Fado, 2004

Eriksson H., Penker M., Lyons B., Fado D. (2004), UML 2 Toolkit, Indianapolis: OMG Press.

Friedenthal, Moore i Steiner, 2008

Friedenthal S., Moore A., Steiner R. (2008), A Practical Guide to SysML, Indianapolis: OMG Press.

Grady i Caswell, 1987

Grady R., Caswell D. (1987), Software Metrics: Establishing a Company-wide Program, New York: Prentice Hall.

Jacobson, Christerson, Jonsson i Overgaard, 1992

Jacobson I., Christerson M., Jonsson P., Overgaard G. (1992), Object-Oriented Software Engineering: A Use-Case Driven Approach, Boston: Addison-Wesley.

162

Język inżynierii systemów SysML. Architektura i zastosowania

Kwapisz, 2006

Kwapisz S. (2006), Modelowanie systemu baz danych o dużej instytucji finansowej wsparte językiem UML 2.0 (w:) S. Kozielski, B. Małysiak, P. Kasprowski, D. Mrozek (red.), Bazy danych: struktury, algorytmy, metody. Wybrane technologie i zastosowania, Warszawa: Wydawnictwo Komunikacji i Łączności.

Kwapisz, 2007a

Kwapisz S. (2007), Enhancing the Business Processing in Insurance enterprise by SOA and ECM Presented with UML 2.1, „Polish Journal of Environmental Studies”, nr 16.

Kwapisz, 2007b

Kwapisz S. (2007), UML 2.0 in the modeling of the complex business processes of reporting and control of financial information system (in:) Proceedings of The Second AIS SIGSAND European Symposium on Systems Analysis and Design, Gdansk: Gdansk University Press.

Leffingwel i Widrig, 2003

Leffingwel D., Widrig D. (2003), Zarządzanie wymaganiami, Warszawa: WNT.

Maciaszek, 2005

Maciaszek L. A. (2005), Requirements Analysis and System Design 2nd Edition, Harlow: Pearson.

Marcinkowski, 2005a

Marcinkowski B. (2005), Isomorphism of Interaction Diagrams in UML 2 (in:) W. Abramowicz (ed.), Proceedings of 8th International Conference on Business Information Systems, Poznan: Poznan University of Economics Press.

Marcinkowski, 2005b

Marcinkowski B. (2005), Relevance of Use-Case Scenarios’ Descriptions in System Requirements Specification (in:) B. F. Kubiak, A. Korowicki (eds.), Information Management, Gdansk: Gdansk University Press.

Marcinkowski, 2008

Marcinkowski B. (2008), Business modeling with UML and BPMN: Features and Comparison (in:) Proceedings of BIR'2008. The Seventh International Conference on Perspectives in Business Informatics Research, Gdansk: Gdansk University Press.

Marcinkowski, Wrycza Marcinkowski B., Wrycza S., Wyrzykowski K., (2005), i Wyrzykowski, 2005 Interaction Occurrences and Combined Fragments in System Dynamics Modeling with UML 2 Sequence Diagram (in:) A. G. Nilsson, R. Gustas, W. Wojtkowski, W. G. Wojtkowski, S. Wrycza, J. Zupančič (eds.), Proceeding of the 14th International Conference on Information Systems Development. Advances in ISD: Bridging the Gap between Academia and Practice, Karlstad: Karlstad University Studies.

Dodatek E ♦ Literatura

163

Matosek, 2002

Matosek W. (2002), Użyteczność języka UML w modelowaniu procesów kadrowych, praca doktorska pod kier. S. Wryczy, Gdańsk: Uniwersytet Gdański.

Mielcarek, 2007

Mielcarek P. (2007), Towards UML Based Persistence Modeling: A Quality Driven Approach (in:) M. Helfert, T. T. P. Thi, H. Duncan (eds.), Cases and Projects in Business Informatics — International Business Informatics Challenge 2007, Berlin: Logos-Verlag.

Muller, 2000

Muller R. J. (2000), Bazy danych. Język UML w modelowaniu danych, Warszawa: Mikom.

Podeswa, 2005

Podeswa H. (2005), UML for the IT Business Analyst: A Practical Guide to Object-Oriented Requirements Gathering, Boston: Thomson Course Technology PTR.

Przybyłek, 2007

Przybyłek A. (2007), Zastosowanie notacji UML w modelowaniu procesów biznesowych firmy, „Logistyka”, nr 3.

Przybyłek, 2008

Przybyłek A. (2008), Separation of Crosscutting Concerns at the Design Level: an Extension to the UML Metamodel (in:) Proceedings of International Multiconference on Computer Science and Information Technology, Mrągowo: Polish Information Processing Society Press.

Rational, 2002

Rational Software Corporation (2002), Rational Unified Process, Process Made Practical — plansza informacyjna.

Rumbaugh et al., 1991 Rumbaugh J., Blaha M. R., Lorensen W., Eddy F., Premerlani W. (1991), Object-Oriented Modeling and Design, New Jersey: Prentice Hall. Śmiałek, 2005

Śmiałek M. (2005), Zrozumieć UML 2.0. Metody modelowania obiektowego, Gliwice: Helion.

Subieta, 1998

Subieta K. (1998), Obiektowość w projektowaniu i bazach danych, Warszawa: Oficyna Wydawnicza PLJ.

Weilkiens, 2007

Weilkiens T. (2007), Systems Engineering with SysML/UML. Modeling, Analysis, Design, Indianapolis: OMG Press.

Wrycza i Marcinkowski, Wrycza S., Marcinkowski B. (2006), Proces dydaktyczny 2006a w zakresie języka UML 2.0 na Uniwersytecie Gdańskim, „Roczniki Kolegium Analiz Ekonomicznych SGH. Współczesne trendy w informatyce ekonomicznej”, nr 16.

164

Język inżynierii systemów SysML. Architektura i zastosowania

Wrycza i Marcinkowski, Wrycza S., Marcinkowski B. (2006), Unified Modeling 2006b Language Teaching Approach: Survey and Assessment (in:) Proceedings of the 5th International Conference on Perspectives in Business Informatics Research, Kaunas: Kaunas University of Technology Press. Wrycza i Marcinkowski, Wrycza S., Marcinkowski B. (2007), Język UML 2.x 2007a Light — ocena uwarunkowań i model, „Prace i Materiały Wydziału Zarządzania Uniwersytetu Gdańskiego”, nr 3. Wrycza i Marcinkowski, Wrycza S., Marcinkowski B. (2007), Towards a Light 2007b Version of UML 2.x: Appraisal and Model, „Organizacija” (Słowenia), nr 4. Wrycza i Marcinkowski, Wrycza S., Marcinkowski B. (2008), Język UML 2.x 2008a w dydaktyce akademickiej, „Software Developer’s Journal”, nr 10. Wrycza i Marcinkowski, Wrycza S., Marcinkowski B. (2008), Kompleksowe podejście 2008b do nauczania języka UML 2.x na uczelniach wyższych (w:) S. Kozielski, B. Małysiak, P. Kasprowski, D. Mrozek (red.), Bazy danych: rozwój metod i technologii. Architektura, metody formalne i zaawansowana analiza danych, Warszawa: Wydawnictwo Komunikacji i Łączności. Wrycza i Marcinkowski, Wrycza S., Marcinkowski B. (2008), Rozwój języka UML 2008c — zmiany w wersji 2.1, „Software Developer’s Journal”, nr 2. Wrycza, 1999

Wrycza S. (1999), Analiza i projektowanie systemów informatycznych zarządzania, Warszawa: PWN.

Wrycza, 2007

Wrycza S. (2007, ed.), Proceedings of The Second AIS SIGSAND European Symposium on Systems Analysis and Design, Gdansk: Gdansk University Press.

Wrycza, 2008a

Wrycza S. (2008, ed.), Proceedings of BIR'2008. The Seventh International Conference on Perspectives in Business Informatics Research, Gdansk: Gdansk University Press

Wrycza, 2008b

Wrycza S. (2008, ed.), Proceedings of the 8th MINE Doctoral Consortium Workshop Methodologies for Interactive Networked Enterprises, Gdansk: Gdansk University Press.

Wrycza, 2009

Wrycza S. (2009, red.), Informatyka ekonomiczna, Warszawa: PWE.

Wrycza, Marcinkowski Wrycza S., Marcinkowski B., Wyrzykowski K. (2005), i Wyrzykowski, 2005a Język UML 2.0 w modelowaniu systemów informatycznych, Gliwice: Helion. Wrycza, Marcinkowski Wrycza S, Marcinkowski B., Wyrzykowski K. (2005),

Dodatek E ♦ Literatura

165

i Wyrzykowski, 2005b Rola fragmentów wyodrębnionych w języku UML 2 (w:) S. Kozielski, B. Małysiak, P. Kasprowski, D. Mrozek (red.), Bazy danych: Modele, Technologie, Narzędzia. Architektura, metody formalne, bezpieczeństwo, Warszawa: Wydawnictwo Komunikacji i Łączności. Wrycza, Marcinkowski Wrycza S., Marcinkowski B., Wyrzykowski K. (2005), i Wyrzykowski, 2005c Rola i funkcje diagramów harmonogramowania w modelowaniu systemów informatycznych z wykorzystaniem języka UML 2 (w:) A. Nowakowski (red.), Infobazy ‘2005. Bazy danych dla nauki, Gdańsk: Centrum Informatyczne TASK. Wrycza, Marcinkowski Wrycza S., Marcinkowski B., Wyrzykowski K. (2005), i Wyrzykowski, 2005d Timing Diagram Functionalities in Information Systems Modeling with UML 2 (in:) B. F. Kubiak, A. Korowicki (eds.), Information Management, Gdansk: Gdansk University Press. Wrycza, Marcinkowski Wrycza S., Marcinkowski B., Wyrzykowski K. (2006), i Wyrzykowski, 2006 Pseudostany w diagramach maszyny stanowej języka UML 2.0 (w:) S. Kozielski, B. Małysiak, P. Kasprowski, D. Mrozek (red.), Bazy danych: struktury, algorytmy, metody. Architektura, metody formalne i eksploracja danych, Warszawa: Wydawnictwo Komunikacji i Łączności. Wrycza, Marcinkowski Wrycza S., Marcinkowski B., Wyrzykowski K. (2007), i Wyrzykowski, 2007 UML. Tablice informatyczne, Gliwice: Helion. Wrycza, red., 2007

Wrycza S. (2007, red.), UML 2.1. Ćwiczenia, Gliwice: Helion.

Źródła elektroniczne: EA, 2009

http://www.sparxsystems.com.au, stan na dzień 05.08.2009.

Balmelli, 2006

Balmelli L., An overview of the Systems Modeling Language for product and systems development, http://www.ibm.com/ developerworks/rational/library/aug06/balmelli/index.html, stan na dzień 05.08.2009.

Cisco, 2009

Cisco Systems, Models Comparison, http://www.cisco.com/ en/US/products/ps6406/prod_models_comparison.html, stan na dzień 05.08.2009.

Hause, 2009

Hause M., SysML hits the home straight, http://www.esemagazine.com/index.php?option=com_content& task=view&id=140&Itemid=2, stan na dzień 05.08.2009.

IBM, 2009

http://www-01.ibm.com/software/sw-bycategory/subcategory/ SW710.html, stan na dzień 05.08.2009.

166

Język inżynierii systemów SysML. Architektura i zastosowania

IEEE, 1998

Institute of Electrical and Electronics Engineers, IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications — Description, http://standards.ieee.org/reading/ieee/std_public/description/ se/830-1998_desc.html, stan na dzień 05.08.2009.

INCOSE, 2007

Technical Board International Council on Systems Engineering, Systems Engineering Handbook. Version 3.1, http://www.incose.org/ProductsPubs/products/sehandbook.aspx, stan na dzień 05.08.2009.

MagicDraw, 2009

http://www.magicdraw.com, stan na dzień 05.08.2009.

OMG, 2008

Object Management Group, OMG Systems Modeling Language (OMG SysML). Version 1.1, http://www.sysmlforum.com/docs/ specs/OMGSysML-v1.1-08-11-01.pdf, stan na dzień 05.08.2009.

OMG, 2009

Object Management Group, OMG Unified Modeling Language (OMG UML), Superstructure. Version 2.2, http://www.omg.org/ spec/UML/2.2/Superstructure/PDF/, stan na dzień 05.08.2009.

RSWP, 1998

Rational Software White Paper, Rational Unified Process. Best Practices for Software Development Teams, ftp://ftp.software.ibm.com/software/rational/web/whitepapers/ 2003/rup_bestpractices.pdf, stan na dzień 05.09.2005.

RUP, 2003

Rational Unified Process — hipertekstowa baza wiedzy, stan na dzień 05.08.2009.

SysMLForum, 2009

http://www.sysmlforum.com, stan na dzień 05.08.2009.

Wojciechowski, 2009

Wojciechowski A., Wprowadzenie do inżynierii wymagań, www.inmost.org.pl/articles/Wprowadzenie_do_inżynierii_ wymagań, stan na dzień 05.08.2009.

Wrycza i Marcinkowski, Wrycza S., Marcinkowski B., „UML 2 Teaching at 2005 Postgraduate Studies — Prerequisites & Practice” (in:) Proceedings of the 22nd Annual Conference for Information Systems Educators. Volume 22, Chicago: AITP Foundation for IT Education. Wrycza i Marcinkowski, Wrycza S., Marcinkowski B., „UML 2 Academic 2006c Course — Methodological Background and Survey Benchmarking” (in:) Proceedings of the 23rd Annual Conference for Information Systems Educators. Volume 23, Chicago: AITP Foundation for Information Technology Education. Wrycza i Marcinkowski, Wrycza S., Marcinkowski B., „A Light Version of UML 2007c 2: Survey And Outcomes redistribution permission” (in:) Proceedings of the 2007 Computer Science and IT Education Conference, Mauritius: University of Technology Mauritius Press.

Skorowidz «constraintBlock», 83 «continuous», 111 «designConstraint», 44 «discrete», 111 «enumeration», 55 «flowSpecification», 69 «functionalRequirement», 43 «interfaceRequirement», 43 «moe», 91 «nobuffer», 107 «optional», 109 «performanceRequirement», 43 «physicalRequirement», 43 «streaming», 104

A activity diagram, 15 agile, 133 akcje, 98 aktor, 47 allocation, 57 alokacja, 57, 60 notacja sekcyjna, 62 specyfikacja tabelaryczna, 64 alokacja przepływów, 61 alokacja struktury, 61 alokacja zachowania, 61 architektura języka SysML, 9 asocjacja, 52, 59

B białe skrzynki, 56 block definition diagram, 15 bloki, 45, 48 cechy, 48 dodatkowe sekcje, 56 sekcje, 50 składnia cech, 50

bloki abstrakcyjne, 58 bloki asocjacyjne, 59 bloki ograniczeń, 60, 82, 83 blokowa notacja czynności, 116 buforowanie, 106

C CASE, 12, 133 cechy ograniczające, 82 constraint block, 60 control operator, 105 CSMP, 11 części, 67 czynności, 95, 97

D definiowanie bloki ograniczeń, 84 porty w sekcjach części/bloku, 79 struktura systemu, 45 diagram bloków wewnętrznych, 45, 65 części, 67 definiowanie portów w sekcjach części/bloku, 79 kategorie modelowania, 65 klasyfikacja portów, 67 konektory, 66 pojedyncze porty transmisyjne, 68 porty, 66, 67 porty standardowe, 71 przepływ zasobów, 78 przywołanie bloku/części, 74 sekcja cech przepływu, 69 sprzęganie zagregowanych portów transmisyjnych, 71 wartość początkowa, 76 węzeł bloku asocjacyjnego, 77 zagregowane porty transmisyjne, 69

168

Język inżynierii systemów SysML. Architektura i zastosowania

diagram definiowania bloków, 15, 45 aktor, 47 alokacja, 60 bloki, 48 bloki abstrakcyjne, 58 bloki asocjacyjne, 59 bloki ograniczeń, 60 dodatkowe sekcje bloku, 56 dostęp do bloków, 46 kategorie modelowania, 46 organizowanie elementów, 47 porty, 47 sekcje bloku, 50 składnia cech bloku, 50 spektrum związków, 46 typy wartości, 46, 54 unikatowa tożsamość, 46 zaawansowana specyfikacja bloków, 56 związki, 51 diagram maszyny stanowej, 15, 124 do, 125 entry, 125 exit, 125 kategorie modelowania, 125 obszar współbieżny, 126 przejście, 125 pseudostan, 126 sekwencje stanów, 124 stan, 125 stan końcowy, 125 stan początkowy, 125 stan złożony, 126 diagram pakietów, 15, 133 biblioteka, 135 dostęp, 135 import, 135 kategorie modelowania, 134 model, 134 pakiet, 134 perspektywa, 135 podsystem, 134 scalenie, 135 zagnieżdżenie, 134 zależność, 134 zrąb, 134 diagram parametryczny, 15, 81 bloki ograniczeń, 83 cechy ograniczające, 86 etapy tworzenia, 86 funkcje celowe, 88 kategorie modelowania, 82 miary efektywności, 83, 91 przypisywanie wartości cechom ograniczającym, 86

punkt wyjścia, 82 reguły, 82 skrócona notacja parametrów, 88 diagram parametryczny analizy wariantowej, 92 diagram przypadków użycia, 15, 120 aktor osobowy, 122 aktorzy, 120, 121 asocjacja, 121 czas, 122 kategorie modelowania, 121 liczebność, 122 nawigacja, 122 przypadek użycia, 121 realizacja, 121 system zewnętrzny, 122 uogólnienie, 121 urządzenie, 122 zależność, 121 zależność rozszerzania, 121 zależność zawierania, 121 diagram sekwencji, 15, 127 aktor, 128 alternatywa, 130 blok, 128 brama, 131 część bloku, 128 formuła, 130 fragmenty wyodrębnione, 129, 130 funkcjonalność nieprawidłowa, 130 istotność, 131 iteracja, 130 kategorie modelowania, 128 komunikaty, 128, 129 linia życia, 128 nieistotność, 131 obszar krytyczny, 130 opcja, 130 ośrodek sterowania, 128 poziom konceptualny, 131 przerwanie, 130 przywoływane wystąpienie interakcji, 131 słabe uporządkowanie, 131 ścisłe uporządkowanie, 131 współbieżność, 130 diagram wymagań systemowych, 15, 19, 21 «copy», 25, 31 «deriveReqt», 28 «refine», 33 «satisfy», 29 «trace», 34 «verify», 32 analiza porównawcza zależności, 37 hierarchiczna struktura wymagań, 25 identyfikacja wymagań, 22

Skorowidz

169

implementacja wymagań, 22 iteracje, 33 kategorie modelowania, 22 kontekst wymagań, 22 kontrakt, 23 notacje wymagań, 24 organizowanie elementów, 23 procedury weryfikacyjne, 33 sens wymagania, 33 skutki zmian, 29 stereotyp tekstowy, 25 testowy przypadek użycia, 33 wielokrotne użycie wymagania, 25 wymagania, 23 wymaganie tylko do odczytu, 31 zagnieżdżenie, 25 zależność powielania, 30 zależność precyzowania, 33 zależność realizacji, 28 zależność śledzenia, 34 zależność weryfikowania, 32 zależność wyprowadzania, 28 zasada ponownego wykorzystania, 31 związki pomiędzy wymaganiami, 24 diagramy, 15 SysML, 16 UML, 16 UML 2 x, 136 diagramy UML4SysML, 14, 119 kategorie, 119 dokumenty RFP, 10 SRS, 21 dokumentowanie scenariusze przypadków użycia, 120 wymagania systemowe, 21

F FURPS, 20

G graficzny język modelowania, 9

H hierarchia diagramów języka SysML, 16

I id, 23 INCOSE, 7, 10 interakcja, 127

interesariusze, 120 interfejs pozyskujący, 71 interfejs udostępniający, 72 internal block diagram, 15 inżynieria systemów, 10, 13 ISO, 7 istotność wymagania, 41 item flows, 78, 111

J jednostki miar, 55 język OCL, 113 język ograniczeń, 83 język SysML, 7 język UML, 7, 9 język UML 2 x, 136

K kierunek transmisji danych, 69 klasyfikacja inżynierii systemów, 14 klasyfikacja wymagań, 20 kombinacja portów, 68 komunikaty, 128 konektor, 82 konektor składany, 72 kontrakt, 23

L lokalne warunki, 113 luźne powiązanie, 61

M MDSE, 10 metodologia inżynierii systemów zorientowanych na model, 11 metodologie tworzenia systemów informatycznych, 12 metody dokumentowania wymagań systemowych, 21 metodyka RUP, 19 miary, 55 miary efektywności, 82, 91 model FURPS, 20 model SIMILAR, 13 Model-Based Systems Engineering Methodologies, 11 modelowanie przetwarzania strumieniowego, 103 modelowanie systemów informatycznych, 7

170

Język inżynierii systemów SysML. Architektura i zastosowania

N nadpisujący przekaźnik danych, 107, 108 namespace, 57 narzędzia tworzenia systemów, 12 NCOSE, 10 niebuforujący przekaźnik danych, 107 niezawodność, 21 notacja sekcyjna alokacji, 62 notacje wymagań, 24 numer porządkowy, 23

O OCL, 113 odpowiedniki diagramów UML, 16 ograniczenia, 81, 111 ograniczenie projektowe, 44 OMG, 7 operatory sterowania, 104

P package diagram, 15 pakiety, 133 parametric diagram, 15 parametry, 81 ograniczające, 86 opcjonalne, 109 participant properties, 77 performance, 21 pierwotne kategorie modelowania, 96 ponowne wykorzystanie, 31, 58 porty, 47, 66, 67 sprzężone, 71 standardowe, 68, 71 porty transmisyjne, 68 pojedyncze, 68 zagregowane, 69 prawdopodobieństwo, 112 priorytet wymagania, 41 problematyka alokacji, 60 program certyfikacyjny z zakresu SysML, 11 przekaźnik danych, 106 przepływ sterowania, 98 przepływ zasobów, 78, 111 przepustowość, 111 przestrzenie nazw, 57 przetwarzanie strumieniowe, 103 przystosowalność, 21 przywołanie bloku/części, 74

R rate, 111 Rational Unified Process, 20 realizacja, 52 referencje, 54 reliability, 21 Request for Proposal, 10 requirements diagram, 15 requirements specification, 19 RFP, 10 rozszerzone wymagania systemowe, 41 rozszerzony diagram czynności, 15, 95 akcje, 98 blokowa notacja czynności, 116 bufor centralny, 100 buforowanie danych, 106 buforowanie sterowania, 106 charakterystyka pierwotnych kategorii modelowania, 96 czynności, 97 decyzja, 98 integracja funkcji decyzji złączenia, 98 integracja funkcji rozwidlenia i scalenia, 99 kategorie modelowania, 96, 97 koniec, 98 lista wartości kontrolnych, 105 manipulator wyjątków, 101 mechanizm zarządzania statusami, 104 nadpisujący przekaźnik danych, 108 niebuforujący przekaźnik danych, 107 obszar przerwania, 101 obszar rozszerzenia, 101 operatory sterowania, 104 parametr czynności, 99 parametr opcjonalny, 109 partycja diagramów czynności, 100 początek, 98 prawdopodobieństwo, 112 przekaźnik danych, 99, 106 przepływ sterowania, 98 przepustowość, 111 rdzeń, 96 rejestrowanie użytkownika, 102 rozwidlenie, 98 scalenie, 99 składnica danych, 100 specyfikacja przepustowości, 111 sygnał, 100 SysML, 103 systemy ciągłe, 103 systemy strumieniowe, 103 waga, 100 wartości kontrolne, 104

Skorowidz

171

warunki końcowe, 113 warunki wstępne, 113 zakończenie przepływu, 98 zarządzanie kolejkowanymi danymi, 107 zestaw przekaźników, 99 złączenie, 98 rozwinięcie koncepcji klasy, 48 różne rodzaje ryzyka implementacji wymagania, 42 RTF, 11 RUP, 19

S sekwencje stanów, 124 sequence diagram, 15 SIMILAR, 13 składnia nazwy, 78 specyfikacja języka SysML, 8 specyfikacja przepustowości, 111 specyfikacja wymagań systemowych, 19 sprzęganie zagregowanych portów transmisyjnych, 71 SRS, 21 stabilność wymagania, 42 stakeholders, 120 state machine diagram, 15 stereotyp tekstowy, 25 stereotypowane bloki, 116 stereotypowanie rozszerzonych wymagań systemowych, 42 struktury, 55, 56 supportablity, 21 SysML, 7, 120 diagramy, 15 ewolucja języka, 11 struktura języka, 14 wersje, 11 założenia języka, 11 system klasyfikacji dziesiętnej Deweya, 40 systemy ciągłe, 103 systemy strumieniowe, 103 szereg stereotypów, 68

T tabelaryczna specyfikacja alokacji, 64 tabelaryczna specyfikacja wymagań, 40 tabelaryczna specyfikacja związków, 41 technologiczne wyzwania, 13 testowy przypadek użycia, 33 text, 23 treść wymagania, 23 typ wymagania, 42

typy wartości, 54 rodzaje, 55

U UML, 7, 9 UML 2 x, 16, 136 UML for Systems Engineering, 10 UML4SysML, 14, 119 uogólnienie, 52 usability, 21 use case diagram, 15, 120 użyteczność, 21

W wartości kontrolne, 104 wartość początkowa, 76 warunki końcowe, 113 warunki wstępne, 113 wewnętrzne buforowanie, 106 węzeł bloku asocjacyjnego, 77 white box, 56 wielodziedzinowe zespoły, 13 wydajność, 21 wyliczenia, 55 wymagania, 19, 23 fizyczne, 43 funkcjonalne, 20, 43 interfejsowe, 43 pozafunkcjonalne, 20, 21 rozszerzone wymagania systemowe, 41 stereotypowanie rozszerzonych wymagań systemowych, 42 tabelaryczna specyfikacja wymagań, 40 wydajnościowe, 43 wyprowadzenie wymagania, 28

Z zaawansowana specyfikacja wymagań, 39 zagnieżdżenie, 52 zakończenie przepływu, 98 zakończenie wykonania czynności-całości, 116 zależność, 52 zarządzanie kolejkowanymi danymi, 107 zarządzanie złożonością modelu, 133 zasada ponownego wykorzystania, 31 związki, 51 związki pomiędzy wymaganiami, 24 związki zagnieżdżenia, 22