Бәріңе сәлем. Мен өз жұмысымда жүйелік инженерия принциптерін жиі қолданамын және осы тәсілді қоғамдастықпен бөліскім келеді.
Жүйелік инженерия - стандарттарсыз, бірақ қарапайым тілмен айтқанда, бұл нақты құрылғы үлгілеріне сілтеме жасамай, жеткілікті дерексіз компоненттер ретінде жүйені әзірлеу процесі. Бұл процесс барысында жүйе құрамдас бөліктерінің қасиеттері мен олардың арасындағы байланыстар орнатылады. Сонымен қатар, жүйені дәйекті және оңтайлы ету керек және жүйе талаптарға сай болуы керек. Бұл оқулықта мен қарапайым қол жеткізуді басқару жүйесін (ACS) жобалау мысалында жүйелік инженерия әдістерін көрсетемін.
Бастапқы архитектураны қалыптастыру
Жүйе, ештеңеге қарамастан, жай ғана дами бастағанда, біздің басымызда немесе қағазда көрсеткілері бар тіктөртбұрыштар пайда болады. Мұндай төртбұрыштар компоненттері жүйелер. Ал жебелер қосылымдар компоненттер арасында. Көбінесе біз анықтаған құрамдас бөліктердің бір-бірімен қалай жұмыс істейтіні туралы ойлауға уақытымыз болмайды, ал соңында біз артық дизайнды ойлап табатын балдақтарды жасай бастаймыз.
Жүйе және оның архитектурасы тұрғысынан компонент абстрактілі нәрсе екенін есте ұстаған жөн. Мысалы, егер біздің жүйеде микроконтроллер болса, онда архитектуралық деңгейде біз үшін STM32, Arduino немесе Milander емес, оның микроконтроллер екендігі маңызды. Оның үстіне, көбінесе жүйеде нақты не болатыны бізге мүлдем түсініксіз, және біз жабдыққа, бағдарламалық жасақтамаға және т.б. талаптарды әзірлеу үшін жүйелік инженерияға жүгінеміз.
ACS мысалында біз оның мақсатын тұжырымдауға тырысамыз. Бұл оның компоненттерін анықтауға көмектеседі. Сонымен, қол жеткізуді басқару жүйесінің міндеті - бөлмеге адамдардың шектеулі шеңберіне кіруге мүмкіндік беру. Яғни, бұл смарт құлып. Демек, бізде бірінші құрамдас бар - есікті бекітетін және құлпын ашатын қандай да бір құрылғы! Оны шақырайық Есік құлпы
Адамның ішке кіре алатынын қайдан білеміз? Біз күзетші қойып, төлқұжаттарды тексергіміз келмейді, солай ма? Адамдарға RFID тегтері бар арнайы карталарды берейік, оларда біз бірегей идентификаторларды немесе адамды дәл анықтауға мүмкіндік беретін басқа деректерді жазамыз. Содан кейін бізге осы тегтерді оқи алатын құрылғы қажет болады. Керемет, бізде тағы бір компонент бар, RFIDReader
Біз не алғанымызды тағы бір рет қарастырайық. RFIDReader кейбір деректерді оқиды, қол жеткізуді басқару жүйесі онымен бірдеңе жасайды және осының негізінде бір нәрсе басқарылады Есік құлпы. Келесі сұрақты қояйық - қол жеткізу құқығы бар адамдардың тізімін қайда сақтау керек? Дерекқордағы ең жақсы. Сондықтан біздің жүйе деректер базасынан сұрауларды жіберіп, жауаптарды өңдей алуы керек. Сонымен, бізде тағы бір компонент бар - DBHandler. Сонымен, біз жүйенің өте дерексіз, бірақ бастау үшін жеткілікті сипаттамасын алдық. Біз оның не істеу керектігін және оның қалай жұмыс істейтінін түсінеміз.
Қағаздың орнына Simulink ортасында жүйелік архитектураларды модельдеуге арналған арнайы құрал - System Composer қолданбасын қолданып, 3 компонент жасаймын. Жоғарыда мен осы компоненттер арасындағы байланыстарды сипаттадым, сондықтан оларды дереу байланыстырайық:
Архитектураны кеңейту
Диаграммамызды қарастырайық. Бәрі жақсы сияқты, бірақ іс жүзінде олай емес. Бұл жүйені пайдаланушының көзқарасымен қараңыз - пайдаланушы картаны оқырманға әкеледі және...? Пайдаланушы рұқсат етілгенін немесе рұқсат берілмегенін қалай біледі? Бұл туралы оған қандай да бір түрде хабарлау керек! Сондықтан тағы бір компонентті қосайық - пайдаланушы хабарландыруы, UserNotify:
Енді абстракцияның төменгі деңгейіне көшейік. Кейбір компоненттерді толығырақ сипаттауға тырысайық. Компоненттен бастайық RFIDReader. Біздің жүйеде бұл компонент RFID тегін оқуға жауап береді. Оның шығысында кейбір деректер болуы керек (UID, пайдаланушы деректері...). Бірақ күтіңіз, RFID, NFC сияқты, бағдарламалық құрал емес, ең алдымен аппараттық құрал болып табылады! Сондықтан бізде «шикі» деректерді препроцессордың қандай да бір түріне жіберетін RFID чипінің өзі бөлек бар деп болжауға болады. Сонымен, бізде RFID тегтерін оқи алатын абстрактілі аппараттық құрал және деректерді бізге қажетті пішімге түрлендіретін дерексіз бағдарламалық құрал бар. Оларды шақырайық RFIDсенсор и RFIParser тиісінше. Мұны System Composer бағдарламасында қалай көрсетуге болады? Компонентті жоюға болады RFIDReader және орнына екі компонентті қойыңыз, бірақ мұны жасамағаныңыз жөн, әйтпесе архитектураның оқылу мүмкіндігін жоғалтамыз. Оның орнына RFIDReader ішіне кіріп, 2 жаңа құрамдас қосайық:
Керемет, енді пайдаланушыны хабардар етуге көшейік. Жүйе пайдаланушыға үй-жайға кіруге тыйым салынғаны немесе рұқсат етілгені туралы қалай хабарлайды? Адам дыбыстарды және жыпылықтаған нәрсені жақсы қабылдайды. Сондықтан, пайдаланушы назар аударуы үшін белгілі бір дыбыстық сигнал бере аласыз және жарық диоды жыпылықтайды. Сәйкес компоненттерді қосамыз UserNotify:
Біз жүйенің архитектурасын жасадық, бірақ онда бірдеңе дұрыс емес. Не? Қосылым атауларына назар аударайық. Автобус ішінде и OutBus - әзірлеушіге көмектесетін қалыпты атаулар емес. Олардың атын өзгерту керек:
Сонымен, біз жүйелік инженерия әдістерінің ең өрескел жуықтауда қалай қолданылатынын қарастырдық. Сұрақ туындайды: неге оларды мүлдем пайдалану керек? Жүйе қарабайыр, атқарылған жұмыс қажетсіз сияқты. Сіз бірден код жаза аласыз, дерекқорды жасай аласыз, сұраулар жаза аласыз немесе дәнекерлей аласыз. Мәселе мынада, егер сіз жүйе туралы ойланбасаңыз және оның құрамдас бөліктері бір-бірімен қалай байланысты екенін түсінбесеңіз, жүйе құрамдастарын біріктіру ұзақ уақытты алады және өте ауыр болады.
Бұл бөліктен алынған негізгі нәтиже:
Жүйені әзірлеуде жүйелік инженерия әдістерін және архитектураны модельдеуді қолдану компоненттерді біріктіру шығындарын азайтуға және әзірленген жүйенің сапасын жақсартуға мүмкіндік береді.
Ақпарат көзі: www.habr.com