In this section, we outline the design flaws our MTS generation process can discover and discuss potential uses of component-level MTSs. Component-level MTSs can facilitate a number of benefits, including: (1) requirements elicitation,
(2) selection of candidate OTS-components, and (3) comparison of designed and implemented components. Discovery of specification discrepancies. The annotation of sequence diagrams (Phase 2) directly exposes two types of potential problems in system specifications: conflicts between the specified scenarios and properties and the presence of inconsistent component states.
Discrepancies between scenarios and properties occur when constraints prohibit the sequence of operations described in a sequence diagram. A discrepancy may be the result of either overly restrictive constraints or misspecified scenarios. Inconsistent states arise when multiple components’ expected values for a significant state variable differ. Requirements elicitation. Eliciting requirements from system-level MTSs, as in , can introduce design flaws because
requirements gathered using a system-level perspective can conflict with what is implementable at the component level. For example, a new scenario extracted from a system-level MTS might only be possible when all participants
have global knowledge. However, this assumption does not hold in component-based systems without incurring significant synchronization overhead.
Replaced/Superseded by document(s)
Early system specifications, such as use-case scenarios
and properties, are rarely complete. Partial models
of system-level behavior, derived from these specifications,
have proven useful in early system analysis. We believe
that the scope of possible analyses can be enhanced by
component-level partial models. In this paper, we outline
an algorithm for deriving a component-level Modal Transition
System (MTS) from system-level scenario and property
specifications. The generated MTSs capture the possible
component implementations that (1) necessarily provide
the behavior required by the scenarios, (2) restrict behavior
forbidden by the properties, and (3) leave the behavior that
is neither explicitly required nor forbidden as undefined. We
discuss how these generated models can help discover system
design flaws, support requirements elicitation, and help
select off-the-shelf components.