1 / 74

Systemy czasu rzeczywistego

Systemy czasu rzeczywistego. Rafał Krawczyk Wacław Kowalski Maciej Stojko Tomasz Żyguła. Plan prezentacji. Część 1: Zastosowanie podejścia środowiskowego UML w modelowaniu struktury systemu czasu rzeczywistego Część 2: Automatyczna weryfikacja modeli UML. Plan prezentacji (cz.1).

Télécharger la présentation

Systemy czasu rzeczywistego

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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. 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. 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. 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

More Related