Projektowanie architektury oprogramowania wbudowanego nie jest trywialnym przedsięwzięciem, jak już opisywaliśmy w poprzedniej części artykułu. Procesu tego nie da się przemyśleć w ciągu jednego popołudnia. Architektura oprogramowania również nie wyłoni się w cudowny sposób z samego skupienia się na pisaniu kodu. Istnieje pięć kroków, które zespoły mogą wykonać, aby ją opracować i rozwinąć:
1. Oddziel architekturę oprogramowania;
2. Zidentyfikuj i śledź zasoby danych;
3. Rozłóż system na czynniki pierwsze;
4. Zaprojektuj interfejs i komponenty;
5. Symuluj, iteruj i skaluj.
W ostatnim poście omówiono pięć kroków niezbędnych do zaprojektowania wbudowanej architektury oprogramowania. Przybliżono korzyści płynące z analizowania oprogramowania systemów wbudowanych jako dwóch osobnych ujęć: architektury biznesowej aplikacji niezależnej od sprzętu i zależnej czasu rzeczywistego. W tym poście przyjrzymy się drugiemu etapowi projektowania: identyfikowaniu i śledzeniu zestawów danych.
Krok #2 – Zidentyfikuj i prześledź pakiety danych
Kiedy pracujemy z zespołami przy tworzeniu ich oprogramowania wbudowanego, zauważam, że inżynierowie wykazują dwie tendencje. Po pierwsze, chcą dostać się do sprzętu od pierwszego dnia. Inżynierowie zachowują się tak, jakby kod niskiego poziomu wchodzący w interakcję z urządzeniem był produktem końcowym i nie ma chwili do stracenia. Niestety jest to przestarzały pogląd na przygotowywanie oprogramowania wbudowanego. W większości systemów rzeczywista wartość tkwi w kodzie aplikacji, czyli niezależnej od sprzętu części architektury.
Po drugie, inżynierowie niemal natychmiast zaczynają rzucać pomysły architektoniczne na wzorce projektowe dotyczące przerwań, wiadomości, interakcji RTOS i tak dalej. Chociaż wspaniale jest przeprowadzić burzę mózgów i przedstawić założenia do oceny, skąd wiesz, jakie koncepcje i wzorce pasują do problemów projektowych pierwszego dnia? Odpowiedź jest prosta — nie możesz!
Gdy zespół przejdzie przez pierwszy krok, oddzielając architekturę oprogramowania, drugim jest identyfikacja i śledzenie zestawów danych. Te to wszelkie zasoby używane przez system, aby pomóc mu w wykonywaniu jego funkcji. Na przykład system wbudowany może zawierać zestawy danych, takie jak:
* Klucze szyfrujące;
* Unikalny numer identyfikacyjny (UUID);
* Mapy pikseli;
* Stany kontrolera;
* Itp.
Oczywiście o wiele więcej pakietów danych trafia do docelowego systemu, ale ta lista doskonale oddaje samą ideę. Kiedy wszystko sprowadzamy do danych, to to, co robimy, to starania, aby zaprojektować i zbudować system osadzony w czasie rzeczywistym, który w odpowiedni sposób zarządza zasobami.
Pierwsza zasada projektowania oprogramowania wbudowanego
Pierwszą zasadą nowoczesnego projektowania oprogramowania wbudowanego jest: „Dane dyktują projekt”. Potrafimy stworzyć wszelkiego rodzaju ekscytujące i niepowtarzalne architektury do wykonania określonego zadania. Z doświadczeń wynika jednak, że najbardziej wydajną architekturą jest ta, która jest zaprojektowana wokół zestawów danych systemu. Dzieje się tak, ponieważ wszystkie obce śmieci, które często trafiają do architektury, jako że są najnowsze i najlepsze lub tak uważamy, zostają wyrzucone.
Kiedy skupiamy się na danych, architektura może stać się nadmiernie skoncentrowana na tym, co powinna z nimi robić. Jak się okazuje, na zasobach można wykonać tylko kilka operacji. Po pierwsze, system może wprowadzać dane. Na przykład użytkownik może nacisnąć przycisk lub układ może odebrać zasoby szeregowe przez interfejs komunikacyjny. Po drugie, system może wyprowadzać dane. Na przykład wyświetlić mapę pikseli na wyświetlaczu lub sterować silnikiem. Po trzecie, system może przetwarzać zasoby. Na przykład, być może dane szeregowe przychodzą w formacie pakietu, który jest następnie dekodowany. Przetwarzanie ma na celu sprawdzenie jego poprawności, a następnie jego rozpakowanie. Wreszcie system może przechowywać dane w pamięci ulotnej lub nieulotnej.
Identyfikacja zestawów danych i operacji, które można wykonać na nich, może znacznie pomóc zespołowi w zaprojektowaniu wbudowanej architektury oprogramowania. Pakiety te są jak czerwone flagi, które wskazują na potrzebę architektoniczną w projekcie. Niestety zbyt wiele zespołów ignoruje dane i zamiast tego goni za nowoczesnymi wzorcami projektowymi, zanim zrozumieją problemy z zasobami. Te mankamenty próbują z kolei rozwiązać za pomocą swojego systemu.
Co oznacza architektura zorientowana na zasoby?
Wiem, że wielu twórców oprogramowania wbudowanego uzna pomysł, że: „Dane dyktują projekt” za trochę dziwny. Wydaje mi się to zaskakujące, biorąc pod uwagę, że w programowaniu obiektowym skupiamy się na tworzeniu obiektów, które są zbiorami danych z operacjami na nich. Zorientowany na zasoby pogląd na projektowanie architektury nie jest nowy. Jednak patrzenie na nią z punktu widzenia danych ma wiele zalet.
Po pierwsze, podejście do architektury oparte na zasobach dobrze zazębia się z zespołami, których systemy mają problemy z bezpieczeństwem. Jeśli chcemy zabezpieczyć swój mechanizm wbudowany, musimy przeprowadzić analizę bezpieczeństwa modelu zagrożeń (TMSA). Ta weryfikacja wymaga od programistów zidentyfikowania różnych zestawów danych i określenia niezbędnych poziomów ochrony. TMSA należy wykonać przed zaprojektowaniem systemu, co oznacza, że wiele szczegółów koniecznych dla architektury podyktowanej danymi będzie już dostępnych. Dwie pieczenie na jednym ogniu.
Po drugie, identyfikacja zestawów danych może pomóc nam określić, w jaki sposób system może zostać rozbity na poziomie komponentów. Załóżmy, że jesteśmy dobrymi architektami i przestrzegamy zasady pojedynczej odpowiedzialności (SRP). W takim przypadku istnieje duża szansa, że każdy pakiet danych, który identyfikujemy, zostanie opakowany w swój moduł z funkcjami.
Po trzecie, śledzenie interakcji różnych zestawów danych może zacząć wskazywać, jak można zaprojektować system na poziomie aplikacji. Załóżmy na przykład, że widzę zasoby wprowadzane do systemu i ich wysoką częstotliwość w porównaniu z szybkością, z jaką będą przetwarzane. W takim przypadku mogę zacząć wiązać interakcję z czynnością wejściową w celu otrzymania danych i czynnością ich procesowania. We wczesnych fazach architektury nie wybieram, czy zasoby wejściowe o wysokiej częstotliwości są odbierane za pomocą przerwań, bufora, czy bezpośredniego dostępu do pamięci (DMA). Po prostu warto związać ten problem i odsunąć ostateczną decyzję do momentu, gdy będzie to konieczne. Nie od razu należy zakładać, że przetwarzanie jest operacją RTOS. Czynność ta może być prostym zadaniem, a może czymś innym. Za wcześnie, żeby to stwierdzić. Podczas gdy inżynier często dąży do jak najszybszego uchwycenia, jak największej liczby szczegółów, dobry architekt oprogramowania stara się podejmować działania tak późno, jak to tylko możliwe, aby zmaksymalizować elastyczność.
Podsumowanie
Drugim krokiem w projektowaniu architektury oprogramowania wbudowanego jest identyfikacja i śledzenie zestawów danych w systemie. Nadmierne skoncentrowanie się na zasobach może wydawać się dziwne dla inżyniera, który zazwyczaj skupia się na sprzęcie. Jednym ze sposobów pomocy w zmianie myślenia jest modyfikacja istniejącej definicji, aby brzmiała ona tak:
„Oprogramowanie wbudowane to kod zaprojektowany i skonstruowany tak, aby działał deterministycznie, często w czasie rzeczywistym, który zarządza zasobami poprzez dane wejściowe i wyjściowe, przetwarzanie oraz przechowywanie w różnych formach”.
Świetna architektura wbudowanego oprogramowania pozwala na dyktowanie projektu przez dane. Ich identyfikacja, a następnie śledzenie interakcji z innymi w systemie może pomóc architektowi zobaczyć, jak może ona powstać. Jej obraz często zaczyna się od widoku z wysokości 10 000 metrów, ze wskazówkami, gdzie komponenty i zadania mogą mieć sens. Jednak na tym etapie chcemy tylko zidentyfikować zestawy danych i operacje, w które są zaangażowane. Obraz architektury zacznie się pojawiać następnym razem, gdy przyjrzymy się krokowi trzeciemu, czyli dekompozycji systemu.
Źródło: https://www.embedded.com/5-steps-to-designing-an-embedded-software-architecture-step-2/
1. Oddziel architekturę oprogramowania;
2. Zidentyfikuj i śledź zasoby danych;
3. Rozłóż system na czynniki pierwsze;
4. Zaprojektuj interfejs i komponenty;
5. Symuluj, iteruj i skaluj.
W ostatnim poście omówiono pięć kroków niezbędnych do zaprojektowania wbudowanej architektury oprogramowania. Przybliżono korzyści płynące z analizowania oprogramowania systemów wbudowanych jako dwóch osobnych ujęć: architektury biznesowej aplikacji niezależnej od sprzętu i zależnej czasu rzeczywistego. W tym poście przyjrzymy się drugiemu etapowi projektowania: identyfikowaniu i śledzeniu zestawów danych.
Krok #2 – Zidentyfikuj i prześledź pakiety danych
Kiedy pracujemy z zespołami przy tworzeniu ich oprogramowania wbudowanego, zauważam, że inżynierowie wykazują dwie tendencje. Po pierwsze, chcą dostać się do sprzętu od pierwszego dnia. Inżynierowie zachowują się tak, jakby kod niskiego poziomu wchodzący w interakcję z urządzeniem był produktem końcowym i nie ma chwili do stracenia. Niestety jest to przestarzały pogląd na przygotowywanie oprogramowania wbudowanego. W większości systemów rzeczywista wartość tkwi w kodzie aplikacji, czyli niezależnej od sprzętu części architektury.
Po drugie, inżynierowie niemal natychmiast zaczynają rzucać pomysły architektoniczne na wzorce projektowe dotyczące przerwań, wiadomości, interakcji RTOS i tak dalej. Chociaż wspaniale jest przeprowadzić burzę mózgów i przedstawić założenia do oceny, skąd wiesz, jakie koncepcje i wzorce pasują do problemów projektowych pierwszego dnia? Odpowiedź jest prosta — nie możesz!
Gdy zespół przejdzie przez pierwszy krok, oddzielając architekturę oprogramowania, drugim jest identyfikacja i śledzenie zestawów danych. Te to wszelkie zasoby używane przez system, aby pomóc mu w wykonywaniu jego funkcji. Na przykład system wbudowany może zawierać zestawy danych, takie jak:
* Klucze szyfrujące;
* Unikalny numer identyfikacyjny (UUID);
* Mapy pikseli;
* Stany kontrolera;
* Itp.
Oczywiście o wiele więcej pakietów danych trafia do docelowego systemu, ale ta lista doskonale oddaje samą ideę. Kiedy wszystko sprowadzamy do danych, to to, co robimy, to starania, aby zaprojektować i zbudować system osadzony w czasie rzeczywistym, który w odpowiedni sposób zarządza zasobami.
Pierwsza zasada projektowania oprogramowania wbudowanego
Pierwszą zasadą nowoczesnego projektowania oprogramowania wbudowanego jest: „Dane dyktują projekt”. Potrafimy stworzyć wszelkiego rodzaju ekscytujące i niepowtarzalne architektury do wykonania określonego zadania. Z doświadczeń wynika jednak, że najbardziej wydajną architekturą jest ta, która jest zaprojektowana wokół zestawów danych systemu. Dzieje się tak, ponieważ wszystkie obce śmieci, które często trafiają do architektury, jako że są najnowsze i najlepsze lub tak uważamy, zostają wyrzucone.
Kiedy skupiamy się na danych, architektura może stać się nadmiernie skoncentrowana na tym, co powinna z nimi robić. Jak się okazuje, na zasobach można wykonać tylko kilka operacji. Po pierwsze, system może wprowadzać dane. Na przykład użytkownik może nacisnąć przycisk lub układ może odebrać zasoby szeregowe przez interfejs komunikacyjny. Po drugie, system może wyprowadzać dane. Na przykład wyświetlić mapę pikseli na wyświetlaczu lub sterować silnikiem. Po trzecie, system może przetwarzać zasoby. Na przykład, być może dane szeregowe przychodzą w formacie pakietu, który jest następnie dekodowany. Przetwarzanie ma na celu sprawdzenie jego poprawności, a następnie jego rozpakowanie. Wreszcie system może przechowywać dane w pamięci ulotnej lub nieulotnej.
Identyfikacja zestawów danych i operacji, które można wykonać na nich, może znacznie pomóc zespołowi w zaprojektowaniu wbudowanej architektury oprogramowania. Pakiety te są jak czerwone flagi, które wskazują na potrzebę architektoniczną w projekcie. Niestety zbyt wiele zespołów ignoruje dane i zamiast tego goni za nowoczesnymi wzorcami projektowymi, zanim zrozumieją problemy z zasobami. Te mankamenty próbują z kolei rozwiązać za pomocą swojego systemu.
Co oznacza architektura zorientowana na zasoby?
Wiem, że wielu twórców oprogramowania wbudowanego uzna pomysł, że: „Dane dyktują projekt” za trochę dziwny. Wydaje mi się to zaskakujące, biorąc pod uwagę, że w programowaniu obiektowym skupiamy się na tworzeniu obiektów, które są zbiorami danych z operacjami na nich. Zorientowany na zasoby pogląd na projektowanie architektury nie jest nowy. Jednak patrzenie na nią z punktu widzenia danych ma wiele zalet.
Po pierwsze, podejście do architektury oparte na zasobach dobrze zazębia się z zespołami, których systemy mają problemy z bezpieczeństwem. Jeśli chcemy zabezpieczyć swój mechanizm wbudowany, musimy przeprowadzić analizę bezpieczeństwa modelu zagrożeń (TMSA). Ta weryfikacja wymaga od programistów zidentyfikowania różnych zestawów danych i określenia niezbędnych poziomów ochrony. TMSA należy wykonać przed zaprojektowaniem systemu, co oznacza, że wiele szczegółów koniecznych dla architektury podyktowanej danymi będzie już dostępnych. Dwie pieczenie na jednym ogniu.
Po drugie, identyfikacja zestawów danych może pomóc nam określić, w jaki sposób system może zostać rozbity na poziomie komponentów. Załóżmy, że jesteśmy dobrymi architektami i przestrzegamy zasady pojedynczej odpowiedzialności (SRP). W takim przypadku istnieje duża szansa, że każdy pakiet danych, który identyfikujemy, zostanie opakowany w swój moduł z funkcjami.
Po trzecie, śledzenie interakcji różnych zestawów danych może zacząć wskazywać, jak można zaprojektować system na poziomie aplikacji. Załóżmy na przykład, że widzę zasoby wprowadzane do systemu i ich wysoką częstotliwość w porównaniu z szybkością, z jaką będą przetwarzane. W takim przypadku mogę zacząć wiązać interakcję z czynnością wejściową w celu otrzymania danych i czynnością ich procesowania. We wczesnych fazach architektury nie wybieram, czy zasoby wejściowe o wysokiej częstotliwości są odbierane za pomocą przerwań, bufora, czy bezpośredniego dostępu do pamięci (DMA). Po prostu warto związać ten problem i odsunąć ostateczną decyzję do momentu, gdy będzie to konieczne. Nie od razu należy zakładać, że przetwarzanie jest operacją RTOS. Czynność ta może być prostym zadaniem, a może czymś innym. Za wcześnie, żeby to stwierdzić. Podczas gdy inżynier często dąży do jak najszybszego uchwycenia, jak największej liczby szczegółów, dobry architekt oprogramowania stara się podejmować działania tak późno, jak to tylko możliwe, aby zmaksymalizować elastyczność.
Podsumowanie
Drugim krokiem w projektowaniu architektury oprogramowania wbudowanego jest identyfikacja i śledzenie zestawów danych w systemie. Nadmierne skoncentrowanie się na zasobach może wydawać się dziwne dla inżyniera, który zazwyczaj skupia się na sprzęcie. Jednym ze sposobów pomocy w zmianie myślenia jest modyfikacja istniejącej definicji, aby brzmiała ona tak:
„Oprogramowanie wbudowane to kod zaprojektowany i skonstruowany tak, aby działał deterministycznie, często w czasie rzeczywistym, który zarządza zasobami poprzez dane wejściowe i wyjściowe, przetwarzanie oraz przechowywanie w różnych formach”.
Świetna architektura wbudowanego oprogramowania pozwala na dyktowanie projektu przez dane. Ich identyfikacja, a następnie śledzenie interakcji z innymi w systemie może pomóc architektowi zobaczyć, jak może ona powstać. Jej obraz często zaczyna się od widoku z wysokości 10 000 metrów, ze wskazówkami, gdzie komponenty i zadania mogą mieć sens. Jednak na tym etapie chcemy tylko zidentyfikować zestawy danych i operacje, w które są zaangażowane. Obraz architektury zacznie się pojawiać następnym razem, gdy przyjrzymy się krokowi trzeciemu, czyli dekompozycji systemu.
Źródło: https://www.embedded.com/5-steps-to-designing-an-embedded-software-architecture-step-2/
Fajne? Ranking DIY
