Duke vazhduar temĂ«n , le ta shohim problemin e modelimit matematikor nga njĂ« kĂ«ndvĂ«shtrim tjetĂ«r. Pasi jemi bindur se modeli pĂ«rputhet me realitetin praktik, mund tâi pĂ«rgjigjemi pyetjes kryesore: «çfarĂ« kemi, nĂ« tĂ« vĂ«rtetĂ«, kĂ«tu?». Kur krijojmĂ« njĂ« model tĂ« njĂ« objekti teknik, zakonisht duam tĂ« sigurohemi qĂ« ky objekt do tĂ« pĂ«rmbushĂ« pritshmĂ«ritĂ« tona. PikĂ«risht pĂ«r kĂ«tĂ« kryhen llogaritjet dinamike tĂ« proceseve dhe rezultati krahasohet me kĂ«rkesat. Kjo Ă«shtĂ« ajo qĂ« quhet binjak dixhital, prototip virtual dhe koncepte tĂ« tjera moderne, tĂ« cilat nĂ« fazĂ«n e projektimit zgjidhin detyrĂ«n se si tĂ« arrijmĂ« pikĂ«risht atĂ« qĂ« kemi planifikuar.
Si mund të sigurohemi shpejt që sistemi ynë është pikërisht ai që po projektojmë, nëse konstruksioni ynë do të fluturojë apo do të notojë? Dhe nëse do të fluturojë, sa lart? E nëse do të notojë, sa thellë?
Në këtë artikull shqyrtohet automatizimi i verifikimit të përmbushjes së kërkesave të specifikimit teknik gjatë krijimit të modeleve dinamike të sistemeve teknike. Si shembull, do të shohim një element të specifikimit teknik për sistemin e ftohjes me ajër të një mjeti fluturues.
Po shqyrtojmĂ« ato kĂ«rkesa qĂ« mund tĂ« shprehen numerikisht dhe tĂ« verifikohen matematikisht mbi bazĂ«n e njĂ« modeli konkret llogaritĂ«s. ĂshtĂ« e qartĂ« se kjo Ă«shtĂ« vetĂ«m njĂ« pjesĂ« e kĂ«rkesave tĂ« pĂ«rgjithshme pĂ«r çdo sistem teknik, por pikĂ«risht pĂ«r verifikimin e tyre shpenzojmĂ« kohĂ«, energji dhe para pĂ«r krijimin e modeleve dinamike tĂ« objektit.
Gjatë përshkrimit të kërkesave teknike në formën e një dokumenti, mund të dallohen disa lloje kërkesash të ndryshme, secila prej të cilave kërkon qasje të ndryshme për krijimin e verifikimit automatik të përmbushjes së kërkesave.
Për shembull, le të shqyrtojmë këtë grup të vogël, por real, kërkesash:
- Temperatura e ajrit atmosferik në hyrje të SVO:
nĂ« qĂ«ndrim â nga minus 35 deri nĂ« 35 ÂșC,
nĂ« fluturim â nga minus 35 deri nĂ« 39 ÂșC. - Presioni statik i ajrit atmosferik gjatĂ« fluturimit â nga 700 deri nĂ« 1013 GPa (nga 526 deri nĂ« 760 mmHg).
- Presioni total i ajrit nĂ« hyrje tĂ« marrjes sĂ« ajrit tĂ« SVO gjatĂ« fluturimit â nga 754 deri nĂ« 1200 GPa (nga 566 deri nĂ« 1050 mmHg).
- Temperatura e ajrit ftohës:
nĂ« parkim â jo mĂ« shumĂ« se 27 ÂșĐĄ, pĂ«r blloqet teknike â jo mĂ« shumĂ« se 29 ÂșĐĄ,
nĂ« fluturim â jo mĂ« shumĂ« se 25 ÂșĐĄ, pĂ«r blloqet teknike â jo mĂ« shumĂ« se 27 ÂșĐĄ. - Konsumi i ajrit ftohĂ«s:
nĂ« parkim â jo mĂ« pak se 708 kg/orĂ«,
nĂ« fluturim â jo mĂ« pak se 660 kg/orĂ«. - Temperatura e ajrit nĂ« ndarjet e pajisjeve â jo mĂ« shumĂ« se 60 ÂșĐĄ.
- Sasia e lagĂ«shtisĂ« sĂ« lirĂ« me grimca tĂ« imĂ«ta nĂ« ajrin ftohĂ«s â jo mĂ« shumĂ« se 2 g/kg ajĂ«r i thatĂ«.
Edhe në një grup kaq të kufizuar kërkesash, mund të dallohen të paktën dy kategori që duhet të trajtohen ndryshe në sistem:
- kërkesat për kushtet e funksionimit të sistemit (pikat 1-3);
- kërkesat parametrike për sistemin (pikat 3-7).
Kërkesat për kushtet e funksionimit të sistemit
Kushtet e jashtme për sistemin që po zhvillohet, gjatë modelimit mund të përcaktohen si kushte kufitare ose si rezultat i funksionimit të sistemit të përgjithshëm.
Gjatë modelimit dinamik, është e nevojshme të verifikohet që regjimet e përcaktuara të funksionimit mbulohen nga procesi i modelimit.
Kërkesat parametrike për sistemin
Këto kërkesa përfaqësojnë parametrat që sigurohen nga vetë sistemi. Gjatë procesit të modelimit, ne mund t'i marrim këta parametra si rezultate të llogaritjes dhe të verifikojmë që kërkesat plotësohen në çdo llogaritje konkrete.
Identifikimi dhe kodimi i kërkesave
Për lehtësi në punën me kërkesat, standardet ekzistuese rekomandojnë caktimin e një identifikuesi për çdo kërkesë. Gjatë caktimit të identifikuesve, është shumë e dëshirueshme të përdoret një sistem i unifikuar kodimi.
Kodi i kërkesës mund të jetë thjesht një numër që pasqyron rendin e kërkesës, por mund të përmbajë edhe kodin e llojit të kërkesës, kodin e sistemit ose të agregatit ndaj të cilit zbatohet, kodin e parametrit, kodin e vendndodhjes dhe shumë elemente të tjera që një inxhinier mund të imagjinojë. (për një variant të përdorimit të kodimit, shihni artikullin)
Në tabelën 1 jepet një shembull i thjeshtë i kodimit të kërkesave.
- kodi i burimit të kërkesave R- kërkesat e specifikimit teknik;
- kodi i llojit tĂ« kĂ«rkesave E â kĂ«rkesat pĂ«r parametrat e mjedisit tĂ« jashtĂ«m, ose kushtet e funksionimit
S â kĂ«rkesat qĂ« sigurohen nga sistemi; - kodi i gjendjes sĂ« avionit 0 â çdo gjendje, G â nĂ« parkim, F â nĂ« fluturim;
- kodi i llojit tĂ« parametrave fizikĂ« T â temperatura, P â presioni, G â rrjedha, H â lagĂ«shtia;
- numri rendor i kërkesës.
| ID KĂ«rkesat | PĂ«rshkrimi | Parametri |
| REGT01 | Temperatura e ajrit atmosferik nĂ« hyrje tĂ« SVO: nĂ« tokĂ« â nga minus 35ÂșĐĄ deri nĂ« 35 ÂșĐĄ. | |
| REFT01 | Temperatura e ajrit atmosferik nĂ« hyrje tĂ« SVO: nĂ« fluturim â nga minus 35 ÂșĐĄ deri nĂ« 39 ÂșĐĄ. | |
| REFP01 | Presioni statik i ajrit atmosferik në fluturim nga 700 deri në 1013 gPa (nga 526 deri në 760 mm Hg). | |
| REFP02 | Presioni i plotë i ajrit në hyrje të marrësit të ajrit të SVO në fluturim nga 754 deri në 1200 gPa (nga 566 deri në 1050 mm Hg). | |
| RSGT01 | Temperatura e ajrit ftohĂ«s: nĂ« tokĂ« jo mĂ« shumĂ« se 27 ÂșĐĄ | |
| RSGT02 | Temperatura e ajrit ftohĂ«s: nĂ« tokĂ«, pĂ«r blloqet teknike jo mĂ« shumĂ« se 29 ÂșĐĄ | |
| RSFT01 | Temperatura e ajrit ftohĂ«s nĂ« fluturim jo mĂ« shumĂ« se 25 ÂșĐĄ | |
| RSFT02 | Temperatura e ajrit ftohĂ«s: nĂ« fluturim, pĂ«r blloqet teknike jo mĂ« shumĂ« se 27 ÂșĐĄ | |
| RSGG01 | Prurja e ajrit ftohës: në tokë jo më pak se 708 kg/orë | |
| RSFG01 | Prurja e ajrit ftohës: në fluturim jo më pak se 660 kg/orë | |
| RS0T01 | Temperatura e ajrit nĂ« ndarjet e instrumenteve jo mĂ« shumĂ« se 60 ÂșĐĄ | |
| RSH01 | Sasia e lagështisë së lirë me grimca të imëta në ajrin ftohës jo më shumë se 2 g/kg ajër të thatë |
Projekti i sistemit të verifikimit të kërkesave.
Për çdo kërkesë llogaritëse ekziston një algoritëm për vlerësimin e përputhshmërisë midis parametrave të llogaritur dhe parametrave të përcaktuar në kërkesë. Në thelb, çdo sistem kontrolli përmban gjithmonë algoritme të verifikimit të kërkesave si pjesë të funksionimit të tij standard. Edhe çdo rregullator i përmban ato. Nëse temperatura del jashtë kufijve, aktivizohet kondicioneri. Kështu, faza e parë e çdo rregullimi është verifikimi i përputhshmërisë së parametrave me kërkesën.
Dhe meqë verifikimi është një algoritëm, mund të përdoren të njëjtat mjete dhe instrumente që përdorim për krijimin e programeve të kontrollit. Për shembull, mjedisi SimInTech mundëson krijimin e paketave të projekteve që përmbajnë pjesë të ndryshme të modelit, të realizuara si projekte të veçanta (modeli i objektit, modeli i sistemit të kontrollit, modeli i mjedisit rrethues etj.).
Në këtë rast, projekti i verifikimit të kërkesave bëhet një projekt algoritmesh si çdo tjetër dhe lidhet me paketën e modelit. Në regjimin e modelimit dinamik ai kryen analizën e përputhshmërisë me kërkesat e detyrës teknike.
Një shembull i mundshëm i paraqitjes së projektit të sistemit është dhënë në figurën 1.
Figura 1. Shembull i paraqitjes së projektit të verifikimit.
Ashtu si për algoritmet e kontrollit, kërkesat mund të organizohen në formën e një grupi fletësh. Për lehtësi në punën me algoritmet në mjedise të modelimit strukturor si SimInTech, Simulink, AmeSim, përdoren mundësitë e krijimit të strukturave shumënivelëshe në formën e nënmodeleve. Kjo organizim bën të mundur grupimin e kërkesave të ndryshme në paketa për të thjeshtuar punën me vëllimin e kërkesave, njësoj siç bëhet për algoritmet e kontrollit (shih fig. 2).
Figura 2. Struktura hierarkike e modelit të verifikimit të kërkesave.
Për shembull, në rastin në shqyrtim janë veçuar dy grupe: kërkesat për mjedisin dhe kërkesat drejtpërdrejt për sistemin. Prandaj përdoret një strukturë të dhënash me dy nivele: dy grupe, secili prej të cilëve është një fletë e algoritmit.
Për lidhjen e të dhënave me modelin përdoret skema standarde e formimit të bazës së të dhënave të sinjaleve, në të cilën ruhen të dhënat për shkëmbimin ndërmjet pjesëve të projektit.
Gjatë krijimit dhe testimit të softuerit, në këtë bazë vendosen leximet e sensorëve (analoge të sensorëve realë të sistemit), të cilat përdoren nga sistemi i kontrollit.
Për projektin e testimit, në këtë bazë të dhënash mund të ruhen gjithashtu çdo parametër i llogaritur në modelin dinamik dhe, në këtë mënyrë, të përdoret për të verifikuar përmbushjen e kërkesave.
Vetë modeli dinamik në këtë rast mund të realizohet në çdo sistem të modelimit matematikor ose edhe në formën e një programi ekzekutues. Kërkesa e vetme është prania e ndërfaqeve programore për dërgimin e të dhënave të modelimit në mjedisin e jashtëm.
Figura 3. Lidhja e projektit të verifikimit me modelin e integruar.
Një shembull i fletës bazë të verifikimit të kërkesave paraqitet në figurën 4. Nga këndvështrimi i zhvilluesit, ajo paraqet një skemë të zakonshme llogaritëse, ku algoritmi i verifikimit të kërkesave është paraqitur në formë grafike.
Figura 4. Fleta e verifikimit të kërkesave.
Pjesët kryesore të fletës së verifikimit përshkruhen në figurën 5. Algoritmi i verifikimit formohet në mënyrë të ngjashme me skemat llogaritëse të algoritmeve të kontrollit. Në anën e djathtë ndodhet blloku i leximit të sinjaleve nga baza e të dhënave. Në këtë bllok kryhet qasja në bazën e të dhënave të sinjaleve gjatë modelimit.
Sinjalet e marra analizohen për të përcaktuar kushtet e verifikimit të kërkesave. Në rastin në shqyrtim, analizohet lartësia për të përcaktuar pozicionin e avionit (nëse ndodhet në parkim apo në fluturim). Për këtë qëllim mund të përdoren edhe sinjale të tjera dhe parametra të modelit të llogaritur.
Kushtet e verifikimit dhe parametrat që kontrollohen dërgohen te blloqet standarde të verifikimit, ku analizohet përputhshmëria e këtyre parametrave me kërkesat e përcaktuara. Rezultatet regjistrohen në bazën e të dhënave të sinjaleve në mënyrë që të mund të përdoren për gjenerimin automatik të checklist-it.
Figura 5. Struktura e fletës së llogaritjes për verifikimin e kërkesave.
Si parametra të verifikimit nuk është e domosdoshme të përdoren vetëm sinjalet që ndodhen në bazën e të dhënave dhe që kontrollohen nga parametrat e llogaritur gjatë modelimit. Asgjë nuk pengon që brenda projektit të kërkesave të kryhen llogaritje shtesë, ashtu siç llogarisim kushtet e verifikimit.
Për shembull, një kërkesë e tillë:
Numri i aktivizimeve të sistemit të korrigjimit gjatë fluturimit drejt objektivit nuk duhet të kalojë 5, ndërsa koha totale e funksionimit të sistemit të korrigjimit nuk duhet të kalojë 30 sekonda.
Në këtë rast, në skemën llogaritëse të projektit të kërkesave shtohet algoritmi i numërimit të aktivizimeve dhe i kohës totale të funksionimit.
Blloku standard i verifikimit të kërkesave.
Ădo bllok standard i verifikimit tĂ« kĂ«rkesave Ă«shtĂ« projektuar pĂ«r tĂ« llogaritur pĂ«rmbushjen e njĂ« kĂ«rkese tĂ« njĂ« lloji tĂ« caktuar. PĂ«r shembull, kĂ«rkesat pĂ«r mjedisin pĂ«rfshijnĂ« intervalin e temperaturave tĂ« punĂ«s sĂ« ajrit tĂ« ambientit nĂ« parkim dhe nĂ« fluturim. Ky bllok duhet tĂ« marrĂ« si parametĂ«r temperaturĂ«n e ajrit nĂ« model dhe tĂ« pĂ«rcaktojĂ« nĂ«se ky parametĂ«r e mbulon intervalin e pĂ«rcaktuar tĂ« temperaturave.
Blloku përmban dy porta hyrëse, param dhe condition.
Në të parën jepet parametri që verifikohet. Në këtë rast, «Temperatura e mjedisit të jashtëm».
NĂ« portĂ«n e dytĂ« jepet njĂ« variabĂ«l booleane â kushti pĂ«r kryerjen e verifikimit.
Nëse në hyrjen e dytë vjen TRUE (1), atëherë blloku kryen llogaritjen e verifikimit të kërkesës.
Nëse në hyrjen e dytë vjen vlera FALSE (0), atëherë kushtet e kontrollit nuk ekzekutohen. Kjo është e nevojshme që të mund të merren parasysh kushtet e llogaritjes. Në rastin tonë, kjo hyrje përdoret për të aktivizuar ose çaktivizuar kontrollin në varësi të gjendjes së modelit. Nëse LA gjatë modelimit ndodhet në tokë, atëherë kërkesat që lidhen me fluturimin nuk kontrollohen dhe, anasjelltas, nëse LA është në fluturim, nuk kontrollohen kërkesat që lidhen me funksionimin gjatë qëndrimit në parkim.
Kjo hyrje mund të përdoret gjithashtu gjatë konfigurimit të modelit, për shembull në fazën fillestare të llogaritjes. Kur modeli sillet në gjendjen e kërkuar, blloqet e kontrollit janë të çaktivizuara, por sapo sistemi kalon në regjimin e kërkuar të punës, blloqet e kontrollit aktivizohen.
Si parametra të këtij blloku përcaktohen:
- kushtet kufitare: kufiri i sipërm (UpLimit) dhe kufiri i poshtëm (DownLimit) të diapazoneve që duhet të kontrollohen;
- koha e kërkuar e qëndrimit të sistemit në diapazonet kufitare (TimeInterval) në sekonda;
- identifikuesi i kërkesës ReqName;
- lejueshmĂ«ria e daljes jashtĂ« diapazonit Out_range â njĂ« variabĂ«l booleane qĂ« pĂ«rcakton nĂ«se dalja e vlerĂ«s jashtĂ« diapazonit qĂ« kontrollohet pĂ«rbĂ«n shkelje tĂ« kĂ«rkesĂ«s.
NĂ« disa raste, dalja e vlerĂ«s sĂ« kontrolluar tregon se sistemi ka rezervĂ« dhe mund tĂ« punojĂ« jashtĂ« kufijve tĂ« diapazonit tĂ« punĂ«s. NĂ« raste tĂ« tjera, dalja tregon se sistemi nuk arrin tâi mbajĂ« parametrat e caktuar brenda diapazonit.
Figura 6. Blloku tipik i kontrollit të vetisë në skemë dhe parametrat e tij.
Si rezultat i llogaritjes së këtij blloku, në dalje formohet variabla Result, e cila merr vlerat e mëposhtme:
- 0 â rNone, vlera nuk Ă«shtĂ« pĂ«rcaktuar;
- 1 â rDone, kĂ«rkesa pĂ«rmbushet;
- 2 â rFault, kĂ«rkesa nuk pĂ«rmbushet.
Paraqitja e bllokut përmban:
- tekstin e identifikuesit;
- paraqitjet numerike të parametrave të kufijve të matjes;
- identifikuesin me ngjyra të gjendjes së parametrit.
Brenda bllokut mund të ndodhet një skemë mjaft komplekse e nxjerrjes logjike.
Për shembull, për kontrollin e diapazonit të punës së temperaturës së bllokut, të paraqitur në figurën 6, skema e brendshme është treguar në figurën 7.
Figura 7. Skema e brendshme e bllokut për përcaktimin e diapazonit të temperaturës.
Brenda bllokut të skemës përdoren vetitë e përcaktuara në parametrat e bllokut.
Përveç analizës së përputhshmërisë me kërkesat, skema e brendshme e bllokut përmban edhe një grafik, i nevojshëm për shfaqjen e rezultateve të modelimit. Ky grafik mund të përdoret si për ndjekje gjatë llogaritjes, ashtu edhe për analizën e rezultateve pas përfundimit të saj.
Rezultatet e llogaritjes dërgohen në daljen e bllokut dhe njëkohësisht regjistrohen në skedarin e përgjithshëm të raportit, i cili krijohet mbi bazën e rezultateve të të gjithë projektit. (shih fig. 8)
Një shembull raporti të krijuar nga rezultatet e modelimit është një skedar html, i gjeneruar sipas një formati të përcaktuar. Formati mund të përshtatet lirisht sipas standardit të miratuar në një organizatë të caktuar.
Brenda bllokut të skemës përdoren vetitë e përcaktuara në parametrat e bllokut.
Përveç analizës së përputhshmërisë me kërkesat, skema e brendshme e bllokut përmban edhe një grafik, i nevojshëm për shfaqjen e rezultateve të modelimit. Ky grafik mund të përdoret si për ndjekje gjatë llogaritjes, ashtu edhe për analizën e rezultateve pas përfundimit të saj.
Rezultatet e llogaritjes dërgohen në daljen e bllokut dhe njëkohësisht regjistrohen në skedarin e përgjithshëm të raportit, i cili krijohet mbi bazën e rezultateve të të gjithë projektit. (shih fig. 8)
Një shembull raporti të krijuar nga rezultatet e modelimit është një skedar html, i gjeneruar sipas një formati të përcaktuar. Formati mund të përshtatet lirisht sipas standardit të miratuar në një organizatë të caktuar.
Figura 8. Shembull i skedarit të raportit mbi rezultatet e modelimit.
NĂ« kĂ«tĂ« shembull, konfigurimi i formĂ«s sĂ« raportit kryhet drejtpĂ«rdrejt nĂ« vetitĂ« e projektit, ndĂ«rsa formati nĂ« tabelĂ« pĂ«rcaktohet si sinjale globale tĂ« projektit. NĂ« kĂ«tĂ« rast, SimInTech e zgjidh vetĂ« detyrĂ«n e konfigurimit tĂ« raportit, ndĂ«rsa blloku i regjistrimit tĂ« rezultateve nĂ« skedar i pĂ«rdor kĂ«to rreshta pĂ«r tâi shkruar nĂ« skedarin e raportit.
Figura 9. Konfigurimi i formatit të raportit në sinjalet globale të projektit
Përdorimi i bazës së të dhënave të sinjaleve për kërkesat.
Për automatizimin e punës me cilësimet e vetive, për çdo bllok tipik krijohet një strukturë standarde në bazën e të dhënave të sinjaleve. (shih fig. 10)
Figura 10. Shembull i strukturës së bllokut të kontrollit të kërkesës në bazën e të dhënave të sinjaleve.
Baza e të dhënave të sinjaleve siguron:
- Ruajtjen e të gjithë parametrave të nevojshëm të kërkesave për sistemin.
- Shqyrtim të përshtatshëm të kërkesave ekzistuese në projekt bazuar në parametrat e përcaktuar dhe rezultatet aktuale të modelimit.
- Konfigurimin e një blloku ose të një grupi blloqesh me përdorimin e një gjuhe programimi skriptesh. Ndryshimet në bazën e të dhënave të sinjaleve sjellin ndryshimin e vlerave të vetive të bllokut në skemë.
- Ruajtjen e përshkrimeve tekstuale, lidhjeve me pikat e detyrës teknike ose identifikuesve në sistemin e menaxhimit të kërkesave.
Strukturat e bazës së të dhënave të sinjaleve për kërkesat mund të përshtaten lehtësisht për punë me një sistem të jashtëm të menaxhimit të kërkesave. Skema e përgjithshme e ndërveprimit me sistemet e menaxhimit të kërkesave paraqitet në figurën 11.
Figura 11. Skema e ndërveprimit me sistemin e menaxhimit të kërkesave.
Sekuenca e ndërveprimit të projektit testues SimInTech me sistemin e menaxhimit të kërkesave është si vijon:
- Specifikimi teknik ndahet në kërkesa.
- Veçohen ato kërkesa të specifikimit teknik që mund të verifikohen përmes modelimit matematik të proceseve teknike.
- Atributet e kërkesave të përzgjedhura dërgohen në bazën e të dhënave të sinjaleve të SimInTech në strukturat e blloqeve tipike (për shembull, temperatura maksimale dhe minimale).
- Gjatë procesit të llogaritjes, të dhënat e strukturave kalojnë në skemat llogaritëse të blloqeve, kryhet analiza dhe rezultatet ruhen në bazën e të dhënave të sinjaleve.
- Pas përfundimit të llogaritjes, rezultatet e analizës dërgohen në sistemin e menaxhimit të kërkesave.
Fazat 3â5 tĂ« punĂ«s me kĂ«rkesat mund tĂ« pĂ«rsĂ«riten gjatĂ« procesit tĂ« projektimit, kur ndodhin ndryshime nĂ« konstruksion dhe/ose nĂ« kĂ«rkesa dhe, pĂ«r rrjedhojĂ«, nevojitet njĂ« verifikim i pĂ«rsĂ«ritur i ndikimit tĂ« ndryshimeve tĂ« bĂ«ra.
PĂ«rfundime.
- Prototipi i krijuar i sistemit siguron një ulje të ndjeshme të kohës së analizës së modeleve ekzistuese për pajtueshmërinë me kërkesat e specifikimit teknik.
- Teknologjia e propozuar e testimit përdor modele dinamike tashmë ekzistuese dhe mund të përdoret edhe për çdo model dinamik, përfshirë ato që nuk janë krijuar në mjedisin SimInTech.
- Përdorimi i organizimit paketor të të dhënave lejon krijimin e paketave për verifikimin e kërkesave paralelisht me zhvillimin e modeleve, ose edhe përdorimin e këtyre paketave si specifikim teknik për zhvillimin e modeleve.
- Teknologjia mund të integrohet me sistemet ekzistuese të menaxhimit të kërkesave pa kosto të konsiderueshme.
Për ata që lexuan deri në fund,
Burimi: habr.com
