Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki. Katedra Automatyki. Rozprawa doktorska

Transkrypt

1 AKADEMIA GÓRNICZO HUTNICZA IM. STANISŁAWA STASZICA Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki Katedra Automatyki Rozprawa doktorska Modelowanie i systematyczna analiza poprawności behawioralnych artefaktów z wykorzystaniem algebry procesów Praca pod kierunkiem: Autor: prof. dr hab. inż. Tomasz Szmuc mgr inż. Rafał Mrówka Kraków 2007

2 Składam serdeczne podziękowania Panu prof. dr hab. inż. Tomaszowi Szmucowi za ogromne wsparcie oraz cenne wskazówki, które umożliwiły mi napisanie tej pracy. 2

3 Zawartość 1. Wstęp Wprowadzenie do przedmiotu pracy badawczej Motywacje i cele rozprawy Zakres oraz zawartość pracy Przegląd metod formalnych w inżynierii oprogramowania systemów czasu rzeczywistego Wprowadzenie Logiki temporalne Logika CTL* Computation Tree Logic Logika CTL oraz LTL Własność sprawiedliwości Weryfikacja modelowa Model checking w logice CTL Własność sprawiedliwości Weryfikacja modelowa w logice LTL Weryfikacja modelowa w logice CTL* Język rachunku μ Sieci Petriego Sieci miejsc i przejść Sieci kolorowane Wykonanie sieci kolorowanej Czasowe sieci Petriego Techniki analizy własności Podsumowanie Metodyka ROPES Wprowadzenie Pojęcia i definicje Etapy projektu Cykle życia projektu Podejście kaskadowe wodospadowe Podejście iteracyjne Prototypowanie Harmonogramowanie i estymacja Makro cykle w metodologii ROPES

4 3.6 Analiza Analiza wymagań Analiza systemowa Analiza obiektowa Projekt techniczny Projekt architektury Projekt realizacji Projekt szczegółowy Implementacja Aktywności i artefakty Etap testów Aktywności i artefakty Wdrożenie i utrzymanie Aktywności oraz artefakty Metamodel encji Podejście pseudo iteracyjne Podsumowanie Zastosowanie języka LOTOS w inżynierii oprogramowania Wprowadzenie Matematyczne podstawy języka LOTOS Podstawowa algebra procesów Algebra procesów ACP Założenia języka LOTOS Notacja LOTOS Basic LOTOS Full LOTOS Podsumowanie Semantyka diagramu stanów UML Wprowadzenie Specyfikacja diagramów stanów w języku UML Pojęcie stanu oraz przejścia Pseudo stany Definicja diagramu stanów w języku UML Podsumowanie

5 6. Wprowadzenie metod formalnych do ROPES Wprowadzenie Translacja maszyny stanowej płaskiej Translacja hierarchicznej maszyny stanowej Hierarchia procesów Implementacja hierarchii procesów w języku LOTOS Regiony ortogonalne stanów typu AND Modelowanie przejść granicznych oraz przejść warunkowych Modelowanie pseudo stanów fork, join oraz condition Podsumowanie Weryfikacja własności modeli systemu Wprowadzenie Poprawność procesu w kontekście relacji modeli Relacje modeli równoważności Relacja bisymulacji Słaba bisymulacja Obserwacyjna kongruencja Relacje typu preorder Silna symulacja Relacja słabej symulacji i bezpieczeństwa Metody weryfikacji relacji pomiędzy modelami Metody weryfikacji modelowej Semantyka wyrażeń AF rachunek μ Przykłady własności Podsumowanie Proces specyfikacji SCR w metodyce f ROPES Wprowadzenie Zakres metodologii f ROPES Realizacja procesu f ROPES Przykładowy projekt realizowany zgodnie z f ROPES Zasady funkcjonowania układu wtryskego w silnikach spalinowych Proces projektowy oprogramowania sterownika układu wtryskowego MDI Iteracja Iteracja

6 8.4.5 Iteracja Analiza parametrów czasowych Podsumowanie Środowisko projektowo programistyczne Wprowadzenie Interfejsy Rhapsody Pakiet CADP Projekty środowiska IDE Projekt 1: Rhapsody VBA Projekt 2: Integracja XMI Projekt 3: f ROPES Workbench Podsumowanie Analiza ekonomiczna zastosowania metodyki f ROPES Wprowadzenie Analiza jakościowa Wprowadzenie do zagadnienia niezawodności oprogramowania Metody przeprowadzania testów maszyn stanowych Testy heurystyczne Analiza ilościowa Etap analizy Etap projektu technicznego Etap testów Wpływ f ROPES na całkowity koszt projektu Podsumowanie Zakończenie Literatura Spis ilustracji i tabel

7 1. Wstęp 1.1 Wprowadzenie do przedmiotu pracy badawczej Obecnie metody formalne w inżynierii oprogramowania po długim okresie rozwoju osiągnęły dojrzałość dostateczną, aby je zastosować w procesie rozwoju oprogramowania dużych oraz skomplikowanych systemów czasu rzeczywistego tj.: kontrola ruchu lotniczego, kolejowego, transportowego, systemu sterowania kanałami komunikacyjnymi, elektrowniami, itd. Fundamentalne podstawy metod formalnych są znane i rozwijane już od lat 60 XX wieku i pojawiły się praktycznie w tym samym okresie, co mikrokomputery. Pierwsze problemy podczas tworzenia oprogramowania jawnie wykazały konieczność stosowania narzędzi, które wspomagałby specyfikacje, projektowanie oraz weryfikacje tworzonego oprogramowania. Obecnie większość instytucji związanych z wytwarzaniem oprogramowania jest świadoma konieczności stosowania oraz dalszego rozwoju metod formalnych. Wbrew powszechnej opinii wykorzystanie metod formalnych nie ogranicza się do systemów czasu rzeczywistego. Coraz częściej wykorzystuje się je także w innych obszarach inżynierii oprogramowania np.: specyfikacji protokołów komunikacyjnych, konstrukcji systemów krytycznych ze względu na bezpieczeństwo, analizie sieci telekomunikacyjnych. W bardzo ważnym obszarze bezpieczeństwa systemów informatycznych Europejski ITSEC (Information Technology Security Evaluation Criteria) wprowadził konieczność stosowania metod formalnych w procesie ewaluacji oprogramowania dla czterech poziomów bezpieczeństwa (z siedmiu). Dodatkowo standard ISO od roku 1999 rekomenduje zastosowanie metod formalnych powyżej piątego poziomu bezpieczeństwa. Pomimo długiej historii rozwoju oraz bardzo wielu znaczących prac naukowych w zakresie wykorzystania metod formalnych w inżynierii oprogramowania, nadal pojawiają się znaczące problemy z ich zastosowaniem dla rzeczywistych systemów czasu rzeczywistego. Chcąc wymienić główne przyczyny takiego stanu rzeczy, koniecznie należy wskazać na: złożoność systemów, które podlegają specyfikacji, a następnie są wytwarzane oraz weryfikowane i przekazywane do użytkowania, brak ustandaryzowanego procesu wytwarzania systemów informatycznych, brak lub niedojrzałość narzędzi wspomagających wytwarzanie oprogramowania, duże koszty związane z zastosowanie metod formalnych. Obszernym zagadnieniem, który jest bardzo często pomijany w pracach dotyczących inżynierii oprogramowania jest analiza ekonomiczna związana z zastosowaniem w procesie wytwarzania metod formalnych. Brak jest głębszych analiz związanych z oceną realnych kosztów związanych z zastosowaniem wybranych metod oraz ich wpływ na TCO całego rozwiązania. Obecnie szacuje się, że koszty związane z testowaniem systemów informatycznych wytwarzanych w USA to 59,5 miliardów dolarów (źródło: The Economist "Building a Better Bug Trap", 19 czerwiec, 2003). Celowym wydaje się więc ocena w jakim stopniu metody formalne mogą zmniejszyć czas, a zatem także pieniądze związane z procesem testowania oprogramowania. Oczywistym wydaje się, że szerokie zastosowanie metod formalnych w długim horyzoncie czasowym znacząco zmniejszy koszty wytworzenia oprogramowania poprzez redukcję kosztów w procesie testowania. Oszczędności te mogą być jedynie osiągnięte poprzez odpowiednie inwestycje zwiane z popularyzacją i wprowadzeniem do przemysłowego zastosowania metod formalnych. Wydaje się ponadto, że oszacowanie kosztów i zysków wprowadzenia metod formalnych pozwoli usunąć szereg mitów (również tych przeciw) związanych z ekonomicznym aspektem ich stosowania. 7

8 1.2 Motywacje i cele rozprawy Celem niniejszej pracy jest propozycja zastosowania metod formalnych w procesie wytwarzania oprogramowania czasu rzeczywistego w oparciu o metodykę ROPES. W procesie wytwarzania oprogramowania stosowana będzie algebra procesów jako język formalnego opisu. Wybór formalizmu był podyktowany przede wszystkim: możliwością wykorzystania implementacji algebry procesów w postaci języka LOTOS, standaryzacją (ISO) języka LOTOS, dostępnością funkcjonalnych narzędzi wspomagających specyfikację systemów w języku LOTOS, szerokim wachlarzem metod weryfikacji oraz walidacji specyfikacji systemów bazujących na własnościach algebry procesów. Głównym celem pracy jest: Opracowanie metodyki wytwarzania systemów czasu rzeczywistego w oparciu o metodologię ROPES z wykorzystaniem języka LOTOS oraz metod formalnych bazujących na formalizmie algebry procesów. Zakłada się, iż proponowane w niniejszej pracy rozszerzenie metodologii ROPES o zastosowanie metod formalnych umożliwi: 1. Przejście modeli behawioralnych systemu do postaci formalnej. 2. Weryfikację poprawności kolejnych kroków procesu wytwarzania oprogramowania. 3. Badanie zadanych własności formalnego modelu systemu. 4. Opracowanie zintegrowanego środowiska projektowego, umożliwiającego praktyczne zastosowanie metod formalnych. 5. Zmniejszenie całkowitych kosztów wytwarzania oprogramowania poprzez wcześniejszą identyfikację defektów oprogramowania Weryfikacja powyżej postawionych tez będzie realizowana w następujących krokach: 1. Opracowanie translacji behawioralnej specyfikacji systemu w postaci diagramu stanów UML do modelu opisywanego językiem LOTOS. 2. Umiejscowienie wykorzystania algebry procesów w podejściu ROPES. Wprowadzenie metodyki f ROPES. 3. Analizę oraz wskazanie relacji równoważności umożliwiających weryfikację poprawności modeli przy przejściu na niższe poziomy hierarchii specyfikacji oraz pomiędzy kolejnymi iteracjami metodyki ROPES. 4. Wprowadzenie metody systematycznego badania własności modeli formalnych systemu z wykorzystaniem technik weryfikacji modelowej (model checking). 5. Opracowanie metodyki formalnej analizy poprawności specyfikacji behawioralnej w fazach analizy i projektowania oprogramowania czasu rzeczywistego. 6. Przygotowanie specyfikacji środowiska projektowo programistycznego wspierającego praktyczne zastosowanie f ROPES. 7. Analiza ekonomiczna zastosowania f ROPES oraz jej wpływ na parametry budżetu projektów informatycznych. W pracy zaproponowano także inne możliwe zastosowania metodyki f ROPES. Jedną z bardzo ciekawych koncepcji jest wprowadzenie metod formalnych do podejścia Executable UML. Wydaje się to interesującym zastosowaniem praktycznym proponowanej metodyki w procesie wytwarzania oprogramowania bazującego na paradygmacie Model Driven Architecture (MDA). Propozycja opiera się na 8

9 możliwości zastosowania translacji maszyny stanowej do specyfikacji w języku LOTOS, a następnie symulacji oraz analizy wybranych własności modelu, niezależnie od języka implementacji systemu. W pracy przedstawiona zostanie analiza finansowa wprowadzenia do przemysłowego procesu wytwarzania oprogramowania proponowanej metodyki f ROPES. Pozwoli to na realną ocenę możliwości szerokiego jej zastosowania. Zostaną także przedstawione szacunkowe korzyści w wymiarze finansowym, możliwe do osiągnięcia z wykorzystaniem f ROPES. Pozwoli to ocenić aspekt ekonomiczny proponowanego podejścia. W celu zwiększenia możliwości wykorzystania i tym samym praktycznej weryfikacji opracowanej metody podano także specyfikację interfejsu pomiędzy dostępnymi obecnie na rynku narzędziami wspierającymi proces wytwarzania oprogramowania: CADP oraz Rhapsody. Dzięki zastosowaniu wspomnianego interfejsu, proces translacji oraz przenoszenia modeli systemów może być całkowicie automatyczny. Konstrukcja tego interfejsu będzie przedmiotem planowanych prac i wydaje się, że w niedługim czasie interfejs ten zostanie zaimplementowany, co umożliwi budowanie odpowiednich zintegrowanych środowisk wspomagających wytwarzanie oprogramowania. 1.3 Zakres oraz zawartość pracy Struktura pracy została skonfigurowana pod kątem osiągnięcia zaplanowanego celu. Można w niej wyróżnić łącznie ze wstępem i zakończeniem łącznie jedenaście rozdziałów, każdy z nich posiada krótkie streszczenie. Poniżej scharakteryzowano zawartość każdego z rozdziałów, w celu przybliżenia czytelnikowi zawartości rozprawy. Rozdział 1 zwiera wstęp oraz wprowadzenie do tematyki pracy. Przedstawiono główne motywacje oraz cele pracy. Opisano oczekiwane wyniki badań oraz zakres przedstawionych tez. Rozdział 2 zawiera przegląd najpopularniejszych metod formalnych stosowanych obecnie w inżynierii oprogramowania. W rozdziale tym przedstawiono podstawy teoretyczne z zakresu zastosowania metod formalnych w inżynierii oprogramowania. Ze względu na charakter pracy nie ograniczano się jedynie do formalizmu wykorzystanego w badaniach autora, lecz przedstawiono również inne, które określają kontekst podjętej decyzji. Rozdział 3 prezentuje zagadnienia związane z metodyką ROPES, ze szczególnym uwzględnieniem elementów związanych ze specyfikacją systemów czasu rzeczywistego oraz podejściem Model Driven Architekture. Przedstawiono teoretyczne zagadnienia związane z prowadzeniem projektów informatycznych z wykorzystaniem metodyki ROPES. Opisano cykl życia produktu oraz jego powiązanie z fazami projektu. Powyższe zagadnienia zostały uzupełnione licznymi przykładami. Rozdział 4 stanowi krótkie wprowadzenie w zagadnienia związanego z algebrą procesów oraz z językiem LOTOS. Ze względu na stosunkowo obszerną literaturę dotyczącą tej algebry, w rozdziale przedstawiono jedynie najważniejsze informacje dotyczące wykorzystania tego języka w zakresie niniejszej pracy. Opisano także elementy środowiska CADP, które były wykorzystywane podczas prac badawczych. Bardziej szczegółowe rozważania można znaleźć w [8]. Rozdział 5 zawiera wprowadzenie do zagadnień języka UML związanych ze specyfikacją dynamiki systemu. Przedstawiono elementy języka UML umożliwiające specyfikację behawioralną za pomocą: diagramów stanów, aktywności oraz kolaboracji. Powyższe informacje uzupełniono o zagadnienia związane z wprowadzeniem ograniczeń czasowych dla systemów czasu rzeczywistego. Rozdział 6 prezentuje główne założenia oraz algorytmy związane z translacją maszyny stanowej do specyfikacji w języku LOTOS. Dodatkowo algorytm translacji uzupełniono o konstrukcje związane z 9

10 hierarchizacją modelu systemu. Następnie przedstawiono relacje pomiędzy poszczególnymi poziomami hierarchii modelu. Rozdział 7, bazując na wynikach prezentowanych w rozdziale 6, przedstawia szereg metod weryfikacji poprawności specyfikacji modeli systemów z zastosowaniem formalizmu algebry procesów. Podstawowe własności modeli będą weryfikowane na podstawie relacji bisymulacji oraz preorder. Dodatkowo rozważano zagadnienia związane z żywotnością oraz bezpieczeństwem systemu. Bazując na zaprezentowanych relacjach bisymulacji przedstawiono także metodę weryfikacji zgodności modeli w poszczególnych iteracjach ścieżki projektowej. Rozdział 8 przedstawia główną ścieżkę projektową z wykorzystaniem elementów prezentowanych w poprzednich rozdziałach. Zmodyfikowana o elementy metod formalnych metodyka ROPES nazwana została f ROPES. Proces projektowy uzupełniono o przykład prezentujący wykorzystanie f ROPES w procesie wytwarzania oprogramowania. Rozdział 9 zawiera specyfikację środowiska projektowo programistycznego wspierającego metodykę f ROPES. Przedstawiono zastosowanie dwóch dojrzałych narzędzi: CADP oraz Rhapsody oraz specyfikację interfejsu pomiędzy nimi. Przedstawiona specyfikacja zawiera także projekt oprogramowania translacyjnego ze specyfikacji Rhapsody do CADP. Rozdział 10 przedstawia analizę kosztową związaną z wdrożeniem metodyki f ROPES w procesie produkcyjnym wytwarzania oprogramowania. Podano także analizę korzyści związaną z wykorzystaniem proponowanej metodyki. Rozdział 11 zawiera podsumowanie pracy oraz wskazuje na dalsze kierunki rozwoju w zakresie poruszanej tematyki. 10

11 2. Przegląd metod formalnych w inżynierii oprogramowania systemów czasu rzeczywistego 2.1 Wprowadzenie Terminu metoda używamy do opisania procesu zmierzającego do osiągnięcia wyznaczonych celów. W inżynierii oprogramowania celem jest stworzenie programu komputerowego, realizującego zadaną funkcjonalność oraz posiadającego wyznaczone parametry jakości. Własność formalności metody realizowana jest poprzez precyzyjne określenie, najczęściej przy wykorzystaniu pojęci i definicji matematyki, sposobu realizacji zadanego celu. Należy jednak zauważyć, iż obecnie metody formalne nadal są w fazie budowy, zwłaszcza w zakresie inżynierii oprogramowania. Metody te w większym stopniu dostarczają wsparcia w postaci narzędzi modelujących lub dedukcyjnych, aniżeli spójnej metodologii procesu wytwarzania oprogramowania. Dlatego też wydaje się bardziej adekwatne stosowanie terminu technik formalnych, a nie metod. Niemniej jednak termin metody formalne odzwierciedla cel, który przyświeca poszczególnym badaczom dziedziny opracowanie metodologicznych podstaw dla formalnego prowadzenia procesów inżynierii oprogramowania. Konsekwencje wystąpienia defektów w oprogramowaniu nie ograniczają się tylko do przywrócenia działa systemu. W domenie systemów czasu rzeczywistego (transport, elektrownie, systemy sterujące, systemy podtrzymywania życia, itd.) skutki defektów mogą dotyczyć ludzkiego zdrowia/życia. Jednakże w większości przypadków kosztem bezpośrednim wystąpienia błędów w oprogramowaniu są pieniądze np. miliardy dolarów kosztowała usterka oprogramowania przełączników sieciowych firmy AT&T [46], czy katastrofa rakiety Ariane 5 [46]. Te oraz wiele innych przykładów pokazuje jak ważna jest wczesna detekcja defektów oprogramowania, co w konsekwencji prowadzi do problemu ścisłej i niezawodnej specyfikacji systemu, czyli takiej, która: ściśle odpowiada wymaganiom stawianym projektowanemu systemowi, jest spójna. Metody formalne koncentrują się przede wszystkim na drugim wymaganiu spójności. Dzięki wprowadzeniu formalnej specyfikacji systemu oraz rygorystycznym procesie wytwarzania oprogramowania bazującym na tej specyfikacji, możemy znacząco ograniczyć liczbę defektów występujących w oprogramowaniu. Stosowanie metod formalnych w inżynierii oprogramowania posiada szereg niebagatelnych zalet, między innymi: umożliwia określenie formalnej semantyki, co pozwala na jednoznaczne zdefiniowanie poszczególnych wymagań systemowych oraz umożliwia wykorzystanie sprawdzonego aparatu matematycznego do dalszego przetwarzania specyfikacji, pozwala na formalne dowodzenie, iż tworzona specyfikacja spełnia założenia funkcjonalne i systemowe i dalej, że zaimplementowany program spełnia wymagania specyfikacji, stanowi bardzo dobrą podstawę do stworzenia narzędzi wspierających proces projektowy, pozwala na ograniczenie zaangażowania zasobów na etapie testów oraz utrzymania systemu, poprzez zmniejszenie ilości defektów oraz posiadanie dokładnej dokumentacji systemu (patrz rozdział 10). 11

12 Ostatni punkt ma niebagatelne znaczenie dla dalszego postępu w badaniach nad metodami formalnymi. Zgodnie z ostatnimi publikacjami [11] 2/3 całkowitych kosztów wykorzystania systemów informatycznych przypada na ich utrzymanie. Wobec powyższej sytuacji, konieczne jest zwiększenie świadomości inżynierów praktyków, iż zastosowanie metod formalnych może oznaczać znaczące obniżenie głównego czynnika kosztów systemów informatycznych, w tym także systemów czasu rzeczywistego. Obecnie możemy spotkać wiele typów metod formalnych, które możemy pogrupować na kilka kategorii. Większość metod można zakwalifikować do jednej z trzech kategorii wymienionych poniżej: bazujące na teorii najczęściej z zakresu matematyki (systemy przejść etykietowanych LTS, struktury Kripke, teoria zbiorów, algebry, rachunek λ, itd.), specyficzne dla danej dziedziny (zarządzanie danymi, bezpieczeństwo, protokoły, systemy czasu rzeczywistego), autorskie propozycje lub warianty powyższych kategorii wprowadzone przez grupy użytkowników, zespoły badawcze, itd. W niniejszym rozdziale skupimy się na przedstawieniu trzech metod formalnych, które można zakwalifikować do pierwszej kategorii. Będą to: logiki temporalne i skojarzone z nimi techniki weryfikacji modelowej (model checking) oraz sieci Petriego. Wybór powyższych formalizmów nie jest przypadkowy. Omawiane metody wraz z algebrą procesów posiadają możliwość reprezentacji modelu systemu, którą można sprowadzić do tej samej postaci struktury Kripke. Model systemu opisywany z zastosowaniem algebry procesów, czy też sieci Petriego może być przedstawiony bezpośrednio w postaci grafu etykietowanego, który właściwie jest strukturą Kripke modelem dla logik temporalnych. Fakt ten pozwala na dowolne przejścia pomiędzy poszczególnymi formalizmami, w zależności od aktualnie badanych własności modelu. Zagadnienia związane z algebrą procesów zostaną omówione w osobnym rozdziale poświęconym stosowanemu w pracy językowi LOTOS. 2.2 Logiki temporalne Logika temporalna jest formalizmem służącym do opisywania sekwencji przejść pomiędzy stanami w systemach reaktywnych. W logice temporalnej modelem w postaci ogólnej jest struktura typu drzewo, która specyfikuje następstwo zdarzeń (stanów). Dla bardzo szczególnej interpretacji może to być reprezentacja momentów czasowych, jednak w zasadzie jest to specyfikacja pewnego porządku stanów, natomiast czas nie jest wprowadzany explicite. Budowanie formuł w takiej logice dotyczy zatem 2 obszarów: określania właściwości poszczególnych (podzbiorów) stanów wyrażanych w terminach klasycznego rachunku zdań (predykatów) oraz specyfikacji własności względem (wzdłuż) ścieżek drzewa definiowanych z zastosowaniem tzw. operatorów temporalnych (uwzględniających wspomniane następstwo stanów). Poszczególne rodzaje logik temporalnych różnią się postacią modelu oraz paletą operatorów temporalnych. Poniżej przedstawiono charakterystyki najważniejszych rodzajów logik temporalnych Logika CTL* Computation Tree Logic Koncepcja logiki CTL* bazuje na własnościach tzw. drzew obliczeniowych (stąd nazwa). Drzewo obliczeniowe jest tworzone poprzez oznaczenie jednego ze stanów struktury Kripke [33] lub grafu przejść jako stanu początkowego, a następnie rozwinięcie danej struktury do nieskończonego drzewa stanów osiągalnych z wybranym wcześniej stanem początkowym. Proces ten przedstawiono na rysunku

13 Drzewo obliczeniowe przedstawia wszystkie możliwe przejścia, rozpoczynając od stanu początkowego. Wyrażenia logiki CTL* składają się z operatorów temporalnych oraz kwantyfikatorów ścieżki. Kwantyfikatory ścieżki są wykorzystywane do opisu struktury gałęzi w drzewie obliczeniowym. Wykorzystuje się dwa takie operatory: A określa dla wszystkich ścieżek obliczeniowych oraz E dla niektórych ścieżek obliczeniowych. Powyższe kwantyfikatory wykorzystuje się w poszczególnych stanach w celu określenia, czy wszystkie ścieżki wychodzące z danego stanu lub tylko niektóre z nich, posiadają daną własność. Operatory temporalne opisują własności ścieżek drzewa. W logice CTL* dostępnych jest pięć takich operatorów: Rys Tworzenie drzewa obliczeń X ( następnym razem ) wymaga, aby dana własność była zachowana także w następnym stanie ścieżki. F ( możliwość lub kiedyś w przyszłości ) operator wykorzystywany do określenia spełnialności danego warunku w którymś z kolejnych stanów ścieżki. G ( zawsze lub globalnie ) wymaga, aby dana własność była spełniona dla każdego stanu ścieżki. U ( aż do ) operator wykorzystuje dwie własności. Operator wymaga, aby któryś ze następnych stanów na ścieżce spełniał drugą własność oraz aby każdy stan poprzedzający spełniał własność pierwszą. R ( zwolnij ) jest logicznym przeciwieństwem operatora U. Operator wymaga, aby druga własność była spełniona przez wszystkie stany poprzedzające stan, który spełnia drugą własność. Wyróżniamy dwa typu wyrażeń w logice CTL*: formuły stanu (prawdziwe w danym stanie) oraz formuły ścieżki (prawdziwe na danej ścieżce obliczeń). Oznaczmy przez AP zbiór nazw atomowych twierdzeń. Wtedy formuły stanów wyrażają następujące reguły syntaktyczne: Jeżeli p AP, wtedy p jest formułą stanu. Jeżeli f oraz g są formułami stanu, wtedy f, f g oraz f g sa formułami stanu. Jeżeli f jest formułą ścieżki, wtedy E f oraz A f są formułami stanu. Wyrażenia ścieżki tworzone są na podstawie dwóch reguł syntaktycznych: Jeżeli f jest formułą stanu, wtedy f jest także formułą ścieżki. Jeżeli f oraz g są formułami stanu, wtedy f, f g, f g, X f, F f, G f, f U g oraz f R g są formułami ścieżki. 13

14 Semantykę logiki CTL* zdefiniujmy w odniesieniu do struktury Kripke [12]. Definicja 2.1 Strukturą Kripke M nazywamy trójkę (S, R, L), gdzie: S jest zbiorem stanów. R S S stanowi relację przejść, takich, że s S s S : (s,s ) R. L: S S AP jest funkcją etykietowania stanów, bazującą na zbiorze atomowych twierdzeń, prawdziwych w danym stanie. Ścieżką w M będziemy nazywać nieskończoną sekwencję stanów π=s 0,s 1,., takich,że i 0, (s i, s i+1 ) R. Ścieżkę można kojarzyć z nieskończoną gałęzią w drzewie obliczeniowym, odpowiadającemu strukturze Kripke. Będziemy oznaczać przez π i sufiks π rozpoczynający się w stanie s i. Jeżeli f jest formułą stanu, wyrażenie M, oznacza, że f jest spełniony w stanie s w strukturze M. Podobnie, jeżeli f jest formułą ścieżki, M, oznacza, że f jest spełniony wzdłuż ścieżki π. Oznaczenie struktury Kripke M można pominąć, jeżeli jej odniesienie wynika bezpośrednio z kontekstu. Relacja jest zdefiniowana następująco: Definicja 2.2 definiu Zakładając, że f 1, f 2 są formułami stanu oraz g 1, g 2 są formułami ścieżek, wtedy relację jemy następująco: ś ż, ż. 6. ż ś ż, ż 0, ,. 14. ż 0, 0, , ż. Warto zauważyć, iż operatory,, X, U oraz E są wystarczające do wyrażenia wszystkich innych formuł logiki CTL*. 14

15 2.2.2 Logika CTL oraz LTL Logika CTL* posiada wiele wersji, które różnią się przede wszystkim pojęciem czasu. Między innymi wyróżniamy logikę z czasem rozgałęzionym oraz z czasem liniowym. Rozróżnienie to sprowadza się do sposobu traktowania gałęzi drzewa obliczeniowego. W logice z czasem rozgałęzionym operatory temporalne działają na wszystkie ścieżki wychodzące z danego stanu, traktując je jako ścieżki możliwe. W przypadku logiki z czasem liniowym operatory temporalne opisują zdarzenia jedynie na pojedynczej ścieżce obliczeniowej. Logika CTL stanowi podzbiór logiki CTL*, w którym każdy z operatorów temporalnych X, F, G, U oraz R musza bezpośrednio poprzedzać kwantyfikatory ścieżki. Bardziej precyzyjnie, CTL jest podzbiorem CTL *, który uzyskujemy poprzez ograniczenie syntaktyki formuł ścieżek, używając następujących reguły: Definicja 2.3 Jeżeli f oraz g są formułami stanu, wtedy X f, F f, G f, f U g oraz f R g są formułami ścieżek. Logika temporalna czasu liniowego zawiera formuły, które posiadają strukturę A f, gdzie f jest formułą ścieżki, w której dozwolone są jedynie pod formuły stanów w postaci twierdzeń atomowych. Precyzyjnie mówiąc, formuły ścieżek logiki LTL ograniczają się do następujących reguł: Definicja 2.4 Jeżeli p AP, wtedy p jest formułą ścieżki. Jeżeli f oraz g są formułami ścieżek, wtedy f, f g, f g, X f, F f, G f, f U g oraz f R g są formułami ścieżki. Wymienione dotychczas logiki temporalne posiadają zróżnicowaną siłę ekspresji [12]. Przykładowo, logika CTL nie posiada formuły ekwiwalentnej wyrażeniu A(FG p) w logice LTL. Wyrażenie to opisuje własność dla każdej ścieżki, która zakłada, że istnieje stan, od którego p jest już zawsze prawdziwe. Podobnie logika LTL nie posiada ekwiwalentnej formuły AG(EF p) wyrażonej w logice CTL. Alternatywa dwóch wyrażeń A(FG p) AG(EF p) w logice CTL* nie może być wyrażona w logice CTL lub LTL. Logika CTL posiada dziesięć podstawowych operatorów: 1. AX oraz EX. 2. AF oraz EF. 3. AG oraz EG. 4. AU oraz EU. 5. AR oraz ER. Każdy z tych dziesięciu operatorów może być wyrażony za pomocą EX, EG oraz EU: 1. AX f = EX( f). 2. EF f = E [True U f]. 3. AG f = EF( f). 4. AF f = EG( f). 5. A[f U g] E[ g U ( f g)] EG g. 15

16 6. A[f R g] E[ f U g]. 7. E[f R g] A[ f U g]. Cztery z powyższych operatorów, które są używane najczęściej, zaprezentowano na rysunku 2.2. Dla łatwiejszego zrozumienia semantyki, ich działanie zobrazowano na rozwiniętych strukturach Kripke. Typowe formuły logiki CTL, wykorzystywane podczas weryfikacji skończenie stanowych systemów współbieżnych przedstawiono poniżej: EF(Start Ready) można przejść do stanu, który spełnia warunek Start, jednak nie może spełniać Ready, AG(Req AF Ack) jeżeli pojawi się żądanie, wtedy ewentualnie pojawi się potwierdzenie, AG(AF Enabled) propozycja Enabled jest spełniona nieskończenie długo, na każdej ścieżce, AG(EF Restart) z każdego stanu można przejść do stanu Restart. Wiele metod formalnych, w celu uniknięcia problemu eksplozji stanów, wprowadza rozumowanie złożone lub hierarchie abstrakcji. Logiki temporalne w tym zakresie są dużo bardziej restrykcyjne. W takich przypadkach wykorzystuje się najczęściej uniwersalne kwantyfikatory ścieżek. Ograniczenie CTL* do uniwersalnych kwantyfikatorów ścieżek nazywa się ACTL*. Natomiast takie samo ograniczenie CTL prowadzi do definicji logiki ACTL. W celu uniknięcia pośredniego stosowania kwantyfikatorów istnienia, wynikających z wykorzystania negacji, zakładamy, że formuły są przedstawiane w pozytywnej postaci normalnej. Negacja jest wprowadzana tylko do twierdzeń atomowych. W celu uniknięcia utraty siły ekspresji formalizmu, niezbędne jest stosowanie operatorów koniunkcji, alternatywy, U oraz R. Rys Podstawowe operatory CTL 16

17 Formuły AF AG a oraz AF AX a są przykładami wyrażeń ACTL. Wyrażeń tych nie można przedstawić za pomocą operatorów LTL. Ponieważ ACTL jest podzbiorem CTL, ACTL i LTL nie są kompatybilne. Co więcej, ACTL* jest bardziej ekspresywne aniżeli LTL Własność sprawiedliwości Sprawiedliwość jest ważną własnością systemów informatycznych. Obrazowo własność ta oznacza, że wszystkie ścieżki obliczeń są równomiernie wykonywane. Przykładowo załóżmy, że weryfikujemy asynchroniczny obwód z arbitrem i wymagamy, aby rozważane były tylko te realizacje, w których arbiter nigdy nie ignoruje pojawiających się żądań. Własności takie nie można wyrazić za pomocą podstawowej logiki CTL. W celu wyrażenia własności sprawiedliwości przy użyciu logiki CTL, należy zmodyfikować nieznacznie jej semantykę. Ograniczeniem sprawiedliwości może być arbitralnie wyznaczony zbiór stanów, zwykle opisanych przez formuły logiki. Jeżeli ograniczenie sprawiedliwości jest interpretowane jako zbiór stanów, wtedy ścieżka spełniająca własność sprawiedliwości musi zawierać nieskończenie często elementy ze zbioru stanów sprawiedliwych. Wykorzystując formułę CTL, można powiedzieć, że ścieżka jest sprawiedliwa, jeżeli ograniczenie jest spełnione nieskończenie często wzdłuż tej ścieżki. Kwantyfikatory ścieżki w logice są wtedy ograniczone do ścieżek sprawiedliwych. Formalnie możemy powiedzieć, że sprawiedliwą strukturę Kripke definiujemy jako: Definicja 2.5 Sprawiedliwą strukturą Kripe nazywamy czwórkę M=(S,R,L,F), gdzie S zbiór stanów, R relacja R: S S, L funkcja etykietująca oraz F 2 S jest zbiorem ograniczenia sprawiedliwości (warunek akceptacji Buchi ). Niech π = s 0, s 1, będzie ścieżką w M. Zdefiniujmy inf(π) = {s s=s i dla i 0}. Twierdzenie 2.1 Mówimy, że π jest sprawiedliwe, wtedy i tylko wtedy gdy dla P F, inf(π) P. Będziemy zapisywać s F f w celu oznaczenia, że formuła f jest prawdziwa w stanie s sprawiedliwiej struktury Kripke. Podobnie piszemy π F g w celu określenia, że formuła g jest prawdziwa wzdłuż ścieżki π. W definicji operatorów jedynie punkt 1, 5 oraz 6 klauzula ulega zmianie: 1. ś ż 4. ś ż, ż 5. ż ś ż, W celu zilustrowania wykorzystania własności sprawiedliwości rozważmy przykład niezawodnego protokołu komunikacyjnego. Zakładamy, że każdy kanał posiada ograniczenie sprawiedliwości określające jego niezawodność. Możliwość wyboru ograniczeń sprawiedliwości powiązanych z kanałem i pozwala na wybór zbioru stanów, spełniających warunek send i receive i. Ścieżka obliczeniowa jest sprawiedliwa wtedy i tylko wtedy, gdy każdy z kanałów, nieskończenie często nie wysyła komunikatu, ale także nie odbiera. 17

18 2.3 Weryfikacja modelowa Weryfikację modelową (model checking) można opisać w następujący sposób: dla danej struktury Kripke M=(S,R,L), reprezentującej skończenie stanowy system współbieżny oraz wyrażenia f logiki temporalnej opisującego żądaną specyfikację, szukamy stanów w S, spełniających warunek f:, Systemy współbieżne mają wyznaczone stany początkowe. System spełnia warunki specyfikacji f, pod warunkiem, że wszystkie stany początkowe należą do tego zbioru. Pierwszy, zaprezentowany poniżej algorytm rozwiązania problemu weryfikacji modelowej wykorzystuje bezpośrednią reprezentację struktury Kripke jako etykietowanego grafu skierowanego. W takim przypadku węzły grafu reprezentują stany ze zbioru S, łuki reprezentują relacje przejść R oraz etykiety odpowiadają funkcji L: S 2 AP Model checking w logice CTL Załóżmy, iż należy określić, które stany ze zbioru S spełniają formułę f logiki CTL. Algorytm będzie działał poprzez etykietowanie każdego stanu s funkcją label(s), określającą pod formuły f, które są prawdziwe w stanie s. Początkowo label(s) równa się L(s). Algorytm składa się z kilku iteracji tych samych kroków. Podczas i tej iteracji, przetwarzane są pod formuły z i 1 zagnieżdżonych operatorów CTL. Jeśli dana pod formuła zostanie przetworzona, wtedy następuje jej dodanie do etykiety wszystkich stanów, spełniający jej warunek. Po zakończeniu działania algorytmu, otrzymamy, ż. Przypomnijmy, że każda formułą CTL może być wyrażona za pomocą operatorów,, EX, EU oraz EG. Dlatego też w pośrednich krokach algorytmu wystarczającym jest, aby obsługiwać sześć przypadków, w zależności od tego, czy g jest twierdzeniem atomowym lub g posiada jedną z następujących postaci: f 1, f 1 f 2, EX f 1, E (f 1 U f 2 ) lub EG f 1. Dla wyrażeń f, stany spełniające ten warunek oznaczamy poprzez nie etykietowanie ich jako f. W przypadku formuły f 1 f 2, etykietujemy wszystkie stany spełniające warunek f 1 lub f 2. Wyrażenie EX f 1 powoduje etykietowanie każdego stanu, którego pewien następca posiada etykietę f 1.Etykietowanie formuł postaci g=e [f 1 U f 2 ] rozpoczynamy od odnalezienia wszystkich stanów z etykietą f 2. Następnie poruszając się wstecz relacji R grafu, poszukujemy wszystkie stany, które możemy osiągnąć na ścieżce, której każdy stan posiada etykietę f 1. Wszystkie tego typu stany powinny zostać opisane etykietą g. W przypadku wyrażeń postaci g=eg f 1 algorytm etykietowania bazuje na dekompozycji grafu na nietrywialne, ściśle spójne komponenty. Definicja 2.6 Ściśle spójnym komponentem C grafu G nazywamy maksymalny podgraf grafu G, w którym dowolny wierzchołek z C jest bezpośrednio połączony z każdym innym wierzchołkiem w C. C jest nietrywialny, jeżeli posiada więcej niż jeden wierzchołek, lub posiada jeden wierzchołek z przejściem do samego siebie. 18

19 Przez M oznaczmy graf uzyskany jako ograniczenie M poprzez usunięcie wszystkich stanów z S, które nie spełniają warunku f 1. Otrzymujemy wtedy M =(S,R,L ), gdzie S ={s S M, s f 1 }, R =R S S oraz L =L S. Należy zauważyć, iż w tym przypadku R nie musi być spójna. Stany, które nie posiadają przejść wyjściowych mogą zostać usunięte, jednak nie rozwiązuje to całkowicie problemu. Wykorzystuje się następujący lemat: Lemat 2.1, wtedy i tylko wtedy, gdy spełnione są następujące warunki: s S. Istnieje ścieżka w M od stanu s do t w nietrywialnym, silnie powiązanym komponencie C grafu (S, R ). Dowód lemtu 2.1 znaleźć można w pracy [12]. Algorytm etykietowania dla formuły g=eg f 1 wynika bezpośrednio z powyższego lematu. Konstruujemy ograniczoną strukturę M =(S,R,V), zgodnie z opisem powyżej. Dzielimy graf (S,R ) na ściśle powiązane komponenty wykorzystując np. algorytm Tarjan a [60]. Złożoność tego algorytmu wynosi O( S + R ). Następnie szukamy tych stanów, które należą do nietrywialnych komponentów. W kolejnym kroku poruszając się wstecz szukamy wszystkich stanów osiągalnych ze ścieżki, której stany posiadają etykietę f 1. Złożoności obliczeniowa tego algorytmu jest rzędu O( S + R ). W celu przetworzenia złożonego wyrażenia f w logice CTL, stosujemy algorytm etykietowania stanów dla każdej pod formuły f, rozpoczynając od najkrótszej i najbardziej zagnieżdżonej, a następnie przechodzimy do kolejnych pod formuł zewnętrznych. Podejście takie charakteryzuje się złożonością obliczeniową rzędu O( f *( S + R )). Twierdzenie 2.2 Istnieje algorytm o złożoności obliczeniowej O( f *( S + R )) określający czy dane wyrażenie f w logice CTL jest prawdziwe w stanie s struktury M=(S,R,L). W celu zilustrowania działania algorytmu weryfikacji modelowej dla logiki CTL, przedstawiony zostanie przykład opisujący działanie kuchenki mikrofalowej [12]. Rysunek 2.3 przedstawia strukturę Kripke przedstawiającą specyfikację behawioralną omawianego systemu. W celu przejrzystości wywodu każdy stan został opisany poprzez atomowe twierdzenia zarówno prawdziwe, jak również zanegowane. Etykiety łuków określają akcje, które wyzwalają przejście nie stanowią części struktury Kripke. Na wstępie zostanie zweryfikowana formuła CTL AG(Start AF Heat), która jest równoważna wyrażeniu EF(Start EG Heat) gdzie EF f oznacza E(true U f). Obliczenia rozpoczniemy od zbioru stanów, które spełniają formuły atomowe, a następnie przejdziemy do obliczenia kolejnych pod formuł. Niech S(g) oznacza zbiór wszystkich stanów oznaczonych przez pod formułę g. Wobec powyższego możemy zapisać: S(Start) = {2,5,6,7}. S( Heat) = {1,2,3,5,6}. 19

20 W celu wyznaczenia S(EG Heat) musimy wyszukać nietrywialnie ściśle spójne komponenty w S =S( Heat) SPK = {{1,2,3,5}}. Następnie wyznaczamy zbiór stanów T, które powinny posiadać etykietę EG Heat oraz być unią elementów SPK. Nie istnieje inny stan w S, z którego można przejść do zbioru T po ścieżce w S. Wobec powyższego obliczenia kończymy wyznaczeniem zbioru: S(EG Heat) = {1,2,3,5}. Rys Struktura Kripke modelowanego systemu Następnie obliczamy zbiór S(Start EG Heat) = {2,5}. W celu obliczenia S(EF (Start EG Heat)), musimy wcześniej wyznaczyć zbiór T=S(Start EG Heat). Następnie, przechodząc wstecz relacji przejść, etykietujemy wszystkie stany spełniający ten warunek. Otrzymujemy: S(EF (Start EG Heat)) = {1,2,3,4,5,6,7}. Ostatecznie zbiór wyrażenia zanegowanego wynosi: S( EF (Start EG Heat)) =. Ponieważ stan początkowy 1 nie jest zawarty w wyznaczonym zbiorze, wnioskujemy, że system opisany przez strukturę Kripke zaprezentowaną na rysunku 2.3 nie realizuje zadanej specyfikacji Własność sprawiedliwości W celu weryfikacji własności sprawiedliwości, należy rozszerzyć podany algorytm weryfikacji modelowej. Oznaczmy przez M=(S,R,L,F) sprawiedliwą strukturę Kripke. Niech F={P 1,P 2,, P k } będzie zbiorem ograniczeń. Mówimy, że ściśle spójny komponent C grafu M jest sprawiedliwy względem F wtedy 20

21 i tylko wtedy, gdy dla każdego P i F istnieje stan t i (C P i ). Następnie przedstawimy algorytm weryfikacji modelowej dla wyrażenia EG f 1 z uwzględnieniem ograniczeń sprawiedliwości. Bazując na lemacie 2.1 musimy przedstawić analogiczne twierdzenie dla problemu z ograniczeniami sprawiedliwości. Lemat 2.2, wtedy i tylko wtedy, gdy spełnione są następujące warunki: s S. Istnieje ścieżka w S od stanu s do t w nietrywialnym, sprawiedliwym, silnie spójnym komponencie C grafu (S, R ). Podobnie jak poprzednio M uzyskujemy poprzez usunięcie stanów ze zbioru S, które nie spełniają formuły f 1 z ograniczeniami sprawiedliwości. Wtedy M =(S,R,L,F ), gdzie S ={s S M, s f 1 }, R =R S S, L =L S oraz F ={P i S P i F}. Złożoność obliczeniowa nowego algorytmu jest porównywalna z wersją bez ograniczenia sprawiedliwości. Ponieważ w algorytmie jest co najwyżej f iteracji, dlatego całkowita złożoności algorytmu wynosi O( f *( S + R )* F ) Weryfikacja modelowa w logice LTL Niech M=(S,R,L) będzie strukturą Kripke oraz niech A g będzie formułą w liniowej logice temporalnej LTL. Wtedy g jest ograniczoną ścieżką formuły, w której tylko jedna pod formuła jest twierdzeniem atomowym. Chcemy określić, czy stan s S spełnia warunek s A g. Należy zwrócić uwagę, że s A g wtedy i tylko wtedy, gdy s E g. W konsekwencji, wystarczające jest sprawdzenie prawdziwości formuł postaci E f, gdzie f jest ograniczoną formułą ścieżki. Problem ten jest PSPACE complete [53]. Szczegóły działania algorytmu zostały opisane w pracy [12]. Warto nadmienić, iż rozwiązanie problemu weryfikacji modelowej LTL należy do klasy NP trudnych Weryfikacja modelowa w logice CTL* Rozwiązanie problemu weryfikacji modelowej w przypadku logiki CTL* posiada podobną złożoność jak w przypadku algorytmów dla logiki LTL. Podstawowa idea rozwiązania postawionego problemu bazuje na połączeniu techniki etykietowania dla logiki CTL z algorytmem weryfikacji modelowej logiki LTL. Oryginalny algorytm LTL obsługuje wyrażenia postaci E f, gdzie f jest ograniczoną formułą ścieżki, w którym tylko jeden stan jest oznaczony atomowym twierdzeniem. Algorytm ten może zostać rozszerzony, aby mógł obsługiwać także inne, dozwolone formuły. Załóżmy, że stan oznaczony podformułami f został już przetworzony oraz etykiety stanów zostały odpowiednio uaktualnione. Następnie każda pod formuła zostanie zastąpiona przez nowe twierdzenie atomowe w obu etykietowaniach miejscach: w modelu oraz w formule. Oznaczmy nową formułę jako E f. Jeżeli formuła jest wyrażona za pomocą logiki CTL, wtedy wykorzystujemy procedurę weryfikacji modelowej dla logiki CTL. W przeciwnym wypadku, f jest typową formułą ścieżki LTL, dlatego też możemy zastosować odpowiedni algorytm dla logiki LTL. W obu przypadkach formuła jest dodana do etykiet wszystkich stanów, które spełniają jej warunek. Jeżeli E f jest pod formułą bardziej złożonej formuły CTL*, wtedy procedura jest powtarzana z E f podmienionym na atomowe twierdzenie. Algorytm jest kontynuowany aż cała formuła zostanie skonstruowana. Złożoność obliczeniowa tego algorytmu zależy od złożoności algorytmów CTL oraz LTL. 21

22 Twierdzenie 2.3 Istnieje algorytm rozwiązania problemu weryfikacji modelowej dla logiki CTL* o złożoności M *2 O( f ). Dowód twierdzenia można znaleźć w pracy [12] Język rachunku μ Język rachunku μ służy do wyrażania własności systemów przejść i miejsc, wykorzystując operatory najmniejszego oraz największego punktu stałego [12]. Język ten znalazł szerokie zastosowanie w narzędziach wspierających weryfikację oprogramowania. Zainteresowanie rachunkiem μ wynika z możliwości zakodowania z jego zastosowaniem większości logik temporalnych oraz modalnych. Dodatkowo, formalizm rachunku μ umożliwia zastosowanie bardzo efektywnego algorytmu rozwiązywania problemu weryfikacji modelowej. Dlatego też, wiele procedur weryfikacyjnych wyrażeń logik modalnych oraz temporalnych sprowadza się do translacji formuł do postaci rachunku μ. Powszechne użycie binarnych diagramów decyzyjnych spowodowało jeszcze szersze wykorzystanie algorytmów wykorzystujących punkty stałe, ponieważ metody polegające na manipulowaniu pojedynczymi stanami nie wykorzystują zalet wynikających z bardziej zaagregowanej reprezentacji. W literaturze można odnaleźć wiele propozycji rachunku μ. Jedną z popularniejszych notacji jest rachunek μ Kozen a [29]. Formuły zamknięte w tej logice operują na zbiorach stanów. Algorytmy operujące na tychże formułach można podzielić na dwie kategorie: lokalne oraz globalne. Procedury lokalne mają na celu udowodnienie, że wybrany stany spełnia zadaną własność. Z tego powodu nie jest konieczne, aby weryfikować wszystkie stany badanego systemu. Jednakże, algorytmy lokalne nie można wykorzystać w obszarze binarnych drzew decyzyjnych. Pierwsze algorytmu lokalne zostały opracowane przez Cleaveland a [13], Stirling, Walkera oraz Winskel a [68]. Ostatnio Andersen oraz Larsen opracowali efektywną metodą rozwiązania problemu lokalnego bazując na podzbiorze rachunku μ [55]. Algorytmy globalne zakładają weryfikację całej przestrzeni stanów systemu. Bazują na binarnych drzewach decyzyjnych, które okazały się bardzo efektywne w zastosowaniach praktycznych. Algorytmy globalne stosują podeście bottom up do weryfikacji danej formuły. W kolejnych iteracjach wyznaczane są punktu stałe wyrażenia. Ponieważ punkty stałe są zagnieżdżone, naiwny algorytm globalny posiada złożoność O(n k ) dla pojedynczej formuły, gdzie n określa liczba stanów, natomiast k jest głębokością osadzenia punktów stałych. Emerson oraz Lei wprowadzili pojęcie zmiennej głębokości, obserwując, że powtarzające się punkty stałe tego samego typu nie powodują zwiększenia złożoności obliczeń. Zaproponowali algorytm o złożoności O(n d ), gdzie d oznacza zmienną głębokość, którą można interpretować jako liczbę zmian pomiędzy najmniejszym i największym punktem stałym. Poprzez odpowiednie manipulacje zbiorami oraz przechowywanie wyników pośrednich można złożoność algorytmu zmniejszyć do O(n d/2 ) [32]. Definicja 2.7 Formuły rachunku μ spełniają następujące warunki: Jeżeli p AP, wtedy p jest formułą. Zmienna relacji Q jest formułą. Jeżeli f oraz g są formułami, wtedy f, f g, f g są formułami. Jeżeli f jest formułą oraz a T, wtedy [a]f oraz a f też są formułami. Jeżeli Q VAR oraz f jest formułą, wtedy μq.f oraz νq.f są formułami, pod warunkiem, że f jest syntaktycznie monotonna w Q (czyli, wystąpienia Q w f zawierają się w parzystej liczbie negacji w f)[55]. 22

23 Formuły rachunku μ będziemy interpretować w odniesieniu do systemu przejść. W celu rozróżnienia dwóch przejść w systemie, definicja struktury Kripke zostanie zmodyfikowana. W miejsce relacji R, zdefiniujemy zbiór relacji przejść T. Upraszczając będziemy traktować element ze zbioru a T, jako przejście, a nie jako relacje przejścia. Niech VAR={Q 1, Q 2, } będzie zbiorem zmiennych relacjnych. Każda taka zmienna Q VAR może posiadać powiązany z nią podzbiór S. Zmienne w rachunku μ mogą być wolne lub powiązane z operatorami punktu stałego. Zamknięte formuły nie posiadają zmiennych. W celu podkreślenia, iż dana formuła posiada wolne zmienne relacji Q 1,,Q n, formułę zapisujemy jako f(q 1,,Q n ). Formułę a f można interpretować jako możliwość wykonania przejścia a do stanu, który spełnia warunek f. Podobnie [a]f oznacza, że f jest spełniony we wszystkich stanach dostępnych w jednym kroku po dokonaniu przejścia a. Operatory ν oraz μ oznaczają największy oraz najmniejszy punkt stały. Pusty zbiór stanów oznaczamy jako False, natomiast zbiór wszystkich stanów S oznaczamy jako True. W celu oznaczenia przejścia (s,s ) a wykorzystuje się notację s s. Formuła f jest interpretowana jako zbiór stanów, dla których f jest prawdziwa. Zbiór taki oznaczamy jako, gdzie M jest systemem przejść, natomiast e : VAR 2 S oznacza otoczenie. Będziemy oznaczać przez e[q W] nowe otoczenie, takie jak e poza e[q W](Q)=W. Zbiór definiujemy rekurencyjnie w sposób następujący: Definicja 2.8 Zbiór definiujemy jako:.. \ jest najmniejszym punktem stałym transformacji τ: 2 S 2 S zdefiniowanej jako:.. jest największym punktem stałym transformacji τ: 2 S 2 S zdefiniowanej jako:. Stosowanie negacji w rachunku μ jest ograniczone. Monotoniczność gwarantuje, aby punktu stałe były dobrze zdefiniowane. Formalnie, każde logiczne połączenie poza negacją jest monotoniczne: z f f wynika f g f g, f g f g, a f a f oraz [a]f [a]f. Negacje mogą być przesunięte na poziom atomowych twierdzeń z wykorzystaniem praw DeMorgana: [a]f a f, a f [a] f, μq.f(q) νq. f( Q), νq.f(q) μq. f( Q). Ponieważ zmienne są powiązane z parzystą liczbą negacji, po zakończeniu tego procesu, ostateczne formuły nie będą posiadały negacji. Każda poprawnie zdefiniowana formuła z operatorem punktu stałego jest monotoniczna, stąd każde możliwe τ jest także monotoniczne (S S τ(s) τ(s )). Warunek ten jest wystarczający do tego, aby istniały punkty stałe. Własność monotoniczności dla systemów skończenie stanowych implikuje także własność ciągłości koniunkcji oraz alternatywy transformacji τ. Stwierdzenie to pozwala na opracowanie efektywnego 23

24 algorytmu rozwiązania problemu weryfikacji modelowej dla logiki rachunku μ. Więcej informacji na temat rachunku μ można znaleźć w [29]. 2.4 Sieci Petriego Sieci miejsc i przejść Sieci miejsc i przejść są podstawowym językiem modelowania współbieżności i synchronizacji procesów dyskretnych [59]. W swojej pierwotnej formie sieci miały ograniczone możliwości. Dalsze prace rozwinęły znacznie zakres modelowania, jak również techniki analizy własności. Sieć miejsc i przejść jest pewnym grafem dwudzielnym, w którym własności dynamiczne są modelowane przez przepływ znaczników przez węzły sieci. Definicja 2.9 Siecią Petriego nazywamy piątkę, PM = P, T, A, W, s ), gdzie: ( 0 1. P zbiór (skończony) miejsc. 2. T zbiór (skończony) przejść. 3. A P T T P zbiór łuków. 4. W: A N funkcja wag przypisująca etykiety (liczby naturalne) do każdego łuku. 5. S 0 : P N * funkcja opisująca oznakowanie początkowe (initial marking), gdzie N oznacza zbiór liczb całkowitych nieujemnych, tj.: N* =N {0}. Zakłada się ponadto, że dla każdej sieci specyfikowanej jak wyżej spełniony jest warunek: P T = φ & P T φ. Pierwsze cztery punkty powyższej definicji opisują sieć Petriego jako graf dwudzielny, w którym wyróżnia się dwa rozłączne podzbiory wierzchołków: zbiór miejsc (places) i zbiór przejść (transitions). Łuki mogą łączyć wyłącznie elementy należące do różnych podzbiorów (punkt 3), czyli nie występują łuki łączące elementy tego samego rodzaju, np. dwa miejsca. Łuki mogą być wielokrotne krotność każdego łuku określa funkcja wag (punkt 4), interpretowana jako specyfikacja ilości łuków związanych z daną parą miejsce przejście (przejście miejsce). Z tego punktu widzenia sieć Petriego jest multigrafem. Cztery początkowe elementy opisują strukturę sieci jako pewien multigraf dwudzielny (dwa rozłączne zbiory wierzchołków). Dodanie oznakowania początkowego umożliwia opis własności dynamicznych, które są modelowane przez przepływ znaczników (markers) powodowany wykonywaniem (firing) przejść sieci. Będziemy często stosować oznaczenie PN = ( P, T, A, W) dla sieci (struktury sieci) określonej według punktów 1 4 definicji 2.7 (wraz z warunkiem określonym na końcu tej definicji). W takich przypadkach używana będzie notacja PM = PN, s ) dla specyfikowania sieci znakowanej. ( 0 W analizie sieci używa się często określenia miejsca wejściowe i miejsca wyjściowe, związane z przejściem. Dowolne miejsce p nazywa się miejscem wejściowym (wyjściowym) dla przejścia t, jeśli istnieje łuk łączący, skierowany od tego miejsca (przejścia) do przejścia t (miejsca p ). Wykonanie dowolnego przejścia w sieci polega na pobraniu znaczników z miejsc wejściowych (danego przejścia) i wstawienie znaczników do miejsc wyjściowych. Ilość znaczników pobieranych (wstawianych) jest określona przez wagi przypisane do odpowiednich łuków. 24

25 W celu uproszczenia zapisu określimy pewne domknięcie funkcji w oznaczone W. Dla dowolnej sieci * PM = P, T, A, W, s ), funkcja W : P T T P N jest określona następująco: ( 0 W ( x ) = W 0 ( x ) dla dla x x A A Definicja 2.10 Niech PN = P, T, A, W, s ) będzie znakowaną siecią Petriego, określoną jak w definicji 2.7. ( 0 1. Zbiór wszystkich oznakowań tej sieci oznaczamy: S = { s s : P N}. 2. Funkcja częściowa δ : S T S jest określona następująco: a. Dom( δ ) = {( s, t) ( p P) s( p) W ( p, t)}. b. jeśli ( s, t) Dom( δ ), to: 3. ( p P)[ s1( p) = δ ( s, t)( p) = s( p) W ( p, t) + W ( t, p)]. 4. Dla dowolnych s, s1, t jeśli s = δ ( s, ), to fakt ten będziemy również zapisywać: t s [ t > s 1 lub również s s1. 1 t Punkt pierwszy definiuje zbiór wszystkich możliwych oznakowań dla danej sieci Petriego. Oznakowanie, zwane również stanem sieci, jest opisywane przez funkcję przypisującą każdemu miejscu liczbę całkowitą nieujemną. Wartość tej funkcji dla danego miejsca jest interpretowana jako ilość znaczników zawartych w tym miejscu. Dowolna funkcja wyznacza ilości znaczników dla wszystkich miejsc, co uzasadnia użycie terminu stan. Wykonanie pewnego przejścia powoduje zmianę ilości znaczników w miejscach związanych z tym przejściem (wejściowych i wyjściowych), czyli realizuje przejście do następnego stanu, określonego przez (zazwyczaj) inną funkcję przypisującą znaczniki do miejsc. Zmiany stanu wskutek realizacji przejścia są określone przez funkcję częściową δ. Warunkiem koniecznym wykonania przejścia przy danym oznakowaniu, jest istnienie w każdym miejscu wejściowym wystarczającej ilości znaczników ( s( p) W ( p, t)). Oznacza to, że dane oznakowanie musi zapewniać odpowiednią ilość znaczników w miejscach wejściowych dla danego przejścia, tak aby możliwe było pobranie tych znaczników w ilości określonej przez funkcję etykietującą łuki W. Zmianę stanu wskutek wykonania przejścia opisuje podpunkt 2.b definicji 2.8. W myśl tej definicji, znaczniki są odbierane z miejsc wejściowych w ilości określonej przez wartość funkcji w dla odpowiedniego łuku od miejsca do przejścia oraz dodawane do miejsc wyjściowych w ilości wyznaczonej przez tę samą funkcję dla odpowiednich łuków wyjściowych (dla danego przejścia). Definicja 2.11 Znakowana sieć PM = ( PN, s0) jest (bezwzględnie) zachowawcza, jeśli dla dowolnego stanu osiągalnego R PN, s ) s ( p) = s0 ( p). s ( 0 spełniony jest warunek: p P p P Znakowana sieć PM = PN, s ) zachowawcza względem wektora wag w, w, K, w ), gdzie ( 0 ( 1 2 n s R ( PN, s0 n = P, w 1 0 dla i = 1,2, K, n, jeśli dla dowolnego znakowania osiągalnego ) spełniony jest warunek: w is( pi ) = wi s0 ( pi ). i i 25

26 Zagadnienie żywotności (liveness) jest niezwykle istotne w analizie własności systemów współbieżnych. Można nieformalnie zdefiniować tę własność jako: coś dobrego kiedyś się zdarzy (something good eventually does happen). Klasycznie żywotność jest kojarzona z ciągłością działania, np. system czasu rzeczywistego powinien być zawsze gotowy do obsługi zdarzeń zachodzących w jego otoczeniu. W szerszym znaczeniu żywotność może być interpretowana jako całkowita poprawność, uzyskanie dostępu do obszaru krytycznego itp. Żądanie żywotności w kontekście sieci Petriego będzie zatem dotyczyło jej nieskończonego działania. Wykonywanie sieci polega na realizacji przejść, stąd w pierwszy kroku dokonamy klasyfikacji przejść w kontekście tej własności. Definicja 2.12 Niech będzie dana sieć Petriego PM = (PN, s 0 ). Mówimy, że dowolne przejście sieci: t T jest w tej 1. L0 żywotne (martwe) jeśli to przejście nie może być odpalone dla każdej sekwencji odpaleń L(s 0 ). 2. L1 żywotne (potencjalnie odpalane) jeśli może być odpalone przynajmniej raz dla pewnej sekwencji odpaleń L(s 0 ). 3. L2 żywotne jeśli to przejście może być odpalone przynajmniej k razy (k > 0) dla pewnej sekwencji odpaleń L(s 0 ). 4. L3 żywotne jeśli t występuje nieskończenie wiele razy w pewnej sekwencji odpaleń L(s 0 ). 5. L4 żywotne (żywotne) jeśli t jest L1 żywotne w każdym oznakowaniu osiągalnym s R(PN,s 0 ). Korzystając z tej definicji możemy określić Lk żywotność sieci (PN, s 0 ) przenosząc to wymaganie na wszystkie przejścia sieci. Definicja 2.13 Dowolna siec oznakowana (PN, s 0 ) jest Lk żywotna, jeśli każde jej przejście jest Lk żywotne, dla k = l, 2, 3, 4. Klasyczna definicja żywotności odpowiada L4 żywotności i w takim formułowaniu jest bardzo ostrym wymaganiem. Zauważmy bowiem, że L4 żywotność, lub krócej żywotność oznacza, że w dowolnym stanie osiągalnym, dla każdego przejścia istnieje w przyszłości (w stanach następnych) oznakowanie, w którym to przejście jest gotowe do odpalenia. Jest to więc nie tylko żądanie ciągłego działania sieci, lecz również pewnej regularności, tzn. każde przejście jest w przyszłości gotowe do odpalenia, czyli nie jest możliwe osiągnięcie oznakowania, począwszy od którego pewne przejścia sieci będą martwe. Można łatwo wykazać, że własności Lk żywotności można ułożyć w następujący ciąg określający wynikanie kolejnych odmian tej własności: L4 żywotność L3 żywotność L2 żywotność LIżywotność L0 żywotność. Przytoczone tu wynikanie klas żywotności skłania do uściślenia tego pojęcia. Mówimy, że sieć jest dokładnie Lk żywotna jeśli jest Lk żywotna nie jest L( k +1) żywotna, dla k = 0, l, 2, 3. W celu poprawienia opisu regularności sieci w stosunku do żywotności wprowadzono pojęcie sprawiedliwości. Nieformalnie określa ono żądanie aby sieć wykonywała się równomiernie tzn. żeby nie było sytuacji, w których wykonanie ograniczałoby się do nieskończonej realizacji wyłącznie pewnych 26

27 przejść. Takie żądanie nakłada silne wymagania na strukturę sieci, która nie powinna dopuszczać zapętlenia pewnych jej fragmentów Sieci kolorowane Pojęcie wielozbioru zostało wprowadzone w celu opisu faktu istnienia kilku egzemplarzy tego samego elementu w zbiorze [27]. W odróżnieniu od klasycznej teorii zbiorów gdzie interesuje nas jedynie przynależność elementu do zbioru, w teorii wielozbiorów zwraca się uwagę na ilość (krotność) danego elementu w zbiorze. Definicja 2.14 Wielozbiorem m nad niepustym zbiorem S nazywamy funkcję m [S N]. Dowolna nieujemna liczba całkowita m(s) N jest ilością wystąpień elementu s w tym wielozbiorze. Wielozbiór jest zazwyczaj zapisywany w postaci pewnej sumy: s S m ( s )` s Wprowadzamy oznaczenia: SMS zbiór wszystkich wielozbiorów nad zbiorem S : Dowolna nieujemna liczba całkowita m(s) nazywa się współczynnikiem elementu s, gdzie s S. Element s S należy do wielozbioru m ( s) 0, fakt ten zapisujemy s m. W powyższej definicji [ S N] oznacza zbiór wszystkich funkcji przeprowadzających zbiór S w N, gdzie N oznacza zbiór liczb całkowitych nieujemnych. Definicja wielozbioru składa się więc z dwóch elementów: zbioru (S) oraz funkcji (m) określającej ilość wystąpień elementów zbioru S w tym wielozbiorze. Dodanie lub usunięcie pewnego elementu z wielozbioru powoduje zmianę odpowiedniego współczynnika, a więc zmianę funkcji m. Dowolny podzbiór zapisuje się często w postaci sumy elementów zbioru S poprzedzonych współczynnikami, na przykład zapis: 3`a+2`b+5`c oznacza wielozbiór, w którym są 3 wystąpienia a, 2 wystąpienia b oraz 5 elementów c. Zdefiniowane wyżej operacje dotyczące wielozbiorów są określone przez działania na poszczególnych współczynnikach elementów wielozbiorów. W przypadku dodawania/ odejmowania operację wykonuje się dodając/odejmując współczynniki przy odpowiednich elementach. Podobną zasadę stosuje się dla porównywania innych operacji określonych w powyższej definicji. Przed podaniem formalnej definicji wprowadzimy pewne pojęcia pomocnicze. 1. Jeśli F oznacza pewien typ, to jest on utożsamiany ze zbiorem wszystkich elementów tego typu. 2. Typ zmiennej v jest oznaczany przez Type(v). Podobnie typ wyniku wyrażenia expr oznaczamy Type(expr). 3. Zbiór wszystkich zmiennych występujących w wyrażeniu expr jest oznaczany Var(expr). Wiązaniem zbioru zmiennych V nazywamy przypisanie każdej zmiennej v V wartości b( v) Type( v), czyli innymi słowy wartościowanie wszystkich zmiennych ze zbioru V. 4. Wartość wyrażenia expr przy wiązaniu (wartościowaniu) b jest oznaczana expr<b>. Żąda się przy tym, aby zbiór zmiennych wyrażenia Var(expr) był podzbiorem zbioru zmiennych wiązania b. 27

28 Definicja 2.15 Dodawanie, mnożenie skalarne, porównywanie i moc wielozobiorów są definiowane następująco. Niech będą dane dowolne wielozbiory: m, m m S, dla każdego n N definiujemy: m 2 1. Dodawanie: m 1 + m 2 = s S 1, 2 ( m 1 ( s) + m 2 ( s))`s n m = ( n m 2 ( s))`s 2. Skalarne mnożenie: s S m1 m2 ( s S) m1 ( s) m2 ( s) 3. Porównanie: m1 m2 ( s S) m1 ( s) m2 ( s) 4. Moc (wielozbioru): m = m( s) s S 5. Jeśli m1 m2, to różnica (wielozbiorów) jest określona następująco: m 1 = s S ( 2 1 m ( s) m ( s))`s Jeśli m =, to wielozbiór jest nieskończony, w przeciwnym przypadku jest skończony. Definicja 2.16 Kolorowaną siecią Petriego nazywamy krotkę CPN = ( Σ, P, T, A, N, C, G, E, I), gdzie: 1. Σ skończony niepusty zbiór typów, zwany zbiorem kolorów. 2. P skończony zbiór miejsc. 3. T skończony zbiór przejść. 4. A skończony zbiór łuków, taki że: P T = P A = T A = φ. 5. N funkcja wierzchołków: N : A P T T P. 6. C funkcja kolorów: C : P Σ. 7. G funkcja dozorów, G : T EB, gdzie EB jest zbiorem wyrażeń o wartościach Boolean, spełniających warunek: ( t A) Type( G( t)) = B Type( Var( G( t)) Σ. 8. E funkcja wyrażeń łuków, E : A EC, gdzie FC jest zbiorem wyrażeń o wartościach wielozbiorach kolorów, spełniających warunek: ( a A) Type( E( a)) = C( p( a)) MS Type( Var( e( a)) Σ gdzie p (a) jest miejscem łuku N (a). 9. I funkcja inicjalizacji, I : P ECP, gdzie ECP jest zbiorem wyrażeń, spełniających warunek: ( p P) Type ( I( p)) = C( p). MS W przypadku sieci kolorowanej mamy do czynienia z odmienną sytuacją niż dla sieci miejsc i przejść [27]. W sieci kolorowanej dopuszcza się bowiem istnienie wielu łuków łączących tę samą parę (p, t) lub (t, p). Wprowadzenie zbioru łuków umożliwia rozróżnienie łuków łączących tę samą parę upo 28

29 rządkowaną. Możliwe jest tym samym rozróżnienie przypadków pobierania/dodawania różnej ilości znaczników. Z drugiej strony można połączyć takie łuki w jeden i odpowiednio zmienić opis, np. case x of p 2`r q 3`r. Formuła przy funkcji dozorów oznacza, że wyrażenie przypisane do dowolnego przejścia t przyjmuje wartości typu Boolean ( Type ( G( t)) = B) oraz wszystkie zmienne tego wyrażenia są dopuszczalnego typu, tzn. należą do zbioru kolorów ( Type ( Var( G( t)) Σ). Zakłada się ponadto, że jeśli dozór nie występuje w opisie pewnego przejścia, to oznacza, że jest to stała true. Formuła opisująca wymagania funkcji E oznacza, że wartościowanie łuków musi odpowiadać wielozbiorom nad kolorami przypisanymi do odpowiednich miejsc ( Type ( E( a)) = C( p( a)) MS ) oraz typ zmiennych zawartych w wyrażeniach przypisanych do łuków należy do zbioru kolorów sieci ( Type ( Var( E( a)) Σ). Ostatnia formuła opisuje własności funkcji inicjalizacji (oznakowanie początkowe). Wyrażone jest w niej wymaganie, aby oznakowanie (początkowe) dowolnego miejsca było zgodne z kolorami przypisanymi do tego miejsca. Innymi słowy, wielozbiór opisujący oznakowanie w dowolnym miejscu musi odpowiadać wielozbiorom nad zbiorem kolorów przypisanym do tego miejsca Type ( I( p)) = C( p). MS Wykonanie sieci kolorowanej Definiujemy następujące pojęcia: Zbiór zmiennych skojarzonych z dowolnym przejściem t T : Var( t) = { v v Var( G( t)) ( a A( t)) v Var( E( a))}. Wyrażenie opisujące połączenie miejsca (przejścia) x 1 z przejściem (miejscem) x 2 jest określone dla każdej pary ( x 1, x2 ) ( P T T P) następująco: E( x1, x2 ) = E( a) a A( x, x ) Zbiór zmiennych skojarzonych z przejściem ( Var( t)) jest zbiorem wszystkich zmiennych, które występują w dozorze lub w łukach wejściowych/wyjściowych tego przejścia. Pojęcie drugie jest konsekwencją dopuszczenia wielokrotnych łuków łączących dowolne dwa węzły sieci, odpowiednie wyrażenie jest sumą wyrażeń przypisanych do tych łuków. Pokazano tym samym sposób zastępowania takich łuków wielokrotnych pojedynczym. Definicja 2.17 Wiązaniem dla przejścia t nazywamy funkcję b nad Var (t) taką, że spełnione są warunki: 1. ( v Var( t)) b( v) Type( v). 2. G(t)<b>, gdzie expr<b> oznacza wartość wyrażenia expr przy wiązaniu (podstawieniu) b

30 Definicja 2.18 Elementem znacznikowym nazywamy dowolną parę (p,c), gdzie p P oraz c C( p). Elementem wiązania nazywamy parę (t,b) w której t T oraz b B(t). Zbiór wszystkich elementów znacznikowych oznaczamy TE, natomiast zbiór wszystkich elementów wiązań BE. Oznakowaniem nazywamy wielozbiór nad TE, natomiast krokiem nie pusty i skończony wielozbiór nad BE. Oznakowaniem początkowym m 0 nazywamy znakowanie otrzymane przez wartościowanie wyrażeń inicjalizacji (wyznaczonych przez funkcję inicjalizacji): ( ( p, c) TE) m0 ( p, c) = ( I( p))( c). Zbiory wszystkich oznakowań i kroków są oznaczone odpowiednio S oraz V. Powyższa definicja wprowadziła pojęcie oznakowania jako pewnego wielozbioru nad zbiorem kolorów. Należy tu podkreślić, że oznakowanie dowolnego miejsca jest wielozbiorem nad kolorami przypisanymi dla danego miejsca. Każde oznakowanie MS M TEMS określa jednoznacznie funkcję M*, zdefiniowaną nad P i taką, że * * M ( p) C( p) : ( p P)( c C( p)) ( M ( p))( c) = M ( p, c). Z drugiej strony każda funkcja M* zdefiniowana nad P, taka że * M ( p) C( p) dla każdego * p P, określa jednoznacznie znakowanie M: ( ( p, c) TE) M( p, c) = M ( p))( c). Jeśli dla dowolnej sieci CPN dane są funkcje M i odpowiadająca jej M*, to dla dowolnego miejsca p * możemy zapisać: M ( p) = M ( p, c). c C ( p) Możliwość wzajemnej reprezentacji jest często wykorzystywana przy opisie własności sieci. Analogicznie istnieje jednoznaczna odpowiedniość między krokiem Y i funkcją Y* zdefiniowaną nad T, * taką że Y ( t) B( t) jest skończone i niepuste dla każdego t T. MS MS Definicja 2.19 Dowolny krok Y jest wzbudzony przy oznakowaniu M spełniony jest następujący warunek: ( p P) E( p, t) < b > M ( p). ( t, b) Y Niech krok Y będzie wzbudzony przy oznakowaniu M. Jeśli ( t, b) Y, to mówimy że t jest wzbudzone w M dla wiązania b. Mówimy także, że ( t, b) jest wzbudzone w M, lub krótko t jest wzbudzone. Jeśli ( t1, b1 ), ( t 2, b2 ) Y oraz ( t1, b1 ) ( t 2, b2 ), to ( t, b 1 1) oraz ( t, b ) 2 2 są równolegle wzbudzone. Jeśli Y ( t) 2, to przejście t jest współbieżnie wzbudzone z samym sobą. To samo dotyczy kroku ( t, b), który jest współbieżnie wzbudzony z samym sobą, jeśli Y ( t, b) 2. Jeśli przejście jest wzbudzone przy znakowaniu M 1,to może nastąpić wykonanie tego przejścia, czyli zmiana oznakowania M 1 W M 2, określona przez następujące warunki: ( p P) M ( p) = ( M ( p) E( p, t) < b > + E( t, b < b >. Mówimy wówczas, że 2 1 ) ( t, b) Y ( t, b) Y znakowanie M 2 jest bezpośrednio osiągalne z M 1, co zapisujemy: M [ Y > M

31 Efektem powyższej konstrukcji jest określenie zmiany oznakowania w wyniku wykonania przejścia. Zauważmy, że wykonanie nie jest określone wyłącznie przez wybór przejścia, lecz zależy również od wiązania, czyli sposobu wartościowania zmiennych skojarzonych z danym przejściem. Stąd, w zależności od wyboru wiązania (b), możemy wykonać dane przejście na kilka sposobów przy zadanym oznakowaniu M (porównaj poprzednią definicje). Własność ta jest efektem ukrycia rozgałęzień sieci zwykłej (miejsc i przejść) w zmiennych, funkcjach przypisujących i kolorach. Rozwinięcie" sieci kolorowanej w odpowiadającą jej sieć zwykłą spowoduje odtworzenie struktury i wówczas dane przejście rozdzieli się na kilka innych, które mogą być współbieżne wzbudzone przy pewnych oznakowaniach Czasowe sieci Petriego Rozszerzenia czasowe były w różny sposób wprowadzane do sieci Petriego, w szczególności do sieci miejsc i przejść [59]. Poniżej przedstawimy krótką charakterystykę tych rozszerzeń, natomiast w dalszej części podamy wprowadzenie do kolorowanych sieci z czasem. Wydaje się, że te ostatnie sieci oferują jeden z najogólniejszych modeli w tej dziedzinie. Naturalnym sposobem wprowadzenia czasu do sieci Petriego jest przypisanie skończonego czasu do przejścia. Czas ten interpretowany jest jako czas wykonywania przejścia, czyli odcinek czasu od momentu wzbudzenia przejścia do zakończenia zmiany oznakowania. Wiąże się to z interpretacją przejścia jako operacji, stąd wspomniany czas może być rozumiany jako czas wykonywania takiej operacji. Wykonanie przejścia (zmiana oznakowania) odbywa się po upływie tego czasu od momentu wzbudzenia tego przejścia. Sieci tego typu były stosowane do analizy systemów współbieżnych. Czas przypisany do miejsca określa minimalny czas przebywania znaczników w tym miejscu, po upływie którego mogą być pobrane przez przygotowane przejście. Jeśli pewne przejście ma wiele miejsc wejściowych, wówczas wykonanie może nastąpić dopiero po upływie najdłuższego spośród czasów przypisanych do tych miejsc. Sieci tego typu były stosowane do analizy wydajności systemów komputerowych. Każde przejście ma przypisane dwa elementy: czas przygotowania i czas wykonywania. W trakcie realizacji przejścia znaczniki miejsc wejściowych są dodatkowo absorbowane przez przejście na określony czas (wykonywania). Sieci tego typu były stosowane do oceny wydajności protokołów komunikacyjnych sieci komputerowych. Przedział czasowy przypisany do przejścia. Przypisanie przedziału czasowego do każdego przejścia jest kolejnym rozszerzeniem. Specyfikacja takiego przedziału następuje przez podanie wartości granicznych a i b ( a b). Przejście przygotowane (wzbudzone) może być wykonane po upływie minimalnego czasu a 0, jednak nie później niż przed upływem czasu określonego przez 0 b. Wartości graniczne dotyczą przedziału, czyli jeśli rozważane przejście jest przygotowane w chwili T, wówczas to przejście może być wykonane w dowolnej chwili czasowej z przedziału [ τ + a, τ + b]. Podobnie jak w poprzednich przypadkach, sieci te były stosowane do analizy protokołów komunikacyjnych. Kolejny model polega na przypisaniu pieczątek czasowych do znaczników. Formalnie jest to zapisywane jako odpowiednie rozszerzenie elementów wielozbiorów. Zbiór wszystkich wielozbiorów nad S oznaczamy S TMS. Dowolna nieujemna liczba całkowita tm( s) ( s S) nazywana jest współczynnikiem czasowego wielozbioru tm. Element s S należy do czasowego wielozbioru, jeśli tm ( s) 0. Fakt ten zapisujemy s tm. 31

32 Definicja 2.20 Wielozbiorem czasowym (timed multi set) tm nad niepustym zbiorem S nazywamy funkcję tm [ S R N], taką że suma: tm ( s) = tm( s, r) jest skończona dla każdego s S. Nieujemna wartość (s) tm. t R tm jest nazywana ilością wystąpień elementu s w skończonym wielozbiorze Lista: tm[ s] = [ r1, r2, K, r tm ( s) ] zawiera wartości czasu r R, dla których wartości współczynników są niezerowe ( tm ( s, r) 0). Każde r występuje tm ( s, r) razy na liście, która jest uporządkowana względem momentów czasowych r i r i+ 1 dla każdego i 1.. tm( s) 1. Wielozbiór czasowy będzie zazwyczaj zapisywany w postaci sumy: tm ( tm[ s] s S Każdy czasowy wielozbiór tm = tm( s)`s. U s S tm STMS wyznacza wielozbiór U SMS tm określony następująco: Jak już wspomniano wielozbiory czasowe są najczęściej reprezentowane w postaci sumy. Przykładowo wielozbiór 1`( q,0)@[0] + 1`( q,1)@[15] opisuje dwa różne znaczniki, przy czym pierwszy jest gotowy do pobrania począwszy od chwili 0, natomiast drugi począwszy od momentu 15. W przypadku wielu wystąpień, czas może być specyfikowany w postaci listy, np. 3`( p,0)@[0,0,0] oznacza, że każdy z trzech znaczników (p,0) jest przygotowany do pobrania począwszy od chwili 0. Warunki wzbudzenia są określone przez relację między pewnym wartościowaniem łuków, a odpowiednim wielozbiorem umieszczonym w miejscu wejściowym. W praktyce jest to więc porównywanie odpowiednich wielozbiorów. W przypadku sieci bez czasu, zagadnienie to nie nastręcza trudności. Dla sieci czasowych oprócz porównywania ilości odpowiednich znaczników (kolorem) musimy jeszcze sprawdzić zachowanie relacji dla pieczątek czasowych. Zagadnienie to jest złożone, gdyż te same znaczniki mogą mieć przypisany rożny czas i co więcej, porównywane listy mogą być różnej długości. Relację oraz operację odejmowania dla wielozbiorów czasowych wprowadza się przedłużając odpowiednią relację i operację (oznaczane tak samo jak dla wielozbiorów nieczasowych). Zauważmy, że pozostawienie tylko części nieczasowej, przy żądaniu równości pieczątek czasowych odpowiadających tym samym kolorom, jest niezadowalające, gdyż przy usuwaniu znaczników zazwyczaj mamy do czynienia z różnymi czasami i interesujące jest usunięcie elementu, który ma czas mniejszy lub równy określonemu. To ostatnie oznacza bowiem, że znacznik jest gotowy do pobrania Techniki analizy własności Wyróżnia się trzy podstawowe techniki analizy sieci Petriego: 1. Konstrukcja i analiza drzewa stanów osiągalnych. 2. Analiza metodami rachunku macierzowego rozwiązywanie równań utworzonych na bazie macierzy incydencji sieci. 3. Redukcja i dekompozycja sieci. 32

33 Drzewo stanów osiągalnych Drzewo stanów osiągalnych posiada węzeł dla każdego oznakowania osiągalnego z oznakowania początkowego oraz łuk dla każdego elementu wiążącego (binding element). Definicja 2.21 Pełnym drzewem pokrycia sieci Petriego nazywamy graf skierowany OG = ( V, A, N) gdzie: V = { s 0 }, A = {( s1, b, s2 ) V BE V s1[ b > s2}, a = ( s1, b, s2 ) A : N ( a) = ( s1, s2 ). Kiedy ma się do czynienia z kolorowaną siecią Petriego, w której wszystkie zmienne (w wyrażeniach łuków i dozorach) mają skończone zbiory kolorów oraz instancje miejsc są ograniczone to można dowieść, że drzewo pokrycia jest skończone. Wykonanie sieci Petriego sprowadza się najczęściej do nieskończonego wykonania pewnych przejść sieci. Skonstruowanie drzewa pokrycia o skończonej ilości węzłów wymaga dokonania pewnych uproszczeń. Generalnie są dwie przyczyny powodujące powstawanie nieskończonych drzew stanów osiągalnych: 1. powtarzające się sekwencje wykonań pewnych przejść, 2. nieograniczony wzrost ilości znaczników w pewnych miejscach. Drzewo osiągalności składa się ze skończonej liczby węzłów, co umożliwia badanie własności dynamicznych: 1. Sieć PM = ( PN, s0) jest ograniczona symbol ω nie występuje w drzewie pokrycia. Wówczas drzewo stanów osiągalnych jest skończone. 2. Sieć PM = ( PN, s0 ) jest bezpieczna w węzłach drzewa nie występują oznakowania składające się wyłącznie z zer lub jedynek. 3. Przejście t jest martwe jeśli w drzewie pokrycia nie występuje łuk etykietowany przez t. 4. Oznakowanie s jest osiągalne z oznakowania początkowego s 0, jeśli w drzewie pokrycia istnieje węzeł s oraz ścieżka prowadząca z s 0 do s Niezmienniki Niezmienniki miejsc są pewnymi równaniami, dotyczącymi danej sieci Petriego, od których wymaga się aby były spełnione dla każdego osiągalnego oznakowania [27][54]. Analiza niezmienników miejsc może być użyta do udowadnienia dynamicznych własności sieci. Można ją stosować bez określania konkretnych parametrów danego systemu, co daje możliwość zbadania ogólnych właściwości systemu. Niezmienników miejsc można użyć także przy projektowaniu systemu. Wymaga się wówczas, aby konstrukcja systemu zachowywała w każdej fazie założone z góry niezmienniki. 2.5 Podsumowanie W rozdziale przedstawiono najważniejsze kierunki rozwoju metod formalnych w inżynierii oprogramowania. Obecnie można wskazać na dwa niezależne kierunki ich rozwoju: Rozwój efektywnych algorytmów automatyzujących proces weryfikacji poprawności oprogramowania oraz tworzenie na ich bazie narzędzi wspierających. 33

34 Integracja opracowanych formalizmów z metodologiami prowadzenia projektów informatycznych. Opracowywanie metodologii definiowania zakresu projektu, specyfikacji oraz implementacji opartych o metody formalne. Z punktu widzenia inżynierii oprogramowania, oba kierunki rozwoju są niezmiernie ważne, ponieważ oczekuje się, iż zastosowanie metodyk formalnych znacząco zmniejszy obecne koszty testowania oraz utrzymania oprogramowania, zwłaszcza w obszarze systemów czasu rzeczywistego. 34

35 3. Metodyka ROPES 3.1 Wprowadzenie Ze względu na specyfikę zagadnienia oraz dojrzałość przedmiotu, tworzenie oprogramowania, a zwłaszcza oprogramowania dla systemów czasu rzeczywistego, nie jest przedsięwzięciem powtarzalnym, dającym za każdym razem te same dobre jakościowo i ekonomicznie uzasadnione rezultaty. Obecny rozwój inżynierii oprogramowania, tak chętnie przez wielu porównywanej do innych dziedzin inżynierii np. budownictwa nadal przypomina bardziej rodzaj sztuki lub rękodzieła aniżeli ugruntowaną i zestandaryzowaną gałąź przemysłu. Główną z przyczyn takiego staniu rzeczy należy upatrywać w samej istocie oprogramowania, którego głównym zadaniem jest modelowanie świata rzeczywistego. Niestety modelowany obiekt jest z reguły bardzo skomplikowany, to też oprogramowanie modelujące także musi być skomplikowane. Sytuację pogarsza dodatkowo bardzo zróżnicowane podejścia do procesu tworzenia oprogramowania, zależne od wybranego środowiska programistycznego, wykorzystanych zasobów oraz doświadczenia osób zarządzających danym projektem. Symptomatyczny dla projektów informatycznych jest brak wiedzy osób zaangażowany, jaki będzie efekt końcowy projektu. Ta nieoznaczoność projektów informatycznych jest główną przyczyną problemów z planowaniem oraz organizacją projektów. Należy jednak zaznaczyć, iż ostatnie lata przyniosły znaczną poprawę w stosunku do sytuacji z początku lat 90 tych XX wieku. Zostały upowszechnione standardy związane z językami oprogramowania oraz modelowania systemów informatycznych. Powstało wiele instytucji nadzorujących rozwój wprowadzonych standardów. Na rynku dostępnych jest bardzo wiele środowisk programistycznych wspomagających tworzenie oprogramowania. W dziedzinie metod formalnych pojawiło się wiele narzędzi wspomagających ich wykorzystanie w zastosowaniach przemysłowych. Nadal jednak problemem pozostanie modelowanie skomplikowanego świata zewnętrznego oraz brak wiedzy na temat wszystkich aspektów tworzonego systemu. Bardzo często podczas projektu informatycznego następuje zmiana założeń dotyczących wymagań np. funkcjonalnych. Wprowadzanie tychże zmian do projektu wymaga niejednokrotnie powrotu do początkowych faz projektu, co znacznie utrudnia jego realizację zgodnie z założonym harmonogramem oraz budżetem. Najważniejszymi pytaniami stawianymi najczęściej przed rozpoczęciem projektu informatycznego są: Jakie będą całkowite koszty związane z wytworzeniem, wdrożeniem oraz utrzymaniem systemu? Jakie oszczędności (przychody) zostaną osiągnięte w wyniku wdrożenia systemu? Jak długo będzie trwał projekt? Jakie zasoby należy wykorzystać w projekcie? Jak zapewnić odpowiednią jakość systemu? Oczywistym jest fakt, że nie jest możliwe podanie precyzyjnych odpowiedzi na powyższe pytania na początkowych etapach projektów informatycznych. Jednakże, aby można przystąpić do projektów konieczne jest podanie co najmniej zgrubnych szacunków dotyczących wielkości projektu. W tym celu wprowadzono wiele metodologii, które podają wytyczne, w jaki sposób należy podejść do planowania i budżetowania projektów, a następnie realizacji zaplanowanych działań. W zakresie wytwarzania systemów czasu rzeczywistego zaproponowano metodologię ROPES Rapid Object Oriented Process for Embedded Systems [16]. 35

36 3.2 Pojęcia i definicje W zakresie definicji metodologii możemy wyróżnić szereg jej elementów tj.: definicja semantyki języka jakim będzie się posługiwać, lista oraz definicje aktywności, kolejność wykonania poszczególnych aktywności, podział na fazy, listę produktów poszczególnych faz. Elementem wyróżniającym poszczególne metodologie jest język opisujący model systemu. Wybrany język modelowania wykorzystany w poszczególnych faza projektu pozwala na wytwarzanie produktów, które następnie są wykorzystywane jako artefakty wyjściowe kolejnych aktywności. Rezultatem końcowym projektu powinien być system informatyczny spełniający wymagania wyspecyfikowane na początku projektu Etapy projektu W celu lepszego zarządzania procesem wytwarzania oprogramowania wprowadzono podział projektu na etapy. Umożliwia to lepszą kontrole nad zadaniami w projekcie oraz lepszą identyfikację problemów i zagrożeń. W przypadku projektów informatycznych tradycyjny podział obejmuje fazy: Analiza wymagań identyfikacja najważniejszych funkcji systemu oraz opracowanie możliwych do realizacji rozwiązań zadanego problemu. Projekt techniczny systemu opracowanie sposobu realizacji zidentyfikowanych wymagań, wyodrębnianie najważniejszych modułów oraz obiektów systemu, dostosowania architektury rozwiązania do wymagań pozafunkcjonalnych, np. wydajnościowych. Najważniejszym produktem tego etapu jest projektowy model systemu. Implementacja (translacja) oprogramowanie w wybranym języku programowania poszczególnych modułów zaprojektowanego systemu. Produktem końcowym jest wykonywalny kod, który może zostać uruchomiony na zadanej platformie sprzętowej. Testy systemu weryfikacja oraz walidacja, czy powstały system jest zgodny z zaakceptowanym projektem technicznym oraz spełnia wszystkie wymagania zidentyfikowane podczas etapu analizy. Uruchomienie i utrzymanie wdrożenie systemu, uruchomienie produkcyjne oraz utrzymanie jego działania zgodnie z zadanymi warunkami SLA (Service Level Agreement). We wszystkich powyższych fazach bazuje się na modelach systemu, odpowiednich do poziomu abstrakcji oraz szczegółowości niezbędnego opisu. Istotnym warunkiem nałożonym na powstające w kolejnych etapach modelach jest to, aby kolejne jego przybliżenia były zgodne z modelem wyjściowym. Zgodność modeli można rozumieć jako pewną relację homorficzną pomiędzy modelami. Z tego punktu widzenia model analizy, model projektu, model implementacji (w postaci kodu źródłowego), model testowy, nie stanowią różnych modeli w sposób dowolny powiązanych. Należy je traktować, jako różne modele opisujące ten sam system, z odmiennych perspektyw i różnym poziomem szczegółowości. Większość inżynierów i programistów potwierdza fakt, iż większość abstrakcyjnych modeli znacząco odbiega od modelu implementacyjnego. Doprowadza to do sytuacji, w której powstają dwa różne modele opisujące dwa różne systemy. Kwestią podstawową w metodologii ROPES jest założenie, że wszystkie produkty etapów (tj. modele) muszą opisywać ten sam system lub jego fragment. Oczywiście modele te mogą koncentrować się na różnych aspektach systemu, podobnie jak inżynierowie budowlani posiadają różne rzuty i widoki rysunku technicznego (podłogi, kondygnacji, instalacji elektrycznej, itd.), które jednak nadal opisują ten sam budynek. Etap analizy może zostać podzielona na kilka mniejszych faz: Analiza wymagań wyekstrahowanie wymagań klienta wobec systemu oraz zapisanie ich w ustrukturyzowanej formie. 36

37 Analiza systemowa budowa w sposób bardziej rygorystyczny modelu systemu bazującego na uzyskanych wymaganiach, obejmującego podział na domeny związanych z budowanym systemem (oprogramowanie, sprzęt, itd.). Faza jest istotna przede wszystkim w przypadku dużych systemów np. kontroli lotów. W przypadku małych systemów wbudowanych, ich architektura jest zdecydowanie prostsza, co umożliwia pominięcie tej fazy podczas projektu. Analiza obiektowa składa się z dwóch faz: o strukturalnej analizy obiektowej polega na identyfikacji i dekompozycji strukturalnych jednostek systemu, takich jak klasy i obiekty. Następnie zidentyfikowane jednostki organizowane są w pakiety, komponenty, które powiązane są ze sobą odpowiednimi relacjami. o Behawioralnej analizy obiektowej modeluje zachowanie dynamiczne zidentyfikowanych obiektów i klas. Należy podkreślić, iż analiza wymagań oraz analiza systemowa bazuje przede wszystkim na dekompozycji funkcjonalnej oraz behawioralnej systemu. Jednostkami strukturalnymi dekompozycji są stany, funkcje i aktywności. Elementy te są następnie organizowane w model systemu, który zostaje produktem fazy analizy, jako dokument specyfikacji systemu. Bardzo ważnym i nietrywialnym krokiem w fazie analizy jest przejście z analizy systemowej do analizy obiektowej. W kroku tym następuje mapowanie realizowanych funkcji na moduły i obiekty systemu. Podobnie jak w przypadku analizy, faza projektu technicznego może zostać podzielona na kilka mniejszych faz: Projekt architektury systemu służy do identyfikacji oraz organizacji fizycznych modułów systemu, które będą następnie uruchamiane na projektowanej platformie sprzętowej. Projekt architektury składa się z wielu elementów semantycznych zaczerpniętych przede wszystkim z języka UML. Do nich należy: widok rozmieszczenia (deployment view) prezentujący rozmieszczenie modułów wykonalnych na poszczególnych węzłach procesorach, widok współbieżności prezentujący diagram równoległej współpracy pomiędzy obiektami systemu. Warto dodać, iż widok rozmieszczenia organizuje także niewykonywalne elementy modelu np. dokumenty tekstowe. Pozwala to na lepszą organizacje pracy zespołów projektowych oraz ich członków. Projekt szczegółowy definiuje i organizuje strukturę poszczególnych klas systemu. Na tym etapie bardzo często stosuje się już wzorce projektowe wykorzystywane w fazie implementacji systemu. Produktem tej fazy procesu jest lista klas wraz z definicją ich atrybutów (typ, widoczność), specyfikacje metod realizujących określone funkcje oraz relacje pomiędzy poszczególnymi klasami. Faza projektu technicznego może być realizowana zgodnie z przyjętą strategią projektu. W szczególności można wskazać dwie najszerzej rozpowszechnione. Pierwsza, najbardziej popularna to podejście bazujące na kolejnych uszczegółowieniach modelu analitycznego. W tym podejściu informacje z fazy projektowej są dodawane do modelu analitycznego, aż do momentu uzyskania modelu, który może zostać zaimplementowany. Drugie podejście zakłada przygotowanie projektu systemu, który następnie jest kompilowany do wykonywalnego systemu. Podejście to bardzo często spotyka się w projektach, gdzie stosuje się specyficzne dla danej dziedziny narzędzia, które pozwalają na automatyczną translację zapisów analizy systemu do kodu wykonywalnego. Podejście to jest możliwe do zastosowania z wykorzystaniem pakietu Rhapsody, który bazuje na paradygmacie Executable UML. Temat ten będzie przedmiotem rozważań w dalszej części pracy. 37

38 Podejście uszczegóławiania generalnie nie wymaga zastosowania specjalnych narzędzi wspomagających, jednakże z doświadczeń wynika, iż etap analizy i projektu w takich przypadkach trwa znacznie dłużej. 3.3 Cykle życia projektu Kolejność realizacji poszczególnych etapów oraz aktywności w projekcie definiuje przyjęty dla danego przedsięwzięcia cykl życia lifecycle. W inżynierii oprogramowania najczęściej spotykanym podejściem jest cykl wodospadowy. W cyklu tym wszystkie etapy oraz fazy następują po sobie sekwencyjnie. Popularność tego podejścia wynika z jego prostoty, łatwości zarządzania oraz szerokiego wachlarza narzędzi wspierających. Bazując jednak na wynikach analiz przeprowadzonych projektów można jednoznacznie stwierdzić, iż zastosowanie tego modelu jest uzasadnione w przypadkach wdrożeń powtarzalnych, gdzie celem jest uruchomienie systemu na bazie gotowego produktu. W przypadku projektów informatycznych, gdzie produkt ma zostać dopiero wytworzony, model ten może skutkować nieoptymalnym wykorzystaniem zasobów przeznaczonych na projekt oraz znacznym przekroczeniem harmonogramu. Podejściem konkurencyjnym do wodospadowego jest iteracyjny cykl życia, w którym etapy projektu powtarzają się w zakresie poszczególnych cykli projektu. Ważną zaletą podejścia iteracyjnego jest możliwość wcześniejszej identyfikacji ryzyk w projekcie, pozwalającej na zastosowanie strategii minimalizacji ryzyka, które nie będzie tak kosztowne jak w przypadku podejścia kaskadowego Podejście kaskadowe wodospadowe Realizacja poszczególnych etapów projektu, jako sekwencyjnie następujących po sobie aktywności zdecydowanie ułatwia proces planowania projektu oraz stworzenie harmonogramu takiego przedsięwzięcia. Zakłada się, że kolejny etap może rozpocząć się dopiero po zakończeniu etapu poprzedzającego. Oznacza to, że faza projektu technicznego nie może się rozpocząć dopóki nie zostaną zakończone prace nad produktem (specyfikacją systemu) etapu analizy. Teoretycznie założenie to jest słuszne i uzasadnione, ponieważ nie można rozpocząć szczegółowego projektu bez kompletnej wiedzy na temat specyfikacji funkcjonalnej systemu. Praktyka pokazuje jednak, iż jest to założenie bardzo rzadko realizowalne. Ze względu na ograniczenia czasowe harmonogramu projektu, kierownictwo decyduje się na rozpoczęcie prac nad kolejnym etapem, pomimo braku finalnej wersji produktu fazy poprzedniej. Strategia taka określana jest jako zrównoleglanie (fasttracking). Decyzja o zastosowaniu zrównoleglenia automatycznie zwiększa ryzyko w projekcie związane z integracją i zgodnością produktów następujących po sobie etapów. Łatwo można sobie wyobrazić, iż projekt techniczny, który bazował na 80% analizy funkcjonalnej, musi być częściowo lub całkowicie zmieniony ze względu na modyfikacje w specyfikacji całego systemu związanych z nieuwzględnioną częścią funkcjonalną systemu. Podobna sytuacja może wystąpić po zakończeniu implementacji i wcześniejszym rozpoczęciu fazy testów, jednak na tym etapie zmiany w systemie będą dużo bardziej kosztowne. Konsekwencją takiego zdarzenia są w pierwszej kolejności opóźnienia w projekcie oraz przekroczenie budżetu planowanego na dany etap. W takich przypadkach pojawia się automatycznie presja na dotrzymanie harmonogramu projektu, co w większości przypadków skutkuje utratą jakości produktu końcowego. Dlatego też cykl kaskadowy projektów zaleca się stosować dla powtarzalnych wdrożeń systemów informatycznych, w którego zakresie jest niewielka ilość koniecznych do zaimplementowania zmian w systemie. Dzięki wiedzy wyniesionej z poprzednich wdrożeń tego typu, można realnie zaplanować harmonogram poszczególnych etapów, minimalizując ryzyko opóźnień spowodowanych koniecznością integracji produktów następujących po sobie etapów. 38

39 3.3.2 Podejście iteracyjne Rys Kaskadowy cykl życia projektu Iteracyjny cykl życia projektu jest próbą rozwiązania problemów występujących w podejściu kaskadowym, związanych przede wszystkim z niekompletnością produktów kolejnych faz. Proponuje się, aby finalne produkty nie wytwarzać w ramach jednego etapu, ale w ramach cyklicznie powtarzających się takich samych etapów. W wyniku takiego podejścia, model kaskadowy jest powtarzany cyklicznie tyle razy, ile jest konieczne do osiągnięcia odpowiedniej jakości produktów poszczególnych etapów. Każdy cykl powinien być zakończony powstaniem prototypu systemu. Uzyskuje się dzięki temu możliwość bardzo wczesnej weryfikacji założeń poczynionych podczas analizy oraz projektu technicznego. Podczas weryfikacji wyników poszczególnych iteracji możliwa staje się wczesna identyfikacja zagrożeń i ryzyk, zwłaszcza związanych z parametrami wydajnościowymi rozwiązania, co w przypadku systemów czasu rzeczywistego ma istotne znaczenie. Prezentacja wyników kolejnych iteracji użytkownikowi końcowemu pozwala na weryfikacje poprawności zrozumienia jego wymagań oraz daje możliwość wprowadzenia modyfikacji, które lepiej będą spełniać wymagania i jednocześnie będą atrakcyjniejsze dla użytkownika. Niestety podejście iteracyjne znacznie utrudnia proces zarządzania projektem. Ze względu na iteracyjność procesu, zespół projektowy ma możliwość bardziej elastycznego definiowania zakresu produktów kolejnych cykli, przesuwając zadania nietrywialne na następne cykle. W przypadku zadań trudnych i długotrwałych podejście takie może doprowadzić do nieefektywnego zwiększenia liczby iteracji, a w efekcie do przedłużenia harmonogramu. Koniecznym staje się ciągłe monitorowanie postępów prac w projekcie oraz odpowiednie ustalenie kryteriów odbiorów prototypów kolejnych cykli. Niemniej jednak odpowiedzialność za monitoring oraz kontrole postępu w projekcie, w przypadku podejścia iteracyjnego jest znacznie większa i wymaga większego zaangażowania kierownika projektu aniżeli w podejściu kaskadowym. W literaturze można znaleźć wiele pozycji, które dokładnie opisują podejście iteracyjne. Jedna z wcześniejszych pozycji Barrego Bohema [7] wprowadza pojęcie modelu spiralnego, który jest realizacją opisanego modelu iteracyjnego. 39

40 3.3.3 Prototypowanie Rys Spieralny cykl życia projektu Prototyp systemu stanowi instancje modelu systemu. W kontekście oprogramowania, prototypy są najczęściej jednostkami wykonywalnymi w pewnym zakresie funkcjonalnym. Prototypy mogą być przeznaczone do jednorazowego wykorzystania lub iteracyjne. Prototypy jednorazowego użytku służą jedynie do weryfikacji poczynionych założeń i nie przewiduje się ich wykorzystania jako cześć produktu końcowego. Za przykład takiego prototypu może posłużyć makieta interfejsu użytkownika. Taką makietę można stworzyć przy pomocy narzędzi graficznych lub dowolnego graficznego edytora GUI np. dla systemu Windows. Makieta ma za zadanie jedynie zaprezentować interfejs przyszłemu użytkownikowi oraz programistom, którzy mają za zadanie oprogramować dany interfejs. Prototyp iteracyjny z założenia ma stanowić cześć produktu końcowego. Niejednokrotnie prototyp taki jest rozbudowywany w kolejnych iteracjach i po zakończeniu wszystkich cykli stanowi produkt końcowy. Oznacza to, iż w odróżnieniu od prototypu jednorazowego, należy zapewnić znacznie większą jakość wytwarzanego w ramach prototypu oprogramowania. Dotyczy to języka programowania, konwencji formatowania kodu źródłowego, podziały na moduły, itd. Prototyp spełniający finalne kryteria odbioru zostaje przekazany do użytkownika jako produkt końcowy. Po jego uruchomieniu, prototyp nadal jest rozbudowywany i uzupełniany w zakresie etapu utrzymania i rozwoju systemu. Każdy prototyp powinien mieć zdefiniowaną misję, którą powinien realizować. Przykładem takiej misji może być weryfikacja założeń wydajnościowych systemu, zminimalizowanie ryzyka integracji z systemami zewnętrznymi, weryfikacja założeń dotyczących architektury systemu, realizacja danego przypadku użycia, przygotowanie systemu do testów alfa lub beta. Większość wytwarzanych obecnie systemu informatycznych posiada wielowarstwową architekturę. Dotyczy to także systemów czasu rzeczywistego, a poszczególne warstwy są związane z obsługiwanymi urządzeniami zewnętrznymi poprzez warstwę sterowników, wykorzystywanym RTOS oraz udostępnianymi interfejsami. Podejście takie jest zgodne z podziałem na poszczególne domeny systemu, które najczęściej reprezentują różne poziomy abstrakcji modelu. W przypadku, gdy prototyp ma za zadanie zrealizować dany przypadek użycia, konieczne jest oprogramowanie wszystkich warstw systemu, niezbędnych do realizacji danej funkcjonalności. Strategia implementacji realizowanej zgodnie z powyższym podejściem określana jest mianem wertykalnej. Podejście takie nazywane jest czasem 40

41 implementacja iteracyjną. W konsekwencji projektując system konieczne jest podejście horyzontalne, które dzieli system na poziome warstwy, natomiast realizować poszczególne funkcjonalności należy wertykalnie rysunek 3.3. Rzeczywiste zastosowanie iteracyjnego prototypowania wymaga zastosowania odpowiednich narzędzi umożliwiających automatyczną translację z opisu modelu systemu do postaci kodu wykonywalnego. Posiadanie wykonywalnego prototypu jest krytyczne dla procesu weryfikacji własności systemu. Bez możliwości uruchomienia danego modułu nie ma możliwości faktycznej weryfikacji poczynionych założeń. Pojawia się jednak problem budowy takiego prototypu oraz ciągłego wprowadzania zmian podczas jego budowy. W przypadku dużych systemów oznacza to konieczność stworzenia kilkuset klas oraz implementacji kilkunastu diagramów stanów. W przypadku narzędzia wspierającego automatyczną translację, proces ten wykonywany jest automatycznie przez odpowiednie narzędzie, a projektant może skoncentrować się na uruchomieniu i weryfikacji powstałego modelu. Rys Prototypowanie wertykalne 3.4 Harmonogramowanie i estymacja Jednym z trudniejszych elementów planowania projektów informatycznych jest niewątpliwie harmonogramowanie oraz estymacja poszczególnych zadań w projekcie. Regularnie prowadzone badania dowodzą, iż przez ostatnie dziesięciolecie polepszyły się statystyki dotyczące trafności szacunków czasu trwa projektów oraz ich budżetów. Niezależnie od poczynionych postępów nadal występują spore trudności związane z poprawnym określeniem czasu trwania projektów. W celu wyjaśnienia tego zjawiska powstało wiele teorii oraz opracowań. Zgodnie z definicją wprowadzoną przez instytut PMI projekt jest tymczasowym przedsięwzięciem, którego celem jest wytworzenie unikalnego produktu lub usługi. Definicja ta oczywiście dotyczy także projektów informatycznych. Analizując projekt jako przedsięwzięcie, można podać mniej formalnie jego najważniejsze własności: Projekt jest realizowany przez ludzi. Jest ograniczony liczbą dostępnych zasobów. Projekt jest planowany, wykonywany oraz kontrolowany. Ograniczona liczba zasobów, którymi dysponujemy ma największe znaczenie podczas planowania oraz realizacji projektów. Estymacja oraz harmonogramowanie w projekcie informatycznym należy do etapu planowania i najczęściej poprzedza fazę realizacji danego etapu projektu. Należy jednak 41

42 zwrócić uwagę, iż estymacja oraz jej uaktualnienia powinny być procesem ciągłym podczas trwania projektu. Jest to niezbędne do efektywnego śledzenia postępu prac i pozwala na wcześniejszą identy fikację ryzyk w projekcie. W projekcie informatycznym najczęściej szacowaniu podlegają następujące wielkości niezbędne do odpowiednie skonstruowania harmonogramu projektu: Wielkość systemu wielkość wymagań, funkcji, modułów, produktów, liczba linii kodu itd. Czas realizacji czas realizacji projektu przy danych zasobach SLIM Price S oraz SEER SEM, CostXpert, Costar, REVIC, Checkpoint Koszt projektu najczęściej liczony w osobodniach lub roboczogodzinach koszt realizacji pro jektu z rozbiciem na poszczególne etapy W wyniku wielu prac badawczych wprowadzono do zastosowania wiele modeli estymacji powyżej wymienionych wielkości. Najpopularniejsze z nich to: COCOMO / COCOMO II Wszystkie wymienione wyżej modele wymagają dużej ilości rzeczywistych danych o przeprowadzo estymacje należy wprowadzić do modelu informacje, które mają wpływ na wielkość projekty. Informacje te nych projektach w celu ich wyskalowania dla danego przedsiębiorstwa. Przeprowadzając dzielimy na trzy grupy: wielkość systemu, złożoność projektu oraz czynniki ryzyka. Rys Proces estymacji wielkości projektu Najtrudniejszą do oszacowania wartością podczas estymacji jest wielkość systemu. Wartość tą najczęściej wyraża się w ilości linii kodu, ilości modułów, punktach lub obiektach funkcyjnych. Obecnie najczęściej stosowaną wielkościąą są punkty funkcyjne. Bazując na wymaganiach funkcjonalnych po Z opi zwalają na początkowym etapie projektu oszacować wartości niezbędne do dalszej estymacji. sanego wyżej procesu estymacji wynika bardzo istotna informacja. Lista wymagań funkcjonalnych jest krytyczna dla otrzymania poprawnych szacunków wielkości projektu. Dane wejściowe niskiej jakości prowadzą do otrzymania błędnych oszacowań, a co z kolei doprowadzi do złego zaplanowania projektu. Analizując dane dotyczące projektów informatycznych można zaobserwować pewną regularność. Dla systemów o złożoności powyżej 1500 FP ryzyko w projekcie dramatycznie rośnie (patrz tabela 3.1 oraz rysunek 3.5). Zjawisko to jest obserwowane jako znaczne zwiększenie ilości projektów zakoń du czonych niepowodzeniem (przekroczony budżet lub termin, projekty porzucone). W przypadku żych projektów należy brać pod uwagę podaną prawidłowość i starać dzielić projekt na mniejsze etaniż 1500 py (cykle), w których złożoności produkowanych części systemu/prototypów jest mniejsza FP. 42

43 Projekt Mały program FP przed terminem zakończenie projektu w terminie po terminie porzucone do 10 14,68% 83,15% 1,92% 0,25% Przeciętna aplikacja 10 11,08% 81,25% 5,67% 2,00% Duża aplikacja 100 6,06% 74,77% 11,83% 7,34% Program komercyjny ,24% 60,76% 17,67% 20,33% System informatyczny ,14% 28,03% 23,83% 48,00% Duży system informatyczny ,00% 13,56% 21,33% 65,00% Tabela 3.1 Zestawienie zakończonych projektów fp 1000 fp 10 fp 100 fp 1000 fp fp fp użytkowe outsourcing komercyjne ZSZ wojskowe systemowa 10 fp Rys Prawdopodobieństwo niepowodzenia w projekcie w zależności od jego złożoności Błędne oszacowania wielkości projektów są najczęściej przyczyną ich niepowodzeń. Błędy popełniane podczas estymacji wielkości projektu można podzielić na kilka kategorii. Najważniejsze z nich to: Błędy metody: o Brak odniesienia do poprzednich projektów przeprowadzonych w danej organizacji. o Stosowanie tylko jednej metody bez możliwości weryfikacji z wynikami innych metod. o Brak ciągłego uaktualniania estymacji i porównania z rzeczywistymi wielkościami po zakończeniu projektu. o Brak stosowania jakiejkolwiek metody estymacji. o Szacowanie w celu dostosowania wielkości do oczekiwań sponsora projektu, klienta, udziałowców, price to win itd. Błędy społeczne: o Nadmierny optymizm w stosunku do dostępności i kompetencji zespołu projektowego. 43

44 o o o Przecenianie wpływu narzędzi i nowych technologii. Brak odniesieni do krzywej uczenia się zespołu projektowego. Utajnianie złych informacji przed przełożonymi. Błędy organizacyjne: o Brak doświadczonych kierowników projektów. o Rozproszenie odpowiedzialności w strukturze organizacyjnej, brak jasnych ścieżek raportowania. o Rozproszenie zespołu projektowego. o Nieodpowiednie narzędzia i technologia. Podczas tworzenia harmonogramu należy uwzględnić wcześniej opracowane estymacje dotyczące wielkości systemu, złożoności projektu oraz zidentyfikowane ryzyka. Proces tworzenia harmonogramu przebiega w kilku etapach. W modelowym przypadku proces ten wygląda następująco: Opracowanie struktury podziału prac WBS (Work Breakdown Structure) dla danego projektu. Wyróżniamy dwa rodzaje WBS: produktowy oraz fazowy. Produktowy dzieli wyniki prac w projekcie na mniejsze moduły. Fazowy dzieli projekt na poszczególne etapy i fazy. Ostatni poziom WBS pakiety prac (work packages) są dzielone na poszczególne aktywności/zadania. Przyjmuje się, że jeden pakiet prac zawiera około 8 osobodni pracy. Na podstawie zadań zdefiniowanych w poprzednim punkcie tworzy się sieć powiązań pomiędzy zadaniami. Stosuje się cztery rodzaje zależności pomiędzy zadaniami: start to start, start to finish, finish to finish oraz finish to start. Do sieci wprowadza się estymacje czasu trwania zadania. W przypadku złożonych projektów można zastosować sieć PERT, w której podaje się trzy wartości czasu trwania zadania: optymistyczną, oczekiwaną i pesymistyczną. Wtedy oczekiwany czas wykonania czynności podaje się jako: 4 6 Na podstawie powiązań pomiędzy zadaniami oraz oczekiwanymi czasami trwania zadań oblicza się ścieżkę krytyczną projektu oraz rezerwy czasu pomiędzy zadaniami. Długość ścieżki krytycznej wyznacza najkrótszy czas trwania projektu przy danych założeniach. Na podstawie otrzymanej sieci, przechodzi się do wykresu Gantta, który stanowi standardową reprezentację harmonogramu projektu. Do tak stworzonego harmonogramu wprowadza się następnie informacje dotyczące dostępnych zasobów. Najczęściej stosuje się metody heurystyczne przydziału zasobów. W większości przypadków prowadzi to do wydłużenia harmonogramu. Podział projektu na etapy powinien odzwierciedlać przyjęty dla danego projektu cykl życia. W przypadku metodologii ROPES, która bazuje na podejściu iteracyjnym, harmonogram będzie składał się z kilku powtarzających się cykli o podobnych zadaniach (analiza, projekt techniczny, translacja, testy). Mówiąc obrazowo, harmonogram będzie prezentował sekwencje zadań, które powstają poprzez rozciągnięcie spirali na osi czasu. Ważnymi punktami milowymi, które będą wyraźnym miernikiem postępu prac w projekcie będą zakończenia poszczególnych cykli iteracji. Dla projektów informatycznych o podobnej złożoności stosunek długości trwania poszczególnych etapów do całkowitej jego długości jest bardzo zbliżony. Wykres 3.6 prezentuje stosunek długości etapów od złożoności projektu. Należy zwrócić uwagę, że zmiana złożoności projektu wpływa na strukturę podziału pracy w projekcie. 44

45 Procent czasu projektu 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Testy systemowe Testy integracyjne Testy jednostkowe Kodowanie Projekt techniczny Analiza Wielkość projektu w KLOC Rys Zależność podział czasu poszczególnych etapów w projekcie od jego złożoności Następna konstatacja dotyczy zmian, które zachodzą w strukturze prac w wyniku rozwoju technologii i narzędzi wykorzystywanych w projektach informatycznych. Dla przykładu w roku 1980 pisanie kodu oprogramowania stanowiło około 60% całego czasu realizacji projektu, natomiast obecnie wynosi około 15% [7]. Przewiduje się, iżż w niedalekiej przyszłości, pisanie kodu będzie zajmować jedynie 5% [16], a większość prac będzie koncentrować się na analizie wymagań oraz projekcie technicznym. Stanowi to trend, w który wpisuje się także metodologia ROPES oraz Execute UML. Translacja modeli projektowych do prototypów oznacza minimalizację prac związanych z ręcznym pisaniem kodu źró dłowegoo systemów informatycznych. 70% 60% 50% 40% 30% 20% 10% 0% Przyszłość Obecnie Obecnie Przyszłość Rys Zmiana podziałów czasu etapów 45

46 3.5 Makro cykle w metodologii ROPES Metodologia ROPES bazuje na podejściu iteracyjnym oraz wykorzystuje standardowy metamodel języka UML jako podstawę semantyczną i bazową notację opisu modeli systemu. Wspiera automatyczną generację kodu źródłowego w celu wsparcia procesu prototypowania, jednakże nie jest to wymaganie konieczne. Rysunek 3.8 prezentuje bazową koncepcję procesu wytwarzania oprogramowania bazującego na ROPES. Rys Model spiralny w metodologii ROPES Podejście iteracyjne stosowane w metodologii ROPES składa się z trzech poziomów zagnieżdżonych cylki: Marko cykle zawierające główne etapy projektu lub budowany koncepcji. Mikro cykle o długości trwania wystarczającej do stworzenia nowej wersji prototypu lub systemu, realizującego zakładaną na daną iterację funkcjonalność. Nano cykle pozwalający na implementacje, uruchomienie oraz przetestowanie bardzo małej części systemu. Cykl ten powinien trwać od 1 2 godzin. Celem wprowadzenia metodologii ROPES jest poprawa dotychczasowych praktyk stosowanych w zakresie wytwarzania systemów czasu rzeczywistego. W szczególności głównymi celami ROPES są: Zwiększenie jakości produktu końcowego. Zwiększenie przewidywalności oraz powtarzalności procesu tworzenia oprogramowania. Zmniejszenie ilości zasobów niezbędnych do wykonania produktu końcowego z zakładaną jakością. 46

47 W celu osiągnięcia zakładanych celów zdefiniowano odpowiednie etapy, fazy, aktywności oraz artefakty związane z procesem. Aktywności pogrupowane zostały w odpowiednie fazy zgodnie ze zdefiniowanym dla danego etapu poziomem abstrakcji. Wymiernym rezultatem zakończenia poszczególnych faz są artefakty. Główne artefakty w procesie ROPES zostały przedstawione na rysunku 3.9. Zgodnie z wcześniej podanymi definicjami, produktami poszczególnych faz są artefakty, które stanowią różne widoki na ten sam system tzw. modele systemu. Prototyp zawiera nie tylko moduły uruchamialne, ale także artefakty niezbędne do jego wygenerowania lub wytworzenia. Rys Główne etapy oraz artefakty metodologii ROPES Każdy prototyp w procesie ROPES jest zorganizowany wokół przypadków użycia systemu. Jeżeli tylko pewien zbiór przypadków użycia został zidentyfikowany oraz scharakteryzowany, zostaje on skategoryzowany w celu optymalizacji wykorzystanych zasobów. Optymalna kategoryzacja bazuje na następujących własnościach danego przypadku użycia: Priorytet. Szacowane ryzyko. Część wspólna z innymi przypadkami użycia. Dla przykładu załóżmy, że zadaniem zespołu jest opracowanie oraz implementacja wbudowanego protokołu komunikacyjnego, który bazuje na siedmiowarstwowym modelu ISO [17]. Zakłada się, że protokół ten musi być zaimplementowany dla kilku procesorów, wykorzystujących kilka różnych 47

48 RTOS oraz różne kompilatory. Platforma sprzętowa zakłada wykorzystanie różnorodnych procesorów 16 oraz 32 bitowych, jak również procesorów DSP. Dodatkowo zakłada się, że niektóre moduły będą zaimplementowane w języku C, natomiast inne w języku C++. Ze względu na konieczność wykorzystania wspólnego kodu źródłowego przez cały zespół, należy zidentyfikować to jako wczesne ryzyko projektowe. Uzgodniono, że do stworzenia modelu obiektowego oraz jego implementacji zostanie wykorzystany standardowy język C, który jest także kompatybilny z językiem C++. Następnie przygotowano kolejne prototypy, które w procesie iteracyjnym realizowały zakładane cele. Dla przykładu pierwszy prototyp zakładał stworzenie prostego programu Hello World dla wszystkich docelowych platform sprzętowych. Dzięki czemu kolejne prototypy były możliwe do uruchomienia na wszystkich platformach jedynie po wprowadzeniu niezbędnych translacji opracowanych dla pierwszego prototypu. W następnych punktach rozdziału przedstawiono szczegółowo opis poszczególnych etapów procesu ROPES ze szczególnym uwzględnieniem aktywności oraz poszczególnych artefaktów. 3.6 Analiza Etap analizy ma za zadanie zidentyfikować wszystkie wymagania stawiane przed tworzonym systemem. Wyniki analizy będą stanowiły podstawę dla kolejnych etapów projektu oraz punkt odniesienia, czy końcowy produkt jest zgodny z wymaganiami użytkownika. Rysunek 3.10 prezentuje poszczególne podetapy fazy analizy oraz ich produkty, obejmujące artefakty wygenerowane oraz wyprodukowane w ramach poszczególnych aktywności. Rys Fazy oraz artefakty etapu analizy 48

49 3.6.1 Analiza wymagań Celem analizy wymagań jest zidentyfikowanie oraz strukturyzacja wymagań klienta wobec projektowanego systemu. Klientem może być dowolny użytkownik, który posiada wiedzę na temat dziedziny modelowanej przez system. Osiągnięcie pełnej, kompletnej, niesprzecznej listy wymagań nie jest zadaniem trywialnym. Użytkownicy systemu biorący udział w analizie wymagań najczęściej posiadają wiedzę fragmentaryczną, nieobejmującą całego modelowanego systemu. Prowadzi to do powstania niekompletnych lub co gorsza sprzecznych wymagań funkcjonalnych. Niejednokrotnie wymagania stawiane przez użytkowników są nierealizowalne lub bardzo kosztowne. Pojawia się także problem użytkownika eksperta, który nie specyfikuje pewnych wymagań, zakładając, że są one oczywiste. Drugim ważnym źródłem trudności w otrzymaniu poprawnej listy wymagań to tendencja użytkowników do rozwiązywania ich problemów w zadany przez nich sposób. Bardzo często zaproponowane przez nich rozwiązanie nie jest optymalne dla zadanego problemu. Jeżeli produkt końcowy będzie tym, o co prosił klient, jednak niespełniający jego wymagań, będzie to wynikiem błędów popełnionych na etapie analizy wymagań. Należy zwrócić uwagę na fakt, iż analiza wymagań nie prowadzi do identyfikacji obiektów oraz klas. Podczas analizy wymagań porusza się w obszarze semantyki funkcjonalnej, analizy behawioralnej oraz przypadków użycia. Dopiero następny etap analiza obiektowa, dotyczy identyfikacji klas oraz relacji między nimi Aktywności i artefakty Główne aktywności związane z fazą analizy wymagań to: Identyfikacja przypadków użycia oraz aktorów. Dekompozycja przypadków użycia z wykorzystanie relacji generalizacji, rozszerzenia oraz użycia. Identyfikacja oraz charakteryzacja zewnętrznych zdarzeń wpływających na system. Definiowanie scenariuszy zachowań, które określają specyfikację dynamiczną systemu. Identyfikacja wymagań wydajnościowych, interfejsów oraz ograniczeń systemu. Podczas analizy wymagań są przede wszystkim używane diagramy przypadków użycia. Większość systemów posiada trzy rodzaje przypadków użycia: główne opisujące widoczne dla obserwatora zewnętrznego funkcjonalności systemu, dodatkowe opisujące funkcjonalności nieobserwowalne oraz związane z niezawodnością systemu oraz przypadki związane z bezpieczeństwem systemu. Istotnym jest, aby podczas analizy wymagań traktować system jako czarną skrzynkę. Na tym etapie nie interesuje nas organizacja wewnętrzna systemu. Co więcej, same przypadki użycia nie umożliwiają automatycznego przejścia do widoku białej skrzynki. Zgodnie z tym, co zostało przedstawione wcześniej, zadanie to nie jest trywialne i jest przedmiotem analizy obiektowej. Zidentyfikowane przypadki użycia pozwalają na przejście do opracowania scenariuszy zachowania systemu instancji przypadku użycia. Definiowanie scenariuszy jest podstawowym sposobem na identyfikację wymagań. Pozwala na ekstrahowanie najważniejszych funkcji systemu oraz niejednokrotnie ujawnia konieczność wprowadzenia kolejnych scenariuszy. Zdarzenia zachodzące w otoczeniu systemu i mające wpływ na jego działanie także powinny być zidentyfikowane oraz scharakteryzowane podczas etapu analizy wymagań. Zakłada się, że zdarzenia 49

50 będą przekazywane do systemu przez aktorów za pomocą komunikatów, jak również system będzie odpowiadał aktorom wysyłając komunikaty zwrotne. Komunikaty charakteryzują się następującymi własnościami: Powiązani aktorzy: o Nadawca komunikatu. o Odbiorca komunikatu. Wzorzec okresowości komunikacji (periodyczne, przypadkowe). Wzorzec czasu komunikacji: o Okres dla komunikatów periodycznych. o Minimalny okres pomiędzy komunikatami lub długość komunikatów przypadkowych. Własności komunikacji zwrotnej: o Nieprzekraczalny termin odpowiedzi dla twardych warunków czasowych. o Średni czas odpowiedzi dla miękkich warunków czasowych. Informacja o stanie: o Niezmienniki warunków wstępnych komunikatu. o Protokół. o Dane komunikatu. o Inwarianty warunków wyjściowych odpowiedzi. Powyższe informacje są najczęściej przedstawiane za pomocą diagramów sekwencji lub stanów powiązanych z danym przypadkiem użycia. Podczas fazy analizy wymagań powstaje wiele produktów artefaktów. Ich lista została przedstawiona w tabeli 3.2. Artefakt Reprezentacja Opis Dokument analizy wymagań Przypadki użycia Tekst Diagramy przypadków użycia Diagramy stanowe Lista zdazeń zewnętrznych Tekstowy opis zawartości systemu, interfejsów, aktorów zewnętrznych, dynamikę, ograniczenia, włączając wymagania w zakresie bezpieczeństwa systemu. Identyfikacja głównych obszarów funkcjonalnych systemu oraz interakcji pomiędzy aktorami i przypadkami użycia. Opis behawioralnych dla reaktywnych przypadków użycia. Lista powinna zawierać listę zdarzeń, które zachodzą w otoczeniu i są istotne dla systemu oraz te, które system generuje wraz z ich atrybutami: trybem aktywacji, okresem, danymi itd. 50

51 Scenariusze przypadków użycia Diagram kontekstu (obiektów) Diagramy sekwencji Idiomatyczne użycie diagramu obiektów UML, gdzie system jest identyfikowany jako jeden obiekt. Pozostałe obiekty stanowią zewnętrzni aktorzy, systemy itd. Reprezentacja specyficznych scenariuszy przypadków użycia za pomocą sekwencji zdarzeń, komunikacji pomiędzy obiektami, itd. Diagramy czasowe Reprezentacja poszczególnych scenariuszy przypadków użycia z wykorzystaniem osi czasu wraz z identyfikacją aktualnego stanu systemu. Analiza zagrożeń Testowe zestawy danych Tekst Tekst Najczęściej w formacie dokumentu tekstowego zawierającego listę zagrożeń wraz z opisem ich atrybutów, tolerancji występowania, wpływu na system oraz otoczenie, prawdopodobieństwo występowania, itd. Specyfikacja scenariuszy oraz danych testowych, walidująca działanie systemu zgodne z wymaganiami. Tabela 3.2. Artefakty etapu analizy wymagań Dla niektórych systemów, zwłaszcza dużych i złożonych, konieczne jest stworzenie wszystkich wymienionych artefaktów. Mniejsze systemy wymagają stworzenia tylko niektórych z nich Metamodel encji Dwa rodzaje elementów metamodelu są wykorzystywane podczas analizy wymagań: elementy kontekstowe oraz elementy behawioralne. Należy pamiętać, iż faza analizy traktuje system jako czarną skrzynkę, czyli struktura wewnętrzna systemu jest całkowicie pomijana podczas analizy. Analizie podlega jedynie ta część systemu, która jest widoczna dla obserwatora z zewnątrz. Elementy kontekstowe wykorzystywane podczas analizy wymagań to: Aktorzy (obiekty, które istnieją poza zakresem naszego systemu). Obiekt systemu (jeden obiekt reprezentuje cały system lub istotne moduły rozpoznawalne przez obserwatora zewnętrznego). Przypadki użycia. Relacja pomiędzy przypadkami. 51

52 Komunikaty zewnętrzne (włączając zdarzenia). Zagrożenia i ryzyka. Relacje mogą występować pomiędzy przypadkami użycia i aktorami oraz pomiędzy innymi przypadkami użycia. Przypadki użycia najczęściej opisują zachowanie systemu w sytuacjach wyjątkowych, widocznych dla aktorów. Aktorzy natomiast są obiektami spoza zakresu przypadku użycia systemu, na przykład użytkownicy systemu, urządzenia, z którymi systemu musi współpracować lub inne systemy informatyczne. Pomiędzy aktorami a przypadkami użycia występuje relacja asocjacji. Asocjacja pomiędzy aktorami i przypadkami użycia oznacza, że aktorzy mogą wysyłać oraz otrzymywać komunikaty, które są częścią scenariusza danego przypadku użycia. Identyfikacja zagrożeń jest krytyczna dla bezpieczeństwa systemu, w szczególności dla systemu czasu rzeczywistego. W wersji minimalnej należy zdefiniować zagrożenia oraz powiązane z nimi ryzyka. Często opis zagrożenia obejmuje także pomiar bezpieczeństwa, jeżeli jest mierzalne, pomimo iż najczęściej tego typu oszacowania dokonuje się na etapie projektu technicznego. Elementy behawioralne obejmują: Ograniczenia oraz wymagania wydajnościowe. Diagramy stanów. Scenariusze. Protokoły komunikatów w scenariuszach aktor system. Elementy behawioralne prezentują sposób w jaki zachowuje się system, ale tylko z pespektywy czarnej skrzyni. Najpopularniejszym elementem wykorzystywanym podczas specyfikowania protokołów komunikacji oraz scenariuszy przypadków użycia są diagramy stanów. Zaletą maszyn stanowych jest ich kompletność. Umożliwia to specyfikowanie pełnej dynamiki powiązanego z nim elementu kontekstowego. W przeciwieństwie do diagramów stanu, scenariusze specyfikują jedynie jeden z wariantów zachowania systemu. Z tego powodu scenariusze mogą być wykorzystane do przedstawienia jeden z kilku ścieżek maszyny stanowej np. ważnych z punktu widzenia analizy wymagań, lub w przypadku, kiedy zachowanie systemu nie jest sterowane aktualnym stanem systemu Analiza systemowa Analiza systemowa jest istotną fazą projektu, zwłaszcza w przypadku dużych oraz skomplikowanych systemów czasu rzeczywistego. Podczas tej fazy najczęściej opracowane zostają najważniejsze algorytmy, natomiast zidentyfikowane wymagania zostają podzielone na elektroniczne, mechaniczne oraz programowe komponenty systemu. Często podczas analizy systemowej wykorzystuje się narzędzia do specyfikacji dynamiki systemu takie jak: Simulink [82] oraz Statemate [73]. Narzędzia te pozwalają na stworzenie modeli wykonywalnych w celu weryfikacji poprawności zachowania budowanego systemu. Podobnie jak analiza wymagań, analiza systemowa nie dokonuje identyfikacji obiektów oraz klas należących do wewnętrznej struktury systemu. Wprawdzie następuje podział systemu na poszczególnie komponenty, jednakże podział tem dotyczy przede wszystkim fizycznej realizacji systemu. Zidentyfikowane komponenty pozostają nadal blokami funkcjonalnymi, które traktujemy jako czarne skrzynki Aktywności oraz artefakty Podstawowe aktywności fazy to: Identyfikacja głównych komponentów oraz organizacji systemu. 52

53 Budowa oraz analiza specyfikacji behawioralnej głównych komponentów systemu. Podział wymagań funkcjonalnych na trzy odrębne dyscypliny: o Oprogramowanie o Elektronika o Mechanika Testowanie dynamiki systemu na bazie wykonywalnych modeli. Organizacja systemu realizowana podczas analizy systemowej prowadzi do wyodrębnienia modułów funkcjonalnych nazywanych komponentami. Podczas tej fazy konieczne jest utworzenie specyfikacji interfejsów poszczególnych komponentów, przynajmniej na bardzo wysokim poziomie. Jest to konieczne w celu umożliwienia współpracy inżynierom odpowiedzialnym za poszczególne dyscypliny, pracującymi nad wyodrębnionymi komponentami. Analiza behawioralna jest realizowana poprzez badanie własności maszyn stanowych lub matematycznych modeli systemów ciągłych. W niektórych przypadkach jest to kombinacja dwóch powyższych. Dla systemów reaktywnych oznacza to konieczność opracowania wielu, niejednokrotnie skomplikowanych skończonych maszyn stanowych oraz analizę ich własności. Dla modeli sterowania ciągłego mamy najczęściej do czynienia z typowymi sterownikami (np. PID), modelującymi żądaną dynamikę systemu poprzez jego odpowiednie sterowanie. W przypadku skomplikowanych systemów czasu rzeczywistego, istotne jest, aby analizę dynamiki systemu weryfikować na podstawie wykonywalnych modeli. Pozwala to na sprawdzenie, czy specyfikacja jest poprawna, jednoznaczna oraz kompletna. Błędy popełnione na tym etapie projektu są bardziej kosztowne niż pojawiające się w późniejszych etapach projektu. Niejednokrotnie poprawa błędu w specyfikacji systemu oznacza zmianę implementacji wielu komponentów, a następnie ich ponowne przetestowanie. Wczesne dowodzenie poprawności specyfikacji, zwłaszcza przy użyciu metod formalnych znacząco minimalizuje ryzyko powstania takich nieprzewidzianych kosztów w projekcie. Wszelkie testy zaprojektowane podczas analizy systemowej powinny zostać tak skonstruowane, aby można było je wykorzystać podczas testów zaimplementowanego systemu. Oznacza to nie tylko redukcje kosztów związanych z tworzeniem scenariuszy testowych, ale przede wszystkim pozwala na weryfikację poprawnej implementacji systemu. Poniżej przedstawiono listę produktów fazy analizy systemowej. Artefakt Reprezentacja Opis Model architektury Specyfikacja wykonywalna Diagramy wdrożenia Diagramy komponentów Maszyny stanowe Modele matematyczne Identyfikacja fizycznych komponentów, na których będzie uruchamiane oprogramowanie. Identyfikacja modułów funkcjonalnych, które potencjalne będą osadzone na wykonywalnych komponentach oznaczonych stereotypem <<device>>. Definicja skończonych maszyn stanowych na poziomie komponentów. Matematyczny opis modeli systemu np. model systemu ze sterownikiem PID. 53

54 Specyfikacja oprogramowania Specyfikacja platformy sprzętowej Zbiór danych testowych Diagramy aktywności Diagramy sekwencji Tekst Tekst Diagramy sekwencji Plan testów Diagramy aktywności UML reprezentują współbieżne diagramy przepływu. Ich głównym zadaniem jest modelowanie działania współbieżnego, podobnie jak sieci Petriego oraz specyfikacja skomplikowanych algorytmów. Prezentacja ważnych scenariuszy na przestrzeni stanów systemu. Szczegółowe wymagania, odpowiedzialności oraz zachowanie wymagane od systemu. Szczegółowe wymagania, odpowiedzialność oraz zachowanie platformy sprzętowej systemu. Scenariusze testowy wykonywane zgodnie z założonym planem testów. Plan w jaki sposób system będzie testowany, aby zapewnić zgodność jego działania z wymaganiami funkcjonalnymi Metamodel encji Tabela 3.3. Artefakty etapu analizy systemowej Podczas analizy systemowej wykorzystywane są zarówno elementy strukturalne oraz behawioralne. Komponenty strukturalne są wykorzystywane w celu podziału funkcjonalności systemu na odpowiednie bloki funkcjonalne. Bardzo często podczas analizy systemowej wprowadza się pojęcie podsystemu (subsystem). Język UML przewiduje odpowiednie oznaczenie graficzne dla wyróżnienia obiektu podsystemu. UML nie przewiduje możliwości specyfikacji zależności matematycznych dla systemów ciągłych. W takich przypadkach najlepiej wykorzystać opisy w postaci równań lub opis przy użyciu pseudokodu. Diagram aktywności może zostać wykorzystany do przedstawienia algorytmu działania danego komponentu. Ograniczenia wydajnościowe powinny zostać określone podczas analizy systemowej i być przypisane do poszczególnych komponentów systemu Analiza obiektowa Analiza obiektowa ma za zadanie identyfikację obiektów i klas w systemie oraz ich najważniejszych własności. Poprzednia faza definiowała wymaganą dynamikę systemu. Wymagania te muszą zostać zrealizowanie poprzez odpowiednią strukturę wewnętrzną systemu. Jest to pierwsza faza, w której pojawiają się obiekty oraz klasy. Oznacza to, że faza analizy obiektowej definiuje strukturę logiczną systemu, która jest krytyczna dla stworzenia poprawnego rozwiązania. Analiza obiektowa składa się z dwóch faz: strukturalna analiza obiektowa oraz behawioralna analiza obiektowa. W praktyce obie te fazy realizowane są równolegle. Przykładowo specyfikacja głównych scenariuszów w systemie może pomóc w identyfikacji dodatkowych obiektów oraz klas. 54

55 Aktywności i artefakty Główne aktywności fazy analizy obiektowej to: Identyfikacja najważniejszych obiektów w systemie z wykorzystaniem odpowiednich strategii. Definiowanie klas na bazie zidentyfikowanych obiektów. Określenie relacji pomiędzy obiektami oraz klasami. Konstrukcja metod współpracy obiektów w celu realizacja wymagań behawioralnych systemu. Definiowanie dynamiki głównych obiektów. Identyfikacja metod oraz atrybutów klas. Weryfikacja zidentyfikowanych mechanizmów przy pomocy scenariuszy. Dekompozycja wymagań wydajnościowych systemu na poszczególne ograniczenia dotyczące metod obiektów. Poniżej przedstawiono artefakty będące produktami fazy analizy obiektowej. Artefakty Reprezentacja Opis Model strukturalny obiektów Model behawioralny Diagramy obiektów i klas Diagramy pakietów/domen Diagramy komponentów Diagramy stanów Identyfikacja głównych abstrakcji w systemie, relacji pomiędzy nimi, organizacja w pakiety. Diagram klas reprezentujący organizacje domen systemu pakietów, relacje pomiędzy nimi oraz zakres wykorzystania. Identyfikacja komponentów wdrożeniowych, takich jak pliki, dokumenty, co pozwala na koordynację pracy członków zespołu projektowego. Skończone maszyny stanowe zdefiniowane na poziomie klas. Diagramy aktywności Diagramy sekwencji Diagramy kolaboracji Diagramy aktywności UML reprezentują współbieżne diagramy przepływu. Ich głównym zadaniem jest modelowanie działania współbieżnego, podobnie jak sieci Petriego oraz specyfikacja skomplikowanych algorytmów. Typowe oraz wyjątkowe sekwencje współpracy dla danej klasy. Zadanie podobne jak w przypadku diagramu sekwencji, z naciskiem na pojęcie obiektu. Diagramy czasowe Specyfikuje warunki czasowe dla poszczególnych operacji oraz przejść pomiędzy stanami. Tabela 3.4. Artefakty etapu analizy obiektowej 55

56 Metamodel encji Encjami modelu wykorzystywanym podczas analizy obiektowej są standardowe elementy diagramów obiektów oraz klas: klasy, obiekty, relacje itd. Do opisu mechanizmów współpracy pomiędzy obiektami wykorzystuje się pojęcie interfejsu elementu języka UML. Dodatkowo obiekty oraz klasy grupuje się w różne obszary zwane domenami. Typowe domeny dotyczą urządzeń wejścia wyjścia, interfejsu użytkownika, zarządzania alarmami oraz przechowywaniem danych. Domena urządzeń wejściawyjścia może zawierać klasy jak konwerter A/D, rejestr, port, itd. Domena interfejsu użytkownika może zawierać klasy takie jak: okno, scrollbar, przycisk, czcionka, bitmapa. Relacja generalizacji jest wykorzystywana w zakresie pojedynczej domeny. Oczywiście obiekty mogą współpracować pomiędzy domenami oraz może łączyć ich odpowiednia relacja. Domeny są reprezentowane w języku UML poprzez pakiety klas oraz obiektów. Podział na pakiety pozwala przeprowadzać niezależnie analizę poszczególnych domen. W celu podziału pracy pomiędzy członkami zespołu projektowego wprowadza się pojęcie komponentów wdrożeniowych. Komponenty te zawierają moduły niewykonywalne takie jak dokumenty, pliki pomocnicze oraz moduły wykonywalne: tabele bazy danych, biblioteki programistyczne, programy wykonywalne. Zarządzanie podziałem pracy na poszczególne komponenty, wersjonowanie oraz strategie utrzymywania systemu należą do przedmiotu zarządzania konfiguracją. Skończone maszyny stanowe są stosowane do opisu behawioralnego zidentyfikowanych klas i obiektów. Oznacza to, że diagramy stanów powstałe w poprzednich fazach i powiązane z przypadkami użycia (analiza wymagań) lub komponentami (analiza systemowa), muszą zostać podzielone pomiędzy diagramy powiązane z poszczególnymi obiektami oraz klasami. Najczęściej prowadzi to do reorganizacji dziedziny stanów systemu, dlatego należy zwrócić uwagę, aby pomiędzy diagramami obiektów, a odpowiadającymi im diagramami przypadków użycia i komponentów zachodziła relacja endomorficzna. Sekwencje komunikatów, diagramy czasowe oraz kolaboracji są używane do przedstawienia dynamiki oraz współpracy pomiędzy obiektami. Na początkowych etapach analitycy chętniej wykorzystują diagramy sekwencji. Jednakże po identyfikacji obiektów i klas często przechodzą do diagramów kolaboracji. W przypadku ograniczeń czasowych na wykonanie poszczególnych operacji stosuje się diagramu czasowe, lub maszyny stanowe z czasem. 3.7 Projekt techniczny W odróżnieniu od analizy, która koncentruje się przede wszystkim na logicznymi modelu systemu, etap projektu technicznego ma za zadanie opracowanie optymalnego rozwiązania. Przykładowo projekt techniczny będzie identyfikował następujące dane o systemie: Obiekty aktywne model współbieżności. Strategie harmonogramowania zadań. Organizacje klas i obiektów w komponentach wdrożeniowych. Protokoły komunikacji międzyprocesowej. Rozmieszczenie komponentów na poszczególnych procesorach. Strategie implementacji relacji (głównie powiązania) pomiędzy obiektami. Wzorce implementacji maszyn stanowych. Zarządzanie rolami wielowartościowymi. Strategie zarządzania błędami oraz wyjątkami. Strategie zarządzania pamięcią. 56

57 Etap projektu technicznego najczęściej dzielony jest na trzy fazy: projekt architektury, projekt realizacji, projekt szczegółowy. W podfazie projektu architektury podejmowane są najważniejsze decyzje strategiczne związane z architekturą rozwiązania docelowego i dotyczy przede wszystkim komponentów oprogramowania systemu. Projekt realizacji analizuje metody współpracy pomiędzy obiektami i wprowadza dodatkowe obiekty, które mają stanowić pomoc w implementacji zaprojektowanych relacji. Takie obiekty to przykładowo: iteratory, kontenery, inteligentne wskaźniki. Projekt szczegółowy definiuje wewnętrzną architekturę systemu oraz dynamikę poszczególnych klas. Projekt zawiera szczegółową strukturę wewnętrzną danych oraz realizowanych algorytmów. Artefakty fazy projektu technicznego w procesie ROPES zostały przedstawione na rysunku Głównym produktem fazy jest model projektowy. Rys Etapy oraz artefakty etapu projektu technicznego W fazie projektu technicznego projektanci systemu bardzo często sięgają po wzorce projektowe, których zastosowanie pozwala na rozwiązanie najbardziej typowych problemów spotykanych podczas budowy wybranej klasy rozwiązań informatycznych. Zastosowane wzorce projektowe mogą dotyczyć architektury systemu, modelu fizycznego lub projektu szczegółowego. Ważnym jest, aby zastosowane wzorce nie zmieniały założeń funkcjonalnych systemu. Projektanci muszą dążyć to stworzenia modelu projektowego będącego innym widokiem na ten sam system, który powstał na etapie analizy. Formalnie można przedstawić to jako zgodność produktów etapu analizy oraz projektu technicznego. Przejście od modelu abstrakcyjnego etapu analizy do modelu projektowego w metodologii ROPES może odbyć się poprzez proces ewaluacji lub translacji. Podejście translacyjne jest zdecydowanie rekomendowane w procesie ROPES. W translacyjnych makro cyklach powstaje translator, w którego strukturze zawarte zostają decyzje dotyczące architektury oraz użytych wzorcach. Translator zostaje następnie wykorzystany do stworzenia wykonywalnego 57

58 modelu na bazie stworzonej struktury obiektów. Ważną zaletą translatora jest oszczędność czasu oraz zasobów podczas produkowania modeli prototypowych na bazie wyników kolejnych iteracji analizy. Raz zbudowany translator pozwala na stworzenie prototypu w przeciągu kilku sekund, a nie dni czy tygodni jak ma to miejsce w przypadku ręcznego programowania prototypów. Translator najczęściej posiada dwie części: szkielet (framework) systemów czasu rzeczywistego oraz generator kodu. Szkielet systemów czasu rzeczywistego działa podobnie jak inne szkielety np. interfejsu użytkownika (MFC, Swing, itd.). Dojrzały szkielet systemów czasu rzeczywistego powinien zawierać klasy: wątek, timer, semafor, maszyna stanowa, stan, zdarzenie oraz zbiór abstrakcji funkcji systemu operacyjnego. Generator kodu służy do generowania kody źródłowego modelowanych klas, relacji, maszyn stanowych, które są odpowiednie do wykorzystywanego szkieletu. Wygenerowany kod źródłowy klas jest następnie kompilowany oraz konsolidowany. Bardziej tradycyjnym podejściem projektowania systemów obiektowych jest podejście ewaluacyjne. Model analityczny jest punktem wyjścia do szczegółowego projektu technicznego. Poprzez zastosowanie odpowiednich wzorców projektowych do modelu analitycznego uzyskujemy model projektowy. Proces ten zakłada jednak ręczne dodawanie klas do diagramów analitycznych oraz ręczne implementowanie operacji i atrybutów związanych z daną klasą. Często podnoszonym problemem podejścia ewaluacyjnego jest konieczność utrzymywania dwóch odrębnych modeli: analitycznego oraz projektowego. Generalnie rozróżnia się dwa podejścia do tego zagadnienia. Pierwszy z nich traktuje model analityczny jako pewien abstrakcyjny model wyższego poziomu w stosunku do modelu projektowego i dlatego powinien być utrzymywany niezależnie od modeli niższego rzędu. Drugie podejście wychodzi z założenia, że model projektowy jest kontynuacją i uszczegółowieniem modelu analitycznego, dlatego nie powinno się rozróżniać tych dwóch modeli, a model analityczny uzupełniać o elementy projektowe. Oba podejścia mają swoje zalety jak i wady. Ze względu jednak na problemy wynikające z utrzymywania dwóch modeli przy niewielkich korzyściach, rekomendowana jest podejście drugie. Pozwala to na jednoznaczną identyfikację oraz weryfikację wymagań funkcjonalnych stawianych przed systemem. Stosując różnego rodzaju relacje równoważności można prowadzić formalną weryfikację własności tworzonych po sobie modeli Projekt architektury Faza projektu architektury dotyczy przede wszystkim ważnych decyzji dotyczących kompletnej architektury oprogramowania projektowanego rozwiązania Aktywności i artefakty Podstawowe aktywności fazy projektu architektury: Identyfikacja oraz charakterystyka wątków. Definiowanie komponentów oprogramowania oraz ich rozmieszczenie w systemie. Zastosowanie wzorców projektowych w zakresie. o Globalnego zarządzania błędami. o Bezpieczeństwa. o Obsługa sytuacji wyjątkowych. Architektura rozwiązania prawe zawsze podyktowana jest wynikami analizy systemu. Należy jednak podkreślić, iż poza identyfikacją obiektów i klas systemu nadal pozostaje dużo pracy związanej z dzia 58

59 łaniem współbieżnym, niezawodnością oraz bezpieczeństwem rozwiązania. Dlatego faza projektu architektury w przypadku systemów czasu rzeczywistego jest tak istotna. Poniżej w tabeli 3.5 przedstawiono listę głównych produktów fazy projekty architektury. Artefakt Reprezentacja Opis Model projektu architektury Metamodel encji Diagramy obiektów i klas Diagramy komponentów Maszyny stanowe Diagramy aktywności Diagramy sekwencji Diagramy kolaboracji Diagramy czasowe Diagramy klas z uwzględnieniem wzorców projektowych oraz klas pomocniczych. Identyfikacja komponentów wdrożeniowych, takich jak pliki, dokumenty, pozwala na koordynację pracy członków zespołu projektowego. Skończone maszyny stanowe na poziomie klas. Diagramy aktywności UML reprezentują współbieżne diagramy przepływu. Ich głównym zadaniem jest modelowanie działania współbieżnego, podobnie jak sieci Petriego oraz specyfikacja skomplikowanych algorytmów. Typowe oraz wyjątkowe sekwencje współpracy dla danej klasy. Zadanie podobne jak w przypadku diagramu sekwencji, z naciskiem na pojęcie obiektu. Specyfikuje warunki czasowe dla poszczególnych operacji oraz przejść pomiędzy stanami. Tabela 3.5. Artefakty fazy projektu architektury Ze względu na fakt, iż projekt architektury jest rozwinięciem etapu analizy, wykorzystywane elementy języka UML są takie same jak w przypadku etapu analizy. W przypadku etapu projektu technicznego dodatkowo pojawiają się oznaczenia węzła oraz procesora, które odwzorowują fizyczny diagram wdrożenia oprogramowania. W przypadku modelowania współbieżności wykorzystuje się stereotyp obiektu aktywnego wątku. Dodatkowo do modelowania komunikacji pomiędzy komponentami i procesorami wykorzystuje się klasy protokołów Projekt realizacji Projekt realizacji poświęcony jest uzupełnieniu modelu analitycznego obiektami pomocniczymi, wynikającymi z modelowanych relacji lub w wyniku zastosowany wzorców projektowych. Podobnie jak w przypadku projektu architektury, w fazie projektu realizacji najczęściej stosuje się dostępne wzorce projektowe oraz standardowe metody realizacji danych wymagań np. kontenery przechowywania obiektów w pamięci Aktywności i artefakty Podstawowe aktywności fazy projektu realizacji: 59

60 Identyfikacja obiektów pomocniczych i narzędziowych niezbędnych do realizacji zadanych wymagań. Wprowadzenie obiektów i klas realizujących zadane relacje. Zastosowanie wzorców projektowych stosownych do podanych założeń architektury. Tabela 3.6 zawiera listę artefaktów będących wynikiem powyższych aktywności: Artefakt Reprezentacja Opis Model projektu realizacji Diagramy obiektów i klas Diagramy komponentów Zaktualizowany diagram klas o wzorce projektowe oraz klasy pomocnicze. Identyfikacja komponentów wdrożeniowych, takich jak pliki, dokumenty, pozwala na koordynację pracy członków zespołu projektowego. Model projektu realizacji Diagramy sekwencji Typowe oraz wyjątkowe sekwencje współpracy dla danej klasy. Diagramy kolaboracji Zadanie podobne jak w przypadku diagramu sekwencji, z naciskiem na pojęcie obiektu. Diagramy czasowe Specyfikacja warunków czasowych dla poszczególnych operacji oraz przejść pomiędzy stanami Projekt szczegółowy Tabela 3.6. Artefakty fazy projektu realizacji Projekt szczegółowy stanowi najniższy poziom uszczegóławiania projektu technicznego systemu. Związany jest z identyfikacją oraz definiowaniem wewnętrznej struktury oraz zachowania pojedynczych klas oraz obiektów Aktywności i artefakty Większość klas w typowym systemie są na tyle proste, iż nie wymagają szczegółowego projektu. Jednakże nawet w takich przypadkach implementacja relacji asocjacji, agregacji i generalizacji musi zostać odpowiednio zdefiniowana. Dodatkowo określa się warunki początkowe oraz końcowe inwariantów operacji, obsługę wyjątków, uściśla się definicje typów oraz zakres atrybutów. Te aktywności muszą zostać wykonane na etapie projektu szczegółowego. Tabela 3.7 zawiera główne produkty etapu projektu szczegółowego. 60

61 Artefakt Reprezentacja Opis Szczegółowy model projektowe Model obiektów Definiowanie struktury, typów, zakresu wartości atrybutów klasy oraz podział operacji na pojedyncze metody klasy. Diagramy stanów Maszyna stanowa na poziomie klasy Diagramy aktywności Definicja algorytmów operacji w rozbiciu na poszczególne metody. 3.8 Implementacja Pseudokod Definicja algorytów i własności behawioralnych. Tabela 3.7. Artefakty fazy projektu szczegółowego Etap implementacji, czasem zwany etapem translacji służy do przejścia z modelu zapisanego w języku UML do kodu źródłowego w wybranym języku programowania. Następnie kod źródłowy zostaje skompilowany i uruchomiony na wybranej platformie sprzętowej. Rysunek 3.12 przedstawia opisywany proces translacji Aktywności i artefakty Bazując na mikro cyklach, faza translacji odbywa się w większości przypadków automatycznie lub quasi automatycznie. W podejściu ewolucyjnym, programista musi zmapować elementy modelu UML na elementy języka programowania. Jeżeli wybrany język jest zorientowany obiektowo, proces ten jest z reguły bardzo prosty, ponieważ wszystkie najważniejsze decyzje zostały podjęte na etapie analizy i projektu technicznego. W przypadku języków strukturalnych, programista ma znacznie trudniejsze i zarazem bardziej kreatywne zadanie. W takich sytuacjach najczęściej wprowadza się tzw. podręcznik translacji. Dokument ten opisuje reguły, które pozwalają programiście zaimplementować elementy języka UML w docelowym języku programowania np. C, Pascal, kod maszynowy. Metodyka ROPES zakłada także wykonanie testów jednostkowych w etapie implementacji systemu. Testy jednostkowe stanowią zbiór prostych skryptów testowych traktujących poszczególne moduły systemu jako białe skrzynki. Celem testu jednostkowego jest sprawdzenie poprawności wewnętrznej struktury modułu oraz jego zgodności z projektem technicznym. W celu przeprowadzenia testów jednostkowych przygotowuje się plan testów, dokument procedury testowej oraz same skrypty testujące. W wyniku przeprowadzenia testów jednostkowych powstaje dokument opisujący wyniki testów. Pojedynczy test jest przeznaczony dla pojedynczej klasy lub metody. Zaletą stosowania testów jednostkowym jest przede wszystkim zmniejszenie ilości błędów na kolejnych etapach testów. Raz utworzone skrypty testowe stanowią doskonałą podstawę do testów regresyjnych w kolejnych iteracjach procesu ROPES. Wykonywanie tychże testów jest najczęściej zautomatyzowane poprzez specjalne narzędzia (np.cunit, JMeter). Dzięki czemu wyniki poprawności działania poszczególnych modułów można uzyskać w przeciągu kilku minut. Doświadczenie pokazuje, że czas i zasoby poświęcony na utworzenie testów jednostkowych, znacząco przyśpiesza proces implementacji oraz testów, zwłaszcza w podejściu iteracyjnym. 61

62 Rys Główne fazy i artefakty etapu implementacji Tabela 3.8 zawiera listę produktów fazy implementacji. Artefakt Generowany kod źródłowy Reprezentacja Opis Kod źródłowy Kod źródłowy oprogramowania w docelowym języku programowania. Podręcznik translacji Skompilowany kod obiektów systemu Dokument tekstowy Plik w formacie zapisu kompilatora Zbiór reguł translacji encji UML do docelowego języka programowania. Skompilowany kod wykonywalny. Kod źródłowy systemu Szkielet czasu rzeczywistego Komponenty opcje Kod źródłowy, skompilowany kod obiektów Kod źródłowy Plik binarny Źródłowy lub skompilowany kod obiektów wykorzystywanych przez aplikację. Klasy szkieletu realizujące podstawowe funkcje w zakresie systemów czasy rzeczywistego. Biblioteki oraz komponenty wykorzystywane przez system, rozwijane i utrzymywane przez firmy trzecie. 62

63 Plan testów jednostkowych Dokument tekstowy Dokument opisujący proces testów jednostkowych poszczególnych klas. Procedury testów jednostkowych Wyniki testów jednostkowych Połączenie komponentów wykonywalnych Komponenty aplikacji 3.9 Etap testów Dokument tekstowy Dokument tekstowy Aplikacja lub moduły wykonywalne Aplikacja lub moduły wykonywalne Szczegółowa instrukcja przeprowadzenia testów jednostkowych poszczególnych klas i metod. Dokument tekstowy opisujący wyniki przeprowadzenia testów, zwiera dane: tester, data, dane we., wynik, status. Skompilowane i skonsolidowane komponenty, które jeszcze nie zostały przetestowane. Komponenty po wykonaniu testów. Tabela 3.8. Artefakty etapu implementacji Etap testów w procesie ROPES zawiera zarówno testy integracyjne jak również walidacje oraz weryfikację zaimplementowanego systemu. Testowanie najczęściej oznacza wykorzystanie testowych scenariuszy oraz danych w celu weryfikacji wyników działania systemu. Scenariusze testowe zostały opracowane na etapie analizy systemu, dzięki czemu możliwa jest weryfikacja implementacji systemu zgodnie z przyjętymi wymaganiami funkcjonalnymi. Produkty etapu testów oraz związane z nim procesy zostały zaprezentowane na rysunku Rys Główne fazy i artefakty etapu testów 63

64 3.9.1 Aktywności i artefakty Wszystkie testy powinny zostać wykonane zgodnie z przyjętym planem testów oraz procedurami testowymi zapisanymi w odpowiednim dokumencie. Podczas testów integracyjnych system jest testowany poprzez weryfikację interfejsów poszczególnych komponentów. Testy są przeprowadzane poprzez dodawanie kolejnych komponentów do systemu i testowanie nowo włączonych interfejsów w kontekście funkcjonalności całego rozwiązania. Testy walidacyjne najczęściej są definiowane przez zespół testowy i mają na celu sprawdzenie, czy zaimplementowany system spełnia wymagania zdefiniowane na etapie analizy. Testy walidacyjne traktują systemu jako czarną skrzynkę. Jedyny wyjątek stanowią testy bezpieczeństwa, które muszą obejmować znajomość wewnętrznej struktury systemu i analizować precyzyjnie zachowanie systemu w sytuacjach wyjątkowych. W tabeli 3.9 przedstawiono listę najważniejszych produktów etapu testów. Artefakt Reprezentacja Opis Plan testów integracyjnych Dokument tekstowy Definicja kolejności testowania poszczególnych komponentów dołączanych do systemu. Testy integracyjne Dokument tekstowy Wyniki testów integracyjnych Dokument tekstowy Szczegółowa definicja sposoby wykonania testów integracyjnych wraz z warunkami pozytywnego zakończenia testów. Wyniki testów poszczególnych komponentów, zawiera dane na temat testerów, daty wykonania, rezultatów. Przetestowane komponenty Plan testów walidacyjnych Procedury testów walidacyjnych Wykonywalne komponenty Dokument tekstowy Dokument tekstowy Komponenty przetestowane. Definicja testów, które mają dowieść poprawności poprawnego zaimplementowania systemu. Testy weryfikują, czy system spełnia postawione wymagania. Szczegółowy opis w jaki sposób wykonać testy walidacyjne wraz z warunkami pozytywnego zakończenia testów. Wyniki testów walidacyjnych Dokument tekstowy Wyniki testów walidacyjnych systemu, zawiera dane na temat testerów, daty wykonania, rezultatów. Przetestowana aplikacja Aplikacja Wykonywalna aplikacja po przeprowadzeniu walidacji. Tabela 3.9. Artefakty etapu testów 64

65 3.10 Wdrożenie i utrzymanie Faza wdrożenia i utrzymania systemu nie została włączona w dotychczasowych pracach dotyczących metodologii ROPES. Autor koncepcji Bruce Douglas wskazał jako ostatnią fazę etap testów i przekazania gotowego produktu do klienta. Doświadczenie ostatniej dekady rozwoju oprogramowania pokazuje jednak, iż etap wdrożenia, a przede wszystkim utrzymania systemu są ważnymi czynnikami sukcesu projektu. Z analizy finansowej przeprowadzonych projektów wynika, iż koszty trzyletniego utrzymania systemu wynoszą około 50% całego budżetu projektu. Dlatego też, w niniejszej pracy uznano za konieczne wprowadzenie do metodologii ROPES dodatkowej fazy związanej z wdrożeniem i utrzymaniem systemu. Przebieg procesu wdrożenia zależy w szczególności od otoczenia systemu, w którym ma funkcjonować. Podczas planowania wdrożenia należy uwzględnić następujące czynniki: Czy nowy system ma zastąpić aktualnie funkcjonujący? Wpływ wdrożenia nowego systemu na otoczenie. Architekturę oraz reżim pracy obecnego systemu. Proces zasilenia i migracji danych do nowego systemu. Czas przestoju systemu zewnętrznych. Wpływ na bezpieczeństwo otoczenia. Powyższe elementy powinny zostać przeanalizowane przed przeprowadzeniem wdrożenia. Odpowiednie zapisy dotyczące użytkowania systemu powinny pojawić się w dokumentach powdrożeniowych. W przypadku uruchamiania systemu, który ma za zadanie zastąpić system aktualnie działający, bardzo ważnym etapem jest proces migracji danych. Odpowiednie przygotowanie danych, a następnie proces zasilenia powinno być przedmiotem fazy testów. Dodatkowo należy uwzględnić wpływ uruchomienia systemu na otoczenie, a w szczególności na systemy zewnętrzne. Dotyczy to przede wszystkim sytuacji, w której wdrażany system posiada interfejsy online do systemów zewnętrznych, a jego wdrożenie może zakłócić ich dotychczasową pracę. Praktyka pokazuje, iż nawet najbardziej dokładne testy nie uchronią przed ewentualnymi problemami po uruchomieniu produkcyjnym systemu. Dlatego też, bardzo częstą zasadą stosowaną zwłaszcza dla systemów o podwyższonych wymaganiach bezpieczeństwa jest koncepcja wdrożeń pilotażowych. Wdrożenia pilotażowe polegają na kolejnym uruchamianiu funkcji i procesów systemu na ograniczonej, lecz reprezentacyjnej grupie użytkowników. Wyniki działania systemu, najczęściej przez okres paru miesięcy, a w szczególnych przypadkach lat, są szczegółowo badane, a następnie pozwalają na wprowadzenie ewentualnych poprawek w systemie. Etap pilotażowy jest przedsięwzięciem kosztownym, ponieważ oznacza niejednokrotnie konieczność utrzymywania dwóch systemów produkcyjnych równolegle, a po jego zakończeniu musi nastąpić synchronizacja danych. Niemniej jednak jest to jeden z bardziej skutecznych sposobów na zapewnienie odpowiedniej jakość produktu końcowego. Proces utrzymania systemu zasadniczo nie różni się w przypadku pojedynczego wdrożenia od produktu masowego. Różnica dotyczy przede wszystkim kanałów komunikacji pomiędzy klientem, a producentem. W standardowym podejściu do utrzymania systemów informatycznych, serwis można podzielić na trzy warstwy: Pierwsza linia wsparcia najczęściej występuje w charakterze centrum komunikacyjnego lub Call Center, gdzie użytkownicy mogą zarejestrować zgłoszenie problemów i uzyskać informacje na temat prowadzonych prac lub oprogramowanie pozwalające przekazać zgłoszenie drogą elektroniczną. 65

66 Druga linia wsparcia wyspecjalizowany zespół konsultantów, którzy posiadają wiedzę na temat systemu pozwalająca do rozwiązania problemu bez ingerencji w kod systemu. Trzecia linia wsparcia zespół programistów odpowiedzialnych za rozwój oprogramowania systemu oraz usuwanie ewentualnych błędów z kodu źródłowego. W zależności o rodzaju zgłoszenia, może on zostać obsłużony na poziomie pierwszej linii (najczęściej problem standardowy lub zapytanie o informacje) lub przekierowany na poziom drugi. Następnie zespół konsultantów analizuje problem i w zależności od wyników analizy może przekazać zgłoszenie na poziom trzeci, lub przesłać rozwiązanie do pierwszej linii, a ta z kolei do klienta. Trzecia linia może rozwiązać problem bez ingerencji w oprogramowanie systemu, lub poprzez implementację odpowiednich zmian. W takiej sytuacji konieczne jest wyprodukowanie aktualizacji oprogramowania lub wymiana platformy sprzętowej, a następnie przekazanie aktualizacji do klienta. Zgłoszenia obsługiwane przez trzecią linię wsparcia są najbardziej kosztowne dla organizacji utrzymującej system. Ważnym elementem procesu utrzymania jest umowa utrzymaniowa oraz definicja parametrów SLA (Service Level Agreement). Parametry SLA określają szczegółowe wytyczne dotyczące ograniczeń czasowych akcji, do których zobowiązana jest organizacja świadcząca usługę utrzymania. Najczęściej definiuje się parametry następujące akcji: Czas reakcji maksymalny czas wysłania potwierdzenia przyjęcia zgłoszenia Czas naprawy maksymalny czas przygotowania rozwiązania problemu (może być liczony jako czas na przygotowanie aktualizacji lub jako czas wdrożenia poprawki na środowisku produkcyjnym) Czas obejścia maksymalny czas, w którym usługodawca zobowiązany jest przedstawić obejście problemu Czas przestoju maksymalny czas przestoju systemu w zadanym okresie (np. 10h w ciągu roku) Przekroczenie poszczególnych parametrów skutkuje uruchomieniem procedur karnych przewidzianych przez umowę. Najczęściej stosuje się kary finansowe. Należy podkreślić, iż wyżej wymienione parametry są definiowanie dla kilku kategorii błędów np.: krytycznych, poważnych, zwykłych. Najczęściej popełnianymi błędami korporacji świadczących usługi utrzymaniowe są: Brak świadomości zapisów umowy utrzymaniowej przez osoby realizujące usługę. Brak wystarczającej ilości zasobów umożliwiających rzetelną realizację umowy. Brak planów i procedur awaryjnych w sytuacjach kryzysowych Aktywności oraz artefakty Poniżej przedstawiono listę najważniejszych aktywności związanych z fazą wdrożenia oraz utrzymania: Analiza wpływu systemu na otoczenia. Migracja i zasilenie danymi. Przygotowanie planu wycofania system. Stworzenie dokumentacji powdrożeniowej i utrzymaniowej. Przygotowanie procesu utrzymania i archiwizowania systemu. Realizacja zapisów i warunków umowy utrzymaniowej. 66

67 Ciągła aktualizacja raportów z realizacji warunków SLA. Listę artefaktów przedstawiono w tabeli Artefakt Reprezentacja Opis Procedura wdrożenia Dokument tekstowy Definicja zadań, które należy wykonać w celu wdrożenia systemu. Zawiera także procedurę wycofania systemu. Procedura migracji Procedura utrzymania systemu Dokument tekstowy Dokument tekstowy Szczegółowa definicja sposoby przeprowadzenia migracji danych i/lub zasilenia danymi. Opis aktywności, koniecznych do wykonania w zadanym czasie w celu zapewnienia ciągłości działania systemu. Raport z realizacji utrzymania systemu Aktualizacja oprogramowania Dokument tekstowy Wykonywalna aplikacja, komponent Raport prezentujący ilość problemów i czas ich rozwiązania w zadanym okresie. Całość lub część systemu, która pozwala na usunięcie zgłoszonego problemu Metamodel encji Tabela Artefakty etapu wdrożenia i utrzymania Ze względu na charakter etapu wdrożenia oraz utrzymania większość produktów stanowią dokumenty opisujące procedury oraz warunki utrzymania. Dokumenty te stanowią część nieuruchamianych modułów diagramu wdrożeniowego. Procedury najczęściej wykorzystują elementy diagramu aktywności lub sekwencji Podejście pseudo iteracyjne W zaprezentowanym powyżej podejściu iteracyjnym z podziałem na cykle, poszczególne etapy projektu można uznać za zakończone w momencie wykonania ostatniej iteracji makro cyklu. Konstatacja ta prowadzi do oczywistego wniosku, iż finalne produkty fazy analizy i projektu technicznego zostaną opublikowane dopiero w ostatnich etapach danego projektu. W przypadku systemów czasu rzeczywistego bardzo często projekt wytwarzania oprogramowania jest powiązany z równoległym projektem projektowania i wykonania warstwy sprzętowej tworzonego systemu. W tym miejscu należy podkreślić, iż proces wytwarzania warstwy sprzętowej jest niejednokrotnie dłuższy od etapu wytwarzania oprogramowania. Dodatkowym ograniczeniem jest konieczność zakończenia fazy analizy wymagań i opracowania architektury systemu przed przystąpieniem do tworzenia projektu warstwy sprzętowej. W celu optymalizacji czasu trwania całego przedsięwzięcia, metodologia ROPES przewiduje możliwość elastycznego modyfikowania struktury iteracji i cykli poszczególnych faz projektu. Jeżeli w przypadku projektu, którego celem jest wytworzenie oprogramowania oraz komponentów sprzętowych systemu, celowe jest jak najszybsze zakończenie fazy analizy wymagań oraz architektury systemowej, wtedy fazy ten wykonywane są w sposób sekwencyjny. Po ich zakończeniu dalsze prace nad projek 67

68 tem technicznym oraz implementacją systemu przebiegają iteracyjnie. W ten sposób prace nad komponentami sprzętowymi systemu rozpoczną się w najkrótszym możliwym terminie. W tym miejscu należy podkreślić, iż wprowadzony podział na dwa podprojekty sprzętowy oraz oprogramowania, wymaga ustalenia interfejsów pomiędzy tymi komponentami. Specyfikacja tych interfejsów powinna być produktem etapu analizy systemowej Podsumowanie W niniejszym rozdziale przedstawiono najważniejsze informacje na temat procesów związanych z tworzeniem oprogramowania, w szczególności systemów czasu rzeczywistego. Zawarto także informacje na temat harmonogramowania oraz estymacji projektów informatycznych. Trudności związane z estymowaniem czasu trwania zadań można podzielić na dwie kategorie: socjologiczne oraz techniczne. Większość problemów z kategorii socjologicznej można rozwiązać stosując odpowiednią strategię planowania projektów oraz zarządzania czasem. Większość zawartości rozdziału poświęcono prezentacji najważniejszych elementów metodologii ROPES. Autor uzupełnił informacje prezentowanych przez Bruca Douglass a o elementy związane z zarządzaniem projektem informatycznym oraz etapem wdrożenia i utrzymania systemu, które są istotne ze względu na analizę kosztową wdrożenia opisywanej metodologii. Proces tworzenia programowania wykorzystujący ROPES dzieli projekt na 4 etapy: analizę, projekt, implementacje (translację) oraz testy. Poszczególne etapy dzielą się na mniejsze fazy. Każda faza ma zdefiniowane aktywności oraz artefakty, które stanowią produkty końcowe poszczególnych faz. Etapy ROPES zostały zorganizowane w proces iteracyjny. Każdy prototyp, który jest rezultatem pojedynczego cyklu najczęściej implementuje jeden lub więcej przypadków użycia. Pozwala to na minimalizowanie ryzyk związanych z realizacją poszczególnych wymagań. Wykonywalny prototyp może stanowić model, który pozwala zweryfikować postawione założenia dotyczące tworzonego systemu. Kluczem do efektywnego wytwarzania oprogramowania opartego o metodologię ROPES jest możliwość automatycznego generowania kodu źródłowego. Pozwala to na redukcję czasu niezbędnego do stworzenia kolejnych prototypów z tygodni lub miesięcy do godzin lub dni. ROPES wspiera ewolucyjne lub translacyjne podejście mikro cykli, jednak rekomendowana jest opcja podejścia translacyjnego. 68

69 4. Zastosowanie języka LOTOS w inżynierii oprogramowania 4.1 Wprowadzenie Język LOTOS Language of Temporal Ordering Specification, jest jednym z dwóch technik formalnego opisu (Formal Description Technique FDT), powstałych w ramach instytutu standaryzacji ISO i wprowadzonych w celu formalnego opisu specyfikacji systemów rozproszonych, zwłaszcza związanych z architekturą sieci komputerowych opartych o OSI (Open Systems Interconnection). Głównym celem utworzenia języka LOTOS było opracowanie narzędzia opisu relacji pomiędzy obiektami systemu, które komunikują się między sobą za pomocą sekwencji akcji, obserwowalnych z poziomu otoczenia systemu. Wbrew nazwie LOTOS nie bazuje na formalizmie logiki temporalnej, lecz wykorzystuje algebrę procesów CCS jako podstawowe narzędzie matematyczne opisu procesów modelowanego systemu. Należy jednak dodać, że oba te podejścia łączy wspólny model bazujący na częściowym porządku, choć opisywanym w odmienny sposób. LOTOS, poza wykorzystaniem formalizmu algebry procesów, zawiera jeszcze drugi komponent pozwalający na opisanie struktur i typów danych. Dzięki zaczerpnięciu idei abstrakcyjnych typów danych z języka ACT ONE, LOTOS pozwala na definiowanie oraz operowanie na typach danych, pomocnych podczas modelowania systemów rozproszonych. 4.2 Matematyczne podstawy języka LOTOS Podstawy algebry procesów zostały stworzone, całkowicie niezależnie, przez Milnera [43] oraz Hoare [26]. Zaprezentowane przez nich koncepcje algebr procesów zostały zaczerpnięte z formalizmów takich jak: sieci Petriego, teoria automatów, języków formalnych oraz pracy Bekic a [3]. Milner wprowadził algebrę CCS Calculus of Communicating Systems, natomiast Hoare opracował podstawy algebry CSP Communicating Sequential Processes. Główne różnice pomiędzy tym formalizmami obejmują: Komunikacja w przypadku CCS odbywa się pomiędzy dwoma procesami, natomiast CSP dopuszcza komunikację rozgłoszeniową. Algebra CCS dopuszcza istnienie akcji wewnętrznych τ, modelujących wewnętrzną komunikację systemu. Algebra CCS posiada tylko jeden operator równoległego wykonywania oraz operator wyboru. Niedeterminizm modelowany jest poprzez wykorzystastanie operatora wyboru z argumentami jest samej wartości. Dalsze prace w zakresie algebry procesów doprowadziły do rozwoju nowych wersji algebr, które w większym stopniu odpowiadają wymaganiom stawianym formalizmom wykorzystywanym w inżynierii oprogramowania. W niniejszej pracy będzie stosowana zbliżona do CCS algebra ACP Algebra of Communicating Processes. Informacje na temat algebry ACP można znaleźć w pracy [21]. W dalszej części rozdziału zostanie przedstawiona podstawowa wersja algebry procesów, która następnie zostanie uzupełniona o pozostałe definicje zgodne z ACP Podstawowa algebra procesów. Sygnatura podstawowej wersji algebry procesów zawiera następujące elementy: 69

70 1. Niepusty zbiór akcji a A, reprezentujących niepodzielne (atomowe) czynności wykonywane przez system tj.: naciśnięcie przycisku, czytanie porcji danych, wysyłanie porcji danych. Każda atomowa akcja a jest niezmienna oraz może wykonać sama siebie, po czym poprawnie kończy działanie. Graficznie taką sytuację reprezentujemy następująco: Predykat reprezentuje poprawne zakończenie działania akcji a. 2. Operator binarny + oznaczający kompozycję alternatywy. Jeżeli zamknięte wyrażenia t 1 oraz t 2 reprezentują procesy p 1 oraz p 2, wtedy wyrażenie t 1 +t 2 definiuje proces, który wykonuje funkcjonalność p 1 lub p 2. Innymi słowy, graf procesu t 1 +t 2 uzyskujemy poprzez połączenie p 1 i p 2 w ich stanach początkowych: 3. Operator binarny oznaczający kompozycję sekwencyjną. Jeżeli zamknięte wyrażenia t 1 oraz t 2 reprezentują procesy p 1 oraz p 2, wtedy wyrażenie t 1 t 2 definiuje proces, który wykonuje funkcjonalność p 1, a następnie p 2. Innymi słowy, graf procesu t 1 t 2 uzyskujemy poprzez zastąpienie każdego poprawnego zakończenia w p 1, przez przejście, gdzie s jest stanem początkowym p 2. Powyższe wyrażenia i operatory należą do definicji podstawowej algebry procesów BPA (Basic Process Algebra). Z wyrażeniami procesów algebry powiązana jest ściśle definicja grafu procesów. Relacja ta bazuje na definicji strukturalnej semantyki operacyjnej SOS (structural operational semantics). W tym celu wprowadza się pojęcie zbioru reguł przejść (specyfikacji systemu przejść). Definicja 4.1 Specyfikacją systemu przejść TSS nazywamy zbiór (może być nieskończony) reguł przejść. Regułą przejścia ρ nazywamy wyrażenie w postaci, gdzie H jest zbiorem wyrażeń oraz (t,p) z t,t Σ zwanym zbiorem przesłanek ρ, natomiast π jest zbiorem wyrażeń postaci oraz (t,p) z t,t Σ zwanym zbiorem konkluzji ρ. Lewostronny argument π jest nazywany źródłem ρ. Reguła przejścia jest zamknięta, jeżeli nie posiada zmiennych. Wyrażenie (t,p) oznacza, że predukat P jest spełniony w stanie t. 70

71 Przez graf procesu będziemy rozumieć etykietowany system przejść. Oznaczmy, przez S niepusty zbiór stanów, przez A oznaczmy niepusty, skończony zbiór etykiet przejść oraz skończony zbiór predykatów. Definicja 4.2 Etykietowanym systemem przejść (LTS) będziemy nazywać zbiór przejść. Przejściem będziemy nazywać: trójkę (s,a,s ), gdzie s,s są stanami oraz a A, lub parę (s,p), gdzie P jest predykatem. Zamiast notacji (s,a,s ) bardzo często przejście oznacza się jako. Co więcej wyrażenie (s,p) najczęściej oznacza się przez sp i oznacza, że predykat P jest spełniony w stanie s. W tabeli 4.1 przedstawiono specyfikację TSS określającą strukturalną semantykę operacyjną BPA. Zmienne x, x, y oraz y oznaczają kolekcję wyrażeń BPA, natomiast v reprezentują zbiór atomowych akcji A. Nr 1 Reguły przejść BPA 2 3 Tabela 4.1. Reguły TSS dla podstawowej algebry procesów Zgodnie z podaną definicją specyfikacji systemu przejść możemy podać następujące interpretacje poszczególnych grup reguł: Pierwsza reguła oznacza, że każda akcja może zakończyć się poprawnie po wykonaniu samej siebie. Grupa reguł (2) opisująca działanie operatora kompozycji alternatywy jeżeli jedno wyrażenie z t+t zakończy się lub przejdzie do innej akcji, wtedy całe wyrażenie zostaje zakończone lub przechodzi do nowej akcji. Ostatnie dwie reguły (3) reprezentują operator sekwencji. Wyrażenie t t jest wykonywane, aż do zakończenia akcji t, a następnie t. Reguły te wykorzystuje się do budowy grafu procesu, lub dowodzenia poprawności przejścia pomiędzy stanami danego procesu. Przykładowo prześledźmy dowodzenie następującego przejścia:. 1. (reguła, ) 2. (,,, ) 71

72 3. (,,, ) 4. (,,,, ) W nawiasach podano reguły SOS wykorzystane w kolejnych krokach weryfikacji przejścia. W przypadku dowodzenia relacji równości pomiędzy procesami, lub w przypadku automatycznego wnioskowania na bazie specyfikacji wykorzystuje się zbiór aksjomatów algebry procesów. Aksjomaty BPA zostały przedstawione w tabeli 4.2. Nr Aksjomaty BPA Algebra procesów ACP Tabela 4.2. Aksjomizacja ε BPA podstawowej algebry procesów W praktyce specyfikacja behawioralna systemu składa się z kolekcji niezależnych procesów, które działając współbieżnie i mogą na siebie wpływać poprzez wymianę komunikatów. Obrazowo można powiedzieć, że procesy stanowią bloki, z których zbudowany jest kompletny system. Natomiast bloki są ze sobą powiązane poprzez wzajemne komunikowanie akcji. W celu zamodelowania takiego systemu Milner wprowadził binarny operator złączenia (merge), który pozwala na współbieżne wykonywanie procesów, które zostały wskazane jako argumenty operatora. Proces zdefiniowany jako, może wybrać wykonanie przejścia początkowego s (czyli lub ) lub przejścia początkowego t. Działanie operatora przedstawiono za pomocą reguł TSS : Operator może dokonać synchronizacji pomiędzy przejściami s oraz t. W tym celu zakładamy, że funkcja γ : A A A jest funkcją komunikacji, która dla każdej pary akcji a i b oznacza fakt komunikacji przez γ(a,b). Wymagane jest, aby funkcja komunikacji była przemienna oraz łączna: γ(a,b) γ(b,a), γ(γ(a,b),c) γ(a,γ(b,c)). Bazując na funkcji komunikacji możemy przedstawić kolejne cztery reguły TSS dla operatora złączenia:,,,, Korzystając z powyższych reguł możemy stworzyć graf procesu. Zakładamy, że komunikacja pomiędzy a i b zawsze zwraca c. 72

73 Rys Przykładowy graf procesu (ab) (ba) Powyższy przykład pokazuje, że nawet z prostej definicji generowany jest duży graf procesu. Wyjaśnia to częściowo siłę ekspresji teorii komunikujących się procesów. Pokazuje także, że dużo prościej jest analizować poszczególne komponenty systemu, aniżeli cały system. Moller w pracy [45] wykazał, ze nie istnieje kompletna i skończona aksjomizacja algebry z operatorem złączenia. Problem ten ma swoje konsekwencje w definicji własności słabej bisymulacji. Okazuje się, że relacja ta w połączeniu z operatorem złączenia nie jest kongruentna. Problem ten został rozwiązany przez wprowadzenie dwóch dodatkowych operatorów: lewego złączenia oraz komunikacyjnego złączenia, które realizują częściowo funkcjonalność operatora złączenia. Operator lewego złączenia rozpoczyna od przejścia początkowego s, a następnie zachowuje się jak zwykły operator złączenia. Jego działanie możemy opisać przy pomocy dwóch reguł TSS: Złączenie komunikacyjne rozpoczyna działanie od wymiany komunikatów przejść początkowych, a następnie działa jak normalny operator złączenia. Wyrażają to cztery reguły TSS:,,,, Operatory złączenia,, mają wyższy priorytet od operatora +. Podstawową algebrę procesów poszerzoną o operatory złączenia nazywamy algebrą procesów z zrównolegleniem PAP (Process Algebra with Parallelism). Podobnie jak w przypadku podstawowej algebry procesów BPA wprowadzamy aksjomaty algebry z zrównolegleniem. W tabeli 4.3 przedstawiono listę aksjomatów PAP. Podczas modelowania komunikacji pomiędzy procesami interesują nas przede wszystkim akcje, które reprezentują kolejne kroki wymiany informacji. Przykładowo, niech akcja send(d) reprezentuje wysyłanie porcje danych d do jednego z końców kanału komunikacyjnego, natomiast read(d) reprezentuje akcje odbioru danych d. Następnie ustalmy, że proces komunikacji pomiędzy dwoma procesami poprzez kanał odbywa się za pomocą akcji comm(d). Z punktu widzenia zewnętrznego obserwatora, 73

74 akcje send(d) oraz read(d) nie są widoczne, a jedyną akcją widoczną dla otoczenia systemu jest comm(d). Nr Aksjomaty PAP 1 y , 6, 7, 8, 9 10 Tabela 4.3. Aksjomizacja ε PAP algebry procesów z zrównolegleniem W celu umożliwienia modelowania ukrytej komunikacji, wprowadza się specjalną stałą δ, zwaną deadlock, która nie skutkuje wykonaniem żadnej akcji. Definicja funkcji komunikacji ulega rozszerzeniu, pozwalając, aby komunikacja dwóch akcji atomowych zakończyła się δ, γ : A A A {δ}. Rozszerzenie to pozwala na modelowanie sytuacji, w której dwie akcje a oraz b nie komunikują się: γ(a,b) δ. Dodatkowo wprowadza się operator enkapsulacji, określony na zbiorze H atomowych akcji, który powoduje przemianowanie wszystkich akcji a H na akcję δ. Stałą δ oraz operator enkapsulacji zostały wprowadzone przez Milner a [44]. Jeżeli dotychczas zdefiniowaną algebrę PAP rozszerzymy o pojęcie deadlock oraz operator enkapsulacji, otrzymamy ostateczną postać algebry ACP. Ponieważ stała δ nie powoduje widocznej zmiany w działaniu systemu, dlatego nie ma z nią powiązanego żadnego przejścia. Jednakże należy uwzględnić w ostatnich czterech regułach dla operatora złączenia fakt, iż komunikacja dwóch akcji może prowadzić do stanu deadlock. W tym celu wprowadzamy dodatkowy warunek dla tych reguł:,. Dodatkowo wprowadzamy dwie reguły określające działanie operatora enkapsulacji: Należy zwrócić uwagę, że przejście postaci ma całkowicie inne znaczenie, niż przejście. Pierwsze wyrażenie opisuje sytuację, w której proces zostaje zatrzymany po wykonaniu akcji a, natomiast w drugim wyrażeniu t poprawnie kończy działanie po wykonaniu akcji a. Generalnie własność zakleszczenia deadlock jest niepożądaną własnością, ponieważ odpowiada sytuacji, w której proces zatrzymuje swoje działanie bez przekazania jakiejkolwiek odpowiedzi. Doświadczenie uczy jednak, iż wiele specyfikacji zawiera explicite stan deadlock. Warto wspomnieć, że w większości przypadków dana specyfikacja musi zostać zweryfikowana pod kątem własności zakleszczenia. Zadanie to realizują 74

75 najczęściej automatyczne narzędzia wspomagające projektowanie. W tabeli 4.4 przedstawiono aksjomaty ACP w zakresie stanu deadlock oraz operatora enkapsulacji. Nr Aksjomaty ACP Założenia języka LOTOS Tabela 4.4. Aksjomizacja ε ACP algebry procesów Główne założenia języka LOTOS, będące fundamentem obecnej specyfikacji ISO [8], wymieniono poniżej. Spójny formalizm dla opisu danych i sterowania dzięki połączeniu języka ACT ONE oraz algebry CCS umożliwiono projektantom tworzenie specyfikacji systemów z zastosowaniem jednego formalizmu. Formalna definicja LOTOS posiada formalną definicję syntaktyczną, statyczną oraz dynamiczną semantykę. Semantykę statyczną reprezentują reguły gramatyczne, natomiast semantykę dynamiczną określają reguły transformacji wyrażeń behawioralnych. Algebra procesów bazując na koncepcji Milner a, strukturalna semantyka operacyjna została zdefiniowana w taki sposób, aby było możliwe zastosowanie szerokiej gamy relacji równoważności w procesie weryfikacji specyfikacji oraz implementacji. Współbieżność z przeplotem zdarzenia są niepodzielnymi akcjami, których równoległe wykonanie modelujemy jako sytuację wyboru. W takim przypadku zdarzenie a może wystąpić przed b, ale także może wystąpić sytuacja odwrotna. Wykonywalność wykorzystując definicję SOS (Structural Operational Semantics) języka LO TOS można wprowadzić do procesu wytwarzania oprogramowania narzędzie transformujące specyfikację LOTOS do wykonywalnego programu. Działanie takie pozwana na szybkie prototypowanie stworzonej specyfikacji, nie tracąc rygoru formalizmy metody. Modułowość i komponentowość język LOTOS dostarcza możliwość dekompozycji specyfikacji na poszczególne moduły. Dodatkowo, korzystając z parametryzacji poszczególnych 75

76 komponentów, możemy wielokrotnie wykorzystywać raz utworzoną specyfikację danego komponentu. Siła ekspresji języka LOTOS wynika przede wszystkim z zastosowania operatorów współbieżności oraz koncepcji synchronizacji procesów. Ich semantyka jest zdecydowanie różna od spotykanych w innych językach programowania np. Ada. Realizację synchronizacji procesów w LOTOS można scharakteryzować następująco: Synchronizacja wieloprocesowa LOTOS pozwala w odróżnieniu od oryginalnej koncepcji CCS na synchronizację wielu procesów. Mechanizm ten został zapożyczony z formalizmu CSP Hoare a. Symetryczna synchronizacja reguły synchronizacji nie wyróżniają żadnego procesu. Przykładowo podczas komunikacji dwóch procesów, typową sytuacją jest występowanie procesu aktywnego odpowiedzialnego za komunikację oraz pasywnego będącego odbiorcą komunikatów. W LOTOS proces synchronizacji nie wyróżnia w żaden sposób aktywnych lub pasywnych procesów. Synchronizacja anonimowa LOTOS umożliwia wprowadzenie punktu synchronizacji bez konieczności wskazywania, z którym bezpośrednio procesem należy ją wykonać. Identyfikacja procesów, które będą brały udział w synchronizacji bazuje na wymianie akcji lub odpowiednich wartości zmiennych. Niedeterministyczna synchronizacja pozwala na modelowanie więcej niż jednej synchronizacji, natomiast tylko jedna zostanie wykonana, w zależności od niedeterministycznego wyboru. Wyrażenie behawioralne reprezentuje stan procesu. Predefiniowany zbiór operatorów służy do powiązania akcji oraz wyrażeń behawioralnych w celu stworzenia innych wyrażeń behawioralnych. W języku LOTOS występują dwa predefiniowane wyrażenia behawioralne: stop oznacza sytuację deadlock (zawieszenie działania procesu), exit poprawne zakończenie pracy procesu. Definicja procesu w LOTOS stanowi wyrażenie behawioralne i odpowiada procedurze w innych językach programowania. Instancja procesu jest odpowiednikiem wywołania procedury. Wyrażenie behawioralne procesu określa, które z akcji są możliwe do wykonania w kolejnym kroku. Akcje, które proces wykonuje niezależnie od innych procesów i niewidoczne dla obserwatora nazywane są akcjami ukrytymi i oznaczamy je przez i. Zdarzenia, których zajście musi zostać zsynchronizowane z otoczeniem są oferowane poprzez punkty synchronizacje bramy. Otoczenie procesu stanowią inne procesy lub zewnętrzne systemy np. obserwator. Jeżeli dana akcja zostanie wykonana, wyrażenie behawioralne procesu transformowane jest do innego wyrażenia behawioralnego. Reguły transformacji semantyki dynamicznej LOTOS określają, które z oferowanych akcji zostaną wywołane oraz w jaki sposób nastąpi transformacja wyrażenia behawioralnego. 4.4 Notacja LOTOS Język LOTOS został podzielony na dwie części: Basic LOTOS oraz Full LOTOS. Różnica pomiędzy wersją podstawową Basic, a wersją pełną Full, wynika z wprowadzenia abstrakcyjnych typów danych w wersji pełnej. Oznacza to, iż w wersji Basic synchronizacja procesów odbywa się bez wymiany danych pomiędzy procesami. 76

77 4.4.1 Basic LOTOS Semantyka wyrażeń behawioralnych Basic LOTOS została zamieszczona w tabeli 4.5. Przez B, B1 oraz B2 oznaczono wyrażenia behawioralne LOTOS, następnie a akcja obserwowalna, i akcja nieobserwowalna, g bramy synchronizacyjne. Nazwa Wyrażenie Opis Zatrzymanie procesu Stop Działanie procesu zostaje zatrzymane. Poprawne procesu zakończenie exit Proces poprawnie kończy swoje działanie. Prefiks akcji a;b Po wykonaniu akcji a, proces jest transformowany do wyrażenia behawioralnego B. Wybór B1[]B2 Wyrażenie może zachowywać się zgodnie z definicja B1 lub B2. Zezwolenie B1>>B2 Odpowiada sytuacji, w której po poprawnym zakończeniu wyrażenia behawioralnego B1, proces przechodzi o wyrażenia B2. Przerwanie B1[>B2 Wyrażenie behawioralne B1 wykonywane jest do czasu poprawnego zakończenia (wtedy całe wyrażenie B1[>B2 kończy działanie), lub jeśli B2 zaakceptuje oferowaną akcję i przerwie działanie B1. W takiej sytuacji wyrażenie wykonywane jest zgodnie z B2. Operator przerwania odpowiada operatorowi mode transfer należącego do rozszerzenia CCS. Pełna synchronizacja B1 B2 Procesy B1 i B2 działają współbieżnie oraz są synchronizowane na wszystkich wspólnych (o tej samej etykiecie) bramach. Synchronizacja częściowa B1 [g 1, g 2,,g n ] B2 Procesy B1 i B2 działają współbieżnie oraz są synchronizowane na wymienionych bramach g 1, g 2,,g n. Współbieżność z przeplotem B1 B2 Procesy B1 oraz B2 działają równolegle zgodnie z koncepcją współbieżności z przeplotem. Wybór warunkowy [F] >B Wyrażenie B zostanie wykonane, jeżeli formułą warunku F przyjmuje wartość 77

78 Ukrywanie hide g 1 g 2,,g n in B Operator ukrywa akcje synchronizowane na bramach g 1, g 2,,g n w wyrażeniu behawioralnym B. Obserwator zewnętrzny nie będzie miał możliwości obserwacji zdarzeń na ukrytych bramach. Otrzyma informacje jedynie o wykonaniu akcji wewnętrznej i. true. Definicja procesu process Nazwa_procesu [g 1,g 2,,g n ] := B endproc Pozwala na zdefiniowanie procesu Nazwa_procesu realizującego wyrażenie behawioralne B i posiadającego określone bramy. Proces może posiadać własność exit jest możliwe zakończenie jego działania oraz noexit jeżeli proces jest nieskończony. W takim wypadku po zakończeniu działania proces przechodzi do wyrażenia stop. Instancja procesu Nazwa_procesu[g 1,g 2,,g n ] Stworzenie procesu o zadanej nazwie. Instancja specyfikacji specification Nazwa[g 1,g 2,,g n ]: noexit behavior Pozwala na stworzenie instancji procesów zdefiniowanych w modelowanym systemie Full LOTOS proces[[g 1,g 2,,g n ] endspec Tabela 4.5. Operatory i wyrażenia Basic LOTOS Pełna wersja LOTOS pozwala na wymianę danych pomiędzy procesami w punktach synchronizacji. Struktury danych oraz ich wartości są zdefiniowane z zastosowaniem języka ACT ONE. Każdy typ danych posiada odpowiadające mu wartości oraz operacje, które można na nim wykonać. Definicja typu danych w LOTOS składa się z sygnatury oraz listy możliwych wyrażeń algebraicznych eqns. Sygnatura typu jest definicją zbioru wartości sort oraz operacji opns. W wersji Basic LOTOS akceptowane przez proces akcje są synonimem bram synchronizacyjnych. Full LOTOS znacząco rozszerza semantykę akcji, pozwalając na oferowanie oraz pobieranie zmiennych, jak również wprowadza pojęcie predykatów akcji. Pomiędzy procesami następuje synchronizacja, jeżeli nazwy akcji oraz bram są uzgodnione oraz spełnione są warunki predykatów danej akcji. Wymiana danych następuje poprzez oferowanie offer! oraz akceptowanie accept? akcji. Przykładowo rozważmy następującą konstrukcję: g? V:Nat!1 [V=<3] Powyższe wyrażenie określa sytuację, w której zdarzenie a jest akceptowane w bramie g oraz oczekuje wartości V typu Nat z otoczenia oraz oferuje wartość 1. Dodatkowo oczekiwana wartość V musi 78

79 być mniejsza lub równa 3. Wyrażenie możemy zamienić na wybór czterech akcji oferujących wartości: g!0!1, g!1!1, g!2!1, g!3!1. Synchronizacja pomiędzy procesami z wymianą danych następuje, jeżeli dwa lub więcej procesów uzgodnią wartości zmiennych oferowanych na danej bramie. Proces ten nazywa się kojarzeniem akcji. Jeżeli procesy P 1, P 2,, P n działając współbieżnie oraz G jest zbiorem wspólnych bram, na których następuje synchronizacja, to proces synchronizacji może nastąpić, gdy spełnione są następujące warunki: 1. P 1, P 2,, P n oferują odpowiednio akcje a 1, a 2,, a n. 2. Bramy akcji a 1, a 2,, a n zawarte są w zbiorze G. 3. Zbiór T=wartości(a 1 ) wartości(a 2 ) wartości(a n ). Tabela 4.6 przedstawia semantykę wyrażeń dla pełnej wersji języka LOTOS. Nazwa Wyrażenie Opis Deklaracja wartości!e Wyrażenie deklaruje ofertę wartości E. Deklaracja zmiennej?x:t Określa deklarację zmiennej X o sygnaturze (typie) T. Prefiks akcji a?x:t;b(x) Podobnie jak w Basic LOTOS określa akceptację akcji a, a następnie przejście do sparametryzowanego wyrażenia behawioralnego B(x). Różnica polega na wprowadzeniu zmiennej X, która jest ustalana na podstawie ofert synchronizacji i parametryzuje wyrażenie B(x). Predykat selekcji a?x:t[f(x)];b(x) Umożliwia wprowadzenie warunku akceptacji zdarzenia a na podstawie wyrażenia logicznego F(x) oraz wartości X. Jeżeli F(x)=true, wtedy proces przechodzi do wyrażenia B(x). Operator dozoru [F(x)] a!x;p(x) Przetwarzanie akcji a jest dozorowane przez warunek logiczny F(x). Zmienna x musi zostać zadeklarowana przed określeniem wartości warunku. Ogólny operator wyboru choice x:t [] B(x) Operator wyboru [] pozwala na zadeklarowanie dla kończonej liczby wyrażeń. Ogólny operator wyboru pozwala na rozszerzenie tego warunku dla wszystkich wartości sygnatury T. Deklaracja procesu parametryzowanego process Nazwa_procesu [g 1,g 2,,g n ] (x 1 :t 1, x 2 :t 2,, x n :t n ) := B Definicja procesu zostaje rozszerzona o zmienne x n o sygnaturze t n. Zmienne te mogą być następnie przekazywane do kolejnych procesów poprzez bramy syn 79

80 Zwrot wartości po zakończeniu procesu Złożenie sekwencyjne z przekazaniem danych endproc exit(x 1,x 2,,x n ) B1>>accept x 1 :t 1,x 2 :t 2,,x n :t n in B2 chronizacji. Wyrażenie exit pozwala na wskazanie wartości zmiennych przekazywanych po poprawnym zakończeniu procesu. Wartości zwracane przez B1 są następnie przekazywane do następującego po nim B2. Oba procesy muszą posiadać skojarzone zmienne x 1 :t 1,x 2 :t 2,,x n :t n. 4.5 Podsumowanie Tabela 4.6. Operatory i wyrażenia Full LOTOS W rozdziale zaprezentowano podstawowe założenia specyfikacji języka LOTOS oraz jego główne elementy syntaktyczne oraz semantyczne. Język posiada algebraiczne podstawy, dlatego też jego wyrażenia oraz operatory są całkowicie odmienne od typowych języków programowania. W rozdziale przedstawiono także najważniejsze definicje i aksjomaty algebry procesów ACP. Algebra ACP bazuje na formalizmie CCS, który stanowi matematyczny formalizm języka Basic LOTOS. W zakresie algebry procesów istotne z punktu widzenia inżynierii oprogramowania są relacje równoważności pomiędzy procesami. Przedstawione aksjomaty ACP pozwalają na automatyzację procesu weryfikacji relacji bisymulacji. W oparciu o aksjomaty można także udowodnić, iż relacje bisymulacji procesów algebry ACP są kongruentne. Język LOTOS posiada wiele zalet, do których należy przede wszystkim możliwość modelowania procesów współbieżnych. Dzięki formalnej definicji operacyjnej struktury semantycznej możliwa jest budowa automatycznych translatorów specyfikacji LOTOS do innej postaci, pozwalającej na przeprowadzenie szybkiego prototypowania. Pakiety tj. CADP [81] umożliwiają przykładowo translację do grafów LTS, a następnie symulację modelu. Jednakże najistotniejszym czynnikiem wpływającym na siłę ekspresji oraz zastosowanie języka LOTOS jest możliwość badania różnorodnych relacji równoważności pomiędzy modelami. Własność ta będzie wykorzystywana w dalszych rozdziałach niniejszej pracy. 80

81 5. Semantyka diagramu stanów UML 5.1 Wprowadzenie Model behawioralny projektowanego systemu czasu rzeczywistego najczęściej powstaje w kilku etapach projektu (przedsięwzięcia). Jego specyfikacja jest iteracyjnie uszczegóławiana, aby produkt końcowy maksymalnie odwzorowywał wymagania funkcjonalne wobec tworzonego systemu. W przypadku prezentowanej w niniejszej pracy metodologii ROPES, wstępną specyfikację dynamiki systemu informatycznego otrzymujemy już na etapie analizy, początkowo jako diagramy uzupełniające przypadki użycia i opisujących interakcję systemu z jego otoczeniem, a następnie kompletną specyfikacje określającą dynamikę i współdziałanie obiektów systemu. Język UML posiada wiele mechanizmów opisu dynamiki systemu diagramy: aktywności, sekwencji, kolaboracji oraz stanów. Diagramy stanów są przy tym językiem o szerokim zasięgu. W odróżnieniu od diagramów aktywności, kolaboracji czy też sekwencji, diagram stanów pozwala na zdefiniowanie pełnej dziedziny zachowania systemu, natomiast pozostałe diagramy jedynie cześć dziedziny objętej prezentowanym scenariuszem. Dlatego projektanci systemów czasu rzeczywistego bardzo często sięgają po maszyn skończenie stanowe (Finite State Machine FSM) jako podstawowego narzędzia opisującego dynamikę systemu. Diagramy stanów są jednym ze sposobów wizualizacji maszyn stanowych. Język UML w zakresie definicji diagramów stanów bazuje na koncepcji maszyn stanowych Harel a [45]. W stosunku do maszyn skończenie stanowych, diagramy Harel a zostały uzupełnione o trzy dodatkowe własności: komunikację, współbieżność oraz hierarchię. W dalszych punktach rozdziału będą przedstawione szczegółowo w jaki sposób język UML modeluj powyższe własności. Istotnym brakiem w diagramach Harel a, uzupełnionym przez twórców specyfikacji UML jest przekazywanie danych poprzez zdarzenia oraz akcję. 5.2 Specyfikacja diagramów stanów w języku UML Język UML wspiera specyfikację maszyn stanowych poprzez wykorzystanie diagramów stanów. W literaturze angielskojęzycznej wykorzystuje się zamiennie dwa określenia: statechart oraz state diagram, które służą do określenia tego samego zestawu elementów wizualizacji modelu maszyny stanowej. W dalszej części rozdziału zostaną przedstawione wszystkie elementy notacji diagramów stanów zgodnej ze specyfikacją UML Pojęcie stanu oraz przejścia System, którego dynamikę mamy za zadanie przedstawić w postaci maszyny stanowej jest określany mianem systemu reaktywnego [56]. Określenie to oznacza, iż system współdziała z otoczeniem lub obiektami zewnętrznymi poprzez ciągłą wymianę komunikatów w postaci zdarzeń i odpowiada na zmiany w nich (otoczeniu, obiektach zewnętrznych) zachodzące. Obszar działania takiego systemu można podzieli się na rozłączne zbiory spełnialnych warunków, zwanych stanami. Stan jest ontologicznym warunkiem nałożonym na system, który jest spełniony przez określony przedział czasu oraz jest rozróżnialny i rozłączny z innymi warunkami. Własność rozróżnialności pozwala obserwatorowi rozróżnić poszczególne stany poprzez akceptowalne warunki oraz wykonywane akcje. Zgodnie ze specyfikacją UML stan charakteryzują następujące elementy [17]: Nazwa stanu. Akcja wejścia akcja atomowa (niepodzielna) wywoływana w momencie wejścia do danego stanu. Akcja wyjścia akcja atomowa (niepodzielna) wykonywana podczas opuszczania stanu. 81

82 Akcje wewnętrzne realizowane podczas przebywania w danym stanie. Aktywności zbiór akcji wykonywanych przez obiekt pozostający w danym stanie. W odróżnieniu od akcji, wykonywanie aktywności może zostać przerwane. Klauzula odrzucenia zbiór zdarzeń, które nie są akceptowane przez stan, ale pozwalają na odnotowanie, iż dane zdarzenie miało miejsce. Stany osadzone dany stan może być reprezentantem wyższego poziomu hierarchii, a jego wewnętrzna struktura definiuje poziom niższy. Stany osadzone (podstany) pozwalają określać kolejne poziomy hierarchii jako uszczegółowienie działania super stanów. Przejścia w diagramie stanów wiążą relacją dwa stany. Określają kierunek oraz warunki przejścia pomiędzy stanem początkowym oraz końcowym. Na diagramie przejścia oznaczane są symbolem łuku skierowanego. Sygnaturę łuku określamy jako: nazwa zdarzenia ( lista parametrów ) [ wyrażenie warunkowe ] / lista akcji Wszystkie powyższe pola są opcjonalne. Przejście bez sygnatury zostanie wyzwolone jak tylko stan początkowy będzie aktywny. W UML rozróżniamy następujący rodzaj zdarzeń [25]: SignalEvent zdarzenia powiązany z sygnałem. Sygnały reprezentują model komunikacji asynchronicznej. CallEvent zdarzeniem powiązanie z wywołaniem metody. Zdarzenie tego typu związane jest z modelem komunikacji synchronicznej. TimeEvent zdarzenie związane z upływem określonych jednostek czasu. Ze zdarzeniem TimeEvent związane są parametry określające czas wyzwolenia zdarzenia. ChangeEvent zdarzenie związane ze zmianą wartości danego atrybutu lub komórki pamięci. Ważnym rozszerzeniem notacji UML w stosunku do maszyn Harel a jest możliwość wykorzystania zmiennych jako parametrów zdarzenia. Pozwala to na propagacje informacji pomiędzy poszczególnymi stanami. Dodatkowo zmienne stanowią podstawę działania wyrażeń oraz pseudo stanów warunkowych. Zmienne w sygnaturze zdarzenia oznaczone są jako lista parametrów. Wyrażenia warunkowe pozwalają na zapisanie warunku wykonania danego przejścia jako formuły logicznej. Typowe wyrażenie warunkowe stanowi inwariant przejścia, który zostaje uaktywniony jedynie w przypadku przyjęcia przez warunek wartości prawdy logicznej. Wyrażenia warunkowe stanowią bardzo proste narzędzie do modelowania warunków wstępnych (preconditions) przetwarzania. Kolejność wykonywania akcji oraz aktywności jest ważna z punktu widzenia dalszej części pracy. W przypadku specyfikacji diagramów stanów UML obowiązuje następująca kolejność przetwarzania akcji: 1. Akcje wyjścia stanu początkowego. Jeżeli jest to stan złożony, to następuje wywołanie akcji wyjścia wszystkich aktywnych pod stanów, począwszy od najniższej struktury w hierarchii. Zasada ta, obowiązuje także dla przejść granicznych, czyli przechodzących pomiędzy różnymi poziomami hierarchii. 2. Akcje przejścia. 3. Akcje wejścia stanu docelowego. W przypadku stanów złożonych, zasada wywoływania akcji wejścia jest odwrotna niż przedstawiona w punkcie 1. W pierwszej kolejności wywoływane są akcje stanów nadrzędnych, a w dalszej kolejności podstanów. 82

83 Własność współbieżności maszyn stanowych w języku UML jest modelowana za pomocą stanów typu AND. Reprezentują one pojęcie regionów ortogonalnych. Najważniejszą cechą stanu typ AND jest całkowita niezależności w przetwarzaniu kolejnych zdarzeń w stosunku do innych stanów tego samego typu. Należy zwrócić uwagę na bardzo ważną cechę współbieżności regionów ortogonalnych. Ponieważ nie są one ze sobą w żadne sposób synchronizowane, nie jesteśmy w stanie przewidzieć, który ze stanów wykona pierwszy dane przejście. Każdy ze stanów AND otrzymuje swoją kopie zdarzeń oraz przetwarza ją niezależnie Pseudo stany Język UML definiuje szereg pseudo stanów, realizujących specyficzne funkcje, wykraczające poza standardową definicję maszyn Harel a. Pseudo stany pozwalają w sposób prosty i czytelny zapisać specyficzne funkcje diagramów stanów. Dzięki ich zastosowaniu znacząco zwiększa się siła ekspresji języka UML. Na rysunku 5.1 przedstawiono zestawienie pseudo stanów zgodnych ze specyfikacją UML 2.0. Rys Pseudo stany języka UML 2.0 Funkcjonalność poszczególnych pseudo stanów podano poniżej [17]: Pseudo stan początkowy (initial lub default) w przypadku stanów złożonych (super stanów) należy wskazać wewnętrzny stan, który zostanie uaktywniony po wejściu systemu w danych super stan. Służy do tego pseudo stan początkowy. Rozgałęzienie z warunkami (branch) stanowi rodzaj rozgałęzienia przejścia. W odróżnieniu od pseudo stanu rozgałęzienia, branch posiada dodatkowo wyrażenia warunkowe, które determinują aktywne przejścia w segmencie. 83

84 Rozgałęzienie (junction) najczęściej używany w celu połączenia kilku przejść lub w celu podzielenia jednego przejścia na kilka sekwencyjnych segmentów. W zależności od ilość połączonych segmentów, są wszystkie wykonywane w pojedynczym kroku run to completion. Rozwidlenie (fork) pozwala na podział przejścia na kilka regionów ortogonalnych. W przypadku rozgałęzienia, przejście aktywuje tylko jeden segment, natomiast fork aktywuje wszystkie segmenty równocześnie. Port wejściowy (entry point) pozwala na połączenie stanów podrzędnych bezpośrednio z innymi stanami zdefiniowanymi poza ich super stanem. Pseudo stan końcowy (terminal of finale) jeżeli jeden ze stanów podrzędnych osiągnie stan końcowy, oznacza to, że dany super stan nie akceptuje już nowych przejść. Najczęściej oznacza to konieczność usunięcia obiektu, którego dynamikę modeluje dany diagram stanów. Historia płaska (shallow history) zachowuje informacje, który z podstanów danego stanu był aktywny przed jego opuszczeniem. Pozwala to na powrót do tego samego stanu podrzędnego w przypadku ponownej jego aktywacji. Historia płaska zachowuje informacje jedynie dla poziomu n 1 hierarchii. Historia głęboka (deep history) działa podobnie jak historia płaska, jednak zachowuje informację o stanach aktywnych dla wszystkich poziomów hierarchii. Pseudo stan wyboru (choice point) jest rodzajem pseudo stanu rozwidlenia, jednak w odróżnieniu od junction, przed dokonaniem wyboru wykonuje zdefiniowaną listę akcji. Połączenie (join) pozwala na połączenie kilku przejść współbieżnych pochodzących z różnych regionów ortogonalnych. Port wyjścia (exit port) pozwala na powiązanie podstanów z innymi stanami zdefiniowanymi poza jego super stanem. 5.3 Definicja diagramu stanów w języku UML Bazując na powyższym opisie specyfikacji diagramów stanów w języku UML możemy zaproponować ich definicję, która będzie następnie wykorzystywana podczas budowy funkcji translacji. Zakładamy, iż definicja nie obejmuje elementów, które nie będą podlegały translacji do języka LOTOS. Przedstawiona definicja stanowi rozszerzenie pojęcia podanego przez Pnueli oraz Shavel [50]. Diagram stanów definiujemy jako szóstkę (, N, Γ, r,, Φ), gdzie stanowi skończony zbiór atomowych zdarzeń, N skończony zbiór nazw stanów, Γ jest zbiorem syntaktycznych przejść, r N oznacza stan początkowy, jest zbiorem skończonym pseudo stanów oraz Φ jest zbiorem wyrażeń warunkowych. Zakładamy, iż wyrażenia warunkowe mogą zwierać wyrażenia logiczne bazujące na alfabecie zdarzeń oraz zmiennych. Zbiór zdarzeń stanowi podstawę do skonstruowania oznakowania poszczególnych przejść. Dla każdego elementu zbioru π istnieje zdarzenie negatywne π określające brak zdarzenia. Zbiór Π = { π π }. Oznakowanie l składa się z określenia zdarzenia wyzwalającego oraz akcji. Oznaczenie zdarzenia wyzwalającego należy do podzbioru, natomiast oznaczenie akcji należy do podzbioru zbioru. Dla oznakowania przejścia l definiujemy następujące funkcję: event(l) zdarzenie wyzwalające, action(l) wyzwalana akcja. Wobec powyższego zbiór oznakowań przejść definiujemy jako: 2 2 Φ. Zakładamy, że event(l) action(l) nie zwiera przeciwstawnych oraz duplikujących się zdarzeń. Traktujemy wyrażenia warunkowe jako element oznakowania danego przejścia. Podobnie postępujemy w przypadku zbioru nazw stanów: 2 2, dla określenia listy akcji wejściowych oraz wyjściowych stanów. 84

85 Dla diagramu stanów (, N, Γ, r,, Φ) ze zbiorem nazw stanów powiązana jest funkcja children N : N 2 N, type N : N {or, and} oraz funkcja częściowa default N : N N. W przypadku jednoznacznego kontekstu, nie musimy wykorzystywać indeksu N. Oznaczmy przez NxN relację powiązania stan nadrzędny podrzędny. Z relacji n n wynika, że n children(n). Powyżej zdefiniowana relacja wprowadza strukturę drzewiastą stanów. Jeżeli type(n) = and, to stany podrzędne n są stanami współbieżnymi. Jeżeli type(n) = or, wtedy potomkowie n są zorganizowani sekwencyjnie tylko jeden z nich może być w danej jednostce czasu aktywny. Zakładamy, że stan typu and nie może posiadać potomków typu and. Dla każdego stanu n typu or, children(n), default(n) children(n) określa stan początkowy stanu n. Zbiór skończony pseudo stanów definiujemy jako = {, initial, junction, fork, join, choice point, entry point, exit point}. Pseudo stany traktujemy jako elementy grafu, które nie są brane pod uwagę podczas określania konfiguracji diagramu. Mogą jedynie pośredniczyć w relacji pomiędzy dwoma stanami. Jeżeli p oraz p=, oznacza to, że przejście nie wykorzystuje żadnego pseudo stanu. W diagramie stanów (, N, Γ, r,, Φ), zbiór przejść definiujemy jako Γ = N x x x N. Przejście t Γ, posiada początek, oznakowanie oraz koniec. Dla przejścia t=(n, l, p, n ) definiujemy funkcje: source(t)=n, target(t)=n oraz label(t) = l. Dodatkowo możemy powiedzieć, że event(t) = event (label(t)) oraz action(t) = action(label(t)) oraz, że stany n oraz n mają wspólny stan nadrzędny n : n,n children(n ). 5.4 Podsumowanie W rozdziale przedstawiono podstawowe pojęcia dotyczące syntaktyki oraz semantyki diagramów stanów języka UML 2.0. Przedstawiono formalną definicję diagramu stanów, która w kolejnych rozdziałach będzie wykorzystywana podczas specyfikacji funkcji translacji do implementacji w języku LOTOS. Definicja zwiera elementy notacji, które będą podlegały translacji. Dalsze prace będą prowadzone w zakresie translacji pełnej definicji diagramu stanów UML

86 6. Wprowadzenie metod formalnych do ROPES 6.1 Wprowadzenie Diagramy stanów wykorzystują strukturalny języki opisu dynamiki złożonych systemów reaktywnych [81]. Rozszerzają konwencjonalną definicję maszyn stanowych o dodatkowe trzy elementy notacji: hierarchię, współbieżność oraz komunikację. Dodanie hierarchizacji do definicji maszyn stanowych było konsekwencją problemów związanych z eksplozją ilości stanów dla złożonych systemów informatycznych. Podejście hierarchiczne umożliwia zastosowanie sprawdzonych w inżynierii oprogramowania metod analizy strukturalnej, które ułatwiają zarządzanie złożonością definiowanej specyfikacji. Popularne w inżynierii paradygmaty top down oraz bottom up mogą być zastosowane właśnie dzięki wprowadzeniu hierarchii, w tym także w maszynach stanowych. Współbieżność oraz komunikacja są standardowymi paradygmatami specyfikacji algebry procesów. Język LOTOS, bazujący na algebrze CCS pozwala na rzutowanie elementów języka UML modelujących współbieżność oraz komunikację do odpowiednich konstrukcji algebry procesów, bez konieczności stosowania dodatkowych konstrukcji semantycznych. Jednakże model hierarchiczny nie został jak dotychczas wprowadzony explicite do definicji algebry procesów oraz języka LOTOS. Jednym z celów niniejszej pracy jest zaproponowanie modelowania hierarchii procesów w języku LOTOS. W niniejszym rozdziale przedstawione zostaną zasady oraz algorytmy translacji diagramów stanowych UML 2.0 do specyfikacji w języki LOTOS. Uzyskany w ten sposób model formalny systemu będzie następnie wykorzystany w procesie ROPES w celu weryfikacji poprawności specyfikacji na poszczególnych etapach projektu. W niniejszym rozdziale będą wykorzystane informacje zawarte w rozdziale 5 dotyczące poszczególnych elementów składni UML, które będą podlegały translacji do języka LOTOS. Metoda translacji zostanie przedstawiona etapami. Poszczególne etapy będą zawierały jedynie części algorytmu translacji. W przypadkach kiedy nie jest to koniecznie, stosowana będzie wersja Basic języka LOTOS (bez użycia zmiennych). Jednakże w niektórych sytuacjach konieczne będzie stosowanie Full LOTOS. Podany algorytm pozwala na odpowiednie dobranie wersji języka, tak aby narzędzia weryfikujące wchodzące w skład pakiety CADP mogły być wykorzystane optymalnie. 6.2 Translacja maszyny stanowej płaskiej W przypadku maszyny stanowej płaskiej, zwanej także maszyną skończenie stanową lub automatem skończonym, model zawiera jedynie definicję stanów oraz przejść. Przejścia są aktywowane zajściem odpowiednich zdarzeń w otoczeniu systemu. Dodatkowo uwzględnimy specyfikacje UML w zakresie pseudo stanów: rozpoczęcia oraz zakończenia. Poniżej przedstawiono algorytm translacji maszyny stanowej płaskiej do specyfikacji LOTOS. Założenia: 1. Wyjściowy diagram stanów zawiera jedynie węzły typu OR. 2. Zdarzenia nie posiadają zmiennych, przesyłanych pomiędzy stanami. 3. Ze względu na brak zmienny nie są stosowane warunki predykatów, pseudo stany decyzyjne, fork, join oraz junction. 4. Stany nie wykonują żadnych akcji w wyniku wejścia lub wyjścia z danego stanu. 5. Diagram stanów jest płaski. Są to założenia wstępne, wymagane jedynie do prezentacji translacji skończonej maszyny stanowej. W dalszej części niniejszego rozdziału powyższe założenia zostaną usunięte. 86

87 Algorytm przejścia z definicji FSM do specyfikacji LOTOS: 1. Każde zdarzenie maszyny stanowej jest rzutowane do akcji w rozumieniu specyfikacji języka LOTOS. 2. Każdy stan jest rzutowany do instancji procesu definiującego dany stan. 3. Przejścia pomiędzy stanami realizowane jako powiązanie akcji, operatora prefiksu ; oraz stanu następującego po wyzwoleniu danego zdarzenia. 4. Rozróżnienie pomiędzy następującymi stanami realizowane jest poprzez zastosowanie operatora wyboru []. 5. Pseudo stan początkowy reprezentowany jest jako instancja procesu w klauzuli specyfikacji. 6. Pseudo stan końcowy jest reprezentowany przez proces Finish bez definicji kolejnych akcji. Algorytm 6.1. Algorytm translacji FSM do języka LOTOS Wprowadźmy funkcję transformującą Specyfication. Jej postać dla algorytmu 6.1 podano poniżej. W kolejnych krokach będziemy uzupełniać podaną funkcję o dodatkowe funkcjonalności. _. :. Process_definition :=. gdzie: : ; _ _ Name zwraca nazwę obiektu podanego jako argument. type zwraca typ stanu. Lista dostępnych typów to: ROOT, OR, AND. event zwraca nazwę zdarzenia wyzwalającego. entry_action, exit_action zwraca listę akcji wejściowych, wyjściowych stanu. exit_state, entry_state zwraca nazwę stanu początkowego, końcowego przejścia. Definicja 6.1. Definicja funkcji translacyjnej algorytmu

88 Na podstawie podanego algorytmu budujemy mapę translacyjną notacji UML do języka LOTOS. Rys Mapa translacyjna algorytmu 6.1 Bazując na podanym schemacie rzutowania przystąpimy do translacji przykładowej specyfikacji systemu sterowania dmuchawy grzewczej [17] (w specyfikacji występuje pod nazwą Blower), posiadającej dwie prędkości obrotowe. Przykład ten będzie w dalszej części rozdziału wykorzystywany do wprowadzenia kolejnych elementów notacji języka UML. Prezentowane podejście będzie bazować na paradygmacie top down. Kolejne wersje specyfikacji będziemy uzupełniać o dodatkowe uszczegółowienia dynamiki systemu. System dmuchawy jest sterowany prostym dwustanowym przełącznikiem on/off. Prezentuje to rysunek 6.2. Rys Model FSM dla systemu dmuchawy 88

89 Wyrażeniami evswithon oraz evswithoff oznaczono zdarzenia zachodzące w otoczeniu systemu, wpływające na stan przełącznika. W wyniku zastosowania rzutowaniaa z rysunku 6.2 otrzymujemy następującą specyfikację w języku LOTOS. specification Blower1 [evswitchon, evswitchoff] : exit behaviour Off [evswitchon, evswitchoff] where (* Definicje poszczegolnych stanow *) (* Stan Off *) process Off [evswitchon, evswitchoff] : exit := evswitchon; On [evswitchon, evswitchoff] endproc endspec (* Stan On *) process On [evswitchon, evswitchoff] : exit : evswitchoff; Off [evswitchon, evswitchoff] endproc Model 6.1. Implementacja systemu FSM Rys Graf BCG modelu Translacja hierarchicznej maszyny stanowej W celu weryfikacji poprawności tak otrzymanej specyfikacji możemy wygenerować etykietowany graf przejść LTS. W tym celu możemy skorzystać z narzędzi dostępnych w pakiecie CAESAR[81]. Graf BCG (Binary Coded Graphs) jest standardowym formatem reprezentacji LTS odpowiadającego danej spe cyfikacji LOTOS. Na rysunku 6.3 przedstawiono otrzymany graf BCG dla modelu Hierarchia procesów Semantyka algebry procesów w naturalny sposób wprowadza możliwość modelowania dwóch wła się po sności diagramów stanów UML: współbieżności oraz komunikacji. Współbieżność realizujee przez wprowadzeniee niezależnych procesów, które komunikują się ze sobą z wykorzystaniem zdefi identy niowanych bram. Natomiast hierarchizacja procesów nadal jest przedmiotem badań. Obecnie fikuje sięę dwa główne podejścia w definiowaniu hierarchii procesów. Oba bazują na wprowadzeniu nowego operatora algebry, łączącego procesy w strukturę semantyczną oraz umożliwiającego prze kazanie sterowania z procesu podrzędnego do procesu nadrzędnego. 89

90 Pierwsze podejście bazuje na zaproponowanym przez Andrew C.Uselton oraz Scotta A.Smolka [64] operatorze state refinement uszczegółowienie stanu. Operator ten stanowi uzupełnienie podstawowej algebry procesów BPA. Operator binarny uszczegółowienia stanu oznacz się przez s[t]. Intuicyjnie zapis ten można rozumieć, iż proces t uszczegóławia proces s lub podobnie, iż proces t stanowi podstrukturę procesu s. Operator [] posiada następujące reguły SOS: Równanie 6.1. Reguły dedukcyjne dla operatora state refinement Drugie podejście wykorzystuje wprowadzony przez J.A.Bergstra oraz J.C.M.Baetena [2] operator mode transfer. Operator ten został wprowadzony całkowicie niezależnie od state refinement i jest próbą algebraicznego ujęcia operatora wywłaszczenia disabling występującego w języku LOTOS i oznaczonego symbolem [>. Potrzeba wprowadzenia tego operatora wynikała z konieczności zastosowania mechanizmów przerywających działanie procesu wywłaszczenia i przekazania sterowania do procesu wywłaszczającego. Interesujące jest porównanie reguł dedukcyjnych SOS dla obu operatorów. state refinament mode transfer Równanie 6.2. Porównanie działania operatorów Zasadnicza różnica wynika z faktu, iż w przypadku operatora state refinament po zakończeniu procesu t (podrzędnego) sterowanie przekazywane jest do procesu nadrzędnego. Natomiast, w przypadku operatora mode transfer zakończenie procesu podrzędnego powoduje, iż nie można już powrócić do procesu nadrzędnego s poprzez zastosowanie operatora wywłaszczenia. Obecnie do standardu ISO języka LOTOS został wprowadzony operator wywłaszczenia [>, dlatego też w niniejszej pracy zastosowano drugie podejście do realizacji hierarchii procesów. Konsekwencją takiego wyboru będzie konieczność wprowadzenia do specyfikacji systemu pojęcia portów wejścia/wyjścia super stanu. Będzie to konieczne przede wszystkim w przypadku tranzycji przekraczających granicę super stanu, tzw. przejść granicznych Implementacja hierarchii procesów w języku LOTOS W niniejszym paragrafie przedstawione zostaną metody translacji hierarchicznej maszyny stanowej. W celu utrzymania przejrzystości prezentacji pozostaną utrzymane dotychczasowe założenia, poza ostatnim dopuścimy istnienie wewnętrznej struktury w stanach. Ze względu na wprowadzenie hierarchii musimy dodać założenie, iż na tym etapie nie będziemy modelować przypadków przejść granicznych, czyli przechodzących pomiędzy różnymi poziomami struktury hierarchii. 90

91 Poniżej przedstawiono uzupełnienie algorytmu translacji hierarchicznej maszyny stanowej: 7. Poszczególne podstany są definiowane jako procesy zagnieżdżone w procesie nadrzędnym. 8. Definicje poszczególnych podprocesów wprowadzamy do lokalnej klauzuli where. 9. Do procesu nadrzędnego wprowadzamy operator wywłaszczenia [>. 10. Jako lewy argument operatora [> podajemy wywołanie procesu podrzędnego wskazanego przez pseudo stan rozpoczęcia. 11. Prawy argument operator [> stanowi realizację powiązań procesu nadrzędnego z innym procesami tego samego poziomu hierarchii, zgodnego ze specyfikacją. Algorytm 6.2. Dodanie rzutowania procesów hierarchicznych Podobnie jak w poprzednim przypadku przedstawiono mapę translacyjną języka UML do notacji LO TOS. Rys Mapa translacyjna dla algorytmu 6.2 Stosując powyższe rzutowanie uzupełnimy specyfikację przykładowego systemu dmuchawy grzewczej o możliwość przełączania pracy silnika pomiędzy dwoma prędkościami. Na rysunku 6.5 przedstawiono model uzupełnionego diagramu stanów. Zdarzenia tohigh oraz tolow oznaczają przejścia do odpowiednio wyższej i niższej prędkości obrotowej. 91

92 Rys Przykładowy diagram stanów dla struktury hierarchicznej Process_definition := else : if compose state i false then endproc Name Default state i _ where _ ; _ ; _ endproc. : _ : _ gdzie: Default funkcja zwracająca podstan początkowy danego super stanu. Definicja 6.2. Obsługa struktur hierarchicznych Na bazie nowego diagramu stanów otrzymujemy specyfikację w języku LOTOS. Na uwagę zasługuje użycie operatora [>. W przypadku płaskiej maszyny stanowej połączenia z innym stanami poprzez użycie operatora wyboru [] stanowiły główną definicję ciała procesu. W przypadku procesów zagnieżdżonych blok ten zostaje użyty jako prawa strona operatora [>. Wynika to z interpretacji funkcji tego operatora podanej w równaniu 6.2. Procesy podrzędne będą aktywne dopóty, dopóki proces(stan) nadrzędny będzie aktywny. W momencie przejścia do innego stanu, procesy podrzędne kończą swoje działanie. W celu weryfikacji powstałego modelu możemy stworzyć odpowiadający jej graf tranzycji. Na rysunku 6.6 przedstawiono graf BCG dla modelu z rysunku

93 Rys Graf BCG dla implementacji modelu 6.2 specification Blower2 [evswitchon, evswitchoff, tohigh, tolow] : exit behaviour Off [evswitchon, evswitchoff, tohigh, tolow] where (* Stan Off *) process Off [evswitchon, evswitchoff, tohigh, tolow] : exit := evswitchon; On [evswitchon, evswitchoff, tohigh, tolow] endproc (* Stan On *) process On [evswitchon, evswitchoff, tohigh, tolow] : exit = LowSpeed [evswitchon, evswitchoff, tohigh, tolow] [> (* przejście do innego stanu na wyższym poziomie hierarchii *) ( evswitchoff; Off [evswitchon, evswitchoff, tohigh, tolow] ) where (* Definicje poszczególnych stanów *) (* Stan LowSpeed *) process LowSpeed [evswitchon, evswitchoff, tohigh, tolow] : exit := tohigh; HighSpeed [evswitchon, evswitchoff, tohigh, tolow] endproc endproc endspec (* Stan HighSpeed *) process HighSpeed [evswitchon, evswitchoff, tohigh, tolow] : exit := tolow; LowSpeed [evswitchon, evswitchoff, tohigh, tolow] endproc Model 6.2. Implementacja hierarchii procesów 93

94 6.4 Regiony ortogonalne stanów typu AND Podstawowym modelem współbieżności diagramów stanów są regiony ortogonalne, realizujące koncepcję stanów typu AND. Poszczególne stany typu AND stanowią niezależne obszary, w których przejścia pomiędzy stanami zachodzą bez żadnej synchronizacji. Odnosząc koncepcję regionów ortogonalnych UML do języka LOTOS, należy wskazać na definicję kompozycji równoległej procesów. Jeżeli procesy te nie komunikują się ze sobą (takie założenie posiada definicja regionów ortogonalnych), to należy zastosować operator rozłączności interleaving oznaczony symbolem III. Nadal zakładamy, że nie są wykorzystywane pseudo stany fork oraz join, które zostaną wprowadzone w kolejnym kroku omawianej metody. W celu uzupełnienia naszego algorytmu translacji o możliwość tworzenia regionów ortogonalnych wprowadzamy następujące dodatkowe kroki translacji: 12. Stany typu AND traktujemy jako procesy podrzędne do procesu odpowiadającego super stanowi, podzielonego na regiony ortogonalne. 13. W definicji ciała procesu nadrzędnego wprowadzamy jako lewą stronę operatora [> kompozycję równoległą, bez synchronizacji poszczególnych procesów podrzędnych typu AND. Algorytm 6.3. Obsługa regionów ortogonalnych Następnie uzupełniamy mapę translacji o kolejne elementy notacji języka LOTOS. Process_definition := : if compose state i false then else ; _ _ endproc ; _ _ where : _ : endproc. _ Definicja 6.3. Funkcja uzupełniona o obsługę regionów ortogonalnych 94

95 Rys Mapa translacyjna dla algorytmu 6.3 Uzupełniając modelowany przykład systemu dmuchawy dodajemy specyfikację modułu grzewczego, który działa niezależnie od napędu wiatraka. Oznacza to, iż mamy dwa niezależne obszary działania systemu. Modelujemy je jako regiony ortogonalne. Dodatkowo zakładamy, że moduł grzewczy może działać w trzech stanach odpowiadających mocy z jaką ogrzewa wydmuchiwane powietrze: LowHead, MediumHead, HighHead. Zmiany pomiędzy stanami mogą zachodzić jedynie sekwencyjnie. Na rysunku 6.8 przedstawiono uzupełniony model w języku UML. Rys Rozbudowany model dmuchawy o dwa regiony ortogonalne 95

96 Na podstawie mapy translacyjnej zaprezentowanej na rysunku 6.7 można stworzyć następującą specyfikację w języku LOTOS. specification Blower3 [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] : exit: behaviour Off [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] where (* Stan Off *) process Off [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] : exit := evswitchon; On [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] endproc (* Stan On *) process On [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] : exit := ( LowSpeed [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] Heating [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] ) [> (* przejście do innego stanu na wyższym poziomie hierarchii *) evswitchoff; Off [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] ) where process LowSpeed [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] : exit := tohigh; HighSpeed [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] endproc process HighSpeed [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] : exit := tolow; LowSpeed [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] endproc process Heating [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] : exit := LowHeat [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] where process LowSpeed [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] : exit := tohigh; HighSpeed [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] endproc process HighSpeed [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] : exit := tolow; LowSpeed [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] endproc process Heating [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] : exit := LowHeat [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] where process LowHeat [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] : exit := evmediumheat; MediumHeat [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] endproc process MediumHeat [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] : exit := evhighheat; HighHeat [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] endproc process HighHeat [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] : exit := evlowheat; LowHeat [evswitchon, evswitchoff, tohigh, tolow, evlowheat, evmediumheat, evhighheat] endproc endproc endproc endspec Model 6.3. Implementacja specyfikacji 6.8 w języku LOTOS Na podstawie przedstawionej specyfikacji utworzono diagram LTS. Na rysunku 6.9 zaprezentowano odpowiadający mu graf BCG. 96

97 Rys Graf BCG dla modelu Modelowanie przejść granicznych oraz przejść warunkowych Problem zastosowania przejść granicznych w modelowaniu maszyn stanowych jest poruszany przez wielu ekspertów z dziedziny metod formalnych. Przeciwnicy wprowadzania do specyfikacji przejść granicznych powołują się na argumenty związane z teorią poprawnej definicji poszczególnych pozio wiążą mów hierarchii. Według niektórych ekspertów konieczność wykorzystania przejść granicznych cych różne poziomy hierarchii oznacza nieodpowiedniee podejście projektanta do podziału na po mode szczególne poziomy abstrakcji systemu, odpowiadających poszczególnym poziomom hierarchii lu. Jednakżee w dyskusji pojawiają się także opinie, które wskazują na duże zalety stosowania przejść granicznych. Są to przede wszystkim argumenty pragmatyczne, bazujące na dotychczasowym do przejść świadczeniu w projektowaniu systemów czasu rzeczywistego. Dowodzi się, iż zastosowanie granicznych znacznie upraszcza budowę modelu. Należy także wskazać, iż elementy języka UML takie jak pseudo stany join oraz fork wymagają, ze względu na swoją specyfikę, zastosowania przejść gra przejścia graniczne. Podczas opracowywaniaa algorytmu translacji koniecznym okazało się zastosowa nie zmiennych powiązanych z akcjami. W związku z tym wprowadzono wersję języka Full LOTOS. nicznych. Dlatego też w niniejsze pracy wprowadzono metody translacji modelu UML zawierającego Więcej informacji na temat Full LOTOS czytelnik znajdzie w rozdziale 4. Dodatkowo wprowadzono do algorytmu translacji warunki akceptacji zdarzeń oraz pseudo stan decyzji. 97

98 W celu poprawnego zamodelowania przejścia granicznego należy wprowadzić nowy element specyfikacji, umożliwiający jednoznaczną identyfikację podziału obszarów pomiędzy stanem nadrzędnym i docelowym przejścia. Koncepcja portów została wprowadzona w pracy Arnab Ray, Rance Cleaveland oraz Arne Skou [51] jako struktury wewnętrznej stanów. Wymienieni autorzy dodatkowo wprowadzili operatory bazujące na algebrze BPA, pozwalające na budowę hierarchicznych maszyn stanowych. W przypadku omawianego algorytmu pojęcie portów pozwoli na określenie, które stany w danym super stanie powinny być uaktywnione po wyzwoleniu danego przejścia. Poniżej podano kolejne kroku algorytmu translacji. sorts InPort_Sort opts endtype sorts OutPort_Sort opts endtype. Process_definition := :!,! : _! : _ : _ : if compose state i false then else _ endproc _ hide Name state i _exit in ; _ ; _! ; ; _ Name state i _exit?out_port:outport_sort; where _ endproc. _ : _ : Definicja 6.4. Rozszerzenie procesu o obsługę portów wejścia/wyjścia 98

99 14. Definiujemy dwa typy danych odpowiadających portom wejściowym i wyjściowym super stanów. Tworzymy odpowiednią listę portów wejściowych oraz wyjściowych. Do listy portów wejściowych dodajemy port domyślny Default. 15. W ciele definicji procesu nadrzędnego dodajemy obsługę portów wejściowych. Jako lewy parametry operatora [> wprowadzamy listę wyboru poszczególnych wejść stanu. Poszczególne porty obsługujemy poprzez odpowiedni warunek na zmiennej in_port. 16. Do definicji ciała procesu nadrzędnego dodajemy obsługę zdarzenia wewnętrznego, niewidocznego dla obserwatora zewnętrznego: hide <nazwa stanu>_exit in. Zdarzenie to będzie wyzwalane w momencie zgłoszenia wyjścia procesu podrzędnego przez port wyjściowy, wskazany poprzez zmienną powiązaną. 17. W definicji procesu podrzędnego dodajemy procedurę obsługi zdarzenia wyjścia, poprzez ofertę zdarzenia sparametryzowanego. Algorytm 6.4. Obsługa przejść granicznych Mapa translacji dla podanych kroków algorytmu została przedstawiona na rysunku Na uwagę zasługuje wprowadzenie do modelu zdarzeń ukrytych. Rys Mapa translacyjna dla algorytmu

100 Poniżej przedstawiono przykład działania funkcji translacyjnej dla specyfikacji systemu wykorzystują Jeżeli modelowany system posiada zestaw zmiennych, które będą następnie wykorzystywane pod cej przejścia graniczne. Obsługa przejść granicznych wykorzystuje mechanizm przejść warunkowych. czas przejść warunkowych, należy te typy zadeklarowaćć w sekcji type endtype, a następnie wpro ma to wadzić odpowiedniee warunki na zmienne przekazywanee do poszczególnych procesów, tak jak miejsce w przypadku przekazywania nazwy portów. Deklaracja warunku występuje przed akceptacją zdarzenia w ciele procesu. Wykorzystując ten sam mechanizm modelujemy także przejścia warunko we. S evts T T1 S1 evs2 ST2 evt1 evt2 evs1 S2 T2 evoff Off Rys Przykładowy diagram stanów wykorzystujący przejścia graniczne Na rysunku 6.12 przedstawiony odpowiadający przykładowemu modelowi graf BCG. Rys Graf BCG dla modelu

101 6.6 Modelowanie pseudo stanów fork, join oraz condition Dzięki zastosowaniu zaprezentowanej powyżej metody implementacji przejść granicznych, modelowanie pseudo stanów fork oraz join nie nastręcza większych trudności. Dodatkowo wprowadzamy synchronizację niezależnych obszarów ortogonalnych poprzez operator częściowej synchronizacji. W języku UML stosuje się niekiedy explicite pojęcie punktów synchronizacji. Ich modelowanie w języku LOTOS odbywa się w sposób zaprezentowany poniżej. 18. W obszarze instancji regionów ortogonalnych, wprowadzamy operator częściowej synchronizacji. Jako zdarzenie synchronizujące wprowadzamy zdarzenie wyjściowe superstanu. 19. Pseudo stan condition modelujemy poprzez wprowadzenie przejść warunkowych w poszczególnych stanach docelowych. Algorytm 6.5. Obsługa pseudo stanów fork, join oraz condition Process_definition := : _ : if compose state i false then else endproc _ _ _ hide Name state i _exit in ; _ ; _! ; ; _ Name state i _exit?out_port:outport_sort; child state i where _ : _ : endproc. _ Definicja 6.5. Obsługa pseudo stanów fork, join 101

102 Na rysunku 6.13 przedstawiono mapę translacyjna dla kolejnych kroków algorytmu. port_in1 port_in2 Stan_A Stan_A1 Stan_A1_A Stan_A2 Stan_A2_A port_out1 port_out2 zdarzenie_1 process Stan_A [...] : exit := hide exit_int in ( Stan_A1 [...](port_in1) [zdarzenie_1] Stan_A2 [...](port_in2) [>... >> Stan_B[...] where... endproc zdazenie_1!true zdazenie_1!false Stan_A Stan_B process Stan_A [...](warunek:boolean) : exit := [warunek=true] -> zdazenie_1;stan_a1 [...](warunek)... endproc process Stan_B [...](warunek:boolean) : exit := [warunek=false] -> zdazenie_1;stan_b1 [...](warunek)... endproc Rys Mapa translacyjna dla pseudo stanów fork, join oraz condition W celu zaprezentowania działania powyższego rzutowania przedstawiono przykład diagramu stanów z pseudo stanami fork oraz join. Model 6.4 stanowi implementację przykładu w języku LOTOS. Rys Przykład modelu z wykorzystaniem pseudo stanów 102

103 specification Test2 [evstart, evstop, evdown, evoff, evexc] : exit type OutPortName is sorts OutPort_Sort opns Heading_out (*! constructor *): > OutPort_Sort endtype type InPortName is sorts InPort_Sort opns Default (*! constructor *) : > InPort_Sort endtype behaviour On [evstart, evstop, evdown, evoff, evexc] where process On [evstart, evstop, evdown, evoff, evexc] : exit := evstart; Heating [evstart, evstop, evdown, evoff, evexc] endproc process Heating [evstart, evstop, evdown, evoff, evexc] : exit := hide exit_int in (( Heating1 [evstart, evstop, evdown, evoff, evexc, exit_int](default) [evoff] Heating2 [evstart, evstop, evdown, evoff, evexc, exit_int](default) ) [> evexc; Exception [evstart, evstop, evdown, evoff, evexc] ) >> Off [evstart, evstop, evdown, evoff, evexc] where process Heating1 [evstart, evstop, evdown, evoff, evexc, exit_int](in_port:inport_sort) : exit := Start [evstart, evstop, evdown, evoff, evexc, exit_int] where process Start [evstart, evstop, evdown, evoff, evexc, exit_int] : exit := evstop; SStop [evstart, evstop, evdown, evoff, evexc, exit_int] endproc process SStop [evstart, evstop, evdown, evoff, evexc, exit_int] : exit := evoff; exit_int!heading_out; exit endproc endproc process Heating2 [evstart, evstop, evdown, evoff, evexc, exit_int](in_port:inport_sort) : exit := Up [evstart, evstop, evdown, evoff, evexc, exit_int] where process Up [evstart, evstop, evdown, evoff, evexc, exit_int] : exit := evdown; Down [evstart, evstop, evdown, evoff, evexc, exit_int] endproc process Down [evstart, evstop, evdown, evoff, evexc, exit_int] : exit := evoff; exit_int!heading_out; exit endproc endproc endproc process Off [evstart, evstop, evdown, evoff, evexc] : exit := i; exit endproc process Exception [evstart, evstop, evdown, evoff, evexc] : exit := i; exit endproc endspec Model 6.4. Implementacja w języku LOTOS diagramu

104 6.7 Podsumowanie Przedstawiony w niniejszym rozdziale algorytm pozwala przeprowadzić automatyczną translację diagramów stanów zaimplementowanych w języku UML do specyfikacji w języku LOTOS. Model maszyny stanowej po translacji zachowuje najważniejsze cechy diagramów UML, czyli: współbieżność, komunikację oraz hierarchię. Otrzymana specyfikacja jest przedstawiona za pomocą diagramów procesów zgodnych z algebrą BPA. Dzięki czemu uzyskujemy możliwość formalnej weryfikacji własności modelu behawioralnego projektowanego systemu. W zależności o wykorzystywanych elementów notacji UML, algorytm bazuje na wersji Basic lub Full LOTOS. Rozróżnienie to pozwala na stworzenie czytelnego oraz ekonomicznie uzasadnionego modelu, który będzie mógł zostać zweryfikowany przy użyciu dostępnych narzędzi. Poza opisem formalnym funkcji translacyjnej przedstawiono mapy translacyjne, prezentujące rzutowanie poszczególnych składni syntaktycznych obu języków w postaci graficznej. Treść teoretyczną wzbogacono o przykłady prostych modeli, ilustrujące zaproponowane konstrukcje. Zaprezentowane podejście kolejnych przybliżeń na przykładzie dmuchawy grzewczej będzie wykorzystywane w kolejnych rozdziałach do weryfikacji poprawności kolejnych iteracji specyfikacji z wykorzystaniem relacji bisymulacji oraz preorder. Wyniki pracy zawartej w niniejszym rozdziale posłużą następnie do wzbogacenia metodologii ROPES o elementy formalnej weryfikacji własności tworzonych modeli behawioralnych projektowanego systemu. 104

105 7. Weryfikacja własności modeli systemu 7.1 Wprowadzenie Jedną z głównych przesłanek wprowadzenia metod formalnych do inżynierii oprogramowania jest możliwość ścisłego dowodzenia zadanych własności tworzonego systemu informatycznego. Metody formalne opierając się na matematycznych definicjach oraz twierdzeniach pozwalają dowodzić poprawności oprogramowania. Proces ten polega na poszukiwaniu spełnialności zadanych warunków przez model systemu. Jeżeli model spełnia te warunki, to twierdzimy, iż oprogramowanie spełnia zadane wymagania 1. W przypadku algebry procesów oraz języka LOTOS jedną z najczęściej spotykanych metod dowodzenia własności są badania relacji pomiędzy etykietowanymi grafami przejść LTS. Istnieje szereg algorytmów i narzędzi, które automatyzują proces badania relacji pomiędzy grafami. Jednym z najczęściej wykorzystywanych polega na sprowadzeniu problemu badania relacji równoważności lub preorder do rozwiązania układu równań logicznych BES (Boolean Equation System). Praktyczna realizacja badania relacji pomiędzy modelami możliwa jest dzięki zastosowaniu narzędzi wspomagających takich jak CADP. W ramach tego pakietu dostępne jest narzędzie bisimulator, pozwalające na automatyczną weryfikację zadanych relacji pomiędzy dwoma grafami LTS. Istotną cechą tego narzędzia, odróżniającą go od innych implementacji algorytmu BES, jest możliwość generacji kontrprzykładów w przypadku weryfikacji negatywnej. Możliwość wykorzystania algorytmu rozwiązywania równań BES w oparciu o model algebraiczny systemu udostępnia szeroki wachlarz innych metod weryfikacji własności systemu, należących do kategorii weryfikacji modelowej (model checking). W niniejszej pracy wykorzystano formalizm zaczerpnięty z logiki temporalnej alternative free rachunek μ. Podobnie jak w przypadku badań relacji równoważności grafów LTS, weryfikacja własności bezpieczeństwa, czy też jej egzemplifikacji jako braku zakleszczeń (deadlock) sprowadza się do rozwiązania układu równań logicznych. Z punktu widzenia procesu wytwarzania oprogramowania własności modelu powinny być definiowane podczas analizy wymagań systemu. Własności te powinny być następnie zakodowane do odpowiedniej konwencji logiki temporalnej. Dodatkową zaletą wprowadzenia powyższego formalizmu do metodologii ROPES jest możliwość praktycznej realizacji zaproponowanego podejścia. Pakiet CADP zawiera moduł evaluator, który pozwala na rozwiązanie zadań weryfikacyjnych bazując na modelu w postaci grafu LTS oraz własności zakodowanych z użyciem odpowiedniej logiki. W niniejszym rozdziale szczegółowo zostaną omówione definicje, twierdzenia oraz algorytmu, które służą do realizacji powyżej wymienionych zadań weryfikacji własności modeli. 7.2 Poprawność procesu w kontekście relacji modeli Jednym z podstawowym typów relacji pomiędzy dwoma modelami jest relacja równoważności. Poszukiwanie równoważności modeli jest istotne z punktu widzenia weryfikacji poprawności procesu wytwarzania oprogramowania. Jeżeli przyjmiemy, iż proces wytwarzania jest iteracyjny, to poprawność tego procesu możemy zdefiniować jako: Definicja 7.1 Produkt jest poprawny w danej iteracji procesu wytwarzania oprogramowania, jeżeli spełnia warunki zdefiniowane w iteracji poprzedniej. 1 Zakładamy przy tym poprawność translacji: diagram UML > model LOTOS. 105

106 Produkt procesu wytwarzania oprogramowania rozumiemy nie tylko jako oprogramowanie, ale także każdy artefakt będący wynikiem zakończenia pewnej fazy projektu. Zgodnie z definicją 7.1 poszukujemy relacji pomiędzy warunkami specyfikacji S i oraz S i 1. W przypadku interesujących nas systemów reaktywnych, modelowanych za pomocą maszyn stanowych, możemy powiedzieć, iż dwa modele są równoważne, jeżeli maszyna stanowa S i symuluje maszynę stanową S i 1. Pojęcie symulacji można zobrazować jak w poniższej definicji. Definicja 7.2 Mówimy, że model S i symuluje model S i 1, jeżeli dla każdego zdarzenia należącego do specyfikacji S i 1, odpowiedzi systemów S i oraz S i 1 są identyczne. Oznacza to, że obserwator zewnętrzny, testujący system S i 1 nie rozpozna różnicy po podmianie obiektu testowanego na S i. Należy zwrócić uwagę, iż definicja 7.2 pokrywa jedynie relację jednokierunkową. Wynika z niej, że system S i symuluje S i 1, jednakże relacja odwrotna niekoniecznie musi wystąpić. Nie jest istotne tutaj, jakie stany są osiągane w systemie S i oraz S i 1. Istotny jest warunek odpowiedzi systemu na zdarzenie wewnętrzne. Wprowadzone powyżej pojęcie odpowiada relacji słabej symulacji, która nie uwzględnia struktury akcji wewnętrznych systemów. Jeżeli obserwator będzie miał także możliwość obserwacji akcji wewnętrznych, to relacja symulacji będzie silna. Chcąc zdefiniować relację dwukierunkową musimy wprowadzić pojęcie bisymulacji. W tym przypadku relacja symulacji musi być relacją symetryczną. Tak jak w przypadku symulacji, bisymulacja oparta o obserwowalne odpowiedzi systemu jest bisymulacją słabą, nazywaną także bisymulacją obserwowalną. Jeżeli obserwator będzie miał także możliwość obserwacji akcji wewnętrznych, to relacja bisymulacji będzie odpowiednio silna. Z punktu widzenia procesu wytwarzania oprogramowania relacja symulacji jest warunkiem koniecznym, aby proces był poprawny. Należy jednak przeanalizować relację zachodzącą pomiędzy specyfikacją systemu a jego implementacją. Projektanci systemu informatycznego, zakładają, że specyfikacja definiuje kompletny zakres funkcjonalny systemu. Oznacza to, że jeżeli zaimplementowany system posiada funkcje nieopisane w specyfikacji, to pomimo że system ją symuluje (spełnia warunek konieczny), może wykraczać poza zakres zakładany przez projektantów systemu. W skrajnym przypadku system może realizować zadania, które powodują jego błędne, nieprzewidziane działanie. Powyższa obserwacja jest też bardzo istotna także z punktu widzenia ekonomii realizowanych projektów informatycznych. Dlatego należy uzupełnić warunek konieczny o warunek wystarczający, stwierdzający iż pomiędzy modelem specyfikacji systemu a jego implementacją musi zachodzić relacja bisymulacji. Rodzaj relacji bisymulacji w warunku wystarczającym jest istotny z punktu widzenia zastosowanego formalizmu. Zgodnie z tym, co zostało przedstawione powyżej słaba bisymulacja, czyli bisymulacja obserwowalna nie uwzględnia przejść wewnętrznych modelu, co może mięć istotne znaczenie dla modelowania działania systemu. Dodatkowo słaba bisymulacja nie spełnia aksjomatów dla operatora sumowania [] w algebrze CCS. Z tego powodu wprowadzono relacje obserwowalnej kongruencji (przystawania) dwóch modeli. Obserwowalna kongruencja jest operatorem silniejszym od słabej symulacji, ponieważ uwzględnia także przejścia wewnętrzne modelu, ale tylko pod względem jakościowym (wystąpienie pewnej liczby akcji ukrytych), a nie ilościowym (pomijana jest ilość tychże wystąpień). Dlatego też relacja obserwowalnej kongruencji jest odpowiednia dla warunku równoważności specyfikacji oraz implementacji. W kolejnych paragrafach rozdziału przedstawione zostaną definicje oraz twierdzenia dotyczące omawianych klas relacji równoważności oraz preorder. 106

107 7.3 Relacje modeli równoważności Przed określeniem poszczególnych relacji związanych z algebrami procesów przytoczymy znaną w teorii zbiorów definicję relacji równoważności. Definicja 7.3 Niech X oznacza dowolny zbiór. Relacja binarna R zdefiniowana nad X jest podzbiorem X x X. Jeżeli R jest relacją równoważności, to spełnia następujące warunki: 1. R jest relacją zwrotną, czyli xrx dla każdego x X. 2. R jest relacją symetryczną, czyli xry yrx, dla każdego x,y X. 3. R jest relacją przechodnią, czyli xry yrz xrz, dla każdego x,y,z X. Podstawowym rodzajem relacji równoważności jest relacja równość dwóch modeli LST. Jest to relacja izomorficzna ze względu na model LTS. Z punktu widzenia jej rzadkiego praktycznego zastosowania, relacja równości nie jest przedmiotem naszego zainteresowania Relacja bisymulacji Najczęściej spotykanym rodzajem relacji równoważności jest wspomniana wcześniej relacja bisymulacji silnej. Definicja 7.4 Relację binarną R zdefiniowaną nad zbiorem stanów modelu LTS nazywamy bisymulacją, wtedy i tylko wtedy gdy dla każdego s 1 Rs s oraz dowolnej akcji α zachodzi: α α 1. Jeżeli s 1 s1, to istnieje przejście s 2 s2, takie że s 1 Rs 2. α α 2. Jeżeli s 2 s2, to istnieje przejście s 1 s1, takie że s 1 Rs 2. Fakt ten zapisujemy s s i relację nazywamy silną bisymulacją. Relacja silnej bisymulacji dwóch grafów oznacza największą istniejącą silną bisymulację. Można wykazać, że relacja bisymulacji jest relacją równoważności (spełnia warunki definicji 7.3), jak również relacją kongruentną. Aby wykazać relację silnej bisymulacji pomiędzy dwoma grafami LST należy sprawdzić, czy wszystkie pary stanów S 1 posiadają odpowiedniki w grafie S 2. Przykład grafów, pomiędzy którymi zachodzi relacja silnej bisymulacji przedstawiono na rysunku 7.1. Liną przerywaną zaznaczono wierzchołki grafów, które są członami relacji równoważności. Relację silnej bisymulacji można także wykorzystać do redukcji przestrzeni stanów analizowanego modelu. Ma to na celu zoptymalizowanie działania narzędzi wspomagających, jak również praktyczne zwiększenie wielkości modelu, który może podlegać analizie przy ograniczonych zasobach stosowanych narzędzi. 107

108 7.3.2 Słaba bisymulacja Rys Przykład grafów silnie bisymulacyjnych W przypadku definicji słabej bisymulacji, inaczej zwanej bisymulacji obserwacyjnej musimy prowadzić pojęcie przejścia ukrytego modelu systemu. Oznacza to, że wyzwolenie takiego przejścia nie skutkuje żadną akcją widoczną dla obserwatora zewnętrznego. Przejście ukryte oznaczmy jako akcję τ. W języku LOTOS, akcja ukryta należy do jego specyfikacji i jest oznaczana literą i. Definicja 7.5 Oznaczmy przez τ τ dla a Γ oraz τ τ. Natomiast lewostronne dopełnienia oznaczamy jako τ. Przez τ oznaczamy relacje domknięcia przejściowego dla akcji τ. Posługując się operatorami z definicji 7.5 możemy przejść do definicji słabej bisymulacji. Definicja 7.6 Relacje binarną R zdefiniowaną nad zbiorem stanów LST nazywamy słabą bisymulacją, jeżeli dla każdego (s 1,s 2 ) R oraz dla każdego a Γ są spełnione warunki: α 1. Jeżeli s 1 s1, to istnieje przejście s 2 s 2, takie że s 1 Rs 2. α 2. Jeżeli s 2 s2, to istnieje przejście s 1 s 1, takie że s 1 Rs 2. Dwa stany są słabo bisymulacyjne, jeżeli zachodzi pomiędzy nimi relacja słabej bisymulacji, co oznacza się jako s 1 s 2. Relacja słabej bisymulacji dwóch grafów oznacza największą istniejącą słabą bisymulację. Można wykazać, iż relacja słabej bisymulacji jest relacją równoważności, jednak nie jest relacją konguentną. Oczywistym jest także fakt, że pomiędzy silną bisymulacją oraz słaba bisymulacją zachodzi relacja:. 108

109 Rys Przykład relacji słabej bisymulacji Istotnym czynnikiem wpływającym na możliwość wykorzystania słabej bisymulacji w procesie weryfikacji oprogramowania jest przypadek badania równoważności modeli wykorzystujących operator sumowania []. Jeżeli przeanalizujemy przykład z rysunku 7.3, łatwo zauważmy, iż nie zachodzi pomiędzy nimi relacja słabej bisymulacji Obserwacyjna kongruencja Rys Przykład nie zachowania relacji słabej bisymulacji Własność kongruencji relacji równoważności jest istotna z punktu widzenia procesu wytwarzania oprogramowania. Załóżmy sytuację, w której mamy dwie równoważne specyfikacje pewnej części modelowanego systemu, pomiędzy którymi zachodzi relacja słabej bisymulacji. Chcemy dokonać aktualizacji modelu i zamienić starszą specyfikację na nowszą. Niestety dokonanie takiej zamiany może spowodować błędne działanie systemu, ponieważ relacja słabej bisymulacji nie spełnia warunku kongruencji. Można jednak zdefiniować relację równoważności, która jest kongruentna, ale jednocześnie nie analizuje wszystkich przejść wewnętrznych modelu. 109

110 Definicja 7.7 Relacje binarną R zdefiniowaną nad zbiorem stanów LST nazywamy obserwacyjną kongruencją, jeżeli dla każdego (s 1,s 2 ) R oraz dla każdego a Γ są spełnione warunki: α 1. Jeżeli s 1 s1, to istnieje przejście s 2 s2, takie że s 1 Rs 2. α 2. Jeżeli s 2 s2, to istnieje przejście s 1 s1, takie że s 1 Rs 2. Dwa stany są obserwacyjnie kongruentne, jeżeli zachodzi pomiędzy nimi relacja obserwacyjnej kongruencji i oznacza się jako s 1 s 2. Relacja obserwacyjnej kongruencji, w odróżnieniu od słabej bisymulacji, nie ignoruje całkowicie przejść ukrytych. Uzgodnienie wystąpień przejść τ w porównywanych modelach odbywa się jedynie na poziomie jakościowym. Nie są brane pod uwagę liczby ich wystąpień, a jedynie fakt wystąpienia przynajmniej jednego przejścia τ. Rys Przykład relacji obserwacyjnej kongruencji Pewnym rodzajem relacji bisymulacji jest także równoważność τ*.a. W odróżnieniu od obserwacyjnej kongruencji oraz słabej bisymulacji, wykorzystuje jedynie lewostronne dopełnienie przejść τ. Definicja 7.8 Relacje binarną R zdefiniowaną nad zbiorem stanów LST nazywamy równoważnością τ*.a, jeżeli dla każdego (s 1,s 2 ) R oraz dla każdego a Γ są spełnione warunki: α 1. Jeżeli s 1 s1, to istnieje przejście s 2 s 2, takie że s 1 Rs 2. α 2. Jeżeli s 2 s2, to istnieje przejście s 1 s 1, takie że s 1 Rs 2. Dwa stany są równoważne τ*.a, jeżeli zachodzi pomiędzy nimi relacja równoważności τ*.a i oznacza się jako s 1 τ*.a s 2. Relacja równoważności τ*.a znajduje zastosowanie przede wszystkim w weryfikacji własności bezpieczeństwa modeli. W myśl definicji 7.8 dwie specyfikacje są równoważne τ*.a, jeżeli obserwowalne przejście (nie ukryte) jest ostatnim prowadzącym do nowego stanu systemu. 110

111 7.4 Relacje typu preorder Relacje równoważności ze względu na swoją definicje są relacjami symetrycznymi. W poprzednich paragrafach niniejszego rozdziału powoływaliśmy się także na inny rodzaj relacji, które odzwierciedlały proces symulowania jednego procesu przez drugi. Tego typu relacje nazywamy preorder. Relacje te nie spełniają warunku symetryczności. Pozostałe własności relacji równoważności, czyli zwrotność i przechodniość są zachowane. W wyniku złożenia relacji preorder z jej relacją przeciwną otrzymujemy relację równoważności (ale nie bisymulacji patrz definicja). Relacje preorder otrzymuje się poprzez usunięcie warunku symetrii z definicji poszczególnych relacji równoważności. W ten sposób można przedstawić definicję relacji preorder odpowiadających relacjom bisymulacji Silna symulacja Relację symulacji możemy zdefiniować jak w poniżej. Definicja 7.9 Relację binarną R zdefiniowaną nad zbiorem stanów modelu LTS nazywamy symulacją, wtedy i tylko wtedy, gdy dla każdego s 1 Rs s oraz akcji α zachodzi: 1. Jeżeli s 1 α s1, to istnieje przejście s 2 α s2, takie że s 1 Rs 2. Zapisujemy wtedy s ss s i określamy jako relację silnej symulacji. Relacja silnej symulacji dwóch grafów oznacza największą istniejącą silną symulację. Relacja silnej symulacji jest odpowiednikiem relacji silnej bisymulacji. Na rysunku 7.5 przedstawiono przykładową relację silnej symulacji. Podobnie jak w przypadku bisymulacji, relacja symulacji bierze pod uwagę także przejścia ukryte. Rys Przykład relacji silnej symulacji Relacja słabej symulacji i bezpieczeństwa Odpowiednią definicję można przedstawić także dla słabej symulacji. 111

112 Definicja 7.10 Relacje binarną R zdefiniowaną nad zbiorem stanów LST nazywamy słabą symulacją, jeżeli dla α każdego (s 1,s 2 ) R oraz dla każdego a Γ są spełnione warunki: jeżeli s 1 s1, to istnieje przejście s 2 s 2, takie że s 1 Rs 2. Relację słabej symulacji oznacza się jako s 1 s s2. Relacja słabej symulacji dwóch grafów oznacza największą istniejącą słabą symulację. Relacja słabej symulacji S 1 s S 2 odpowiada sytuacji, w której specyfikacja S 1 spełnia co najmniej wszystkie własności specyfikacji S 2. Podobnie można zdefiniować relację symulacji τ*.a. Na podstawie tej własności możemy zdefiniować relację równoważności będącą złożeniem relacji symulacji τ*.a oraz jej odwrotności. Definicja 7.11 Relacje binarną R zdefiniowaną nad zbiorem stanów LTS nazywamy symulacją τ*.a, jeżeli dla α każdego (s 1,s 2 ) R oraz dla każdego a Γ są spełnione warunki, jeżeli s 1 s1, to istnieje przejście s 2 s 2, takie że s 1 Rs 2. Dwa stany są równoważne τ*.a, jeżeli zachodzi pomiędzy nimi relacja równoważności τ*.a i oznacza się jako s 1 τ*.a s 2. Relacja symulacji τ*.a jest praktycznie wykorzystywana w definicji równoważności bezpieczeństwa. Jeżeli posiadamy dwa modele S 1 oraz S 2, to możemy powiedzieć, że S 1 spełnia warunki bezpieczeństwa S 2 jeżeli zachodzi relacja S 1 τ*.a S 2. Definicja 7.12 Modele S 1 oraz S 2 spełniają te same własności bezpieczeństwa, jeżeli S 1 τ*.a S 2 oraz S 2 τ*.a S 1, co oznaczmy jako S 1 τ*.a S 2. Rozwinięcie powyższej definicji można znaleźć w [81]. Jeżeli założymy, że specyfikacja S 1 rozszerza zakres S 2, to relacja symulacjiτ*.a gwarantuje nam, że model S 1 nie zmienia funkcjonalności S 2. Warunek ten będzie wykorzystywany w proponowanej metodologii f ROPES. 7.5 Metody weryfikacji relacji pomiędzy modelami Najczęściej stosowanym algorytmem weryfikacji typu relacji pomiędzy dwoma modelami jest sprowadzenie problemu do zbioru równań logicznych BES. Pierwszym krokiem algorytmu jest sprowadzenie badanych specyfikacji w języku LOTOS do postaci grafów etykietowanych LTS: M i ={Q i,a,t i,q i0 }, dla i={1,2}. Następnie zgodnie z podanymi definicjami w poprzednim paragrafie dokonujemy transformacji warunków relacji do postaci równań logicznych. Tabela 7.1 zawiera zakodowaną listę warunków poszczególnych relacji. Każdą relację reprezentuje pojedynczy v block równań BES. 112

113 Relacja Silna Kodowanie,,, Gałęzi Obserwacyjna τ*.a, τ,,, τ,,,,,,,,,,, Bezpieczeństwo (Safety),,,, Tabela 7.1. Kodowanie relacji w układzie BES, Dla każdej pary stanów (p,q) Q 1 xq 2 definiujemy zmienną X p,q, która przechowuje informacje, czy dane stany p,q są równoważne. Dla każdej relacji równoważności obliczana jest odpowiednia relacja niesymetryczna typu preorder poprzez usunięcie prawego argumentu koniunkcji. Należy zauważyć, iż w przypadku słabej relacji równoważności dla prawego argumentu równania należy obliczyć domknięcie przechodnie tranzycji τ dla jednego lub obu grafów LTS. Następnie równania z tabeli 7.1 transformowane są do postaci, w której w jednym bloku występują tylko operatory koniunkcji lub alternatywy. Tak przygotowane równania możemy zastosować do wybranego algorytmu rozwiązywania układu BES. Oprogramowanie narzędziowe bisimulator, które automatycznie weryfikuje zadaną relację na bazie grafów LST, pozwala na zastosowanie dwóch algorytmów: breadth first search oraz depth first search. Na temat szczegółowej implementacji algorytmów rozwiązywania układów BES można znaleźć informacje w pracach [20][22][38]. 7.6 Metody weryfikacji modelowej Proces wytwarzania oprogramowania bazujący na weryfikacji własność inkrementalnych modeli tworzonego systemu pozwala na formalne dowodzenia jego poprawności poprzez porównanie kolejnych wersji specyfikacji. Jednakże dalej pozostaje problemem sprawdzenie, czy pierwsza wersja specyfikacji, która rozpoczyna iterację jest poprawna w kontekście stawianych wymagań. Szereg własności systemu tj. bezpieczeństwo, żywotność, zakleszczenia, zapętlenia, obsługa obszarów krytycznych są 113

114 wymaganiami poza funkcjonalnymi, które także muszą podlegać weryfikacji na każdym etapie procesu projektowego. Jedną z metod takiej weryfikacji jest technika weryfikacji modelowej. W proponowanym podejściu, model projektowanego systemu (np. w języku LOTOS) jest translatowany do postaci grafu etykietowanego LTS, a następnie bada się kolejne własności modelu, zapisanych w postaci formuł logiki temporalnej za pomocą odpowiedniego algorytmu weryfikacji modelowej. Ważnym jest, aby formalizm wykorzystywany do zapisania pożądanych własności systemu był wystarczająco ekspresywny do zamodelowania często bardzo skomplikowanych własności systemu. Wśród szerokiego wachlarza dostępnych w literaturze typów logik temporalnych, modalny μ rachunek wydaje się najbardziej praktyczny i wystarczająco ekspresywny dla zastosowań praktycznych. Dodatkowo, zastosowany formalizm musi być na tyle prosty, aby jego wykorzystanie nie nastręczało zbyt wielu trudności dla inżynierów oprogramowania. Powyższe wymaganie spełnia logika alternation free rachunek μ [37], będąca podzbiorem pełnej wersji rachunku μ. Zastosowana logika posiada rozszerzenia formuł akcji bazujący na ACTL oraz rozszerzenie wyrażeń regularnych podobnych dla zastosowanych w PDL. Istotną zaletą wyboru AF μ rachunek jest możliwość praktycznej realizacji za pomocą dostępnych narzędzi pakietu CADP. Dzięki wykorzystaniu modułu evaluator, możemy realizować zadania weryfikacji własności modeli w zakresie zakładanym przez proponowaną metodologie f ROPES. Metoda weryfikacji własności modelu sprowadza się, podobnie jak to miało miejsce podczas weryfikacji relacji, do stworzenia odpowiedniego układu równań BES, a następnie jego rozwiązaniu. W przypadku logiki AF rachunek μ rozwiązanie równań BES za pomocą algorytmów evaluator a ma złożoność liniową, co znacząco przyśpiesza proces weryfikacji oraz umożliwia badanie znacznie większej przestrzeni stanów Semantyka wyrażeń AF rachunek μ Ze względu na kontekst weryfikowanych modeli, które reprezentowane w postaci grafów LTS, wyrażenia logiki AF rachunek μ zostaną przedstawione jako własności grafów etykietowanych. Przyjmujemy oznaczenia dla grafu LTS L=(S,A,T,s 0 ), gdzie S jest skończonym zbiorem stanów, A jest skończonym zbiorem akcji, T S x A x S określa relację przejść oraz s 0 stanowi stan początkowy. Wyrażenia AF rachunek μ posiadają trzy rodzaje formuł, zaprezentowanych w tabeli 7.2. Formuła Wyrażenie BNF Akcji α := a α α 1 α 2 Wyrażenia regularne Stanu β := α β 1.β 2 β 1 β 2 β * ϕ := true false ϕ 1 ϕ 2 β ϕ [β]ϕ Y μy. ϕ νy. ϕ Tabela 7.2. Wyrażenia AF rachunek μ Formuła akcji α jest zbudowana z alfabetu akcji a A oraz operatorów logicznych. Wyrażenia regularne β są budowane na podstawie formuł akcji α oraz standardowych operatów regularnych: konkatenacji, wyboru. oraz przechodniego, zwrotnego domknięcia *. Operator pustej sekwencji ε oraz przechodniego domknięcia + są zdefiniowane jako: ε=f * oraz β + =β.β *. Wyrażenie stanu ϕ składa się z definicji zmiennych Y z wykorzystaniem operatorów logicznych, operatora możliwości β ϕ oraz wymagalności [β]ϕ oraz operatów minimalnego oraz maksymalnego punktu stałego μy. ϕ, νy. ϕ. 114

115 Wyrażenie ϕ bez wystąpień zmiennych Y nazywamy wyrażeniem zamkniętym. W tabeli 7.3 przedstawiono zestawienie semantyki poszczególnych wyrażeń. Formuła Akcji Semantyka \ Wyrażenia regularne,.. Stanu., s φ., s φ. Φ S S. S Φ S gdzie: Φ :2 S 2 S,Φ S φ ρ S /Y Tabela 7.3. Semantyka AF rachunek μ Wyrażenie akcji należy interpretować jako zbiór akcji LTS spełniający warunek α. Podobnie wyrażenie określa relację binarną sekwencji przejść spełniający warunek β. Pojedyncza formuła α charakteryzuje jedną sekwencje przejścia, gdzie a spełnia α. Formuła. stanowi konkatenację dwóch sekwencji spełniających warunki β 1 oraz β 2. Natomiast wyraża sekwencję dwóch przejść, spełniających β 1 lub β 2. Wyrażenie odpowiada przechodniemu i zwrotnemu dopełnieniu konkatenacji, czyli konkatencji zero lub większej liczbie sekwencji spełniających β. Operatory modalne oraz charakteryzują stany, których niektóre (operator możliwości) lub wszystkie (operator konieczności) wychodzące sekwencje przejść spełniające β prowadzą do stanu spełniającego warunek ϕ. Szczegółowe informacje na temat operatorów AF rachunku μ można znaleźć w pracach [37][38]. 115

116 7.6.2 Przykłady własności Logika modalna AF rachunek μ pozwala na zakodowanie szerokiego zakresu własności systemu. Pakiet CADP wprowadził szereg własności predefiniowanych tj. deadlock czy live lock, które są dostępne bez konieczności wprowadzania tychże własności explicite jako część specyfikacji. W tabeli 7.4 podano przykłady własności, które można wykorzystać w procesie projektowym. Klasa własności Formuła Własność Bezpieczeństwo [true *. Error] false Akcja Error nie powinna wystąpić w jakiejkolwiek sekwencji [( Send) *. Recv ] false [true *. Open!1. ( Close!1) *. Open!2] false Przejście Recv nie może być osiągnięte przed Send Wzajemne wykluczenie sekcji krytycznej Żywotność [true * ] true true Brak zakleszczeń (czytamy: [true * ] dla każdej sekwencji, true istnieje przynajmniej jedna ścieżka do każdego stanu [true *.Request] μy. true true [ Grant] Y true *. Send. (true *. Error) *. Recv true Konieczność osiągnięcia akcji Grant po akcji Request Potencjalna możliwość osiągnięcia Recv po Send, nawet po kilku Error Uczciwość (fairness) [true * ] μy.[τ]y Brak zapętleń (brak cykli τ) [true *. Send. ( Recv) * ] ( Recv) *. Recv true Uczciwe osiągnięcie Recv po Send (opuszczenie pętli) 7.7 Podsumowanie Tabela 7.4. Przykłady zakodowanych własności modelowanego systemu W rozdziale przedstawiono najważniejsze definicje oraz twierdzenia, które będą wykorzystywane podczas konstrukcji metodologii f ROPES. Bazując na koncepcji procesu wytwarzania oprogramowania zostały zaproponowane warunki konieczne i wystarczające do zapewnienia poprawności tworzonego systemu. Praktyczne badanie relacji bisymulacji oraz symulacji pomiędzy modelami możliwe jest dzięki zastosowaniu oprogramowania wspomagającego tj. CADP. Wykorzystując algorytmy rozwiązywania układów równań BES, możemy przeprowadzić analizę występujących relacji, jak również wskazać kontrprzykład w przypadku weryfikacji negatywnej. Korzystając z pakietu CADP możemy także użyć techniki weryfikacji modelowej w celu zbadania własności poza funkcjonalnych systemu. Należy jednak zaznaczyć, iż rozwiązywanie równań BES nie jest zadaniem łatwym, dlatego też przed każdym procesem weryfikacji, odpowiedni graf LTS należy zredukować, korzystając np. z algorytmu bisymulacji. Ograniczenie na wielkość analizowanego modelu wynika ze złożoności algorytmu rozwiązywania układów BES oraz dostępnych zasobów przydzielonych do wykonania danej weryfikacji. 116

117 8. Proces specyfikacji SCR w metodyce f ROPES 8.1 Wprowadzenie Proces wytwarzania oprogramowania czasu rzeczywistego zgodny z metodologią ROPES [16] został przedstawiony w rozdziale 3. Istotną cechą wyróżniającą ROPES spośród innych popularnych metod jest trójpoziomowe podejście iteracyjne. Zgodnie z podanym poprzednio opisem, ROPES definiuje trzy rodzaje zagnieżdżonych w sobie cykli: makro cykle, mikro cykle oraz nano cykle. Ilość oraz czas trwania każdego cyklu zależny jest od specyfiki danego projektu. Należy jednak pokreślić, iż poza oczywistymi zaletami podejścia iteracyjnego, metodologia ROPES posiada pewne wady. Poza wymienionym wcześniej wyższym poziomem trudności zarządzania projektem oraz tendencją do multiplikowania iteracji, istnieje jeszcze jedna trudność wynikająca z charakteru iteracyjnego metodologii ROPES. Każda iteracja, niezależenie od cyklu, powoduje wytworzenie nowego produktu w postaci specyfikacji lub prototypu. W przypadku prototypu konieczne jest przeprowadzenie testów, czy oprogramowanie spełnia zidentyfikowane wymagania. Oznacza to, iż po każdej iteracji należy przeprowadzić pełne testy włącznie z testami regresyjnymi funkcjonalności udostępnionej w poprzednich iteracjach. Niestety w przypadku zaawansowanego systemu i częstych iteracjach, testy takie zajęłyby większość czasu przeznaczonego na projekt. Dlatego też, bardzo często nie prowadzi się testów całościowych po każdej z iteracji, a jedynie testy funkcjonalności udostępnionych w danej iteracji (bez testów regresji). Prowadzi to w oczywisty sposób do zwiększonego ryzyka pojawienie się błędów integracji w nowych wersjach prototypów (pojawią się błędy w już przetestowanej funkcjonalności). Poprawa tychże błędów po zakończeniu implementacji jest oczywiście bardzo kosztowna i znacząco wpływa na harmonogram projektu. Oczywistym jest fakt, iż samo przeprowadzenie całościowych testów, nawet po każdej iteracji, nie gwarantuje, że stworzone oprogramowanie będzie wolne od błędów. W celu wyeliminowania powyżej wymienionych wad procesu ROPES zaproponowano rozszerzenie tejże metodologii w zakresie formalnej walidacji oraz weryfikacji specyfikacji behawioralnej systemu. Rozszerzona metodologia f ROPES (od formal ROPES) pozwala na formalną weryfikację relacji pomiędzy specyfikacjami dynamiki systemu tworzonymi w poszczególnych iteracjach procesu oraz na walidację powstałego modelu zgodnie z podanymi wymaganiami. 8.2 Zakres metodologii f ROPES Metodologia f ROPES bazuje na wykorzystaniu formalnych modeli behawioralnych budowanego systemu. Model systemu, podobnie jak to miało miejsce w metodologii ROPES, jest w całości budowany z wykorzystaniem języka UML lub profilu RT UML [17]. Specyfikacja behawioralna realizowana jest za pomocą diagramów stanów oraz diagramów aktywności. Zakładamy, iż na tym etapie rozwoju metodologii f ROPES, będziemy wykorzystywać metody formalne jedynie w zakresie specyfikacji dynamiki systemu, wyrażonej za pomocą diagramów stanów. Jednak nic nie stoi na przeszkodzie, aby ten sam algorytm translacji zastosować do diagramów aktywności. W takim przypadku proces w języku LOTOS odpowiadałby wykonywanej aktywności. Model formalny jest realizowany z wykorzystaniem języka LOTOS. Zakładamy się, że przejście od modelu UML do specyfikacji w języku LOTOS będzie wykonywane automatycznie, z wykorzystaniem przedstawionego w rozdziale 6 algorytmu translacji. W celu dokładnego prześledzenia kolejnych fazy metodologii f ROPES musimy odwołać się do procesu bazowego ROPES [16]. Jego głównym założeniem jest wykorzystanie podejścia iteracyjnego w procesie analizy, projektowania oraz implementacji systemu. Dodatkowo proces zakłada, iż każdy cykl 117

118 także wykorzystuje podejście iteracyjne. W ten sposób powstał trójpoziomowy proces iteracyjny, składający się z następujących cykli: Marko cykl zawierający główne etapy projektu lub budowy koncepcji. Najczęściej wyróżniamy 3 4 makro cykle, jednakże ilość cykli w szczególności zależy od samego projektu i w niektórych przypadkach może być tylko jeden cykl. Mikro cykl o długości trwania wystarczającej do stworzenia nowej wersji prototypu lub systemu, realizującego zakładaną na daną iterację funkcjonalność. Nano cykl pozwalający na implementacje, uruchomienie oraz przetestowanie bardzo małej części systemu. Cykl ten powinien trwać od 1 2 godzin. Na rysunku 8.1 przedstawiono zależności pomiędzy poszczególnymi cyklami. Należy zwrócić szczególną uwagę na relację pomiędzy poszczególnymi cyklami oraz iteracjami. Kolejne iteracje mikrocykli zakładają wykorzystanie produktów poprzedniej iteracji. Podobnie sytuacja przedstawia się w zakresie nanocykli. Produkty końcowe kolejnych cykli stanowią dane wejściowe swojego następnika. Rys Cykle procesu ROPES Struktura pojedynczej iteracji stanowi odzwierciedlenie procesu sekwencyjnego wytwarzania oprogramowania, jednakże w pomniejszonej skali. Jej zmiana wynika ze znacznie mniejszego zakresu niezbędnego do realizacji danej wersji prototypu systemu. Nawet w przypadku bardzo krótkich nanocykli możemy wyróżnić etapu analizy, projektu technicznego, implementacji oraz testów. Oczywiście w jego zakresie będą dodanie do projektu nowe klasy lub procesy, jednakże nawet tak atomowe operacje muszą zawierać elementy analizy, modelowania oraz testów. Z powyższej obserwacji wynika kolejne ważne założenie. Każda faza pojedynczej iteracji dostarcza produktu wyjściowego dla fazy po niej następującej. Strukturę tego procesu obrazuje rysunek 8.2. Podsumowując, w procesie ROPES mamy ciągły wielopoziomowy proces rozbudowy systemu, w którym poszczególne elementy są integrowane na ostatniej fazie testów. Projektant musi samodzielnie dbać, aby zmiany wprowadzone w kolejnych iteracjach, takie jak dodanie stanów podrzędnych do definicji diagramu stanów, dodanie regionów ortogonalnych, synchronizacja z systemem zewnętrznym, nie spowodowała zmiany funkcjonalności systemu opracowanej i przetestowanej w poprzednich iteracjach lub cyklach. 118

119 Rys Relacja pomiędzy fazami pojedynczej iteracji Załóżmy jednak, iż proces wytwarzania został przeprowadzony w sposób koherentny. Bazując na semantyce UML projektant nie ma możliwości, poza przeprowadzeniem testów, weryfikacji formalnej własności stworzonej specyfikacji. Zbadanie takich własności maszyny stanowej jak bezpieczeństwo, żywotność, zakleszczenie (deadlock), zapętlenie (livelock) oraz innych specyficznych dla danego systemu, wymagałoby stworzenia osobnego modelu w wybranej metodyce formalnej. Pojawia się jednak problem rozbieżności niezależnych specyfikacji oraz implementacji. Prezentowana metodologia f ROPES ma ambicję rozwiązać przynajmniej cześć z opisanych powyżej problemów. Poprzez wprowadzenie metody formalnej bazującej na algebrze procesów CCS, przy jednoczesnym małym koszcie dodatkowym jej wprowadzenia, f ROPES ma na celu: zapewnienie spójności poszczególnych cykli, iteracji oraz faz procesu wytwarzania oprogramowania zgodnych z metodologią ROPES, umożliwić formalną weryfikację własności specyfikowanego systemu, zapewnić spójność modelu analitycznego oraz projektowego, udostępnić mechanizmy generowania testów weryfikacyjnych dla powstałego oprogramowania, zmniejszenie kosztów oraz czasu niezbędnego do realizacji projektu poprzez minimalizację błędów popełnianych podczas faz analizy i projektu technicznego, a przez to zmniejszenie niezbędnych zasobów do realizacji fazy testów. 119

120 8.3 Realizacja procesu f ROPES Znając zakres oraz cele proponowanej metodologii możemy przystąpić do prezentacji technik oraz zastosowanych algorytmów w procesie f ROPES. Kolejne kroki omawianego procesu umiejscowione są w fazach pojedynczej iteracji. Faza początkowa analiza została podzielona na dwa obszary: analizę funkcjonalną oraz poza funkcjonalną. Podział ten ma na celu oddzielenie zadań związanych z inżynierią wymagań funkcjonalnych, reprezentowanych przez przypadki użycia od analizy własności systemu poza funkcjonalnych. Ma to istotne znaczenie w kolejnych cyklach procesu, kiedy analiza funkcjonalna zostaje ciągle uzupełniana poprzez nowe przypadku użycia, natomiast wymagania stanowią inwarianty dla opisywanych przypadków. Oczywiście zakłada się, że w kolejnych iteracjach mogą pojawić się nowe warunku lub modyfikacji ulegają już istniejące. W takich sytuacjach należy zadbać o to, aby wszystkie dotychczasowe modele były weryfikowalne także z nowym zestawem warunków. Przed przystąpieniem do weryfikowania relacji pomiędzy modelami poszczególnych iteracji, musimy uprzednio poddać szczegółowej analizie zmiany zachodzące w modelach podczas ich iteracyjnego wytwarzania. Istotne jest, iż procesy te zmieniają swój charakter w zależności od zaawansowania procesu wytwarzania oprogramowania. Dodatkowo należy uwzględnić preferowane podejście zespołu projektowego do uszczegóławiania specyfikacji. Najczęściej spotykanym podejściem, preferowanym przez metodologie ROPES jest top down, jednakże w niektórych przypadkach wskazane jest podeście przeciwne bottom up. Nie tracąc ogólności rozważań, dla obu podejść możemy przyjąć, że proces zmian dzielimy na trzy fazy: Początkową specyfikacja dotyczy jedynie bardzo podstawowych funkcjonalności systemu. Bardzo często definiowane diagramy oraz obiekty dotyczą jedynie wybranych i niezależnych fragmentów z całego obrazu systemu. Uszczegóławiania specyfikacja początkowa poszerza swój zakres wertykalnie oraz horyzontalnie. Prowadzi to często do uszczegóławiania definicji stanów poprzez budowę struktur hierarchicznych. Konsolidacji szczegółowe specyfikacje modułów systemu, dotychczas rozwijane niezależnie, są w fazie konsolidacji spajane w jedną, spójną specyfikację systemu. Uzupełniane są mechanizmy synchronizacji oraz współbieżności poszczególnych modułów systemu. Do każdej z powyższych faz można przyporządkować zmiany jakie zachodzą podczas definiowania specyfikacji. Spośród istotnych dla niniejszej pracy można wymienić: Definiowanie pojawiają się nowe obiekty oraz diagramy. Sytuacja taka występuje podczas pierwszych iteracji fazy analizy oraz projektu technicznego. W przypadku projektu technicznego możemy oprzeć się na wynikach analizy, jednakże nadal nie posiadamy punktu odniesienia z poprzednich iteracji. Rozszerzenia do istniejących specyfikacji dodajemy nowe obiekty, akcje diagramy. Jako rozszerzanie rozumiemy także uściślanie definicji poszczególnych stanów np. poprzez budowanie hierarchii. Taka kategoryzacja jest podyktowana koniecznością rozbudowy listy obsługiwanych akcji modelu stanowego, a co za tym idzie rozbudową grafu tranzycji LTS. Redukcja podczas fazy konsolidacji może nastąpić konieczność usunięcia stanów lub procesów nadmiarowych, usunięcia niedeterministycznych wyborów lub realizacji danej funkcjonalności przez inny moduł. W takich sytuacjach dochodzi do redukcji diagramu stanów, a co za tym idzie modelu formalnego. 120

121 Powyższy opis procesów zachodzących podczas wytwarzania oprogramowania jest istotny z punktu widzenia budowy relacji pomiędzy specyfikacjami poszczególnych iteracji oraz relacji pomiędzy specyfikacją oraz implementacją. W rozdziale 7 przedstawione zostały definicje oraz twierdzenia dotyczące możliwych relacji równoważności oraz preorder dla grafów LTS. Na podstawie ich własności można wskazać na dwie relacje, które znajdują zastosowanie w metodologii f ROPES. W przypadku poszukiwania równoważności pomiędzy dwiema specyfikacjami B i oraz B i+1 można nie brać pod uwagę zdarzeń ukrytych, które nie mają wpływu na warunki spełniane przez system w danej konfiguracji. W takiej sytuacji wystarczającą relacją równoważności pomiędzy specyfikacjami byłby bisymulacja słaba. Jednakże ze względu na charakter przejść ukrytych w budowanych modelach (przejścia graniczne oraz regiony ortogonalne) nie możemy całkowicie ich zaniedbać. Dlatego poszukiwaną relacją pomiędzy specyfikacjami, jak również implementacją będzie relacja obserwacyjnej kongruencji. Nie ignoruje ona przejść ukrytych, jednakże w odróżnieniu od silnej bisymulacji, nie bierze pod uwagę ilości tychże przejść. W przypadku procesu rozszerzenia lub redukcji specyfikacji w modelu formalnym zmianie ulega struktura przejść oraz lista akcji. Z tego powodu zastosowanie relacji równoważności nie znajduje uzasadnienia. Jednakże możemy nadal badać relacje pomiędzy modelami z wykorzystaniem symulacji, czyli relacji typu preorder. Podobnie jak w przypadku relacji równoważności, nie będziemy badali silnej relacji symulacji, a jedynie słabą symulację, zwaną relacją równoważności bezpieczeństwa. Jeżeli między dwoma modelami B i oraz B i+1 spełniona jest relacja słabej symulacji, to wtedy modele te są równoważne z punktu widzenia bezpieczeństwa (spełniają te same warunki bezpieczeństwa). W przypadku modeli tworzonych na podstawie algorytmu translacji UML2LOTOS, równoważność bezpieczeństwa oznacza, że specyfikacja B i+1 posiada dodatkowe stany lub akcje w stosunku do B i, jednakże nadal spełnia własności B i. Zewnętrzny obserwator, który testuje B i oraz B i+1 i nie znający struktury wewnętrznej systemu, nie może rozróżnić, który model aktualnie testuje, jeżeli posługuje się zakresem akcji B i. Jest to spójność, której oczekujemy od kolejnych iteracji specyfikacji oraz implementacji. Kolejnym elementem metodologii f ROPES jest weryfikacja własności modelu formalnego. W tym zakresie wykorzystywana jest technika weryfikacji modelowej. Własności systemu zapisywane są podczas fazy analizy w postaci wyrażeń logiki temporalnej AF rachunek μ. Następnie wykorzystując algorytm podany przez Radu Mateecsu oraz Mihaela Sighireanu [37] można dokonać automatycznego sprawdzenia, czy model spełnia zadane warunki. Powyższą weryfikację można przeprowadzić przy użyciu narzędzia EVALUATOR, będącego częścią pakietu CADP. Charakter własności oraz odpowiednie przykłady przedstawiono w rozdziale 7. W metodologii f ROPES zakładamy, iż lista oraz definicje własności mogą ulegać zmianie w czasie projektu. Jednakże szczególną uwagę należy zwrócić, aby własności te odpowiadały realizowanym przez system wymaganiom. W przypadku systemu typu livecritical zapisane warunki musza odzwierciedlać możliwość przejścia dla krytycznych ścieżek systemu. Podsumowując powyższe rozważania możemy przedstawić kroki procesu f ROPES dla pojedynczej iteracji. Algorytm został przedstawiony także w formie graficznej na rysunku 8.5. Podczas jego definicji wykorzystano dwie procedury, których specyfikację przedstawiono na rysunkach 8.3 i 8.4. Algorytm 8.1 Założenia: wytwarzamy system reaktywny S, cykl procesu dowolny, iteracja cyklu i {1,, n} 1. W obszarze funkcjonalnym systemu identyfikujemy wymagań funkcjonalne. Tworzymy dla nich odpowiednie przypadki użycia. Dla opisania dynamiki przypadków tworzymy specyfikację B i (S) w postaci diagramów stanów oraz aktywności. 121

122 2. W obszarze poza funkcjonalnym definiujemy wymagania bezpieczeństwa, żywotności oraz inne istotne z punktu widzenia działania systemu. Wymagania definiujemy w postaci logiki temporalnej AF rachuneku μ na bazie specyfikacji B i (S). Wynikiem tego kroku jest zbiór wymagań P(S) odpowiadających poszczególnym diagramom stanów lub aktywności. 3. Na podstawie modelu B i (S) generujemy specyfikację formalną F i (S) w języku LOTOS. Proces translacji został opisany w rozdziale Weryfikujemy, czy powstała specyfikacja spełnia odpowiednie warunki P(S). Jeżeli tak, przechodzimy do kroku 5. W przypadku negatywnym ponownie analizujemy specyfikację B i (S) w celu usunięcia błędów. Należy także przeanalizować, czy podana własność jest poprawna. Jeżeli nie jest poprawna, należy ją zmodyfikować, a następnie zweryfikować B i (S) dla każdej iteracji j<i. 5. Dla specyfikacji F i (S) oraz i>1 sprawdzamy relację R: F i 1 (S)R F i (S). a. Jeżeli R jest relacją obserwacyjnej kongruencji, to specyfikacja F i (S) spełnia własności F i 1 (S). Z punktu widzenia procesu specyfikacje są spójne. Przechodzimy do kroku 7. b. Jeżeli R jest relacją weak preorder >=, to specyfikacja F i (S) spełnia własności bezpieczeństwa F i 1 (S). Z punktu widzenia procesu specyfikacja F i (S) została rozszerzona, jednakże nadal symuluje F i 1 (S), co jest formalnym warunkiem spójności specyfikacji. Przechodzimy do kroku 7. c. Jeżeli R jest relacją weak preorder <=, to specyfikacja F i (S) spełnia własności bezpieczeństwa F i 1 (S). Z punktu widzenia procesu specyfikacja F i (S) została zawężona, jednakże nadal symuluje F i 1 (S), co jest formalnym warunkiem spójności specyfikacji. Przechodzimy do kroku Specyfikacja F i (S) nie spełnia warunków spójności z F i 1 (S). Należy powrócić do kroku Na podstawie modelu statycznego systemu S, definiujemy dynamikę odpowiednich klas (jak dla przypadków użycia) za pomocą diagramów stanu lub aktywności. Otrzymujemy implementację systemu CB i (S). 8. Na podstawie modelu CB i (S) generujemy specyfikację formalną CF i (S) w języku LOTOS. Proces translacji został opisany w rozdziale Weryfikujemy, czy powstała implementacja spełnia odpowiednie warunki P(S). Jeżeli tak, przechodzimy do kroku 10. W przypadku negatywnym ponownie analizujemy implementację CB i (S) w celu usunięcia błędów. Należy także przeanalizować, czy podana własność jest poprawna. Jeżeli nie jest poprawna, należy ją zmodyfikować, a następnie zweryfikować B i (S) oraz CB i (S) dla każdej iteracji j<i. 10. Dla specyfikacji CF i (S) oraz i>1 sprawdzamy relację R: CF i 1 (S)R CF i (S). Dokonujemy analizy jak w kroku 5. W przypadku pozytywnej weryfikacji przechodzimy do kroku 11, natomiast w przypadku odpowiedzi negatywnej przechodzimy do kroku Dla specyfikacji CF i (S) sprawdzamy relację R: CF i (S)R F i (S). Dokonujemy analizy jak w kroku 5. W przypadku pozytywnej weryfikacji przechodzimy do kroku 12, natomiast w przypadku odpowiedzi negatywnej przechodzimy do kroku Przechodzimy do fazy implementacji pozostałej części systemu oraz testów. Testy powinny obejmować weryfikację własności P(S) na podstawie zaimplementowanego modelu systemu. 122

123 W kroku 12 został wprowadzony nowy rodzaj modelu, który zostaje wygenerowany na podstawie zaimplementowanego kodu źródłowego. Należy nadmienić, iż taki proces generacji wykracza poza zakres niniejszej pracy, ale będzie przedmiotem dalszych badań w zakresie metodologii f ROPES. Rys Definicja procedury "zgodność iteracyjna" Rys Definicja procedury "zgodność fazowa" 123

124 Rys Kroki iteracji f ROPES 124

125 8.4 Przykładowy projekt realizowany zgodnie z f ROPES W celu zademonstrowania praktycznego zastosowania f ROPES przedstawiony zostanie proces specyfikacji oraz implementacji systemu sterowania elektronicznym wtryskiem paliwa w silniku spalinowym. Na wstępie opisane zostaną zasady funkcjonowania systemu wtrysku paliwa. Następnie przedstawione zostaną kolejne kroki procesu projektowego zmierzającego do stworzenia specyfikacji oprogramowania elektronicznego sterownika systemu wtryskowego Zasady funkcjonowania układu wtryskego w silnikach spalinowych Zasada działania silnika spalinowego opiera się na wymianie energii cieplnej powstającej w wyniku spalania na energię mechaniczną. Proces spalania odbywa się w obszarze cylindrów silnika przy odpowiedniej konfiguracji poszczególnych tłoków. Materiałem podlegającym spalaniu jest mieszanka paliwa oraz powietrza. Średni stosunek ilości paliwa i powietrza wynosi 1:15 [69] i zmienia się w zależności od chwilowych parametrów pracy silnika. Głównym zadaniem układu wtryskowego jest ustalenie proporcji mieszanki w danych warunkach pracy. Najnowsze modele silników benzynowych oraz diesla są wyposażone w układy wtrysku bezpośredniego, w którym wtrysk następuje bezpośrednio w obszar cylindra. Obecnie wykorzystuje się dwie konfiguracje układów wtryskowych: SPI układ pojedynczego wtrysku dla wszystkich cylindrów oraz MPI układ wtrysku wielopunktowego, w którym każdy cylinder posiada indywidualny układ wtryskowy. Niezależnie od konfiguracji, pracą układu wtryskowego zarządza elektroniczny sterownik. Prace sterownika można konfigurować oraz monitorować przez zewnętrzne urządzenia serwisowe. Ustalenie proporcji mieszanki jest uzależnione od następujących parametrów: prędkości obrotowej silnika, poziomu otwarcia przepustnicy, ciśnienia powietrza, temperatury silnika, zawartości tlenu w spalinach czujnik Lambda. Parametry te są mierzone przez odpowiedni zestaw czujników. Najtrudniejszym pomiarem jest odczyt ciśnienia powietrza trafiającego do komory spalania. W tym celu można posłużyć się pomiarem podciśnienia w kolektorze ssącym i na podstawie tabeli danych można wyznaczyć parametry pracy układu wtrysku. Najdokładniejszym sposobem pomiaru ciśnienia powietrza jest stosowanie przepływomierza. Zasada działania przepływomierza polega na pomiarze zmiany temperatury sondy pomiarowej ogrzanej do stałej temperatury np. 100 C, a następnie chłodzonej przez przepływające powietrze. Zmiana natężenia prądu, który utrzymuje stałą temperaturę sondy jest proporcjonalna do natężenia przepływu powietrza. Najczęściej stosowane rozwiązania wykorzystują układ stałego ciśnienia w układzie paliwowym. Wartość ciśnienia dobiera się do poszczególnych modeli silnika i najczęściej zawiera się w przedziale kpa dla silników benzynowych. Sterowanie wtryskiwaczem polega na ustaleniu dwóch parametrów: momentu otwarcia zaworu wtryskiwacza, długości okresu otwarcia zaworu. 125

126 Rys Schemat budowy układu wtryskowego MPI. Źródło [40] 2. Na rysunku 8.6 przedstawiono schemat budowy układu wtryskowego MPI. W typowym układzie MPI możemy wyróżnić następujące elementy: U 1 przewód odprowadzający nadmiar paliwa do zbiornika. F 1 filtr paliwa ssący. M12 zbiornik paliwa. F 2 filtr paliwa na tłoczeniu. U 2 regulacja zaworu wtrysku. U 4 regulacja zaworu wtrysku pomocniczego. Y3/1 wtryskiwacz paliwa. Y14 wtryskiwacz pomocniczy (wykorzystywany przy rozruchu silnika). R pomiar ciśnienia powietrza/paliwa. S104 przepustnica. Y3/X kolektor współśrodkowy. Rys Budowa wtryskiwacza / Źródło [69] 2 Wykorzystano za zgodą Zarządu firmy MECHATRONIKA. Urządzenie wtryskowe (wtryskiwacz) składa się z układu doprowadzającego paliwo, zaworu zamykającego, sprężyny zaworu zamykającego, tłoku zaworu oraz cewki elektromagnesu sterującego tłokiem zaworu. Otwarcie zaworu powoduje wyrzucenie pod ciśnieniem paliwa doprowadzonego przez układ paliwowy. Ciśnienie paliwa zależy od zastosowanego układu pompy paliwowej i w większości przypadków jest utrzymywane na stały poziomie. Sterowanie pracą wtryskiwacza polega na generowaniu odpowiednich impulsów elektrycznych na uzwojenie elektromagnesu. Moment pojawienia się impulsu oraz długość jego trwania określają parametry pracy układu wtryskowego. 126

127 Chcąc ustalić parametry pracy układu wtryskowego wykorzystuje się tabele słownikowe, które określają długość czasu otwarcia zaworu w zależności od parametrów pracy silnika. Przykładowa tabela parametrów pracy układu została przedstawiona na rysunku 8.8. Rys Przykładowa tabela słownikowa układu wtryskowego Dodatkowo układ wtryskiwacza posiada układ sprzężenia zwrotnego bazującego na sondzie Lambda. Sonda ta bada zawartość tlenu w spalinach. Jeżeli poziom tlenu jest za wysoki, oznacza to sytuację, w której mieszanka jest za uboga w paliwo. Natomiast, jeżeli poziom tlenu jest za niski, to poziom paliwa w mieszance jest za wysoki. Należy zaznaczyć, iż powyższa korelacja działa jedynie w stanach ustalonej pracy silnika (stała prędkość). W innych sytuacjach np.: przyśpieszania, zimnego silnika, działanie sondy Lambda powodowałyby opóźnienia w działaniu silnika Proces projektowy oprogramowania sterownika układu wtryskowego MDI Zgodnie z metodologią f ROPES, proces projektowy zakłada iteracyjne budowanie kolejnych modeli systemu. W niniejszej pracy zostaną przedstawione przykładowe trzy iteracje. Ze względu na wielkość systemu część specyfikacji oraz diagramów LTS zostały zamieszczone w dodatku A Iteracja Etap analizy Iterację rozpoczynamy od analizy funkcjonalnej systemu. W pierwszym kroku identyfikujemy aktorów, którzy będą uczestniczyć w przypadkach użycia. W tym celu możemy posłużyć się opisem działania układu wtryskowego zamieszczonego powyżej. W pierwszej kolejności identyfikujemy obserwatorów zewnętrznych: kierowcę oraz serwisanta. W dalszej kolejności wprowadzamy jako aktorów 127

128 wszystkie czujniki oraz układy mechaniczne silnika mające wpływ na proces. Dla przejrzystości opisu wprowadzamy także jako aktora silnik oraz projektowany sterownik. Na diagramie 8.9 przedstawiono zbiór zidentyfikowanych aktorów. W celu łatwiejszego zarządzania elementami diagramu wprowadzono osobny pakiet zawierający czujniki układu. uc Actors uc Zestaw czujników Czuj nik lambda Czujnik ciśnienia paliwa Czuj nik natężenia przepływu powietrza Czuj nik temperatury silnika Sterow nik układu wtryskowego Timer Silnik Serwisant Kierow ca Rys Zbiór aktorów Następnie przechodzimy do identyfikacji podstawowych procesów zachodzących podczas pracy układu wtryskowego. Podstawowymi procesami inicjowanymi przez kierowcę są: uruchamianie silnika, wyłączenia silnika, zwiększanie obrotów (przyśpieszanie), zmniejszanie obrotów (hamowanie), bieg jałowy oraz utrzymywanie stałych obrotów. Są to szczególne przypadki sterowania obrotami silnika. Sam silnik także bierze udział w sterowaniu procesem wtrysku paliwa. Kąt obrotu wału korbowego, poprzez układ rozrządu określa moment uruchomienia wtrysku paliwa oraz otwarcia zaworu ssącego oraz spalinowego. W przypadku wtrysku bezpośredniego, sterowanie zaworem ssącym zastąpione zostaje otwarciem zaworu wtryskiwacza. Na rysunku 8.10 przedstawiono poszczególne przypadki użycia wraz z relacjami pomiędzy nimi. Przypadek sterowanie wtryskiem zawiera wszystkie czynności konieczne do obliczenia parametrów pracy wtryskiwacza. Zgodnie z wytycznymi metodologii na początku etapu analizy będziemy analizować model uproszczony, zawierający jedynie podstawowe funkcjonalności. W omawianym modelu skupimy się na specyfikacji pracy sterownika jednego cylindra, a następnie w ostatniej iteracji uzupełnimy model dla N cylindrów. Posiadając podstawową mapę przypadków użycia możemy przejść do opisu ich dynamiki. Ze względu na zakres pracy, skupimy się na najważniejszym przypadku: sterowanie wtryskiem. Model behawioralny zostanie opisany za pomocą diagramu stanu. 128

129 uc Primary Use Cases Układ wtryskowy Uruchomienie silnika Wtrysk paliwa «invokes» Zw iększenie obrotów silnika Sterowanie wtryskiem «invokes» «include» Sterowanie zaworami wydechowymi Wyłączenie silnika Silnik Zmniejszenie obrotów silnia «extend» Wolne obroty Kierow ca Utrzymuw anie stałych obrotów Rys Przypadki użycia inicjowane przez Kierowcę oraz Silnik W tym miejscu należy zwrócić szczególną uwagę na definicję alfabetu akcji. Ma to istotne znaczenie podczas badania relacji równoważności pomiędzy modelami. Jeżeli w identycznych modelach zastosujemy różne alfabety akcji, narzędzia wspierające nie będą w stanie poprawnie zweryfikować relacji pomiędzy modelami. Dlatego też, już na początkowym etapie wprowadzone zostaną ujednolicone oznaczenia w języku angielskim, które będą stosowane także podczas fazy projektowania oraz implementacji. W celu zachowania spójności diagramu, także poszczególne stany zostaną nazwane w języku angielskim. Na rysunku 8.11 przedstawiono odpowiedni diagram stanów dla przypadku użycia sterowanie wtryskiem. Zakłada się, że układ wtrysku posiada trzy główne stany: wyłączony Off, w stanie inicjalizacji Initiation oraz włączony On. Stan Off odpowiada sytuacji, w której do układu nie jest doprowadzane zasilanie (brak kluczyków w stacyjce). Inicjalizacja układu następuje w momencie przekręcenia kluczyków do pierwszej pozycji zapłon. W tym stanie powinny być przeprowadzone czynności sprawdzające układy silnika oraz ewentualnie informujące użytkownika o defektach. Następnie kierowca włącza silnik i następuje przejście do staniu pracy układu On. W stanie On wtryskiwacz powtarza sekwencyjnie ciąg zadań: odczyt danych z sensorów i silnika ReadSensorData, obliczenie parametrów wtrysku Calculate, oczekiwanie na moment wtrysku Idle oraz sam wtrysk. 129

130 stm Sterowanie wtryskiem_v0.1 Initial On Off ev_engine_stop Initial ReadSensorData ev_read_done Calculate ev_ignition tm(injection_stop) ev_calculation_done Initiation ev_engine_start Injection tm(injection_start) Idle Rys Diagram stanów przypadku użycia "sterowanie wtryskiem" Wtrysk paliwa oznaczony jest zdarzeniami czasowymi tm(injection_start) oraz tm(injection_stop). Zakładamy, że układem wtrysku sterują bezpośrednio niezależne zegary, które są ustawiane w stanie Calculate. Na podstawie opis dynamiki przypadku użycia możemy zdefiniować formalne wymagania stawianie systemowi. Własności te powinny być przedstawione w postaci logiki temporalnej AF rachunek μ. Na potrzeby przykładu proponujemy, aby model systemu spełniał następujące własności: 1. Nie posiadał stanów zawieszenia (deadlock). Własność tą reprezentuje formuła: [ true* ] < true > true 2. Zawsze po wykonaniu akcji tm(injection_start), następuje tm(injection_stop) (jest to jedna z własności żywotności): < true*. "TM_INJECTION_START". true*. "TM_INJECTION_STOP" > true 3. Istnieje sekwencja akcji ev_engine_start, ev_read_done, ev_calculation_done po której następuje wtrysk paliwa: < true*. "EV_ENGINE_START". "EV_READ_DONE". "EV_CALCULATION_DONE". true*. "TM_INJECTION_START". true*."tm_injection_stop" > true Własności te możemy zapisać w osobnych plikach z rozszerzeniem *.mcl, a następnie wykorzystywać do badania kolejnych iteracji modeli. Wykorzystując algorytm translacji UML2LOTOS przedstawiony w rozdziale 6, tworzymy specyfikację diagramu 8.11 w języku LOTOS. Treść specyfikacji zamieszczono w dodatku A. Na bazie specyfikacji LOTOS budujemy graf LTS. W omawianym przykładzie zastosowano język skryptowy SVL. Polecenie generowania grafu LTS ma postać: "Injector1.bcg" = generation of "Injector1.lotos" W wyniku (* 7 states, działania 12 transitions, powyższego 3.0 polecenia Kbytes *) otrzymujemy następujący graf LTS (rys. 8.12). 130

131 Rys Graf LTS odpowiadający specyfikacji LOTOS Ze względu na niewielki rozmiar modelu oraz brak przejść ukrytych możemy zrezygnować z redukcji grafu. W kolejnych iteracjach, redukcja będzie jednak wykonywana z wykorzystaniem relacji silnej bisymulacji. Podczas fazy analizy pierwszej iteracji nie posiadamy modeli, które moglibyśmy badać relacjami równoważności. Wobec powyższego przechodzimy do badania wcześniej zdefiniowanych własności systemu. W tym celu możemy posłużyć się językiem SVL. Wykonujemy następujące polecenia: verify "prop1.mcl" in "Injector1.bcg" TRUE verify "prop2.mcl" in "Injector1.bcg" TRUE verify "prop3.mcl" in "Injector1.bcg" TRUE Weryfikacja potwierdziła, iż model Injector1.bcg spełnia wszystkie wymagane warunki. Następnie przechodzimy do analizy obiektowej systemu. Celem jest identyfikacja obiektów, które składają się na modelowany system. Proces identyfikacji jest najczęściej wieloetapowy i rozpoczyna się od wskazania głównych obiektów reprezentowanych przez rzeczowniki występujące w opisie. Następnie analizuje się celowość i funkcję wprowadzenia danego obiektu. Na diagramie 8.12 przedstawiono listę oraz relacje pomiędzy zidentyfikowanymi obiektami. Główne obiekty to sterownika systemu, poszczególne czujniki zarządzane przez odpowiedni sterownik. Pozostałe obiekty modelują pompę paliwową, przepustnicę, silnik, zawór wtrysku, zegar oraz tabele parametrów pracy układu wtryskowego. 131

132 obj ect Domain Model Czuj niktemperatury CzujnikCiśnieniaPaliwa CzujnikPrzepływuPowietrza CzyjnikLambda (from Czujniki) 1..n (from Czujniki) 1 1..n n (from Czujniki) 1..n (from Czujniki) 1 Przepustnica Sterow nikczujników TabelaParametrów (from Sterownik) SterownikWtrysku 1 ZawórWtrysku (from Sterownik) (from Sterownik) n PompaPaliwa 1..n Timer 1 Silnik (from Sterownik) (from Sterownik) (from Sterownik) Rys Model obiektów układu wtryskowego Na diagramie zaznaczono relacje pomiędzy poszczególnymi obiektami oraz liczność obiektów tychże relacji Etap projektu technicznego Na podstawie artefaktów etapu analizy przystępujemy do realizacji pierwszej iteracji projektu technicznego. W pierwszym kroku budujemy diagram klas. Bazując na diagramie obiektów z etapy analizy, tworzymy odpowiedni diagram klas. W szczególności może on odpowiadać diagramowi obiektów z uwzględnieniem wzorców projektowych oraz elementów języka implementacji. Diagram klas dla modelu układu wtryskiwacza przedstawiono na rysunku Do poszczególnych klas zostały dodane metody, niezbędne do wykonania poszczególnych operacji oraz akcji. 132

133 class System FuelSensor TemperatureSensor AirFlowSensor LambdaSensor «interface» SensorInterface + getsensordata() : void + resetsensor() : void + geterrorcode() : void ParameterTable SensorControl + readsensorsdata() : void + resetsensor() : void + calibratesensor() : void + geterrorcode() : void + gettabledata() : ParameterTable + setrowdata() : void 1 Throttle FuelPump + subthrottle() : void + addthrottle() : void 1 1 InjectionControl + checksensors() : void + getdeviceparameters() : ParameterTable + Initialization() : void + setdisplay() : void startpump() : void + stoppump() : void + decreacepressure() : void + increasepressure() : void InjectionValve + openvalve() : void + closevalve() : void 1..n 1..n Timer + settimer(timer) : void + resettimier(timer) : void 1 Engine + startengine() : boolean + stopengine() : boolean Rys Diagram klas modelu układu wtrysku paliwa Metody są następnie wykorzystywane podczas definiowania diagramów stanów poszczególnych obiektów. Zdefiniowanie dynamiki obiektów rozpoczynamy od stworzenia diagramu stanów klasy InjectionControl odpowiadającej za sterowanie całym układem wtryskowym. Na diagramie 8.15 przedstawiono odpowiedni diagram stanów klasy InjectionControl. Diagram zawiera zaprojektowane stany oraz wywoływane metody podczas realizacji poszczególnych zdarzeń. W celu zapewnienia wspólnego alfabetu akcji dla modeli analitycznych oraz projektowych, wprowadzono dla każdej metody alias, zawierający odpowiednią nazwę, wspólną dla wszystkich modeli. Podczas przygotowywania niniejszego przykładu, konieczna okazała się parokrotna zmiania nazw akcji, zarówno w modelu analitycznym jak i projektowym. Ma to szczególne znacznie w sytuacji wprowadzenia zmiennych oferowanych wraz z akcjami. Wtedy występuje konieczność wprowadzenia podobnych zmian w modelu analitycznym. Kolejnym krokiem procesu jest badanie relacji równoważności pomiędzy modelem analitycznym a przedstawionym poniżej modelem projektowym. W tym celu transformujemy diagram 8.15 do postaci specyfikacji LOTOS, a następnie wykonujemy następujące czynności: 133

134 1. "Injector1_prj.bcg" = generation of "Injector1_prj.lotos" (* 7 states, 12 transitions, 3.0 Kbytes *) 2. "Injector1_stron.bcg" = strong reduction of "Injector1.bcg" "Injector1_prj_strong.bcg" = strong reduction of "Injector1_prj.bcg" 3. "Injector_safety.seq" = safety comparison "Injector1_strong.bcg" == "Injector1_prj_strong.bcg" TRUE W pliku Injector_safety.seq zapisane zostają sekwencje, które w przypadku braku relacji równoważności, pokazują miejsce w grafie, w którym dana relacja nie jest zachowana. stm InjectionControl Initial On Off + entry / starttimier(entry) + exit / resettimer(exit) + exit / setdisplay stopengine() Initial ReadSensorData Calculate Initialization() + do / ReadInjectionParameter + do / ReadSensorsData Calculate() + do / CalculatePeriod + do / CalculateTimie + exit / settimier startengine() stopemc() CalculationReady Initiation Injection + entry / openvalve + exit / closevalve startemc() Idle Rys Diagram stanów dla klasy InjectionControl Podobnie jak w przypadku analizy, wykonujemy badanie własności modelu. Wykonujemy następujące polecenia: verify "prop1.mcl" in "Injector1_prj.bcg" TRUE verify "prop2.mcl" in "Injector1_prj.bcg" TRUE verify "prop3.mcl" in "Injector1_prj.bcg" TRUE Wynik TRUE badania relacji oraz wszystkich własności oznacza, że dany krok procesu projektowego zgodnego z metodologią f ROPES został przeprowadzony poprawnie. Następnie możemy przejść do fazy implementacji prototypu oraz jego testowania. Opis powyższych faz zostanie pominięty ze względu na ograniczony zakres merytoryczny pracy Iteracja 2 W pierwszej iteracji przedstawiono szczegółowo, krok po korku czynności wykonywane w procesie projektowym z wykorzystaniem f ROPES oraz narzędzi pakietu CADP. W kolejnych iteracjach omawianego przykładu zostanie położony nacisk na rozbudowę bazowego modelu oraz na badanie relacji 134

135 pomiędzy modelami analitycznymi. Dlatego też część kroków procesu nie będzie omawiana, a niektóre wywołania poleceń będą pomijane. Przypadek użycia Sterowanie wtryskiem obejmował szereg czynności wykonywanych przez projektowany sterownik. Dlatego też w kolejnym kroku zostanie uszczegółowiony zakres funkcjonalny tego przypadku. Na diagramie 8.16 przedstawiono szczegółowy opis przypadków wchodzących w skład Sterowania wtryskiem. uc Sterowanie wtryskiem Timer (from Actors) Sterowanie wtryskiem Czujnik ciśnienia paliwa (from Zestaw czujników) Kierowca (from Actors) Ustalenie położenia przepustnicy Ustawienie timera «include» Czujnik lambda (from Zestaw czujników) Odczyt prędkości obrotowej silnika «include» Wyznaczenie momentu wtrysku paliwa «invokes» Wyznaczenie okresu otw arcia zaw oru (lookup table) «include» «invokes» Czujnik temperatury silnika (from Zestaw czujników) Silnik (from Actors) Odczyt położenia wału dla cylindru Ci Wtrysk paliwa Czujnik natężenia przepływu powietrza (from Zestaw czujników) Rys Przypadek użycia Sterowanie wtryskiem Należy zauważyć, iż większość przypadków sprowadza się do opisu czynności koniecznych do obliczenia czasu trwania impulsu otwarcia zaworu wtrysku. Dane niezbędne do wykonania tej czynności pobierane są z poszczególnych czujników. Na tym etapie projektu konieczne jest także wprowadzenie modelu stanów silnika. Wobec powyższego wprowadzamy dodatkowy przypadek Zmiana stanu silnika w głównym diagramie rysunek Przypadek ten odpowiada zmianom stanu silnika, w zależności od warunków jego pracy. Aktualny stan silnika ma wpływ na obliczenia parametrów wtrysku. 135

136 uc Primary Use Cases Układ wtryskowy Uruchomienie silnika Zmiana stanu silnika Wtrysk paliwa «include» «invokes» Zwiększenie obrotów silnika Sterowanie wtryskiem «invokes» «include» Sterowanie zaworami w ydechowymi Wyłączenie silnika Silnik Zmniejszenie obrotów silnia «extend» Wolne obroty Kierow ca Utrzymuw anie stałych obrotów Rys Uzupełniony diagram przypadków systemu Diagram stanów odpowiadający przypadkowi użycia Zmiana stanu silnika został przedstawiony na diagramie stm Zmiana stanu silnika_v0.1 On Initial Starting ev_start_done HeatingUp ev_stop Off ev_start ev_temp_low ev_temp_normal CoolDow n ev_temp_high ev_temp_normal Normal Rys Diagram stanów przypadku "Zmiana stanu silnika" Model przedstawiony na diagramie 8.18 transformujemy do specyfikacji LOTOS, a następnie do grafu LTS. Przypadek Wtrysk paliwa sprowadza się do dwóch akcji: otwarcia oraz zamknięcia zaworu. Przypadek ten nie wymaga opisywania z wykorzystaniem diagramu stanów. 136

137 uc Wtrysk paliwa Wtrysk paliwa Otwarcie zaworu Sterownik układu wtryskowego (from Actors) Zamknięcie zaworu Timer (from Actors) Rys Przypadek wtrysku paliwa Następnie przechodzimy do uszczegółowienia diagramu stanów przypadku Sterowanie wtryskiem. W modelu pierwszej iteracji diagram stanów sterowania wtryskiem posiadał pewną niebezpieczną własność: wtrysk paliwa mógł być wykonany jedynie po zakończeniu obliczeń oraz ustawieniu odpowiednich parametrów wtrysku. Jednakże w przypadku silników samochodowych, gdzie w wyniku zmiennych warunków pracy nie możemy zawsze gwarantować stałego czasu pomiarów i obliczeń (np. zmniejszenie ciśnienia paliwa spowodowane zabrudzeniem filtra), oznaczałoby to brak wtrysku paliwa w wyznaczonym okresie. Jest to sytuacja bardzo niepożądana. W celu zapobieżenia występowania takiej sytuacji, należy oddzielić stan wtrysku od stanów przygotowawczych. Wprowadzamy nowy stan nadrzędny PrepareFule. Nowy diagram został przedstawiony na rysunku Po translacji diagramu do specyfikacji LOTOS otrzymujemy graf LTS zaprezentowany na rysunku Wprowadzona zmiana pozwoliła na wymuszenie wtrysku w przypadku braku zakończenia akcji stanów przygotowawczych. Należy założyć, iż to jest sytuacja awaryjna i może wynikać z uszkodzenia sensorów lub któregoś z elementów mechanicznych układu. Wtrysk powinien być wykonywany dla parametrów awaryjnych, co powinno prowadzić do zmniejszenia obrotów silnika. Następnie należy zbadać relację pomiędzy poprzednim modelem diagramu o jego obecną wersją. W tym celu wykonujemy następujące czynności: Translacja diagramu 8.20 do specyfikacji Injector2.lotos 1. "Injector2.bcg" = generation of "Injector2.lotos" (* 8 states, 19 transitions, 3.1 Kbytes *) 2. "Injector1_stron.bcg" = strong reduction of "Injector1.bcg" (* 6 states, 10 transitions, 3.0 Kbytes *) "Injector2_stron.bcg" = strong reduction of "Injector2.bcg" (* 6 states, 13 transitions, 3.1 Kbytes *) 3. "Injector_safety.seq" = safety comparison "Injector1_strong.bcg" <= "Injector2_strong.bcg" TRUE 137

138 Powyższe badanie potwierdza relację bezpieczeństwa preorder pomiędzy modelem Injector1 oraz Injector2. Oznacza to, że Injector1 symuluje Injector2 oraz, że oba modele spełniają te same własności bezpieczeństwa. stm Sterowanie wtryskiem_v0.2 On Off Injection_C(i) Initial ev_engine_stop tm(injection_start) tm(injection_stop) PrepareFuel_C(i) ev_ignition ReadSensorData_C(i) Initial Initiation ev_engine_start ev_read_done Idle_C(i) ev_calculation_done Calculate_C(i) ev_wait Rys Druga iteracja diagram stanów sterowania wtryskiem Następnie weryfikujemy własności modelu Injector2. W wyniku wykonania powyższych czynności, ustalamy, że druga iteracja procesu projektowanego została przeprowadzona poprawnie. Rys Graf LTS drugiej iteracji procesu 138

139 8.4.5 Iteracja 3 W trzeciej iteracji procesu projektowego skoncentrujemy się na uzupełnieniu diagramu stanów sterowania wtryskiem oraz wprowadzimy funkcje serwisowe. Pierwszą wprowadzoną zmianą jest rozszerzenie specyfikacji o obsługę większej liczby cylindrów. W tym celu wprowadzamy do stanu On nowy stan NewStroke, określający zamknięcie całego cyklu wtrysków wszystkich cylindrów. Dodana została także zmienna i, określająca numer cylindra, który aktualnie jest w fazie wtrysku. Po wykonaniu wszystkich wtrysków, zmienna i jest zerowana. Dodatkowo wprowadzamy możliwość wystąpienia defektu w pracy silnika lub podczas jego inicjalizacji. Realizuje to stan EngineDefect. Uszczegółowiony zostaje także stan inicjalizacji pracy sterownika. Obejmuje on sprawdzenie czujników oraz uruchomienie pompy paliwa. Jeżeli wszystkie czynności zostaną poprawnie zakończone, system oczekuje na uruchomienie silnika w stanie EngineReady. Uszczegółowiony diagram przedstawiono na rysunku stm Sterowanie wtryskiem_v0.3 Off ev_engine_stop On Injection_C(i) EngineDefect New Stroke ev_ignition ev_sensor_error ev_sensor_error tm(injection_stop) [i=n] tm(injection_start) tm(injection_stop) Czy wszystkie cylindry [i<n] ev_new_cycle Initial Initiation PrepareFuel_C(i) Initial ev_sensor_ok CheckSensors ev_engine_start Calculate_C(i) ev_read_done ReadSensorData_C(i) Initial StartPump ev_calculation_done Idle_C(i) ev_pump_ok EngineReady ev_wait ev_wait Rys Trzecia iteracja diagramu stanów sterowania wtryskiem Przechodzimy następnie do badania relacji powstałego modelu ze specyfikacją poprzedniej iteracji. W tym celu wykonujemy następujące polecenia: Translacja diagramu 8.22 do specyfikacji Injector3.lotos 1. "Injector3.bcg" = generation of "Injector3.lotos" (* 28 states, 97 transitions, 3.7 Kbytes *) 2. "Injector2_stron.bcg" = strong reduction of "Injector2.bcg" (* 6 states, 13 transitions, 3.1 Kbytes *) "Injector3_stron.bcg" = strong reduction of "Injector3.bcg" (* 22 states, 74 transitions, 3.7 Kbytes *) 3. "Injector_safety.seq" = safety comparison "Injector2_strong.bcg" <= "Injector3_strong.bcg" TRUE 139

140 Należy zwrócić uwagę, iż w specyfikacji LOTOS pojawiły się definicję typów danych oraz zmiennych (patrz dodatek A). Wynika to z konieczności obsługi zmiennej i, określającej numer cylindra w fazie wtrysku. Przechodzimy następnie o weryfikacji własności modelu Injector3. Wykonujemy następujące polecenia: verify "prop1.mcl" in "Injector3.bcg" FALSE verify "prop2.mcl" in "Injector3.bcg" TRUE verify "prop3.mcl" in "Injector3.bcg" TRUE Badanie to pozwoliło wykryć błąd w analizowanym modelu. Wykrycie defektu w pracy silnika i przejście do stanu EngineDefect powoduje zawieszenie pracy systemu. Należy w takim przypadku podjąć decyzję, co system powinien wykonać po wykryciu błędu. W przykładzie proponujemy, aby silnik został wyłączony przejście do stanu Off. Poprawiony diagram przedstawiono na rysunku stm Sterowanie wtryskiem_v0.3 Off ev_engine_stop On Injection_C(i) ev_engine_stop EngineDefect New Stroke ev_ignition ev_sensor_error ev_sensor_error tm(injection_stop) [i=n] tm(injection_start) tm(injection_stop) Czy wszystkie cylindry [i<n] ev_new_cycle Initial Initiation PrepareFuel_C(i) Initial ev_sensor_ok CheckSensors ev_engine_start Calculate_C(i) ev_read_done ReadSensorData_C(i) Initial StartPump ev_calculation_done Idle_C(i) ev_pump_ok EngineReady ev_wait ev_wait Rys Poprawiony diagram stanów dla sterownika wtrysku Po dokonaniu ponownej weryfikacji własności modelu możemy twierdzić, iż opisany krok procesu został wykonany poprawnie. Parametry pracy sterownika może definiować serwisant za pomocą odpowiedniego programatora. W tym celu należy przewidzieć dodatkowe przypadki użycia. Poza definiowaniem parametrów, serwisant może pobrać kody błędów, wynikające z przekroczenia dopuszczalnych wartości mierzonych wielkości tj.: temperatura, ciśnienie, ilość tlenu. 140

141 uc Zespół monitorujący Zespół monitorujący Odczytanie danych historycznych Odczytanie parametrów pracy Serwisant Sterow nik układu wtryskowego (from Actors) (from Actors) Ustaw ienie parametrów pracy Analiza parametrów czasowych Rys Przypadki użycia serwisu sterownika Sterownik układu wtrysku paliwa silnika spalinowego jest przykładem systemu czasu rzeczywistego o twardych warunkach czasowych. Oznacza to, że spóźnienie się któregoś z zadań powoduje, iż danych cykl wtrysku nie może być wykonany. Najczęściej prowadzi to do wyłączenia, lub spadku mocy silnika. Dlatego też w procesie projektowym musimy uwzględnić ograniczenia czasowe dla poszczególnych stanów sterownika. Silniki spalinowe pracują w różnych konfiguracjach: liniowej, V, płaskiej itd. Najczęściej spotykaną konfiguracja dla silników samochodów osobowych jest konfiguracja liniowa. W konfiguracji tej cylindry pracują w jednej płaszczyźnie i kierunku. Ilość cylindrów determinuje częstotliwość kolejnych cykli spalania. Przykładowo dla silnika z czterema cylindrami, wprowadza się spalanie parami. Oznacza to, że cylindry pracują w synchronicznych parach obrazuje to rysunek Rys Konfiguracja 4 cylindrów w silniku spalinowym. Źródło [69]. Układ sterownika powinien kontrolować dwie pary wtryskiwaczy. Ograniczenia czasowe wynikają bezpośrednio z prędkości obrotowej silnika oraz jego konfiguracji. Załóżmy, że silnik ma pracować 141

142 z maksymalnymi obrotami 8000 obr/min. Jeżeli analizujemy pracę silnika czterosuwowego, oznacza to, że wtrysk występuje co czwarty suw cylindra, czyli co dwa obroty wału. Wobec powyższego, wtrysk do jednego cylindra występuje co 267 ms. W przypadku konfiguracji liniowej z dwoma parami cylindrów, układ sterujący musi być w stanie wygenerować impuls sterujący wtryskiwaczem co 133ms (267/2). Otrzymujemy wobec tego ograniczenie czasowej na jeden cykl pracy stanów sterowania wtryskiem. Przedstawia to diagram czasowy stanów rysunek Diagram ten został przeskalowany do 100 jednostek czasu. sd Sterowanie wtryskiem {10} {10} {40} {4} {10} ReadSensorData TimeLine1 Calculate Idle Injection Rys Diagram czasowy stanów sterowania wtryskiem Formalne dowodzenie własności z ograniczeniami czasowymi nie jest obecnie możliwe z wykorzystaniem dostępnych programów narzędziowych. Zakłada się, iż wykorzystanie E LOTOS [8], pozwalającego na definiowanie ograniczeń czasowych, powinno być kolejnym krokiem w pracy badawczej nad f ROPES. 8.5 Podsumowanie W rozdziale przedstawiono koncepcję rozszerzenia metodologii ROPES o wykorzystanie metod formalnych w procesie wytwarzania oprogramowania. Jako formalizm zaproponowano wykorzystanie bazującego na algebrze procesów języka LOTOS. Dzięki algorytmowi transformacji diagramów stanów UML do specyfikacji LOTOS możliwe jest wprowadzenie formalnego dowodzenia poprawności oprogramowania w zakresie specyfikacji behawioralnej systemów czasu rzeczywistego. Przedstawiono także przykład przeprowadzenia procesu projektowego dla układu sterowania wtryskiem paliwa w silnikach spalinowych. Zaprezentowane trzy iteracje procesu miały na celu przedstawienie najważniejszych kroków w zakresie proponowanej metodologii f ROPES. Ważnym czynnikiem wpływającym na zastosowanie f ROPES jest konieczność utrzymywania wspólnego alfabetu akcji badanych modeli. Wykorzystanie koncepcji alias ów akcji pozwala na wprowadzenie spójnego procesu nazewnictwa oraz nie ogranicza modelu projektowego w zakresie definiowania metod oraz aktywności. Dalsze badania powinny koncentrować się na rozbudowie zastosowania metodologii dla ograniczeń czasowych poprzez wykorzystanie E LOTOS oraz czasowych algebr procesów. 142

143 9. Środowisko projektowo programistyczne 9.1 Wprowadzenie Możliwość praktycznego zastosowania dla metod formalnych ma znaczenie krytyczne. Posługując się analogią możemy powiedzieć, że praktyczne wykorzystanie metod formalnych w inżynierii oprogramowania jest tym, czym doświadczalna weryfikacja teoretycznych przewidywań teorii fizycznych. Bez tego elementu, wszystkie teorie pozostają hipotezami. Podobnie sytuacja wygląda w przypadku metod formalnych brak możliwości zastosowania dla rzeczywistych problemów poddaje w wątpliwość sens ich istnienia. Wbrew pozorom jest to pogląd bardzo powszechny, nie tylko wśród praktyków przedmiotu. Zastosowanie praktyczne metod formalnych w inżynierii oprogramowania zawsze sprowadza się do wykorzystania w procesie projektowym odpowiednich narzędzi wspierających projektantów systemów. Dlatego też, każda formalna metodologia powinna poza koncepcją teoretyczną obejmować specyfikację narzędzi wspomagających. Narzędzia te powinny tworzyć kompletne środowisko projektowo programistyczne, tak aby ich zastosowanie produkcyjne nie powodowało znacznego wzrostu kosztów wytwarzania oprogramowania. Ważne jest także, aby krzywa uczenia się obsługi tychże narzędzi była akceptowalna przez korporacje prowadzące projekty informatyczne z wykorzystaniem metod formalnych. Metodologia f ROPES także wpisuje się w opisany powyżej proces. Jej zastosowanie uwarunkowane jest możliwością wykorzystania dostępnych programów narzędziowych. f ROPES bazuje na dwóch podstawowych elementach: metodologii ROPES oraz języku LOTOS. Wybór nie był oczywiście przypadkowy. Oba obszary posiadają możliwe do wykorzystania pakiety narzędziowe, które pozwalają na budowę zintegrowanego środowiska f ROPES. W przypadku ROPES możemy wykorzystać dowolne narzędzie służące do modelowania w języku UML, jednak ze względy na swoją specyfikę oraz orientację na systemy czasu rzeczywistego, warto wykorzystać program Rhapsody firmy i Logic [72]. W przypadku języka LOTOS mamy dostępnych szereg narzędzi tj.: LOLO [10], TETRA [10] oraz TOPO. Jednakże najbogatsze środowisko dostarcza pakiet CADP[81] zwany także jako "CAESAR/ALDEBARAN Development Package", tworzony przez zespół INRIA Rhone Alpes. Poza kompilatorem języka LOTOS, pakiet udostępnia szereg narzędzi wspierających badanie własności tworzonych modeli. Bazując na powyższych dwóch pakietach możliwe jest zastosowanie metodologii f ROPES bez konieczności budowania oprogramowania narzędziowego od podstaw. Jednakże w celu ułatwienia stosowania f ROPES opracowano trzy projekty zintegrowanego środowiska projektowego, bazującego na oprogramowaniu Rhapsody oraz CADP. Celem stworzenia takiego środowiska jest całkowite zautomatyzowanie zastosowania f ROPES w procesie produkcyjnym. Projekty te różnią się od siebie poziomem integracji poszczególnych elementów środowiska projektowo programistycznego. 9.2 Interfejsy Rhapsody Stworzenie zintegrowanego środowiska projektowo programistycznego wymaga połączenia kilku niezależnych rozwiązań, rozwijanych przez niezależne firmy oraz grupy badawcze. Jako przykład można tu podać platformę Eclipse [80], która początkowo została stworzona, a następnie udostępniona jako oprogramowanie open source przez firmę IBM. Obecnie rozwijana jest przez niezależne firmy i grupy badawcze. Czynnikiem decydującym o sukcesie podobnych przedsięwzięć jest dostępność otwartych interfejsów do modułów platformy oraz systemów zewnętrznych, które umożliwiają rozbudowę bazowej aplikacji przez niezależnych producentów. O atrakcyjności systemu Rhapsody w głównej mierze decyduje duża ilość interfejsów udostępnianych przez twórców tego oprogramowania, w celu przetwarzania informacji o tworzonych modelach, jak 143

144 również w celu automatycznego przenoszeniu danych pomiędzy aplikacjami. Wśród tych interfejsów możemy wymienić: Interfejs z platformą Eclipse natywny interfejs do środowiska programistycznego Eclipse, pozwalający na automatyczne przenoszenie zmian z modelu do kodu źródłowego, jak również z kodu źródłowego do modelu. Interfejs DOORS możliwość połączenia z systemem zarządzania wymaganiami. Dzięki temu interfejsowi mamy możliwość powiązania poszczególnych elementów modelu (np. diagramy stanów) z odpowiednimi wymaganiami. Import modeli Rational Rose pozwala na załadowanie modelu w formacie Rational Rose do Rhapsody. Interfejs XMI bardzo elastyczny moduł importowania oraz eksportowania modelu UML do formatu XML. Interfejs Tornado pozwala na połączenie z platformą Tornado w celu symulacyjnego testowania oraz inspekcji zmiennych modelu z Rhapsody. Integracja Simulink połączenie z systemem Matlab oraz Simulink. Pozwala na symulację modeli dynamicznych opisanych poza systemem Rhapsody. Interfejs Teamcenter System Engineering połączenie do systemu zarządzania pracą zespołową. Interfejs programistyczny API umożliwia stworzenie aplikacji zewnętrznych odwołujących do funkcji oraz modelu Rhapsody. Ze względu na cele niniejszej pracy będziemy koncertować się na interfejsie XMI oraz Rhapsody API. Na ich podstawie zostaną przedstawione koncepcje stworzenia zintegrowanego środowiska projektowo programistycznego. Interfejs programistyczny Rhapsody pozwala na dostęp do elementów modelu przez programy zewnętrzne. Obecnie dostępne są dwa typy interjestów: COM wykorzystujący technologię Component Object Model firmy Mircosoft, pozwana na dostęp do aplikacji w środowisku Windows. Java dostęp do elementów aplikacji z wykorzystaniem technologii Java. Interfejs Java został udostępniony w wersji Rhapsody 7.0. Funkcjonalność obu typów interfejsów jest identyczna. Różnią się jedynie stroną techniczną realizacji. Interfejs API Rhapsody pozwala na czytanie, modyfikowanie, kasowanie oraz tworzenie poszczególnych elementów modelu. Umożliwia dostęp do danych modelu z aplikacji zewnętrznych całkowicie w sposób automatyczny, bez konieczności ręcznego przenoszenia modelu pomiędzy aplikacjami. Szczegółowy opis wykorzystania Rhapsody API można znaleźć w [71]. Interfejs XMI bazuje na standardzie ORG, określającym sposób wymiany meta danych z wykorzystaniem języka XML. XMI[47] pozwala w szczególności na zapisanie danych modelu UML w postaci pliku XML. Wprowadzenie standardu XMI umożliwia wymianę informacji o modelu pomiędzy niezależnymi aplikacjami. Oczywiście wykorzystanie XMI nie ogranicza się wyłączenie do języka UML. Generalnie można powiedzieć, że standard XMI pozwala zapisać każdy model oparty na MOF Meta Object Facility. W rzeczywistość MOF jest prostym językiem służącym do definiowania innych języków np. UML. W przypadku języka UML, MOF odpowiada definicji metamodelu UML. W tabeli 9.1 przedstawiono odpowiednie rzutowanie meta modeli według OMG. 144

145 Meta poziom Definicja MOF Przykład M3 meta metamodel model MOF M2 M1 meta metadane metamodel metadane model UML metamodel modele UML M0 dane modelowany system Tabela 9.1. Meta modele OMG Stosując język XML możemy wykorzystać transformaty XSLT w celu przetransformowania modelu UML do innej postaci. Wymaga to jednak zdefiniowania jednoznacznych reguł rzutowania. Pozwala także na wygenerowanie pliku XML tylko z wybraną częścią interesującego nas modelu np. tylko diagram klas lub diagramy stanów. 9.3 Pakiet CADP Pakiet CADP [81] oferuje szereg modułów funkcjonalnych, które pozwalają na specyfikację, symulację oraz weryfikację modeli systemów rozproszonych. W zakresie pakietu możemy wymienić następujące główne narzędzia: CAESAR kompilator języka LOTOS, który transformuje specyfikację LOTOS do kodu w języku C lub do grafu LTS. Algorytm translacji polega na przejściu ze specyfikacji języka LOTOS do uproszczonej wersji SUBLOTOS, a następnie wersja ta jest przekształcana do sieć Petriego. Graf LTS otrzymuje się poprzez konstrukcję grafu osiągalności dla sieci Petriego. BCG zbiór poleceń pozwalających na graficzną reprezentację oraz modyfikację grafów binarnych, które reprezentują struktury LTS. OPEN/CAESAR środowisko graficzne pozwalające na symulację, wykonywanie, weryfikację oraz generowanie testów modelowanego systemu. BISIMULATOR narzędzie pozwalające na weryfikację zadanych własność równoważności pomiędzy grafami LTS. REDUCTOR pozwala na zredukowanie grafu LTS za pomocą różnych rodzajów relacji: silnej bisymulacji, równoważności τ*.a, bisymulacji ścieżek itd. EVALUATOR narzędzie pozwalające na weryfikację modelu metodą model checking, z wykorzystaniem własności zakodowanych przy pomocy logiki temporalnej AF rachunek μ. EVA LUATOR sprowadza problem model checking do układu równań logicznych, a następnie rozwiązuje tenże układ. XTL język zbliżony do klasycznych języków programowania, pozwalający na opisanie działania operatorów w logikach temporalnych. EXP.OPEN narzędzie bada zależność pomiędzy zadanymi grafami w sieci komunikujących się procesów, reprezentowanych w postaci grafów BCG. PROJECTOR narzędzie redukuje specyfikację LOTOS zakodowaną w postaci grafu LTS w odniesieniu do zadanego interfejsu, także zakodowanego w postaci LTS. 145

146 SVL język skryptowy pozwalający na automatyzacje procesu kompilacji i weryfikacji zadanych specyfikacji. Pozwala na powiązanie ze sobą narzędzi CADP w sekwencję kolejnych kroków procesu weryfikacji specyfikacji systemu. DISTRIBUTOR dzieli graf na zadaną liczbę fizycznie rozproszonych maszyn z wykorzystaniem komunikacji TCP/IP. Ponowne złożenie grafu odbywa się za pomocą instrukcji BCG_MERGE. EUCALYPTUS graficzny interfejs użytkownika integrujący wszystkie narzędzia pakietu CADP oraz kilka narzędzi zewnętrznych: APERO, ELUDO oraz FC2TOOLS. Pakiet CADP jest dostępnych dla systemów operacyjnych: Solaris, Linux oraz Windows. W przypadku narzędzi uruchamianych z wiersza poleceń, dane wejściowe oraz wyjściowe są zapisywane w postaci plików w odpowiednim formacie. Obecnie stanowi to jedyny sposób bezpośredniej integracji narzędzi pakiety CADP z systemami zewnętrznymi. W zakresie projektowanego środowiska IDE będziemy wykorzystywać polecenia: CAESAR, BCG, BISIMULATOR, REDUCTOR, EVALUATOR oraz SVL. 9.4 Projekty środowiska IDE Koncepcja zintegrowanego środowiska projektowo programistycznego, w skrócie IDE, pozwalającego na praktyczne zastosowanie metodologii f ROPES opiera się na odpowiednim zintegrowaniu dostępnych obecnie narzędzi oraz wykonaniu programu automatycznie transformującego diagram stanów UML do specyfikacji LOTOS. Przedstawionych zostanie kilka projektów, które różnią się przede wszystkim stopniem zintegrowania poszczególnych elementów, a co za tym idzie konieczną ilością pracy niezbędnej do wykonania w celu jego stworzenia Projekt 1: Rhapsody VBA Pierwszy projekt środowiska IDE zakłada wykorzystanie języka Visula Basic for Application [74] oraz interfejsu Rhapsody API. W tym celu należy stworzyć zestaw funkcji VBA makr, które następnie zostaną zainstalowane w programie Rhapsody. Specyfikację funkcji makr możemy przedstawić w sposób następujący: Specyfikacja CreateLOTOSSpec funkcja transformuje diagram stanów do specyfikacji w języku LOTOS. Dane wejściowe: diagram stanów UML. Dane wyjściowe: plik tekstowy zawierający specyfikację w języku LOTOS. Opis działania: Funkcja pobiera informacje na temat diagramu za pomocą interfejsu IRP Statechart oraz IRPState. Następnie realizuje algorytm translacji przedstawiony w rozdziale TransformLOTOS2LTS funkcja transformuje specyfikację LOTOS do grafu LTS. Dane wejściowe: specyfikacja modelu w języku LOTOS. Dane wyjściowe: graf LTS modelu zapisany w formacie BCG. Opis działania: Funkcja wykorzystuje polecenie CAESAR w celu kompilacji specyfikacji w języku LOTOS do postaci grafu LTS. 3. VerifyLTS funkcja weryfikuje podstawowe własności modelu. Dane wejściowe: graf LTS zapisany w formacie BCG. Dane wyjściowe: plik tekstowy zawierający wyniki weryfikacji. Opis działania: Za pomocą polecenia EVALUATOR, weryfikowane są własności specyfikacji modelu tj.: żywotność, bezpieczeństwo, brak zakleszczeń (deadlock), brak pętli nieskończonych (livelock). 146

147 4. CheckIterationStep funkcja weryfikuje poprawność wykonania kolejnej iteracji modelu behawioralnego systemu. Dane wejściowe: grafy LTS zapisane w formacie BCG, odpowiadające iteracji i oraz i 1. Dane wyjściowe: wynik badania relacji bezpieczeństwa preorder pomiędzy modelami wejściowymi wraz ze wskazaniem miejsca, gdzie relacja nie jest spełniona. Opis działania: Za pomocą polecenia REDUCTION następuje zredukowanie grafu LTS, a następnie poleceniem BISIMULATION sprawdzana jest równoważność bezpieczeństwa preorder pomiędzy modelami wejściowymi. Jeżeli relacja jest spełniona funkcja zwraca wartość TRUE. W przeciwnym wypadku zwracana jest wartość FALSE oraz miejsce w którym relacja nie jest spełniona. 5. CheckDesignStep funkcja weryfikuje poprawność wykonania kolejnej iteracji modelu projektowego (implementacji) w stosunku do modelu analitycznego. Dane wejściowe: grafy LTS zapisane w formacie BCG, odpowiadające iteracji i. Dane wyjściowe: wynik badania relacji bezpieczeństwa obserwacyjnej kongruencji pomiędzy modelami wejściowymi wraz ze wskazaniem miejsca, gdzie relacja nie jest spełniona. 6. ModelCheckingLTS funkcja weryfikuje własność dla zadanego grafu LTS za pomocą algorytmu model checikng. Dane wejściowe: graf LTS w formacie BCG, plik testowy zawierający specyfikacje badanej własności w logice AF rachunek μ. Dane wyjściowe: plik tekstowy zawierający wyniki badania własności. Jako parametr Opis działania: wejściowy Wykorzystując wywołania marka polecenie podawany EVALUATOR będzie weryfikowane diagram Algorytm są własności działania zapisanie makra byłby następujący: przy użyciu logiki temporalnej. Implementacja powyższych funkcji w postaci makr VBA, pozwala umiejscowić je w obszarze działania aplikacji Rhapsody, co zdecydowanie ułatwia łatwość ich wykorzystania. Stanowi to największą zaletę tego rozwiązania. Projektant ma możliwość z poziomu jednej aplikacji wywołać funkcję automatycznie porównującą dwa modele, lub weryfikującą zadaną własność modelu. Warunkiem koniecznym funkcjonowania wyżej wyspecyfikowanych funkcji jest posiadanie zainstalowanej na tym samym stanowisku roboczym wybranych poleceń pakietu CADP. Koniecznym jest uwzględnienie wersji systemu operacyjnego stacji roboczej, jak również wykorzystywanych narzędzi. Ze względu na zastosowanie języka VBA warunkiem koniecznym jest posiadanie instalacji w systemie Windows. Problem ten zostanie poruszony w dalszych propozycjach środowiska IDE. Rysunek 9.1 przedstawia diagram procesu wykorzystania wyspecyfikowanych funkcji w procesie projektowym. 3. Wykonanie polecenia CADP Rys Proces projektowy z wykorzystaniem makr VBA 147

148 Wadą przedstawionego powyżej rozwiązania jest konieczność stosowania systemu Rhaposdy jedynie na platformie Windows. Rhapsody nie posiada wbudowanego modułu wersjonowania modeli, co także stanowi utrudnienie dla projektanta, który chce porównać modele dwóch kolejnych iteracji. W takich sytuacjach konieczne jest zachowywanie explicite modeli kolejnych iteracji w obszarze roboczym projektu. Dodatkowo projektant może elastycznie sterować procesem weryfikacji wywołując odpowiednie funkcje, co może skutkować rozprężeniem procedury projektowej i w konsekwencji doprowadzić do utraty jakość specyfikacji Projekt 2: Integracja XMI W celu eliminacji wad opisanego w poprzednim podrozdziale rozwiązania możemy wykorzystać standard ORG zapisu modeli MOF [47]. Stosując specyfikacje XMI możemy zapisać dowolny modelu w języku UML w formacie XML, a następnie przetwarzać na dowolnej platformie aplikacyjnej. Podobnie jak w większość profesjonalnych programów modelujących UML, także Rhapsody umożliwia zapisanie modelu UML zgodnie ze specyfikacją XMI. W ten sposób unikamy konieczność stosowania platformy Windows oraz systemu Rhapsody. Rozwiązanie to wymaga stworzenia niezależnego oprogramowania, którego zadaniem będzie przetwarzanie plików XML oraz uruchamianie poszczególnych algorytmów weryfikujących. Funkcje tego oprogramowania są zgodne z przedstawioną powyżej specyfikacją 9.1. Dodatkowo, oprogramowanie to przechowywałoby w swojej bazie danych kolejne wersje modeli oraz definicji własności systemu, co ułatwiłoby zarządzanie wersjami w aplikacji modelującej np. Rhapsody. Proces weryfikacji wyglądałby następująco: Algorytm Eksport weryfikowanych modeli do formatu XML zgodnie ze specyfikacją XMI. 2. Transformacja modelu XML za pomocą XSLT w celu wyekstrahowania z modelu diagramów stanu. 3. Import plików modeli do aplikacji weryfikującej. 4. Konwersja modelu UML do specyfikacji LOTOS wywołanie funkcji CreateLOTOSSpec. 5. Konwersja specyfikacji LOTOS do grafu LTS wywołanie funkcji TransformLOTOS2LTS. 6. Weryfikacja własności modelu wywołanie funkcji TransformLOTOS2LTS. 7. Weryfikacji poprawności kroku iteracji wywołanie funkcji CheckIterationStep. 8. Weryfikacja równoważności specyfikacji i implementacji CheckIDesignStep 9. Zapisanie zadanych własności modelu. 10. Weryfikacja własności modelu ModelCheckingLTS. Podczas implementacji omawianego rozwiązania należy uwzględnić konieczność wywołania poleceń pakietu CADP. Ze względu na możliwość współpracy z kilkoma platformami, naturalnym wyborem języka implementacji takiego oprogramowania jest Java. Na rysunku 9.2 przedstawiono przebieg procesu projektowego z wykorzystaniem omawianego podejścia. Wadą przedstawionego rozwiązania jest konieczność implementacji nowej aplikacji, wraz z nowym interfejsem użytkownika, która będzie zarządzać procesem weryfikacji oraz wersjonowania modeli. Pociąga to za sobą konieczność wykorzystania znacznie większej ilości zasobów, aniżeli w przypadku pierwszym. Dodatkowo, decydując się na implementację niezależnego rozwiązania, wprowadza się do procesu kolejną aplikację silos, który zwiększa złożoność środowiska projektowoprogramistycznego (co najmniej 4 osobne aplikacje do: modelowania UML, edycji kodu, wersjono 148

149 wania źródeł oraz weryfikacji) i w żaden sposób nie wspiera integracji pomiędzy poszczególnymi elementami. Rys Przepływ procesu z wykorzystaniem zewnętrznej aplikacji Model Checker Projekt 3: f ROPES Workbench Przedstawione wcześniej dwa projektu posiadają jedną wspólną wadę. Mianowicie są to rozwiązania zamknięte na integrację z zewnętrznymi środowiskami IDE oraz systemami wspierającymi zarządzanie projektem. Dodatkowo brak w nich sterowania procesem projektowym, wymuszającym poprawność kolejnych kroków procesu. Obecnie dominującą pozycję w inżynierii oprogramowania posiadają rozwiązania otwarte, najczęściej open source, gdzie rozwój poszczególnych modułów systemów jest realizowany przez niezależne grupy robocze, uniwersytety, czy też korporacje. Flagowym przykładem takiego podejścia jest platforma Eclipse [80]. Początkowo rozwijana przez firmę IBM jako platforma programistyczna dla środowiska Java, obecnie posiada kilkadziesiąt wersji dla różnych języków programowania. IBM udostępniając kod źródłowy platformy Eclipse, uruchomił ewolucyjny proces doskonalenia tego oprogramowania przez niezależne zespoły. Bardzo popularne stają się platformy oparte na Eclipse, specjalizowane w wybranych obszarach zastosowania. W zakresie systemów czasu rzeczywistego możemy wymienić środowisko WindRiver oparte o platformę Eclipse, specjalizujące się w tworzeniu systemów czasu rzeczywistego. Bogactwo funkcjonalne, a zatem i popularność platformy Eclipse opiera się na dwóch paradygmatach: 149

150 otwartość rozwiązania, osiągnięta poprzez udostępnienie prostego mechanizmu tworzenia wtyczek (plug in) poszerzających funkcjonalność samej platformy, jak również integrujących z innymi systemami zewnętrznymi, modularność, pozwalająca na współpracę wielu grup roboczych, koncentrujących się na wybranych modułach platformy. W ten sposób platforma Eclipse stanowi zintegrowane środowisko projektowo programistyczne, wykorzystywane na każdym etapie projektu informatycznego. Wydaje się więc naturalnym, iż realizacja metodologii f ROPES powinna opierać się o platformę Eclipse. Proponuje się, aby środowisko wspomagające metodologię f ROPES (f ROPES Workbench) powinno obejmować następujące moduły: Projektowania modeli w języku UML. Zarządzania wersjami modeli i kodów źródłowych. Zarządzania procesem projektowym i kontrolą jakości. Tworzenia oraz testowania oprogramowania. Translacji modelu do specyfikacji LOTOS oraz weryfikacji jej własności. Pakiet CADP. Rys Koncepcja f ROPES Workbench 150

151 Wybór odpowiednich aplikacji realizujących powyższe funkcjonalności jest praktycznie dowolny. Decydując się jednak na sprawdzone standardy tj. Rhapsody oraz Eclipse, uzyskujemy pewność rozwoju tychże aplikacji w przyszłości oraz gwarancję, że stworzone środowisko będzie akceptowalne przez projektantów oraz programistów. Dodatkowo, za wyborem Rhapsody przemawia możliwość łatwej integracji z Eclipse za pomocą Rhaposdy API. Systemy kontroli wersji modeli oraz kodów źródłowych można wybrać z obecnie dostępnych tj.: SVN, CVS, SourceSafe, itd. Eclipse posiada interfejsy do większości tego typu programów. W celu zarządzania procesem projektowym, w tym kontrolą jakości, można wykorzystać takie narzędzia jak MAVEN [70] lub Trac [77]. W ten sposób projektant przed przejściem do kolejnej iteracji procesu, będzie musiał pozytywnie zweryfikować własności stworzonego modelu. Jedynym modułem wymagającym zaimplementowania jest moduł translacji oraz weryfikacji modeli Model Checker. Jego funkcjonalność sprowadza się do zakresu specyfikacji 9.1. Moduł ten może zostać z powodzeniem zaimplementowany w postaci wtyczki platformy Eclipse. Implikuje to konieczność zastosowania języka Java podczas jego implementacji. Wybór tego języka pozwala na integrację z platformą Rhapsody poprzez Java API. Dodatkowo moduł Model Checker powinien obsługiwać interfejs XMI, dzięki czemu będzie mógł być wykorzystany przez projektantów nie wykorzystujących system Rhaposdy. Warto także wspomnieć o możliwości wykorzystania modułów Java w heterogenicznym środowisku operacyjnym. W przypadku wykorzystywania platformy Windows jako stanowiska projektowego, możemy wykorzystać pakiet CADP w wersji np. dla systemu operacyjnego Solaris, poprzez wykorzystanie Java RPC np. RMI. Wymaga to jedynie stworzenia odpowiednich agentów dla poszczególnych środowisk operacyjnych. 9.5 Podsumowanie Warunkiem koniecznym zastosowania metod formalnych w inżynierii oprogramowania jest dostępność narzędzi wspierających ich wykorzystanie w procesie produkcyjnym. Efektywne wykorzystanie formalnych metodologii dodatkowo wymaga integracji ze środowiskiem projektowoprogramistycznym. W rozdziale przedstawiono trzy koncepcje zintegrowanego środowiska IDE, wykorzystującego obecnie dostępne moduły modelowania oraz tworzenia oprogramowania. Projekty te różnią się od siebie złożonością integracji oraz otwartością architektury. Koncepcją najbardziej zaawansowaną jest środowisko f ROPES Workbench, integrujące wszystkie moduły występujące w procesie wytwarzania oprogramowania w jeden spójny proces. Wydaje się, że najlepszym sposobem realizacji stworzenia środowiska f ROPES Workbench jest ewolucyjne przejście poprzez wszystkie zaproponowane rozwiązania. 151

152 10. Analiza ekonomiczna zastosowania metodyki f ROPES 10.1 Wprowadzenie Zastosowanie metod formalnych w procesie wytwarzania oprogramowania jest przez większość praktyków postrzegane jako bardzo kosztowne oraz w większości przypadków niepraktyczne przedsięwzięcie. Często można spotkać twierdzenia, iż ich zastosowanie ogranicza się do wąskiego grona sytemu klasy life critical. Pomimo znaczących osiągnięć badań w obszarze metod formalnych w ostatnich kilku latach, opinia ta utrzymuje się nadal. Niejednokrotnie barierą zastosowania opracowanych metodologii jest brak wiedzy na ich temat wśród inżynierów praktyków. W celu zmniejszenia bariery zastosowania metod formalnych, tworzone są coraz bardziej zaawansowane narzędzia wspomagające, które automatyzują proces ich zastosowania. Działania te mają na celu przygotowanie zintegrowanego środowiska projektowego, w którym wykorzystanie metody formalnej odbywałoby się bez konieczności angażowania projektanta w manualną budowę dodatkowych specyfikacji lub modeli. Tylko przy spełnieniu powyższych warunków, metody formalne mogą stać się codziennością pracy informatyków, zajmujących się nie tylko systemami klasy life critical. Należy jednak nie zapominać o bardzo ważnej kwestii związanej z wprowadzaniem nowych paradygmatów lub standardów do inżynierii oprogramowania. Każda nowa technologia, nowy standard, koncepcja takie jak: SOA, MDA, EJB, ESB, itd., niosła ze sobą obietnicę, iż poprzez ich zastosowanie proces wytwarzania nowych produktów będzie tańszy i szybszy w porównaniu do ówcześnie wykorzystywanych. Rachunek ekonomiczny steruje rozwojem poszczególnych technologii oraz standardów wytwarzania oprogramowania. Warunek ten muszą spełniać także metodologie formalne. Obszarem, gdzie można osiągnąć największe korzyści z zastosowania metod formalnych to etap testów. Wystarczy wspomnieć, iż około 40% budżetów projektów informatycznych pochłania faza testów, aby dojść do przekonania o konieczności optymalizacji procesu wywarzania oprogramowania w tym właśnie obszarze. W dalszej części niniejszego rozdziału zostanie przedstawiona analiza ekonomiczna praktycznego zastosowania metodologii f ROPES Analiza jakościowa Analiza jakościowa zastosowania f ROPES zostanie przeprowadzona metodą porównawczą do obecnie stosowanych metodyk przeprowadzania testów oprogramowania. W następnym paragrafie zostaną przedstawione oszacowania liczbowe dla wskazanych elementów proponowanej metodologii Wprowadzenie do zagadnienia niezawodności oprogramowania W celu odpowiedzenia na pytanie w jakim zakresie zastosowanie metodologii f ROPES wpływa na jakość oprogramowania musimy wprowadzić kilka podstawowych informacji z zakresu jakości oraz niezawodności oprogramowania. Definicja 10.1 Jakością oprogramowania nazywamy ogół cech programu komputerowego, które wpływają na jego zdolność spełniania określonych wymagań tj.: funkcjonalność, elastyczność, integralność, efektywność, użyteczność, wydajność oraz niezawodność. W obszarze systemów czasu rzeczywistego, zwłaszcza wbudowanych, na szczególną uwagę zasługuje własność niezawodności. Własność ta określa minimalny czas pomiędzy kolejnymi błędnymi odpo 152

153 wiedziami systemu. Bazując na definicji niezawodność posiadamy możliwość prowadzenia badań z zakresu metodologii wykrywania defektów oprogramowania oraz skutecznych strategii przeprowadzania testów. Definicja 10.2 Niezawodnością oprogramowania nazywamy zdolność niezakłóconego wykonywania zadanej funkcji oprogramowania w danych warunkach eksploatacyjnych, przez zadany okres czasy. Niezawodność określamy jako prawdopodobieństwo wystąpienia defektu oprogramowania w zadanym okresie czasu:. W zakresie systemów czasu rzeczywistego definiuje się odpowiednie klasy niezawodności: ultra niezawodność odpowiada prawdopodobieństwu wystąpienia błędu < 10 7 w przeciągu godziny działania, średnia niezawodność prawdopodobieństwo od 10 3 do 10 7, niska niezawodność prawdopodobieństwo wystąpienia błędu > Wartości podanych przedziałów wykorzystuje się do projektowania procedur testowych oraz określania długości trwania testów np. z wykorzystaniem podejścia life testing. Pod koniec lat 90 XX wieku powstało wiele modeli statystycznych, które wprowadzały różnego rodzaju estymatory niezawodności oprogramowania. Jednym z pierwszych był model E.C. Nelson a [31], który bazując na statystycznej teorii próbkowania, zaproponował nowej podejście do procesu testowania, optymalizujące niezawodność oprogramowania. Nelson zaproponował, aby dziedzinę danych wejściowych programu podzielić na rozłączne dziedziny D 1,.,D s. Każda dziedzina D j może zostać podzielona na dwa ziobry: D j zbiór danych wejściowych dla których program π dostarcza poprawnej odpowiedzi oraz zbiór D j dla których program π zwraca odpowiedzi błędne. Przy takim założeniu, niezawodność programu π wyraża następująca zależność: 1 gdzie P j oznacza prawdopodobieństwo wystąpienia elementu w zbiorze D j oraz P j odpowiada prawdopodobieństwu wystąpienia danej wejściowej w zbiorze D j. Oczywiście parametry P j oraz P j nie są znane podczas prowadzenia testów. Jeżeli następnie założymy, że poszczególne domeny D j zawierają odpowiednio n j elementów, takich że: n 1 +n 2 + +n s =n, wtedy nieobciążonym estymatorem niezawodności oprogramowania jest wyrażenie: 1 gdzie, f j określa ilość błędnych próbek w zbiorze D j. Następnie, jeżeli założymy, iż wszystkie dane wejściowe należą do jednego zbioru D, wtedy powyższy wzór można przekształcić do prostej zależności. W konsekwencji, mając zadaną niezawodność oprogramowania oraz mając danych zbiór danych wejściowych, można określić możliwą ilość defektów przypadających na zbiór danych wej 153

154 ściowych. Zależność tę będziemy wykorzystywać w dalszej części rozdziały podczas określania czasu niezbędnego na przeprowadzenie testów, w celu uzyskania zakładanej niezawodności oprogramowania. Model Nelson a [23] jest uproszczonym odwzorowaniem niezawodności oprogramowania. Jedną z głównych jego wad jest brak rozróżnienia wagi błędów, zakładając że wszystkie błędy mają taką samą wagę równą 1. Dlatego inni badacze poszerzyli model Nelson a o możliwość wprowadzenia całkowitoliczbowej funkcji kosztów C(x,F(x)), gdzie F(x) oznacza wynika działania funkcjonalności F dla zadanych warunków wejściowymi x. Przykładem takiego podejścia jest model Weiss a i Weyuker a [23]. Niezależnie jednak od wprowadzonych rozszerzeń, główna relacja wyrażająca się jako stosunek ilość błędnych próbek do ilość próbek zostaje zachowana. Zastosowanie praktyczne modelu Nelson a zakłada możliwość prowadzenia badań z wykorzystaniem danych z etapu testów. Niekiedy jednak chcemy oszacować niezawodność oprogramowania jeszcze przed przystąpieniem do fazy testów np. na początku projektu. W takich przypadkach zaleca się stosowanie sieci Bayesowskich jako narzędzia estymacji prawdopodobieństwa wystąpienia defektów bazując na parametrach charakterystycznych procesu wytwarzania oprogramowania. Wadą tej metody jest konieczność eksperckiej oceny wag poszczególnych własności tj.: cykl projektowy, architektura, dojrzałość zespołu projektowego, ocena ryzyk zewnętrznych, zastosowanie metod formalnych, itd Metody przeprowadzania testów maszyn stanowych Metodologia f ROPES koncentruje się an weryfikacji specyfikacji behawioralnej systemu, reprezentowanej przez diagramy stanów. Ze względu na swoje szerokie zastosowanie maszyn stanowych w elektronice oraz w inżynierii oprogramowania, metody testowania maszyn stanowych były przedmiotem intensywnych badań przez ostatnie dziesięciolecia. Obecnie dysponujemy szerokim wachlarzem metod oraz algorytmów, które ułatwiają przeprowadzenie testów maszyn stanowych. Niemniej jednak nadal większość testów specyfikacji opartych o diagramy stanów przeprowadza się ręcznie poprzez wykonywanie odpowiednio przygotowanych scenariuszy testowych. Zakres testów maszyn stanowych możemy podzielić na kilka problemów, które będą przedmiotem naszego zainteresowania w dalszej części rozdziału: 1. Identyfikacji ścieżki synchronizacyjnej ustalenie stanu kończącego daną sekwencję testów. 2. Identyfikacja stanu ustalenie stanu początkowego maszyny stanowej lub stanu złożonego. 3. Weryfikacja stanu weryfikacja, czy maszyna znajduje się w zadanym stanie. 4. Weryfikacja maszyny (wykrycie defektu) badamy relację pomiędzy zadaną maszyną stanową, a jej specyfikacją także reprezentowaną przez maszynę stanową. 5. Identyfikacja maszyny posiadając nieznaną maszynę M próbujemy zidentyfikować jej strukturę wewnętrzną. Powyższe zadania są typowymi przykładami problemów weryfikacyjnych w testach black box. Rozwiązanie powyższy problemów pozwala na opracowanie scenariusza kolejnych kroków, które należy wykonać w celu pozytywnej lub negatywnej weryfikacji zadanej własności. W tym miejscu należy zaznaczyć, iż wszystkie powyżej wymienione własności maszyn stanowych są weryfikowane w metodologii f ROPES w sposób formalny po każdym zakończeniu iteracji. Z punktu widzenia procesu testowania najważniejszą jest własność 4. Istnieje wiele algorytmów opracowania sekwencji testowej, jednakże ich ogólna zasada działania pozostaje taka sama. Poszukujemy sekwencji zdarzeń a, która z zadanego stanu s i, powoduje przejście do stanu s j. Następnie badamy za pomocą sekwencji identyfikacyjnej (własność 2), stan wygenerowany przez sekwencje a w maszynie implementacyjnej. Poszczególne algorytmy różnią się jedynie sposobem identyfikacji stanów. Obecnie stosowane algoryt 154

155 my generują sekwencje testowe dla zadanej maszyny stanowej są rzędu O(pn 3 +n 4 log(n)) [31] dla maszyny bez funkcji reset oraz rzędu O(pn 3 ) [31] dla maszyn z funkcją resetującą, gdzie p oznacza ilość zdarzeń, natomiast n ilość stanów. Na wykresie 10.1 przedstawiono graficzną zależność złożoności maszyny stanowej oraz długości sekwencji testowych Długość sekwencji testowej ilość sekwencji testowych osobodni Ilość stanów/ilość zdarzeń 0 Rys Zależność długości sekwencji testowej od struktury maszyny stanowej Z zależności tej wynika, że małej maszyny stanowej n=10 oraz p=15 musimy wykonać sekwencję kroków, aby dokonać pełnej weryfikacji poprawności implementacji maszyny stanowej. W celu zapewnienia takiej samej niezawodności systemu jak w przypadku formalnej weryfikacji relacji równoważności maszyn stanowych, musimy wykonać pełną sekwencję testową. Chcąc jednak wykonać pełne pokrycie przestrzeni testowej i zakładając, że jedna sekwencja może zostać wykonana przez testera w 30s, testy takie wymagałyby wykorzystania 26 osobodni pracy testerów. W celu wykonania takich testów możemy także wykorzystać narzędzia wspomagające, które zdecydowanie przyśpieszają proces testów, jednakże narzucają pewne ograniczenia związane z ocenianym modelem: model specyfikacji musi być wyrażony z wykorzystaniem tego samego alfabetu stanów oraz akcji, graf maszyny stanowej musi być ściśle spójny, model specyfikacji nie może posiadać więcej stanów niż badana maszyna stanowa, zakłada się, że analizowane diagramy są maszynami płaskimi. Dlatego też, korzyści związane z zastosowaniem automatów testujących są ograniczone przez konieczność stosowania dwóch modeli systemu oraz ograniczeniami struktury diagramów stanów Testy heurystyczne W większości programów komputerowych nie jest wymagana wysoka niezawodność systemu. Możemy stwierdzić, iż nie interesuje nas pełna weryfikacja maszyny stanowej, a jedynie taka, która gwarantuje niski poziom niezawodności 10 3 (np. dla systemów niekrytycznych). Oznacza to, że na kroków może wystąpić 25 błędów (estymator Nelson a). Dobierając odpowiednią strategię próbkowania statystycznego otrzymujemy wielkość koniecznej próbki testowej. Wprowadza nas to w obszar testowania heurystycznego, gdzie poszczególne własności systemu są weryfikowane jedynie poprzez odpowiednią liczbę scenariuszy testowych. Ilość scenariuszy oraz czas potrzebny na ich przetestowa 155

156 nie zależy od złożoności systemu. W celu oszacowania czasu i zasobów niezbędnych do przeprowadzenia testów wprowadza się różne metody heurystyczne. W tabeli 10.1 przedstawiono zestawienie powszechnie stosowanych metod. Nazwa metody Opis Estymacja Ad hoc Proporcjonalna Oparta na metryce oprogramowania Punkty przypadków użycia Metoda oparta na spełnieniu wymagań wobec narzuconego harmonogramu lub budżetu. Ustalenie wymaganych zasobów i czasu przeznaczonego na testy na podstawie parametrów związanych z fazą implementacji systemu. Najczęściej przyjmuje się, że czas trwania testów wynosi około 30 40% czasu trwania implementacji. Bazuje na zależności pomiędzy wybraną metryką wielkości oprogramowania (np. KLOC, punkty funkcyjne), a długość trwania testów. Metoda oparta o analizę ilościową przypadków użycia. Stanowi średnią ważoną parametrów ilościowych przypadków użycia oraz wag, reprezentujących wiedzę ekspercką z zakresu procedur testowych. W odróżnieniu od poprzednich metod, punkty przypadków użycia wyrażą ilość zasobów niezbędnych do realizacji fazy testów. T t = C*T i, gdzie C stała proporcjonalności. T t = FP 1.2, gdzie FP punkty funkcyjne. R t = AUCP *c, gdzie c waga języka imp., AUCP=UUCP*(0,65+(0,01*TEF)), UUCP = UAC+UUCW, TEF współczynnik technologii UAC ilość aktorów UUCW liczba przypadków użycia Tabela Metody heurystyczne szacowania etapu testów Należy jednak podkreślić, iż wykonanie testów scenariuszowych nie gwarantuje uzyskania poziomu niezawodności, którą zakłada wykorzystanie metodologii f ROPES. Oznacza to, że obszar testów zgodności maszyn stanowych ze specyfikacją oraz ich własności charakteryzują się poniższymi cechami: jest realizowany na podstawie zaprojektowanych scenariuszy testowych, które badają jedynie wybrane ścieżki maszyn stanowych, brak jest możliwości automatyzacji procesu weryfikacji, istnieje jedynie możliwość ciągłego odtwarzania przebiegu wybranych scenariuszy, w stosunku do metodologii f ROPES, tradycyjne podejście do testów wymaga dodatkowych zasobów oraz czasu niezbędnego do ich realizacji. Ich oszacowanie wymaga zastosowania jednej z metod heurystycznych, weryfikacja poprawności specyfikacji powstałej na etapie analizy i projektu technicznego następuje dopiero po fazie implementacji, co w przypadku wykrycia błędów powstałych w tych etapach, znacznie zwiększa koszty ich usunięcia. Punkt ten zostanie poddany szczegółowej analizie podczas analizy ilościowej. 156

157 10.3 Analiza ilościowa Celem analizy ilościowej jest oszacowanie korzyści wynikających z zastosowania f ROPES w procesie wytwarzania oprogramowania. Koszt realizacji projektu informatycznego w podejściu iteracyjnym można przedstawić w postaci formuły: gdzie C i oznacza koszt realizacji danej iteracji, C w stanowi koszt wdrożenia oraz n określa ilość kolejnych iteracji procesu. Każda iteracja jest zdefiniowana jako sekwencyjna realizacja poszczególnych etapów: analizy, projektu technicznego, implementacji oraz testów. Dodatkowo, zakładamy, nie tracąc ogólności rozważań, iż będziemy analizować jedynie koszt osobowy związany z realizacją poszczególnych prac. Koszty materiałów oraz koszty zewnętrzne nie będą brane pod uwagę, ponieważ są najczęściej stałe, niezależnie od zastosowanych metodologii prowadzenia projektu i nie wpływają na wartości porównawcze. Zatem możemy zapisać, iż koszty osobowe realizacji projektu wynoszą: Koszty osobowe można wyrazić jako iloczyn średniego zaangażowania zasobów ludzkich oraz długości trwania etapu. Wobec powyższego wartość kosztów można wyrazić w postaci: gdzie M j średnia ilość osób zaangażowanych w etapie j, T j czas trwania etapu j. Wartość kosztów C wyrażamy w jednostkach osobodni, osobotygodni, osobomiesięcy, itd. w zależności od przyjętej skali czasu T. Wartość C można przeliczyć do skali pieniężnej, poprzez przemnożenie jej wartości przez średnią wartość pracy informatyka za dany okres czasu dla danej korporacji. Następnie przeprowadzimy analizę wpływu wykorzystania f ROPES na koszty poszczególnych etapów. W rozważaniach nie będziemy omawiać fazy implementacji oraz wdrożenia, ponieważ zastosowanie f ROPES nie ma bezpośredniego wpływu na ich przebieg. Zakładamy, że nie będziemy uwzględniać kosztów uczenia się oraz stworzenia odpowiedniego środowiska projektowego wspierającego f ROPES. Problem ten został umówiony w rozdziale Etap analizy W stosunku do tradycyjnego podejścia realizacji etapu analizy, f ROPES wprowadza następujące czynności dodatkowe: 1. Przeprowadzenie weryfikacji i uzgodnienie specyfikacji S i ze specyfikacją poprzedniej iteracji S j 1. Proces ten jest przeprowadzany automatycznie, jednakże w przypadku negatywnej weryfikacji, algorytm zakłada konieczność wprowadzenia korekt do specyfikacji S i. Realizacja tego zadania wymaga dodatkowego czasu oraz zasobów. 2. Zdefiniowanie warunków poza funkcjonalnych z wykorzystaniem formuł modalnej logiki temporalnej. 3. Przeprowadzenie automatycznej weryfikacji własności z punktu 2 dla specyfikacji S i. W przypadku braku zgodności należy wprowadzić odpowiednie korekty do specyfikacji. 157

158 Brak jest danych empirycznych pozwalających na dokładne oszacowanie, ile dodatkowo czasu oraz zasobów należy przeznaczyć na wykonanie powyższych czynności. Podczas realizacji przykładów w ramach pracy badawczej, wykonanie dodatkowych czynności analitycznych wynosiło około d A = 15% czasu podstawowego analizy. Zakłada się, że wartość tego współczynnika jest zmienna i zależy od złożoności i rozmiarów systemu Etap projektu technicznego Podobnie jak w przypadku etapu analizy, projekt techniczny f ROPES nie zakłada tworzenia dodatkowych modeli lub wprowadzenia dodatkowych długotrwałych zadań. Nowe składowe etapu projektu technicznego to: 1. Przeprowadzenie weryfikacji i uzgodnienie implementacji I i z implementacją poprzedniej iteracji I j 1. Proces ten jest przeprowadzany automatycznie, jednakże w przypadku negatywnej weryfikacji, algorytm zakłada konieczność wprowadzenia korekt do implementacji I i. 2. Przeprowadzenie weryfikacji i uzgodnienie implementacji I i ze specyfikacją S i powstałą w fazie analizy. Proces ten jest przeprowadzany automatycznie, jednakże w przypadku negatywnej weryfikacji, algorytm zakłada konieczność wprowadzenia korekt do implementacji I i. 3. Przeprowadzenie automatycznej weryfikacji własności poza funkcjonalnych dla implementacji I i. W przypadku braku zgodności należy wprowadzić odpowiednie korekty do danej implementacji. Oszacowanie realnego wzrostu zaangażowania zasobów w fazie projektu technicznego wymaga przeprowadzenia kilkunastu eksperymentów z wykorzystaniem f ROPES. Na tym etapie pracy badawczej można jedynie podać dane dla realizowanych przykładów. Efektywny wzrost zaangażowania zasobów wynosił około d A = 10%. Podana wartość wskaźnika d A wynika z dotychczasowych badań autora niniejszej pracy. Zakłada się, że wartość tego współczynnika także jest zależna od złożoności i rozmiarów systemu Etap testów Korzyści wynikające z wykorzystania f ROPES najbardziej uwidaczniają się podczas analizy ekonomicznej etapu testów. Jednym z podstawowych paradygmatów inżynierii oprogramowania jest reguła stwierdzająca, że najkosztowniejsze błędy są wprowadzane na początku projektu i usuwane na ostatnich jego etapach. Dla systemów czasu rzeczywistego przyjmuje się, że usunięcie błędów etapów początkowych kosztuje 100 więcej na etapie testów, aniżeli podczas tej samej fazy początkowej, w której powstał błąd. W celu zobrazowania powyższego problemu możemy podać przykład systemu nadzorowania produkcji [78]. Gotowa aplikacja napisana w języku C/C++ posiadała linii kodu. Podczas fazy testów wykryto defektów. Analizując poszczególne błędy oraz ich źródła wystąpienia, obliczono koszt usunięcia jednego defektu dla poszczególnych etapów projektu. Na wykresie 10.2 przedstawiono wyniki analizy. 158

159 Koszty usunięcia błędów w poszczególnych fazach projektu $15 000,,00 $14 102,00 $10 000,,00 $7 136,00 $5 000,,00 $0,,00 $139,00 $455,00 $977,00 Rys Przykładowy koszt usunięcia błędów w zależności od fazy projektu Z wykresu wynika, iżż koszt usunięcia błędu powstałego na etapie analizy jest około 100 razy mniejszy, aniżeli koszt usunięcia tego samego błędu na etapie testów. Dlatego priorytetem dla procesu wytwa na rzania oprogramowania powinna być maksymalizacja prawdopodo obieństwa wykrycia defektów początkowych etapach projektów. Metodologia f ROPES realizuje powyższy postulat poprzez zasto sowanie formalnych metod weryfikacji specyfikacji behawioralnej oraz implementacji projektowane f go systemu. W celu oszacowaniaa korzyści wynikających z wczesnego korygowania defektów z wykorzystaniem ROPES, musimy prześledzić dynamikę powstawania defektów w poszczególnych etapach projektu. Badania statystyczne wykazały, iż funkcja gęstości wystąpienia defektu w etapiee P projektu jest estymowanaa rozkładem Rayleigh a: gdzie E całkowita ilość defektów na KLOC, B efektywność identyfikacji defektów B [0,1], P faza projektu. Człon równania, określa gęstość występowania niezidentyfikowanych defektów w etapiee P. Całkowity koszt poprawy wszystkich defektów obliczamy: gdzie, n dp ilość defektów w fazie p, C p koszt usunięcia defektu w fazie p, N ilość etapów. Możemy następnie podstawićć wyrażenie określającą liczbę błędów i otrzymujemy całkowity koszt usunięcia defektów: 159