Assessing the Suitability of UML for Modeling Software Architectures

1
Assessing the Suitability of UMLfor Modeling
Software Architectures

• Nenad Medvidovic
• Computer Science Department
• University of Southern California
• Los Angeles, CA 90089-0781
• neno_at_usc.edu
• http//sunset.usc.edu/neno/

2
Outline

• Overview of software architectures
• Overview of UML
• Modeling software architectures in UML
• Lessons learned
• Current status
• Conclusions

3
Software Architectures

• High-level model of a software system
• software components
• their interactions software connectors
• their interconnections configurations
• Promise of software architectures
• better, more reliable software systems
• modeling important system aspects early
• ensuring system properties throughout

4
Key Architectural Concepts

• Components loci of computation and state
• Connectors loci of interaction
• communication
• coordination
• mediation
• Architectural constraints
• structural vs. behavioral
• local vs. non-local vs. global
• Architectural style
• interaction constraints topological constraints

5
Example Architecture

• Components interact via connectors

• Connectors enforce interaction constraints

• Configurations reflect topological constraints

6
Architecture Description Languages

• High-level architecture modeling notations
• Model architectural structure and behavior
• Difference in focus
• Varying degrees of formality
• Varying levels of tool support
• Differences in maturity

7
Example ADLs

• C2
• focus on style-based topological constraints and
  evolution
• static component behavior in 1st order logic
• Wright
• focus on connectors
• dynamic subsystem behavior in CSP
• Rapide
• focus on system events
• dynamic system behavior using event patterns and
  posets

8
Unified Modeling Language Motivation

• Community fragmentation

Academic Approach to Architectures
Industrial Approach to Architectures
9
Unified Modeling LanguageStandardization

• Provides an economy of scale
• more and better tools
• improved tool interoperability
• more skilled developers
• lower training costs
• Combine the benefits of powerful, specialized
  notations with those of widely adopted, general
  notations
• specific solution integrate ADLs with UML

10
Unified Modeling LanguageBenefits

• Large, useful set of predefined constructs
• Extensible
• Semi-formal definition of syntax and semantics
  via
• a meta model
• descriptive text
• constraints
• Potential for
• wide adoption
• standardization
• substantial tool support
• Basis in experience with mainstream development
  methods

11
Unified Modeling LanguageExtensibility

• New constructs may be added to address new
  development issues
• Three extensibility mechanisms
• constraints
• tagged values
• stereotypesStereotype Person for instances of
  meta class Class1 A Person can be either
  female or malepersonGender enum female, male
  
• The meta model may also be extended
• results in a new notation
• may be incompatible with UML-compliant tools

12
Modeling Software Architecturesin UML

• Strategy 1
• use UML as is
• enables direct comparison of UML and an ADL
• Strategy 2
• use UMLs built-in extension mechanisms
• allows automated conformance checking to
  architectural style rules
• Strategy 3
• augment the UML meta model to directly support
  architectural concerns

13
Strategy 1Using UML As Is

• Simultaneous consideration of architecture
  composition rules and UML notational constructs
• Develop a UML domain model
• Develop an (informal) architectural diagram
• Map domain classes to architectural components
• Design class (component) interfaces
• Provide constructs for modeling connectors
• connectors add no functionality at the domain
  model level
• Model architectural structure in class and/or
  collaboration diagrams

14
Strategy 1UML Metamodeling Architecture
Meta-Meta Model
Meta Model
Model
User Objects
15
Strategy 1Example
16
Strategy 2Constraining UML

• Identify UML meta classes semantically similar
  to major architectural constructs
• operation, message, port
• component, connector, architecture
• Define stereotypes and apply them to meta class
  instances
• use stereotypes to model structural aspects of an
  architecture
• Describe semantics using UML diagrams
• sequence, statechart, collaboration, activity

17
Strategy 2UML Metamodeling Architecture
18
Strategy 2Example
19
Strategy 3Augmenting UML

• Introduce explicit architectural constructs and
  constraints in UML
• Introduce additional notations for modeling
  architectural semantics
• Follow an approach similar to Strategy 1 to
  model specific architectures
• Follow an approach similar to Strategy 2 to
  model specific architectural styles

20
Strategy 3UML Metamodeling Architecture
21
Discussion of Integration Strategies

• All three approaches have merits and shortcomings
• Straight UML
• understandable architectures
• manipulable by standard tools
• architectural constraint violations
• Constrained UML
• ensures architectural constraints
• requires complete style specifications
• requires OCL-compliant tools
• Extended UML
• provides native support for architectures
• requires backward tool compatibility
• may result in incompatible UML versions

22
Current Status

• Integrated environment for transforming C2-style
  architectures into UML

23
From Architectureto Implementation
24
Architectural View Mismatches

• Different UML diagrams present different system
  views
• redundant information across views
• Key challenge is to ensure inter-view consistency
• Ramifications on round-trip engineering

25
Round-Trip Software Engineering Using UML
26
Conclusions

• Software modeling philosophies
• Assumptions
• Problem domain modeling
• Architectural abstractions
• Modeling behavior
• Architectural style
• Architectural views