Assessing the Suitability of UML for Modeling Software Architectures
description
Transcript of Assessing the Suitability of UML for Modeling Software Architectures
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
[email protected]://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 notationsArchitecture 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