Saluton al ĉiuj. Mi ofte aplikas sistemajn inĝenierajn principojn en mia laboro kaj ŝatus kunhavigi ĉi tiun aliron kun la komunumo.
Sisteminĝenieristiko - sen normoj, sed simple dirite, ĝi estas la procezo de evoluigado de sistemo kiel sufiĉe abstraktaj komponentoj, sen referenco al specifaj aparatprovaĵoj. Dum ĉi tiu procezo, la propraĵoj de la sistemaj komponantoj kaj la ligoj inter ili estas establitaj. Aldone, necesas fari la sistemon konsekvenca kaj optimuma kaj ke la sistemo plenumas la postulojn. En ĉi tiu lernilo mi montros sistemajn inĝenierajn teknikojn uzante la ekzemplon de desegnado de sufiĉe simpla alirkontrola sistemo (ACS).
Formante la komencan arkitekturon
Kiam sistemo, negrave kio, nur komencas disvolviĝi, rektanguloj kun sagoj aperas en niaj kapoj aŭ sur papero. Tiaj rektanguloj estas Komponentoj sistemoj. Kaj la sagoj estas ligoj inter komponantoj. Kaj tre ofte ni ne havas tempon por sidi kaj pensi pri kiel ĉiuj komponantoj, kiujn ni difinis, funkcios unu kun la alia, kaj fine ni komencas krei amason da lambastonoj, elpensante superfluajn dezajnojn.
Gravas memori, ke el la vidpunkto de la sistemo kaj ĝia arkitekturo, komponanto estas sufiĉe abstrakta afero. Ekzemple, se nia sistemo havas mikroregilon, tiam ĉe la arkitektura nivelo nur gravas por ni, ke ĝi estas mikroregilo, kaj ne ke ĝi estas STM32, Arduino aŭ Milander. Krome, ofte estas tute ne klare al ni, kio precize estos en la sistemo, kaj ni turnas nin al sistema inĝenierado por evoluigi postulojn por ekipaĵo, programaro ktp.
Por nia ekzemplo kun ACS, ni provos formuli ĝian celon. Ĉi tio helpos nin identigi ĝiajn komponantojn. Do, la tasko de la alirkontrola sistemo estas permesi limigitan cirklon de homoj en la ĉambron. Tio estas, ĝi estas inteligenta seruro. Sekve, ni havas la unuan komponanton - ian aparaton, kiu ŝlosas kaj malŝlosas la pordon! Ni voku lin Pordoŝlosilo
Kiel ni scias, ke homo povas eniri? Ni ne volas meti gardiston kaj kontroli pasportojn, ĉu ne? Ni donu al homoj specialajn kartojn kun RFID-etikedoj, sur kiuj ni registros unikajn identigilojn aŭ aliajn datumojn, kiuj ebligas al ni precize identigi homon. Tiam, ni bezonos iun aparaton kiu povas legi ĉi tiujn etikedojn. Bonege, ni havas unu plian komponanton, RFIDReader
Ni rigardu denove kion ni ricevis. RFIDReader legas iujn datumojn, la sistemo de alirkontrolo faras ion per ĝi, kaj surbaze de tio io estas regata Pordoŝlosilo. Ni faru la sekvan demandon - kie stoki la liston de homoj kun alirrajtoj? Plej bona en datumbazo. Tial, nia sistemo devas povi sendi petojn kaj prilabori respondojn de la datumbazo. Do ni havas unu plian komponanton - DBHandler. Do, ni ricevis ege abstraktan, sed sufiĉan por komenci, priskribon de la sistemo. Ni komprenas, kion ĝi devas fari kaj kiel ĝi funkcias.
Anstataŭ papero, mi uzos System Composer, specialan ilon por modeli sistemajn arkitekturojn en la medio Simulink, kaj kreos 3 komponantojn. Supre mi priskribis la ligojn inter ĉi tiuj komponantoj, do ni tuj ligu ilin:
Pligrandigante la arkitekturon
Ni rigardu nian diagramon. Ŝajnas, ke ĉio estas en ordo, sed fakte ne estas. Rigardu tiun ĉi sistemon el la vidpunkto de la uzanto - la uzanto alportas la karton al la leganto kaj...? Kiel uzanto scias ĉu al ili estas permesita aŭ malpermesata aliro? Necesas iel sciigi lin pri tio! Sekve, ni aldonu unu plian komponenton - uzantan sciigon, UserNotify:
Nun ni iru malsupren al pli malalta nivelo de abstraktado. Ni provu priskribi kelkajn komponantojn iom pli detale. Ni komencu kun la komponanto RFIDReader. En nia sistemo, ĉi tiu komponanto respondecas pri legado de la RFID-etikedo. Ĝia eligo devus enhavi kelkajn datumojn (UID, uzantdatenoj...). Sed atendu, RFID, kiel NFC, estas ĉefe aparataro, ne programaro! Tial ni povas supozi, ke ni aparte havas la RFID-peceton mem, kiu transdonas "krudajn" datumojn al ia antaŭprocesoro. Do ni havas abstraktan aparataron, kiu povas legi RFID-etikedojn, kaj abstraktan programaron, kiu povas konverti datumojn en la formaton, kiun ni bezonas. Ni voku ilin RFIDSensor и RFIDParser respektive. Kiel montri ĉi tion en System Composer? Vi povas forigi komponanton RFIDReader kaj metu du komponantojn anstataŭe, sed estas pli bone ne fari tion, alie ni perdos la legeblecon de la arkitekturo. Anstataŭe, ni eniru RFIDReader kaj aldonu 2 novajn komponantojn:
Bonege, nun ni daŭrigu sciigi la uzanton. Kiel la sistemo sciigos la uzanton, ke li estas rifuzita aŭ permesita aliro al la loko? Homo perceptas sonojn kaj ion palpebrumantan plej bone. Sekve, vi povas elsendi certan sonsignalon por ke la uzanto atentu, kaj palpebrumi la LED. Ni aldonu la taŭgajn komponantojn al UserNotify:
Ni kreis la arkitekturon de nia sistemo, sed estas io malĝusta kun ĝi. Kio? Ni rigardu la nomojn de konekto. InBus и Eksterbuso - ne tute normalaj nomoj, kiuj helpus la programiston. Ili devas esti renomitaj:
Do, ni rigardis kiel sistemajn inĝenierajn metodojn estas aplikataj en la plej malglata aproksimado. Estiĝas la demando: kial uzi ilin entute? La sistemo estas primitiva, kaj ŝajnas, ke la laboro farita estas nenecesa. Vi povus tuj skribi kodon, desegni datumbazon, skribi demandojn aŭ luti. La problemo estas, ke se vi ne pensas tra la sistemo kaj komprenas kiel ĝiaj komponantoj estas konektitaj unu al la alia, tiam la integriĝo de sistemaj komponantoj daŭros longan tempon kaj estos sufiĉe dolora.
La ĉefa eliro el ĉi tiu parto estas:
La uzo de sistemaj inĝenieraj metodoj kaj arkitekturmodeligado en sistemdisvolviĝo permesas redukti la kostojn de integrigado de komponentoj kaj plibonigi la kvaliton de la evoluinta sistemo.
fonto: www.habr.com