Applying UML to System Engineering More Lessons Learned

1
Applying UML to System EngineeringMore Lessons
Learned

• Murray Cantor
• Principal Consultant
• Mcantor_at_rational.com

2
Topics

• Background
• Customers needs
• Lessons Learned
• UML Issues
• Next steps

3
Background

• Ongoing interest in systems throughout last 15
  years
• Increasing demand over last 3 years in applying
  to UML semantics and associated architecture
  processes
• Ongoing engagements at various sites of
  Lockheed-Martin, Boeing, Raytheon, others
• Increasing commitment of Rational to this
  community
• Whitepaper published and small cadre of
  experienced field staff
• Major revision in process
• Deployment service with supporting tool add-ins
• Beta version of Rational Unified Process add-in
  available
• Participation in OMG SE DSIG

4
Customers Needs

• Complexity of solutions to meet requirements is
  growing
• More integration, capability development
• Technology opportunities require large trade
  space
• Scalability better architecture semantics for
  large systems
• Less stovepipes many current systems have
  unacceptable cost of ownership
• Top-down OOAD methods
• Entails better support for conceptual, analysis
  designs
• Combination of functional, logical, physical
  decompositions
• Support for iterative system development
• Better communication between hardware, software,
  test, integration communities

5
Cross Community Communications

• For UML to enable communications, need to
  agreement on
• What to express
• Architectural views
• Requirements (shalls, use cases, )
• How to express
• Semantics, syntax
• Answer will add needed complexity

6
Strengths of UML

• Environment for dealing with complexity
• Encapsulation, abstraction, generalization
• Expressing and validating logical decompositions
• Relationship between static and dynamic views
• Rich association semantics

7
What to Express

• Classical SE
• Functional decomposition of requirements
• Architecture Views Nodes, Assemblies
• Object-Oriented SE (E.g. RUP SE, OOSEM)
• Requirements as Use cases,
• Logical decomposition
• Other views Locality, process, capsule, .
• Constraints as tagged values
• Both?

8
What to Express Rational Experience

• Multi-level context modeling
• Explicit treatment of blackbox and whitebox
  semantics
• Locality Diagrams for conceptual physical
  partitioning
• Support design trades
• Realtime semantics
• Use case flowdown Derivation of use cases to
  elements of logical, physical architecture
• Derivation of system services
• Derivation of subsystem use cases, services
• Use case anatomy traceability between level of
  requirements in logical decompositions

9
How to Express

• Major Issue Should SE be a UML profile or should
  core UML reflect system modeling needs?
• More careful definitions of system, subsystem,
  use case, service, .
• Cultural Considerations An Example 4 versions
  of the ECD
• Original
• Includes stereotypes
• Orthodox
• 2 Compromises

10
Elaborated Context Diagram Original
11
Orthodox Version
12
A Compromise
13
Another Compromise
14
UML Issues System semantics

• Standard definitions of system have two aspects
• Black box A system is an entity that has
  behavior and provides services that enable it to
  collaborate with other entities to meet a
  business purpose or mission
• White Box A system is made up of hardware,
  software, workers, data,
• Need semantics to describe system blackbox
  elements
• Attributes
• Operations/services
• Constraints
• Whitebox specifications
• Multiple decompositions required logical,
  physical, process, information,
• Semantics for relationships between physical,
  logical, elements

15
UML Issues Subsystem semantics

• Subsystems in 1.X are Classifier and a package
• inconsistent,
• Incomplete
• Need relationship of system and subsystem
  semantics

16
UML Issues Distribution of resources

• The distribution of the finite physical resources
  that provide the system services are captured in
  node diagrams
• Confusion between hosting resources and system
  resources
• There needs to be more clarity on specifying
  levels of specificity in node diagrams
• The two currently defined levels
• descriptor - design
• Instance - implementation
• There needs to be a corresponding version at the
  analysis level to support conceptual design and
  design trades
• Additionally, the semantics of each type should
  be made explicit. Also the distinction of a
  worker as an actor and a worker as a system
  component should be expressible

17
UML Issues Component semantics

• System engineers need a term to mean physically
  delivered item such as a hardware assembly or an
  executable file.
• The term component is commonly used for such an
  item. However, he use of component in various UML
  2.0 drafts seems to mean something more abstract.
  
• If component can no longer be used to mean a
  delivered item, a new term is needed.
• The typically many-to-many association between
  conceptual and design entities and delivered
  items needs to be modeled.

18
UML Issues Assemblies

• A system can be decomposed into parts from which
  it is physically assembled,
• Assemblies have physical properties, weight,
  thermal conductivity, distribution of mass, and
  the like, which are of interest to the hardware
  engineers on the system development effort.
• Further assemblies interact physically. The
  semantics of the components with their budgeted
  or derived physical properties is not found in
  UML 1.X.
• The current UML 2.0 draft does have inclusion
  semantics that may suffice, but these semantics
  need to be considered from the SE point of view.

19
UML Issues Temporal models

• system elements often interact through the
  sequencing of events. The current sequence and
  collaboration diagrams lack sufficient semantics
  to deal with these interactions.
• The improved semantics in UML 2.0 need to be
  considered from an SE perspective.

20
Some Final Conclusions

• Partial UML solutions have provided value to SE
  teams using OO system development approaches
• Adding SE concerns to UML requires attention to
  core UML specification
• More precision needed
• Exposes compromises in 1.X
• It is not just the formal semantics, it is common
  usage
• Resulting models reflect complexity of system
  specification
• This is a hard, but worth it.