Integrating Architecture Description Languages with a Standard Design Method

1. Integrating Architecture Description Languages with a Standard Design Method jrobbins@ics.uci.eduneno@ics.uci.eduredmiles@ics.uci.edudsr@ics.uci.edu Jason E. RobbinsNenad MedvidovicDavid F. RedmilesDavid S. Rosenblum Information and Computer Science Dept. University of California, Irvine

2. Overview • Introduction, Motivation • UML Background, Brief Tutorial • UML Constructs • A Simplified UML Meta-model • UML Extension Mechanisms • Extending UML to Model C2 Architectures • Extending UML to Model Wright Architectures • Discussion: Core Models and Extensions • References and URLs: see www.ics.uci.edu/pub/arch/uml

3. Introduction • Software architecture focuses on high-level models of software systems • Formalists: Analysis is the main purpose of a modelADLs: C2, Wright, Rapide, Darwin, Aesop, etc. • Practitioners: Communication is the main purposeBooch, OMT, OOSE, ROOM, Fusion, etc. • We try to get the best of both worlds:Use a practical, mainstream notation (UML) but extend it to get the benefits of an ADL • We add semantic constraints on the UML meta-model to make it match ADL semantics

4. BackgroundUML: The Unified Modeling Language • UML unifies • Popular OO design notations: Booch, OMT, OOSE • Many views of the system: object model, state models, use cases, deployment model, etc. • Notations used for analysis, design, and implementation • UML is well defined • UML Meta-model defines what is in a UML model • Object Constraint Language specifies system constraints • UML stereotypes allow the notation to be extended

5. Motivation: Why use UML? • Fairly complete set of models that work together • Better than current OO design notations • Reduces training costs, eases communication • The software industry is in an skills/employment crisis • Evolving into industry standard, market leader • OMG standard scheduled for late 1998 • Rational, Microsoft, IBM, ObjectTime, HP, Oracle, MCI Systemhouse, Unisys, IntelliCorp, I-Logix, … • Dozens of tools support UML notation now, more semantic support expected next year

6. Motivation: Why use it for research? • Reduces barriers to technology transfer • Easier to explain value added over status quo • Sets an example of what industry values, and what they can accept • Leverages existing skills, training • Extensive tool support from multiple sources • Allows for incremental adoption: use a little at a time • Formalism is behind the scenes • Visually more self-explanatory than Booch or OMT • “Catch a wave”: make our research exciting by linking it with exciting, growing, current things

7. UML Constructs: Objects • UML defines constructs for Classes, Attributes, Operations, Associations between classes, Class Inheritance 0..* «stereotype» Class1 «optional stereotype» Name of Class Association Name attr2 : int attr1 : data_type = init oper1 (arg_list) : result_type Class2 Class3 { self.class1.attr2->exists( a | a mod 2 == 0 ) }

8. entry: action_1 do: action_2 on event : action_3 … exit action_4 «stereotype» State Name UML Constructs: State Machines • UML defines constructs for (Hierarchical) States, Transitions, Events, Guards, Actions • Based on Statemate event(args) [condition] /action Super State Name «stereotype» State Name «stereotype» State Name

9. UML Constructs: Collaboration • UML defines constructs for illustrating interactions between instances that occur as part of a use case • Example instances • Example messages 1: setScreenColors(256) myWindow :WindowManager 1.1: repaint() :Window 1.2: repaint() w2

10. UML Constructs: Sequences • UML defines constructs for illustrating interactions between instances that occur as part of a use case myWindow :WindowManager :Window setScreenColors(256) repaint() repaint()

11. «stereotype» Comp Name «stereotype» Comp Name «stereotype» Comp Name UML Constructs: Components • UML defines constructs for software components • Basically defines Makefile-style dependencies

12. «stereotype» Comp Name «stereotype» Comp Name «stereotype» Comp Name UML Constructs: Deployment • UML defines constructs for software components • Not very well developed Host Name Host Name

13. UML Constructs: Use Cases • Informally enumerate expected classes of users and usage scenarios (i.e., use cases) • Show dependency and inheritance among use cases • Useful as an input to formal requirements «stereotype» Use Case «stereotype» Use Case «stereotype» Use Case «stereotype» Use Case

14. UML Constructs: Constraints • Any UML model element can have constraints applied to it • Some constraints are predefined, e.g., {or}, {disjoint} • Others can be written in constraint languages, e.g., OCL • Many examples are discussed below • The Object Constraint Language (OCL) is described below

15. «stereotype» State Name «stereotype» State Name Some Comments On This Element UML Constructs: Other • Packages: group elements and define name spaces • Dependencies: indicate that if head element changes, tail element may need revision • Notes: attach comments to any element «stereotype» State Name Package contents

16. UML Example (self.robot->size) / (self.worker->size) < 0.1 0..* Company Course 1..4 1..* 1..* Worker Trainee 0..* Robot «Person» Employee

17. Practitioners View of UML • What you have seen up to this point is probably the type of description most developers will use when learning UML • Examples of notation with explanations in English • However, UML is defined more formally with a meta-model and constraints

18. 1 User Objects in the Running System Run-time instances Checking of design constraints on running system 2 Model of System Under Design Instances of UML constructs Specify design constraints on running system Checking of UML language syntax and semantic constraints 3 Meta-model Abstract syntax of UML constructs defined Constraints on use of constructs in Model 4 Meta-metamodel Data interchange formats between modeling tools E.g., CDIF or MOF Four Levels of Modeling

19. Stereotype «Person» Stereotype Person for instances of meta-class Class [1] If a person is in any composite relationship, it must be the composite (not one of the parts) self.oclType.role.forAll ( myRole |myRole.association.role->exists ( anyRole | anyRole.aggregation = composite) implies myRole.aggregation = composite) • This defines a new kind of class that is like a regular class, but avoids a certain kind of design errors

20. Simplified UML Meta-model 0..* 1..* Class Role Feature 2..* {ordered} 0..* Interface Association Operation Attribute 0..* 0..* {ordered} Parameter

21. UML Extension Mechanisms • UML predefines a set of flexible constructs • Tagged values can be applied to any construct • Constraints can be applied to any construct • Stereotype are groups of tagged values and constraints that can be named and applied to any construct • Stereotypes are the main extension mechanism • They add semantics w/out changing UML language • They can be just names, with meaning for humans

22. Object Constraint Language (OCL) • Useful for • Constraints on classes, associations • pre-, post- conditions • Based on first order predicate logic • And, or, not, forall, exists • Set union, intersection, difference, size, etc. • Strongly typed • Adds a navigation language to “move around” object models and access attributes • Every expression is evaluated in the context of some construct • UML compliant tools must check OCL syntax

23. UML Metrics • ~100 Meta-classes • ~70 Attributes on those meta-classes • ~190 Associations between meta-classes • ~180 Constraints on all of that • Graphical Notation Guide, 142 pagesSemantic Reference, 162 pagesOCL reference, 32 pages • Several books in print, many more on the way

24. Making a New Design Notation • Imagine you are designing a new language to model some aspect of a design/architecture • Identify modeling requirements • Invent constructs to model objects of concern • Define a precise meaning for each construct • Usually a minimum set of constructs is best • Test your language to see if it meets stated needs • Document what you have done, e.g. users’ manual • Implement tools to support your language • This assumes a one-shot process with no reuse

25. UML as a Domain Asset for a Design Notation Product Family • Product families pay off • Investigate domain requirements, gain experience • Invest in a reusable domain model and supporting assets • Only state commonalties in the domain model • Leave the specifics for the products in the family • UML’s meta-model as reusable asset • not perfect, but usable and useful, based on experience • UML provides a set of broadly defined constructs that might not be defined as precisely as we would like • We can “instantiate” UML to make a new design notation with more specific semantics • Still “backward compatible” with standard UML tools

26. UML as a Domain Asset for a Design Notation Product Family • I feel that ACME and UML are basically on the same track, but differ in style and scope • Meta-model classes: ACME 7, UML 100 • Constraint languages: ACME uses Armani and more, UML uses OCL and more • We might prefer to use and teach Scheme, but industry went for more for Common Lisp

27. BackgroundC2: A Software Architecture Style • C2 is a style for building systems with complex user interfaces • Architectures consist of components and connectors • Architecture is layered • Connectors broadcast messages up or down one layer • Request messages only go up; Notifications only go down • Components connect to one connector above and one below • For more detail see C2 paper in TSE, June 1996

28. C2 Example Database Component Admin IU User IU Window System

29. Extending UML to C2C2 Operations • C2 operations are modeled as stereotyped UML operations • C2 operations are tagged as notifications or requests • C2 messages do not have return values Stereotype C2Operation for instances of meta-class Operation[1] c2MsgType : enum { notification, request }[2] not self.oclType.parameter->exists( p | p.kind = return )

30. Extending UML to C2C2 Components • C2 components are modeled as stereotyped UML classes • C2 components have exactly two interfaces, one labeled “top” and one labeled “bottom” • Request messages can only be sent through the top interface, notifications through the bottom interface • C2 components contain four predefined internal parts

31. Extending UML to C2C2 Connectors • C2 connectors are modeled as stereotyped UML classes • A connector’s interface is determined by what it is connected to, rather than being declared • There are only three kinds of associations allowed between C2 components and C2 connectors • C2AttachOverComp connector above component • C2AttachUnderComp connector below component • C2AttachConnConn connector to connector

32. Extending UML to C2C2 Architectures • C2 Architectures are modeled as stereotyped UML SystemModels • C2 architectures can only contain elements with C2 stereotypes • The number of attachments each component has is limited to one above and one below • Each component must attach to something Let comps = self.oclType.elements->select(e | e.stereotype = C2Component), comps.role.association->size > 0

33. «C2Component» Database Component rqst rcvd changeSchema() note sent changedSchema() «C2Component» Admin UI rqst sent changeSchema() note rcvd changedSchema() «C2Component» Database Component rqst sent update() note rcvd changedSchema() C2 Example in UML «C2AttachUnderComp» «C2Connector» Connector_One «C2AttachOverComp» «C2AttachOverComp»

34. DiscussionModeling C2 Architectures in UML • Modeling our style was fairly straightforward • UML provides a good set of broadly defined meta-classes that can be constrained to mean what we wanted to say • Many C2 concepts are similar to those of OO design • Some concepts are very different • We can represent similar concepts in UML and treat others as annotations • Similar concepts might be checked by UML/OCL tools • C2 specific concepts may still need special tools

35. Extending UML to Wright • Wright describes system topology and behavior of components and connectors with CSP • Topology can be constrained as done in the C2 extension • CSP processes are like UML objects with state machines inside, in fact we can define a mapping from CSP constructs to state machine constructs • CSP communication can be mapped to UML messages

36. DiscussionCore Models and Extensions • We propose using a core model (UML) with a core process and adding ADL extensions as needed • Places emphasis on day-to-day development needs;Leverages standard notations, tools, and skills • Architecture questions can be answered as they arise • Adds practicality to ADLs, analysis possibilities to UML • Conflicts between extensions can arise, must be managed Core Model (UML) ADL specific extensions

37. DiscussionCore Models and Extensions • Analysis is a key goal for architecture • Where does architecture fit in process? • Can’t always answer questions before they arise • Don’t just stick architecture early in the waterfall • Use architecture to identify/resolve risks throughout Architecture ADL ADL UML ADL