Dizains sistēmas līmenī. 1. daļa. No idejas līdz sistēmai

Sveiki visiem. Savā darbā bieži izmantoju sistēmu inženierijas principus un vēlos dalÄ«ties ar Å”o pieeju ar sabiedrÄ«bu.

Sistēmu inženierija - bez standartiem, bet vienkārÅ”i sakot, tas ir process, kurā tiek izstrādāta sistēma kā diezgan abstrakti komponenti, bez atsauces uz konkrētiem ierīču paraugiem. Å Ä« procesa laikā tiek noteiktas sistēmas komponentu Ä«paŔības un savienojumi starp tiem. Turklāt ir nepiecieÅ”ams, lai sistēma bÅ«tu konsekventa un optimāla un lai sistēma atbilstu prasÄ«bām. Å ajā apmācÄ«bā es parādÄ«Å”u sistēmu inženierijas metodes, izmantojot diezgan vienkārÅ”as piekļuves kontroles sistēmas (ACS) projektÄ“Å”anas piemēru.

Sākotnējās arhitektÅ«ras veidoÅ”ana

Kad sistēma, neatkarīgi no tā, tikai sāk attīstīties, mūsu galvās vai uz papīra parādās taisnstūri ar bultām. Šādi taisnstūri ir sastāvdaļas sistēmas. Un bultas ir savienojumi starp komponentiem. Un ļoti bieži mums nav laika sēdēt un domāt par to, kā visas mūsu definētās sastāvdaļas darbosies viena ar otru, un galu galā mēs sākam veidot kruķu kopu, izdomājot liekus dizainus.

Ir svarÄ«gi atcerēties, ka no sistēmas un tās arhitektÅ«ras viedokļa komponents ir diezgan abstrakta lieta. Piemēram, ja mÅ«su sistēmai ir mikrokontrolleris, tad arhitektÅ«ras lÄ«menÄ« mums ir svarÄ«gi tikai, lai tas bÅ«tu mikrokontrolleris, nevis STM32, Arduino vai Milander. Turklāt bieži vien mums nemaz nav skaidrs, kas Ä«sti bÅ«s sistēmā, un mēs vērÅ”amies pie sistēmu inženierijas, lai izstrādātu prasÄ«bas aprÄ«kojumam, programmatÅ«rai utt.

Mūsu piemērā ar ACS mēs mēģināsim formulēt tā mērķi. Tas mums palīdzēs noteikt tā sastāvdaļas. Tātad piekļuves kontroles sistēmas uzdevums ir ielaist telpā ierobežotu cilvēku loku. Tas ir, tā ir viedā atslēga. Līdz ar to mums ir pirmā sastāvdaļa - kaut kāda ierīce, kas aizslēdz un atslēdz durvis! Sauksim viņu Durvju atslēga

Kā mēs zinām, ka cilvēks var tikt iekŔā? Mēs nevēlamies likt sargu un pārbaudÄ«t pases, vai ne? Iedosim cilvēkiem Ä«paÅ”as kartes ar RFID tagiem, uz kurām ierakstÄ«sim unikālus ID vai citus datus, kas ļauj precÄ«zi identificēt personu. Pēc tam mums bÅ«s nepiecieÅ”ama ierÄ«ce, kas var nolasÄ«t Å”os tagus. Lieliski, mums ir vēl viens komponents, RFIDReader

ApskatÄ«sim vēlreiz, ko esam ieguvuÅ”i. RFIDReader nolasa dažus datus, piekļuves kontroles sistēma ar tiem kaut ko dara, un uz Ŕī pamata kaut kas tiek kontrolēts Durvju atslēga. Uzdosim Ŕādu jautājumu ā€“ kur glabāt to personu sarakstu, kurām ir piekļuves tiesÄ«bas? Labākais datu bāzē. Tāpēc mÅ«su sistēmai jāspēj nosÅ«tÄ«t pieprasÄ«jumus un apstrādāt atbildes no datu bāzes. Tātad mums ir vēl viena sastāvdaļa - DBHandler. Tātad, mēs esam saņēmuÅ”i ārkārtÄ«gi abstraktu, bet iesākumam pietiekamu sistēmas aprakstu. Mēs saprotam, kas tam ir jādara un kā tas darbojas.

PapÄ«ra vietā izmantoÅ”u System Composer speciālo rÄ«ku sistēmu arhitektÅ«ru modelÄ“Å”anai Simulink vidē un izveidoÅ”u 3 komponentes. IepriekÅ” es aprakstÄ«ju savienojumus starp Å”iem komponentiem, tāpēc nekavējoties savienosim tos:

Dizains sistēmas līmenī. 1. daļa. No idejas līdz sistēmai

Arhitektūras paplaŔināŔana

ApskatÄ«sim mÅ«su diagrammu. Å Ä·iet, ka viss ir kārtÄ«bā, bet patiesÄ«bā tā nav. Paskaties uz Å”o sistēmu no lietotāja viedokļa ā€“ lietotājs atnes karti lasÄ«tājam un...? Kā lietotājs zina, vai viņam ir atļauta vai liegta piekļuve? Par to viņam kaut kā jāpaziņo! Tāpēc pievienosim vēl vienu komponentu - lietotāja paziņojumu, UserNotify:

Dizains sistēmas līmenī. 1. daļa. No idejas līdz sistēmai

Tagad pāriesim uz zemāku abstrakcijas lÄ«meni. Mēģināsim nedaudz sÄ«kāk aprakstÄ«t dažus komponentus. Sāksim ar komponentu RFIDReader. MÅ«su sistēmā Å”is komponents ir atbildÄ«gs par RFID marķējuma nolasÄ«Å”anu. Tās izvadē jāietver daži dati (UID, lietotāja dati...). Bet pagaidiet, RFID, tāpat kā NFC, galvenokārt ir aparatÅ«ra, nevis programmatÅ«ra! Tāpēc mēs varam pieņemt, ka mums atseviŔķi ir pati RFID mikroshēma, kas pārsÅ«ta ā€œneapstrādātusā€ datus uz sava veida priekÅ”procesoru. Tātad, mums ir abstrakta aparatÅ«ra, kas var nolasÄ«t RFID tagus, un abstrakta programmatÅ«ra, kas var pārvērst datus vajadzÄ«gajā formātā. Sauksim viņus RFIDsensors Šø RFIDParser attiecÄ«gi. Kā to parādÄ«t System Composer? JÅ«s varat noņemt komponentu RFIDReader un tā vietā ievietojiet divus komponentus, taču labāk to nedarÄ«t, pretējā gadÄ«jumā mēs zaudēsim arhitektÅ«ras lasāmÄ«bu. Tā vietā ieejam RFIDReader un pievienosim 2 jaunus komponentus:

Dizains sistēmas līmenī. 1. daļa. No idejas līdz sistēmai

Lieliski, tagad pāriesim pie lietotāja paziņoÅ”anas. Kā sistēma informēs lietotāju, ka viņam ir liegta vai atļauta piekļuve telpām? Cilvēks vislabāk uztver skaņas un kaut ko mirgojoÅ”u. Tāpēc jÅ«s varat izdot noteiktu skaņas signālu, lai lietotājs pievērstu uzmanÄ«bu, un mirgot LED. Pievienosim atbilstoŔās sastāvdaļas UserNotify:

Dizains sistēmas līmenī. 1. daļa. No idejas līdz sistēmai

Mēs esam izveidojuÅ”i savas sistēmas arhitektÅ«ru, taču ar to kaut kas nav kārtÄ«bā. Kas? ApskatÄ«sim savienojumu nosaukumus. InBus Šø OutBus - ne gluži normāli nosaukumi, kas palÄ«dzētu izstrādātājam. Tie ir jāpārdēvē:

Dizains sistēmas līmenī. 1. daļa. No idejas līdz sistēmai

Tātad, mēs apskatÄ«jām, kā sistēmu inženierijas metodes tiek izmantotas vislielākajā tuvinājumā. Rodas jautājums: kāpēc tos vispār lietot? Sistēma ir primitÄ«va, un Ŕķiet, ka padarÄ«tais darbs ir lieks. JÅ«s varētu nekavējoties rakstÄ«t kodu, izveidot datubāzi, rakstÄ«t vaicājumus vai lodēt. Problēma ir tāda, ka, ja jÅ«s nepārdomājat sistēmu un nesaprotat, kā tās komponenti ir savienoti viens ar otru, tad sistēmas komponentu integrācija prasÄ«s ilgu laiku un bÅ«s diezgan sāpÄ«ga.

Šīs daļas galvenā iezīme ir:

Sistēmu inženierijas metožu un arhitektÅ«ras modelÄ“Å”anas izmantoÅ”ana sistēmu izstrādē ļauj samazināt komponentu integrÄ“Å”anas izmaksas un uzlabot izstrādātās sistēmas kvalitāti.

Avots: www.habr.com

Pievieno komentāru