Introducing Object Oriented Systems Engineering Methods to University Systems Engineering Curricula

Chris Ryder Johns Hopkins University Applied Physics Laboratory 26 October 2006

References

ƒ Systems Engineering: Principles and Practices ƒ Alexander Kossiakoff and William Sweet ƒ OMG SysML Tutorial (Presented by Abe Meilich on 10/23) ƒ Sandy Friedenthal – “Model Driven Architecture for Systems Engineering” ƒ http://www.omgsysml.com ƒ OMG SysML Specification

slide 2 26 October 2006

Observation

ƒ There is no standardized approach to SE architecting, modeling and design used in the JHU WSE SE Curriculum ƒ Most instructors teach the methods they are familiar with ƒ The single common element is the SE Method ƒ And its relationship to SE Life Cycle and Materialization ƒ Most students/ classes use Power Point as the modeling tool ƒ Difficult to portray engineering diagrams ƒ Does not “contain” any data details ƒ Tools used by instructors include: ƒ VITECH Core ƒ Sparx Enterprise Architect ƒ MS Visio

slide 3 26 October 2006

Proposition

ƒ Introduce Object Oriented Systems Engineering Methods as the basis for architecting, modeling and design for design related activities in SE courses ƒ At a minimum, introduce model-driven SE using a standardized modeling language ƒ Independent of method ƒ Independent of any specific tool ƒ OMG SysML meets this criterion ƒ It is standardized (released by OMG on 6 July 06) ƒ Implemented by several tool vendors ƒ Most of whom will provide licenses at little (i.e. < $100) or no cost

slide 4 26 October 2006

The Systems Engineering Method

ƒ Every phase of the systems life cycle consists of some form of: ƒ Requirements Analysis ƒ Functional Definition ƒ Physical Definition ƒ Design Validation ƒ This is the basis of the JHU WSE Systems Engineering curriculum ƒ The SE Method is applicable to both traditional Structured Analysis or with OOSEM

slide 5 26 October 2006

Systems Engineering Method Needs ts n Requirements e m e Analysis ir u q e R s n Functional o s ti n c o Definition n ti u lu F o S l a ti Physical n te o Definition P

Design Validation

Solution(s) slide 6 26 October 2006

Principal Stages in System Life Cycle (Kossiakoff & Sweet)

Products

System Models (Baselines)

slide 7 26 October 2006

System Materialization Integration Needs Concept Concept Advanced Engineering and Phase/Level Analysis Exploration Definition Development Design Evaluation Test and Define Define Evaluate Operational Explore Selected Validate (System and System Objectives Concepts Concepts Concept Operational) Validate Define Define Selected Subsystem Visualize Functions Configuration Subsystems Integrate, Test Validate, Select, Define Specify Component Visualize Functions construction Design, Test Integrate,

Sub- Define component Visualize Functions Design

Select or Part Visualize adapt

Ref: SYSTEMS ENGINEERING PRINCIPLES & PRACTICE A Guide to the Engineering of Complex Systems

slide 8 26 October 2006

JHU WSE Systems Engineering Program

ƒ ~400 student enrolled ƒ Curricula offered at four primary campuses ƒ APL, JHU Montgomery County Campus, WSE Dorsey Center, Southern Maryland Higher Education Center ƒ Curricula also offered on site at industry locations ƒ MITRE (Bedford, MA; Vienna, VA) ƒ NAVSEA (Crystal City, VA) ƒ BAE Systems (Nashua, NH) ƒ Courses conducted by instructor teams ƒ One from APL and one from industry

slide 9 26 October 2006

JHU EPP SE Core Program

Systems Engineering Core Program

Technical Core Course Intro to SE Management 645.462

Intro to Proj Man. System Conceptual Design System Design & integration System T&E SE Project 595.460 645.767 645.768 645.769 645.770

Project Planning & Control SW Engineering Man. 595.464 595.763

- Denotes courses with modeling and design projects

slide 10 26 October 2006

Why Object Oriented SE?

ƒ Applies the SE Method ƒ Requirements are captured using SysML requirements diagram and Requirements Traceability Matrix (RTM) ƒ Functional analysis and decomposition performed using SysML behavioral diagrams ƒ Physical elements, behaviors and relationships are modeled using SysML structural diagrams ƒ Functionality assigned to physical objects ƒ Trace model elements to requirements

slide 11 26 October 2006

OOSE Requirements Capture

ƒ Start at the Beginning ƒ Needs Analysis and requirements definition ƒ Formulating the “Requirements Model” ƒ Define/scope the problem ƒ Analyze requirements ƒ Necessary, concise, attainable, complete, consistent, unambiguous, verifiable ƒ Create requirements traceability ƒ Documenting the requirements ƒ Constructing the SysML Requirements Diagram ƒ Building the Requirements Traceability Matrix

slide 12 26 October 2006

OOSE Functional Analysis

ƒ Structured SE and Object Oriented SE Methods are “Homeomorphic” (Joe Carl, PhD, Retired Guy) ƒ “Possessing intrinsic topological equivalence” ƒ SA representation can be directly mapped to OO form ƒ In other words: ƒ OO methods involves the same “Top Down” hierarchical approach ƒ Top Down/ Breadth First ƒ Event Driven ƒ Objects have well-defined functionality that execute tasks as a sequence of events ƒ Interactions between objects are defined at each level in the system ƒ Refined as lower-level objects become instantiated ƒ Systems, subsystems, components exist in a state

slide 13 26 October 2006

Object Oriented

ƒ Every system is composed of “Objects” ƒ All Objects contain Attributes, Operations, Parameters and Constraints ƒ Operations Æ FUNCTIONS ƒ Functional analysis still applies to OOSE ƒ Operations are assigned to an object, however abstract, early in the process ƒ Unlike with OOSWE, “Functional Decomposition” is not a dirty word ƒ Measures are contained within the objects ƒ Measures that can quantify objectives

slide 14 26 October 2006

So What is the Difference?

ƒ Focus on the “Logical” as opposed to the “Functional” ƒ Logical elements posses both Function and State ƒ Analyze the system from the viewpoint of the “Things” however abstract ƒ Consistent with Systems Materialization ƒ OOSE is a model-driven methodology by definition

slide 15 26 October 2006

Systems Engineering Model

ƒ A Systems Engineering model captures the essential elements of the systems engineering life-cycle ƒ “Dynamic and recursive process” (Bootch, Rumbaugh, Jacobson) ƒ Iteratively captures enterprise capabilities and systems requirements ƒ Promotes incorporation of technology evolution ƒ Forms basis for sound, long-term SE and analysis ƒ Compliant with DoDAF and JCIDS

slide 16 26 October 2006

Model-Driven SE Approach

ƒ Establish system model bases on: ƒ Requirements model ƒ Functional model ƒ Logical/ Physical model ƒ Show relationships between the models ƒ Link requirements to functions ƒ Link functions to system/ elements ƒ Understand the capability being developed

“If you don’t model it, you won’t understand it.” Ivar Jacobson

slide 17 26 October 2006

OMG SysML

ƒ OMG SysMLTM is a standardized family of diagrams that addresses requirements, functional and logical/physical elements ƒ OMG SysML is suitable for both OO and structured methods, but it was formulated from UML with OO methods in mind ƒ SysML standard ~ 230 pages ƒ As opposed to non-standard SA diagrams ƒ IDEF-0 (180 Pages) ƒ IDEF-3 (235 Pages) ƒ Data Flow/ Control Flow (No standard) ƒ Functional Flow Diagrams (No standard) ƒ Enhanced Functional Flow Block Diagrams (No Standard) ƒ Tool Vendors are implementing it in their applications

slide 18 26 October 2006

What Is SysML?

• A graphical modeling language in response to the UML for Systems Engineering RFP developed by the OMG, INCOSE, and AP233 • A UML Profile that represents a subset of UML 2 with extensions • Supports the specification, analysis, design, verification, and validation of systems that include hardware, software, data, personnel, procedures, and facilities • Supports model and data interchange via XMI and the evolving AP233 standard (in-process)

SysML is Critical Enabler for Model Driven SE

Source: OMG SysML Tutorial

slide 19 26 October 2006

Relationship Between SysML and UML

Source: OMG SysML Tutorial

slide 20 26 October 2006

SysML Taxonomy

Source: OMG SysML Tutorial

slide 21 26 October 2006

Behavioral Elements in the Functional Model

ƒ Represented by Use Cases and SysML behavioral diagrams ƒ Executed by “Actors” outside the system boundary ƒ Actor is a form of Block and its own attributes and operations ƒ Actor represents a role, not an person or group ƒ Block at one level can be actor at an other ƒ Actors are often external systems or internal system controls ƒ Actor executes the Use Case on the materiel object, i.e. the system, subsystem, component or part

slide 22 26 October 2006

SysML Behavioral Diagrams

Source: OMG SysML Tutorial

slide 23 26 October 2006

The Logical Model

ƒ Physical Definition ƒ Beginning with abstract “things” ƒ Evolve to real systems ƒ Assign functionality to the element ƒ Depict the relationships between elements

The Logical Model is the heart of an architecture – Elements that exhibit behavior and their defined relationships with other elements within the domain

slide 24 26 October 2006

SysML Structural Diagrams

Source: OMG SysML Tutorial

slide 25 26 October 2006

Structural/ Physical Elements

ƒ Depicts basic logical structure of the system ƒ Packages ƒ Organize the elements as sub-entities ƒ Blocks ƒ Basic structural element ƒ Same specification as the UML Class ƒ Consists of attributes, operations, associations, constraints ƒ Also represents human and organizational elements –- the Actor ƒ Ports ƒ Specifies interaction points or parts ƒ Specifies flow or standardized interface ƒ Parametrics ƒ Specifies constraints with value types

Copyright © Lockheed Martin Corporation, 2000 – 2003 & INCOSE 2004. All rights reserved.

slide 26 26 October 2006

ATIS Case

ƒ Automated Traffic Intersection System ƒ Students presented a set of “less-than-good” requirements ƒ Describe what improvements need to be done ƒ Describe the “top level” functions ƒ Initiate functional analysis ƒ Describe the logical elements with assigned functionality ƒ Depict a hierarchy of components with functions ƒ Consider interfaces for one subsystem

slide 27 26 October 2006

ATIS Context Diagram

cd Context Diagram

«External System» External Power «External System» +Monitored by System Motor Vehicle - 115 VAC: - 60 Hz:

+Powers the System

«System» +Monitors ATIS

+ Sense Traffic() +Sends and Receives Messages + Monitor Pedestrian Crossing() + Respond to Emergency Vehicle() + Respond to External Power()

+Monitors

+Signals «External System» +Sends and Receives Messages Emergency Vehicle

Pedestrian

slide 28 26 October 2006

ATIS Use Case Diagram

uc ATIS UC Diagram

«External System» Motor Vehicle Sense Traffic

«External System» Emergency Vehicle Respond to Emergency Vehicle «System» ATIS

«External System» External Power Respond to System External Power

Monitor Pedestrian Crossing :Pedestrian

slide 29 26 October 2006

Functionality Depicted in Hierarchical Form

class Use Case Model

Perform ATIS Functions

«Use Case» Respond to «Use Case» «Use Case» Sense Traffic Emergency Vehicle Monitor Pedestrian Respond to Crossing External Pow er

slide 30 26 October 2006

ATIS SysML Activity Diagram

act Sense Traffic

ATIS

«Continuous» «Continuous» Monitor Emergency Detect Vehicles Monitor Vehicle Activity Pedestrians

«I/O» «I/O» :Pedestrian :Vehicle Track File Request

Calculate Optimal «I/O» Sequencing :EV Incoming Message

«I/O» :Traffic Signal Command Message

[Emergency Vehicle Present]

Send Signal to Emergency Vehicle «I/O» :EV Outgoing Message

«I/O» Traffic Signal Send Signal to Me ssa ge Lights slide 31 26 October 2006 ATIS Block Definition Diagram

At the system level, attributes must be measurable!

cd ATIS Class Diagram «System» ATIS System Measure of - «MOE» Reduce Traffic Fatalities: Effectiveness + Sense Traffic() + Monitor Pedestrian Crossing() + Respond to Emergency Vehicle() + Respond to External Power() * «Subsystem» ATIS Traffic Signal + Sequence Signals() «Subsystem» Control Center + Estimate Veh Speed and Size() + Control Traffic Signal Sequence() + Coordinate EV Messaging() «Subsystem» Comm System «Subsystem» «Subsystem» Traffic Sensor Emer Vehicle Message Terminal - «MOP» Sensor Capacity: «Subsystem» Pedestrian Sensor + Receive Emergency Message() + Detect Vehicle() + Send EV Data to Control() + Send Vehicle Track File to Control() + Monitor Crosswalk() + Send Message to EV() + Receive Pedestrian Signal()

Subsystem/ component Measure of Performance

slide 32 26 October 2006

ATIS Traffic Sensor Subsystem

cd Traffic Sensor

«Subsystem» Traffic Sensor

+ Detect Vehicle() + Send Vehicle Track File to Control()

«Component» «Component» Traffic Camera Traffic Radar

+ Capture Image() : Image + Detect Vehicle() + Capture Vehicle Position() : Posit + Calculate Positoin() : Posit + Capture Image File() : file + Calculate Velocity() : float + Send Image to Control() + Create Vehicle Track() : record + Send Vehicle Track() : record

«Component» Traffic Sensor CPU

+ Correlate Radar & Camera Data() : file

slide 33 26 October 2006

Example of Internal Block Diagram

cd Traffic Sensor

ATM -- Assynchronous Transfer Mode ATM messages are used primarily with fiber optic netwoks. Its messages based are fixed 53 octet packets

«Component» ATM Traffic Camera ATM «Component» Traffic Radar

ATM Message Packet ATM Message Packet

ATM

«Component» Traffic Sensor CPU

slide 34 26 October 2006

Example of Internal Block Diagram

composite structure Traffic Sensor

«Subsystem» Traffic Sensor

ATM: Assynchronous Transfer Mode messages are primarily used with «Component» fiber-optic networks using fixed 53 «Component» Traffic Camera octet packets Traffic Radar

ATM: Traffic Radar to CPU ATM: Camera to CPU

ATM: CPU

«Component» Traffic CPU

slide 35 26 October 2006

TBDA Requirements Diagram req TBDA Requirements

TBDA System

Bandwidth

Area of (from Data Link ) Field of Coverage Regard Data (from Vehicle) Transfer (from Sensors) Rate (from Data Link ) Field of View Range for Range of Coverage Coverage (from Sensors) for Data (from Vehicle) Link Number of Targets for (from Data Link ) Simultaneous Time of Track Flight (from Sensors) (from Vehicle) Mean Flight Range of Hours Speeds for Between Target Maintenance Tracking Vehicle Actions (from Sensors) (from Logistics and Supportability) (from Vehicle) Sensor Mean Time Range for Maintenance (from Sensors) Action Target (from Logistics and Supportability) Radar Cross System Set- Section up Time (from Sensors) SysML diagrams supported by robust database (from Logistics and Supportability) Target Vehicle Resolution Launch and Landing (from Sensors) (from Logistics and Supportability) slide 36 26 October 2006

Summary of OOSE

ƒ There is nothing special about using Object Oriented SE methods ƒ It involves the same basic analysis ƒ OOSE is a model-driven style ƒ Models are fundamental to architecture development ƒ Human beings think in terms of “things”

slide 37 26 October 2006

Conclusion ƒ This proposal considers only an introduction to basic OOSEM practices ƒ Details of OOSEM is far beyond the scope of design courses ƒ OOSEM using SysML could be an entire semester course ƒ The INCOSE tutorial is intended to introduce detailed practices for real-world project usage ƒ By introducing OOSE principles at the University, students can apply the SE Method as it relates to Systems Materialization across the life-cycle ƒ Standardized modeling methods must be applied ƒ Instructors must keep up with evolving industry practices ƒ Observation from INCOSE 06 and NDIA SE Conference indicates SysML will be widely used throughout industry If anything else, you know what “Homeomorphic” means

slide 38