1 / 26

Assessing the Suitability of UML for Modeling Software Architectures

Assessing the Suitability of UML for Modeling Software Architectures. Nenad Medvidovic Computer Science Department University of Southern California Los Angeles, CA 90089-0781 neno@usc.edu http://sunset.usc.edu/~neno/. Outline. Overview of software architectures Overview of UML

cole
Download Presentation

Assessing the Suitability of UML for Modeling Software Architectures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Assessing the Suitability of UMLfor Modeling Software Architectures Nenad Medvidovic Computer Science Department University of Southern California Los Angeles, CA 90089-0781 neno@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. Comp 1 Comp 2 Conn 1 Comp 3 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. Focus on analytic evaluation of architectural models Focus on wide range of development issues Individual models Families of models Rigorous modeling notations Practicality over rigor Architecture as the “big picture” in development Powerful analysis techniques Depth over breadth Breadth over depth Special-purpose solutions General-purpose solutions Unified Modeling Language: Motivation • Community fragmentation Academic Approach to Architectures Industrial Approach to Architectures

  9. S G G G G S S Unified Modeling Language:Standardization • 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 Language:Benefits • 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 Language:Extensibility • 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

  12. Modeling Software Architecturesin 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

  13. Strategy #1: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

  14. Strategy #1:UML Metamodeling Architecture Meta-Meta Model Meta Model Model User Objects

  15. Comp 1 Comp 2 Conn 1 C1i C2i 7:Notif1(data1) 6:Notif2(data2) 4:Notif1(data1) 5:Notif2(data2) 3:Request() 2:Request() C3i Comp 3 Conn1 bus : Conn1 C1i C2i 1:Request() C3i c3 : Comp3 :Comp2 :Comp1 Comp1 Comp2 Comp3 Strategy #1:Example

  16. Strategy #2:Constraining 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. Meta-Meta Model Meta Model Model User Objects Strategy #2:UML Metamodeling Architecture

  18. Comp 1 Comp 2 Conn 1 <<CompConn>> <<CompConn>> <<Connector>> Conn1 Comp 3 <<ConnComp>> <<Component>> Comp2 <<Component>> Comp1 <<Component>> Comp3 Strategy #2:Example

  19. Strategy #3:Augmenting 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. Meta-Meta Model Meta Model Model User Objects Strategy #3:UML 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

More Related