ការផ្ទៀងផ្ទាត់ដោយស្វ័យប្រវត្តិនូវតម្រូវការលក្ខណៈបច្ចេកទេសកំឡុងពេលបង្កើតគំរូថាមវន្ត

ការបន្តប្រធានបទ "តើអ្វីជាភស្តុតាងរបស់អ្នក?"សូមក្រឡេកមើលបញ្ហានៃគំរូគណិតវិទ្យាពីផ្នែកម្ខាងទៀត។ បន្ទាប់​ពី​យើង​ជឿ​ជាក់​ថា​គំរូ​ត្រូវ​នឹង​សេចក្ដី​ពិត​នៃ​ជីវិត​ដែល​កើត​ឡើង​នៅ​ក្នុង​ផ្ទះ យើង​អាច​ឆ្លើយ​នឹង​សំណួរ​ចំបង​ថា៖ «តើ​យើង​មាន​អ្វី​នៅ​ទី​នេះ?»។ នៅពេលបង្កើតគំរូនៃវត្ថុបច្ចេកទេស ជាធម្មតាយើងចង់ធ្វើឱ្យប្រាកដថាវត្ថុនេះនឹងបំពេញតាមការរំពឹងទុករបស់យើង។ ចំពោះគោលបំណងនេះការគណនាថាមវន្តនៃដំណើរការត្រូវបានអនុវត្តហើយលទ្ធផលត្រូវបានប្រៀបធៀបជាមួយនឹងតម្រូវការ។ នេះគឺជាឌីជីថលភ្លោះ គំរូនិម្មិត។ល។ បុរសតូចៗដែលមានម៉ូដទាន់សម័យដែលនៅដំណាក់កាលរចនា ដោះស្រាយបញ្ហារបៀបធ្វើឱ្យប្រាកដថាយើងទទួលបានអ្វីដែលយើងបានគ្រោងទុក។

តើ​យើង​អាច​ធ្វើ​យ៉ាង​ណា​ឱ្យ​ប្រាកដ​ថា​ប្រព័ន្ធ​របស់​យើង​ពិត​ជា​អ្វី​ដែល​យើង​រចនា តើ​ការ​រចនា​របស់​យើង​នឹង​ហោះ​ហើរ ឬ​អណ្តែត? ហើយ​បើ​វា​ហោះ​ឡើង តើ​ខ្ពស់​ប៉ុណ្ណា? ហើយ​បើ​វា​អណ្តែត តើ​ជ្រៅ​ប៉ុណ្ណា?

អត្ថបទនេះពិភាក្សាអំពីស្វ័យប្រវត្តិកម្មនៃការផ្ទៀងផ្ទាត់ការអនុលោមតាមតម្រូវការនៃអគារបច្ចេកទេសនៅពេលបង្កើតគំរូថាមវន្តនៃប្រព័ន្ធបច្ចេកទេស។ ជាឧទាហរណ៍ សូមក្រឡេកមើលធាតុមួយនៃលក្ខណៈបច្ចេកទេសសម្រាប់ប្រព័ន្ធត្រជាក់តាមយន្តហោះ។

យើងពិចារណាលើតម្រូវការទាំងនោះដែលអាចបង្ហាញជាលេខ និងផ្ទៀងផ្ទាត់តាមគណិតវិទ្យាដោយផ្អែកលើគំរូគណនាជាក់លាក់មួយ។ វាច្បាស់ណាស់ថានេះគ្រាន់តែជាផ្នែកនៃតម្រូវការទូទៅសម្រាប់ប្រព័ន្ធបច្ចេកទេសណាមួយប៉ុណ្ណោះ ប៉ុន្តែវាស្ថិតនៅលើការត្រួតពិនិត្យពួកវាថាយើងចំណាយពេលវេលា សរសៃប្រសាទ និងលុយលើការបង្កើតគំរូថាមវន្តនៃវត្ថុ។

នៅពេលពិពណ៌នាអំពីតម្រូវការបច្ចេកទេសក្នុងទម្រង់ជាឯកសារ ប្រភេទជាច្រើននៃតម្រូវការផ្សេងៗគ្នាអាចត្រូវបានសម្គាល់ ដែលនីមួយៗទាមទារវិធីសាស្រ្តផ្សេងៗគ្នាសម្រាប់ការបង្កើតការផ្ទៀងផ្ទាត់ដោយស្វ័យប្រវត្តិនៃការបំពេញតម្រូវការ។

ជាឧទាហរណ៍ សូមពិចារណាលើសំណុំនៃតម្រូវការដ៏តូច ប៉ុន្តែជាក់ស្តែងនេះ៖

1. សីតុណ្ហភាពខ្យល់នៅច្រកចូលប្រព័ន្ធប្រព្រឹត្តកម្មទឹក៖
   នៅក្នុងចំណតរថយន្ត - ពីដក 35 ទៅ 35 ºС,
   នៅក្នុងការហោះហើរ - ពីដក 35 ទៅ 39 ºС។
2. សម្ពាធឋិតិវន្តនៃខ្យល់បរិយាកាសក្នុងការហោះហើរគឺពី 700 ទៅ 1013 GPa (ពី 526 ទៅ 760 mm Hg) ។
3. សម្ពាធខ្យល់សរុបនៅច្រកចូល SVO ខ្យល់ក្នុងជើងហោះហើរគឺពី 754 ទៅ 1200 GPa (ពី 566 ទៅ 1050 mm Hg) ។
4. សីតុណ្ហភាពខ្យល់ត្រជាក់៖
   នៅក្នុងចំណតរថយន្ត - មិនលើសពី 27 ºС, សម្រាប់ប្លុកបច្ចេកទេស - មិនលើសពី 29 ºС,
   នៅក្នុងការហោះហើរ - មិនលើសពី 25 ºСសម្រាប់ប្លុកបច្ចេកទេស - មិនលើសពី 27 ºС។
5. លំហូរខ្យល់ត្រជាក់៖
   នៅពេលចត - យ៉ាងហោចណាស់ 708 គីឡូក្រាម / ម៉ោង;
   ក្នុងការហោះហើរ - មិនតិចជាង 660 គីឡូក្រាមក្នុងមួយម៉ោង។
6. សីតុណ្ហភាពខ្យល់នៅក្នុងបន្ទប់ឧបករណ៍គឺមិនលើសពី 60 ºС។
7. បរិមាណសំណើមល្អនៅក្នុងខ្យល់ត្រជាក់គឺមិនលើសពី 2 ក្រាម / គីឡូក្រាមនៃខ្យល់ស្ងួត។

សូម្បីតែនៅក្នុងសំណុំនៃតម្រូវការមានកំណត់នេះ យ៉ាងហោចណាស់មានប្រភេទពីរដែលត្រូវដោះស្រាយខុសគ្នានៅក្នុងប្រព័ន្ធ៖

• តម្រូវការសម្រាប់លក្ខខណ្ឌប្រតិបត្តិការនៃប្រព័ន្ធ (ប្រការ 1-3);
• តម្រូវការប៉ារ៉ាម៉ែត្រសម្រាប់ប្រព័ន្ធ (ប្រការ 3-7) ។

លក្ខខណ្ឌប្រតិបត្តិការរបស់ប្រព័ន្ធ
លក្ខខណ្ឌខាងក្រៅសម្រាប់ប្រព័ន្ធដែលកំពុងត្រូវបានបង្កើតឡើងកំឡុងពេលធ្វើគំរូអាចត្រូវបានបញ្ជាក់ជាលក្ខខណ្ឌព្រំដែន ឬជាលទ្ធផលនៃប្រតិបត្តិការនៃប្រព័ន្ធទូទៅ។
នៅក្នុងការក្លែងធ្វើថាមវន្តវាចាំបាច់ដើម្បីធានាថាលក្ខខណ្ឌប្រតិបត្តិការដែលបានបញ្ជាក់ត្រូវបានគ្របដណ្តប់ដោយដំណើរការក្លែងធ្វើ។

តម្រូវការប្រព័ន្ធប៉ារ៉ាម៉ែត្រ
តម្រូវការទាំងនេះគឺជាប៉ារ៉ាម៉ែត្រដែលផ្តល់ដោយប្រព័ន្ធខ្លួនឯង។ ក្នុងអំឡុងពេលដំណើរការគំរូ យើងអាចទទួលបានប៉ារ៉ាម៉ែត្រទាំងនេះជាលទ្ធផលនៃការគណនា ហើយត្រូវប្រាកដថាតម្រូវការត្រូវបានបំពេញក្នុងការគណនាជាក់លាក់នីមួយៗ។

តម្រូវការកំណត់អត្តសញ្ញាណ និងការសរសេរកូដ

ដើម្បីងាយស្រួលក្នុងការធ្វើការជាមួយតម្រូវការ ស្តង់ដារដែលមានស្រាប់សូមផ្តល់អនុសាសន៍ឱ្យកំណត់អត្តសញ្ញាណសម្រាប់តម្រូវការនីមួយៗ។ នៅពេលកំណត់អត្តសញ្ញាណ វាជាការចង់ប្រើប្រព័ន្ធសរសេរកូដបង្រួបបង្រួមមួយ។

លេខកូដតម្រូវការអាចគ្រាន់តែជាលេខដែលតំណាងឱ្យលេខលំដាប់នៃតម្រូវការ ឬវាអាចមានលេខកូដសម្រាប់ប្រភេទនៃតម្រូវការ លេខកូដសម្រាប់ប្រព័ន្ធ ឬអង្គភាពដែលវាអនុវត្ត កូដប៉ារ៉ាម៉ែត្រ លេខកូដទីតាំង និង អ្វីផ្សេងទៀតដែលវិស្វករអាចស្រមៃបាន។ (សូមមើលអត្ថបទសម្រាប់ការប្រើប្រាស់ការអ៊ិនកូដ)

តារាងទី 1 ផ្តល់នូវឧទាហរណ៍សាមញ្ញនៃការសរសេរកូដតម្រូវការ។

1. កូដប្រភពនៃតម្រូវការ R-requirements TK;
2. ប្រភេទកូដនៃតម្រូវការ E - តម្រូវការ - ប៉ារ៉ាម៉ែត្របរិស្ថាន ឬលក្ខខណ្ឌប្រតិបត្តិការ
   S - តម្រូវការដែលផ្តល់ដោយប្រព័ន្ធ;
3. លេខកូដស្ថានភាពយន្តហោះ 0 - ណាមួយ, G - ចត, F - នៅក្នុងការហោះហើរ;
4. ប្រភេទប៉ារ៉ាម៉ែត្ររាងកាយ កូដ T - សីតុណ្ហភាព P - សម្ពាធ G - អត្រាលំហូរសំណើម H;
5. លេខស៊េរីនៃតម្រូវការ។

ID តម្រូវការ	បរិយាយ	ប៉ារ៉ាម៉ែត្រ
REGT01	សីតុណ្ហភាពខ្យល់នៅច្រកចូលប្រព័ន្ធទឹកត្រជាក់៖ នៅចំណតរថយន្ត - ពីដក ៣៥ºС។ រហូតដល់ 35 ºС។
REFT ០១	សីតុណ្ហភាពខ្យល់នៅច្រកចូលប្រព័ន្ធការពារអាកាស៖ នៅក្នុងការហោះហើរ - ពីដក ៣៥ ºС ដល់ ៣៩ ºС។
REFP01	សម្ពាធបរិយាកាសឋិតិវន្តក្នុងការហោះហើរគឺពី 700 ទៅ 1013 hPa (ពី 526 ទៅ 760 mm Hg) ។
REFP02	សម្ពាធខ្យល់សរុបនៅច្រកចូល SVO ខ្យល់ក្នុងជើងហោះហើរគឺពី 754 ទៅ 1200 hPa (ពី 566 ទៅ 1050 mm Hg) ។
RSGT01	សីតុណ្ហភាពខ្យល់ត្រជាក់៖ នៅពេលចតរថយន្តមិនលើសពី ២៧ ºС
RSGT02	សីតុណ្ហភាពខ្យល់ត្រជាក់៖ នៅក្នុងចំណតរថយន្តសម្រាប់អង្គភាពបច្ចេកទេសមិនលើសពី 29 ºС
RSFT01	សីតុណ្ហភាពខ្យល់ត្រជាក់ក្នុងការហោះហើរមិនលើសពី 25 ºС
RSFT02	សីតុណ្ហភាពខ្យល់ត្រជាក់៖ ក្នុងជើងហោះហើរសម្រាប់អង្គភាពបច្ចេកទេសមិនលើសពី ២៧ ºС
RSGG01	លំហូរខ្យល់ត្រជាក់៖ ពេលចតមិនតិចជាង 708 គីឡូក្រាម/ម៉ោង
RSFG01	លំហូរខ្យល់ត្រជាក់៖ ក្នុងជើងហោះហើរមិនតិចជាង ៦៦០ គីឡូក្រាមក្នុងមួយម៉ោង
RS0T01	សីតុណ្ហភាពខ្យល់នៅក្នុងបន្ទប់ឧបករណ៍មិនលើសពី 60 ºС
RSH01	បរិមាណសំណើមល្អនៅក្នុងខ្យល់ត្រជាក់គឺមិនលើសពី 2 ក្រាម / គីឡូក្រាមនៃខ្យល់ស្ងួត

ការរចនាប្រព័ន្ធផ្ទៀងផ្ទាត់តម្រូវការ។

សម្រាប់តម្រូវការរចនានីមួយៗ មានក្បួនដោះស្រាយសម្រាប់វាយតម្លៃការឆ្លើយឆ្លងនៃប៉ារ៉ាម៉ែត្ររចនា និងប៉ារ៉ាម៉ែត្រដែលបានបញ្ជាក់នៅក្នុងតម្រូវការ។ ជាទូទៅ ប្រព័ន្ធត្រួតពិនិត្យណាមួយតែងតែមានក្បួនដោះស្រាយសម្រាប់ពិនិត្យតម្រូវការតាមលំនាំដើម។ ហើយសូម្បីតែនិយតករណាមួយក៏មានផ្ទុកពួកគេ។ ប្រសិនបើសីតុណ្ហភាពលើសពីដែនកំណត់ នោះម៉ាស៊ីនត្រជាក់នឹងបើក។ ដូច្នេះដំណាក់កាលដំបូងនៃបទប្បញ្ញត្តិណាមួយគឺត្រូវពិនិត្យមើលថាតើប៉ារ៉ាម៉ែត្រត្រូវនឹងតម្រូវការ។

ហើយចាប់តាំងពីការផ្ទៀងផ្ទាត់គឺជាក្បួនដោះស្រាយ នោះយើងអាចប្រើឧបករណ៍ និងឧបករណ៍ដូចគ្នាដែលយើងប្រើដើម្បីបង្កើតកម្មវិធីត្រួតពិនិត្យ។ ឧទាហរណ៍ បរិយាកាស SimInTech អនុញ្ញាតឱ្យអ្នកបង្កើតកញ្ចប់គម្រោងដែលមានផ្នែកផ្សេងៗនៃគំរូ ប្រតិបត្តិក្នុងទម្រង់នៃគម្រោងដាច់ដោយឡែក (គំរូវត្ថុ គំរូប្រព័ន្ធគ្រប់គ្រង គំរូបរិស្ថាន។ល។)។

គម្រោងការផ្ទៀងផ្ទាត់តម្រូវការក្នុងករណីនេះក្លាយជាគម្រោងក្បួនដោះស្រាយដូចគ្នា និងត្រូវបានភ្ជាប់ទៅកញ្ចប់គំរូ។ ហើយនៅក្នុងរបៀបគំរូថាមវន្តវាធ្វើការវិភាគសម្រាប់ការអនុលោមតាមតម្រូវការនៃលក្ខណៈបច្ចេកទេស។

ឧទាហរណ៍ដែលអាចកើតមាននៃការរចនាប្រព័ន្ធត្រូវបានបង្ហាញក្នុងរូបភាពទី 1 ។

រូបភាពទី 1. ឧទាហរណ៍នៃការរចនាគម្រោងផ្ទៀងផ្ទាត់។

ដូចគ្នានឹងក្បួនដោះស្រាយការគ្រប់គ្រងដែរ តម្រូវការអាចត្រូវបានគូរឡើងជាសំណុំនៃសន្លឹក។ សម្រាប់ភាពងាយស្រួលនៃការធ្វើការជាមួយក្បួនដោះស្រាយនៅក្នុងបរិយាកាសគំរូរចនាសម្ព័ន្ធដូចជា SimInTech, Simulink, AmeSim សមត្ថភាពបង្កើតរចនាសម្ព័ន្ធពហុកម្រិតក្នុងទម្រង់ជាគំរូរងត្រូវបានប្រើប្រាស់។ អង្គការនេះធ្វើឱ្យវាអាចដាក់ជាក្រុមតម្រូវការផ្សេងៗទៅជាសំណុំ ដើម្បីសម្រួលការងារជាមួយអារេនៃតម្រូវការ ដូចដែលត្រូវបានធ្វើសម្រាប់ក្បួនដោះស្រាយការគ្រប់គ្រង (សូមមើលរូបភាពទី 2)។

រូបភាពទី 2. រចនាសម្ព័ន្ធឋានានុក្រមនៃគំរូផ្ទៀងផ្ទាត់តម្រូវការ។

ឧទាហរណ៍ ក្នុងករណីដែលកំពុងពិចារណា ក្រុមពីរត្រូវបានសម្គាល់៖ តម្រូវការសម្រាប់បរិស្ថាន និងតម្រូវការដោយផ្ទាល់សម្រាប់ប្រព័ន្ធ។ ដូច្នេះរចនាសម្ព័ន្ធទិន្នន័យពីរកម្រិតត្រូវបានប្រើ: ពីរក្រុមដែលនីមួយៗជាស្លឹកនៃក្បួនដោះស្រាយ។

ដើម្បីភ្ជាប់ទិន្នន័យទៅនឹងគំរូ គ្រោងការណ៍ស្តង់ដារសម្រាប់បង្កើតមូលដ្ឋានទិន្នន័យសញ្ញាត្រូវបានប្រើ ដែលរក្សាទុកទិន្នន័យសម្រាប់ការផ្លាស់ប្តូររវាងផ្នែកនៃគម្រោង។

នៅពេលបង្កើត និងសាកល្បងកម្មវិធី ការអានឧបករណ៍ចាប់សញ្ញា (អាណាឡូកនៃឧបករណ៍ចាប់សញ្ញាប្រព័ន្ធពិត) ដែលត្រូវបានប្រើដោយប្រព័ន្ធគ្រប់គ្រងត្រូវបានដាក់ក្នុងមូលដ្ឋានទិន្នន័យនេះ។
សម្រាប់គម្រោងសាកល្បង ប៉ារ៉ាម៉ែត្រណាមួយដែលបានគណនានៅក្នុងគំរូថាមវន្តអាចត្រូវបានរក្សាទុកក្នុងមូលដ្ឋានទិន្នន័យដូចគ្នា ហើយដូច្នេះត្រូវបានប្រើដើម្បីពិនិត្យមើលថាតើតម្រូវការត្រូវបានបំពេញ។

ក្នុងករណីនេះ គំរូថាមវន្តខ្លួនឯងអាចត្រូវបានប្រតិបត្តិនៅក្នុងប្រព័ន្ធគំរូគណិតវិទ្យាណាមួយ ឬសូម្បីតែនៅក្នុងទម្រង់នៃកម្មវិធីដែលអាចប្រតិបត្តិបាន។ តម្រូវការតែមួយគត់គឺវត្តមាននៃចំណុចប្រទាក់កម្មវិធីសម្រាប់ការចេញទិន្នន័យគំរូទៅកាន់បរិយាកាសខាងក្រៅ។

រូបភាពទី 3. ការភ្ជាប់គម្រោងផ្ទៀងផ្ទាត់ទៅនឹងគំរូស្មុគស្មាញ។

ឧទាហរណ៍នៃសន្លឹកផ្ទៀងផ្ទាត់តម្រូវការមូលដ្ឋានត្រូវបានបង្ហាញក្នុងរូបភាពទី 4 ។ តាមទស្សនៈរបស់អ្នកអភិវឌ្ឍន៍ វាគឺជាដ្យាក្រាមគណនាសាមញ្ញដែលក្បួនដោះស្រាយការផ្ទៀងផ្ទាត់តម្រូវការត្រូវបានបង្ហាញជាក្រាហ្វិក។

រូបភាពទី 4. សន្លឹកត្រួតពិនិត្យតម្រូវការ។

ផ្នែកសំខាន់ៗនៃសន្លឹកពិនិត្យត្រូវបានពិពណ៌នានៅក្នុងរូបភាពទី 5 ។ ក្បួនដោះស្រាយការត្រួតពិនិត្យត្រូវបានបង្កើតឡើងស្រដៀងនឹងដ្យាក្រាមរចនានៃក្បួនដោះស្រាយត្រួតពិនិត្យ។ នៅផ្នែកខាងស្តាំមានប្លុកសម្រាប់អានសញ្ញាពីមូលដ្ឋានទិន្នន័យ។ ប្លុកនេះចូលប្រើមូលដ្ឋានទិន្នន័យសញ្ញាអំឡុងពេលក្លែងធ្វើ។

សញ្ញាដែលទទួលបានត្រូវបានវិភាគដើម្បីគណនាលក្ខខណ្ឌផ្ទៀងផ្ទាត់តម្រូវការ។ ក្នុងករណីនេះ ការវិភាគរយៈកម្ពស់ត្រូវបានអនុវត្តដើម្បីកំណត់ទីតាំងរបស់យន្តហោះ (ថាតើវាត្រូវបានចត ឬកំពុងហោះហើរ)។ ចំពោះគោលបំណងនេះអ្នកអាចប្រើសញ្ញាផ្សេងទៀតនិងប៉ារ៉ាម៉ែត្រគណនានៃគំរូ។

លក្ខខណ្ឌផ្ទៀងផ្ទាត់ និងប៉ារ៉ាម៉ែត្រដែលកំពុងត្រួតពិនិត្យត្រូវបានផ្ទេរទៅប្លុកផ្ទៀងផ្ទាត់ស្តង់ដារ ដែលក្នុងនោះប៉ារ៉ាម៉ែត្រទាំងនេះត្រូវបានវិភាគសម្រាប់ការអនុលោមតាមតម្រូវការដែលបានបញ្ជាក់។ លទ្ធផលត្រូវបានកត់ត្រានៅក្នុងមូលដ្ឋានទិន្នន័យសញ្ញាតាមរបៀបដែលពួកគេអាចប្រើដើម្បីបង្កើតបញ្ជីត្រួតពិនិត្យដោយស្វ័យប្រវត្តិ។

រូបភាពទី 5. រចនាសម្ព័ន្ធនៃសន្លឹកគណនាការផ្ទៀងផ្ទាត់តម្រូវការ។

ប៉ារ៉ាម៉ែត្រដែលត្រូវសាកល្បងមិនចាំបាច់ប្រើសញ្ញាដែលមាននៅក្នុងមូលដ្ឋានទិន្នន័យ ដែលត្រូវបានគ្រប់គ្រងដោយប៉ារ៉ាម៉ែត្រដែលបានគណនាក្នុងអំឡុងពេលដំណើរការក្លែងធ្វើនោះទេ។ គ្មាន​អ្វី​រារាំង​យើង​ពី​ការ​ធ្វើ​ការ​គណនា​បន្ថែម​ក្នុង​ក្របខណ្ឌ​នៃ​សេចក្តី​ព្រាង​តម្រូវ​ការ ដូច​យើង​គណនា​លក្ខខណ្ឌ​ផ្ទៀងផ្ទាត់​ដែរ។

ឧទាហរណ៍តម្រូវការនេះ៖

ចំនួននៃការធ្វើឱ្យសកម្មនៃប្រព័ន្ធកែតម្រូវក្នុងអំឡុងពេលហោះហើរទៅកាន់គោលដៅមិនគួរលើសពី 5 ហើយពេលវេលាប្រតិបត្តិការសរុបនៃប្រព័ន្ធកែតម្រូវមិនគួរលើសពី 30 វិនាទី។

ក្នុងករណីនេះ ក្បួនដោះស្រាយសម្រាប់ការប្រឆាំងចំនួននៃការចាប់ផ្តើម និងពេលវេលាប្រតិបត្តិការសរុបត្រូវបានបន្ថែមទៅដ្យាក្រាមរចនានៃតម្រូវការ។

ប្លុកផ្ទៀងផ្ទាត់តម្រូវការធម្មតា។

ប្រអប់ធីកតម្រូវការស្តង់ដារនីមួយៗត្រូវបានរចនាឡើងដើម្បីគណនាការបំពេញតម្រូវការនៃប្រភេទជាក់លាក់មួយ។ ឧទាហរណ៍ តម្រូវការបរិស្ថានរួមមានជួរនៃសីតុណ្ហភាពប្រតិបត្តិការជុំវិញនៅពេលចត និងពេលហោះហើរ។ ប្លុកនេះត្រូវតែទទួលសីតុណ្ហភាពខ្យល់នៅក្នុងគំរូជាប៉ារ៉ាម៉ែត្រ និងកំណត់ថាតើប៉ារ៉ាម៉ែត្រនេះគ្របដណ្តប់ជួរសីតុណ្ហភាពដែលបានបញ្ជាក់ឬអត់។/p>

ប្លុកមានច្រកបញ្ចូលពីរ ប៉ារ៉ាម៉ែត្រ និងលក្ខខណ្ឌ។

ទីមួយត្រូវបានចុកជាមួយនឹងប៉ារ៉ាម៉ែត្រដែលត្រូវបានពិនិត្យ។ ក្នុងករណីនេះ "សីតុណ្ហភាពខាងក្រៅ" ។

អថេរប៊ូលីនត្រូវបានផ្គត់ផ្គង់ទៅច្រកទីពីរ - លក្ខខណ្ឌសម្រាប់អនុវត្តការត្រួតពិនិត្យ។

ប្រសិនបើ TRUE (1) ត្រូវបានទទួលនៅពេលបញ្ចូលទីពីរ នោះប្លុកអនុវត្តការគណនាការផ្ទៀងផ្ទាត់តម្រូវការ។

ប្រសិនបើការបញ្ចូលទីពីរទទួលបាន FALSE (0) នោះលក្ខខណ្ឌសាកល្បងមិនត្រូវបានបំពេញទេ។ នេះគឺចាំបាច់ដើម្បីឱ្យលក្ខខណ្ឌនៃការគណនាអាចត្រូវបានគេយកមកពិចារណា។ ក្នុងករណីរបស់យើង ការបញ្ចូលនេះត្រូវបានប្រើដើម្បីបើក ឬបិទការត្រួតពិនិត្យអាស្រ័យលើស្ថានភាពនៃគំរូ។ ប្រសិនបើយន្តហោះនៅលើដីកំឡុងពេលពិសោធន៏ នោះតម្រូវការទាក់ទងនឹងការហោះហើរមិនត្រូវបានត្រួតពិនិត្យទេ ហើយផ្ទុយទៅវិញ ប្រសិនបើយន្តហោះកំពុងហោះហើរ នោះតម្រូវការទាក់ទងនឹងប្រតិបត្តិការនៅឈរមិនត្រូវបានត្រួតពិនិត្យទេ។

ការបញ្ចូលនេះក៏អាចត្រូវបានប្រើនៅពេលដំឡើងគំរូ ឧទាហរណ៍នៅដំណាក់កាលដំបូងនៃការគណនា។ នៅពេលដែលគំរូត្រូវបាននាំយកទៅក្នុងស្ថានភាពដែលត្រូវការ ប្លុកត្រួតពិនិត្យត្រូវបានបិទ ប៉ុន្តែដរាបណាប្រព័ន្ធឈានដល់របៀបប្រតិបត្តិការដែលត្រូវការ ប្លុកត្រួតពិនិត្យត្រូវបានបើក។

ប៉ារ៉ាម៉ែត្រនៃប្លុកនេះគឺ:

• លក្ខខណ្ឌព្រំដែន៖ ដែនកំណត់ជួរខាងលើ (UpLimit) និងខាងក្រោម (DownLimit) ដែលត្រូវតែពិនិត្យ។
• ពេលវេលានៃការប៉ះពាល់ប្រព័ន្ធដែលត្រូវការនៅជួរព្រំដែន (TimeInterval) គិតជាវិនាទី;
• ស្នើសុំ ID ReqName;
• លទ្ធភាពនៃការលើសពីជួរ Out_range គឺជាអថេរ Boolean ដែលកំណត់ថាតើតម្លៃលើសពីជួរដែលបានពិនិត្យគឺជាការបំពានលើតម្រូវការ។

ក្នុងករណីខ្លះ លទ្ធផលតម្លៃសាកល្បងបង្ហាញថាប្រព័ន្ធមានរឹមខ្លះ ហើយអាចដំណើរការនៅក្រៅជួរប្រតិបត្តិការរបស់វា។ ក្នុងករណីផ្សេងទៀត លទ្ធផលមានន័យថាប្រព័ន្ធមិនអាចរក្សាចំណុចកំណត់ក្នុងជួរបានទេ។

រូបភាពទី 6. ប្លុកត្រួតពិនិត្យលក្ខណៈធម្មតានៅក្នុងដ្យាក្រាម និងប៉ារ៉ាម៉ែត្ររបស់វា។

ជាលទ្ធផលនៃការគណនាប្លុកនេះ អថេរលទ្ធផលត្រូវបានបង្កើតឡើងនៅទិន្នផល ដែលយកតម្លៃដូចខាងក្រោម៖

• 0 - rNone, តម្លៃមិនត្រូវបានកំណត់;
• 1 - ធ្វើរួច តម្រូវការត្រូវបានបំពេញ;
• 2 - rFault, តម្រូវការមិនត្រូវបានបំពេញ។

រូបភាពប្លុកមាន៖

• អត្ថបទកំណត់អត្តសញ្ញាណ;
• ការបង្ហាញឌីជីថលនៃប៉ារ៉ាម៉ែត្រកំណត់ដែនកំណត់រង្វាស់;
• ការកំណត់ពណ៌នៃស្ថានភាពប៉ារ៉ាម៉ែត្រ។

នៅខាងក្នុងប្លុកអាចមានសៀគ្វីសន្និដ្ឋានឡូជីខលស្មុគស្មាញ។

ឧទាហរណ៍ ដើម្បីពិនិត្យមើលជួរសីតុណ្ហភាពប្រតិបត្តិការរបស់អង្គភាពដែលបង្ហាញក្នុងរូបភាពទី 6 សៀគ្វីខាងក្នុងត្រូវបានបង្ហាញក្នុងរូបភាពទី 7 ។

រូបភាពទី 7. ដ្យាក្រាមខាងក្នុងនៃអង្គភាពកំណត់ជួរសីតុណ្ហភាព។

នៅខាងក្នុងប្លុកសៀគ្វីលក្ខណៈសម្បត្តិដែលបានបញ្ជាក់នៅក្នុងប៉ារ៉ាម៉ែត្រប្លុកត្រូវបានប្រើ។
បន្ថែមពីលើការវិភាគការអនុលោមតាមតម្រូវការ ដ្យាក្រាមខាងក្នុងនៃប្លុកមានក្រាហ្វដែលចាំបាច់សម្រាប់បង្ហាញលទ្ធផលក្លែងធ្វើ។ ក្រាហ្វនេះអាចត្រូវបានប្រើទាំងសម្រាប់ការមើលកំឡុងពេលគណនា និងសម្រាប់ការវិភាគលទ្ធផលបន្ទាប់ពីការគណនា។

លទ្ធផលនៃការគណនាត្រូវបានបញ្ជូនទៅលទ្ធផលនៃប្លុក ហើយត្រូវបានកត់ត្រាក្នុងពេលដំណាលគ្នានៅក្នុងឯកសាររបាយការណ៍ទូទៅ ដែលត្រូវបានបង្កើតឡើងដោយផ្អែកលើលទ្ធផលសម្រាប់គម្រោងទាំងមូល។ (សូមមើលរូបភាពទី 8)

ឧទាហរណ៍នៃរបាយការណ៍ដែលបានបង្កើតដោយផ្អែកលើលទ្ធផលនៃការក្លែងធ្វើគឺជាឯកសារ html ដែលត្រូវបានបង្កើតឡើងតាមទម្រង់ដែលបានផ្តល់ឱ្យ។ ទម្រង់អាចត្រូវបានកំណត់រចនាសម្ព័ន្ធតាមអំពើចិត្តចំពោះទម្រង់ដែលទទួលយកដោយស្ថាប័នជាក់លាក់មួយ។

នៅខាងក្នុងប្លុកសៀគ្វីលក្ខណៈសម្បត្តិដែលបានបញ្ជាក់នៅក្នុងប៉ារ៉ាម៉ែត្រប្លុកត្រូវបានប្រើ។
បន្ថែមពីលើការវិភាគការអនុលោមតាមតម្រូវការ ដ្យាក្រាមខាងក្នុងនៃប្លុកមានក្រាហ្វដែលចាំបាច់សម្រាប់បង្ហាញលទ្ធផលក្លែងធ្វើ។ ក្រាហ្វនេះអាចត្រូវបានប្រើទាំងសម្រាប់ការមើលកំឡុងពេលគណនា និងសម្រាប់ការវិភាគលទ្ធផលបន្ទាប់ពីការគណនា។

លទ្ធផលនៃការគណនាត្រូវបានបញ្ជូនទៅលទ្ធផលនៃប្លុក ហើយត្រូវបានកត់ត្រាក្នុងពេលដំណាលគ្នានៅក្នុងឯកសាររបាយការណ៍ទូទៅ ដែលត្រូវបានបង្កើតឡើងដោយផ្អែកលើលទ្ធផលសម្រាប់គម្រោងទាំងមូល។ (សូមមើលរូបភាពទី 8)

ឧទាហរណ៍នៃរបាយការណ៍ដែលបានបង្កើតដោយផ្អែកលើលទ្ធផលនៃការក្លែងធ្វើគឺជាឯកសារ html ដែលត្រូវបានបង្កើតឡើងតាមទម្រង់ដែលបានផ្តល់ឱ្យ។ ទម្រង់អាចត្រូវបានកំណត់រចនាសម្ព័ន្ធតាមអំពើចិត្តចំពោះទម្រង់ដែលទទួលយកដោយស្ថាប័នជាក់លាក់មួយ។

រូបភាពទី 8. ឧទាហរណ៍នៃឯកសាររបាយការណ៍ផ្អែកលើលទ្ធផលនៃការក្លែងធ្វើ។

ក្នុងឧទាហរណ៍នេះ ទម្រង់របាយការណ៍ត្រូវបានកំណត់រចនាសម្ព័ន្ធដោយផ្ទាល់នៅក្នុងលក្ខណៈសម្បត្តិរបស់គម្រោង ហើយទម្រង់ក្នុងតារាងត្រូវបានកំណត់ជាសញ្ញាគម្រោងសកល។ ក្នុងករណីនេះ SimInTech ខ្លួនវាដោះស្រាយបញ្ហានៃការដំឡើងរបាយការណ៍ ហើយប្លុកសម្រាប់ការសរសេរលទ្ធផលទៅកាន់ឯកសារប្រើប្រាស់បន្ទាត់ទាំងនេះដើម្បីសរសេរទៅកាន់ឯកសាររបាយការណ៍។

រូបភាពទី 9. ការកំណត់ទម្រង់របាយការណ៍នៅក្នុងសញ្ញាគម្រោងសកល

ការប្រើប្រាស់មូលដ្ឋានទិន្នន័យសញ្ញាសម្រាប់តម្រូវការ។

ដើម្បីធ្វើការដោយស្វ័យប្រវត្តិជាមួយនឹងការកំណត់ទ្រព្យសម្បត្តិ រចនាសម្ព័ន្ធស្តង់ដារមួយត្រូវបានបង្កើតឡើងនៅក្នុងមូលដ្ឋានទិន្នន័យសញ្ញាសម្រាប់ប្លុកធម្មតានីមួយៗ។ (សូមមើលរូបទី 10)

រូបភាពទី 10. ឧទាហរណ៍នៃរចនាសម្ព័ន្ធនៃប្លុកត្រួតពិនិត្យតម្រូវការនៅក្នុងមូលដ្ឋានទិន្នន័យសញ្ញា។

មូលដ្ឋានទិន្នន័យសញ្ញាផ្តល់៖

• ការរក្សាទុកប៉ារ៉ាម៉ែត្រតម្រូវការប្រព័ន្ធចាំបាច់ទាំងអស់។
• ការមើលភាពងាយស្រួលនៃតម្រូវការគម្រោងដែលមានស្រាប់ពីប៉ារ៉ាម៉ែត្រដែលបានបញ្ជាក់ និងលទ្ធផលគំរូបច្ចុប្បន្ន។
• ការដំឡើងប្លុកមួយ ឬក្រុមប្លុកដោយប្រើភាសាសរសេរកម្មវិធីស្គ្រីប។ ការផ្លាស់ប្តូរនៅក្នុងមូលដ្ឋានទិន្នន័យសញ្ញានាំទៅរកការផ្លាស់ប្តូរតម្លៃទ្រព្យសម្បត្តិប្លុកនៅក្នុងដ្យាក្រាម។
• ការរក្សាទុកការពិពណ៌នាអត្ថបទ តំណភ្ជាប់ទៅកាន់ធាតុបញ្ជាក់បច្ចេកទេស ឬឧបករណ៍កំណត់អត្តសញ្ញាណនៅក្នុងប្រព័ន្ធគ្រប់គ្រងតម្រូវការ។

រចនាសម្ព័ន្ធមូលដ្ឋានទិន្នន័យសញ្ញាសម្រាប់តម្រូវការអាចត្រូវបានកំណត់រចនាសម្ព័ន្ធយ៉ាងងាយស្រួលដើម្បីធ្វើការជាមួយប្រព័ន្ធគ្រប់គ្រងតម្រូវការភាគីទីបី។ ដ្យាក្រាមទូទៅនៃអន្តរកម្មជាមួយប្រព័ន្ធគ្រប់គ្រងតម្រូវការត្រូវបានបង្ហាញនៅក្នុងរូបភាពទី 11 ។

រូបភាពទី 11. ដ្យាក្រាមនៃអន្តរកម្មជាមួយប្រព័ន្ធគ្រប់គ្រងតម្រូវការ។

លំដាប់នៃអន្តរកម្មរវាងគម្រោងសាកល្បង SimInTech និងប្រព័ន្ធគ្រប់គ្រងតម្រូវការមានដូចខាងក្រោម៖

1. លក្ខខណ្ឌនៃសេចក្តីយោងត្រូវបានបែងចែកទៅជាតម្រូវការ។
2. តម្រូវការនៃលក្ខណៈបច្ចេកទេសត្រូវបានកំណត់អត្តសញ្ញាណដែលអាចត្រូវបានផ្ទៀងផ្ទាត់ដោយគំរូគណិតវិទ្យានៃដំណើរការបច្ចេកទេស។
3. គុណលក្ខណៈនៃតម្រូវការដែលបានជ្រើសរើសត្រូវបានផ្ទេរទៅមូលដ្ឋានទិន្នន័យសញ្ញា SimInTech នៅក្នុងរចនាសម្ព័ន្ធនៃប្លុកស្តង់ដារ (ឧទាហរណ៍ សីតុណ្ហភាពអតិបរមា និងអប្បបរមា)។
4. ក្នុងអំឡុងពេលដំណើរការគណនាទិន្នន័យរចនាសម្ព័ន្ធត្រូវបានផ្ទេរទៅដ្យាក្រាមរចនាប្លុកការវិភាគត្រូវបានអនុវត្តហើយលទ្ធផលត្រូវបានរក្សាទុកក្នុងមូលដ្ឋានទិន្នន័យសញ្ញា។
5. នៅពេលដែលការគណនាបានបញ្ចប់ លទ្ធផលនៃការវិភាគត្រូវបានផ្ទេរទៅប្រព័ន្ធគ្រប់គ្រងតម្រូវការ។

តម្រូវការជំហានទី 3 ដល់ទី 5 អាចត្រូវបានធ្វើម្តងទៀតក្នុងអំឡុងពេលដំណើរការរចនា នៅពេលដែលការផ្លាស់ប្តូរការរចនា និង/ឬតម្រូវការកើតឡើង ហើយផលប៉ះពាល់នៃការផ្លាស់ប្តូរចាំបាច់ត្រូវធ្វើតេស្តឡើងវិញ។

សេចក្តីសន្និដ្ឋាន។

• គំរូដែលបានបង្កើតនៃប្រព័ន្ធផ្តល់នូវការថយចុះគួរឱ្យកត់សម្គាល់នៅក្នុងពេលវេលានៃការវិភាគនៃគំរូដែលមានស្រាប់សម្រាប់ការអនុលោមតាមតម្រូវការនៃលក្ខណៈបច្ចេកទេស។
• បច្ចេកវិជ្ជាធ្វើតេស្តដែលបានស្នើឡើងប្រើគំរូថាមវន្តដែលមានស្រាប់ហើយអាចប្រើបានសូម្បីតែសម្រាប់ម៉ូដែលថាមវន្តណាមួយ រួមទាំងអ្វីដែលមិនបានអនុវត្តនៅក្នុងបរិយាកាស SimInTech ផងដែរ។
• ការប្រើប្រាស់អង្គភាពទិន្នន័យជាបាច់អនុញ្ញាតឱ្យអ្នកបង្កើតកញ្ចប់ផ្ទៀងផ្ទាត់តម្រូវការស្របជាមួយនឹងការអភិវឌ្ឍន៍គំរូ ឬសូម្បីតែប្រើកញ្ចប់ទាំងនេះជាលក្ខណៈបច្ចេកទេសសម្រាប់ការអភិវឌ្ឍន៍គំរូ។
• បច្ចេកវិទ្យាអាចត្រូវបានរួមបញ្ចូលជាមួយប្រព័ន្ធគ្រប់គ្រងតម្រូវការដែលមានស្រាប់ដោយមិនចាំបាច់ចំណាយសំខាន់។

សម្រាប់អ្នកដែលអានដល់ចប់ ភ្ជាប់ទៅវីដេអូដែលបង្ហាញពីរបៀបដែលគំរូដំណើរការ។

ប្រភព: www.habr.com