Assessing the Suitability of UMLAssessing the Suitability of UMLfor Modeling Software Architecturesfor Modeling Software Architectures

Nenad MedvidovicComputer Science Department

University of Southern CaliforniaLos Angeles, CA 90089-0781

neno@usc.eduhttp://sunset.usc.edu/~neno/

OutlineOutline

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

Software ArchitecturesSoftware 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

Key Architectural ConceptsKey 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

Example ArchitectureExample Architecture

Components interact via connectors

Connectors enforce interaction constraints

Configurations reflect topological constraints

AArchitecture rchitecture DDescription escription LLanguagesanguages

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

Example ADLsExample 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

UUnified nified MModeling odeling LLanguage: anguage: MotivationMotivation Community fragmentation

Academic Approachto Architectures

Industrial Approachto Architectures

Focus on wide range ofdevelopment issues

Focus on analytic evaluation ofarchitectural models

Families of modelsIndividual models

Practicality over rigorRigorous modeling notations

Architecture as the“big picture” in developmentPowerful analysis techniques

Breadth over depthDepth over breadth

General-purpose solutionsSpecial-purpose solutions

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

UUnified nified MModeling odeling LLanguage:anguage:StandardizationStandardization

UUnified nified MModeling odeling LLanguage:anguage:BenefitsBenefits 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

UUnified nified MModeling odeling LLanguage:anguage:ExtensibilityExtensibility New constructs may be added to address new

development issues Three extensibility mechanisms

– constraints– tagged values – stereotypesStereotype Person for instances of meta class Class[1] 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

Modeling Software ArchitecturesModeling Software Architecturesin UMLin UML Strategy #1

– use UML “as is”– enables direct comparison of UML and an ADL

Strategy #2– use UML’s built-in extension mechanisms – allows automated conformance checking to

architectural style rules Strategy #3

– augment the UML meta model to directly support architectural concerns

Strategy #1:Strategy #1:Using UML “As Is”Using 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

Strategy #1:Strategy #1:UML Metamodeling ArchitectureUML Metamodeling Architecture

Strategy #1:Strategy #1:ExampleExample

Comp3

Comp2Comp1

Conn1

C3i

C3i

C2i

C2i

C1i

C1i

2:Request() 3:Request()

c3 : Comp3

:Comp2:Comp1

1:Request()

bus : Conn1

4:Notif1(data1) 5:Notif2(data2)

6:Notif2(data2)

7:Notif1(data1)

Strategy #2:Strategy #2:Constraining UMLConstraining 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

Strategy #2:Strategy #2:UML Metamodeling ArchitectureUML Metamodeling Architecture

Strategy #2:Strategy #2:ExampleExample

<<Component>>Comp3

<<Component>>Comp2

<<Component>>Comp1

<<Connector>>Conn1

<<CompConn>> <<CompConn>>

<<ConnComp>>

Strategy #3:Strategy #3:Augmenting UMLAugmenting 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

Strategy #3:Strategy #3:UML Metamodeling ArchitectureUML Metamodeling Architecture

Discussion of Integration Strategies 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

Current StatusCurrent Status

Integrated environment for transforming C2-style architectures into UML

From ArchitectureFrom Architectureto Implementationto Implementation

Architectural View MismatchesArchitectural 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

Round-Trip Software Engineering Round-Trip Software Engineering Using UMLUsing UML

ConclusionsConclusions

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