ACM SIGSOFT Software Engineering Notes
Page 1
January 2006
Volume 31
Number 1
Formally Modelling Software Architectures with the UML 2.0 Profile for π-ADL Flavio Oquendo University of South Brittany VALORIA – Formal Software Architecture and Process Research Group B.P. 573 – 56017 Vannes Cedex – France
[email protected] Abstract
Is the latest release of UML, i.e. UML 2.0, suitable as an ADL?
A key aspect of the design of any software system is its architecture. An architecture description, from a runtime perspective, should provide a formal model of the architecture in terms of components and connectors, their ports and behaviours, and how they are composed together. The Unified Modelling Language (UML) is widely used in the design of software systems and has recently been extended to better support software architecture description. This paper presents the UML 2.0 Profile for π-ADL, a novel ADL that has been designed in the ArchWare European Project. It briefly presents π-ADL and its UML 2.0 Profile, then it illustrates through a case study how the UML 2.0 Profile for π-ADL can be used for formally modelling software architectures. The toolset for supporting the UML 2.0 Profile for π-ADL is outlined: it supports architecture modelling, architectural behaviour animation, and model checking of architectural properties.
The answer is “as is”, no, it is not [20]. The modelling capabilities provided by UML “as is” do not fully satisfy the structural and behavioural requirements for describing software architectures for two key reasons. First, UML 2.0 does not provide specialized constructs for modelling software architectures, in particular for modelling software architectures from a runtime perspective. For example, although they are different architectural elements with very different responsibilities, components and connectors must be modelled in UML 2.0 using the same mechanism. Second, the rules of a given architectural style must be applied mentally by the software architect who chooses to use UML 2.0 for describing software architectures.
Keywords: UML 2.0 Profile, Software Architecture Modelling, Architecture Description Language, π-ADL 1. Introduction Software architecture has emerged as an important subdiscipline of software engineering. A key aspect of the design of any software system is its architecture, i.e. the fundamental organisation of the system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution [15]. An architecture can be modelled according to different viewpoints. From a runtime perspective, two viewpoints are frequently used in software architecture [15]: the structural viewpoint and the behavioural viewpoint. The structural viewpoint may be specified in terms of: • components (units of computation of a system), • connectors (interconnections among components for supporting their interactions), • configurations of components and connectors. Thereby, from a structural viewpoint, an architecture description should provide a formal model of the architecture in terms of components and connectors and how they are composed together. The behavioural viewpoint may be specified in terms of: • actions a system executes or participates in, • relations among actions to specify behaviours, • behaviours of components and connectors, and how they interact. A large challenge for an Architecture Description Language (ADL) is the ability to model software architectures from structural and behavioural viewpoints.
In addition to modelling structural aspects of an architecture, modelling constructs are also needed for modelling the dynamic behaviour of components and connectors, and their interactions. UML’s features, such as state machines can be used effectively to this end. As with the structural modelling constructs, however, it may be difficult to ensure that the intended behaviours or interactions are correctly modelled in UML 2.0. Hence, describing software architectures in UML 2.0 is an error-prone approach. However, does UML 2.0 provide a suitable base for defining profiles for formally modelling software architectures? The answer is, yes, it provides a much better basis than UML 1.5. This paper presents a UML 2.0 Profile for π-ADL, a novel ADL that has been designed in the ArchWare1 European Project. π-ADL [26][28][24] is a formal architecture description language: • it is a formal, well-founded theoretically language based on the higher-order typed π-calculus [31][32]; • it is automated by tools, i.e. a specification and verification toolset providing support for automated checking. The remainder of this paper is organised as follows. Section 2 introduces π-ADL core concepts. Section 3 briefly presents the UML 2.0 Profile for π-ADL. Section 4 illustrates through a case study how the UML 2.0 Profile for π-ADL can be used for formally describing software architectures. In section 5, we compare π-ADL with related work. To conclude we summarise, in section 6, the main contributions of this paper and briefly outlines the toolset for supporting the UML 2.0 Profile for π-ADL (it supports architecture modelling, architectural behaviour animation, and model checking of architectural properties).
1
The ArchWare European Project was partially funded by the Commission of the European Union under contract No. IST-2001-32360 in the IST-V Framework Programme.
ACM SIGSOFT Software Engineering Notes
Page 2
2. Concepts and Notation π-ADL supports description of software architectures from a runtime perspective. In π-ADL, an architecture is described in terms of components, connectors, and their composition. Figure 1 depicts its main constituents.
January 2006
Volume 31
Number 1
connections are observable. From a white-box perspective, internal behaviours are also observable. Components and connectors can be composed to construct composite elements (see Figure 2), which may themselves be components or connectors. Composite elements can be decomposed and recomposed in different ways or with different components in order to construct different compositions. Composite components and connectors comprise external ports (i.e. observable from the outside) and a composition of internal architectural elements. These external ports receive values coming from either side, incoming or outgoing, and simply relay it to the other side keeping the mode of the connection. Ports can also be declared to be restricted. In that case, constituents of composite elements can use connections of restricted ports to interact with one another but not with external elements.
Figure 1. Architectural constructs in π-ADL Components are described in terms of external ports and an internal behaviour. Their architectural role is to specify computational elements of a software system. The focus is on computation to deliver system functionalities. Ports are described in terms of connections between a component and its environment. Their architectural role is to put together connections providing an interface between the component and its environment. Protocols may be enforced by ports and among ports. Connections are basic interaction points. Their architectural role is to provide communication channels between two architectural elements. Connections may be unified to enable communication. A component can send or receive values via connections. They can be declared as output connections (values can only be sent), input connections (values can only be received), or input-output connections (values can be sent or received). Connectors are special-purpose components. They are described as components in terms of external ports and an internal behaviour. However, their architectural role is to connect together components. They specify interactions among components. Therefore, components provide the locus of computation, while connectors manage interaction among components. A component cannot be directly connected to another component. In order to have actual communication between two components, there must be a connector between them. Both components and connectors comprise ports and behaviour. In order to attach a port of a component to a port of a connector, at least a connection of the former port must be attached with a connection of the later port. A connection provided by a port of a component is attached to a connection provided by a port of a connector by unification or value passing. Thereby, attached connections can transport values (that can be data, connections, or even architectural elements). From a black-box perspective, only ports (with their connections) of components and connectors and values passing through
Figure 2. Architectural composition in π-ADL Architectures are composite elements representing systems. An architecture can itself be a composite component in another architecture, i.e. a sub-architecture. π-ADL provides primitive constructs for supporting the description of all these architectural concepts. In π-ADL, architectures, components, and connectors are formally specified in terms of typed abstractions over behaviours. π-ADL is formally defined by a formal transition and type system. Its structural operational semantics represents behaviour (and thereby computation) by means of a deductive system, expressed by a formal transition system, in line with a type system. Type soundness asserts that well-typed terms do not give rise to runtime errors under the transition system (see [28] for details). The π-ADL concrete syntax is defined in terms of context free and context sensitive definitions. Production rules are used to define the context free syntax of π-ADL. The production rules are further qualified by a set of context sensitive type rules (not presented hereafter for the sake of simplicity). Also for the sake of simplicity, we present hereafter a simplified abstract syntax in terms of production rules expressed as follows: • • •
•
keywords are written with bold; non-terminals are written without bold; a sequence of zero, one or more elements is written: Elementmin, …, Elementmax, where the value of min specifies the minimum number of elements (0 specifies possibly no elements, 1 specifies at least one element) and the value of max specifies the maximum number of elements (Elementn specifies any number of elements); alternative choices are written separated by |.
ACM SIGSOFT Software Engineering Notes
Page 3
The abstract syntax of types for expressing typed behaviours is defined as follows. syntax of types ValueType
::=
BaseType
|
ConstructedType
January 2006
::=
∆, name : ValueType
|
∅
Number 1
The abstract syntax for expressing typed behaviours is defined in Figure 6. Behaviours are expressed using the following π-ADL constructs: type, value, prefix, condition, choice, composition, decomposition, replication, inaction, application. syntax of behaviours behaviour
syntax of type environments ∆
Volume 31
::= type . behaviour |
value . behaviour
|
prefix . behaviour
|
if
boolean then { behaviour1 } else { behaviour2 }
Figure 3. Abstract syntax of value types As shown in Figure 3, all types are value types. Value types are base types or constructed types. Type environments are expressed through declarations. A value can be declared as being of a base type or a constructed type.
|
choose
{ behaviour0 … or behaviourn }
|
compose
{ behaviour0 … and behaviourn }
|
decompose behaviour
The abstract syntax of base types is defined in Figure 4.
|
replicate
|
done -- inaction
|
abstraction ( expression0 …, expressionn ) -- application
behaviour
syntax of base types BaseType ::=
Any prefix
|
Natural
|
Integer
|
Real
|
Boolean
|
String
|
Behaviour
::= via connectionValue send value |
via connectionValue receive variable : ValueType
|
unobservable
|
if boolean do prefix
syntax of values value
::= baseValue |
Figure 4. Abstract syntax of base types The abstract syntax of constructed types is defined in Figure 5.
constructedValue
constructedValue ::=
…
|
connectionValue
|
behaviourValue
|
abstractionValue
syntax of constructed types ConstructedType ::= tuple [ ValueType1, …, ValueTypen ] |
view [ label1 : ValueType1, …, labeln : ValueTypen ]
|
union [ ValueType1, …, ValueTypen ]
|
quote [ name ]
|
variant [ label1 : ValueType1, …, labeln : ValueTypen ]
|
location [ ValueType ]
|
sequence [ ValueType ]
|
set [ ValueType ]
|
bag [ ValueType ]
|
inout [ ValueType ] | in [ ValueType ] | out [ ValueType ]
|
ValueType0, …, ValueTypen → Behaviour
Figure 5. Abstract syntax of constructed types
Figure 6. Abstract syntax of typed behaviours and values Type type name is ValueType . behaviour introduces an alias to type ValueType in the scope of a behaviour behaviour. Value Declaration value name is value . behaviour expresses the restriction of the scope of a name name, bound to value value, to the scope of a behaviour behaviour. Prefix Behaviours enact by performing actions. The capabilities for action are expressed via the prefixes. A prefix can be an output or input prefix, a silent prefix or a match prefix. An output prefix via connection send value expresses the capability to send a value value via the connection connection. An input prefix
ACM SIGSOFT Software Engineering Notes
Page 4
January 2006
Volume 31
Number 1
via connection receive value expresses the capability to receive a value value via the connection connection. The silent prefix unobservable expresses the capability to enact an action invisibly, i.e. internally, silently. The match prefix if boolean do prefix expresses the capability of enacting a prefix prefix if the condition boolean is true, or do nothing otherwise.
behaviour }.
Prefix prefix . behaviour expresses the capability of a behaviour to enact a prefix prefix and then become behaviour. Thereby, prefix expresses the capability of sending and receiving values via connections, enacting unobservable actions, or enacting conditional actions. After enacting prefix, the behaviour will proceed as behaviour.
Application In order to apply abstractions, application3 is used. An application has the form abstraction ( value0,…,valuen ). Applications instantiate abstractions yielding behaviours.
Condition Condition if boolean then { behaviour1 } else { behaviour2 } expresses the capability of a behaviour to proceed as behaviour1 if the boolean is true, otherwise as behaviour2. When one of the capabilities is exercised, the other is no longer available.
Inaction Inaction done is a behaviour that can do nothing. Inaction is not a basic construct: it can be defined as an empty choice.
Declaring types and values supports the expression of architectural abstractions. An architectural abstraction can be an architecture, a component or a connector. Interfaces of architectural abstractions are expressed by ports in terms of incoming, outgoing or incoming-and-outgoing connections. The abstract syntax for expressing architectural abstractions is defined in Figure 7.
Choice Choice choose { behaviour0 … or behaviourn } expresses the capability of a behaviour to choose either the capability of behaviour0 or the capability of behaviour1 … or the capability of behaviourn. When one of the capabilities is exercised, the others are no longer available. Thereby, the choice will proceed either as behaviour0’ or as behaviour1’ … or as behaviourn’, i.e. as a behaviour behaviouri’ after exercising the capability of behaviouri.
syntax of architectural abstractions architecturalAbstraction ::= archtype name is abstraction archtype ::= abstraction
architecture | component | connector ::=
abstraction ( name0 : ValueType0, …, namen : ValueTypen ) { type0 . … . typen .
Composition Composition compose { behaviour0 … and behaviourn } expresses the capability of a behaviour to parallel compose the capabilities of behaviour0 … and behaviourn. behaviour0 … and behaviourn can proceed independently and can interact via attached connections. Thereby, the composition will proceed by exercising the capabilities of independent actions in behaviour0’ … and behaviourn’, or jointly exercising a capability of interaction, i.e. when via an attached connection one behaviour sends a value and the other receives the value yielding an unobservable communication action.
value0 . … . valuen . port0 . … . portn . behaviour is { behaviour } } assuming { property } type ::=
type name is ValueType
value ::=
value name is expression
port ::=
port name is restriction { connection0 . … . connectionn
Decomposition Decomposition decompose behaviour expresses the capability of a behaviour to be decomposed into its constituent behaviours behaviour1 … and behaviourn with their unbound connections. A behaviour is decomposed in its constituent behaviours once it reaches its reduction limit2. Behaviours, and in particular composite behaviours, can be decomposed and recomposed. The decomposition of a composite behaviour yields the set of constituent behaviours as they were before composition, i.e. behaviours with their unbound connections. These behaviours can be composed again in the same or another composition.
} assuming { protocol is property } restriction ::=
free | restricted
connection ::=
connection name is mode ( ValueType )
mode ::=
in | out | inout
Figure 7. Abstract syntax of architectural abstractions π-ADL is formally defined by a formal transition and type system. The π-ADL abstract syntax is completely defined in [28]. Its concrete textual syntax (with a tutorial) is presented in [24].
Replication Replication replicate behaviour expresses the capability of a behaviour to replicate itself infinitely. It can be thought of as an infinite composition defined as compose { behaviour and replicate 2
Behaviours must be in normal form with respect to β-reduction of values in order to be decomposed.
3
The term application is used instead of pseudo-application.
ACM SIGSOFT Software Engineering Notes
Page 5
3. UML 2.0 Profile The release 2.0 of the Unified Modelling Language (UML 2.0) builds on the UML 1.5 standard, which has become an industry standard for modelling, design and construction of software systems as well as more generalized business and scientific processes. In UML 2.0, as was the case in UML 1.5, there is no specific diagram for modelling architectures. In fact, constructs for architecture description are not directly provided but architecture description is supported and can be expressed as a combination of different views, e.g. 4+1 views. What is new in UML 2.0 concerning support for architecture description? UML 2.0 provides a major improvement in its support to architecture description with a major enhancement in the Component Diagram and the introduction of a new diagram – the Composite Structure Diagram. In fact, Component Diagrams have largely evolved. Until UML 1.5, Component Diagrams were promoted as detailed design diagrams for software component-based systems. The focus was on the implementation view of a system in terms of software components. In UML 2.0, components have been generalised, and are consider as higher-level than classes. The UML 2.0 Profile for π-ADL defines the following stereotype icons whose meanings were presented in the previous section. Stereotype
Stereotype Icon
January 2006
Volume 31
Number 1
« composite »
« abstraction »
Inherited from « abstraction »
« port »
Port
connection[*] protocol[*]
« connection »
Interface
protocol[*]
« unification »
Assembly Connector
renaming[0..1]
« relay »
Delegation Connector
renaming[0..1]
« protocol »
Comment
–
Meta-attribute
Type
Surface Notation
« parameter »
String
π-ADL
« type »
String
π-ADL
« value »
String
π-ADL
« connection »
String
π-ADL
« protocol »
String
π-ADL
« renaming »
String
π-ADL
The constructs of state machines in UML 2.0 enhances those of statecharts in UML 1.5. Behaviours of architectural abstractions (π-ADL Components or Connectors) are described in terms of stereotyped UML 2.0 State Machines as follows. Behaviour States
Final state
Intermediate state
Initial state
Behaviour Transitions p refix
v ia connec ti on n a m e se nd va lue v ia connec ti on n a m e re c eive va lue un ob serva bl e
The stereotypes belonging to the UML 2.0 Profile for π-ADL are described hereafter using a compact tabular form rather than graphically. The first column gives the name of the stereotype label corresponding to the stereotype. The second column identifies the base metaclass of the stereotype. The last column identifies the defined tags. Stereotype
Base Metaclass
Tags
« abstraction »
Component (including Ports, Interfaces, and Behaviour)
parameter[*] type[*] value[*]
« component »
« abstraction »
Inherited from « abstraction »
« connector »
« abstraction »
Inherited from « abstraction »
[c ondition ] pr efix M at ch p ref ix : [ va lue = va lue ]
prefix
::=
via name send
value
-- output prefix
|
via name receive value
-- input prefix
|
unobservable
-- silent prefix
|
if value=value do prefix
-- match prefix
ACM SIGSOFT Software Engineering Notes
Page 6
Sequence Behaviour
January 2006
Volume 31
Number 1
Recursive Behaviour
] A (X , Y )
S e qu enc e A (a , b )
Behaviour
R ecu rsio n
::=
…
|
prefix . Behaviour
-- prefix
Behaviour
::=
…
|
BehaviourApplication
BehaviourApplication ::= name { v1,…,vn }
Choice Behaviour
For instance, the following behaviour expressed in the UML 2.0 Profile for π-ADL: C hoi ce
b (X : R eal, Y : R eal)
b (X , Y )
Behaviour
v ia p sen d X
::= … | choose { Behaviour1 or Behaviour2 }
-- choice
v ia p sen d Y
R ecu rsion
translates to the following π-ADL expression:
Replicated Behaviour
behaviour b(X: Real, Y: Real) is { via p send X . via p send Y . b(X, Y) }
< < rep li cat e > > R ep lic ation
Composed Behaviour Behaviour
::= … | replicate Behaviour
-- replication
Restricted Behaviour
C omposi tion
< < F ree > > n am e: C o n n ectio n T y p e
Behaviour
::= … | compose { Behaviour1 and Behaviour2 } -- composition
R estrictio n (b y d efau lt)
Behaviour
::=
…
| restrict name : ConnectionType . Behaviour
-- restriction
The translation rules for generating architecture descriptions in π-ADL from UML 2.0 models describing software architectures are based on the stereotypes and tags specified above. They are illustrated in the next section through a case study. The screenshot below (see Figure 8) partially depicts the three π-ADL profile packages that comprise the UML 2.0 Profile for π-ADL.
ACM SIGSOFT Software Engineering Notes
Page 7
January 2006
Volume 31
Number 1
4. Case Study We present hereafter a case study to demonstrate how the UML 2.0 Profile for π-ADL, named π-UML2 for short, can be used to formally describe a software architecture. We describe a client-server architecture of a login system. First we will present a black-box description of the architecture focusing on interface (i.e. ports and their connections) of components and connectors. Then we will add the internal behaviour of components and connectors in a white-box description. Finally the encompassing structure (i.e. binding among components and connectors using connection unifications) is described. The login system supports the creation of new logins by receiving a new userId and a password to be stored under this userId. Concurrently, it supports checking of existing logins by answering requests for the password of a certain existing userId by sending the password stored under this userId. Figure 10 depicts a black-box description of the login system using an icon stereotype display in the UML 2.0 Profile for π-ADL. It is represented as a composite component, named LoginManager, having ports 4 update and request. These ports represent the interaction of the LoginManager system with its environment.
update
request LoginManager
Figure 8. Profile packages composing the UML 2.0 Profile for π-ADL
Figure 10. Black-box description in π-UML2 (icon display)
The resulting toolbox for visual modelling software architectures with the UML 2.0 Profile for π-ADL is presented in Figure 9. LoginManager UserId = Any Password = Any Login = tuple[UserId, Password]
update upd = in(Login)
request log = in(UserId) pwd = out(Password) ( via log receive any. true*. via pwd send any )*
Figure 9. Toolbox of the UML 2.0 Profile for π-ADL The complete description of the stereotypes and the tags, their syntax and formal semantics, that composes the UML 2.0 Profile for π-ADL are given in [27].
Figure 11. Black-box description in π-UML2 (decoration display)
4
By syntactic convention, ports that are not explicitly declared as restricted are external free ports.
ACM SIGSOFT Software Engineering Notes
Page 8
January 2006
Volume 31
Number 1
Figure 11 further details the black-box model of Figure 10 using a decoration stereotype display. In this interface description of the login system, type UserId is the set of all possible userIds and type Password is the set of all possible passwords. Login is the tuple type tuple[UserId, Password], i.e. the set of all possible logins associating userId and password. Two ports are declared: update that comprises the connection in for receiving new login entries and request that comprises the connections log and pwd for answering requests. The protocol enforced by this port is that requests for the password of a certain userId, which are received via the connection log, are answered by sending (after processing) a password via the connection pwd. For each userId received there must be a password sent before accepting the next userId.
NewLoginUI UserId = Any Password = Any Login = tuple[UserId, Password]
incoming in = in(Login)
(
The black-box description of the LoginManager system expressed using the UML 2.0 Profile for π-ADL in Figure 11 can be formally translated in π-ADL as shown in Figure 12.
via incoming::in receive any. true*. via outgoing::toLink send any )*
outgoing toLink = out(Login)
architecture LoginManager is abstraction() { type UserId is Any. type Password is Any.
Figure 14. Component NewLoginIU in π-UML2
type Login is tuple[UserId, Password]. port update is {
connection upd is in(Login) }.
port request is {
connection log is in(UserId). connection pwd is out(Password)} assuming {
protocol is { ( via log receive any. true*. via pwd send any )* } }. … }
Figure 12. Black-box description of the architecture in π-ADL The login system is composed of a login user interface (UI) and a login database manager. The login IU acts as a client of the database manager that acts as a server managing the login data. A new login entry received from the environment first undergoes some processing in the login IU and is then forwarded to the remote database manager that stores its data. Figure 13 outlines the architecture of the system in terms of its components and connectors.
In component NewLoginIU (shown in Figure 14), two ports are declared: incoming that comprises the connection in for receiving new login entries and outgoing that comprises the connection toLink for forwarding these logins. The protocol enforced by the two ports is that a value received via the connection in is (after processing) forward by sending some (possibly processed) value via the connection toLink. For each new login entry received there must be a login sent before accepting the next new login. The component NewLoginIU described using the UML 2.0 Profile for π-ADL in Figure 14 can be formally translated in π-ADL as shown in Figure 15. component NewLoginUI is abstraction() { type UserId is Any. type Password is Any. type Login is tuple[UserId, Password]. port incoming is { connection in is in(Login) }. port outgoing is { connection toLink is out(Login) }. … } assuming {
update
protocol is { (
request
via incoming::in receive any. true*. via outgoing::toLink send any )* }
LoginManager
} incoming
outgoing
outgoing
incoming
incoming
select
Link NewLoginUI
LoginDB
Figure 13. Description of the architecture in π-UML2 (icon) The architecture consists of a login IU component NewLoginIU, a database manager component LoginDB, and a connector Link to connect them together. They can be formally described in π-UML2 and translated in π-ADL as follows.
Figure 15. Component NewLoginIU in π-ADL
ACM SIGSOFT Software Engineering Notes
Page 9
LoginDB UserId = Any Password = Any Login = tuple[UserId, Password]
January 2006
Volume 31
Number 1
Link UserId = Any Password = Any Login = tuple[UserId, Password]
incoming toLink = in(Login)
select log = in(UserId) pwd = out(Password) ( via log receive any. true*. via pwd send any )*
(
via incoming::toLink receive login : Login. via outgoing::fromLink send login )*
incoming fromLink = in(Login) outgoing fromLink = out(Login)
Figure 16. Component LoginDB in π-UML2 In component LoginDB (shown in Figure 16), two ports are declared: select that comprises the connection log for receiving userId values and the connection pwd for sending the password value stored under this userId, and incoming for receiving new login entries to be stored. The component LoginDB described using the UML 2.0 Profile for π-ADL in Figure 16 can be formally translated in π-ADL as shown in Figure 17. component LoginDB is abstraction() {
Figure 18. Connector Link in π-UML In connector Link (shown in Figure 18), two ports are declared: incoming that comprises the connection toLink for receiving login entries and outgoing that comprises the connection fromLink for forwarding these entries. The protocol enforced by the two ports is that login entries received via the connection toLink are immediately forward by sending it via the connection fromLink. The connector Link described using the UML 2.0 Profile for π-ADL in Figure 18 can be formally translated in π-ADL as shown in Figure 19.
type UserId is Any. type Password is Any. type Login is tuple[UserId, Password]. port select is {
connector Link is abstraction() {
connection log is in(UserId).
type UserId is Any. type Password is Any.
connection pwd is out(Password)
type Login is tuple[UserId, Password].
} assuming {
port incoming is { connection toLink is in(Login) }.
protocol is { ( via log receive any. true*. via pwd send any )* }
port outgoing is { connection fromLink is out(Login) }.
}.
…
port incoming is { connection fromLink is in(Login) }.
} assuming {
…
protocol is { ( via incoming::toLink receive login : Login.
}
via outgoing::fromLink send login )* }
Figure 17. Component LoginDB in π-ADL
}
Figure 19. Connector Link in π-ADL This black-box description of the LoginManager architecture can be further detailed to achieve a white-box description of the architecture that encompasses interface, behavioural and structural aspects. For instance, the behaviour of the connector Link can be described using the UML 2.0 Profile for π-ADL in terms of state machines as follows.
ACM SIGSOFT Software Engineering Notes
Page 10
January 2006
Volume 31
Number 1
via incoming::toLink receive login : Login
architecture LoginManager is abstraction() { … behaviour is compose { replicate ui via outgoing::fromLink send login *
Figure 20. Behaviour of the connector Link in π-UML
}
In connector Link, the behaviour specifies that login entries received via the connection toLink are immediately forward by sending it via the connection fromLink. The behaviour is recursively defined. Once a login entry is handled, it continues with the same (recursive) behaviour for the next entry. The behaviour of the connector Link described using the UML 2.0 Profile for π-ADL in Figure 20 can be formally translated in π-ADL as shown in Figure 21. connector Link is abstraction() { … behaviour is { via incoming::toLink receive login : Login. via outgoing::fromLink send login. behaviour() } } assuming { … } }
Figure 21. Behaviour of the connector Link in π-ADL Now let us come back to the architecture described in Figure 13 (depicted again in Figure 22 below). Using the components NewLoginIU and LoginDB and the connector Link, the architecture of LoginManager can be described using the UML 2.0 Profile for π-ADL as shown in Figure 22, thereby providing the structure of the architecture in terms of attached components and connector.
update
request LoginManager
incoming
outgoing
outgoing
incoming
incoming
select
Link NewLoginUI
LoginDB
Figure 22. Description of the architecture in π-UML2
*
That architecture description expressed in the UML 2.0 Profile for π-ADL can be formally translated in π-ADL as shown in Figure 23.
is NewLoginUI()
and
lk
is Link()
and
db
is LoginDB()
where {
ui::incoming relays update
and
ui::outgoing unifies lk::incoming
and
lk::outgoing unifies db::incoming
and
request relays db::select
} }
Figure 23. Composition of the Architecture In the architecture, the component instances ui and db are connected using the connector lk. In order to actually connect them, connections must be unified5. Connection toLink of port outgoing of component iu is unified with connection toLink of port incoming of connector lk. Connection fromLink of port outgoing of connector lk is unified with connection fromLink of port incoming of component db. Besides connecting component instances together, the architecture must express the binding between external ports and ports of components. This binding is expressed by connection relay. Connection in of external port update is relayed to connection in of port incoming of component iu. Connection log of external port request is relayed to connection log of port select of component db. Connection pwd of port select of component db is relayed to connection pwd of external port request. The architecture is dynamic: there are as many iu instances as needed (the number of instances is only known at runtime). 5. Related Work Different ADLs have been proposed in the literature [21], including: ACME/Dynamic-ACME, AESOP, AML, ARMANI, CHAM-ADL, DARWIN, META-H/AADL, PADL, RAPIDE, SADL, σπ-SPACE, UNICON-2, WRIGHT/Dynamic-WRIGHT, and ZETA. Comparing ADLs objectively is a difficult task because their focuses are quite different. Most ADLs essentially provide constructs for a component-and-connector description including topological constraints from a structural viewpoint. The reason for this is probably that structure is certainly the most understandable and visible part of an architecture. But behavioural and qualities are not completely neglected. They are often taken into account (even if partially) in most ADLs. They are certainly an essential part of an architecture description. π-ADL introduces the notion of architectural abstractions, which can be architectures, components and connectors from a runtime perspective. All abstractions are first-class citizens. In π-ADL, 5
If connections have the same names in different ports, identifying ports is enough to express unifications (if connection names are different, then they must be explicitly unified).
ACM SIGSOFT Software Engineering Notes
Page 11
architectures, components, and connectors are formally specified in terms of typed abstractions over behaviours. These abstractions can be enforced to comply with architectural styles [8]. No other ADL provides a comprehensive set of features for describing software architectures (including evolvable software architectures [14][23]) as π-ADL. Further details on the positioning of π-ADL with respect to the state-of-art can be found in [12][17][26]. The definition of UML Profiles for modelling software architectures in itself is not new. In fact, [20] identifies three possible strategies for modelling software architectures using UML: • to use UML “as is”; • to extend the UML metamodel to directly support the needed architectural concepts; • to constrain the UML metamodel using UML’s built-in extension mechanisms (e.g. UML Profile). Each approach has pros and cons. Regarding π-ADL, the first strategy has no interest. We have then experimented with the other two. In [3], we extended the UML 1.5 metamodel to support the architectural concepts of π-ADL. The resulting metamodel was not compliant to UML and the customisation of existing UML tools was a heavy process. Indeed, the use of UML Profile as an extension mechanism provides the best compromise to at the same time remain compliant with UML and specialise UML with a precise semantics.
January 2006
Volume 31
Number 1
6. Conclusion The UML 2.0 Profile for π-ADL briefly presented in this paper provides a UML-compatible visual notation for formal modelling software architecture. This UML 2.0 Profile provides an easy to learn and low cost entry point for describing software architectures formally. Indeed, π-ADL supports formal specification (and corresponding verification) of static and dynamic software architectures. This is a key factor in the architectural design phase. A major impetus behind developing formal languages for architectural description is that their visual notation must be user-friendly and their formality renders them suitable to be manipulated by software tools. The usefulness of an ADL is thereby directly related to the kinds of tools it provides to support visual and formal architecture description, but also analysis, refinement, code generation, and evolution [29]. Indeed, π-ADL (including the UML 2.0 Profile as its visual notation) is supported by a comprehensive toolset for supporting architecture-centric formal development. It is composed of: • a π-ADL visual modelling tool [4], • a π-ADL callable compiler and a persistent virtual machine, • a π-ADL verification tool based on CADP [13][19] and XSB Prolog, • a π-ADL refinement tool providing a process-centred refinement framework based on the Maude rewriting logic system [5][18], • a π-ADL-to-Code synthesizer, from which, among others, a π-ADL-to-Java code generation tool has been synthesized.
The π-ADL visual modelling tool [4] is implemented as an The UML 2.0 Profile for π-ADL is based on that approach, i.e. it extension of the Objecteering UML Modeller. It implements the adds the typed π-calculus semantics underlying π-ADL to UML. UML 2.0 Profile for π-ADL, including generation of architecture Thereby, it supports semantics checking and full generation of descriptions in π-ADL, their animation by stepwise “execution”, as software architecture descriptions in π-ADL. Indeed, it provides a well as their verification, refinement, and code generation. The novel specialisation of UML 2.0 for formally modelling software following screenshot (see Figure 24) shows its use for visual modelling a software architecture. architectures based on the typed π-calculus semantics. Its interpretation of the UML 2.0 constructs in the framework of π-ADL provides the formal π-calculus semantics for these constructs in order to support formal modelling and verification of software architecture descriptions. Furthermore, the UML 2.0 Profile for π-ADL provides a UML-compatible visual notation for software architecture modelling in a Model Driven Architecture (MDA) framework [6]. This assists in the mapping between visual architecture diagrams and formal descriptions, which can be analysed and refined, by providing the ability to elaborate visually and formally architecture models. Using a similar approach other UML Profiles have been defined. For instance, the SAE Architecture Analysis & Design Language (AADL [30]) standard includes UML 1.4 and UML 2.0 Profiles that add the real-time and embedded systems semantics of AADL to UML [10]. It is expected that multiple profiles for different domains will be defined as specializations of UML 2.0 in the future.
Figure 24. Objecteering UML Modeller extended with the UML 2.0 Profile for π-ADL All tools supporting π-ADL, including the UML Modeller, are integrated using an XML-based interchange language [35] and web services.
ACM SIGSOFT Software Engineering Notes
Page 12
π-ADL and its UML 2.0 Profile have been applied in several realistic case studies and industrial business cases at Thésame (France) and Engineering Ingegneria Informatica (Italy) in the framework of the ArchWare European Project. In the pilot project at Thésame, an agile integrated industrial process system was architected and generated. In the pilot project at Engineering Ingegneria Informatica, a federated knowledge management system was architected and generated. π-ADL has also been used by the CERN (Switzerland) for architecting human computer interfaces for monitoring particle accelerator restart. In addition to these industrial applications carried out in the ArchWare European Project and at the CERN, π-ADL, and its associated languages and tools, including its UML 2.0 Profile, have been applied in the following application domains: • component-based software systems for sensor-actuator networks, • mobile agent software systems, • service-oriented architectures for grid computing systems, • service-oriented architectures for enterprise application integration. All these domains are characterised by the need of architecture description, analysis and refinement languages powerful enough, in terms of expressiveness, to model dynamic architectures, including support for modelling the structure, behaviour and qualities of open and mobile systems. The different applications of π-ADL, and its associated languages and tools are broad and general enough to demonstrate their adequacy and relevance for addressing innovative industrial problems. Furthermore, the π-ArchWare software environment itself is a validation of π-ADL and associated languages and tools since it has been completely specified and developed using π-ADL itself. Ongoing work is mainly related with the formal development of an architecture-centric formal method. This formal method, called the π-Method, like formal methods such as B [1], FOCUS [34], VDM [11], and Z [9], aims to provide full support for formal description and development. Unlike these formal methods that do not provide any architectural support, the π-Method has been built from scratch to support architecture-centric formal software engineering. References [1] Abrial J.-R.: The B-Book: Assigning Programs to Meanings. Cambridge University Press, 1996. [2] Alloui I., Garavel H., Mateescu R., Oquendo F.: The ArchWare Architecture Analysis Language: Syntax & Semantics. Deliverable D3.1b, ArchWare European RTD Project, IST-2001-32360, January 2003. [3] Alloui I., Oquendo F.: Graphical Notation for ArchWare ADL by Extension of UML 1.5. Deliverable D1.4, ArchWare European RTD Project, IST-2001-32360, June 2003. [4] Alloui I., Oquendo F.: Describing Software-intensive Process Architectures using a UML-based ADL. Proceedings of the 6th International Conference on Enterprise Information Systems (ICEIS’04), Porto, Portugal, April 2004. [5] Bolusset T., Oquendo F.: Formal Refinement of Software Architectures Based on Rewriting Logic. Proceedings of the ZB2002 International Workshop on Refinement of Critical Systems: Methods, Tools and Experience, Grenoble, Janvier 2002.
January 2006
Volume 31
Number 1
[6] Brown A.W.: An Introduction to Model Driven Architecture – Part I: MDA and Today’s Systems. The Rational Edge, February 2004. [7] Chaudet C., Greenwood M., Oquendo F., Warboys B.: Architecture-Driven Software Engineering: Specifying, Generating, and Evolving Component-Based Software Systems. IEE Journal: Software Engineering, Vol. 147, No. 6, UK, December 2000. [8] Cimpan S., Leymonerie F., Oquendo F.: The ArchWare Foundation Styles Library. Report R1.3-1, ArchWare European RTD Project, IST-2001-32360, June 2003. [9] Davies J., Woodcock J.: Using Z: Specification, Refinement and Proof. Prentice Hall, 1996. [10] Feiler P., Lewis B., Vestal S.: The SAE Architecture Analysis & Design Language (AADL) Standard: A Basis for Model-Based Architecture-Driven Embedded Systems Engineering. Proceedings of the RTAS 2003 Workshop on Model-Driven Embedded Systems, May 2003. [11] Fitzgerald J., Larsen P.: Modelling Systems: Practical Tools and Techniques for Software Development. Cambridge University Press, 1998. [12] Gallo F. (Ed.): Annual Report: Project Achievements in 2002. Appendix B: Survey of State-of-the-Art and Typical Usage Scenario for ArchWare ADL and AAL. Deliverable D0.4.1, ArchWare European RTD Project, IST-2001-32360, February 2003. [13] Garavel H., Lang F., Mateescu R.: An Overview of CADP 2001. European Association for Software Science and Technology (EASST) Newsletter, Vol. 4, August 2002. [14] Greenwood M., Balasubramaniam D., Cimpan S., Kirby N.C., Mickan K., Morrison R., Oquendo F., Robertson I., Seet W., Snowdon R., Warboys B., Zirintsis E.:Process Support for Evolving Active Architectures. Proceedings of the 9th European Workshop on Software Process Technology, LNCS 2786, Springer Verlag, Helsinki, September 2003. [15] IEEE Std 1471-2000: IEEE Recommended Practice for Architectural Description of Software-Intensive Systems. IEEE Press, October 2000. [16] Kozen D.: Results on the Propositional µ-Calculus. Theoretical Computer Science 27:333-354, 1983. [17] Leymonerie F., Cimpan S., Oquendo F. : État de l'art sur les styles architecturaux : classification et comparaison des langages de description d'architectures logicielles. Revue Génie Logiciel, No. 62, September 2002 (In French). [18] Martí-Oliet N., Meseguer J.: Rewriting Logic: Roadmap and Bibliography. Theoretical Computer Science, 2001. [19] Mateescu R., Garavel H.: XTL: A Meta-Language and Tool for Temporal Logic Model-Checking. Proceedings of the 1st International Workshop on Software Tools for Technology Transfer, Aalborg, Denmark, July 1998. [20] Medvidovic N., Rosenblum D., Redmiles D., Robbins J.: Modeling Software Architectures in the Unified Modeling Language. ACM Transactions on Software Engineering and Methodology, vol. 11, no. 1, January 2002. [21] Medvidovic N., Taylor R.: A Classification and Comparison Framework for Architecture Description Languages. Technical Report UCI-ICS-97-02, University of California. Irvine, February 1997. [22] Milner R.: Communicating and Mobile Systems: The -Calculus. Cambridge University Press, 1999. [23] Morrison R., Graham K., Balasubramaniam D., Mickan K., Oquendo F., Cimpan S., Warboys B., Snowdon B., Greenwood M.: Support for Evolving Software Architectures in the ArchWare ADL. Proceedings of the 4th Working IEEE/IFIP International Conference on Software Architecture (WICSA’04), Oslo, Norway, June 2004. [24] Oquendo F.: The ArchWare Architecture Description Language: Tutorial. Report R1.1-1, ArchWare European RTD Project, IST-2001-32360, March 2003.
ACM SIGSOFT Software Engineering Notes
Page 13
[25] Oquendo F.: The ArchWare Architecture Refinement Language. Deliverable D6.1b, ArchWare European RTD Project, IST-2001-32360, December 2003. [26] Oquendo F.: π-ADL: An Architecture Description Language based on the Higher Order Typed π-Calculus for Specifying Dynamic and Mobile Software Architectures. ACM Software Engineering Notes, Vol. 28, No. 8, USA, May 2004. [27] Oquendo F.: The ArchWare Architecture Description Language: UML 2.0 Profile for Architecting with ArchWare ADL. Deliverable D1.8, ArchWare European RTD Project, IST-2001-32360, June 2005. [28] Oquendo F., Alloui I., Cimpan S., Verjus H.: The ArchWare Architecture Description Language: Abstract Syntax and Formal Semantics. Deliverable D1.1b, ArchWare European RTD Project, IST-2001-32360, December 2002. [29] Oquendo F., Warboys B., Morrison R., Dindeleux R., Gallo F., Garavel H., Occhipinti C.: ArchWare: Architecting Evolvable
[30] [31] [32] [33] [34] [35]
January 2006
Volume 31
Number 1
Software. Proceedings of the 1st European Workshop on Software Architecture, LNCS 3047, Springer Verlag, May 2004. SAE Standard AS5506: Architecture Analysis & Design Language (AADL). Embedded Computing Systems Committee, SAE, November 2004. Sangiorgi D.: Expressing Mobility in Process Algebras: First-Order and Higher-Order Paradigms. PhD Thesis, University of Edinburgh, 1992. Sangiorgi D., Walker D.: The π-Calculus: A Theory of Mobile Processes, Cambridge Universtity Press, 2001. Stirling C.: Modal and Temporal Properties of Processes. Springer Verlag, 2001. Stolen K., Broy M.: Specification and Development of Interactive Systems. Springer Verlag, 2001. Verjus H., Oquendo F.: The ArchWare Architecture Interchange Language: XML Syntax. Deliverable D1.3b, ArchWare European RTD Project, IST-2001-32360, June 2003.
