Differences

This shows you the differences between two versions of the page.

--- scr:systemy_czasu_rzeczywistego [2013/03/08 20:52]
pszwed [Cele]
+++ scr:systemy_czasu_rzeczywistego [2014/06/08 14:49] (current)
pszwed [Zakres dokumentacji]
@@ Line 1: / Line 1: @@
 ====== Systemy Czasu Rzeczywistego ======
+===== Organizacja zajęć =====
-[[scr:sidebar]]
+Zajęcia laboratoryjne obejmują dwie części:
+  *realizacja [[scr:laboratoria|ćwiczeń laboratoryjnych]]
+  *realizacja [[scr:projekt|projektu]]
-===== Projekt =====
-W wyniku realizacji projektu mają powstać trzy „artefakty”.
-  *Model formalny (sieci Petriego)
-  *Specyfikacja (UML)
-  *Implementacja (Java)
-Wpływ na ocenę:
-^Model formalny|25%|
-^Specyfikacja|25%|
-^Implementacja|50%|
-===== Model formalny =====
+===== Przykładowe realizacje =====
-Model formalny tworzony jest z wykorzystaniem sieci Petriego. Ma pokazać zasadę działania obejmującą fragment funkcjonalności.
+  *[[http://pszwed.kis.agh.edu.pl/kssres/skrzyz/index.html|Skrzyżowanie]]
+  *[[http://pszwed.kis.agh.edu.pl/kssres/FALA/index.html|Zielona fala]]
+  *[[http://pszwed.kis.agh.edu.pl/kssres/kociol/proj.html|Sterownik kotłą CO]]
+  *[[http://pszwed.kis.agh.edu.pl/kssres/bankomat/Page1.htm|Bankomat]]
-Jego zadaniem jest przede wszystkim:
+<!--  *[[http://zibiteac.ayz.pl| Symulatory ruchu na skrzyżowaniu (praca inżynierska)]] -->
-  *wczesna identyfikacja stanów systemu
+===== Tematy i rejestracja =====
-  *identyfikacja akcji wykonywanych w systemie
+[[scr:tematy|Lista tematów i formularz do rejestracji]]
-  *symulacja działania
-Model formalny będzie zawsze pewnym przybliżeniem – np.: zamiast 1-n procesów uwzględni procesy w konfiguracji 1-1.
+===== Zakres dokumentacji =====
-Nie będzie tak szczegółowy, jak implementacja
+  - Opis ogólny (krótki) ew. rysunek poglądowy.
+  - Główne komponenty (może być zilustrowane diagramem komponentów systemu) lub wyliczenie z informacjami, jakie dany komponent pełni zadania
-Używane narzędzie: [[http://www.renew.de/|Renew]]
+  - Opis realizacji przypadku(ów) użycia. Realizacja przypadku użycia różni się  się od specyfikacji, że nie pokazuje wyłącznie dialogu aktor-system, ale także działania wewnątrz systemu.
+  - Model formalny (sieci Petriego)
-===== Specyfikacja =====
+  - Dodatkowo: diagram klas, sekwencji do ilustracji wybranych elementów
-Specyfikacja składa się z dwóch podstawowych dokumentów:
-  *Analizy wymagań
-  *Projektu
-==== Analiza wymagań ====
-Analiza wymagań powinna definiować model logiczny i być sporządzona w oderwaniu od platformy, na której dokonuje się implementacji.
-Powinna:
-  *Zawierać analizę fizycznych własności systemu (tam gdzie ma to zastosowanie należy przeprowadzić obliczenia)
-  *Definiować otoczenie systemu (zewnętrzne elementy dokonujące interakcji z systemem)
-  *Definiować zdarzenia/informacje/komunikat przesyłane pomiędzy systemem i otoczeniem
-  *Definiować stany systemu (i komponentów).
-  *Identyfikować procesy zachodzące w systemie oraz to, kiedy (w reakcji na jakie zdarzenie) będą uruchamiane
-  *Definiować dialog pomiędzy systemem i jego otoczeniem oraz ewentualne wymagania czasowe.
-Nie powinna zawierać elementów leksykalnych języka implementacji, typu: button1Clicked, actionPerformed, Thread, Socket, paint.
-Wiele projektów ma charakter symulacyjny. Na poziomie analizy wymagań należy przeprowadzić rozgraniczenie między:
-  *implementowanym systemem (sterownik świateł na skrzyżowaiu)
-  *modelem otoczenia tworzonym na potrzeby symulacji (pojazd)
-Gdyby konieczne było ograniczenie specyfikacji – lepiej dokładniej wyspecyfikować system, a bardziej pobieżnie model otoczenia.
-W większości przypadków do zdefiniowania wymagań dla otoczenia wystarczy to, co wynika ze scenariuszy przypadków użycia lub diagramów sekwencji.
-W specyfikacji należy wykorzystać język UML.
-Diagramy UML można sporządzić wykorzystując ArgoUML, StarUML, Eneterprise Architect, Rational Rose lub Visio.
-==== Projekt ====
-Projekt systemu powinien zawierać odniesienia do implementacji.
-Struktura: definicje klas, relacje pomiędzy klasami
-Zachowanie: diagramy stanów, sekwencji
-Odwzorowanie wymagań w projekt (głównie zadań wykonywanych w systemie w metody konkretnych obiektów)
-W tej części wykorzystywany jest UML.
-===== Dokumentacja =====
-Oczekiwana objętość dokumentacji około 10 stron.
-Główne części:
-  *Ogólna koncepcja działania systemu. Wskazanie architektury systemu. (krótko)
-  *Model formalny (max 2-3 strony)
-  *Analiza wymagań (w równych proporcjach z projektem)
-  *Projekt
-Zaleca się mocną strukturalizację dokumentu.
-=====Implemetacja =====
-Implementacja ma być przeprowadzona w języku Java. Język nie jest językiem czasu rzeczywistego, ale do celów symulacyjnych może być z powodzeniem wykorzystany; zapewnia bardzo efektywne mechanizmy programowania współbieżnego (wątki, komunikacja, synchronizacja i wzajemne wykluczanie). Dodatkową zaletą jest łatwość tworzenia interfejsu graficznego.
-Program może być zrealizowany jako aplikacja lub aplet. Nie ma to wpływu na ocenę, chciaż forma apletu może wydawać się łatwiejsza do przedstawienia.
-Oczekuje się, że aplikacja będzie skonstruowana w postaci zbioru wątków komunikujących sie za pośrednictwem obiektów typu semafory, kolejki komunikacji, ewentualnie zabezpieczone obiekty dzielone.
-Wykluczona jest realizacja sekwencyjnego programu sterowanego zdarzeniami generowanymi w interfejsie graficznym
-Efektem tej fazy jest prezentacja działającego programu oraz dostarczenie go w formie kodu źródłowego i w wersji skompilowanej. Nie należy dostarczać programu w formie projektu dla aplikacji typu IDE. W dokumentacji należy podać komendę uruchamiającą program/dostarczyć plik BAT.
-Zakłada się, że z językiem Java zapoznaliście się Państwo na przedmiocie Języki i Techniki Programowania.
-Narzędzia: dowolny kompilator/interpreter języka Java (liniowy z SDK lub IDE): javac/java, JBuilder, NetBeans, RealJ, JCreator, Eclipse.
-Wszystkie używane narzędzia są dostępne jako freeware, ew. Visio na licencji akademickiej dostępnej bezpłatnie dla studentów AGH.