← Барлық мақалаларға оралу

NASA-ның cyclomatic complexity туралы critical lessons: неге simple code өмір сақтайды

Жарияланды

Boeing CST-100 Orbital Flight Test failures кейін software metric space missions үшін қалай crucial болды.

Boeing Crew Space Transportation (CST)-100 Orbital Flight Test critical software failures болғаннан кейін NASA Chief Engineer Ralph Roe NASA software testing requirements жеткіліксіз болуы мүмкін деп concern көтерді. Serious errors flight-қа дейін undetected қалуы unacceptable еді.

Бұл concern NASA Engineering and Safety Center (NESC) ұйымын safety-critical software ішінде cyclomatic complexity және basis path testing зерттеуге алып келді.

Cyclomatic Complexity деген не?

Cyclomatic complexity - code control flow graph негізінде code арқылы өтетін independent paths санын өлшейтін software metric. Мұны decision points санау деп елестетуге болады: if, while, for және switch сияқты constructs complexity қосады.

Basic formula:

Cyclomatic Complexity = Number of Decisions + 1

Conditional statements жоқ function complexity 1 болады, өйткені оның one straight path бар. Бір if statement қоссаңыз, complexity 2 болады: condition true болғандағы path және false болғандағы path.

Екі nested single-condition if statements немесе екі conditions бар бір if complexity 3 береді.

NASA Study: Real-World Impact

NESC assessment үш major software sets қарастырды:

  • Space Launch System (SLS) Flight Software.

  • Core Flight Software (CFS) bundle және applications.

  • Autonomous Power Controller (APC) system.

Results functions complex болған сайын testing effort қаншалықты тез өсетінін көрсетті.

Complexity уақыттық құны

NASA APC developers-тен different complexity levels бар functions үшін basis path testing орындауды сұрады. Documented total effort:

  • Complexity 5: 45 minutes.

  • Complexity 9: 1.65 hours.

  • Complexity 28: 31 hours.

Complexity 28 function тестілеуге 30 hours-тен көп уақыт алды, ал developer full coverage achieved болды деген confidence тек 30% деп estimate етті. Lower-complexity functions үшін confidence estimate 100%-ға жақын болды.

Бұл universal formula proof емес, small practical evaluation еді, бірақ highly complex control flow testing-ке қандай burden әкелетінін clearly demonstrated етті.

SLS success story

SLS Flight Software coding standard cyclomatic complexity 20-дан higher болмауын талап етті. Threshold жоғары units reworked болуы немесе waiver алуы керек еді, large switch statements үшін exception allowed болды.

Result SLS flight software бойынша average complexity шамамен 2.9 болды. Legacy guidance, navigation және control code бөлігі үшін only one waiver processed болды.

Неге limit 15 болды

NASA practices, military requirements, industry standards және academic research review жасағаннан кейін assessment team safety-critical software үшін 15 maximum cyclomatic complexity таңдады.

Report бірнеше reference points атап өтті:

  • U.S. Air Force: complexity level 15-20.

  • Industry and academic examples, MISRA, AUTOSAR, HIS және JSF AV++ қоса: requirements 10-20 range ішінде.

  • Practical testing: lower complexity verification және testing жеңілдетіп, жылдамдатады.

Team complexity alone қолданылмауы керек екенін де stressed етті. Architectural complexity, code and requirements changes және defect density де маңызды.

Cyclomatic Complexity үш түрі

Report үш common variants талқылайды:

  • Standard (CC1): decisions + 1, basic measure.

  • Strict (CC2): compound Boolean expressions ішіндегі individual conditions санайды, metric stricter болады.

  • Modified (CC3): multi-branch switch-ті standard measure-ден lenient қарайды.

Assessment team бір variant міндеттемеді. Projects өз needs-іне fitting version таңдай алады, бірақ choice consistent және justified болуы керек.

Сандардан тыс: шын мәнінде не маңызды

Line count емес

Decisions жоқ 100-line function complexity 1 болуы мүмкін, ал nested conditions бар 10-line function much higher complexity иеленуі мүмкін.

Lines of code cyclomatic complexity-ті directly көрсетпейді.

Architecture та маңызды

Simple functions та highly interdependent болса problematic болуы мүмкін. NASA function-level complexity-ден beyond қарауды және мына factors tracking етуді emphasized етті:

  • Code churn: code қаншалықты жиі өзгереді.

  • Inter-module dependencies.

  • Architectural complexity.

  • Defect density және requirements changes.

Individual functions complexity азайту overall architecture-ны more tangled етпеуі керек.

Testing revolution

NASA basis path testing-ті Modified Condition/Decision Coverage (MC/DC)-пен салыстырды. Evaluated functions ішінде MC/DC:

  • More complex cases үшін 30-50% less time required етті.

  • Redundant path testing азайтты.

  • Functional және requirements testing-пен combined болғанда safety-critical software үшін more robust approach берді.

  • DO-178C сияқты safety-critical aviation guidance ішінде already established болды.

MC/DC decision ішіндегі every condition decision outcome-ға independently affect ете алатынын verifies етеді. Ол every possible combination of conditions қажет етпей strong coverage aim етеді.

Tools of the Trade

NASA cyclomatic complexity calculating немесе working with tools қарастырды.

Free Options

  • University of Southern California жасаған Unified Code Counter (UCC).

  • Кейбір IDEs және development toolchains ішіндегі complexity metrics.

Commercial Solutions

  • CC1, CC2 және CC3 analysis әрі complexity visualizations үшін Scientific Toolworks’ Understand.

  • Coverity және CodeSonar сияқты static analysis products.

  • MC/DC testing үшін LDRA және VectorCAST сияқты coverage tools.

Specific tool consistent measuring және analysis-ті development workflow ішіне integrating етуден less important.

Alternative Viewpoint

Assessment team ішінде complexity bounding code quality жақсартудың most effective way екеніне бәрі келіспеді. Gerard Holzmann disciplined engineering practices-ке focused alternative viewpoint ұсынды:

  • Risk reduction aimed rigorous coding standards.

  • Every build үстінде бір немесе preferably multiple strong static analyzers.

  • All compiler warnings highest level-да enabled және zero warnings produced.

  • Average assertion density at least 2%.

  • Higher-level requirements-тен derived tests, MC/DC coverage analysis-пен бірге.

Бұл маңызды reminder: complexity threshold - guardrail, sound engineering substitute емес.

Practical Recommendations

NASA findings негізінде:

  1. Safety-critical code үшін complexity limit 15 қойыңыз.

  2. Limit-тен жоғары кез келген function-ды testability, maintainability және code quality бойынша assess етіңіз.

  3. Safety-critical functions үшін functional және requirements testing-пен бірге MC/DC testing қолданыңыз.

  4. Code churn, dependencies және architectural complexity track етіңіз.

  5. Every build үстінде static analyzers run етіп, compiler warnings zero ұстаңыз.

  6. Style rule satisfy етуден гөрі reducing risk фокусында болыңыз.

The Bottom Line

NASA study complex code тек harder to read емес екенін көрсетті: оны confidence-пен test ету dramatically harder болуы мүмкін. Software hazardous systems controls еткенде, cyclomatic complexity manageable сақтау mission assurance бөлігіне айналады.

Келесі жолы already complex function ішіне “тағы бір condition” қосқыңыз келгенде, simpler control flow thorough testing-ті achievable ететінін есте сақтаңыз.

Source: NASA’s Cyclomatic Complexity and Basis Path Testing Study, report NASA/TM-20205011566, NESC document NESC-RP-20-01515.