Handout for Northrop Grumman, March 6, 2003 By: Mark Austin, Natasha Kositsyna, Vimal Mayank (...with help from Jeff Coriale)
Table of Contents	Contact Information and Project Participants
Major Challenges facing the Practicing Systems Engineer Support for Team Development Synthesis from Modular Components and Subsystems Our Strategy and Approach to System Development. We promote: Orthogoalization of Design Concerns ..... Automation of Multidisciplinary Information-Based Design Current Project Architecture (NSF, NASA Goddard, Lochheed Martin) Overall Project Architecture Areas of Research Focus: Requirements, Design, and Build NSF Viewpoint Case Study Framework and Relevant UML Diagrams Requirements Engineering Methodologies and (Semantic Web) Tools Platform-Independent Diagram Editor (XML/RDF) NASA Goddard Viewpoint Architecture-Level Synthesis and Analysis of a Home Theatre System Writing Requirements and Specifications	Institute for Systems Research, University of Maryland, College Park, MD 20742. Mark's e-mail: austin@isr.umd.edu Natasha's e-mail: kosnat@isr.umd.edu Vimal's e-mail: vmayank@isr.umd.edu Jeff's e-mail: coriale@isr.umd.edu Current Industry Participants: Lockheed Martin, NASA Goddard Space Flight Center.

Support for Team Development Teams of experts from multiple disciplines/domains working together on the solution of complex problems is a common requirement in industry today (e.g., integrated product teams (IPTs)). We need to maintain a shared view of the project objectives, and at the same time focus on specific tasks. See Figure 1. Figure 1. Elements of Team-Based Development A key challenge is avoiding communication and interpretation problems -- everyone needs to know what they are supposed to be working on, and when it's due! Synthesis from Modular Components and Subsystems The prevalence of synthesis from modular components is no longer true just for aerospace, defense and large government contracts (systems engineering started with Aerospace Engineering). Instead it is required in all commercial designs and operations. This so-called ``systems integration'' has become key and perhaps the most profitable engineering practice.

Promote use of Technology-Independent System-Level Design Representations We want to create system-level design representation that are not tied to an underlying implementation technology. This can be achieved, in part, through separate representations for the logical and physical design. Figure 2. Provision for Fomalization and Early Detection of Errors Goal. Hardware and software implementations and specific technology selections are ``pushed'' near the very end (i.e., delayed as long as possible), but are performed once and must work flawlessly. Promote Orthogonalization of Design Concerns -- Function-Architecture Co-Design Emphasize function-architecture co-design. System design alternatives are created by mapping models of system behavior onto tentative system structures. System evaluation and ranking/optimization procedures eliminate the inferior solutions. Figure 3. Evaluation, Ranking, Optimization and Trade-Off Analysis for System Design Alternatives Figure 4 shows the primary tracks of traceability for the development of a system-level product. Figure 4. Traceability Mappings for the Development Pathway, Goals/Scenarios through Eystem Evaluation. For system-level design, traceability begins with the connnection of goals and scenarios with use cases. It links the requirements and specifications with models of system behavior, system structure, and procedures for system evaluation. Traceability can also be applied to the sequence of decisions defining the underlying development process, e.g., traceablity of rationale to specific decisions, decisions to actions items ...etc. In the design of complex engineering systems, "orthogonalization of concerns" coupled with mappings and traceablity simplifies the difficulty in exploring the space of design alternatives. Promote Multi-Representations and Reuse at all levels of Abstraction Abstract multiple disciplines to properly annotated information representations. This is the only way to allow communication among disciplines and multiple contextual views. Figure 5. Layers of Abstraction in Reuse A "general-purpose" information representation that can describe all aspects of system behavior and structure is currently unavailable. Hence, systems must work with multiple information abstractions. For example, at high levels of abstraction -- Unified Modeling Language (UML), Technical drawings, Ontologies (Semantic Web). At lower-levels of abstraction -- three dimensional geometric models, engineering simulation packages ... etc. Enable reuse of designs, architectures and business processes through object-relational database storage. To ensure that the handling of data and information in the synthesis of complex designs is kept in check, it is essential that design domains be modeled with a structure and appropriate level of abstraction that facilitates interpretation, evaluation, and communication of data/information. We want to represent designs in such a way that we can make usefule interpretations of these representations. Deciding what to leave out of a model is just as important as what to include! Designers are used to describing the same design in many different ways. Generally it is easier to think in terms of multiple representations (or multiple views) of the same description rather than a canoncical (catch all) descipription from which all other descriptions can be derived. This is appropriate if the different design representations are put to different uses (which, of course, will occur in team-based design). Promote Automation for Multidisciplinary Information-Based Design We need to find ways to automate the capture and processing of data/information relevant to engineering system development.

Overall Project Architecture

Areas of Research Focus: Requirements, Design, and Build

Natasha will talk about capabilities of the editor, and how we work with XML and RDF to create and save high-level system descriptions (i.e., networks of modules connected by ports and cables).

Vimal will talk about RDF and it's capabilities.

Education: Case Study Framework We would like all of our case studies to have a common system development and design framework: Problem Statement Generation of User Requirements Simplified Models of System Behavior Modeling the System Structure Creating the Logical Design Creating the Physical Design Evaluation and Ranking of System Design Alternatives System Optimization and Tradeoff Analysis Generalizing the Problem Domain for System Reuse References and Web Resources Small Case Study Problems Small case study problems will be developed by students in the MSSE program. Systems Development and Design of a 4-way Traffic Intersection . Systems Development and Design of a Portable CD Player (Tarun Luthra).

Classification of UML Diagrams Major Area View Diagram System Structure Static View Class Diagram Use Case View Use Case Diagram Implementation View Component Diagram Deployment View Deployment Diagram System Behavior State Machine View Statechart Diagram Activity View Activity Diagram Interaction View Sequence Diagram Collaboration Diagram Table 1. Classification of UML Diagrams for each Major Area Tutorial and Case Study Support Material UML Diagram Notation and Semantics Guidelines for UML Diagram Development Glossary of Terms

Research: Requirements Engineering Methodologies and Tools (April 2002 - present)

1. Critical Assessment of Present-Day Systems Engineering Tools (e.g., DOORS and SLATE).

   How do we capture and represent knowledge through requirements engineering activities?

   

   Figure 9. Requirements Engineering Work Breakdown Structure (WBS).

   

   Figure 10. Requirements Engineering WBS and Industry Toolset Weakensses. (For details, see Ramesh and Jarke, 2001)

   Specific Limitations of Present-Day Tools (Selberg, 2002)

   1. Thick Descriptions.
      Current tools lack the ability to store informal representations (i.e., so-called thick descriptions) of systems conveying information along subtle or implied lines.

   2. Model Driven Trace Capture and Usage.
      Current tools lack mechansms for "easy linking" of models into the design environment (e.g., SLATE).

   3. Abstraction Mechanisms.
      Current tools lack the ability to search and explore requirements at various levels of abstraction.

   4. Inference Services.
      The lack of "inference services" in the work breakdown structure impacts the systems engineering process in several ways. Current tools are incapable of analyzing requirements for completeness or consistency. Search mechanisms are limited to keywords, which can be limiting for custom jargon in multidisciplinary and multilingual projects.

   Observations

   1. The glue that holds the system together is the basic modeling methodology.
   2. The loose coupling between knowlede domains and between CAD applications, and between knowledge repositories supports robust ad-hoc incremental development.
   3. Basic web-based infrastructure, which includes web-servers, application servers, and web browsers is already ubiquitous.

The Semantic Web Layer Cake

Figure 11. The Semantic Web Layer Cake (Berners-Lee, 2002).

The Semantic Web is an extension of the current web. It aims to give information a well-defined meaning, thereby creating a pathway for machine-to-machine communication and automated serives based on descriptions of semantics. XML files and web resources capture objects and classes. XML separates structure from presentation. RDF (resource description framework) describes relationships between objects and classes in a general but simple way. RDF separates content from structure, thereby allowing for the merging of multiple conceptual models. Ontologies provide a formal conceptualization (semantic representation) of a particular domain shared by a group of people. Ontology-based applications will be built on top of the Semantic Web infrastructure (i.e., XML, RDF and ontologies)

Transfer of Semantic Web Technologies to Tools for Requirments Engineering

What is the minimum level of Semantic Web Technology that can mitigate (and hopefully overcome) limitations in present-day tools?

Figure 12. Requirements Engineering WBS (Create Branch) to Semantic Layer Cake (Selberg, 2002).

Figure 13. Requirements Engineering WBS (Use Branch) to Semantic Layer Cake (Selberg, 2002).

References

1. Ramesh B., and Jarke M., "Toward Reference Models for Requirements Traceability," IEEE Transactions on Software Engineering, Vol. 27., No. 1., January 2001, pp. 58-93.
2. Selberg S., "Requirements Engineering and the Semantic Web," M.S. Thesis, Institute for Systems Research, University of Maryland, College Park, MD 20742, April 2002.

Software Development: Platform-Independent Diagram Editor (June, 2001--present)

Create a click-and-drop editor for development of "Collections of Java-Enabled Diagrams." knowledge capture for systems engineering is enabled through: (1) Diagram annotation features, (2) Links to heterogenous data and information sources on the web, and (3) File (XML/RDF formats) and database storage.

We are currently working on the right-hand side of this diagram. Future versions of the editor will import of XML representations of diagrams, requirements, and systems stored in commerical databases (e.g., Oracle).

Medium-Term Objectives and Scope

Explore application of Semantic Web Technologies to the team-based synthesis, visualization, and assessment of system-level architectures for multi-disciplinary spacecraft systems. (3 years work). How do we build thse systems engineering tools? What kinds of new capability are possible?

As a first step, we are studying problems associated with the architecture-level synthesis of a home theatre system.

Computational Support for Bottom-Up Synthesis of Systems, enhanced with Component Reuse

Figure 15 shows elements of a top-down/breadth first development (decomposition) followed by a bottom-up implemenation procedure (composition). In the latter half, a key design decision is: should we custom build new components or buy/reuse them. We envision a library (XML database) of object-specification descriptions.

Figure 15. Elements of Top-down and Bottom-Up Development coupled with Component Reuse

The decomposition/composition process proceeds as follows:

System Decomposition

• Begins with a small set of requirements and evolves into detailed requirements and a system-level design. (In producing new designs we start with high-level goals and decompose them into sub-goals. These sub-goals are further decomposed until we reach a set of sub-goals that can be satisfied by a set of design decisions. In the process we must satisfy design constraints, resolve conflicts, handle design failures appropriately and make approriate trade-offs in objectives.) We create the system-level design by mapping models of system behavior onto system structure (system architecture) alternatives.

  The component architecture consists of a set of application-level components, their structural relationships and behavioral dependencies. Behavior is defined in terms of ports and interfaces -- among objects and between objects and the surrounding environemnt -- and their I/O relationships.

  The development of a good system-level architecture is a dependency management problem. We seek to ensure that the components and subsystems developed by different design teams can work together successfully. The key challenge -- how to do this?

• Each sub-system description will be accompanied by a set of requirements (e.g., cost, performance) that must be met for its implementation.

System Composition

• Is concerned with the implementation and testing of the system design. For each sub-system and/or system module, a key design decision is: should we custom build a new component or can be buy/reuse it.
• For reuse of components to occur, the specifications associated with the components must be logically consistent with the sub-system design requirements.

The economic benefits of reuse in software are well known. The research challenge we face is how to create a object-specification framework, together with software tools, that will enable reuse across a broader spectrum of engineering systems. Tools are needed for:

• Checking the logical consistency of objects and sub-system requirements.
• Searching databases of objects that satisfy a certain set of specification criteria.

Research questions to be answered:

• We need a formal language framework for project requirements and specifications. What role can UML and XML and RDF play?
• We need a formal language to describe system assemblies. We will start with a system-port model for the architecture-level description of modules.

Writing Requirements and Specifications

Requirements and specifications need to be written in a manner that balances two key aspects: (1) they should be readable, and (2) they should lend themselves to various forms of automated processing.

Table 2 summarizes the key features of requirements and specifications.

Organizing requirements into the right structure can help:

• Minimize the number of requirements (i.e.. eliminate redundant requiremnts).
• Find sets of requirements relating to a particular topic.
• Detect omissions, duplications and inconsistencies.
• Eliminate conflicts among requirements.

Attaching Specifications to Objects/Components

An object-specification pair defines a set of behaviors can be offered by a component/object.

Figure 16. Elements of an Object-Specification Pair.

Object/component descriptions must be at least multi-input multi-output (MIMO). Otherwise they aren't useful.

Research
Research questions to be answered:

• Input and Output
  How to use XML/RDF to model ports, port attributes, and flows (e.g., signals, energy) to varying levels of complexity?
  How to design a hierarchy of port classes?
  Engineering constraints -- convervation of flow, energy, force?
• Pre- and Post-Conditions
  How to XML/RDF to model pre- and post-conditions for object/module use? We'd like to write these rules in a manner that enables tools like Jess and MANDARAX to evaluate compatibility of pre- and post-conditions.
• Interface Specification
  An interface specification precisely defines what a component that offers an interface must do, and what a client of that interface can expect (i.e., the list of allowwable operations is defined by an underlying information model). The specification consists of the following parts:
  • The interface type itself.
  • The information model -- that is, the attributes and association roles of the interface, and their types.
  • The operation specifications -- pre- and post-consitions.
• Information Model
  An abstract definition of any information or state that is retained between client requests by an object supporting the interfaces and any constraints on that information. (persistence).

Example: Architecture-Level Synthesis and Analysis of a Home Theatre System

System-level design of the "home theatre system" requires top-down decompositions of goals into layers of requirements, followed by a bottom-up implementation of the system from theatre components.

We would like to create and interactive design environment where the specifications for components are found on the web.

Figure 17. Synthesis of System Architectures Supported by Product Descriptions on Web

Figure 16 shows a simple scenario:

• We are assembling a home theatre system using descriptions of the components and their capabilities located at the vendor web sites. Component specifications will basically say "...if you supply a required set of inputs, then the component will gurantee a minimum level of performance (output).

Top-Down System-Level Development Coupled with Component Reuse

Design Goal
I need a home theatre system.

Operations Concept
Our wishes are very modest -- we will simply watch DVD movies on a large size theatre screen and high fidelity audio system.

Figure 18. Flowdown of Requirements to System Architecture. Reuse of System Components.

Pathway from Goals/Scenarios to Requirements

Our course of action will be to represent requirements knowledge in terms of facts and logical rules, and to implement control tasks separately.

Research questions to be answered:

• We need templates for structuring/writing requiremnts in a way enables precise parsing and interpretation of their content. How to do this?

Representation of System Architecture
The system architecture is the structure of the pieces that make up a system, including the resposibilities of the pieces and their interconnection.

In many applications, the spatial configuration of elements is an important consideration. Hence, there is a need for representations that capture the size, location, and relative positioning of objects. Of course, allowable positioning of objects will depend on the properties of the objects themselves.

To keep the complexity of evaluation in check, designs are organized into abstraction hierarchies.

Research questions to be answered:

• What is an appropriate symbolic representation for the system architecture?
• Can we use (or easily adapt) an architecture description language (ADL) that has already been developed?
• How to make statements about a design in a way that lends inself to pro-active computer assistance?

  Models. Networks of adjaceny relationships need to be inferred from the dimensions and spatial locations of design components.

  Some design descriptions can be inferred from others .. for example, given the spatial geometry of an ensemble of objects, the topology of adjaceny relationships can be inferred. The oposite direction does not work.

Interface Requirements/Specifications

Insert ....

Hybrid (Symbolic/Instantiated) Represenation for System Architecture

Insert ....

Library of Product (Amplifier Object) Descriptions

We envision an XML database containing collections of object-specification pairs. Research questions to be answered:

• How to search/browse the database and graphically display object-specifications?
• Is it possible to completely separate the object-specification description (XML, RDF, SVG) from the browser functionality?

A model-based system should be able to handle a wide range of designer-intiated queries, and anticipate queries based on information in the design knowledge base. Many features of a design can be inferred its explicity description -- since much of this information may not be relevant to a particular set of decisions, there must be some strategy to guide the interpretation process. Generally this can be achieved by setting up interpretation goals -- statements whose truth we wish to test against the design description.

Allocation of Objects (Product Descriptions) to Subsystem Elements

Research questions to be answered:

Print Version. March 14, 2003.