(An) Embedded Software Requirement Writing and Testing Method = 임베디드 소프트웨어 요구사항 작성 및 테스팅 방법

다국어 초록 (Multilingual Abstract)

In general, the software development process begins with writing the requirement of the stakeholder. Since the system designer designs the software using this requirement, it is important that it be written unambiguously. To do this, a new requirement writing language is needed that is unambiguous, easy to use, and easy to understand. In this dissertation, a Requirement Diagram Language (RDL) is presented, together with its philosophy and major features. The uniqueness of the RDL comes from its simplicity and intuitiveness in describing system requirements. In contrast to other languages that aim to present a graphical requirement description, RDL can completely describe requirements using graphical symbols that are sufficiently intuitive that even novices can understand them. A complete requirement for an embedded system can be built with a collection of simple elementary requirements in RDL. A major advantage of a requirement described in RDL is that the requirement is executable. That is, the requirement itself can be verified or simulated without any other extra information. A case study using RDL to describe an elevator’s requirements is presented.
In this dissertation, I also present a new coverage criterion MC/DC with Definition Clear Path (MC/DC-DCP). Traditionally, many types of coverage criteria are used for generating test cases. In particular, the Modified Condition and Decision Coverage (MC/DC) criterion is known as one of the most powerful methods. However the MC/DC does not sufficiently reflect the dependency between two different modules. To overcome this disadvantage, I adopt flow driven coverage criteria to MC/DC. By applying MC/DC-DCP, the data dependencies between two different modules are considered in the MC/DC coverage criterion. Since the MC/DC-DCP is more powerful than MC/DC, it is appropriate for a safety critical system. The analysis of difference coverage criteria on several requirement examples is presented.
Finally, this dissertation introduces the tools of R-Bench, which is a commercial product for designing, verifying and testing embedded systems. REED (Requirement Editor), which is the requirement management tool using RDL for writing requirements, and TE (Test Executor), which is the automatic test execution tool, are presented. REED has several features, such as a requirement analyzer, unit-tester, source code generator, requirement manager, natural language translator and so on. Using the TE, a test engineer can execute the test automatically in batches. The TE shows the status of the SUT during test execution. If there are faults, these show up in real-time. The faults are recognized by comparing the SUT outputs and the oracle, which is generated automatically.

목차 (Table of Contents)

• Acknowledgement i
• Abstract iv
• List of Contents vi
• List of Figures ix
• List of Tables xi
• List of Abbreviations xii
• 1. Introduction 1
• 1.1. Requirement Writing Method 2
• 1.2. Test Coverage Criteria 6
• 1.3. Dissertation Structure 8
• 1.4. Contributions 9
• 2. Related Work 10
• 2.1. Requirement Writing Method 10
• 2.1.1. Natural Language 11
• 2.1.2. Linear-time Temporal Logic (LTL) 12
• 2.1.3. Software Cost Reduction (SCR) 13
• 2.1.4. Petri-Nets 15
• 2.1.5. Object-Process Network (OPN) 16
• 2.1.6. Unified Modeling Language (UML) [14] 17
• 2.1.7. Simulink [15] 19
• 2.1.8. Requirement writing & modeling methods summary 20
• 2.2. Test Case Generation 23
• 2.3. Test Coverage Criteria 25
• 2.3.1. Code based coverage criteria 25
• 2.3.2. The coverage criteria on a State diagram 28
• 2.3.3. Control-flow driven coverage criteria 29
• 2.3.4. Data-flow driven coverage criteria 30
• 3. RDL - Requirement Diagram Language 32
• 3.1. Motivation 32
• 3.1.1. Using graphic operation blocks to minimize obscurity 32
• 3.1.2. Executable requirement 34
• 3.2. The notations of Requirement Diagram Language 35
• 3.2.1. Basic Notations 35
• 3.2.2. Basic operation blocks 36
• 3.2.3. Entity Definition 40
• 3.2.4. Writing values on the link 41
• 3.2.5. Requirement Hierarchy 44
• 3.2.6. Before-values and After-values 47
• 3.2.7. State diagram 47
• 3.3. The simulator for RDL 50
• 4. Requirement Test Coverage 53
• 4.1. Well-known coverage criteria for RDL 53
• 4.1.1. Statement Coverage for RDL 53
• 4.1.2. Decision Coverage for RDL 54
• 4.1.3. Condition Coverage for RDL 55
• 4.1.4. MC/DC Coverage for RDL 55
• 4.2. MC/DC Criterion with Def-Clear Path 60
• 4.2.1. Motivation & Definition 60
• 4.2.2. MC/DC-DCP on RDL 62
• 4.2.3. Advantages of MC/DC-DCP 64
• 5. Test Framework & Tools 65
• 5.1. Requirement Editor 66
• 5.1.1. Requirement Description Features 67
• 5.1.1.1. Requirement Description Window 67
• 5.1.1.2. Describing the requirement with a state diagram 69
• 5.1.1.3. Describing the requirement hierarchically 69
• 5.1.1.4. Describing a requirement with a table 70
• 5.1.1.5. Describing a requirement with a function 71
• 5.1.2. Requirement Analyzer 73
• 5.1.3. Translation Features 74
• 5.1.4. Requirement testing using the Unit-Tester 76
• 5.1.5. Source-code generation 76
• 5.1.6. Requirement management 77
• 5.2. Test Executor 78
• 5.2.1. Test script format 79
• 5.2.2. The features of Test Executor Client 81
• 5.2.2.1. Test execution control & monitoring 82
• 5.2.2.2. Test Result Analysis 82
• 5.2.3. Test Executor Server 85
• 6. Empirical Analysis 86
• 6.1. Case study of RDL 86
• 6.1.1. Hierarchical requirement 86
• 6.1.2. Intuitive description 89
• 6.1.3. Executable requirement and analysis 90
• 6.1.4. Translation 90
• 6.2. Test Coverage Analysis 91
• 6.3. Discussion of the analysis 94
• 7. Conclusion 95
• References 98