The Influence of Software Module Systems on Modular Verification [chapter]

Harry C. Li, Kathi Fisler, Shriram Krishnamurthi
<span title="">2002</span> <i title="Springer Berlin Heidelberg"> <a target="_blank" rel="noopener" href="" style="color: black;">Lecture Notes in Computer Science</a> </i> &nbsp;
The effectiveness of modular model checking for hardware makes it tempting to apply these techniques to software. Existing modular techniques have been driven by the parallel-composition semantics of hardware. New architectures for software, however, combine sequential and parallel composition. These new, feature-oriented, architectures mandate developing new methodologies. They repay the effort by yielding better modular verification techniques. This paper demonstrates the impact of
more &raquo; ... ented architectures on modular model checking. We have implemented an explicit-state model checker and applied it to a real software system to validate our prior, theoretical work on feature-oriented verification. Our study highlights three results. First, it confirms that the state-space overhead arising from our methodology is minimal. Second, it demonstrates that feature-oriented architectures reduce the need for the property decompositions that often plague modular verification. Third, it reveals that, independent of our methodology, feature-oriented designs inherently control statespace explosion. the mission. As the code corresponding to a single mission may not be cleanly isolated in the original code (since multiple missions may involve similar decision-making processes), this editing operation is potentially expensive (not to mention error prone). With feature-oriented modules, in contrast, each module encapsulates code for a mission centered around a particular weapon under a certain set of conditions. To remove a weapon from the system, a programmer can simply re-compose the system without the missions (modules) that use a weapon; the original implementor performed the necessary decomposition, so no editing of code is required. Feature-oriented modules have been called collaborations, since a module encapsulates the code through which the actors collaborate to perform an operation. We adopt the term collaboration in the rest of this paper. In FSATS, each actor/mission code fragment is a class. A collaboration is therefore an ordered tuple of classes, one per actor. Collaboration composition connects the classes for each actor via object-oriented inheritance. The resulting (single) class contains all of the code needed to implement each mission for that (single) actor. FSATS's requirement of flexible personnel hierarchies mandates that classes within collaborations have parameterized super-classes. For example, assume that battalion leaders report to brigade leaders in one simulator and to division command in another. These simulators require different collaborations for their core communications protocols. A designer implementing a mission involving battalions does not know which communication collaboration to use; that decision happens at system-composition time. 1 The designer therefore cannot fix the super-classes of the classes in his collaboration; he can, however, impose constraints on them through interfaces. Classes with parameterized super-classes are called mixins [10, 22, 38, 42] . Collaborations comprised of mixins provide the flexibility needed to implement FSATS. Different FSATS simulators are built by selecting weapons and communications collaborations and composing them to form a complete simulator. As described here, collaborations obey the characteristics of components [22] , such as separate compilation, multiple instantiability and external linkage. A brief sampling of other successful designs in this domain includes protocol layers and database modules [7, 8, 41] , a programming environment [17] , test-bench generators [25] and verification tools [21, 39] . The growing application of collaboration-based architectures also reflects in the increased language support for programming with collaborations [6, 22, 34] . A Formal Model of FSATS Having motivated the overall architecture of FSATS, we now describe a more formal model of collaborations, their interfaces, and their compositions that we use in our verification methodology. In FSATS, two pieces of code implement a particular actor's role in a mission. The first is a state machine fragment that specifies a mission-specific communication protocol. The second is a set of rules that govern whether an actor is equipped to accept a particular mission (based on his weapons' status and capacity). Our case study verifies properties of the communication protocol, not of the weapons selection rules. We therefore adopt a simpler view of FSATS in which each collaboration 1 In other words, collaborations are composed through client-controlled or third-party linking.
<span class="external-identifiers"> <a target="_blank" rel="external noopener noreferrer" href="">doi:10.1007/3-540-46017-9_7</a> <a target="_blank" rel="external noopener" href="">fatcat:lqt6iu44cbfjfixfknb65wrsyi</a> </span>
<a target="_blank" rel="noopener" href="" title="fulltext PDF download" data-goatcounter-click="serp-fulltext" data-goatcounter-title="serp-fulltext"> <button class="ui simple right pointing dropdown compact black labeled icon button serp-button"> <i class="icon ia-icon"></i> Web Archive [PDF] <div class="menu fulltext-thumbnail"> <img src="" alt="fulltext thumbnail" loading="lazy"> </div> </button> </a> <a target="_blank" rel="external noopener noreferrer" href=""> <button class="ui left aligned compact blue labeled icon button serp-button"> <i class="external alternate icon"></i> </button> </a>