130 likes | 314 Views
Architectural Aspects in UML. Workshop on Aspects in Architectural Description Monday March 12th 2007. Jon Oldevik, University of Oslo, Norway jonold at ifi.uio.no. Preface. Motivation Architectural Aspects by Example Comparison with UML Constructs
E N D
Architectural Aspects in UML Workshop on Aspects in Architectural Description Monday March 12th 2007 Jon Oldevik, University of Oslo, Norway jonold at ifi.uio.no
Preface • Motivation • Architectural Aspects by Example • Comparison with UML Constructs • Further Work / Summary / Relationship with AARCH contributions
Motivation • UML de-facto standard for graphical modelling • Also a candidate for modelling architectures • Architecture community seems to find UML deficient • Connectors not first class • How can aspects be used for architecture in UML • Represent architectural views? • Represent architectural concerns? • Be used to compose new architectures? • How does architectural aspects compare with standard UML language mechanisms?
Representation of Aspects: Access Control Aspect Unbound ports
Binding the aspect AspectBinding { aspect: AccessControlAspect; base: ICU-System; PortMap {(acEnv, envUsr), (inRec, fromUsr), ((inDB, outDB), new Port (dbManager, ”acPort”)} } Interesting challenge! New structure and behaviour on an existing element. Desirable?
Related to the original system Distributed Proxy
The binding for the DPA AspectBinding { aspect: DistributedProxyAspect; base: ICU-System; PortMap { ((lp, rp), (toCtrl, fromSms), distrProxy=”p1”), ((lp, rp), (toSms, fromCtrl), distrProxy=”p2”)} }
Comparison with UML Constructs • Aspects vs Specialisation • The extensions done in the example are not legal UML specialisations • Could have redefined parts and add new complexity there • E.g. redefine smsMgr and add access control inside it. • Must specify the new architecture • Cross cutting benefits lost • Result architecture is different • Product line approach: • All changes are anticipated and provided as ”virtual” elements that can be redefined in specisalisations • Extended Virtual Connectors • Connectors in UML can be virtual and hence be redefined in specialisations • Connectors must be redefined by connectors • Redefinitions must be type compatible • Redefinition of connectors by more complex structures might by useful! • This was introduced in SDL, but later deprecated • Connectors as objects with types? • Aspect Bindings vs CollaborationUse • UML provides a mechanism called collaboration use • Binds roles (parts) of collaborations with parts of a class • Pros • Notation is there. • Cons • Impossible to impact the existing structure, which is what we want. • An extension to collaboration uses would be required.
Summary / Further Work • Binding Language • Semantics: What should it express? • Quantifications: E.g. all ports providing interface Y • Syntax: How should it be expressed? • In UML constraints? Separate specification? Graphical? • What changes should be legal? • Additions / deletions / modifications to ports, parts, … • Implications for existing structure and behaviour • Legal to modify internals of existing parts? • Restrict to only structure? • Further evaluation of UML constructs and possible UML extensions • What can it be useful for? • Representing architectural concerns • Composition of architecture variants