Applying UML to Simulation Development

1
Applying UML toSimulation Development

• Paul Gustavson
• SimVentions

2
Survey

• What is your role?
• Developer?
• Manager?
• User / Sponsor?
• Other?
• What are your project goals?
• Bug-free software?
• Software delivered on-time?
• Maintainable / extensible?
• Fulfills requirements?
• Better team collaboration?
• Under budget?
• People buy it!

• What are the Hurdles?
• Lack of understanding
• Of requirements
• Among team members
• Lack of communication
• Separation
• Low/No collaboration
• Lack of skill set
• Lack of funds
• Lack of time
• Lack of tools
• Changing requirements/demands by the customer
• Ad hoc development

3
SOFTWARE CODE VS. MODEL
OR
One diagram

• 7 source files
• 940 lines of code

4
The UML

• Vastly underutilized
• Reasons why people avoid it
• Something new to learn
• Too much time / effort
• Use of RAD IDEs
• Tools are too expensive
• Dont understand the benefit / payoff
• Dont know how to mold it into their process

myth
myth
5
What it takes

• Policy / Process
• Roles
• Roadmap
• Communication
• Tools, templates and techniques. 
• CapabilityUnderstanding Vision Purpose!

Productivity increases when a team has purpose!
6
UML Process
Blueprint
Corrective Actions

• There is no UML process.
• UML cannot be used effectively without
  application to a process.

Sketch
Borlands Application Lifecycle Management
7
Applied to the FEDEP
Model Composability
System Composability
Plug Play Systems
8
UML / BOMs
Arrival Trigger
Greeting Message
Seating Message
Food Order Request Message
Food Order Response Message
Waiting (reading paper)
Food Served Trigger
Eating
Finished Eating Trigger
Check delivered trigger
Payment Message
Leaving
Customer left Trigger
Clearing
9
UML as
3110 Tom Gullion lttom.gullion_at_borland.comgt

• Martin Fowler suggests UML is commonly used in
  three ways
• UMLAsSketch
• UMLAsBlueprint
• UMLAsProgrammingLanguage
• see www.martinfowler.com/bliki/

10
UML Diagrams
Borland Together Edition for Visual Studio
11
UML 2.0 Diagram Taxonomy

• All diagrams refined some updated while others
  are new

OMG 2003
12
Other Things To Try / Consider

• Dog eared rectangles lt-notes
• Color UML (post-it pastels)
• Stereotypes / Profiles
• Patterns !
• OCL Object Constraint Language
• Use XMI to move between UML tools (1.4)
• Version Control Class Diagrams
• Take advantage of LiveSource (once you reach
  Blueprint)
• Look at MDA

13
Recommended Reading

• Martin Fowler, UML Distilled Applying the
  Standard Object Modeling Language (3rd Edition),
  Addison-Wesley, 2004.
• Joseph Schuller, SAMS Teach Yourself UML in 24
  Hours (3rd Edition), SAMS, 2004.
• Grady Booch, Ivar Jacobson, James Rumbaugh, The
  Unified Modeling Language User Guide,
  Addison-Wesley, 1999.
• Alistair Cockburn, Writing Effective Use Cases,
  Addison-Wesley, 2001.
• MY STUFF
• - Understanding and Using Patterns
• - Fitting the UML into your Development Process
• Both will be made available at my blog
  http//www.simventions.com/gustavson

14
Addendum Slides
15
3106 Gundars Osvalds Systems of Systems
Architect The Boeing Company
Architecture Framework Relationships
FE AF
Zachman FW
C4ISR/DoD AF
Architecture Frameworks
Architecture Framework
RUP
Bridged ZF
OOSEM
SD
SA
Other
Modeling Methods
Object Oriented
Structured Analysis (Functional)
Functional
Object Oriented
Diagrams
Standards
e.g., IDEF0
e.g., OMG UML
Chesapeake Chapter INCOSE OOSEM WG
16
Types of Design Patterns

• CONCEPTUAL MODEL ATTRIBUTES
• What the system will represent,
• the assumptions limiting those representations,
  and
• the capabilities needed to satisfy the users
  requirements.

identifies the need to represent structural
elements of our design.
structuraldesign patterns
identifies the creational limitations and
capabilities upon those structural
representations, which are needed for
realistically modeling our system.
creational design patterns
identifies the behavioral capabilities needed of
the conceptual entities being represented within
the problem space. 
behavioral design patterns
BOMs
17
Structural Patterns
18
Examples Adapter Pattern

• matches an existing object beyond your control
  to a particular interface.
• A system has the right data and behavior but the
  wrong interface. The Adapter provides a wrapper
  with the desired interface.

• Examples
• DIS to HLA RPR FOM adapters
• DoD HLA 1.3 to IEEE 1516 adapters.

19
Examples Bridge Pattern

• designed to separate a classs interface from its
  implementation allowing you to vary or replace
  the implementation without changing the client
  code.

• Example
• SOMs Federates
• SOM identifies intrinsic capabilities of federate
• Federate supports capabilities identified by SOM
• IF BOMs ECAP BOMs
• Interface BOM provides the abstraction serving as
  the class interface,
• Encapsulated BOM provides the implementation.

20
Examples Composite Pattern

• used to form a collection of objects.

• Examples
• Mega-BOM is used to represent a composite of IF
  BOMs

• This composite is used to formulate the model
  representation for
• a federation (akin to a FOM),
• a federate (akin to a SOM), or
• an aggregation of elements or HLA object classes.

21
Examples Facade Pattern

• used to wrap a set of complex classes into a
  simpler enclosing interface.

• Example
• Dynamic Link Compatibility (DLC) API effort
• Focused on creating a common interface to support
  the various RTI implementations that are
  currently in existence.

This will allow a federate to plug into
virtually any RTI implementation using the DLC
API calls rather than having to recode to support
various RTI implementations as is often the case
now.
22
Examples Flyweight Pattern

• used to help manage large numbers of class
  instances (i.e. entities) within a simulation.

• Example
• By identifying the common attributes of the
  classes representing the entities within a
  simulation, a common class can be defined,
• any differences in attributes among the various
  classes can be maintained as extrinsic data
  passed in as arguments (using mechanisms such as
  HLA Interactions).

This approach is currently being investigated to
support instance aggregation within the
simulation community.
23
Creational Patterns
24
Abstract Factory

• Used to provide an interface for creating
  families of related or dependent objects without
  specifying their concrete classes

25
Behavioral Patterns
26
Examples Strategy Pattern

• Used to define a family of algorithms,
  encapsulate each one, and make them
  interchangeable.
• Strategy lets the algorithm vary independently
  from clients that use it.
• The selection of an algorithm that needs to be
  applied depends upon the client making the
  request or the data being acted upon.
• It separates the selection of algorithm from
  the implementation of the algorithm.
• It allows for the selection to be made based
  upon context 5. .

• Example
• Dead Reckoning algorithm

27
Chain of Responsibility

• Used to avoid coupling the sender of a request to
  its receiver by giving more than one object a
  chance to handle the request. 
• Chain the receiving objects and pass the request
  along the chain until an object handles it.