Zaczynam od programowania oprogramowania wbudowanego za pomocą RTOS, a ponieważ jestem już programistą aplikacji komputerowych, zastanawiałem się, jak to jest modelować oprogramowanie wbudowane przy użyciu diagramów UML, takich jak diagramy aktywności, diagramy sekwencji, przypadki użycia itp.
Czy oprogramowanie wbudowane jest zaprojektowane przy użyciu UML, tak samo jak aplikacje komputerowe? Czy to najlepsza opcja, czy jest lepsza? Czy mogę podać jakieś przykłady?
Czy istnieje specjalne narzędzie, które to robi?
Odpowiedzi:
Istnieją rozszerzenia UML w czasie rzeczywistym, które zostały spopularyzowane przez firmę, której nazwa w tej chwili mi ucieka. Pamiętam, jak napisałem o tym kilka lat temu. Bruce Powell Douglass napisał kilka książek na temat modelowania systemów osadzonych przy użyciu UML, ale jego firma nie jest tą, o której myślę.
Powiedziawszy to, aby powtórzyć Wouterowi, nie ma nic specjalnego w oprogramowaniu wbudowanym jako takim. Codziennie piszę oprogramowanie wbudowane dla systemu działającego na procesorach klasy Pentium; UML jest całkiem odpowiedni. Pamiętaj również, że z czasem dodano do UML wiele aspektów oprogramowania sterującego: istnieje składnia do określania zdarzeń synchronicznych lub asynchronicznych wraz z czasem odpowiedzi na diagramach sekwencji, zachowanie typu Petri można znaleźć na diagramach aktywności, zachowanie modelu Statecharts jeszcze lepiej niż diagramy stanu mogą itp.
OTOH, wiele osób woli modelować oprogramowanie wbudowane przy użyciu koncepcji Structured Design i Dataflow. Wszystko zależy od rodzaju projektowanego systemu i tego, co działa najlepiej.
źródło
Przechodząc do RTOS, zwykle mamy do czynienia z aplikacją, która ma wiele współbieżnych zadań, które należy optymalnie zaplanować, aby każde z nich dotrzymało terminów lub bezpiecznie dzieliło zasoby. Wybrane środowisko RTOS implementuje harmonogram zadań, a Twoim zadaniem (zwykle) jest zapisanie tych indywidualnych zadań z pewnym zestawem właściwości (okres, priorytet itp.), A następnie przekazanie ich harmonogramowi. Tak więc w przypadku dokumentacji podejściem, które wybrałbym, byłoby dokładne udokumentowanie każdego zadania.
Większość oprogramowania wbudowanego i, o ile mi wiadomo, większość RTOS-ów nie jest napisana w języku zorientowanym obiektowo, a zatem może nie korzystać z wielu rzeczy, które są ukierunkowane na takie jak na przykład diagramy klas.
Jednak przy dokumentowaniu zadań RTOS, każdy schemat dobrze opisujący zadanie byłby bardzo korzystny. Wyobrażam sobie, że schemat sekwencji dla każdego zadania może być na przykład bardzo pomocny. Oprócz tego możesz określić jego twarde wymagania, takie jak okres / częstotliwość, priorytet, wszelkie współdzielone zasoby, których może używać, wymagania dotyczące uprzedniej emulacji itp. Warto również udokumentować, jak skonfigurowałeś RTOS i być może stan maszyna jego algorytmu szeregowania.
Skorzystaj z którejkolwiek z tych rad, jak chcesz, nie zawiodłem się w RTOS od czasów studenckich i nigdy tak naprawdę nie „udokumentowałem” pracy.
źródło
Najważniejsze jest modelowanie
wiedząc, jaki aspekt jest trudny i złożony w Twojej aplikacji,
znalezienie narzędzia do modelowania / języka / abstrakcji / konwencji / zapisu odpowiedniego dla tego aspektu
zaprojektowanie tego aspektu
Dlatego żadne narzędzie do modelowania / podejście / itp. Nie jest odpowiednie dla wszystkich sytuacji. Satelita będzie prawdopodobnie systemem wielozadaniowym w czasie rzeczywistym, prawdopodobnie z więcej niż jednym procesorem. Diagramy struktury zadań, STD i diagramy sekwencji są prawdopodobnie przydatne (żeby wymienić tylko kilka). Jeśli projekt jest wykonywany w C, diagram klasy jest mniej przydatny (jeśli okaże się bardzo przydatny, wybór C prawdopodobnie był zły). Nie przepadam za UseCases, a satelita nie ma użytkownika. Przypadki użycia są najbardziej odpowiednie w sytuacji, gdy chcesz omówić wymagania dotyczące systemu z użytkownikiem nietechnicznym. Jeśli tak jest w przypadku projektu satelitarnego, coś poszło nie tak.
źródło
Nie zaprojektowałem niczego, co ma miejsce w kosmosie. Ale pracowałem dla podwykonawcy lotniczego Departamentu Obrony (DoD) i wiele moich projektów było zakwalifikowanych do lotów. Wymagają dużo dokumentacji dotyczącej twoich projektów i zawierają opisy elementów danych (DID), które dokładnie opisują to, co chcą zobaczyć.
Możesz użyć szybkiego wyszukiwania DoD ASSIST, aby zobaczyć wszystkie DID dla dokumentów, które mogą być wymagane, jeśli wpiszesz „oprogramowanie” w polu „Słowo (-a) w tytule” i klikniesz Prześlij. (Zabawne jest to, że witryna DoD wyświetla ostrzeżenie bezpieczeństwa certyfikatu, ale zapewniam cię, że jest bezpieczny).
Ponieważ pytasz konkretnie o Dokument Projektowy, oto DID Software Design Description (SDD). Podkreślają użycie słów do opisania każdej części projektu. Ale jeśli użycie UML, diagramów stanu, schematów blokowych, pseudokodu itp. Może poprawić zrozumienie projektu, to oczywiście chcieliby go dołączyć.
Wybór metody modelowania, jak stwierdzili inni, zależy od projektu. Ale pomyślałem, że zobaczenie DID dla oprogramowania lotniczego może pomóc ci napisać dokument projektowy, ponieważ twój projekt jest związany z przestrzenią.
źródło