UML 2.0 Profile for ArchWare ADL: Coping with UML 2.0

Transcription

1 ArchWare Architecting Evolvable Software European RTD Project IST UML 2.0 Profile for ArchWare ADL: Coping with UML 2.0 (Project Deliverable D1.8) Author: Editor: Flavio Oquendo InterUnec Flavio Oquendo InterUnec Document ID: D1.8 Date: 30 June 2005 Version: 1.0 Status: Issued Reviewed by: Distribution: Abstract: Public This deliverable specifies a UML 2.0 Profile for ArchWare ADL that upgrades the UML 1.5 Profile for ArchWare ADL (Deliverable D1.4b). This new profile uses new UML 2.0 modelling constructs, not provided in UML 1.5, for supporting the description of software architectures. Copyright by the ArchWare Consortium CPR Consorzio Pisa Ricerche Italy InterUnec Université de Savoie France Victoria University of Manchester UK ENGINEERING Ingegneria Informatica S.p.A. Italy INRIA Institut National de Recherche en Informatique et Automatique France THESAME Mecatronique et Management France University Court of the University of St. Andrews UK All Rights Reserved

2 Acknowledgments The author would like to acknowledge the participants of the ArchWare Project for their feedbacks on the use of the UML 1.5 Profile for ArchWare ADL. These feedbacks were very useful on specifying the new UML 2.0 Profile for ArchWare ADL. Caveat This deliverable is subject to evolutions based on feedbacks from its usage within the project. Only the most recent release of this report should be used. New releases will be advertised to project participants and be made available on the project cooperative work support web site. Disclaim The authors have utilized his professional expertise in preparing this deliverable. However, neither the ArchWare Consortium nor the authors make any representation or warranties with respect to the contents of this report. Rather, it is provided on an AS IS basis, without warranty, express or implied, INCLUDING A FULL DISCLAIMER OF THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. ISSUE 1.0

3 TABLE OF CONTENTS 1. Introduction Document Purpose Document Structure Architectural Modelling with ArchWare ADL ArchWare ADL: The Language ArchWare ADL: The UML 1.5 Profile Architectural Modelling with UML Overview of UML What is new in UML 2.0? Which UML 2.0 Constructs are Relevant? Architecture-related Modelling Constructs Defining Profiles in UML Specification of the UML 2.0 Profile for ADL Case Study Conclusion...63 References...67 ISSUE 1.0 III

4 HISTORY AND EVOLUTIONS Changes Log Document Version Ch. Request Origin Changes and Reasons for Change Authors 1.0 Review 3: J. Jourdan s Review Report & Consolidated Review Report Coping with UML 2.0: In order to make ArchWare results dissemination as wide as possible, I (Jean Jourdan) would suggest implementing most of ArchWare concepts on top of UML modeller ensuring compliance to UML 2.0 as much as possible. Open Issues/To Do Items Issue Number Date Logged Description of Open Issue/ To Do Item Priority Status Origin ISSUE 1.0 IV

5 1. INTRODUCTION Is UML 2.0 suitable for modelling software architectures? The answer is as is, no, it is not. The modelling capabilities provided by UML as is do not fully satisfy the structural and behavioural needs of architectural description for two key reasons. First, UML 2.0 does not provide specialized constructs for modelling architectures, in particular for modelling software architectures from a runtime perspective. For example, although there are different architectural elements with different responsibilities, connectors and components must be modelled in UML using the same mechanism. Second, the rules of a given architectural style are directly reflected in its corresponding ADL and maintained by the accompanying toolset, whereas those rules must be applied mentally by the software architect who chooses to use UML. Emulating particular structural constraints in UML is an error-prone approach. Furthermore, additional documentation must accompany such a UML model to ensure that no future modifications violate the desired constraints. In addition to structural aspects of an architecture, a number of ADLs (e.g., Rapide, Wright, π-space) including ArchWare ADL also provides constructs for modelling the dynamic component behaviour and interactions in the architecture. UML s features, such as state machines can be used effectively to this end. As with the structural constructs, however, it may be difficult to ensure that the intended behaviours or interactions, as they would be specified in an ADL (e.g., in Wright s CSP or ArchWare s π-calculus), are correctly modelled in UML. However, does UML 2.0 provide a suitable base for defining profiles for modelling software architectures? The answer is, yes, it provides a better basis than UML Document Purpose This deliverable specifies a UML Profile for ArchWare ADL that copes with UML 2.0 using new UML 2.0 modelling facilities. 1.2 Document Structure This document is organised as follows: chapter 2 gives a brief overview of the design principles that guided the design of ArchWare ADL and recalls the UML 1.5 Profile for ArchWare ADL, chapter 3 presents the modelling constructs of UML 2.0 that provides the basis for architectural modelling; chapter 4 presents the constructs for defining profiles in UML 2.0; chapter 5 defines the UML 2.0 Profile for ArchWare ADL based on constructs described in chapter 3 using the constructs described in chapter 4 having as baseline the profile recalled in chapter 2; chapter 6 illustrates through a case study how the UML 2.0 Profile for ArchWare ADL can be used for modelling software architectures; chapter 7 concludes the deliverable with implementation aspects. ISSUE 1.0 5

6 2. ARCHITECTURAL MODELLING WITH ARCHWARE ADL This chapter gives a brief overview of the design principles that guided the design of ArchWare ADL and recalls the UML 1.5 Profile for ArchWare ADL. 2.1 ArchWare ADL: The Language ArchWare ADL provides the core structure and behaviour constructs for describing dynamic software architectures. It is a formal specification language designed to be executable and to support automated verification. The following general principles guided the design of ArchWare ADL: formality: ArchWare ADL is a formal language: it provides a formal system, at the mathematical sense, for describing dynamic architectures and reasoning about them; runtime perspective: ArchWare ADL focuses on the formal description of architectures from the runtime viewpoint: the (run-time) structure, the (runtime) behaviour, and how these may evolve over time; executability: ArchWare ADL is an executable language (a virtual machine runs specifications of software architectures). Based on these general principles, the design of ArchWare ADL followed the following language design principles: the principle of correspondence: the use of names are consistent within ArchWare ADL, in particular there is a one to one correspondence between the method of introducing names in declarations and parameter lists; the principle of abstraction: all major syntactic categories have abstractions defined over them (in ArchWare ADL, it includes abstractions over behaviours and abstractions over data), the principle of type completeness: all types are first-class without any restriction on their use. In first-class citizenship, in addition to rights derived from type completeness (i.e. where a type may be used in a constructor, any type is legal without exception), there are properties possessed by all values of all types that constitute their civil rights in the language. In ArchWare ADL they are: the right to be declared, the right to be assigned, the right to have equality defined over them, the right to persist. ArchWare ADL provides a novel ADL that is general-purpose and Turing-complete. It has been used in the ArchWare Project since its draft definition in deliverables D1.1a and D1.2a mid Version 1.0 was issued on December 2002 in deliverables D1.1b (semantics) and D1.2b (syntax). ISSUE 1.0 6

7 2.2 ArchWare ADL: The UML 1.5 Profile Deliverable D1.4b specifies the UML 1.5 Profile for ArchWare ADL. It includes stereotypes for the basic Abstraction-Connection ArchWare ADL layer and for the Component-Connector one. The former includes as architectural elements, abstractions and connections, while the latter includes as architectural elements, composites, components, connectors and ports. The Basic Abstraction-Connection Profile In the basic profile the only architectural elements are abstractions and connections, modeled as stereotyped classifiers. Stereotype <<abstraction>> Stereotyped Notation <<connection>> The Foundation Component-Connector Profile In the foundation component-connector profile the architectural elements are composites, components, connectors, ports, and connections, modeled as stereotyped classifiers. Composites are composite abstractions. Abstractions are stereotyped as components or connectors. Ports get together connections. Stereotype <<composite>> Stereotyped Notation <<component>> <<connector>> <<port>> ISSUE 1.0 7

8 3. ARCHITECTURAL MODELLING WITH UML 2.0 This chapter presents the modelling constructs of UML 2.0 that provides the basis for architectural modelling. 3.1 Overview of UML 2.0 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. UML 2.0 defines 13 basic diagram types, divided into two general sets: Structural Modelling Diagrams and Behavioural Modelling Diagrams. Structural Modelling Diagrams Structure Diagrams define the static organization of a model. They are used to model the 'things' that make up a model the classes, objects, interfaces and components. In addition they are used to model the relationships and dependencies between elements. Package Diagrams are used to divide the model into logical containers or 'packages' and describe the interactions between them at a high level. Class Diagrams define the basic building blocks of a model: the types, classes and general materials that are used to construct a full model. Object Diagrams show how instances of structural elements are related and used at run-time. Composite Structure Diagrams provide a means of layering an element's structure and focusing on inner detail, construction and relationships. Component Diagrams are used to model higher level or more complex structures, usually built up from one or more classes, and providing a well defined interface. ISSUE 1.0 8

9 Deployment Diagrams show the physical disposition of significant artefacts within a real-world setting. Behavioural Modelling Diagrams Behaviour Diagrams capture the varieties of interaction and instantaneous state within a model as it 'executes' over time. Use Case Diagrams are used to model user/system interactions. They define behaviour, requirements and constraints in the form of scripts or scenarios. Activity Diagrams have a wide number of uses, from defining basic program flow, to capturing the decision points and actions within any generalized process. State Machine Diagrams are essential to understanding the instant to instant condition or "run state" of a model when it executes. Communication Diagrams show the network and sequence of messages or communications between objects at run-time during a collaboration instance. Sequence Diagrams are closely related to Communication Diagrams and show the sequence of messages passed between objects using a vertical timeline. Timing Diagrams fuse Sequence and State Diagrams to provide a view of an object's state over time and messages which modify that state. Interaction Overview Diagrams fuse Activity and Sequence Diagrams to provide allow interaction fragments to be easily combined with decision points and flows. Structurally, these diagrams are expressed in terms of classifier constructs. ISSUE 1.0 9

10 3.2 What is new in UML 2.0? 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 abstractions than classes. The component notation has also improved accordingly, as one can see in the following figure, which shows both a UML 1.5 Component Diagram and a UML 2.0 Component Diagram. The most noticeable difference is the component notation itself: Components are now simple boxes with a component stereotype, either the bandaged box visual stereotype or the <<component>> textual stereotype. The second notation difference concerns interfaces. A socket notation has been added to indicate a required interface: In the figure below, the Student component requires the Access Control interface, which is provided by the Security component. The combination of the required interface notation and the traditional lollipop notation is often referred to as ball-and-socket notation. Hereafter enhanced or new UML 2.0 modelling constructs related to component and composite modelling are presented. Component Diagram Component Diagrams illustrate the pieces of software, embedded controllers, etc. that will make up a system. A Component diagram has a higher level of abstraction than a Class diagram usually a component is implemented by one or more classes (or objects) at runtime. They are building blocks, such that eventually a component can encompass a large portion of a system. The diagram below demonstrates some components and their inter-relationships. Assembly connectors 'link' the provided interfaces supplied by Product and Customer to the required interfaces specified by Order. A dependency relationship maps a customer's associated account details to the required interface, 'Payment', indicated by Order. ISSUE

11 Components are similar in practice to package diagrams as they define boundaries and are used to group elements into logical structures. The difference between Package Diagrams and Component diagrams is that Component Diagrams offer a more semantically rich grouping mechanism. With Component Diagrams all of the model elements are private whereas Package diagrams only display public items. Subsystems are stereotyped components. Component Components are represented as a rectangular classifier with the keyword «component», optionally the component may be displayed as a rectangle with a component icon in the right-hand upper corner. Port Using Ports with Component Diagrams allows for a service or behaviour to be specified to its environment as well as a service or behaviour that a Component requires. Ports may specify inputs, outputs as well as operating bi-directionally. The following diagram details a component with a port for Online services along with two provided interfaces Order Entry and Tracking as well as a required interface Payment. ISSUE

12 Assembly The Assembly connector bridges a component s required interface (Component1) with the provided interface of another component (Component2); this allows one component to provide the services that another component requires. Interfaces are collections of one or more methods which may or may not contain attributes. Composite Structure A Composite Structure shows the internal structure of a classifier, including its interaction points to other parts of the system. It shows the configuration and relationship of parts that together perform the behaviour of the containing classifier. Thereby, classes can be displayed as composite elements exposing interfaces and containing ports and parts. Part A part is an element that represents a set of one or more instances which are owned by a containing classifier instance. So for example, if a diagram instance owned a set of graphical elements, then the graphical elements could be represented as parts, if it were useful to do so to model some kind of relationship between them. Note that a part can be removed from its parent before the parent is deleted, so that the part is not deleted at the same time. A part is shown as an unadorned rectangle contained within the body of a class or component element. ISSUE

13 Port A port is a typed element that represents an externally visible part of a containing classifier instance. Ports define the interaction between a classifier and its environment. A port can appear on the boundary of a contained part, a class or a composite structure. A port may specify the services a classifier provides as well as the services that it requires of its environment. A port is shown as a named rectangle on the boundary edge of its owning classifier. Interface An interface is similar to a class but with a number of restrictions. All interface operations are public and abstract, and do not provide any default implementation. All interface attributes must be constants. However, while a class may only inherit from a single super-class, it may implement multiple interfaces. An interface, when standing alone in a diagram, is either shown as a class element rectangle with the «interface» keyword and with its name italicised to denote it is abstract, or it is shown as a circle. Note that the circle notation does not show the interface operations. When interfaces are shown as being owned by classes, they are referred to as exposed interfaces. An exposed interface can be defined as either provided or required. A provided interface is an affirmation that the containing classifier supplies the operations defined by the named interface element and is defined by drawing a realisation link between the class and the interface. A required interface is a statement that the classifier is able to communicate ISSUE

14 with some other classifier which provides operations defined by the named interface element and is defined by drawing a dependency link between the class and the interface. A provided interface is shown as a "ball on a stick" attached to the edge of a classifier element. A required interface is shown as a "cup on a stick" attached to the edge of a classifier element. Delegation A delegate connector is used for defining the internal workings of a component's external ports and interfaces. A delegate connector is shown as an arrow with a «delegate» stereotype. It connects an external contract of a component as shown by its ports to the internal realisation of the behaviour of the component's part. 3.3 Which UML 2.0 Constructs are Relevant? Which UML 2.0 constructs are relevant to architecture description in ArchWare? The ones related to the key concepts of component and structure of components. The component construct as defined in UML 2.0 is general enough to cope with the modelling of architectural components. Thereby, this is a key point with respect to UML 2.0, as it was with UML 1.5: UML has a fuzzy semantics, i.e. the semantics is not precisely defined and thus allows different interpretations or variations. In order to model software architectures in ArchWare ADL, the following UML 2.0 constructs are relevant: Component, Component Instance, ISSUE

15 Port, Connector (Assembly, Delegation), Composite Element, Composite Structure. 3.4 Architecture-related Modelling Constructs Hereafter the UML 2.0 constructs relevant to modelling software architectures will be presented. For each one, we provide a short introduction, its visual notation (only one possible notation will be presented the one that will be used in ArchWare), the related meta-classes in the UML 2.0 metamodel, its semantics, and the changes from previous UML standards. In addition, stereotypes that will be part of the UML 2.0 Profile for ArchWare ADL are introduced. Component A component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. A component defines its behaviour in terms of provided and required interfaces. As such, a component serves as a type, whose conformance is defined by these provided and required interfaces (encompassing both their static as well as dynamic semantics). One component may therefore be substituted by another only if the two are type conformant. Larger pieces of a system's functionality may be assembled by reusing components as parts in an encompassing component or assembly of components, and wiring together their required and provided interfaces. A component is modelled throughout the development life cycle and successively refined into deployment and run-time. A component may be manifest by one or more artefacts, and in turn, that artefact may be deployed to its execution environment. Notation Component can be notated as follows. Component Metamodel In the UML 2.0 meta-model, the Components package specifies a set of constructs that can be used to define software systems of arbitrary size and complexity. In particular, the package specifies a component as a modular unit with well-defined interfaces that is replaceable within its environment. The component concept addresses the area of component-based development and component-based system structuring, where a component is modelled throughout the development life cycle and successively refined into deployment and run-time. Component is defined from packages BasicComponents and PackagingComponents. ISSUE

16 BasicComponents A component is a subtype of Class which provides for a Component having attributes and operations, and being able to participate in Associations and Generalizations. A Component may form the abstraction for a set of realizingclassifiers that realize its behaviour. In addition, because a Class itself is a subtype of an EncapsulatedClassifier, a Component may optionally have an internal structure and own a set of Ports that formalize its interaction points. A component has a number of provided and required Interfaces, that form the basis for wiring components together, either using Dependencies, or by using Connectors. A provided Interface is one that is either implemented directly by the component or one of its realizingclassifiers, or it is the type of a provided Port of the Component. A required interface is designated by a Usage Dependency from the Component or one of its realizingclassifiers, or it is the type of a required Port. PackagingComponents A component is extended to define the grouping aspects of packaging components. This defines the Namespace aspects of a Component through its inherited ownedmember and elementimport associations. In the namespace of a component, all model elements that are involved in or related to its definition are either owned or imported explicitly. This may include e.g. Use Cases and Dependencies (e.g. mappings), Packages, Components, and Artefacts. Metaclasses The metaclasses that define the basic Component construct are depicted below. ISSUE

17 Semantics A component is a self contained unit that encapsulates the state and behaviour of a number of classifiers. A component specifies a formal contract of the services that it provides to its clients and those that it requires from other components or services in the system in terms of its provided and required interfaces. A component is a substitutable unit that can be replaced at design time or run-time by a component that offers equivalent functionality based on compatibility of its interfaces. As long as the environment obeys the constraints expressed by the provided and required interfaces of a component, it will be able to interact with this environment. Similarly, a system can be extended by adding new component types that add new functionality. The required and provided interfaces of a component allow for the specification of structural features such as attributes and association ends, as well as behavioural features such as operations and events. A component may implement a provided interface directly, or, its realizing classifiers may do so. The required and provided interfaces may optionally be organized through ports, these enable the definition of named sets of provided and required interfaces that are typically (but not always) addressed at run-time. A component has an external view (or black-box view) by means of its publicly visible properties and operations. Optionally, a behaviour such as a protocol state machine may be attached to an interface, port and to the component itself, to define the external view more precisely by making dynamic constraints in the sequence of operation calls explicit. Other behaviours may also be associated with interfaces or connectors to define the contract between participants in a collaboration e.g. in terms of use case, activity or interaction specifications. The wiring between components in a system or other context can be structurally defined by using dependencies between component interfaces (typically on structure diagrams). Optionally, a more detailed specification of the structural collaboration can be made using parts and connectors in of composite structures, to specify the role or instance level collaboration between components. A component also has an internal view (or white-box view) by means of its private properties and realizing classifiers. This view shows how the external behaviour is realized internally. The mapping between external and internal view is by means of dependencies (on structure diagrams), or delegation connectors to internal parts (on composite structure diagrams). Again, more detailed behaviour specifications such as for ISSUE

18 example interactions and activities may be used to detail the mapping from external to internal behaviour. A number of UML standard stereotypes exist that apply to component, e.g. «subsystem» to model large-scale components, and «specification» and «realization» to model components with distinct specification and realization definitions, where one specification may have multiple realizations. Changes from previous UML The following changes from UML 1.5 have been made. The component model has made a number of implicit concepts from the UML 1.5 model explicit, and made the concept more applicable throughout the modelling life cycle (rather than the implementation focus of UML 1.5). In particular, the resides relationship from 1.5 relied on namespace aspects to define both namespace aspects as well as residence aspects. These two aspects have been separately modelled in the UML metamodel in 2.0. The basic residence relationship in 1.5 maps to the realizingclassifiers relationship in 2.0. The namespace aspects are defined through the basic namespace aspects of Classifiers in UML 2.0, and extended in the PackagingComponents metamodel for optional namespace relationships to elements other than classifiers. In addition, the Component construct gains the capabilities from the general improvements in CompositeStructures (around Parts, Ports and Connectors). In UML 2.0, a Component is notated by a classifier symbol that no longer has two protruding rectangles. These were cumbersome to draw and did not scale well in all circumstances. Also, they interfered with any interface symbols on the edge of the Component. Instead, a «component» keyword notation is used in UML 2.0. Optionally, a component icon that is similar to the UML 1.5 icon can still be used in the upper righthand corner of the component symbol. For backward compatibility reasons, the UML 1.5 notation with protruding rectangles can still be used. Stereotypes of UML 2.0 Profile for ArchWare ADL In the UML 2.0 Profile for ArchWare ADL, the UML 2.0 Component is stereotyped as an architectural component that could be an ArchWare Component or an ArchWare Connector. From the core viewpoint, the UML 2.0 Component is stereotyped as an ArchWare Abstraction, that in turn is stereotyped as an ArchWare Component and an ArchWare Connector. An ArchWare Abstraction has ports and an internal behaviour described by a State Machine if it is a primitive abstraction or described by an internal structure if it is a composite abstraction. Composite Component The term Composite Component refers to a component that is composed of interconnected elements, representing run-time instances. Notation Composite Components can be notated as follows. Component ISSUE

19 Metamodel The InternalStructure subpackage provides mechanisms for specifying structures of interconnected elements that are created within an instance of a containing classifier. A structure of this type represents a decomposition of that classifier and is referred to as its internal structure. The StructuredClasses subpackage supports the representation of classes that may have ports as well as internal structure. The Actions subpackage adds actions that are specific to the features introduced by composite structures, e.g., the sending of messages via ports. Composite Component is defined in package PackagingComponents Semantics A Composite Component means a Component that has an internal structure. Changes from previous UML Composite Component was not defined in UML 1.5. The constructs related to Composite Component are new in UML 2.0. Stereotypes of UML 2.0 Profile for ArchWare ADL In the UML 2.0 Profile for ArchWare ADL, from the core viewpoint, the UML 2.0 Composite Component is stereotyped as an ArchWare Composite Abstraction, that in turn is stereotyped as an ArchWare Composite Component and an ArchWare Composite Connector. Component Instance As Component is a Classifier, it can be instantiated. Component instances are used as parts in the description of the internal structure of an encompassing component. A Component Instance represents an instance of an architectural component in a runtime environment (i.e. it represents an architectural component from a runtime viewpoint). Notation Component Instance can be notated as follows. :Component Metamodel As Component is a Classifier, it can be instantiated. Component instances are used as parts in the description of the internal structure of an encompassing component. A Component Instance represents an instance of an architectural component in a runtime environment (i.e. it represents an architectural component from a runtime viewpoint). UML metaclasses can be arranged into 4 levels with metasemantic relationships among the metaclasses in the different levels that transcend different semantic categories (e.g., classifiers, events, behaviours). These include the Type level (it represents types of entities in models, such as classes, states, activities, events, etc.) and Instance level (these are the things that models represent at runtime). These classes do not appear at all in the UML 2.0 metamodel, but they underlie the meaning of UML models. ISSUE

20 Semantics In the UML Metamodel, a model contains three major categories of elements: classifiers, events, and behaviours. Each major category models individuals in an incarnation of the system being modelled. A classifier describes a set of objects; an object is an individual thing with a state and relationships to other objects. An event describes a set of possible occurrences; an occurrence is something that happens that has some consequence within the system. A behaviour describes a set of possible executions; an execution is the performance of an algorithm according to a set of rules. A Component Instance is a self contained unit that encapsulates the state and behaviour of a classifier and that reacts to occurrences of events via its ports. Changes from previous UML The notion and notation of instance did not change between UML 1.5 and UML 2.0. Stereotypes of UML 2.0 Profile for ArchWare ADL In the UML 2.0 Profile for ArchWare ADL, the UML 2.0 Component Instance is stereotyped as an instance of an architectural component that could be an ArchWare Component or an ArchWare Connector, composite or not. A Component Instance has ports and an internal behaviour described by a State Machine if it is a primitive component or has an internal structure, itself composed of instances, if it is a composite component. Port A port is a property of a classifier that specifies a distinct interaction point between that classifier and its environment or between the (behaviour of the) classifier and its internal parts. Ports are connected to properties of the classifier by connectors through which requests can be made to invoke the behavioural features of a classifier. A Port may specify the services a classifier provides (offers) to its environment as well as the services that a classifier expects (requires) of its environment. Ports represent interaction points between a classifier and its environment. The interfaces associated with a port specify the nature of the interactions that may occur over a port. The required interfaces of a port characterize the requests which may be made from the classifier to its environment through this port. The provided interfaces of a port characterize requests to the classifier that its environment may make through this port. A port has the ability to specify that any requests arriving at this port are handled by the behaviour of the instance of the owning classifier, rather than being forwarded to any contained instances, if any. The Port metaclass has the following attributes and associations. Attributes isservice: Boolean If true indicates that this port is used to provide the published functionality of a classifier; if false, this port is used to implement the classifier but is not part of the essential externally visible functionality of the classifier and can, therefore, be altered or deleted along with the internal implementation of the classifier and other properties that are considered part of its implementation. The default value for this attribute is true. isbehavior: Boolean Specifies whether requests arriving at this port are sent to the classifier behaviour of this classifier. Such ports are referred to as behaviour port. Any invocation of a behavioural feature targeted at a behaviour port will be handled ISSUE

21 by the instance of the owning classifier itself, rather than by any instances that this classifier may contain. The default value is false. Associations required: Interface References the interfaces specifying the set of operations and receptions which the classifier expects its environment to handle. This association is derived as the set of interfaces required by the type of the port or its supertypes. provided: Interface References the interfaces specifying the set of operations and receptions which the classifier offers to its environment, and which it will handle either directly or by forwarding it to a part of its internal structure. This association is derived from the interfaces realized by the type of the port or by the type of the port, if the port was typed by an interface. Notation Port can be notated as follows. Port Port Provided Interface Required Interface If the port symbol is placed overlapping the boundary of the rectangle symbol denoting that classifier this port is exposed (i.e., its visibility is public). If the port is shown inside the rectangle symbol, then the port is hidden and its visibility is as specified (it is protected by default). The type of a port may be shown following the port name, separated by colon ( : ). A provided interface may be shown using the lollipop notation attached to the port. A required interface may be shown by the socket notation attached to the port. The following figure shows the notation for ports: p is a port on the Engine class. The provided interface (also its type) of port p is powertrain. The multiplicity of p is 1. In addition, a required interface, power, is shown also. The figure on the left shows the provided interface using the lollipop notation, while the figure on the right shows the interface as the type of the port. A behaviour port is indicated as follows. The following figure shows the behaviour port p, as indicated by its connection to the state symbol representing the behaviour of the Engine class. Its provided interface is powertrain. In addition, a required interface, power, is shown also. ISSUE

22 The following figure shows a class Engine with a port p with a provided interface powertrain. This interface specifies the services that the engine offers at this port (i.e., the operations and receptions that are accessible by communication arriving at this port). The interface power is the required interface of the engine. The required interface specifies the services that the engine expects its environment to provide. At port p, the Engine class is completely encapsulated; it can be specified without any knowledge of the environment the engine will be embedded in. As long as the environment obeys the constraints expressed by the provided and required interfaces of the engine, the engine will function properly. Two uses of the Engine class are depicted: both a boat and a car contain a part that is an engine. The Car class connects port p of the engine to a set of wheels via the axle. The Boat class connects port p of the engine to a propeller via the shaft. As long as the interaction between the Engine and the part linked to its port p obeys the constraints specified by the provided and required interfaces, the engine will function as specified, whether it is an engine of a car or an engine of a boat. Metamodel The Ports subpackage provides mechanisms for isolating a classifier from its environment. This is achieved by providing a point for conducting interactions between the internals of the classifier and its environment. This interaction point is referred to as a port. Multiple ports can be defined for a classifier, enabling different interactions to be distinguished based on the port through which they occur. By decoupling the internals of the classifier from its environment, ports allow a classifier to be defined independently of its environment, making that classifier reusable in any environment that conforms to the interaction constraints imposed by its ports. The port metaclass is defined as follows. ISSUE

23 Actions specific to composite structures are InvocationAction and Trigger. Semantics A port represents an interaction point between a classifier instance and its environment or between a classifier instance and instances it may contain. A port by default has public visibility. However, a behaviour port may be hidden but does not have to be. The required interfaces characterize services that the owning classifier expects from its environment and that it may access through this interaction point: Instances of this classifier expects that the features owned by its required interfaces will be offered by one or more instances in its environment. The provided interfaces characterize the behavioural features that the owning classifier offers to its environment at this interaction point: the owning classifier must offer the features owned by the provided interfaces. The provided and required interfaces completely characterize any interaction that may occur between a classifier and its environment at a port with respect to the data communicated at this port and the behaviours that may be invoked through this port. The interfaces do not necessarily establish the exact sequences of interactions across the port. When an instance of a classifier is created, instances corresponding to each of its ports are created and held in the slots specified by the ports, in accordance with its multiplicity. These instances are referred to as interaction points and provide unique references. A link from that instance to the instance of the owning classifier is created through which communication is forwarded to the instance of the owning classifier or through which the owning classifier communicates with its environment. It is, therefore, possible for an instance to differentiate between requests for the invocation of a behavioural feature targeted at its different ports. Similarly, it is possible to direct such requests at a port, and the requests will be routed as specified by the links corresponding to connectors attached to this port. Strictly speaking requests arriving at a port means request occurrences arriving at the interaction point of this instance corresponding to this port. The interaction point object must be an instance of a classifier that realizes the provided interfaces of the port. If the port was typed by an interface, the classifier typing the interaction point object realizes that interface. If the port was typed by a class, the interaction point object will be an instance of that class. The latter case allows elaborate specification of the communication over a port. For example, it may describe that communication is filtered, modified in some way, or routed to other parts depending on its contents as specified by the classifier that types the port. ISSUE

24 If connectors are attached to both the port when used on a property within the internal structure of a classifier and the port on the container of an internal structure, the instance of the owning classifier will forward any requests arriving at this port along the link specified by those connectors. If there is a connector attached to only one side of a port, any requests arriving at this port will terminate at this port. For a behaviour port, the instance of the owning classifier will handle requests arriving at this port (as specified in the behaviour of the classifier), if this classifier has any behaviour. If there is no behaviour defined for this classifier, any communication arriving at a behaviour port is lost. Semantic Variation Points If several connectors are attached on one side of a port, then any request arriving at this port on a link derived from a connector on the other side of the port will be forwarded on links corresponding to these connectors. It is a semantic variation point whether these requests will be forwarded on all links, or on only one of those links. In the latter case, one possibility is that the link at which this request will be forwarded will be arbitrarily selected among those links leading to an instance that had been specified as being able to handle this request (i.e., this request is specified in a provided interface of the part corresponding to this instance). Changes from previous UML Port was not defined in UML 1.5. The constructs related to Port are new in UML 2.0. Stereotypes of UML 2.0 Profile for ArchWare ADL In the UML 2.0 Profile for ArchWare ADL, the required and provided interfaces of a port specify everything that is necessary for interactions through that interaction point. If all interactions of a classifier with its environment are achieved through ports, then the internals of the classifier are fully isolated from the environment. This allows such a classifier to be used in any context that satisfies the constraints specified by its ports. Thereby, from the core viewpoint, the UML 2.0 Port is stereotyped as an ArchWare Port. Required and provided interfaces are stereotyped as ArchWare Connections. Connector The connector concept is extended in the Components package to include interface based constraints and notation. A delegation connector is a connector that links the external contract of a component (as specified by its ports) to the internal realization of that behaviour by the component s parts. It represents the forwarding of signals (operation requests and events): a signal that arrives at a port that has a delegation connector to a part or to another port will be passed on to that target for handling. An assembly connector is a connector between two components that defines that one component provides the services that another component requires. An assembly connector is a connector that is defined from a required interface or port to a provided interface or port. Notation Delegation A delegation connector is notated as a Connector from the delegating source Port to the handling target Part, and vice versa for required Interfaces or Ports. ISSUE

25 The following figure shows delegation connectors connecting the externally provided interfaces of a component to the parts that realize or require them. Assembly An assembly connector maps a required interface of a component to a provided interface of another component in a certain context. Port Port Assembly An assembly connector is notated by a ball-and-socket connection between a provided interface and a required interface. When this notation is used to connect complex ports that are typed by multiple provided and/or required interfaces, the various interfaces are listed as an ordered set, designated with {provided} or {required} if needed. In a system context where there are multiple components that provide or require a particular interface, a notation abstraction can be used that combines by joining the multiple connectors. This abstraction is similar to the one defined for aggregation and subtyping relationships. ISSUE

26 Metamodel The following metaclasses define the component wire constructs. In the metamodel, a connector kind attribute is added to the Connector metaclass. Its value is an enumeration type with valid values assembly or delegation. Constraints The following constraints are enforced: 1. A delegation connector must only be defined between used Interfaces or Ports of the same kind, e.g. between two provided Ports or between two required Ports. 2. If a delegation connector is defined between a used Interface or Port and an internal Part Classifier, then that Classifier must have an implements relationship to the Interface type of that Port. 3. If a delegation connector is defined between a source Interface or Port and a target Interface or Port, then the target Interface must support a signature compatible subset of Operations of the source Interface or Port. ISSUE

27 4. In a complete model, if a source Port has delegation connectors to a set of delegated target Ports, then the union of the Interfaces of these target Ports must be signature compatible with the Interface that types the source Port. 5. An assembly connector must only be defined from a required Interface or Ports to a provided Interface or Port. Semantics A delegation connector is a declaration that behaviour that is available on a component instance is not actually realized by that component itself, but by another instance that has compatible capabilities. This may be another Component or a (simple) Class. The latter situation is modelled through a delegation connector from a Component Interface or Port to a contained Class that functions as a Part. In that case, the Class must have an implements relationship to the Interface of the Port. Delegation connectors are used to model the hierarchical decomposition of behaviour, where services provided by a component may ultimately be realized by one that is nested multiple levels deep within it. The word delegation suggests that concrete message and signal flow will occur between the connected ports, possibly over multiple levels. A port may delegate to a set of ports on subordinate components. In that case, these subordinate ports must collectively offer the delegated functionality of the delegating port. At execution time, signals will be delivered to the appropriate port. In the cases where multiple target ports support the handling of the same signal, the signal will be delivered to all these subordinate ports. The execution time semantics for an assembly connector are that signals travel along an instance of a connector, originating in a required port and delivered to a provided port. Multiple connectors directed from a single required interface or port to provided interfaces on different components indicates that the instance that will handle the signal will be determined at execution time. Similarly, multiple required ports that are connected to a single provided port indicates that the request may originate from instances of different component types. The interface compatibility between provided and required ports that are connected enables an existing component in a system to be replaced by one that (minimally) offers the same set of services. Also, in contexts where components are used to extend a system by offering existing services, but also adding new functionality, assembly connectors can be used to link in the new component definition. That is, by adding the new component type that offers the same set of services as existing types, and defining new assembly connectors to link up its provided and required ports to existing ports in an assembly. Changes from previous UML Connector was not defined in UML 1.5. The constructs related to Connector are new in UML 2.0. Stereotypes of UML 2.0 Profile for ArchWare ADL In the UML 2.0 Profile for ArchWare ADL, the UML 2.0 Assembly Connector is stereotyped as an ArchWare Connection Unification and the UML 2.0 Delegation Connector is stereotyped as an ArchWare Connection Relay. ISSUE

28 Composite Structure A composite structure depicts the internal structure of a classifier. It encompasses a composition of interconnected elements, representing run-time instances collaborating over communications links. Notation The Composite structures are notated as nested structures. Composite components are notated as follows. Component Component Port «delegate» Port Port «delegate» Port It shows an internal or white-box view of the internal structure of a component that contains other components as parts of its internal assembly. The parts and ports can be expressed as follows. ISSUE

29 The following figure shows an example of a composite component, its provided and required interfaces, and wiring through dependencies on a composite structure. The following figure shows an example of a composite structure of components, with connector wiring between provided and required interfaces of parts (Note: Client interface is a subtype of Person ). The wiring of components can be represented on structure diagrams by means of classifiers and dependencies between them. Note: the ball-and-socket notation from the ISSUE

30 previous figure may be used as a notation alternative for dependency based wiring. On composite structures, detailed wiring can be performed at the role or instance level by defining parts and connectors. Graphic nodes that can be included in structure diagrams are shown in the following tables. ISSUE

31 Metamodel The InternalStructure subpackage provides mechanisms for specifying structures of interconnected elements that are created within an instance of a containing classifier. A structure of this type represents a decomposition of that classifier and is referred to as its internal structure. The StructuredClasses subpackage supports the representation of classes that may have ports as well as internal structure. The Actions subpackage adds actions that are specific to the features introduced by composite structures, e.g., the sending of messages via ports. A structured classifier is defined as follows. ISSUE

32 Actions in composite structures are defined as follows. The target value of an invocation action may be a port. In this case, the invocation request is sent to the object owning this port as identified by the port identity, and is, upon arrival, handled as described by the port owner. Specifying one or more ports for an event implies that the event triggers the execution of an associated behaviour only if the event was received via one of the specified ports. Semantics A composite structure diagram depicts the internal structure of a classifier. For a Composite Component, it depicts its internal structure. Changes from previous UML Composite Structure was not defined in UML 1.5. The constructs related to Composite Structure are new in UML 2.0. Stereotypes of UML 2.0 Profile for ArchWare ADL In the UML 2.0 Profile for ArchWare ADL, from the core viewpoint, the UML 2.0 Composite Structure is stereotyped as an ArchWare Composition of Abstractions, that in turn is stereotyped as an ArchWare Composition of Components and Connectors. Finally, it is stereotyped as an ArchWare Architecture. Action An action is the fundamental unit of behaviour specification. An action takes a set of inputs and converts them into a set of outputs, though either or both sets may be empty. The most basic action provides for implementation-dependent semantics, while other packages provide more specific actions. Some of the actions modify the state of the system in which the action executes. Actions are contained in behaviours, which provide their context. Behaviour provides constraints among actions to determine when they execute and what inputs they have. ISSUE

33 Basic actions include those that perform operation calls, signal sends, and direct behaviour invocation. Operations are specified in the model and can be dynamically selected only through polymorphism. Signals are specified by a signal object, whose type represents the kind of message transmitted between objects, and can be dynamically created. Note that operations may be bound to activities, state machine transitions, or other behaviours. The receipt of signals may be bound to activities, state machine transitions, or other behaviours. The intermediate level describes the various action primitive actions. These primitive actions are defined in such a way as to enable the maximum range of mappings. Specifically, primitive actions are defined so that they either carry out a computation or access object memory, and never both. This approach enables clean mappings to a physical model, even those with data organizations different from that suggested by the specification. In addition, any re-organization of the data structure will leave the specification of the computation unaffected. A surface action language would encompass both primitive actions and the control mechanisms provided by behaviours. In addition, a surface language may map higherlevel constructs to the actions. For example, creating an object may involve initializing attribute values or creating objects for mandatory associations. The specification defines the create action to only create the object, and requires further actions to initialize attribute values and create objects for mandatory associations. A surface language could choose to define a creation operation with initialization as a single unit as a shorthand for several actions. A particular surface language could implement each semantic construct one-to-one, or it could define higher-level, composite constructs to offer the modeller both power and convenience. This specification, then, expresses the fundamental semantics in terms of primitive behavioural concepts that are conceptually simple to implement. Modellers can work in terms of higher-level constructs as provided by their chosen surface language or notation. Notation The action notation is not normative. Metamodel Metaclasses of basic invocation actions. ISSUE

34 Metaclasses of intermediate invocation actions. Semantics An action is a named element that is the fundamental unit of executable functionality. The execution of an action represents some transformation or processing in the modelled system, be it a computer system or otherwise. An action execution represents the run-time behaviour of executing an action within a specific behaviour execution. As Action is an abstract class, all action executions will be executions of specific kinds of actions. When the action executes and what its actual inputs are is determined by the concrete action and the behaviours in which it is used. Changes from previous UML Action is the same concept as in UML 1.5, but modelled independently of the behaviours that use it. Stereotypes of UML 2.0 Profile for ArchWare ADL ISSUE

35 In the UML 2.0 Profile for ArchWare ADL, from the core viewpoint, the UML 2.0 Action is stereotyped as an ArchWare Action (action prefixes or functions). State Machines The StateMachine package defines a set of concepts that can be used for modelling discrete behaviour through finite state-transition systems. In addition to expressing the behaviour of a part of the system, state machines can also be used to express the usage protocol of part of a system. These two kinds of state machines are referred here as behavioural state machines and protocol state machines. Behavioural state machines State machines can be used to specify behaviour of various model elements. For example, they can be used to model the behaviour of individual entities (e.g., class instances). Protocol State machines Protocol state machines are used to express usage protocols. Protocol state machines express the legal transitions that a classifier can trigger. The state machine notation is a convenient way to define a lifecycle for objects, or an order of the invocation of its operation. Because protocol state machines do not preclude any specific behavioural implementation, and enforces legal usage scenarios of classifiers, interfaces and ports can be associated to this kind of state machines. Notation The notation for behavioural state machine is very close to the UML 1.5 notation. The notation for protocol state machine is very similar to the one of behavioural state machines. The keyword {protocol} placed close to the name of the state machine differentiates graphically protocol state machine diagrams. ISSUE

36 Metamodel Behavioural State Machines ISSUE

37 Protocol State Machines Semantics Behavioural state machines Behavioural State machines can be used to express the behaviour of part of a system. Behaviour is modelled as a traversal of a graph of state nodes interconnected by one or more joined transition arcs that are triggered by the dispatching of series of (event) occurrences. During this traversal, the state machine executes a series of activities associated with various elements of the state machine. Protocol State machines A Protocol State Machine specifies which operations of a classifier can be called in which state and under which condition, thus specifying the allowed call sequences on the classifier's operations. A protocol state machine presents the possible and permitted transitions on the instances of its context classifier, together with the operations which carry the transitions. In this manner, an instance lifecycle can be created for a classifier, ISSUE

38 by specifying the order in which the operations can be activated and the states through which an instance progresses during its existence. Protocol state machines constitute a means to formalize the interface of classes. Protocol state machine interpretation can vary from: 1. Declarative protocol state machines that specify the legal transitions for each operation. The exact triggering condition for the operations is not specified. This specification only defines the contract for the user of the context classifier. 2. Executable protocol state machines, that specify all events that an object may receive and handle, together with the transitions that are implied. In this case, the legal transitions for operations will exactly be the triggered transitions. The call trigger specifies the effect action, which is the call of the associated operation. The representation for both interpretations is the same, the only difference being the direct dynamic implication that the second interpretation provides. Changes from previous UML The constructs of state machines in UML 2.0 enhances those of statecharts in UML 1.5. Stereotypes of UML 2.0 Profile for ArchWare ADL In the UML 2.0 Profile for ArchWare ADL, from the core viewpoint, the UML 2.0 Behavioural State Machine is stereotyped as an ArchWare Behaviour. The UML 2.0 Protocol State Machine, interpreted as a declarative protocol, is stereotyped as a protocol property. ISSUE

39 4. DEFINING PROFILES IN UML 2.0 This chapter presents the constructs for defining profiles in UML 2.0. In UML 2.0, as it was in UML 1.5, the Profiles package contains mechanisms that allow metaclasses from existing metamodels to be extended to adapt them for different purposes. This includes the ability to tailor the UML metamodel for different platforms or domains (such as software architecture description or business process modelling). The profiles mechanism is consistent with the OMG Meta Object Facility (MOF). The following requirements have driven the definition of profile semantics from inception: 1. A profile must provide mechanisms for specializing a reference metamodel (such as a set of UML packages) in such a way that the specialized semantics do not contradict the semantics of the reference metamodel. That is, profile constraints may typically define well-formedness rules that are more constraining (but consistent with) those specified by the reference metamodel. 2. A profile must be able to reference domain-specific UML libraries where certain model elements are pre-defined. 3. It must be possible to specify which profiles are being applied to a given Package (or any of specializations of that concept). This is particularly useful during model interchange so that an importing environment can interpret a model correctly. 4. It should be possible to define a UML extension that combines profiles and model libraries (including template libraries) into a single logical unit. However, within such a unit, for definitional clarity and for ease of interchange (e.g. reference by name ), it should still be possible to keep the libraries and the profiles distinct from each other. 5. A profile should be able to specialize the semantics of standard UML metamodel elements, e.g., in a model with the profile Java model generalization of classes should be able to be restricted to single inheritance, without having to explicitly assign a stereotype «Java class» to each and every class instance. 6. A notational convention for graphical stereotype definitions as part of a profile should be provided. 7. Profiles can be dynamically applied to or retracted from a model. It is possible on an existing model to apply new profiles, or to change the set of applied profiles. 8. Profiles can be dynamically combined. Frequently, several profiles will be applied at the same time on the same model. This profile combination may not be foreseen at profile definition time. 9. Models can be exchanged regardless of the profiles known by the destination target. The destination of the exchange of a model extended by a profile may not know the profile, and is not required to interpret a specific profile description. The destination environment interprets extensions only if it possesses the required profiles. 10. The vast majority of UML case tools should be able to implement Profiles. The design of UML profiles should therefore not constraint these tools to have an internal implementation based on a meta-metamodel/metamodel architecture. 11. It must be possible to interchange profiles between tools, together with models to which they have been applied, by using the UML XMI interchange mechanisms. A profile must therefore be defined as an interchangeable UML model. In addition to exchanging profiles together with models between tools, profile application should also be definable by reference (e.g. import by name ); that is, a profile does not need to be interchanged if it is already present in the importing tool. ISSUE

40 Concerning extensibility, the profiles mechanism is not a first-class extension mechanism, i.e., it does not allow for modifying existing metamodels. Rather, the intention of profiles is to give a straightforward mechanism for adapting an existing metamodel with constructs that are specific to a particular domain, platform, or method. Each such adaptation is grouped in a profile. It is not possible to take away any of the constraints that apply to a metamodel such as UML using a profile, but it is possible to add new constraints that are specific to the profile. The only other restrictions are those inherent in the profiles mechanism; there is nothing else that is intended to limit the way in which a metamodel is customized. First-class extensibility is handled through MOF, where there are no restrictions on what you are allowed to do with a metamodel: you can add and remove metaclasses and relationships as you find necessary. Of course, it is then possible to impose methodology restrictions that you are not allowed to modify existing metamodels, but only extend them. In this case, the mechanisms for first-class extensibility and profiles start coalescing. There are several reasons why you may want to customize a metamodel: Give a terminology that is adapted to a particular platform or domain (such as capturing EJB terminology like home interfaces, enterprise java beans, and archives). Give a syntax for constructs that do not have a notation (such as in the case of actions). Give a different notation for already existing symbols (such as being able to use a picture of a computer instead of the ordinary node symbol to represent a computer in a network). Add semantics that is left unspecified in the metamodel (such as how to deal with priority when receiving signals in a state machine). Add semantics that does not exist in the metamodel (such as defining a timer, clock, or continuous time) Add constraints that restrict the way you may use the metamodel and its constructs (such as disallowing actions from being able to execute in parallel within a single transition). Add information that can be used when transforming a model to another model or code (such as defining mapping rules between a model and Java code). There is no simple answer for when you should create a new metamodel and when you instead should create a new profile. The following elements are defined in the Profiles package. ISSUE

41 Profile (from Profiles) A profile defines limited extensions to a reference metamodel with the purpose of adapting the metamodel to a specific platform or domain. A profile is a kind of package that extends a reference metamodel. The primary extension construct is the stereotype, which are defined as part of profiles. A profile introduces several constraints, or restrictions, on ordinary metamodeling through the use of the metaclasses defined in this package. A profile is a restricted form of a metamodel that must always be related to a reference metamodel, such as UML, as described below. A profile cannot be used without its reference metamodel, and defines a limited capability to extend metaclasses of the reference metamodel. The extensions are defined as stereotypes that apply to existing metaclasses. In the following figure, a simple example of an EJB profile is shown. Class (from Profiles) Class has derived association that indicates how it may be extended through one or more stereotypes. A Class that is extended by a Stereotype may be extended by the optional stereotype «metaclass» shown above or before its name. ISSUE

42 In the following example, it is made explicit that the extended class Interface is in fact a metaclass (from a reference metamodel): Extension (from Profiles) An extension is used to indicate that the properties of a metaclass are extended through a stereotype, and gives the ability to flexibly add (and later remove) stereotypes to classes. Extensions can be required. This provides for a way to express extensions that should always be present for all instances of the base metaclass depending on which profiles are applied. The same stereotype can extend different the metaclasses and different stereotypes can extend the same metaclass. Stereotype (from Profiles) A stereotype defines how an existing metaclass may be extended, and enables the use of platform or domain specific terminology or notation in place of or in addition to the ones used for the extended metaclass. Stereotype is a kind of Class that extends Classes through Extensions. Just like a class, a stereotype may have properties, which may be referred to as tag definitions. When a stereotype is applied to a model element, the values of the properties may be referred to as tagged values. Stereotype can change the graphical appearance of the extended model element by using attached icons. A stereotype is a limited kind of metaclass that cannot be used by itself, but must always be used in conjunction with one of the metaclasses it extends. Each stereotype may ISSUE

43 extend one or more classes through extensions as part of a profile. Similarly, a class may be extended by one or more stereotypes. An instance S of Stereotype is a kind of (meta) class. Relating it to a metaclass C from the reference metamodel (typically UML) using an Extension (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of S. At the model level instances of S are related to C model elements (instances of C ) by links (occurrences of the association/extension from S to C ). Any model element from the reference metamodel (any UML model element) can be extended by a stereotype. For example in UML, Classes, Components, States, Transitions, Activities, Use cases, Attributes, Dependencies, etc. can all be extended with stereotypes. In the following figure, a simple stereotype Clock is defined to be applicable at will (dynamically) to instances of the metaclass Class. In the following figure, presentation options for an extended class are shown. Importing Profiles Profiles may import packages. ISSUE

44 In this figure, the package Types is imported from the profile Manufacturer. The data type Color is then used as the type of one of the properties of the stereotype Device, just like the predefined type String is also used. Note that the class JavaInteger may also be used as the type of a property. If the profile Manufacturer is later applied to a package, then the types from Types are also available for use in the package to which the profile is applied (since profile application is a kind of import). This means that for example the class JavaInteger can be used as both a metaproperty (as part of the stereotype Device) and an ordinary property (as part of the class TV). Note how the metaproperty is given a value when the stereotype Device is applied to the class TV. Applying Profiles A profile application is used to show which profiles have been applied to a package. One or more profiles may be applied at will to a package that is created from the same metamodel that is extended by the profile. Applying a profile means that it is allowed, but not necessarily required, to apply the stereotypes that are defined as part of the profile. It is possible to apply multiple profiles to a package as long as they do not have conflicting constraints. If a profile that is being applied depends on other profiles, then those profiles must be applied first. When a profile is applied, instances of the appropriate stereotypes should be created for those elements that are instances of metaclasses with required extensions. The model is not well-formed without these instances. Once a profile has been applied to a package, it is allowed to remove the applied profile at will. Removing a profile implies that all elements that are instances of elements defined in a profile are deleted. A profile that has been applied cannot be removed unless other applied profiles that depend on it are first removed. Given the profiles Java and EJB, the following figure shows how these have been applied to the package WebShopping. The following figure shows an example instance model for when the stereotype Clock is applied to a class called StopWatch. The extension between the stereotype and the metaclass results in a link between the instance of stereotype Clock and the (userdefined) class StopWatch. ISSUE

45 The following figure illustrates using of stereotypes showing values. To summarise, the main nodes and paths that can be included in profiles is shown in the following tables. ISSUE

46 Changes from previous UML The Profile mechanism has been specifically defined for providing a lightweight extension mechanism to the UML standard. In UML 1.1, stereotypes and tagged values were used as string-based extensions that could be attached to UML model elements in a flexible way. In subsequent revisions of UML, the notion of a Profile was defined in order to provide more structure and precision to the definition of Stereotypes and Tagged values. The UML 2.0 infrastructure and superstructure specifications have carried this further, by defining it as a specific meta-modelling technique. Stereotypes are specific metaclasses, tagged values are standard metaattributes, and profiles are specific kinds of packages. In particular, the major changes between UML 1.5 and UML 2.0 are: extension did not exist as a metaclass in UML 1.5; in UML 1.5, it was not possible to indicate which profiles were applied to a package; in UML 1.3, tagged values could extend a model element without requiring the presence of a stereotype; in UML 1.4, this capability, although still supported, was deprecated, to be used only for backward compatibility reasons; in UML 2.0, a tagged value can only be represented as an attribute defined on a stereotype. UML 1.5 Profile for ArchWare ADL Deliverable D1.4b specified a UML 1.5 Profile for ArchWare ADL. In that document, first a layered metamodel of ArchWare ADL was defined independently of the UML 1.5 metamodel. Then, in a second step, the UML 1.5 Profile for ArchWare ADL was specified by mapping the ArchWare ADL metamodel to the UML 1.5 metamodel. It resulted in a UML 1.5 Profile composed of the following UML stereotypes. ArchWare Model Element Stereotype UML 1.5 Base Element Tagged Values Abstraction Archetype <<abstraction>> Classifier value, type, parameter, behaviour Port Archetype <<port>> Classifier Component Archetype << component >> Classifier value, type, parameter, behaviour, port Connector Archetype << connector >> Classifier value, type, parameter, behaviour, port Composite Archetype <<composite>> Classifier value, type, parameter, behaviour, port, component, connector Unification <<unification>> AssociationClass Behaviour <<behaviour>> StateChart Type Declaration <<type>> StructuralFeature ISSUE

47 Value Declaration Parameter Declaration <<value>> <<parameter>> StructuralFeature StructuralFeature That specification of the UML 1.5 Profile for ArchWare ADL was mainly based on stereotypes whose base metaclass is Classifier. It is the case for Abstraction, Port, Connector, Component, and Composite. The stereotype for Unification was based on the AssociationClass metaclass and the one of Behaviour on the StateChart metaclass. Type, Value, and Parameter were defined as structural features, using required tagged values. The design decisions that underlie these choices for UML 1.5 were based on the fact that UML 1.5 has a poor metamodel for describing component-based systems. Therefore, all the architectural component-based concepts of ArchWare ADL were defined as stereotypes based on the general Classifier metaclass. The same approach also applied to unification. The Behaviour is naturally based on StateChart and Type, Value, and Parameter declarations based on tagged values. As UML 2.0 provides a richer metamodel for describing component-based systems, the UML 2.0 Profile for ArchWare ADL will be based on more specialized metaclasses as presented in the next chapter. ISSUE

48 5. SPECIFICATION OF THE UML 2.0 PROFILE FOR ADL This chapter specifies the UML 2.0 Profile for ArchWare ADL based on constructs described in chapter 3 using the constructs described in chapter 4 having as baseline the profile recalled in chapter 2. It upgrades the UML 1.5 Profile for ArchWare ADL. The following stereotypes of the UML 1.5 Profile for ArchWare ADL are redefined in the UML 2.0 Profile for ArchWare ADL based on enhancements and new constructs of UML 2.0. Stereotypes and Tags for Architecture Structure Modelling with ArchWare ADL The stereotypes belonging to the UML 2.0 Profile for ArchWare ADL are described 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, that can be itself a stereotype. The third column identifies the defined tags and the fourth provides a description of the meaning of the stereotype. Stereotype Base Metaclass «abstraction» Component (including Ports, Interfaces, and Behaviour) Tags parameter[*] type[*] value[*] Description & Constraints Indicates that a UML 2.0 Component is interpreted as an ArchWare Abstraction, i.e. the parent stereotype of ArchWare Components, Connectors, and Composites. ArchWare Architectures are described in terms of ArchWare Abstractions. An ArchWare Abstraction has an internal behaviour described by a UML 2.0 State Machine if it is a primitive abstraction or by a UML 2.0 Composite Structure if it is a composite abstraction. «component» «abstraction» Inherited from «abstraction» Indicates that an ArchWare Abstraction is interpreted as an ArchWare Component. ArchWare 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. An ArchWare Component has external ports (and interfaces) ISSUE

49 and an internal behaviour described by a UML 2.0 State Machine. «connector» «abstraction» Inherited from «abstraction» Indicates that an ArchWare Abstraction is interpreted as an ArchWare Connector. ArchWare Connectors are described as ArchWare Components in terms of external ports and an internal behaviour. However, their architectural role is to connect together ArchWare Components. They specify interactions among components. An ArchWare Connector has external ports (and interfaces) and an internal behaviour described by a UML 2.0 State Machine. «composite» «abstraction» Inherited from «abstraction» Indicates that an ArchWare Abstraction is interpreted as an ArchWare Composite, i.e. an architectural abstraction that composes ArchWare Components and Connectors together. ArchWare Composites can be decomposed and recomposed in different ways or with different components and connectors in order to construct different compositions. ArchWare Architectures are composites representing systems. An architecture can itself be a composite component in another architecture, i.e. a sub-architecture. An ArchWare Composite has ports (and interfaces) and an internal behaviour described by a UML 2.0 Composite Structure. «port» Port connection[*] protocol[*] Indicates that a UML 2.0 Port is interpreted as an ArchWare Port. ArchWare Ports are described in terms of connections between a ISSUE

50 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. «connection» Interface protocol[*] Indicates that a UML 2.0 Interface is interpreted as an ArchWare Connection. ArchWare Connections are basic interaction points. Their architectural role is to provide communication channels between two architectural elements. Connections may be unified to enable communication. «unification» Assembly Connector renaming[0..1] Indicates that a UML 2.0 Assembly Connector is interpreted as an ArchWare Unification. A connection provided by a port of a component is attached to a connection provided by a port of a connector by unification. Connections are unified to enable value passing. «relay» Delegation Connector renaming[0..1] Indicates that a UML 2.0 Delegation Connector is interpreted as an ArchWare Relay. 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. Connections are relayed to enable value passing from/to the environment. ISSUE

51 «protocol» Comment Indicates that a UML 2.0 Comment is interpreted as an ArchWare Protocol. An ArchWare Protocol specifies the allowed action sequences on connections in ports or among ports. Protocols may be enforced by ports and among ports. Metaattributes Type Surface Notation Description & Constraints «parameter» String ArchWare ADL Indicates which parameters are required by an ArchWare Abstraction. «type» String ArchWare ADL Indicates which types are declared in an ArchWare Abstraction. «value» String ArchWare ADL Indicates which values are declared in an ArchWare Abstraction. «connection» String ArchWare ADL Indicates which connections are declared in an ArchWare Port. «protocol» String ArchWare ADL Indicates which protocols are enforced by an ArchWare Port. «renaming» String ArchWare ADL Indicates that connections are renamed in an ArchWare Unification. The UML 2.0 Profile for ArchWare ADL defines the following stereotype icons: Stereotype <<composite>> Stereotype Icon ISSUE

52 <<component>> <<connector>> <<port>> <<connection>> Stereotypes and Tags for Architecture Behaviour Modelling with ArchWare ADL The constructs of state machines in UML 2.0 enhances those of statecharts in UML 1.5. Behaviour of an ArchWare Abstraction (ArchWare Component or Connector) is described in terms of stereotyped UML 2.0 State Machines as follows. Behaviour States Initial state Final state Intermediate state << done >> Behaviour Transitions prefix via connec ti on n a m e send va lue via connec tion n a m e re c eive va lue un ob serva bl e [condition ] pr efix Match prefix : [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 ISSUE

53 Sequence Behaviour ] Sequence Behaviour ::= prefix. Behaviour -- prefix Choice Behaviour Choi ce Behaviour ::= choose { Behaviour 1 or Behaviour 2 } -- choice Replicated Behaviour <<replicate>> R ep lic ation Behaviour ::= replicate Behaviour -- replication Restricted Behaviour ISSUE

54 << Free >> name: ConnectionType Restriction (by default) Behaviour ::= restrict name : ConnectionType. Behaviour -- restriction Recursive Behaviour A(X, Y) A(a, b) Recursion Behaviour ::= BehaviourApplication BehaviourApplication ::= name { v 1,,v n } For instance, the following expression: recursive value A is Abstraction(X: Real, Y: Real). { via e receive a. via f receive b. A(a, b) } can be visually notated as follows: Composed Behaviour Composi tion ISSUE

55 Behaviour ::= compose { Behaviour 1 and Behaviour 2 } -- composition Translation Rules for Generating Architecture Descriptions in ArchWare ADL The translation rules for generating architecture descriptions in ArchWare ADL from UML 2.0 models (modelling software architectures) are based on the stereotypes and tags specified so far illustrated in the next chapter. ISSUE

56 6. CASE STUDY This chapter presents a case study to illustrate how the UML 2.0 Profile for ArchWare ADL can be used to formally describe a software architecture. We describe a clientserver 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 1 depicts a black-box description of the login system using an icon stereotype display in the UML 2.0 Profile for ArchWare ADL. It is represented as a composite component, named LoginManager, having ports update and request. These ports represent the interaction of the LoginManager system with its environment. update request LoginManager Figure 1. Black-box description of the architecture in UML 2.0 Profile for ArchWare ADL (icon display) Figure 2 below further details that black-box model using a decoration stereotype display. LoginManager <<type>> UserId = Any <<type>> Password = Any <<type>> Login = tuple[userid, Password] update <<connection>> upd = in(login) request <<connection>> log = in(userid) <<connection>> pwd = out(password) <<protocol>> ( via log receive any. true*. via pwd send any )* ISSUE

57 Figure 2. Black-box description of the architecture in UML 2.0 Profile for ArchWare ADL (decoration 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. The black-box description of the LoginManager system expressed using the UML 2.0 Profile for ArchWare ADL in Figure 2 can be formally translated in ArchWare ADL as shown in Figure 3. architecture LoginManager is abstraction() { type UserId is Any. type Password is Any. 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 3. Black-box description of the architecture in ArchWare 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 4 outlines the architecture of the system in terms of its components and connectors. update request LoginManager incoming NewLoginUI outgoing incoming Link outgoing incoming LoginDB select Figure 4. Description of the architecture in UML 2.0 Profile for ArchWare ADL (icon display) The architecture consists of a login IU component NewLoginIU, a database manager component LoginDB, and a connector Link to connect them together. These components and connector can be formally described in UML 2.0 Profile for ArchWare ADL and translated in ArchWare ADL as follows. ISSUE

58 NewLoginUI <<type>> UserId = Any <<type>> Password = Any <<type>> Login = tuple[userid, Password] incoming <<connection>> in = in(login) <<protocol>> ( via incoming::in receive any. true*. via outgoing::tolink send any )* outgoing <<connection>> tolink = out(login) Figure 5. Component NewLoginIU in UML 2.0 Profile for ArchWare ADL In component NewLoginIU (shown in Figure 5), 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 ArchWare ADL in figure 5 can be formally translated in ArchWare ADL as shown in Figure 6. 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 { protocol is { ( via incoming::in receive any. true*. via outgoing::tolink send any )* } } Figure 6. Component NewLoginIU in ArchWare ADL ISSUE

59 LoginDB <<type>> UserId = Any <<type>> Password = Any <<type>> Login = tuple[userid, Password] select <<connection>> log = in(userid) <<connection>> pwd = out(password) <<protocol>> ( via log receive any. true*. via pwd send any )* incoming <<connection>> fromlink = in(login) Figure 7. Component LoginDB in UML 2.0 Profile for ArchWare ADL In component LoginDB (shown in Figure 7), 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 ArchWare ADL in figure 7 can be formally translated in ArchWare ADL as shown in Figure 8. component LoginDB is abstraction() { type UserId is Any. type Password is Any. type Login is tuple[userid, Password]. port select is { connection log is in(userid). connection pwd is out(password) } assuming { protocol is { ( via log receive any. true*. via pwd send any )* } }. port incoming is { connection fromlink is in(login) }. } Figure 8. Component LoginDB in ArchWare ADL ISSUE

60 Link <<type>> UserId = Any <<type>> Password = Any <<type>> Login = tuple[userid, Password] incoming <<connection>> tolink = in(login) <<protocol>> ( via incoming::tolink receive login : Login. via outgoing::fromlink send login )* outgoing <<connection>> fromlink = out(login) Figure 9. Connector Link in π-uml In connector Link (shown in Figure 9), 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 ArchWare ADL in Figure 9 can be formally translated in ArchWare ADL as shown in Figure 10. connector Link is abstraction() { type UserId is Any. type Password is Any. type Login is tuple[userid, Password]. port incoming is { connection tolink is in(login) }. port outgoing is { connection fromlink is out(login) }. } assuming { protocol is { ( via incoming::tolink receive login : Login. via outgoing::fromlink send login )* } } Figure 10. Connector Link in ArchWare 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 ArchWare ADL in terms of state machines as follows. ISSUE

61 via incoming::tolink receive login : Login via outgoing::fromlink send login Figure 11. 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 ArchWare ADL in Figure 11 can be formally translated in ArchWare ADL as shown in Figure 12. connector Link is abstraction() { behaviour is { via incoming::tolink receive login : Login. via outgoing::fromlink send login. behaviour() } } assuming { } } Figure 12. Behaviour of the connector Link in ArchWare ADL Now let us come back to the architecture described in Figure 4 (depicted again in Figure 13 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 ArchWare ADL as shown in Figure 13, thereby providing the structure of the architecture in terms of attached components and connector. update request LoginManager incoming NewLoginUI outgoing incoming Link outgoing incoming LoginDB select Figure 13: Description of the architecture in UML 2.0 Profile for ArchWare ADL That architecture description expressed in the UML 2.0 Profile for ArchWare ADL can be formally translated in ArchWare ADL as shown in Figure 14. ISSUE

62 architecture LoginManager is abstraction() { } behaviour is compose { replicate ui 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 14. 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 unified. 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. ISSUE

63 7. CONCLUSION The UML 2.0 Profile for ArchWare ADL specified in this deliverable provides a UMLcompatible 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, ArchWare ADL supports formal specification (and corresponding verification) of static and dynamic software architectures. This is a key factor in the architectural design phase. The UML 2.0 Profile for ArchWare ADL can be implemented in different UML Modellers. The following screenshots depict an implementation of the UML 2.0 Profile for ArchWare ADL in the Sparx s Enterprise Architect 5.0 Toolset. Screenshot of ArchWare Profile Packages ISSUE

64 Screenshot of the ArchWare Types Profile Screenshot of ArchWare Core Profile ISSUE

65 Screenshot of ArchWare Component & Connector Profile Screenshot of Toolbox and Resource View with ArchWare Profile ISSUE

66 Screenshot of Architectural Archetypes with ArchWare Profile Screenshot of Architecture Description with ArchWare Profile 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. This is the case in ArchWare with the application of the UML 2.0 Profile for ArchWare ADL. Indeed, the usefulness of an ADL is directly related to the kinds of tools it provides to support visual and formal architecture description, but also analysis, refinement, code generation, and evolution. Definitely, ArchWare ADL is supported by a comprehensive toolset for supporting architecture-centric formal development. ISSUE