Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

5 kroków do zaprojektowania wbudowanej architektury oprogramowania - część 5

ghost666 09 Jan 2023 03:45 792 0
Computer Controls
  • To ostatnia część poradnika poświęconego opracowaniu architektury wbudowanej. Dotychczasowo omówiliśmy tworzenie poszczególnych elementów i klasyfikację ich, w zależności od kontaktu ze sprzętem etc. Ostatni krok łączy wszystkie poprzednie, zapewniając nam kompletną i całkowitą architekturę.

    Pięć kroków projektowania, które przedstawione zostały w ramach w tej serii, obejmuje:

    1. Oddziel ją;
    2. Zidentyfikuj i śledź zestawy danych;
    3. Rozłóż system na czynniki pierwsze;
    4. Zaprojektuj interfejs i komponenty;
    5. Symuluj, iteruj i skaluj.

    Z pewnością obecnych może być więcej lub mniej ujęć, ale to nie jest krytyczne. Gdyż te pięć ma pomóc architektowi w określeniu tego, co musi zrobić i ogólnego procesu, który będzie realizował. Ten artykuł zamyka serię, analizując ostatni etap: Symuluj, iteruj i skaluj.

    Krok #5 – symuluj, iteruj i skaluj

    Tworzenie wbudowanej architektury nie jest na ogół pojedynczym wydarzeniem w cyklu życia oprogramowania (SDLC). Gdyby tak było i miało miejsce w jednym punkcie, oznaczałoby to, że na początku wiemy wszystko, co powinniśmy o systemie i że nic się nie zmieni w trakcie całego procesu. Do tej pory, jak wskazuje autor artykułu, w jego 20-letnim doświadczeniu przy około 150 projektach, nigdy nic takiego nie zaszło. Klienci zlecający produkcję oprogramowania zwykle próbują wprowadzać modyfikacje prawie do dnia wysyłki gotowego konceptu, a w niektórych przypadkach nawet później. Mimo wstępnie znanych wymagań oprogramowania będą się one zmieniać w czasie wykonywanych prac.

    Rozwój architektury oprogramowania jest procesem iteracyjnym. Zazwyczaj zaczyna się od najwyższych poziomów, przysłowiowego: „widoku z wysokości”, a następnie przechodzi się do coraz większej liczby szczegółów. Całość dobrze zrobiona jest często ograniczona, co oznacza, że jest podzielona na kilka autonomicznych lub częściowo niezależnych domen. Można wykorzystać symulację do przetestowania i udowodnienia, że architektura wysokiego poziomu będzie odpowiadać nie tylko naszym potrzebom, ale także klientom. Jeśli odkryte zostaną problemy, następuje kolejna iteracja mająca na celu ulepszyć projekt.

    W miarę ewolucji potrzeb klientów całość również musi przeobrażać się i skalować. Architektura oprogramowania i jej rozwój nigdy się nie kończą. Zawsze jest więcej do zrobienia, niezależnie od tego, czy chodzi o usuwanie błędów, dodawanie nowych funkcji, czy refaktoryzację w celu poprawy jakości i czytelności kodu. Często zdarza się, że zespół opracowuje podstawową architekturę, która działa jako platforma do tworzenia dziesiątek produktów. Taki koncept musi się dobrze skalować, aby sprostać nieznanym przyszłym potrzebom.

    Symulacja oprogramowania wbudowanego

    Pomysł symulowania oprogramowania wbudowanego nie jest nowy, ale jeśli przyjrzymy się realnej pracy programistów czy architektów, to można dostrzec, że obecnie nie ma to wielkiego zastosowania. W przedstawionych artykułach w tym cyklu wielokrotnie podkreślano i pokazywano, jak dobrze zaprojektowana architektura oddziela aplikację od niskopoziomowych zależności sprzętowych. Zaletą takiego podejścia jest to, że można przeprowadzać testy jednostkowe bez sprzętu i uruchamiać kod aplikacji w symulatorach.

    Takie obrazowanie występuje w kilku różnych formach. Po pierwsze, można napisać moduły kodu aplikacji, a następnie stworzyć platformę, która łączy się z nimi i zapewnia wizualną informację zwrotną na temat zachowania i wydajności jednostek. Po drugie, można wdrożyć ww. na sprzęcie do symulacji, co pozwoli uzyskać ogólne dane względem systemu i zbadać jego funkcjonowanie. Te dwie pierwsze opcje bazują na implementacji. Ostatnią metodą symulacji jest użycie narzędzia do stworzenia modelu opracowywanej architektury. Instrumenty takowe mogą często obrazować całość i weryfikować działanie. Czasami modele te mogą nawet generować kod, który można wykorzystać na produkcji.

    Jako przykład zalet symulacji systemu, autor podaje układ, który sterował unikalnym elementem grzejnym. Całość miała zarządzać stanem grzejnika na podstawie kilku parametrów. Można by po prostu zakodować maszynę stanów i walczyć z nią, aby uzyskać prawidłowe jej zachowanie. Zamiast tego stworzony został model stanów i systemu, który nią steruje. Można by użyć go do przetestowania założeń dotyczących jego zachowania i przedstawienia skrajnych przypadków, aby zrozumieć wszelkie potrzebne zmiany architektoniczne. Kiedy działanie stało się jasne, możliwe było zaimplementowanie modelu, dzięki czemu w gotowym systemie wszystko funkcjonowało szybciej.

    5 kroków do zaprojektowania wbudowanej architektury oprogramowania - część 5


    Pokusy związane z architekturą oprogramowania wbudowanego

    Dobry architekt oprogramowania wie, że tworzony przez niego koncept będzie ewoluować. Dlatego całość musi utrzymywać szczegóły na wysokim poziomie, umożliwiając programistom wdrażanie jej według własnego uznania i potrzeb na dany moment. Jednak pewna pokusa dręczy każdego architekta czy programistę. Istnieje bowiem apetyt, aby zagłębić się w niskopoziomowe ujęcia dotyczące systemu i pozwolić im dyktować kształt całego projektu.

    Te chęci łatwo poprzeć konkretnym przykładem. Autor opisuje prowadzone przez siebie niedawno warsztaty dotyczące tworzenia tzw. historii użytkowników (user stories). Próbując sformułować ją dla jakiejś funkcji, prawie każdy programista od razu zadawał pytania na przykład o to, który pin został użyty w mikrokontrolerze, czy był to GPIO, czy jakieś urządzenie podłączone przez I²C. Mieli myśleć o tym, jak użytkownik wchodzi w interakcję z systemem i jakie są jego potrzeby, a mimo to ich umysły natychmiast przeskoczyły do szczegółów implementacji, które były, szczerze mówiąc, nieistotne na poziomie definiowania user story.

    Ważną kwestią przy projektowaniu architektury jest odłożenie wszystkich detali niskiego poziomu, o których nie trzeba decydować teraz na później. Dla twórców oprogramowania wbudowanego ten pomysł jest bardzo często nie do zniesienia i nie pasuje do ich naturalnego sposobu myślenia... Programiści muszą zostać przeszkoleni, a ich percepcja dostosowana do pewnych paradygmatów, aby byli oni w stanie prawidłowo budować architektury systemów wbudowanych.

    Programiści! Nie ulegajcie pokusie! Pozwólcie swojej architekturze kierować implementacją, aby nie była ściśle powiązana i dyktowana przez nią. W przeciwnym razie okaże się, że projekt nie będzie ewoluować ani dobrze się skalować w przyszłości.

    Podsumowanie

    Nowoczesne oprogramowanie układowe dla złożonych systemów wymaga podziału architektury na niezależną i zależną od sprzętu. Tradycyjni twórcy często mają z tym problem. Walkę można do pewnego stopnia złagodzić, koncentrując się na zestawach danych systemów i pozwalając im dyktować kształt konceptu. Rezultatem jest często architektura oprogramowania lepiej powiązana z potrzebami użytkownika, dzięki czemu całość jest bardziej skalowalna i pozwala na ewolucję. Ponadto, starannie zaprojektowany system może wykorzystywać nowoczesne narzędzia, takie jak testy jednostkowe i symulacje. Tudzież może być bardzo przenośny.

    W pięciu artykułach tego cyklu przeanalizowane zostały proste kroki, które można wykonać, aby stworzyć architekturę oprogramowania systemu wbudowanego. Należy pamiętać, że treść ta dotyka tylko powierzchniowo całej tematyki, a jak często bywa, diabeł tkwi w szczegółach. Niemniej koncepcje te powinny pomóc w budowaniu coraz lepszego, czy też modernizacji istniejącego oprogramowania wbudowanego.

    Źródło: https://www.embedded.com/5-steps-to-designing-an-embedded-software-architecture-step-5/[/quote]

    Cool? Ranking DIY
    About Author
    ghost666
    Translator, editor
    Offline 
    Fizyk z wykształcenia. Po zrobieniu doktoratu i dwóch latach pracy na uczelni, przeszedł do sektora prywatnego, gdzie zajmuje się projektowaniem urządzeń elektronicznych i programowaniem. Od 2003 roku na forum Elektroda.pl, od 2008 roku członek zespołu redakcyjnego.
    ghost666 wrote 11498 posts with rating 9731, helped 157 times. Live in city Warszawa. Been with us since 2003 year.
  • Computer Controls