Dif8901 April 2003 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 exportedOperations) 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 restrictionsTagged values – eg. Version and author tagsStereotypes – eg. Interfaces in calss diagramsProfiles – 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

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.

Conclusions...

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.