Hæ allir. Ég beiti oft kerfisverkfræðireglum í starfi mínu og langar að deila þessari nálgun með samfélaginu.
Kerfisverkfræði - án staðla, en einfaldlega sagt, það er ferlið við að þróa kerfi sem nokkuð óhlutbundna íhluti, án tilvísunar til sérstakra tækjasýna. Meðan á þessu ferli stendur koma eiginleikar kerfishluta og tengingar á milli þeirra. Auk þess er nauðsynlegt að gera kerfið stöðugt og ákjósanlegt og að kerfið uppfylli kröfur. Í þessari kennslu mun ég sýna kerfisverkfræðitækni með því að nota dæmi um að hanna frekar einfalt aðgangsstýringarkerfi (ACS).
Mynda upphaflega arkitektúrinn
Þegar kerfi, sama hvað, byrjar að þróast, birtast rétthyrningar með örvum í höfðinu á okkur eða á pappír. Slíkir rétthyrningar eru hluti kerfi. Og örvarnar eru соединения á milli íhluta. Og mjög oft höfum við ekki tíma til að sitja og hugsa um hvernig allir þættirnir sem við höfum skilgreint munu vinna saman, og á endanum byrjum við að búa til fullt af hækjum og koma með óþarfa hönnun.
Það er mikilvægt að muna að frá sjónarhóli kerfisins og byggingarlistar þess er hluti frekar óhlutbundinn hlutur. Til dæmis, ef kerfið okkar er með örstýringu, þá er á byggingarstigi aðeins mikilvægt fyrir okkur að það sé örstýringur, en ekki að það sé STM32, Arduino eða Milander. Þar að auki er okkur oft alls ekki ljóst hvað nákvæmlega verður í kerfinu og við snúum okkur að kerfisfræði til að þróa kröfur um búnað, hugbúnað o.fl.
Fyrir dæmi okkar með ACS munum við reyna að móta tilgang þess. Þetta mun hjálpa okkur að bera kennsl á hluti þess. Þannig að verkefni aðgangsstýringarkerfisins er að hleypa takmörkuðum hópi fólks inn í herbergið. Það er, það er snjall læsing. Þar af leiðandi höfum við fyrsta íhlutinn - einhvers konar tæki sem læsir og opnar hurðina! Við skulum hringja í hann Hurðarlás
Hvernig vitum við að maður kemst inn? Við viljum ekki setja varðmann og athuga vegabréf, er það? Gefum fólki sérstök kort með RFID merkjum, sem við munum skrá einstök auðkenni eða önnur gögn sem gera okkur kleift að bera kennsl á mann nákvæmlega. Þá þurfum við eitthvað tæki sem getur lesið þessi merki. Frábært, við erum með einn íhlut í viðbót, RFIDreader
Við skulum líta aftur á það sem við fengum. RFIDreader les einhver gögn, aðgangsstýringarkerfið gerir eitthvað með þau og á grundvelli þess er einhverju stýrt Hurðarlás. Spyrjum eftirfarandi spurningar - hvar á að geyma listann yfir fólk með aðgangsrétt? Best í gagnagrunni. Þess vegna verður kerfið okkar að geta sent beiðnir og unnið úr svörum úr gagnagrunninum. Svo við höfum einn þátt í viðbót - DBHandler. Þannig að við höfum fengið afar óhlutbundna, en nægilega til að byrja með, lýsingu á kerfinu. Við skiljum hvað það á að gera og hvernig það virkar.
Í stað blaðs mun ég nota System Composer, sérstakt tól til að móta kerfisarkitektúr í Simulink umhverfinu, og búa til 3 hluti. Hér að ofan lýsti ég tengingunum á milli þessara íhluta, svo við skulum tengja þá strax:
Að stækka arkitektúrinn
Við skulum skoða skýringarmyndina okkar. Það virðist sem allt sé í lagi, en í raun er það ekki. Horfðu á þetta kerfi frá sjónarhóli notandans - notandinn kemur með kortið til lesandans og...? Hvernig veit notandi hvort honum er heimilt eða neitað um aðgang? Það þarf einhvern veginn að láta hann vita af þessu! Þess vegna skulum við bæta við einum þætti í viðbót - notendatilkynning, Notandi Tilkynning:
Nú skulum við fara niður á lægra stigi abstrakt. Við skulum reyna að lýsa sumum íhlutum aðeins nánar. Við skulum byrja á þættinum RFIDreader. Í kerfinu okkar er þessi hluti ábyrgur fyrir því að lesa RFID merkið. Úttak hennar ætti að innihalda nokkur gögn (UID, notendagögn...). En bíddu, RFID, eins og NFC, er fyrst og fremst vélbúnaður, ekki hugbúnaður! Þess vegna getum við gert ráð fyrir að við séum sérstaklega með RFID-kubbinn sjálfan, sem sendir „hrá“ gögn til einhvers konar forvinnslu. Þannig að við erum með óhlutbundinn vélbúnað sem getur lesið RFID merki og óhlutbundinn hugbúnað sem getur umbreytt gögnum í það snið sem við þurfum. Við skulum hringja í þá RFIDSensor и RFIDParser í sömu röð. Hvernig á að birta þetta í System Composer? Þú getur fjarlægt íhlut RFIDreader og settu tvo þætti í staðinn, en það er betra að gera þetta ekki, annars missum við læsileika arkitektúrsins. Í staðinn skulum við fara inn í RFIDReader og bæta við 2 nýjum hlutum:
Frábært, nú skulum við halda áfram að tilkynna notandanum. Hvernig mun kerfið tilkynna notandanum að honum sé neitað eða honum veittur aðgangur að húsnæðinu? Maður skynjar hljóð og eitthvað blikkandi best. Þess vegna geturðu gefið út ákveðið hljóðmerki þannig að notandinn fylgist með og blikka LED. Við skulum bæta viðeigandi íhlutum við Notandi Tilkynning:
Við höfum búið til arkitektúr kerfisins okkar, en það er eitthvað athugavert við það. Hvað? Við skulum líta á tengingarheitin. InBus и OutBus - ekki alveg eðlileg nöfn sem myndu hjálpa verktaki. Þeir þurfa að endurnefna:
Svo skoðuðum við hvernig kerfisverkfræðiaðferðum er beitt í grófustu nálgun. Spurningin vaknar: hvers vegna nota þau yfirleitt? Kerfið er frumstætt og svo virðist sem sú vinna sé óþörf. Þú gætir strax skrifað kóða, hannað gagnagrunn, skrifað fyrirspurnir eða lóðað. Vandamálið er að ef þú hugsar ekki í gegnum kerfið og skilur hvernig íhlutir þess eru tengdir hver öðrum, þá mun samþætting kerfishluta taka langan tíma og vera frekar sársaukafullt.
Aðalatriðið frá þessum hluta er:
Notkun kerfisverkfræðiaðferða og arkitektúrlíkana við kerfisþróun gerir manni kleift að draga úr kostnaði við að samþætta íhluti og bæta gæði þróaða kerfisins.
Heimild: www.habr.com