Здраво свима. Често примењујем принципе системског инжењеринга у свом раду и желео бих да поделим овај приступ са заједницом.
Системски инжењеринг – без стандарда, али једноставно речено, то је процес развоја система као прилично апстрактних компоненти, без позивања на специфичне узорке уређаја. Током овог процеса успостављају се својства компоненти система и везе између њих. Додатно, неопходно је да систем буде конзистентан и оптималан и да систем испуњава захтеве. У овом туторијалу показаћу технике системског инжењеринга на примеру пројектовања прилично једноставног система контроле приступа (АЦС).
Формирање почетне архитектуре
Када систем, без обзира на све, тек почне да се развија, правоугаоници са стрелицама се појављују у нашим главама или на папиру. Такви правоугаоници су компоненте система. А стрелице су везе између компоненти. И врло често немамо времена да седимо и размишљамо о томе како ће све компоненте које смо дефинисали функционисати једна са другом, и на крају почињемо да стварамо гомилу штака, смишљајући сувишне дизајне.
Важно је запамтити да је са становишта система и његове архитектуре компонента прилично апстрактна ствар. На пример, ако наш систем има микроконтролер, онда нам је на архитектонском нивоу важно само да је микроконтролер, а не да је СТМ32, Ардуино или Миландер. Штавише, често нам уопште није јасно шта ће тачно бити у систему, па се обраћамо системском инжењерингу да бисмо развили захтеве за опрему, софтвер итд.
За наш пример са АЦС-ом, покушаћемо да формулишемо његову сврху. Ово ће нам помоћи да идентификујемо његове компоненте. Дакле, задатак система контроле приступа је да дозволи ограниченом кругу људи у просторију. То јест, то је паметна брава. Сходно томе, имамо прву компоненту - неку врсту уређаја који закључава и откључава врата! Хајде да га позовемо Брава
Како знамо да особа може ући унутра? Не желимо да ставимо чувара и проверавамо пасоше, зар не? Дајемо људима посебне картице са РФИД ознакама, на које ћемо бележити јединствене ИД-ове или друге податке који нам омогућавају да тачно идентификујемо особу. Затим ће нам требати неки уређај који може читати ове ознаке. Одлично, имамо још једну компоненту, РФИДРеадер
Погледајмо поново шта смо добили. РФИДРеадер чита неке податке, систем контроле приступа нешто ради са њима и на основу тога се нешто контролише Брава. Хајде да поставимо следеће питање – где да чувамо листу људи са правима приступа? Најбољи у бази података. Због тога наш систем мора бити у стању да шаље захтеве и обрађује одговоре из базе података. Дакле, имамо још једну компоненту - ДБХандлер. Дакле, добили смо изузетно апстрактан, али довољан за почетак, опис система. Разумемо шта би требало да ради и како функционише.
Уместо парчета папира, користићу Систем Цомпосер, специјални алат за моделовање системских архитектура у окружењу Симулинк, и креираћу 3 компоненте. Горе сам описао везе између ових компоненти, па хајде да их одмах повежемо:
Проширивање архитектуре
Погледајмо наш дијаграм. Чини се да је све у реду, али у стварности није. Погледајте овај систем из угла корисника – корисник доноси картицу читачу и...? Како корисник зна да ли му је дозвољен или одбијен приступ? Треба га некако обавестити о томе! Стога, додајмо још једну компоненту - обавештење корисника, УсерНотифи:
Хајде сада да се спустимо на нижи ниво апстракције. Покушајмо да опишемо неке компоненте мало детаљније. Почнимо са компонентом РФИДРеадер. У нашем систему, ова компонента је одговорна за читање РФИД ознаке. Његов излаз треба да садржи неке податке (УИД, кориснички подаци...). Али чекајте, РФИД, као и НФЦ, је првенствено хардвер, а не софтвер! Дакле, можемо претпоставити да одвојено имамо и сам РФИД чип, који преноси „сирове“ податке у неку врсту претпроцесора. Дакле, имамо апстрактни комад хардвера који може да чита РФИД ознаке и апстрактни софтвер који може да конвертује податке у формат који нам је потребан. Хајде да их позовемо РФИДсенсор и РФИДПарсер редом. Како то приказати у Систем Цомпосер-у? Можете уклонити компоненту РФИДРеадер и уместо њих ставите две компоненте, али је боље да то не радите, иначе ћемо изгубити читљивост архитектуре. Уместо тога, хајде да уђемо у РФИДРеадер и додамо 2 нове компоненте:
Одлично, сада пређимо на обавештавање корисника. Како ће систем обавестити корисника да му је забрањен или дозвољен приступ просторијама? Човек најбоље опажа звукове и нешто што трепће. Због тога можете издати одређени звучни сигнал тако да корисник обрати пажњу и треперити ЛЕД. Хајде да додамо одговарајуће компоненте у УсерНотифи:
Направили смо архитектуру нашег система, али нешто није у реду са њом. Шта? Погледајмо имена веза. ИнБус и ОутБус - не сасвим нормална имена која би помогла програмеру. Треба их преименовати:
Дакле, погледали смо како се методе системског инжењеринга примењују у најгрубљој апроксимацији. Поставља се питање: зашто их уопште користити? Систем је примитиван, а чини се да је урађени посао непотребан. Можете одмах написати код, дизајнирати базу података, писати упите или лемити. Проблем је у томе што ако не размислите о систему и не разумете како су његове компоненте повезане једна са другом, интеграција компоненти система ће трајати дуго и бити прилично болна.
Главни закључак из овог дела је:
Коришћење метода системског инжењеринга и моделирања архитектуре у развоју система омогућава смањење трошкова интеграције компоненти и побољшање квалитета развијеног система.
Извор: ввв.хабр.цом