Բարեւ բոլորին. Ես հաճախ կիրառում եմ համակարգերի ինժեներական սկզբունքները իմ աշխատանքում և կցանկանայի կիսվել այս մոտեցմամբ համայնքի հետ:
Համակարգերի ճարտարագիտություն - առանց ստանդարտների, բայց պարզ ասած, դա համակարգի մշակման գործընթացն է որպես բավականին վերացական բաղադրիչներ, առանց հատուկ սարքի նմուշների հղումների: Այս գործընթացի ընթացքում հաստատվում են համակարգի բաղադրիչների հատկությունները և նրանց միջև կապերը: Բացի այդ, անհրաժեշտ է համակարգը դարձնել հետևողական և օպտիմալ, և որ համակարգը համապատասխանի պահանջներին: Այս ձեռնարկում ես ցույց կտամ համակարգերի ինժեներական տեխնիկան՝ օգտագործելով բավականին պարզ մուտքի կառավարման համակարգի (ACS) նախագծման օրինակ:
Նախնական ճարտարապետության ձևավորում
Երբ համակարգը, անկախ ամեն ինչից, նոր է սկսում զարգանալ, մեր գլխում կամ թղթի վրա սլաքներով ուղղանկյուններ են հայտնվում: Այդպիսի ուղղանկյուններ են բաղադրիչները համակարգեր. Իսկ նետերն են կապեր բաղադրիչների միջև: Եվ շատ հաճախ մենք ժամանակ չունենք նստելու և մտածելու, թե մեր սահմանած բոլոր բաղադրիչները ինչպես են աշխատելու միմյանց հետ, և վերջում մենք սկսում ենք ստեղծել մի փունջ հենակներ՝ հանդես գալով ավելորդ դիզայնով։
Կարևոր է հիշել, որ համակարգի և նրա ճարտարապետության տեսանկյունից բաղադրիչը բավականին վերացական բան է։ Օրինակ, եթե մեր համակարգն ունի միկրոկոնտրոլեր, ապա ճարտարապետական մակարդակում մեզ համար միայն կարևոր է, որ դա միկրոկոնտրոլեր լինի, այլ ոչ թե այն լինի STM32, Arduino կամ Milander։ Ավելին, հաճախ մեզ համար բոլորովին պարզ չէ, թե կոնկրետ ինչ է լինելու համակարգում, և մենք դիմում ենք համակարգերի ճարտարագիտությանը՝ սարքավորումների, ծրագրերի և այլնի պահանջներ մշակելու համար։
ACS-ի հետ մեր օրինակի համար մենք կփորձենք ձևակերպել դրա նպատակը: Սա կօգնի մեզ բացահայտել դրա բաղադրիչները: Այսպիսով, մուտքի վերահսկման համակարգի խնդիրն է թույլ տալ մարդկանց սահմանափակ շրջանակ մուտք գործել սենյակ: Այսինքն՝ խելացի կողպեք է։ Հետևաբար, մենք ունենք առաջին բաղադրիչը` ինչ-որ սարք, որը կողպում և բացում է դուռը: Եկեք զանգենք նրան Դռան փական
Ինչպե՞ս գիտենք, որ մարդը կարող է ներս մտնել: Չե՞նք ուզում պահակ դնել և ստուգել անձնագրերը: Եկեք մարդկանց տանք RFID պիտակներով հատուկ քարտեր, որոնց վրա կգրանցենք եզակի ID-ներ կամ այլ տվյալներ, որոնք թույլ են տալիս ճշգրիտ նույնականացնել մարդուն։ Այնուհետև մեզ անհրաժեշտ կլինի մի սարք, որը կարող է կարդալ այս պիտակները: Հիանալի, մենք ունենք ևս մեկ բաղադրիչ, RFIDReader
Եկեք նորից նայենք, թե ինչ ենք ստացել։ RFIDReader կարդում է որոշ տվյալներ, մուտքի վերահսկման համակարգը դրա հետ ինչ-որ բան է անում, և դրա հիման վրա ինչ-որ բան վերահսկվում է Դռան փական. Տվենք հետևյալ հարցը՝ որտեղ պահել մուտքի իրավունք ունեցող մարդկանց ցուցակը։ Լավագույնը տվյալների բազայում: Հետևաբար, մեր համակարգը պետք է կարողանա տվյալների բազայից հարցումներ ուղարկել և մշակել պատասխանները: Այսպիսով, մենք ունենք ևս մեկ բաղադրիչ. DBHandler. Այսպիսով, մենք ստացել ենք համակարգի չափազանց վերացական, բայց սկսելու համար բավարար նկարագրություն։ Մենք հասկանում ենք, թե դա ինչ պետք է անի և ինչպես է այն աշխատում:
Թղթի փոխարեն ես կօգտագործեմ System Composer-ը՝ Simulink միջավայրում համակարգերի ճարտարապետությունները մոդելավորելու հատուկ գործիք, և կստեղծեմ 3 բաղադրիչ։ Վերևում ես նկարագրեցի այս բաղադրիչների միջև կապերը, ուստի եկեք անմիջապես կապենք դրանք.
Ընդլայնելով ճարտարապետությունը
Եկեք նայենք մեր դիագրամին: Թվում է, թե ամեն ինչ լավ է, բայց իրականում այդպես չէ։ Նայիր այս համակարգին օգտատիրոջ տեսանկյունից՝ օգտատերը քարտը բերում է ընթերցողին և... Ինչպե՞ս է օգտատերը իմանում՝ իրեն թույլատրված է կամ մերժված մուտքը: Պետք է ինչ-որ կերպ տեղեկացնել նրան այս մասին։ Հետևաբար, եկեք ավելացնենք ևս մեկ բաղադրիչ՝ օգտվողի ծանուցում, User Notify:
Հիմա եկեք իջնենք վերացականության ավելի ցածր մակարդակի։ Փորձենք մի փոքր ավելի մանրամասն նկարագրել որոշ բաղադրիչներ։ Սկսենք բաղադրիչից RFIDReader. Մեր համակարգում այս բաղադրիչը պատասխանատու է RFID թեգը կարդալու համար: Դրա ելքը պետք է պարունակի որոշ տվյալներ (UID, օգտվողի տվյալներ...): Բայց սպասեք, RFID-ը, ինչպես և NFC-ն, հիմնականում ապարատային է, ոչ թե ծրագրային: Հետևաբար, մենք կարող ենք ենթադրել, որ մենք առանձին ունենք ինքնին RFID չիպը, որը «հում» տվյալներ է փոխանցում ինչ-որ նախապրոցեսորին: Այսպիսով, մենք ունենք վերացական սարքաշար, որը կարող է կարդալ RFID պիտակները, և վերացական ծրագրակազմ, որը կարող է տվյալները փոխարկել մեզ անհրաժեշտ ձևաչափի: Եկեք նրանց կանչենք RFID սենսոր и RFIDParser համապատասխանաբար. Ինչպե՞ս ցուցադրել սա System Composer-ում: Դուք կարող եք հեռացնել բաղադրիչը RFIDReader և դրա փոխարեն տեղադրեք երկու բաղադրիչ, բայց ավելի լավ է դա չանել, հակառակ դեպքում մենք կկորցնենք ճարտարապետության ընթեռնելիությունը: Փոխարենը, եկեք մտնենք RFIDReader-ի ներսում և ավելացնենք 2 նոր բաղադրիչ.
Հիանալի է, հիմա եկեք անցնենք օգտվողին ծանուցելուն: Ինչպե՞ս է համակարգը ծանուցելու օգտատիրոջը, որ նրան թույլ չեն տալիս մուտք գործել տարածք: Մարդը լավագույնս ընկալում է ձայները և թարթող ինչ-որ բան: Հետևաբար, դուք կարող եք որոշակի ձայնային ազդանշան տալ, որպեսզի օգտագործողը ուշադրություն դարձնի և թարթել LED-ը: Ավելացնենք համապատասխան բաղադրիչները User Notify:
Մենք ստեղծել ենք մեր համակարգի ճարտարապետությունը, բայց ինչ-որ բան այն չէ։ Ինչ? Եկեք նայենք կապի անուններին: InBus и Արտագնա ավտոբուս - ոչ այնքան նորմալ անուններ, որոնք կօգնեն մշակողին: Նրանք պետք է վերանվանվեն.
Այսպիսով, մենք նայեցինք, թե ինչպես են կիրառվում համակարգերի ինժեներական մեթոդները ամենակոպիտ մոտավորությամբ: Հարց է առաջանում՝ ինչո՞ւ դրանք ընդհանրապես օգտագործել։ Համակարգը պարզունակ է, և թվում է, թե կատարված աշխատանքն ավելորդ է։ Դուք կարող եք անմիջապես գրել կոդը, նախագծել տվյալների բազա, գրել հարցումներ կամ զոդել: Խնդիրն այն է, որ եթե դուք չմտածեք համակարգի միջոցով և չհասկանաք, թե ինչպես են դրա բաղադրիչները կապված միմյանց հետ, ապա համակարգի բաղադրիչների ինտեգրումը երկար ժամանակ կպահանջի և բավականին ցավոտ կլինի:
Այս մասի հիմնական ելքը հետևյալն է.
Համակարգային ինժեներական մեթոդների և ճարտարապետության մոդելավորման օգտագործումը համակարգի զարգացման մեջ թույլ է տալիս նվազեցնել բաղադրիչների ինտեգրման ծախսերը և բարելավել մշակված համակարգի որակը:
Source: www.habr.com