Modeling Software Architecture in the Unified Modeling Language (Medvidovic, et al. 2002)

1. Modeling Software Architecture in the Unified Modeling Language (Medvidovic, et al. 2002) Dif8901 April 2003

2. Paper Motivation • The goal of the paper is to assess the expressive power of UML for modelling software architectures while comparing the manner in which existing software ADLs model architectures. • The authors present two strategies for supporting architectural concerns within UML: • Using UML ”as is” for architectural modelling • Utilise features of ADLs and UML extensions Dif8901 April 2003

3. What is UML? • UML ”is a language with a semi-formal semantic specification that includes abstract syntax, wel-formedness rules, and dynamic semantics” (Page-Jones 2000, p.78). • Inspired by a need for a notation for object orientation simple enough to use while powerful enough to merit using. • Can capture the structure of OOS at a level higher than lines of code. • UML is expessed in diagrams such as the class diagram, the sequence diagram, the collaboration diagram and the state diagram. Dif8901 April 2003

4. UML design models and diagrams • Classes and their declared attributes, operations and attributes • Possible states and behaviour of individual classes • Packages of classes and their dependencies • Example scenarios of system usage including kinds of users and relationships between user tasks • The behaviour of the overall system in the context of a usage scenario • Examples of object instances with actual attributes and relationships in the context of a scenario • Egs. of the actual behaviour of interacting instances in the context of a scenario • The deployment and communication of sw components on distributed hosts (Medvidovic et al, 2002, p.7) Dif8901 April 2003

5. Example UML Model An Employee realises all operations of Trainee because Trainee is an interface (set of exported Operations) not a full class Dif8901 April 2003

6. UML Meta Model Dif8901 April 2003

7. What is software architecture? • An aspect of software engineering • Involves the development of large, complex applications with a (new) focus on system structure, high level communication protocols, assignment of sw components and connectors to hosts and development processes (Medvidovic et al. 2002). • According to Medvidovic et al, SA research promises that better systems can result from modelling important architectural aspects throughout the development life cycle (esp early on). Dif8901 April 2003

8. The importance of modelling... Dif8901 April 2003

9. Architecture description languages (ADLs) • Each ADL describes a particular approach to the specification and evolution of an architecture. • ADLs produced by the research community versus competing notations used in the practitioner community (refer table I, p. 4). • Motivation for standardisation of notations and methods for sw analysis and design. • Medvidovic et al, investigate the possibility of using UML as an emerging standard software design language. Their motivation is to bring architectural modelling into wider industrial use. Dif8901 April 2003

10. Research foundation • Using UML to represent the architectural building blocks of an ADL • Medvidovic et al., have defined a minimum set of requirements (five) for evaluating UML’s ability to represent sw architectures effectively: • Structural - should be well suited to model structural concers (eg. Topology or configuration of a system. • Stylistic - Std design vocab, generic system behaviour. • Behavioural aspects of a system • Component interaction • Constraints arising from the systems structure, behaviuor, interactions and styles. (refer page 6). Dif8901 April 2003

11. UML Extension Mechanisms and OCL • Extensions are to customise and extend the semantics of model elements in UML: • Constraints – added semantic restrictions • Tagged values – eg. Version and author tags • Stereotypes – eg. Interfaces in calss diagrams • Profiles – sets of the above Use OCL (object constraint language) to express contraints on UML models (page 8 and 9). Dif8901 April 2003

12. Modelling software architectures in UML • Strategy 1 Using UML as an ADL • Evaluate UML adequacy by using UML to model applications in the same way as they would be modelled using an ADL • Purpose is to assess the support provided by UML for the needs of architectural modelling and compare the modelling power of UML to that of an ADL. • Example application - meeting schedular problem (page 14) • Model this application in the C2 architectural style using its accompanying ADL. • To highlight the similarities and differences between UML and ADLs. Dif8901 April 2003

13. Overview of C2 • C2 and its ADL are used for highly distributed software systems. • Sw connectors transmit messages between components. • Components maintain state, perform operations, and exchange message with other components via two interfaces (’top’ and ’bottom’) • Each interface consists of a set of messages (sent and received). • Refer page 15 (and section 5) for more rules. Dif8901 April 2003

14. Modelling Meeting schedular in C2 • Refer pages 16 – 18 • They used the C2 ADL to present only a partial model of the application • Serves as a basis for evaluating the UML model with the rules of C2. • components such as meeting Initiator and attendee are defined. • The Meeting Schedular architecture (fig 7) is specified in ADL on pg. 18. etc. Dif8901 April 2003

15. Modelling the C2 Style Meeting Schedular in UML • Medvidovic et al., claim that UML constructs are not suitable for describing architecture-level components. ”Components in UML are assumed to be concrete, executable aritifacts that consume machine resources such as memory. In contrast, architectural component are conceptual artifacts that decompose the system’s state and behaviour” (p.18). (A component in UML is a physical piece of code, hence the authors use UML classes to model architectural components) Dif8901 April 2003

16. UML Class diagram for the meeting schedular application Dif8901 April 2003

17. UML class diagram continued • The idea is that UML is driven and constrained both by the modelling features available in UML and the constraints imposed by the ADL. • Previous figure (8) depicts domain classes, their inheritance relationships and associations. • The diagram abstracts away many architectural details, such as: mapping of classes in the domain to implementation conponents and also the order of interactions among the different classes. Dif8901 April 2003

18. C2 style in UML continued • In UML they model message interfaces of C2 as class icons stereotyped with <<interface>> see page 20 figure 9. The interfaces • C2 architecture in UML requires that connectors must also be defined (refer figure 10, page 20) • A diagram depicting the interface relationships between the classes is shown at figure 11. • A collaboration diagram at figure 12 depicts a collaboration between an instance of the meetingInitiator class and instances of the attendee and ImportantAttendee classes. Dif8901 April 2003

19. Strategy 1 discussion: • Medvidovic et al., claim that mostly we can successfully model a C2-style arch in UML (using architectural concepts such as: interfaces, components, component associations etc. • Nonetheless, modelling capabilities provided by UML do not completely satisfy the structural requirements of architectural description because: • UML does not provide specialised constructs for modelling architectural artifacts (i.e. we must model connectors and components in the same way in UML) • The rules of an architectural style are reflected in the ADL and the toolset, but those rules must be applied explicitly by the UML sw architect. Dif8901 April 2003

20. Strategy 2: Constraining UML to model software architectures • Using OCL to specify additional constraints on existing meta classes of UML’s meta model • Treats UML as a core notation that is extended to support architectural concerns. i.e. UML is conceptually extended to provide additional modelling tools that did not originally exist in UML. • The UML meta model remains intact, but the OCL facilities are used to constrain the notation. • The authors use 3 ADLS to demo this approach: C2, Wright and Rapide (refer pages 24 to 46). Dif8901 April 2003

21. Strategy 2: ADL specific extensions • Are a basis of an evolvable, broadly applicable extension of UML for architectural modelling. • Relies heavily on OCL. • The formality may reduce widespread adoption of startegy • UML is surprisingly flexible in representing a wide range of semantic concerns. Dif8901 April 2003

22. Conclusions... • Medvidovic et al., have described approaches to overcome a key weaknesses of UML, its lackof adequate support for modelling software architectural concerns • Common goal in both strategies is to exploit UML as a base notation without adding too many incompatibilities or adding too much complexity. • Their approach considers what should be in the core model and what should be left to extensions. • They choose UML as their ground model because it is grounded in mainstream development practices and has substantial tool support. Dif8901 April 2003

23. Conclusions Continued... • Considerable effort is required to adapt UML to be a useful complement to ADLs and to be a practical step toward mainstream modelling (Medvidovic et al., 2002). • Six key insights: • Software modelling philosophies • Assumptions about intended usage • Problem domain modelling • Architectural abstractions • Architectural styles • Implementation support Dif8901 April 2003

24. Comments • Research was motivated by industry support for UML (the available tool support). • Many more powerful software architecture languages more suitable for the purposes described in this paper. UML extensions such as constraints and stereotypes are required to achieve what other software architecture languages are designed for. Dif8901 April 2003

25. References • Medvidovic, N., Rosenblun, D.S., Redmiles, D.F and Robbins, J. E. (2002): Modeling Software Architectures in UML. ACM Transactions on Software Engineering and Methodology, Vol. 11, No 1. • Page-Jones, M. (2000): Fundamentals of Objct-Oriented Design in UML. (Eds) Booch, G., Jackobson, Rumbaugh, Adison-Wesley. Dif8901 April 2003