Download Requirements Traceability in Smart Building Applications using UML Class Diagrams - Prof. and more Papers Engineering in PDF only on Docsity!
ABSTRACT
Title of Document: METHODOLOGY AND SOFTWARE PROTOTYPE FOR ONTOLOGY-ENABLED TRACEABILITY MECHANISMS Cari Bever, Master of Science in Systems Engineering, 2006 Directed By: Dr. Mark Austin, Associate Professor, Civil & Environmental Engineering; Affiliate Associate Professor, Institute for Systems Research; University of Maryland at College Park Due to the rapid advancement of technology, industrial-aged systems are being replaced by information-based models through system integration, where hardware and software are combined by a variety of communication means. As engineering systems become progressively complex, the challenge is to fully understand and implement the connectivity relationships among various models of visualization so that catastrophic and expensive failures of engineering systems can be avoided. In order to achieve these connectivity relationships, this project inserts a new notion called “Design Concepts” in the traceability link between the already connected requirements and engineering objects, where rule-checking may be embedded into the design concepts. A software prototype of the Washington, D.C. Metro System has been built to illustrate the feasibility of connectivity between requirements, UML class diagrams and an engineering model. The software makes use of listener-driven events, which are a scalable and efficient method for establishing traceability links and responding to external user events.
METHODOLOGY AND SOFTWARE PROTOTYPE FOR ONTOLOGY-ENABLED
TRACEABILITY MECHANISMS
By Cari E. Bever Thesis submitted to the Faculty of the Graduate School of the University of Maryland, College Park, in partial fulfillment of the requirements for the degree of Master of Science in Systems Engineering 2006 Advisory Committee: Dr. Mark Austin, Chair Dr. Jeffrey Herrmann Dr. Guangming Zhang
ii
Acknowledgements
This project would not have been possible without the support of many people. Many thanks to my advisor, Dr. Mark Austin, for his continuous guidance and encouragement throughout my entire thesis project. Also, thanks to Dr. Jeffrey Herrmann and Dr. Guangming Zhang for serving on my thesis committee. Thanks to my mother, Shirley Bever, for all the time she spent proofreading my paper for grammatical errors and also for the never-ending support and encouragement she provided. I would also like to thank Natasha Shmunis and Nicholas Oben for their help with the programming. Finally, I would like to thank my employer Raytheon for giving me the opportunity to receive my Master’s degree in Systems Engineering.
iii
v
- Chapter 1 Introduction Table of Contents
- 1 Problem Statement
- 2 Traceability Mechanisms and Models
- 3 State-of-the-Art Requirements Modeling and Visualization..............................
- 4 Proposed Approach
- 5 Smart Building Application...............................................................................
- 6 Ontologies and Ontology-Enabled Computing.................................................
- 7 Framework for Interactive Ontology-Enabled Design.....................................
- 8 Project Scope and Objectives
- Chapter 2 Design Concept Modeling with UML........................................................
- 1 Development of System-Level Design Representations....................................
- 2 Representing Ontologies with UML Class Diagrams
- 3 Relationships between Classes...........................................................................
- 4 Human-Ontology Interaction and Processing
- Chapter 3 Software Architecture Design....................................................................
- 1 Software Architecture Design
- 2 Graphical User Interface (GUI) Design and Traceability Support
- 3 Listener-Driven Events Using the Java DEM...................................................
- 4 Violet UML Editor.............................................................................................
- Chapter 4 Application: Washington, D.C. Metro System..........................................
- 1 Washington, D.C. Metro System.......................................................................
- 2 Requirements Panel........................................................................................... iv
- 3 UML Class Diagram Panel................................................................................
- 4 Metro System Engineering Model Panel...........................................................
- 5 Traceability Connections...................................................................................
- 4.5. 1 Interaction with the Requirements Panel...................................................
- 4.5. 2 Interaction with the UML Panel.................................................................
- 4.5. 3 Interaction with the Engineering Drawing Panel
- Chapter 5 Conclusion..................................................................................................
- 1 Conclusions
- 2 Future Work
- Bibliography
- Figure 1. 1 : Meta-model for Low-End Users of Traceability....................................... List of Figures
- Figure 1. 2 : Modeling Translational Mappings Across Hierarchies in SLATE
- (TRAMs) in SLATE............................................................................................ Figure 1. 3 : Modeling and Graphical Representation of Translational Mappings
- Figure 1. 4 : Inheritance and Blocking Mechanisms in SLATE..................................
- Figure 1. 5 : Simplified View of State-of-the-Art Traceability and Proposed Model
- Figure 1. 6 : Modeling of a Wireless Network in a Smart Building
- Figure 1. 7 : Progressive Decomposition of Architectural Floorplans.........................
- Augmented with Network Services.................................................................... Figure 1. 8 : Framework for Multi-Level Development for Building Architectures
- Concepts to Multi-Level Representations of Building Architecture.................... Figure 1. 9 : Pathways from Requirements to UML Representations of System
- Figure 1. 10 : Semantic Web Layer Cake Technologies and their Maturity
- Figure 1. 11 : Present-day and Proposed Graphical User Interfaces............................
- Figure 1. 12 : Multiple Conceptual Interpretations of a Single Design Object
- Figure 1. 13 : Schematic of Viewpoint Interaction.....................................................
- Figure 2. 1 : Magic Square of System Development
- Figure 2. 2 : Definition of Classes for Software and System-Level Design
- Figure 2. 3 : Hierarchy and Network Abstractions for SE Development.....................
- Figure 2. 4 : Hierarchy and Network Abstractions for SE Development.....................
- Figure 2. 5 : Pathway from Meta-meta-models to Engineering Models and Systems..
- Figure 2. 6 : Roles of the Meta-Meta-Model and Meta-Model in System Assembly...
- Figure 2. 7 : Meta-model for Association and Link Relationships
- Figure 2. 8 : Binary Associations in UML: Meta-Model and Example.......................
- Figure 2. 9 : Association Relationships in UML
- Figure 2. 10 : Multiplicity Relationships in UML
- Figure 2. 11 : Inheritance, Composition and Aggregation Relationships in UML.......
- Figure 2. 12 : Connectivity between the Specification and Physical Models vi
- Figure 2. 13 : Step-by-Step Implementation of Ontology Processing Machine...........
- Figure 3. 1 : Overview of System Architecture Requirements....................................
- Figure 3. 2 : GUI Layout
- Figure 3. 3 : Connection of XML to the GUI
- Figure 3. 4 : One Listener Registered to One Source..................................................
- Figure 3. 5 : Many Listeners Registered to one Source
- Figure 3. 6 : One Listener Registered to Many Sources..............................................
- Figure 3. 7 : Circles Example utilizing Event Listeners..............................................
- Figure 3. 8 : System Response for Mouse Over "Small Circle" Rectangle..................
- Figure 3. 9 : System Response for Mouse Over Small Circle
- Figure 3. 10 : Example of a Class Diagram from Violet.............................................
- Figure 4. 1 : Washington, D.C. Metro System (Washington, 2006 )............................
- Class Diagram, and Engineering Drawing.......................................................... Figure 4. 2 : Washington, D.C. Metro System Application - Requirements Panel, UML
- Figure 4. 3 : Requirements in XML
- Figure 4. 4 : UML Class Diagram of Metro System...................................................
- Figure 4. 5 : UML Class Diagram Saved in XML......................................................
- Figure 4. 6 : Engineering Drawing of the Washington, D.C. Metro System................
- Figure 4. 7 : XML Fragment for D.C. Metro Stations
- Figure 4. 8 : XML Fragment for D.C. Metro Tracks
- Figure 4. 9 : XML Fragment for D.C. Metro Lines
- Figure 4. 10 : Tracing Requirements to UML Diagram and Engineering Model.........
- Figure 4. 11 : Verifying the First Requirement...........................................................
- Requirements..................................................................................................... Figure 4. 12 : Tracing UML Class Node to Objects in Engineering Model and
- Figure 4. 13 : Tracing Engineering Model to UML Diagram and Requirements.........
- Figure 5. 1 : Screendump of the PaladinRM Graphical User Interface (GUI)
- Figure 5. 2 : Definition and Evaluation of System Assembled from Simple Shapes
- Figure 5. 3 : Definition and Evaluation of a Simple Assembly
- Figure 5. 4 : Definition and Evaluation of Spatial Relations Among Shapes
Chapter 1 Introduction
1. 1 Problem Statement
The post-event analysis of recent engineering system failures indicates that, often, the underlying cause of catastrophic and expensive failures is minor mistakes or omission in communication of design intent (e.g., errors in the use of engineering units; errors in the placement of electronic devices on a drawing; logic errors in the implementation of software). The importance of this problem stems from the wide array of engineering applications that have failed in this way. Examples include spacecraft, automated baggage handling systems at airports, and networked services in modern building environments (Jackson, 20 06; Jones, 20 04; Sawyer, 1999 ). The difficulty in finding a good solution to this problem is due, in part, to industrial-age systems being replaced by information-age systems. As pointed out by Whitney (Whitney, 1996 ) in the mid 1990s, industrial-age systems tend to be dominated by hardware. Most hardware systems have continuous behavior that can be described by differential equations; generally, a small change in an input parameter will lead to a finite change in the system response. Designers can use safety factors to deal with uncertainties in system properties, behavior and design. Information-age systems, in contrast, tend to be dominated by combinations of hardware, software and communications, which together are required to provide new types of services, superior levels of performance, and work correctly with no errors. There are a number of reasons why satisfaction of these goals can be particularly difficult. First, when new
technologies are weaved together to achieve new types of functionality, systems can fail in new and unprecedented ways. In the late 1990s, for example, NASA certainly did not anticipate that a miscommunication of engineering units would lead to one of their spacecraft crashing into the surface of Mars. Second, correct functionality for software and communications systems is defined by logic (not differential equations). Not only does the concept of “safety factors” not apply, but as observed in a number of engineering system failures, a small fault in the software implementation can trigger (or result in) system level failures that are very costly and, sometimes, even catastrophic. At a first glance it is tempting to think “well, most errors are caused by bugs in the software – they can be fixed with more careful programming.” Jackson (Jackson, 2006 ) reports, however, that almost all grave software problems can be traced back to conceptual mistakes made before the programming was initiated. This project is motivated by the premise that solutions to this class of problems will require better techniques for the representation, communication, visualization, and evaluation of engineering requirements attached to multidisciplinary engineering models (mathematical abstractions) and drawings (visual abstractions). These new techniques will need to operate within the bounds of established engineering and systems engineering practices – multi-disciplinary team-based design; use of multiple representations; support for multiple viewpoints (Peak, 1998 ). The CTO of Bentley Systems, a leading provider of architectural design software, notes that architectural/engineering firms need to move from “drawings” to “building information models,” the latter being capable
are too many places to capture information (in the large number of available diagrams), and too few ways to show relationships between the diagrams (Berkenkotter, 20 03). Moreover, recent history tells us that the benefits of UML are unlikely to be appreciated by upper-level management and discipline-specific engineers – instead, issues need to be explained in terms with which they are already familiar. Part 1. Diagrams in UML 2 Structure Diagrams Behavior Diagrams Class Diagram Activity Diagram Component Diagram Use Case Diagram Object Diagram State Machine Diagram Composite Structure Diagram Interaction Diagrams Package Diagram Sequence Diagram Deployment Diagram Communications Diagram Timing Diagram Interaction Overview Diagram Part 2. Diagrams in SysML Structure Diagrams Behavior Diagrams Block Diagram Activity Diagram Block Definition Diagram (extends UML Activity Diagram) (extends UML Class Diagram) Use Case Diagram Internal Block Diagram State Machine Diagram (extends UML Composite Structure Diagram) Sequence Diagram Parametric Constraint Diagram Parametric Definition Diagram Cross-Cutting Diagrams Parametric Use Diagram Allocation Diagram Package Diagram (extends UML Package Diagram) Requirement Diagram Table 1. 1 : Types of Diagrams in UML 2 and SysML. ( 1 ) Structure and Behavior Diagrams in UML 2 ; ( 2 ) Structure, Behavior, and Cross-Cutting Diagrams in SysML
These gaps will not be bridged unless a method is found to use UML (and its extensions) in concert with discipline-specific models and notations (e.g., visualization of requirements; block diagrams; two- and three-dimensional engineering schematics). Therefore, the key tenet of the proposed work is that end-to-end development of engineering systems will occur through multiple models of visualization networked together. Looking ahead, there will still be a need for development of web-centric, graphically driven, computational platforms dedicated to system-level planning, analysis, design and verification of complex multidisciplinary engineering systems. These environments will employ semantic descriptions of application domains and use ontologies to enable validation of problem domains and communication (or mappings) among multiple disciplines. The abstraction of multiple disciplines to properly annotated information representations and reuse of previous work at all levels of development will be essential. Present-day systems engineering methodologies and tools are not designed to handle projects in this way.
1. 2 Traceability Mechanisms and Models
As engineering designs become progressively complex, the task of understanding the connectivity relations among various parts of the design becomes increasingly difficult. Traceability mechanisms allow for an understanding of how and why various parts of the system development process are connected, thereby providing the development team greater confidence in: (1) Meeting objectives; (2) Assessing the impact of change; (3) Tracking progress;
High-End Traceability Models. Industry experience indicates that high-end users of traceability tend to have problems that require, on average, about 10, 000 requirements (viewed as a major opportunity for customer satisfaction and knowledge creation throughout the system lifecycle) (Balasubramaniam, 2001 ). They view traceability as an opportunity to increase the probability of producing a system that meets all customer requirements, is easier to maintain, and can be produced within cost and on schedule. High-end traceability employs much richer schemes of traceability (e.g., capture of discussion issues, decisions and rationale product-related and process-related dimensions) than their low-end counterparts. Traceability pathways of rationale enable accountability (e.g., what changes have been made; why and how they were made), particularly to stakeholders not directly involved in creation of the requirement.
1. 3 State-of-the-Art Requirements Modeling and
Visualization
In an ideal setting, project participants should be able to view design data/information in a manner with which they are familiar and easily understand “connectivity relations” and transitions among viewpoints and the rationale for establishing the connections in the first place. Unfortunately, state-of-the-art capability in requirements modeling and visualization falls well short of this vision. As a case in point, the Teamcenter (SLATE) Requirements Tool is based upon very good data representations for connecting cause-and-effect relationships among “abstraction blocks” (ABs) in multiple viewpoints (i.e., TRAMS ==
translational mappings). Figure 1. 2 shows, for example, the use of TRAMs to link requirements, electrical, mechanical and software viewpoints. The underlying graphical support is weak in the sense that all design entities are simply referred to as abstraction blocks (ABs). Moreover, to date, no one has been able to figure out how to actually organize and visualize the subsystem viewpoints on a computer as illustrated in Figure 1. 2. Figure 1. 2 : Modeling Translational Mappings Across Hierarchies in SLATE. The example shows use of TRAMs to link Requirements, Electrical, Mechanical and Software Viewpoints
Figure 1. 4 : Inheritance and Blocking Mechanisms in SLATE. Three cases: ( 1 ) Abstraction block 1 complies with requirements R 1 and R 2 , ( 2 ) Abstraction block 2 complies with requirement R 1 , but not R 2 , ( 3 ) Abstraction block 3 is defined by R 3 – it also complies with R 1 through the TRAM mechanism.
1. 4 Proposed Approach
The upper half of Figure 1. 5 shows a simplified representation for how requirements are connected to design elements in state-of-the-art traceability (i.e., traceability links connect requirements directly to design objects). State-of-the-art traceability mechanisms portray that a specific requirement is satisfied by a specific design object (or group of design objects). Or alternatively, looking backwards, this specific design object is included because it will satisfy that design requirement. The lower half of Figure 1. 5 shows the proposed model that will be explored in this work. Instead of directly connecting requirements to design objects, a new node called “Design Concept” will be embedded in the traceability link. Assembly of traceability links will be conducted by asking “what
concept should be applied to satisfy this requirement?” Solutions to this question establish links between requirements and design concepts. It is assumed that the design itself will correspond to the application of appropriate concepts. Thus, the links between design concepts and engineering objects represent actual implementations of concepts. Figure 1. 5 : Simplified View of State-of-the-Art Traceability and the Proposed Model From a validation and verification viewpoint, the key advantage of the proposed model is that software for “design rule checking” can be embedded inside the design concepts module. Thus, rather than waiting until the design has been fully specified, this model has the potential for detecting rule violations at the earliest possible moment. Moreover, if mechanisms can be created to dynamically load design concept modules into computer-based design environments, then rule checking can proceed even if the designer is not an expert in a particular domain. From a modeling and visualization standpoint, this approach opens the door to improved methods for the visualization of requirements with respect to design
