Pobierz prezentację
Pobieranie prezentacji. Proszę czekać
1
Systemy czasu rzeczywistego
Rafał Krawczyk Wacław Kowalski Maciej Stojko Tomasz Żyguła
2
Plan prezentacji Część 1:
Zastosowanie podejścia środowiskowego UML w modelowaniu struktury systemu czasu rzeczywistego Część 2: Automatyczna weryfikacja modeli UML
3
Plan prezentacji (cz.1) Wstęp Modelowanie struktury
Modelowanie zachowania Usługa oparta na czasie Przykład: przedstawienie problemu analiza obiektowa
4
Plan prezentacji (cz.2) Wstęp PVF (Property Verification Framework)
Projekt RIVIERA Krótka charakterystyka wybranych narzędzi CASE: I-Logix Raphsody I-Logix Statement Magnum Together PhD DMS Toolkit Visual Paradigm for UML Community Edition 3.1 Metamill 3.1 Visual UML Case Tool Rational Rose Argo
5
Zastosowanie podejścia środowiskowego UML w modelowaniu struktury systemu czasu rzeczywistego
6
Tytułem wstępu Systemy oprogramowania czasu rzeczywistego spotykane w takich zastosowaniach jak telekomunikacja, aeronautyka i obrona, zwykle są duże i bardzo skomplikowane. Duże znaczenie architektury w tworzeniu SCR Wykorzystanie Unified Modeling Language – UML
7
Użycie UML Okazał się on dobrze spełniać swoje zadanie, a żadne dodatkowe sposoby modelowania nie są potrzebne Zastosowanie znalazły standardowe mechanizmy UML, takie jak: stereotypy (ang. stereotype) wartości-etykiety (ang. tagged value) warunki ograniczające (ang. constrains)
8
Zasady Modelowania SCR
Zasady te można podzielić na dwie grupy: modelowanie struktury modelowanie zachowania
9
Modelowanie struktury
Obejmuje elementy, które mają być modelowane oraz związki między nimi (np. związki komunikowania się, związki zawierania). UML dostarcza dwa komplementarne typy diagramów, które obejmują strukturę logiczną systemów: diagramy klasy (ang. class diagram) diagram współpracy (ang. collaboration diagram)
10
Modelowanie struktury
Przy modelowaniu struktury możemy wyróżnić trzy zasadnicze konstruktory: kapsuły porty konektory
11
Kapsuły Są jedną z najważniejszych konstrukcji modelowania.
Przy ich pomocy przedstawia się ważniejsze elementy architektoniczne skomplikowanych SCR Komunikacja z innymi kapsułami przy użyci portów Może zawierać jedną lub więcej pod-kapsuł połączonych ze sobą za pomocą konektorów
12
Kapsuły – wewnętrzna struktura
Struktóra kapsuły: porty pod-kapsuły konektory role-wtyczki
13
Kapsuły – maszyna stanu
Maszyna stanu opcjonalnie powiązana z kapsułą jest jedynie kolejną częścią implementacji kapsuły Szczególne właściwości maszyny stanowej: nie mogą się składać z innych pod-kapsuł maksymalnie jedna maszyna stanu na kapsułę obsługiwać sygnałów ( in /out) jedyna jednostka, która może uzyskać dostęp do chronionych wewnętrznych elementów kapsuły
14
Kapsuły – maszyna stanu
Zapis kapsuły na diagramie klasy
15
Porty Port jest fizyczną częścią kapsuły, która pośredniczy w komunikacji kapsuły ze światem zewnętrznym, jest obiektem, który zawiera specyficzny interfejs. Każdy port kapsuły odgrywa konkretną rolę we współpracy kapsuły z innymi obiektami Dwa rodzaje portów: przekaźnikowe (ang. relay ports) terminatory (ang. end ports)
16
Porty Modelowanie w UML Porty, protokoły i role protokołów
17
Porty Oznaczanie portów – reprezentacja diagramu klasy
18
Porty Porty o większej liczbie instancji
19
Konektory Konektor reprezentuje kanał komunikacyjny, który udostępnia funkcję transportu dla danego protokołu sygnałowego. Podstawową cechą konektorów jest to, że potrafią one połączyć jedynie te porty, które pełnią wzajemnie komplementarne role w protokole danego konektora
20
Konektory Modelowanie UML
konektor jest modelowany za pomocą związku (ang. association) definiowany jest poprzez rolę związku na diagramie współpracy przedstawiającym kapsułę
21
Modelowanie zachowania
Zachowanie jest opisywane na poziomie architektonicznym przy użyciu pojęcia protokołu
22
Protokoły Jest specyfikacją pożądanego zachowania, które ma miejsce przy użyciu konektora Składa się z szeregu uczestników, z których każdy pełni określoną rolę Może zawierać specyfikację prawidłowych sekwencji komunikacyjnych
23
Zapis roli protokołu – diagram klasy
Protokoły Zapis roli protokołu – diagram klasy
24
Czas - najwżniejszy czynnik SCR
Ogólnie można modelować dwie sytuacje oparte na czasie: możliwość wyzwalania działań w określonym momencie możliwość wywoływania działań po upłynięciu określonego czasu od danego momentu
25
Modelowanie usług opartych na czasie
Idea usługi opartej na czasie nie wymaga żadnych rozszerzeń UML lub specjalnego sposobu zapisu
26
UML real-time na przykładzie.
Przedstawienie problemu Analiza UML
27
Przedstawienie problemu
Co to jest respirator. Zasada działania. Budowa respiratora. Istota sensorów. Zagrożenia występujące w żelaznych płucach. Ważniejsze monitorowane parametry. Alarmy. Tryby działania.
28
Analiza obiektowa. Analiza wymagań. Przypadki użycia. Scenariusze.
Analiza i identyfikacja przedmiotu. Relacje, atrybuty i zachowania. Diagramy.
29
Budowa respiratora i podstawowe zasady działania
30
Schemat respiratora
31
Parametry, które są monitorowane
stężenie O2 w zainspirowanej kończynie oddychającej obwodu (fi O2) stężenie CO2 w wygasłej kończynie oddychającej obwodu (et CO2) Strumień ciśnienia wydychanego przez pacjenta sensor ciśnienia obwodu oddychającego
32
Parametry opisujące respirator:
33
Ważniejsze elementy Istota sensorów.
Zagrożenia występujące w żelaznych płucach. Alarmy. Tryby działania.
34
Zestawienie typowych alarmów :
35
Panel sterowania respiratora
36
Analiza obiektowa. Analiza wymagań. Przypadki użycia. Scenariusze.
Analiza i identyfikacja przedmiotu. Relacje, atrybuty i zachowania. Diagramy.
37
Przypadki użycia:
38
Use case
39
Scenariusze
40
Wyniki błędnego podejścia
41
Identyfikacja przedmiotu:
Analiza przedmiotu. Diagramy klas. Identyfikacja przedmiotu: · wentylator · czujnik O2 · czujnik CO2 · czujnik ciśnienia · wyświetlacz · ruchomą gałkę · przyciski · CO2 pochłaniacz · zawór kontroli ciśnienia gazu
42
Elementy danych (zmierzonych lub kontrolnych)
Wizualne elementy GUI · ciąg znaków etykiety · ciąg znaków wartości · ciąg znaków alarmy · ukryty wskaźnik elementu · ruchomą gałkę Elementy danych (zmierzonych lub kontrolnych) · przepustowość · wydolność (przepustowość czasowa) · Wydajność inspiratorów · I:E (stosunek) · Tempo respiracji · Ciśnienie powietrza · fiO2 · etCO2 · Alarm
43
Odpowiedzialności, atrybuty i zachowanie się.
44
Model analizy :
45
Współdziałanie klas i analiza scenariusza.
46
Automatyczna weryfikacja modeli UML
Krótka charakterystyka wybranych narzędzi Case
47
Dlaczego weryfikacja modeli jest ważna ?
Nowe podejścia do tworzenia oprogramowania takie jak np. MDA uwydatniają użycie modeli UML Szczególnie istotne w przypadku systemów krytycznych, w których życie ludzkie lub drogie systemy mogą być narażone na niebezpieczeństwo Im szybciej nastąpi wykrycie wady tym lepiej Wysokie koszty popełnionych błędów we wstępnych fazach, a szczególnie w fazie modelowania
48
Dlaczego tego typu narzędzia nie cieszą się dużą popularnością ?
Wiele narzędzi CASE jest zorientowanych na bardzo specyficzne podejście do tworzenia oprogramowania Wysokie koszty (licencje, szkolenia, itp.) Nie spełniają często nierealnych wymagań użytkowników
49
PVF – Property Verification Framework
Wspiera wykrywanie błędów w modelach UML Użytkownik ma możliwość sprawdzenia modelu pod względem pożądanych właściwości Jednostki sprawdzające wykorzystują predefiniowany zbiór właściwości, które ma spełniać model Generowane są sugestie, które mogą pomóc w wyeliminowaniu ewentualnych błędów Jedną z najważniejszych cech PVF jest jego modularna budowa, umożliwiająca jego włączanie do istniejących już narzędzi CASE
50
Zakładane ulepszenia PVF
Zaimplementowanie właściwości, które jeszcze nie są zaimplementowane Zidentyfikowanie nowych właściwości dla map stanów Ulepszenie interfejsu użytkownika, tworzenie raportów w postaci HTML
51
Projekt RIVIERA Projekt RIVIERA ma za zadanie stworzenie struktury umożliwiającej tworzenie narzędzi CASE Trzy główne cele projektu: Służyć jako środowisko do symulacji i przetwarzania modeli Wspomóc weryfikacje własności modelu Dostarczyć środowiska umożliwiające transformacje pod wpływem pewnych sugestii
52
Krótka charakterystyka wybranych narzędzi CASE
I-Logix Raphsody I-Logix Statement Magnum Together PhD DMS Visual Paradigm for UML Community Edition 3.1 Metamill 3.1 Visual UML CASE Tool Rational Rose Argo
53
I-Logix Raphsody Umożliwia tworzenie współbieżnych regionów
Pozwala na sprawdzenie wielu ciekawych właściwości np. takich jak: tworzenie pętli (livelocks), izolowanych stanów Niestety wiele interesujących własności nie może być zweryfikowanych przy użyciu tego narzędzia Generowany kod XMI nie jest do końca zgodny z innymi narzędziami
54
I-Logix Statement Magnum
Wykorzystuje kombinacje tradycyjnych notacji graficznych w połączeniu z niektórymi diagramami UML Możliwość symulacji nieukończonych modeli Możliwość generowania kodu i dokumentacji z modelu Umożliwia specyfikowanie współbieżnych stanów Współpracuje z mapami stanów Harel’a, które nie są identyczne z mapami UML
55
Together Potężne środowisko wspierające tworzenie modeli UML i generowanie kodu Dostarcza wielu udogodnień Dodanie klasy do diagramu, sprawia, że natychmiast pojawia się w kodzie Możliwość analizowania tworzonych modeli przy użyciu wbudowanych komponentów metrycznych Nie ma możliwości definiowania stanów współbieżnych
56
Teza PhD Wysunięta przez Porres’a Translacja do języka PROMELA
Użycie modelu sprawdzającego SPIN Możliwe tłumaczenie rezultatu SPIN do diagramu sekwencji UML
57
The DMS Software Reenginering Toolkit
Narzędzie umożliwiające automatyczną analizę programu, jego modyfikacje W skład zestawu narzędzi wchodzą między innymi: kompilator, parser, analizator semantyczny Stworzony do pracy z systemami zawierającymi kilka milionów linii kodu źródłowego poprzez dziesiątki tysięcy plików źródłowych
58
Visual Paradigm for UML Community Edition 3.1
59
Sprawdzanie składni projektu
Sytuacje jakie zostaną wyłapane przez kontrolera składni: wielokrotne dziedziczenie klasa realizuje inny interfejs interfejs rozszerza klasę A class is set to be final and interface at the same time.
61
Sprawdzanie składni klasy
62
Automatyczna generacja kodu projektu
63
Automatyczna generacja kodu projektu
64
VPUML – weryfikacja modelu
Inżynieria wsteczna Istniej możliwość tworzenia modelu UML z kodu źródłowego, jak również wprowadzając zmiany do wcześniej automatycznie generowanego kodu. VPUML – weryfikacja modelu Dostarcza możliwość sprawdzenia modelu pod kontem zgodności ze specyfikacją składni UML.
65
Metamill 3.1 Visual UML CASE Tool
Metamill jest narzędziem do wizualnego modelowania oprogramowania. Wspiera wszystkie diagramy UML. Posiada opcję automatycznej generacji kodu C++, ANSI C, Java oraz C#. Metamill jest prostym narzędziem dającym możliwość tworzenia projektu systemu, nie daje jednak żadnych możliwości sprawdzania poprawności modelu. Automatyczna generacja kodu, jak i inżynieria wsteczna używa specjalnych znaczników wewnątrz których kod nie jest zmieniany.
67
RationalRose Sprawdzanie składni:
- zapobieganie pętlom w dziedziczeniu - naruszenia dostępu klas - detekcja rozbieżności pomiędzy klasą, a obiektem - detekcja rozbieżności pomiędzy komunikatami, a operacjami Automatyczna generacja kodu Inżynieria wsteczna Automatyczna generacja IDL oraz DDL
68
Rational: Weryfikacja modelu CheckModel - sprawdza zgodność modelu wynik zapisany w Log
69
Weryfikacja diagramów współdziałania - wskazuje operacje bez dołączonego komunikatu
70
Weryfikacja diagramów współdziałania - wskazuje obiekty bez wyspecyfikowanej klasy
71
Weryfikacja diagramów klas - wskazuje naruszenia dostępu pomiędzy klasami z różnych pakietów (przy braku relacji importu pomiędzy pakietami)
72
Rational ma jednak wady.
Pozwala na tworzenie modeli niepoprawnych. Np. tworzenie tranzycji ze stanu początkowego z różnymi stereotypami, lub wyrażeniami. Generacja kodu klasy pakietu modułu Komponentu W kodzie wprowadzone znaczniki ograniczające działanie automatu do obszarów poza nimi.
73
Argo open source Java sprawdza model (to do), krytykuje
generuje kod źródłowy (brak inżynierii wstecznej) Java, C++, Php, C#
74
Argo Sprawdza model podając wskazówki co należy jeszcze zrobić zważając na podstawowe zasady modelowania Np. dodawanie nazw do nie nazwanych elementów, stanów początkowych, asocjacji, sugestie klasyfikowane Jednakże: umożliwia tworzenie błędnych modeli, np. dwa stany początkowe podpisanie wyrażeniem tranzycji wychodzącej ze stanu początkowego pętle w dziedziczeniu
Podobne prezentacje
© 2024 SlidePlayer.pl Inc.
All rights reserved.