Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
scr:systemy_czasu_rzeczywistego [2013/03/08 20:56] pszwed [Systemy Czasu Rzeczywistego] |
scr:systemy_czasu_rzeczywistego [2014/06/08 14:49] (current) pszwed [Zakres dokumentacji] |
||
---|---|---|---|
Line 1: | Line 1: | ||
====== Systemy Czasu Rzeczywistego ====== | ====== Systemy Czasu Rzeczywistego ====== | ||
+ | ===== Organizacja zajęć ===== | ||
- | + | Zajęcia laboratoryjne obejmują dwie części: | |
- | [[scr:sidebar]] | + | |
- | + | *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:// |
+ | *[[http:// | ||
+ | *[[http:// | ||
+ | *[[http:// | ||
- | Jego zadaniem jest przede wszystkim: | + | < |
- | *wczesna identyfikacja stanów systemu | + | ===== Tematy i rejestracja ===== |
- | | + | [[scr: |
- | *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, | + | - Opis ogólny (krótki) ew. rysunek poglądowy. |
- | + | | |
- | Używane narzędzie: [[http:// | + | |
- | + | - Model formalny | |
- | ===== 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: | + | |
- | + | ||
- | | + | |
- | *Definiować otoczenie systemu (zewnętrzne elementy dokonujące interakcji | + | |
- | *Definiować zdarzenia/ | + | |
- | *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, | + | |
- | + | ||
- | Wiele projektów ma charakter symulacyjny. Na poziomie analizy wymagań należy przeprowadzić rozgraniczenie między: | + | |
- | + | ||
- | *implementowanym systemem (sterownik świateł na skrzyżowaiu) | + | |
- | | + | |
- | + | ||
- | 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 | + | |
- | + | ||
- | 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 | + | |
- | + | ||
- | + | ||
- | + | ||
- | =====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; | + | |
- | + | ||
- | 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, | + | |
- | + | ||
- | Wykluczona jest realizacja sekwencyjnego programu sterowanego zdarzeniami generowanymi w interfejsie graficznym | + | |
- | + | ||
- | + | ||
- | + | ||
- | Efektem tej fazy jest prezentacja | + | |
- | + | ||
- | Zakłada się, że z językiem Java zapoznaliście się Państwo na przedmiocie Języki i Techniki Programowania. | + | |
- | + | ||
- | Narzędzia: dowolny kompilator/ | + | |
- | + | ||
- | + | ||
- | + | ||
- | Wszystkie używane narzędzia są dostępne jako freeware, ew. Visio na licencji akademickiej dostępnej bezpłatnie dla studentów AGH. | + | |
- | + | ||
- | + |