Cześć wszystkim. W swojej pracy często stosuję zasady inżynierii systemów i chciałbym podzielić się tym podejściem ze społecznością.
Inżynieria systemów - bez standardów, ale najprościej mówiąc, jest to proces tworzenia systemu jako dość abstrakcyjnych komponentów, bez odniesienia do konkretnych próbek urządzeń. Podczas tego procesu ustalane są właściwości elementów systemu i powiązania pomiędzy nimi. Dodatkowo konieczne jest, aby system był spójny i optymalny oraz spełniał stawiane wymagania. W tym tutorialu pokażę techniki inżynierii systemów na przykładzie projektowania dość prostego systemu kontroli dostępu (ACS).
Tworzenie początkowej architektury
Kiedy jakikolwiek system dopiero zaczyna się rozwijać, w naszych głowach lub na papierze pojawiają się prostokąty ze strzałkami. Takie prostokąty są składniki systemy. I strzałki są połączenia pomiędzy komponentami. Bardzo często nie mamy czasu, aby usiąść i pomyśleć o tym, jak wszystkie zdefiniowane przez nas komponenty będą ze sobą współpracować, i w końcu zaczynamy tworzyć kilka kul, wymyślając zbędne projekty.
Należy pamiętać, że z punktu widzenia systemu i jego architektury komponent jest rzeczą dość abstrakcyjną. Przykładowo jeśli nasz system posiada mikrokontroler, to na poziomie architektury ważne jest dla nas tylko to, żeby był to mikrokontroler, a nie żeby był to STM32, Arduino czy Milander. Co więcej, często nie jest dla nas jasne, co dokładnie będzie w systemie, i zwracamy się do inżynierii systemów, aby opracować wymagania dotyczące sprzętu, oprogramowania itp.
Na naszym przykładzie z ACS spróbujemy sformułować jego cel. Pomoże nam to w identyfikacji jego elementów. Zadaniem systemu kontroli dostępu jest więc wpuszczenie do pomieszczenia ograniczonego kręgu osób. Oznacza to, że jest to inteligentny zamek. W rezultacie mamy pierwszy element - jakieś urządzenie, które zamyka i odblokowuje drzwi! Zadzwońmy do niego Zamek od drzwi
Skąd wiemy, że dana osoba może dostać się do środka? Nie chcemy stawiać stróża i sprawdzać paszportów, prawda? Dajmy ludziom specjalne karty z tagami RFID, na których zapiszemy unikalne identyfikatory lub inne dane, które pozwolą nam dokładnie zidentyfikować osobę. Następnie będziemy potrzebować urządzenia, które będzie w stanie odczytać te znaczniki. Świetnie, mamy jeszcze jeden element, Czytnik RFID
Spójrzmy jeszcze raz na to, co otrzymaliśmy. Czytnik RFID odczytuje jakieś dane, system kontroli dostępu coś z nimi robi i na tej podstawie coś jest kontrolowane Zamek od drzwi. Zadajmy sobie pytanie - gdzie przechowywać listę osób z uprawnieniami dostępu? Najlepiej w bazie danych. Dlatego nasz system musi mieć możliwość wysyłania żądań i przetwarzania odpowiedzi z bazy danych. Mamy więc jeszcze jeden element - DBHandler. Otrzymaliśmy więc niezwykle abstrakcyjny, ale wystarczający na początek opis systemu. Rozumiemy, co ma robić i jak działa.
Zamiast kartki papieru użyję System Composer, specjalnego narzędzia do modelowania architektur systemów w środowisku Simulink i stworzę 3 komponenty. Powyżej opisałem połączenia pomiędzy tymi elementami, więc od razu je połączmy:
Rozbudowa architektury
Spójrzmy na nasz diagram. Wydaje się, że wszystko jest w porządku, ale w rzeczywistości tak nie jest. Spójrz na ten system z punktu widzenia użytkownika - użytkownik przykłada kartę do czytnika i...? Skąd użytkownik wie, czy ma zezwolenie na dostęp, czy odmowę? Trzeba go o tym jakoś powiadomić! Dodajmy zatem jeszcze jeden komponent – powiadomienie użytkownika, Powiadom użytkownika:
Zejdźmy teraz na niższy poziom abstrakcji. Spróbujmy opisać niektóre elementy nieco bardziej szczegółowo. Zacznijmy od komponentu Czytnik RFID. W naszym systemie komponent ten odpowiada za odczyt znacznika RFID. Jego dane wyjściowe powinny zawierać pewne dane (UID, dane użytkownika...). Ale czekaj, RFID, podobnie jak NFC, to przede wszystkim sprzęt, a nie oprogramowanie! Można zatem założyć, że osobno mamy sam chip RFID, który przekazuje „surowe” dane do pewnego rodzaju preprocesora. Mamy więc abstrakcyjny sprzęt, który może odczytywać znaczniki RFID i abstrakcyjne oprogramowanie, które może konwertować dane do potrzebnego nam formatu. Zadzwońmy do nich Czujnik RFID и Parser RFID odpowiednio. Jak wyświetlić to w System Composer? Możesz usunąć komponent Czytnik RFID i zamiast tego wstaw dwa komponenty, ale lepiej tego nie robić, bo inaczej stracimy czytelność architektury. Zamiast tego wejdźmy do środka RFIDReader i dodajmy 2 nowe komponenty:
Świetnie, teraz przejdźmy do powiadamiania użytkownika. W jaki sposób system powiadomi użytkownika o odmowie lub umożliwieniu mu dostępu do lokalu? Człowiek najlepiej odbiera dźwięki i coś, co mruga. Można zatem wydać określony sygnał dźwiękowy, aby użytkownik zwrócił uwagę i mrugnęła dioda LED. Dodajmy do tego odpowiednie komponenty Powiadom użytkownika:
Stworzyliśmy architekturę naszego systemu, ale coś jest z nią nie tak. Co? Spójrzmy na nazwy połączeń. W autobusie и Autobus wyjściowy - niezbyt normalne nazwy, które pomogłyby programiście. Należy zmienić ich nazwę:
Przyjrzeliśmy się więc, w najbardziej przybliżonym przybliżeniu, w jaki sposób metody inżynierii systemów są stosowane. Powstaje pytanie: po co w ogóle z nich korzystać? System jest prymitywny i wydaje się, że wykonana praca jest zbędna. Można było od razu pisać kod, projektować bazę danych, pisać zapytania czy lutować. Problem w tym, że jeśli nie przemyślisz systemu i nie zrozumiesz, w jaki sposób jego komponenty są ze sobą połączone, to integracja komponentów systemu zajmie dużo czasu i będzie dość bolesna.
Najważniejszy wniosek z tej części to:
Zastosowanie metod inżynierii systemów i modelowania architektury w tworzeniu systemów pozwala na obniżenie kosztów integracji komponentów i poprawę jakości tworzonego systemu.
Źródło: www.habr.com