Development of Bayesian Networks from Unified Modeling Language Artifacts
Total Page：16
File Type：pdf, Size：1020Kb
Development of Bayesian Networks from Unified Modeling Language Artifacts Kathryn Blackmond Laskey Philip S. Barry Peggy S. Brouse Dept. of Systems Engineering The MITRE Corporation Dept. of Systems Engineering George Mason University 1820 Dolley Madison Blvd. George Mason University Fairfax, VA 22032-4444 McLean, VA 22102-3481 Fairfax, VA 22032-4444 [email protected] [email protected] [email protected] Abstract effort and often stage the design and implementation of This paper examines how Bayesian Networks can be key features to meet release schedules and budgetary generated from development artifacts intrinsic in the constraints. In practice, determining which Use-Cases are Unified Process. The Unified Software Development architecturally significant and how they may relate to Process models the relationship between functional other Use-Cases as well as additional system requirements in the Use-Case model. These relationships requirements is usually determined by heuristic methods. are expanded in the Analysis Model and a clear mapping We assert by exploiting the implicit structure in UML to design components is created. By exploiting the diagrams an algorithmic and mathematically sound relationships intrinsic in the Use-Case Model, as well as method can be introduced to understand the importance of the stereotypical classes and temporal ordering found in use requirements represented as Use-Cases as well as the the analysis model, Bayesian networks that represent system requirements they imply. system requirements can be generated. These networks can then be used to model and assess the architectural 2 Use-Cases: The Requirements Side of UML impact of the requirements early in the system lifecycle, According to Ivar Jacobson [12] “it is absurd to believe thus promoting a more efficient and effective system that the human mind can come up with a consistent and design process. Formal capture of requirements during relevant list of thousands of requirements of the form design also promotes reusability of design knowledge “The system shall…”. The futility of direct specification across similar system. has led to a search for more human-friendly ways to develop system requirements. A highly promising and 1 Introduction popular approach is to develop requirements from a set of Within systems engineering it is well recognized that Use-Cases. Use-Cases represent functionality of the effective requirements analysis and documentation is system in terms of prototypical problems or processes the essential to the development of high performing and system is expected to execute. Thus, a Use-Case reliable systems [4]. This is equally true in software represents one distinct way of using the system from a engineering, where requirements management is generally given external agent or actor’s view. Use-Cases are recognized as a key indicator of organizational maturity generally specified using a graphically based [18]. Methodologies for developing and documenting methodology for defining the actions the system is to software requirements [e.g., 8,11,19,21] have proliferated perform. Analyzing the functionality needed for in the literature and have been employed with varying successful execution of the Use-Case then derives system degrees of success. requirements. The Unified Modeling Language (UML) [5] is rapidly A Use-Case specifies a primary sequence of actions the becoming the de facto standard for analysis and design system is to perform, and may also include excursions within the software development community. UML from the main sequence. Use-Cases have operations and provides a diagrammatic approach to describing user attributes. Thus, a Use-Case description can include state requirements, which begins with Use-Cases and then chart diagrams, collaborations and sequence diagrams. leads into more formal specification using stereotypical Use-Case attributes represent the values that a Use-Case classes in an analysis model. Key elements of these instance uses and manipulates. Use-Case instances do not artifacts form the basis for architectural views into the interact with other Use-Case instances because by design system as well as providing the groundwork for design, Use-Case models should be simple and intuitive. The implementation and validation and verification. flow of events and special requirements are captured in special textual descriptions. From an architecture viewpoint, all Use-Cases are not equally important, necessitating the need to develop a 2.1 Structuring the Use-Case Model scheme to prioritize the most significant Use-Cases. This System designers can specify relationships between Use- need comes from the requirement to focus the design Cases. These relationships can be used to form interesting structures that can provide evidence to the importance of system requirements contingent upon an agent’s goals is requirements based upon their relationships to other often referred to as allocation and flowdown [9]. requirements. There are three relationships used to model We suggest that requirements engineering can benefit Use-Cases: generalization, extension and inclusion. from a computational mechanism to represent of system requirements to each other and to the user requirements • Generalization between Use-Cases is a kind of that engender them. To achieve this the relationship we inheritance. Use-Cases can perform all behavior define an abstract structure of interrelated system described in the generalizing Use-Case. requirements called a system requirement web (SRW). A • Extension models additions to a Use-Case’s sequence SRW is a directed graph in which the nodes represent of actions. These additions are contingent upon some system requirements and the edges represent relationships conditions being satisfied. between requirements that we call weak implication. We • Inclusion between Use-Cases models the situation say that one node weakly implies another node if it is where the including Use-Case cannot function more likely that the requirement represented by the without the included Use-Case. second node is needed if the first one is. User requirements can trigger a flow of weak implication 3 Analysis Models within a SRW, providing a model for allocation and flowdown of requirements. Within the Unified Software Development Process [12], analysis is used to address previously unresolved issues Previous work by the authors has demonstrated that by analyzing the requirements in depth. Key to analysis Bayesian networks provide a natural computational model is the development of the analysis model, which yields a for SRWs [2,3]. A Bayesian network is both a structured more precise specification of the requirements than representation for knowledge about the interrelationships resulted from the Use-Case model. As the analysis model among uncertain variables and a computational is described in the language of the developers it can architecture for reasoning about these variables. A introduce more formalism and can be used to reason Bayesian network is a directed graph composed of nodes about the internal workings of the system. The analysis and arcs. The nodes represent variables whose value is model can be considered a first cut at a design model and uncertain and the arcs represent dependency relationships is an essential input to system design and implementation. between the variables. In our application, the uncertain variables represent requirements and the arcs represent The analysis model makes use of a number of diagrams. weak implication. A requirement can be in one of two Of particular interest is the collaboration diagram, which states: implied or unimplied (the semantics of these terms describes how a specific Use-Case is realized and is described below). Conditional probabilities are used to performed. The diagram is drawn in terms of model the strength of the relationship between the stereotypical analysis classes and their instantiated associated variables. analysis objects. These objects focus on handling functional requirements and postpone the consideration of As a computational architecture, a Bayesian network nonfunctional requirements by designating them as allows the user or application to declare “evidence” on special requirements. some of the nodes and, through a process called “evidence accumulation,” compute revised probabilities for all other In the analysis phase of the Unified Development process, nodes in the network. In the present application context, there are three stereotypical classes: boundary classes, user requirements can be declared as “evidence” in an entity classes and control classes. Boundary Classes are SRW represented as a Bayesian network. This evidence used to model interaction between the system and its propagates through the SRW via the weak implication actors, e.g., information input and output and can be used links, resulting in updated probabilities for other to clarify system boundaries. Entity Classes are used to requirements in the SRW. model information that is long-lived and persistent, which may have associated behaviors and a logical data Not only are Bayesian networks a useful visual metaphor structure. Control Classes are used to model coordination, to aid in the construction of SRWs, they also sequencing, transactions and control of other objects. appropriately represent a semantics appropriate to the problem at hand. At any given moment in the 4 Bayesian Networks for Requirements requirements definition process, the currently operating Key to fully understanding