Ten dokument dotyczył laboratorium prowadzonego w latach poprzednich.

Na obecnym laboratorium ( 2002) użycie programu LACATRE w fazie projektowanie nie jest wymagane. Jednakże można posłużyć się tym narzędziem do automatycznej generacji kodu VxWorks.

1.     Cel projektu

Celem projektu jest zastosowanie Inżynierii Oprogramowania w cyklu budowy niewielkiej aplikacji czasu rzeczywistego dla systemu operacyjnego VxWorks.

 Docelowa aplikacja uruchamiana będzie w środowisku VxSim - symulatora systemu VxWorks dla systemu UNIX. Jako język programowania użyty zostanie język C.

Skala aplikacji (bliska skali małych systemów wbudowanych) i typ środowiska pozwoli na zapoznanie z zasadami programowania na poziomie bliskim jądra systemów operacyjnych czasu rzeczywistego.

Jako język projektowania użyty zostanie graficzny język LACATRE. Przejście pomiędzy projektem systemu a implementacją będzie wspomagane przez generator kodu C LA4VXW.

2.     Etapy realizacji

Przewidziane są nastepujace eatpy realizacji:

·       Analiza wymagań (metoda SART WM)

·       Projektowanie (LACATRE)

·       Implementacja (środowisko VxSim, jezyk C)

2.1     Analiza wymagań

2.1.1     Cel

Celem tego etapu jest:

·       Określenie wejść i wyjść aplikacji.

·       Wstępny podział aplikacji na moduły, ustalenie jej architektury.

·       Wydzielenie modułów realizujących programową symulację otoczenia fizycznego.

·       Dekompozycja modułów.

2.1.2     Proponowana metodologia

Podstawową metodą analizy wymagań powinna być metoda SART Warda-Mellora. Przy specyfikacji wymagań dotyczących interfejsu modułów można użyć MSC (message sequence chart) lub pochodne.

2.1.3     Użyte narzędzia

Brak propozycji )

2.1.4     Oczekiwane rezultaty:

1.     Opis wymagań systemu wraz z interfejsem 

2.     Opis architektury systemu (podział na moduły i ich powiązania)

3.     Opis modułów (dekompozycja na podprocesy, definicje danych) 

4.    Opcjonalnie:  Opis zewnętrznego interfejsu modułów (zachowanie z użyciem MSC, definicje danych) 

2.2     Projektowanie [2002 -- Ten element może zostać pominięty]

2.2.1     Cel

Celem tego etapu jest dokonanie odwzorowania jednostek (procesów, danych) występujących w analizie wymagań w elementy występujące w języku projektowania oraz stworzenie odpowiedniej dokumentacji.

2.2.2     Proponowana metodologia

Proponowana metodologią projektowania jest graficzny język LACATRE.

2.2.3     Użyte narzędzia

Program LACATRE dla środowiska MS Windows

2.2.4     Oczekiwane rezultaty:

1.     Opis projektu modułów  w postaci diagramów LACATRE

2.     Opis interfejsu modułów

3.     Opis sposobu odwzorowania jednostek analizy wymagań w elementy projektu 

4.     Definicje wymienianych danych w języku C

2.3     Implementacja

Celem tego etapu jest:

·       automatyczna translacja modułów LACATRE do kodu C [w przypadku pominięcia etapu projektowania konieczna będzie implementacja manualna]

·       uzupełnienie kodu modułów o deklaracje struktur

·       kompilacja i uruchomienie aplikacji

·       prezentacja działającej aplikacji

2.3.1     Użyte narzędzia

Translator LA4VXW (MS DOS). 

Uwaga translator ma drobny błąd, akceptuje pliki o rozszerzeniach pisanych małymi literami!.

2.3.2     Oczekiwane rezultaty:

1.     Kod źródłowy w postaci pliku

2.     makefile [W Tornado zbędne]

3.     Opis sposobu uruchamiania

4.     Opis sposobu testowania

3.     Dodatki

3.1     Dodatek A Zasady przejścia pomiędzy SART a językiem LACATRE

3.2     Dodatek B Zasady generacji kodu z LACATRE

Program graficzny LACATRE powstał niemal 10  lat temu i jest już mocno przestarzały. Wiele elementów interfejsu jest niewygodnych i kłopotliwych w obsłudze. LACATRE nie obsługuje struktury wielomodułowej aplikacji, pozwala na umieszczenie jednego modułu w jednym pliku.

3.2.1     Cykl zycia

Na rysunku 1 przedstawiono cykl życia aplikacji LACATRE.

1.     Za pomocą narzędzia graficznego użytkownik edytuje poszczególne moduły. Moduły są zapisywane w plikach o rozszerzeniu LA4. Równocześnie w trakcie edycji generowany jest pseudokod LACATRE, który zapisywany jest w pliku o rozszerzeniu T.

2.     W drugim etapie następuje konwersja pseudokodu LACATRE do kodu języka C dla systemu VxWorks. Możliwa jest konwersja pojedynczego pliku lub kilku modułów. Wynikiem jest pojedynczy plik C.

3.     Programista manualnie uzupełnia kod wynikowy, głównie dodając deklaracje pól struktur dla zasobów (dzielona pamięć) i przesyłanych komunikatów. Translator zaznacza miejsca uzupełnień dyrektywą #error .

Rys. 1 Cykl życia aplikacji LACATRE

Możliwość obsługi wielomodułowej aplikacji nie została z początku wbudowana i dlatego ma ona wiele ograniczeń.

3.2.2     Zasady użycia języka LACATRE

Nieobsługiwane elementy

LACATRE był projektowany jako język dla wielu platform, dlatego występują w nim elementy nadmiarowe, które nie są obsługiwane przez translator LA4VXW:

1.     Nie należy używać obiektu Message i MessagePool; jawne obiekty są specyficzne dla platformy IRMX. Message może pojawić się jedynie jako argument SEND_TO_MBX

2.     Nie należy używać obiektu Event

3.     Nie należy używać obiektów Export i Import

 Deklaracje obiektów

Pseudokod LACATRE nie zawiera instrukcji deklaratywnych. Za deklaracje obiektu przyjmuje się:

·       dla obiektu programowalnego - jego procedurę obsługi

·       dla obiektu konfigurowalnego (nieprogramowalnego) - wywołanie funkcji CREATE_XXX

Powtórzone obiekty

Podobnie jak w DFD można umieszczać na diagramie drugą instancję obiektu konfigurowalnego.

Rys. 2 Powtórzony obiekt Mailbox

3.2.3     Interfejs modułów

Zasady ustalania interfejsu modułów są bardzo proste:

1.     można uzyskać dostęp do dowolnego obiektu konfigurowalnego z zewnętrznego modułu umieszczając go na schemacie, (ale nie tworząc go za pomocą CREATE_XXX).

2.     można uzyskać dostęp do dowolnej procedury z zewnętrznego modułu umieszczając ją na schemacie i poprzedzając jej nazwę jej nazwę modyfikatorem „EXTERN:”.

Na ג przedstawiono aplikację złożona z dwóch modułów SENDER i RECEIVER. Moduł SENDER odwołuje się do zewnętrznej procedury receiver_init oraz zewnetrznego obiektu receiver_mbx (który zostanie zadeklarowany poprzez umieszczenie funkcji pierwotnej CREATE_MAILBOX.)

Rys. 3 Aplikacja złożona z dwóch modułów

3.2.4     Parametry wywołania LA4VXW

Składnia pliku LVP

3.3     Dodatek C Zawartość dyskietki [archiwum]