Modeling

NTNU

Composition of UML collaborations

Preface This thesis is carried out as a part of the MSc studies at the Norwegian University of Science and Technology, Faculty of Information Technology, Mathematics and Electrical Engineering, Department of Telematics. It is the result of the master thesis 2005 in the field of Systems Engineering. I would like to thank my supervisor, Professor Lill Kristiansen for her valuable help and guidance during the work. I also want to thank Frank Alexander Krämer for his useful advices and comments. Trondheim, 24th of June 2005 Øyvind Isaksen

iii

NTNU

Composition of UML collaborations

iv

NTNU

Composition of UML collaborations

Abstract Today there are great research activity in developing methods, tools and platforms to enable rapid and incremental service development. A generally approved idea is to develop new services partly by composing basic service components to provide the wanted functionality, also known as a service-oriented approach. This master thesis will look into how service composition can be modeled by a serviceoriented view, using UML collaborations. This concept is in many ways suitable to model collaborations between participating roles. As a way of exploring the capabilities and for illustrating important points of UML collaborations, a concrete example is worked out. This example also serves as a basis for the final discussion. Furthermore, various aspects of role playing and paper prototyping will be investigated, and also how they can be related to UML collaborations. In that way, the concept of roles is taken from the work with users and customers, towards design. With this assignment, some aspects about UML collaborations, role playing and paper prototypes will be identified, and also how they can be used together as a positive contribution in future service development.

v

NTNU

Composition of UML collaborations

vi

NTNU

Composition of UML collaborations

Table of contents Preface................................................................................................................................ iii Abstract ............................................................................................................................... v Table of contents............................................................................................................... vii Figures................................................................................................................................ ix 1 Introduction............................................................................................................... 11 1.1 Background ....................................................................................................... 11 1.2 Scope and constraints........................................................................................ 11 1.3 Project outline ................................................................................................... 12 2 Software Engineering................................................................................................ 13 2.1 Definitions and SOA......................................................................................... 13 2.2 Rational Unified Process................................................................................... 16 2.2.1 Process overview ...................................................................................... 16 2.3 Model-Driven Architecture............................................................................... 19 2.3.1 Model-Driven Architecture viewpoints .................................................... 21 2.3.1.1 The Computation Independent Model .................................................. 21 2.3.1.2 The Platform Independent Model ......................................................... 22 2.3.1.3 The Platform Specific Model................................................................ 22 2.3.2 Transformation.......................................................................................... 22 2.4 RUP and MDA.................................................................................................. 23 3 Unified Modelling Language.................................................................................... 24 3.1 What is behaviour? ........................................................................................... 24 3.2 Collaboration diagram ...................................................................................... 25 4 Role playing .............................................................................................................. 28 4.1 Role playing in the design process.................................................................... 28 4.2 Scenarios ........................................................................................................... 29 4.3 Paper prototyping.............................................................................................. 31 4.4 An example on paper prototyping..................................................................... 32 4.4.1 Service objective....................................................................................... 32 4.4.2 Scenarios from Stroke Unit....................................................................... 33 4.4.3 Outcome.................................................................................................... 34 4.4.4 Observations from developers .................................................................. 34 4.4.5 Functional requirements............................................................................ 34 5 Service composition.................................................................................................. 36 5.1 Definitions......................................................................................................... 36 5.2 Service composition by UML collaboration..................................................... 38 5.2.1 Method ...................................................................................................... 39 6 Service creation framework ...................................................................................... 41 6.1 ServiceFrame objectives ................................................................................... 41 6.2 ActorFrame ....................................................................................................... 43 6.3 The RAM Architecture ..................................................................................... 43 6.4 Transforming collaborations into actor design ................................................. 44 7 Group communication service .................................................................................. 46 7.1 Service composition.......................................................................................... 46 vii

NTNU

Composition of UML collaborations

8

Discussion ................................................................................................................. 61 8.1 Service composition.......................................................................................... 61 8.2 Paper prototyping and role playing................................................................... 63 8.3 Future work....................................................................................................... 63 9 Conclusion ................................................................................................................ 64 10 References............................................................................................................. 65 Abbreviations.................................................................................................................... 68 Appendix........................................................................................................................... 69 APPENDIX A. 5 ODP views in 5 minutes....................................................................... 70 Enterprise viewpoint ..................................................................................................... 70 Information viewpoint .................................................................................................. 71 Computational viewpoint.............................................................................................. 72 Engineering viewpoint .................................................................................................. 72 Technology viewpoint .................................................................................................. 73 Mapping between different viewpoints ........................................................................ 73 Appendix B. Service composition by process algebra...................................................... 74 Appendix C. Functional requirements. ............................................................................. 76

viii

NTNU

Composition of UML collaborations

Figures Figure 2-1: Development process, modified from [38] .................................................... 14 Figure 2-2: Development process, from [13].................................................................... 15 Figure 2-3: The phases and iterations of RUP, from [7]................................................... 17 Figure 2-4: Model view A................................................................................................. 19 Figure 2-5: Model view B................................................................................................. 20 Figure 2-6: Modelling approaches, modified from [9] ..................................................... 20 Figure 3-1: Collaboration definition ................................................................................. 25 Figure 3-2: Collaboration use, refined .............................................................................. 26 Figure 3-3: Collaboration use ........................................................................................... 27 Figure 4-1: Communication problem, modified from [11]............................................... 28 Figure 4-2: Development process ..................................................................................... 29 Figure 4-3: Example of a paper prototype ........................................................................ 34 Figure 5-1: Client-server, from [13] ................................................................................. 36 Figure 5-2: Peer-to-peer, from [13] .................................................................................. 37 Figure 5-3: Composition, from [13].................................................................................. 37 Figure 6-1: Layers, from [12] ........................................................................................... 42 Figure 6-2: Actor, from [24] ............................................................................................. 43 Figure 6-3: Actor, from [19] ............................................................................................. 44 Figure 6-4, from [13] ........................................................................................................ 45 Figure 7-1: Invite collaboration ........................................................................................ 47 Figure 7-2: Invite state diagram........................................................................................ 47 Figure 7-3: Invite sequence diagram................................................................................. 48 Figure 7-4: Transfer collaboration .................................................................................... 49 Figure 7-5: Transfer state diagram.................................................................................... 49 Figure 7-6: Transfer sequence diagram ............................................................................ 50 Figure 7-7: Communicate collaboration ........................................................................... 50 Figure 7-8: Communicate state diagram........................................................................... 51 Figure 7-9: Communicate sequence diagram ................................................................... 51 Figure 7-10: GroupManage collaboration ........................................................................ 52 Figure 7-11: GroupManage state diagram ........................................................................ 52 Figure 7-12: GroupManage sequence diagram................................................................. 53 Figure 7-13: CommunicateWithEmployee collaboration................................................. 54 Figure 7-14: CommunicateWithEmployee collaboration refined..................................... 54 Figure 7-15: CommuicateWithEmployee state diagram................................................... 55 Figure 7-16: CommuicateWithEmployee sequence diagram ........................................... 55 Figure 7-17: Communication collaboration...................................................................... 56 Figure 7-18: Communication state diagram ..................................................................... 56 Figure 7-19: Communication sequence diagram .............................................................. 57 Figure 7-20: Positioning collaboration ............................................................................. 57 Figure 7-21: Positioning collaboration refined ................................................................. 58 Figure 7-22: Positioning state diagram ............................................................................. 58 Figure 7-23: Positioning sequence diagram...................................................................... 59 Figure 7-24: PositionUpdate collaboration....................................................................... 59 ix

NTNU

Composition of UML collaborations

Figure 7-25: PositionUpdate state diagram....................................................................... 60 Figure 7-26: PositionUpdate sequence diagram ............................................................... 60 Figure A- 1: Enterprise viewpoint, from [2]..................................................................... 71 Figure A- 2: Information viewpoint 1, from [2] ............................................................... 71 Figure A- 3: Computation viewpoint, modified from [2] ................................................. 72 Figure B- 1: : S1 ⊕ S2, from [18]..................................................................................... 75

x

NTNU

Composition of UML collaborations

1 Introduction 1.1 Background The Program for Advanced Telecom Services (PATS) is an agreement on co-operation primarily between Telenor, Ericsson and the Department of Telematics (ITEM) at NTNU. The vision of PATS, as defined at [27] is: …to create a virtual centre of excellence on advanced heterogeneous services and fast service development, established as a mutually beneficial collaboration between partners from industry, university and telecom-operators. Within the PATS is an ongoing project called The Arena for Research on advanced Telecom Services (ARTS) which objective is to heighten the national competence level related to advanced telecom services [27]. This will be achieved through a number of sub-goals. Most relevant in this relation is by defining “…a suite of innovative methods and tools for incremental service engineering.” There are many definitions of what a service is. According to [32], a service is “…an autonomous platform-independent unit of work done by a provider to achieve desired end results for a customer.” Connected to this, a service is often seen as a component that is possible to use in combination with other service components. A Service-Oriented Architecture (SOA) supports this mindset and makes it possible to show services across system components [9]. At present, there are several ongoing research projects on the field of service composition. In that connection, it can be referred to [32] and [33], among others. They deal with for instance how to define semantic interfaces and how service specifications can be specified with the use of UML collaborations.

1.2 Scope and constraints The objective of this assignment is to explore how services can be specified with a service oriented viewpoint, primarily by using UML collaborations. Furthermore, the author will look into how paper prototyping can supplement such collaborations as a basis for communication with customers. The service that serves as an example was designed and implemented in a former assignment by the author [21], but was specified only in an object-oriented view. It is therefore interesting to see how the same service can be specified at new in a serviceoriented view.

11

NTNU

Composition of UML collaborations

Performing paper prototyping requires a group of real users, primarily from the domain that the service will work in. In this assignment the author has chosen not to do such a prototyping session in real. Only the main steps of paper prototyping and role playing are identified, to illustrate how it can be used.

1.3 Project outline Chapter 2 gives an overview of what software engineering is. Two central concepts will be described; the Rational Unified Process and the Model-Driven Architecture. The two concepts will also be related to each other. Chapter 3 describes the Unified Modeling Language (UML), primarily the concept of UML collaborations. Chapter 4 introduces the concept of role playing and paper prototyping. An example is worked out to illustrate some main points. Chapter 5 describes service composition in more details and also arguments why UML collaborations are well suited for service specifications. Chapter 6 presents the ServiceFrame framework, the ActorFrame platform and the Role and Modeling Architecture which is closely related to the ServiceFrame framework. Chapter 7 continues the example from chapter 4 and explores how UML collaborations can be used in service specification. Chapter 8 discusses aspects of UML collaborations, role playing and paper prototypes. Chapter 9 concludes this assignment and also identifies future work. Appendix A gives an overview of the ODP viewpoints. Appendix B briefly introduces process algebra. Appendix C quotes the functional requirements of the example service from [isaksen] which the specification in chapter 7 is based on.

12

NTNU

Composition of UML collaborations

2 Software Engineering Software development has become more important, at the same time as a lot of effort is put into research with the intention to improve the field of software engineering. The field of software engineering tries to solve problems related to the process of constructing software, but it is still a young field compared to other engineering disciplines [38] p. xvii. Section 2.1 gives an overall picture of definitions related to software engineering. Section 2.2 describes a well known and a widely accepted approach on software engineering, called the Rational Unified Process. In section 2.3 the concept of Model-Driven Architecture is described. Finally, section 2.4 gives a short description of how the two concepts are related to each other. After reading this chapter the reader has hopefully got an understanding of what part of the developing process that this assignment focus on as a whole. In addition, it will also make it easier to see what this assignment is not about, and what can be leaved to future work.

2.1 Definitions and SOA In [38] p. 6, they refer to two definitions of what software engineering is. The first definition was given on a NATO conference back in 1968: Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. The second definition was given by IEEE in 1990: Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. Based on these definitions, seven characteristics of software engineering are identified in [38]: • • • •

Software engineering concerns the construction of large programs. The central theme is mastering complexity. Software evolves. The efficiency with which software is developed is of crucial importance.

13

NTNU • • •

Composition of UML collaborations Regular cooperation between people is an integral part of programming-in-thelarge. The software has to support its users effectively. Software engineering is a field in which members of one culture create artefacts on behalf of members of another culture.

The process of software development is shown in Figure 2-1. The figure is a simplified illustration, because in reality things will usually be more complex and not so strict linear.

Figure 2-1: Development process, modified from [38]

Requirements engineering mainly focuses on the functions and the purpose of the system as seen from the environment. It should tell why the system is needed [11]. Functional design engineering express the complete functionality and it should tell what the system shall do. Implementation design engineering focuses on the technical solution. Compared to the two previous steps, this step tells how the system shall be realized. A somewhat more complex figure of the engineering process, compared to the previous figure, is shown in Figure 2-2 [11]. The three previous mentioned engineering tasks, requirements engineering, functional design engineering and implementation design engineering, can be mapped to the rectangular boxes in the figure. This figure emphasizes 14

NTNU

Composition of UML collaborations

the point that the specifying of functionality depends on the functional requirements, and ends up in a functional design. The specifying of the implementation depends on both the functional design and the non functional requirements, and ends up in an implementation design.

Figure 2-2: Development process, from [13]

Related to real time systems1 it is worth to dwell a little bit on functional design engineering because, as argued by [11] p.39, the behaviour of a real time system has much to say for the quality. This makes it important to be able to analyze the functionality precisely, and to validate it towards the functional requirements. As a consequence of that, the system’s behaviour should be described in a formal language, for instance the Specification and Description Language (SDL). Such a precise description makes it possible to test functionality in a pretty thorough way. Two different views may be applied in service development; the object-oriented view and the service-oriented view. Object-orientation aims at modelling the phenomena of application area in the form of objects, where an object is described as being characterized by data items carrying state information [11].

1

Systems with time constraints [11].

15

NTNU

Composition of UML collaborations

The service-oriented view shows services across objects. As argued by [9], great flexibility can be achieved by organizing a system as a collection of encapsulated services making calls on operations through service interfaces. At present, the serviceoriented view has also become popular on web, by providing web-services. As stated in [22], the view can be a solution to rapidly evolving software systems by creating an environment in which software is a service. Then services can be composed to deliver a required outcome. Such systems, which result from federations of elementary services, are often called Service-Oriented Architectures (SOA) [9]. In this assignment it is an underlying philosophy to use a service-oriented approach on service specification.

2.2 Rational Unified Process The Rational Unified Process (RUP) is a software engineering process developed and maintained by Rational Software [39]. The obvious goal of a software process is to produce software. But according to [7], to judge a process as a success, the outcome must be software that works, software that is on time, software that is within budget, software that can be maintained and software that can be reused. At the same time, the rights of both developers and customers must be preserved. The RUP aims at fulfilling these goals by providing a disciplined approach on assigning tasks and responsibilities within a development organization [39]. However, it is important to be aware of the fact that RUP in itself is not a guarantee for developing successful software. For instance, reusable and maintainable software is also highly dependent on the chosen software architecture, which is not directly dependent on RUP. RUP is a collection of the best practices in modern software development. The process emphasizes creating and maintaining models, and is at the same time, according to [39], a guide for how to effectively use the Unified Modelling Language (UML) which was originally created by Rational Software. However, the description of RUP itself does not include anything concrete about how to use UML. The only essential outcome of RUP is software that satisfies the user, as pointed out in [7]. 2.2.1 Process overview Basically, RUP consists of nine fundamental process workflows which describe sequences of activities. The activities are executed concurrently throughout the lifetime of the project and are related to the vertical axis of Figure 2-3 [39]. The six core “engineering” workflows are defined as: 1. Business modelling workflow

16

NTNU 2. 3. 4. 5. 6.

Composition of UML collaborations Requirements workflow Analysis and design workflow Implementation workflow Test workflow Deployment workflow

The three “supporting” workflows are: 1. Project management workflow 2. Configuration and change management workflow 3. Enviroment workflow In this connection the names of the workflows speak for themselves, and are not described in more details. But for a more detailed description, the reader is referred to the referenced literature [7] [39].

Figure 2-3: The phases and iterations of RUP, from [7]

The horizontal axis of Figure 2-3 represents time. It is expressed in terms of cycles, phases, iterations and milestones. Each cycle works on a new generation of the product and each cycle are divided into four phases: 1. 2. 3. 4.

Inception phase Elaboration phase Construction phase Transition phase

17

NTNU

Composition of UML collaborations

Each phase defines key goals that must be achieved before moving on to the next phase. The goals are usually referred to as milestones. Next follows a short description of the four phases: Inception phase The goal of this phase is to establish a business case for the system and delimit the project scope. The outcome of this phase may be: • • • •

Vision of the project’s requirements, possibly in the form of use cases. A description of the project objectives. A business case for the project including business context, success criteria, and a financial forecast. A project plan.

Elaboration phase During this phase, the problem domain is analyzed in order to establish a firm understanding of the problem to be solved [7]. Furthermore, both an architectural foundation and a project plan have to be worked out, as well as eliminating the highest risk elements of the project [39]. The outcome of this phase may be: • • • • •

A use-case model. Both functional requirements and non functional requirements. A software architecture description. An executable architectural prototype. A development plan for the overall project.

Construction phase The purpose of the construction phase is to develop, integrate and test all remaining components and application features. As distinct from the two previous phases which purpose was to develop so-called intellectual property, this phase is more a manufacturing process [7]. The outcome of the construction phase may be: • • •

The software product integrated on the adequate platforms. The user manuals. A description of the current release.

Transition phase The last phase is called the transition phase. This phase focuses on the activities required to make the software product available for the users. The main objectives include [39]: • • •

Achieving user self-supportability Achieving stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria of the vision. Achieving final product baseline as rapidly and cost effectively as practical. 18

NTNU

Composition of UML collaborations

The last phase then completes the RUP process.

2.3 Model-Driven Architecture The Object Management Group (OMG) is an international non-profit corporation [25]. One of the important roles that the OMG consortium plays is developing and supporting specifications to improve the practice of enterprise software development and deployment [9]. In 2001 the OMG adopted the Model-Driven Architecture (MDA) which is an approach on using models in software development [25]. Recently, MDA has begun to be approved as an approach to application design and implementation by many organizations [10]. The vision of MDA is to separate the specification of the functionality decisions of the system from the platform decisions by using three different modelling approaches known as viewpoints, as will be described later. Through this architectural separation of concerns, MDA helps in achieving portability, interoperability and reusability [25]. In a way, MDA serves as a guide on how to make relevant models when designing systems. Models provide abstractions of a system allowing system engineers to focus on relevant details about a specific system [25]. Using models in the design phase is a way of helping the developers and others involved in the process to understand the phenomena of interest. Models are in the first place created for a purpose, and they may be more or less useful for this purpose. It all depends on how good the models are in simplifying and generalizing the area of concern [29] p.33. Two simple examples illustrating this point are shown in Figure 2-4 and Figure 2-5. The figures show two models of the same house, but in with different views. None of these models are wrong, but they are suited to illustrate different capabilities about the same house, all depending on which details are most relevant. Figure 2-4 is preferred to illustrate what the house looks like from the outside. However, when it comes to illustrating how the floors are divided into rooms, Figure 2-5 is undoubtedly preferred.

Figure 2-4: Model view A

19

NTNU

Composition of UML collaborations

Figure 2-5: Model view B

Models are, as the name indicates, an important aspect of MDA. As defined in [25], it is model-driven because it provides a means for using models to direct the course of understanding design, construction, deployment, operation, maintenance and modification. Generally, the process of system development usually ends up with some source code that implements the system itself. Models are often synchronized with the source code using different modelling approaches, as shown in Figure 2-6.

Figure 2-6: Modelling approaches, modified from [9]

When models have enough details to enable the generation of a full system implementation from the models themselves, it is called a model-centric approach [9]. This is shown in the left side of Figure 2-6. The transformation from models to code is done by applying different patterns. In a model-only approach, as shown in the right side of Figure 2-6, developers use models primarily to understand the business or the solution domain. In other situations models can be used for analyzing the architecture of a proposed solution. Furthermore, these models are also used as the basis for discussion, communication and analysis within a single organization, or across multi-organizational projects [9].

20

NTNU

Composition of UML collaborations

In connection with this, several viewpoints are made with a view to show different aspects of a system according to what the desire is. These viewpoints are explained in the next section. 2.3.1 Model-Driven Architecture viewpoints A viewpoint is a technique for abstraction, using a selected set of architectural concepts and structuring rules, in order to focus on particular concerns within that system, cf. the point illustrated previously in Figure 2-1 and Figure 2-1 [25]. ODP, which is described in Appendix A, defines a viewpoint as [23]: “… a subdivision of the specification of a complete system, established to bring together those particular pieces of information relevant to some particular area of concern during the design of the system”. Different viewpoint models make it possible to represent a system from many different viewpoints or perspectives. This is related to the fact that stakeholders of a system do not form a uniform group with the same interests, but they have different approaches on the system. The opportunity to represent a system from different angles using different viewpoints is because of this an essential capability. MDA defines three different viewpoints that are going to be used in different phases of the development process. Each phase makes different demands on which aspects of a system that are important. The viewpoints are called the computation independent viewpoint, the platform independent viewpoint and the platform specific viewpoint. Each of these viewpoints is represented with a corresponding model that is explained next. 2.3.1.1 The Computation Independent Model A computation independent model (CIM) focuses on the system environment. The purpose is to help specifying the functional requirements of a system [25]. Often a CIM is also called a domain model, and it is primarily used as a means of communication between developers and others, probably customers and users, so that they can achieve a common understanding of the purpose of the system to be developed. This is also the reason why a CIM is not involved in modelling the structure of a system, because it will interfere with the aim of focusing on functional requirements. All in all, a CIM constitutes the specification of a system. ISO and ITU have adopted five different viewpoints for specification of Open Distributed Processing (ODP) systems. The viewpoints of ODP are described in more details in Appendix A. Related to the CIM, two of these viewpoints, namely the enterprise and information viewpoint specifications might be parts of a CIM [25].

21

NTNU

Composition of UML collaborations

2.3.1.2 The Platform Independent Model A platform independent model (PIM) focuses on the operation of a system by modelling its structure, but does not relate it to any specific platform [25]. As a modelling language, one can use standard UML notation to describe the behaviour as precisely and understandable as possible. It is important to be aware of the fact that a PIM is a complete view of a system, meaning all the requirements must be realized in the model. This also makes it possible to do a test of the system’s functionality before going any further in the development process. The advantage of discovering errors or incomplete functionality at this stage is very cost-effective compared to doing error correction at a later stage. Today, there exist tools [37] supporting such kind of functionality testing on systems described in the specification and description language (SDL) [11]. Again, related to ODP, a PIM might consist of enterprise, information and computational viewpoint specifications [25]. 2.3.1.3 The Platform Specific Model A platform specific model (PSM) is a combination of a PIM and details related to a platform. In other words, a PSM is a transformation of a PIM, showing how the system is realized on a platform. This represents a great advantage of MDA, because the PIM itself does not say anything about how a system is carried out at a specific platform. 2.3.2 Transformation The transition of one type of a model into a new type is, in the context of MDA, called a transformation. There exist mainly two types of transformations. The first is the transformation of a PIM into a PSM. The other one is the transformation of a PIM directly to code [25]. A transformation can take place in three different ways; manually, automatically or as a combination of the two. Also related to the ARTS project, introduced in chapter 1, the last method is of current interest. Parts of the transformation are done automatically, but some parts require manually inputs. For instance, it is possible to completely transform a PIM into code directly, or at least parts of it. This is possible by marking a PIM with socalled stereotypes from a UML-profile and also describing how to take into account which platform that is used by doing a mapping. Then it is possible to use a tool when performing the transformation.

22

NTNU

Composition of UML collaborations

2.4 RUP and MDA As mentioned introductorily, RUP reflects current industry best practice. New approaches on service engineering are typically not included in RUP before they are well established within the field [10]. The Model-Driven Architecture (MDA) is a rather new approach on service engineering, which purpose is to use models in software engineering development [25]. Because it is still considered as something new, it is not yet integrated in the overall RUP process. However, as stated in [10], RUP is highly consistent with MDA. The architecture-centric and iterative development process of RUP offers a basis for succeeding with MDA, and based on this, it is reason to believe that RUP in some years will provide specific guidance on how to integrate MDA.

23

NTNU

Composition of UML collaborations

3 Unified Modelling Language The Unified Modelling Language (UML) is a visual modelling language that is well suited for modelling static structures and dynamic behaviour. It can be used as a means to specify, visualize, construct and document the artefacts of a software system, according to the UML Reference Manual [31] p. 3. Furthermore, the UML allows developers to communicate requirements, architectures and designs with a standardized language, as argued by [39]. The UML was originally created by Rational Software, but has now become a standard accepted by the Object Management Group (OMG) [39]. The newest version of the UML, UML 2.0, was then adopted by OMG at the end of 2004. This release is especially seen as good news for developers in the telecom domain, by the very fact that it is now more influenced by standards like the Message Sequence Chart (MSC) and the Specification and Description Language (SDL) from the International Telecommunication Union (ITU) than before [31]. This chapter is primarily based on [31] and gives a brief presentation of UML collaborations of UML 2.0. However, the uses of some other concepts are assumed to be well known and are therefore not described any further. In any case, for a more detailed description of UML 2.0, the reader is referred to the UML Reference Manual [31].

3.1 What is behaviour? The service to be described in chapter 7 is modelled in a behavioural fashion using the UML notation. A general definition of the concept of behaviour is given in [31]: Behaviour is implemented by groups of objects that exchange messages within a context to accomplish a purpose. This definition is almost the same as the definition by [11] for a discrete system: The behaviour of a system is the development of states and state transitions generated by actions of the system during the time interval it is studied. In other words, behaviour comes into being when two or more objects have some sort of interaction with each other. The focus in this connection, is behaviour modelling, as defined in [28]: •

Behaviour modelling: describes how objects interact with each other. The notation can be use cases, message sequence diagrams, collaboration diagrams, state charts and activity diagrams.

24

NTNU

Composition of UML collaborations

Related to the section about MDA in the previous chapter, the next question is then to decide how to model behaviour in the most useful way? The intention of this assignment is to specify service behaviour, primarily by using the concept of UML collaborations. This concept provides some properties that suit the area of compositional service specification in a reasonable way. According to [33], one advantage of considering a service as a collaboration is that one does not need to bind the participating roles to classes. That allows developers to view a service as a behavioural component of its own. From the author’s viewpoint, this also corresponds with the main intention of MDA.

3.2 Collaboration diagram A collaboration is a description of behaviour among a set of objects that work together to fulfil some purpose, possibly within a limited space of time. Figure 3-1 shows an example of a collaboration between two role instances A and B, of type Seller and Buyer respectively.

Figure 3-1: Collaboration definition

The notation of a collaboration is standardized in UML 2.0 as a dashed ellipse with two compartments; a top compartment and a bottom compartment. The name of the collaboration is shown in the top compartment, while its structure is shown in the bottom compartment. The structure consists of role icons, shown as a rectangle, connected by connectors. Also a goal description can be included in the bottom compartment, as shown in Figure 3-1. The object types do not necessarily map directly to specific classes, but the objects represent different roles which the instances play. A role is a description of a participant in an interaction. An interaction is basically a sequence of messages within a collaboration [31] p. 247. Different roles are related to each other through connectors which represent descriptions of associations among roles. In a way, connectors define communication paths among roles and establish relationships between roles. However, it is worth noticing that the relationships, or the connectors, between roles are only meaningful inside a particular 25

NTNU

Composition of UML collaborations

collaboration instance. This has to do with the fact that relations defined by a collaboration are restricted to a context. Outside of that context the relations are meaningless. The different objects inside a collaboration definition may participate in other collaboration definitions as well, playing different roles. It is even possible for an object to play different roles in the same collaboration. For instance, a buyer and a seller may both be of the type person, but these two roles may still co-exist in the same collaboration. Furthermore, a bound collaboration is called a collaboration use. For instance, roles can be bound to a larger collaboration, as shown in Figure 3-2. A collaboration use is shown as a dashed ellipse containing an instance name of the particular use and in addition the name of the collaboration definition.

Figure 3-2: Collaboration use, refined

As illustrated in Figure 3-2, the Sale collaboration from Figure 3-1 are bound to two roles of the collaboration called CompanySale. This has many advantages when it comes to system design. Probably one of the best advantages is that it helps making the design more modular because of the reusable aspect. In that way, a collaboration definition can be seen as an independent reusable unit which is possible to nest into other collaborations. That will also be useful when collaborations must bind several other collaboration definitions. This is the case in chapter 7, when several collaborations are specified. Another capability of collaborations is the ability to express them at various levels of granularity. By refining collaborations one can produce collaborations that have a finer granularity. For instance, Figure 3-2 represents a refinement of Figure 3-3, which does not describe collaborations uses that the CompanySale collaboration contains.

26

NTNU

Composition of UML collaborations

Figure 3-3: Collaboration use

According to Sanders et al. [33], UML collaborations are very applicable because they allow to express both structural relationships as well as behavioural aspects. This is connected with the fact that UML collaborations inherit from both structure classifiers and behaviour classifiers. A classifier is in [31] defined as a model element that describes behavioural and structural features. It can for instance be an actor, a class or a collaboration, among other things. However, as argued by [33], the UML standard and the reference book [31] provide few guidelines on how the behaviour of a collaboration is to be described. As a consequence of this, the author will base his work with UML collaborations on the suggestions in [33] when the UML standard has shortcomings. The suggestions are based on using state machines and sequence diagrams to describe collaboration behaviour. As the concept of collaboration has been rearranged in UML 2.0 compared to previous versions, a short clarification is necessary just to call attention to the changes. A collaboration is now treated as a kind of structured classifier containing parts that represent roles. This also means that the terms classifier role, association role and association end role are no longer necessary. In addition, there is now a separation between the collaboration itself and the interaction, which is also referred to as the static structure and the dynamic structure, respectively.

27

NTNU

Composition of UML collaborations

4 Role playing The increased focus on time-to-market and development costs claims for efficient design methods. But the collaboration between developers and users is often hampered by the fact that they speak different “languages”. This chapter gives an introduction to the concepts of role playing and paper prototyping, and describes how they can be included in system engineering to establish a common ground between developers and users. In this relation, the focus is especially on drawing parallels between the concepts of role that appear in both role playing and UML collaborations. The intention is then to utilize role playing to be able to model UML collaborations in a better and more intuitive way. Even so, role playing can have different meanings in different contexts. Just to avoid any misunderstandings, in this chapter a role playing is primarily connected to the dramatization of a scenario. But in chapter 6 for instance, a role play is connected to the behaviour of a specific software component.

4.1 Role playing in the design process The communication problem among users, customers and developers, mentioned introductorily, is also mentioned in [11]. [11] states that quality depends on clear communication among the different actors, shown in Figure 4-1.

Figure 4-1: Communication problem, modified from [11]

28

NTNU

Composition of UML collaborations

Figure 4-2 shows a visualization of the part of the service development process that forms customer and users requirements into models.

Figure 4-2: Development process

As shown in the figure, the first stage (1) represents the interaction between the developer and the user. Many different techniques may be used as a means to make users and developers understand each other. In this relation role playing and paper prototyping are described because they may be supplements to the work of identifying service behaviour. For instance, role playing may be in help of identifying different roles and their relations, based on general case scenarios. The second stage (2) is the transformation of the emerged requirements into models. Also, there exist a lot of different models to be used, but in this assignment it is primarily UML collaborations that are of interest. One possibly advantage is that the developer has already introduced a role-oriented mindset about the service functionality in stage 1, and that may make the process of transforming general scenarios into UML collaborations both easier and more obvious, because they contain objects representing roles. For the same reason, the models themselves may also be more understandable for customers and users in the iterative design process as they are already familiar with the mindset about roles. In other words, role playing may make it more intuitive to create models by UML collaborations if the designer can think about roles through the whole developing process.

4.2 Scenarios Role playing usually is a result of dramatizing scenarios, which are by many proposed as a means for designers to explore design artefacts in a simulated use context [6]. The main intention of scenarios is to give a partial description of system usage as seen by its users or by related systems, as argued by [30]. An almost similar definition is provided by Muller [26]. She states that, “…we think of a scenario as a story that one person (or group of people) can tell to another, and that describes human work, human collaboration 29

NTNU

Composition of UML collaborations

or human activities (with or without computers).” Furthermore, Amyot et al. also gives an explanation of a scenario [1]: “Scenarios are known to help describing functional requirements, uncovering hidden requirements and trade-offs, as well as validating and verifying requirements.” This means that scenarios give precise descriptions of functional requirements, as well as driving the design and the evolution of systems further on by causing a better understanding of the problem to be solved. However, as argued by [1], in many cases it can be difficult to give an exact definition of what a scenario is, mostly because it may vary depending on used semantics and notations. Sometimes one wants to use more formal notations, like for instance use cases [14] or just prose descriptions like Muller proposed in the previous paragraph. In the following, the term scenario is connected to prose descriptions if nothing else is mentioned. Such descriptions can be related to different working tasks, and may be very descriptive at some tasks, and at the same time being less descriptive at other parts with the intention of letting users add new details on the way. That allows for discovering new ways of performing different tasks. Furtermore, [1] states that by using scenarios as a means of obtaining goals or properties when the system understanding is in its infancy, proves to be a good usage. Usually, expressing goals and requirements of a system can be difficult to do in an abstract way, and is a frequent problem facing developers. This also means that scenarios can have several objectives. In some situations they must cover all system functions in advance, in other situations they just serve the generation of new ideas, as pointed out in [20]. In [1] some benefits and drawbacks related to scenarios are listed, some of them cited here: Benefits: • • • •

Scenarios are intuitive and relate closely to the requirements. Different stakeholders, such as developers and users, can understand them. They can be introduced in iterative and incremental design processes. They can abstract from the underlying system structure, if necessary (for instance when developing a platform-independent standard). They are most useful for documentation and communication.

Drawbacks: • • •

Since scenarios are partial representations, completeness and consistency of a set of scenarios are difficult to assess, especially when the scenarios are not described at a uniform abstraction level. Scenarios are often unable to express many non-functional requirements other than by giving examples or instances. Scenarios often leave required properties about the intended system implicit. 30

NTNU •

Composition of UML collaborations Getting and maintaining the right granularity for the scenarios can be a real challenge.

According to [1], it is difficult to express many non-functional requirements. This is maybe not true in every situation and is also dependent on the chosen notation. For instance, by using prose descriptions it is possible to say something about expected response time or other quality attributes, especially related to usability2.

4.3 Paper prototyping Participatory design is an approach which focuses on exploring new perspectives of a system by involving users in the design work. According to Brandt and Grunnet [8], different techniques might be used. They suggest role playing as a valuable contribute to design, as it may result in useful insight connected to the performance of tasks. Several experiments have been done with a view to learn how to best utilize role playing in system design. For instance, by using so-called low-fi prototypes (paper prototypes), users can be involved in the design of for instance PDA-based computer systems through role playing. The advantage of such acting is that they have the effect of initiating a dialogue about design ideas between developers and users [36]. When modeling services as compositions of collaborating roles, paper prototyping may be an effective way of revealing new aspects of connections between the roles, as well as new roles that was not considered in the first place. The main idea of paper prototyping is to use hand-sketched drafts of windows, menus, etc. to simulate for instance mobile devices. Users then play different roles with reference to a given scenario, at the same time as they make use of the paper prototypes as a means of executing their mission of the scenario. Developers then observe how they manage to accomplish given tasks according to the scenarios, as stated in [35]. In general, paper prototyping is suited to gather data about a series of problems [35]: • • • • •

Concepts and terminology Navigation/workflow Content Page layout Functionality

What is most relevant in this connection is gathering data about functionality, which is related to requirements engineering. For instance by helping developers to discover missing functionality, or planned functionality that users actually do not care about [35]. Furthermore, paper prototyping may also help developers to discover new relations between the participants, relations which might have been overlooked earlier on. In other situations, when the scenarios are insufficient, the participants are “forced” to make their 2

Usability is one out of many so-called quality attributes or non functional requirements [4].

31

NTNU

Composition of UML collaborations

requirements explicit. Paper prototyping may in such cases also be a positive contribution to the developers. Paper prototyping has some limitations and shortcomings too. As argued by [35], it is not well suited to reveal capabilities like: • •

Technical feasibility Download time or other response time

It is worth noticing that a paper prototype does not say much about non functional requirements like download time and response time. However, used in combination with role playing, the author thinks that some non functional requirements may still be identified. For instance, an actor may give guiding on how long a reasonable response time should be, during the role playing. Another limitation is that parts of a system are difficult to include in role playing. Like for instance behaviour of a message server. The author has neither found any references speaking of such cases. This indicates that it is possibly most customary to play out scenarios that only look at what happens between different users, and then abstract other parts. In this assignment it has been chosen not to perform a real paper prototyping with users involved. Anyway, a small example is worked out just to illustrate some main points about paper prototyping. The example is described in the next section.

4.4 An example on paper prototyping Based on a given scenario from a hospital environment, the author will work out a simple example showing how paper prototyping can be performed. The objective is to relate the outcome of that, possibly some requirements and knowledge about information and communication flows between the participants, to specify collaborations. The collaborations may then also be more understandable for the users in the following developing process. Getting positive returns of practicing paper prototyping assumes careful observation. Developers must observe and analyze what happens during the role playing sessions. As stated, the following paper prototyping is not worked out with any real participants, it is more interesting to focus on the methodology itself and how it works in combination with more formal design practices. The following procedure follows the procedure from the paper prototyping example presented by Seland in [34]. 4.4.1 Service objective

32

NTNU

Composition of UML collaborations

The objective is to design a group communication service helping nurses to cooperate in a better way. This will be achieved by providing functionality allowing to announce context information and support message passing between healthcare workers. 4.4.2 Scenarios from Stroke Unit The given scenarios are partly from [34], a little simplified, and partly motivated from [21]. They serve as starting points in creating paper prototypes and performing role playing with the intention to bring up some requirements. The participating users are free to create the paper prototypes as they want, but they must limit themselves to the available technology. Scenario - A patient with breathing problem: A 55 year old woman is hospitalized at St. Olavs Hospital with chronic breathing problems. It turns out that she is a smoker with asthma. The breathing problems have lasted in several months, but have increased in intensity the last week. The patient is placed in a room at the Stroke Unit. Three scenarios then take place at the hospital ward: 1. Help scenario: The patient is in her bed when she is calling a nurse who is called Alice. She needs to go to the bathroom, but because of her breathing problems she needs assistance. Alice, the assisting nurse, does not manage to help the patient at her own, so she has to call for a second assisting nurse to help her with the patient. 2. Emergency scenario: One of the nurses is assisting the patient in her bed. While she is presence the patient gets in a much worse condition. She realizes that it is an emergency and must call for assistance. 3. Information scenario: The patient has not been able to eat customary food because of her breathing problems and her lack of speech. The nurse on duty wants to give a short report about this to the next nurse on duty assisting this patient. Available technology: • •

Both nurses and doctors have access to a Personal Digital Assistant (PDA) which they carry with them. Every hospital worker can be positioned inside the hospital.

33

NTNU

Composition of UML collaborations

4.4.3 Outcome The possibly outcome of the procedure is some sketched paper prototypes by the participating users. The paper prototypes give the users the opportunity to clarify their requirements in a clear way, especially requirements related to usability. The prototypes will in that way be adapted as much as possible to the tasks to be performed during the dramatization.

Figure 4-3: Example of a paper prototype

Figure 4-3 shows how a graphical user interface of the service can look like. Three buttons are illustrated, one for help, emergency and information. This may indicate some non functional requirements related to usability. For instance, both help messages, emergency messages and information messages must be sent by just pressing one button each time. In that way, the paper prototype expresses that the service must require minimal amount of interaction in daily use. 4.4.4 Observations from developers Developers must observe what the participating users do during the role playing. It can be things like what they want their paper prototype to do in different situations, or what information they need from their devices. In [34], it is stated that the developers felt it was easier to understand the requirements as a result of the role playing. 4.4.5 Functional requirements On the basis of the paper prototypes and the observations, developers can form new future scenarios of how specific tasks can be performed. This will again help specifying the exact requirements of a system, which can then be modeled as collaborations.

34

NTNU

Composition of UML collaborations

The scenarios that could be created on the basis of the observations are described next. But because no observations were done in real, some possible future scenarios, also used in the former project assignment by the author [21], are repeated next: Future scenario 1: Helping a patient: Alice, a nurse in the Stroke Unit, needs help to move the patient in Room 333. Alice uses a help-button on her handheld device to automatically generate a message like “Alice needs help in room 333”. The message is immediately sent to another healthcare worker. While she is waiting, she is helping the patient with other matters of necessities. Nurse assistant Charlie is answering the message on his terminal and is arriving room 333 three minutes later. Alice and Charlie are ready to move the patient. Future scenario 2: Emergency The nurse assistant Charlie is looking after the patient in room 333. Suddenly the patient gets a cardiac arrest. Charlie uses a button on his handheld device with the message “Emergency”. Only four nurses will receive the emergency message with sound on their handheld device. The message also informs about the room number of the emergency. Future scenario 3: Sending and receiving information based on context. Alice is checking a patient, who is a newly arrived. The patient has a lack of appetite and is not able to speak very well either. Alice manages to find out that the only thing the patient wants of food is a special protein drink. To insure that he also gets such a drink in the afternoon, she wants to send a reminder to one of the nurse assisting the patient on the next shift. She generates a message that is to be sent to the first nurse entering room 333 after six pm. When the nurse assistant Anne enters room 333 at half past six, she receives the message saying what type of food the patient prefers. Based on the scenarios, several functional requirements are described, the same as in [21]. They are quoted in Appendix C. They will be the basis for creating models in chapter 7. To read more about practical accomplishment of paper prototyping the reader is referred to [36].

35

NTNU

Composition of UML collaborations

5 Service composition The core idea of service composition is to compose services out of smaller elementary components. This corresponds with the philosophy of the service-oriented view, which was introduced in chapter 2. This chapter relates service composition to actors and roles, and arguments for using UML collaborations when modelling service composition with a service-oriented approach.

5.1 Definitions To avoid any misunderstandings or confusion, some effort will be put on explaining the meaning of both “service” and “composition”. Referring to chapter 3, roles define elementary behaviour. A service feature is a result of combining different elementary roles and making them collaborate [16]. Based on this definition one can identify some general fundamental properties of a service, as identified in [33]: • • •

A service is a partial functionality. It can be combined with other services to provide the full functionality offered to a user. A service execution normally involves several collaborating components. Some components need to participate in several services.

Bræk identifies two different natures of services in [13]. The first one is services following the client-server pattern, as shown in Figure 5-1. The second one is peer-topeer services, shown in Figure 5-2.

Figure 5-1: Client-server, from [13]

36

NTNU

Composition of UML collaborations

Figure 5-2: Peer-to-peer, from [13]

Peer-to-peer services are, according to Bræk, more relevant to the telecom domain than the first one, as they allow for multi-way initiatives. However, a client-server service can be considered just as a special case of a peer-to-peer service. Composition is the other concept to be defined. In fact, service composition is a concept widely known, but usually it has another angle of attack. Traditionally, process algebra is used as a language to express compositions, as described briefly in Appendix B. In this relation the concept is a little expanded. Services can still be described with process algebra, but one also wants to think of it more like visible objects that can be visualized with models. In connection with this, the concept of a service has to be decomposed into smaller components, namely actors and roles. As stated in [13]: • • •

A service is a collaboration among several actors. An actor may be involved in several services. An actor is able to play different roles.

The concept about actors and roles correspond with the same concept which will be described in the next chapter about ServiceFrame. Based on the definitions, the goal is to model services by composing different actors. This is shown in Figure 5-3.

Figure 5-3: Composition, from [13]

37

NTNU

Composition of UML collaborations

The vertical axis shows composition within an actor, while the horizontal axis shows the composition of actors within a service. The horizontal axis also represents the distribution of the system, both physically and logically [32]. To be concrete, this means that actors may belong to service providers that are physically apart from each other or functionality that is distributed among logical separate actors. A specific actor represents some specific behaviour. It is therefore more accurate to refer to it as behavioural composition, because building services by combining other small services together is seen as a very compositional approach, as is also argued by [33]. One advantage of behavioural composition is that it can be used as a means to achieve modularity and adaptability [16], mostly because components that are composed into new services can be considered as independent of each other in the beginning. However, the advantage of adopting such a compositional approach on service engineering is also connected to the fact that role collaborations focus on behaviours across systems boundaries [16]. Furthermore, it is generally true that reuse of system components is sooner connected to a slice of behaviour, like the invite feature previously mentioned, rather than reuse of specific classes, and therefore makes it practical and meaningful to model the system in a behavioural view [16]. A behavioural view is in many ways the same as was identified as a service-oriented view in chapter 2.

5.2 Service composition by UML collaboration The definitions of behaviour, as stated in chapter 3, are relevant in connection with behavioural composition. In this section it is discussed how behavioural composition can be achieved by using UML collaborations. An elementary role is actually easier to explain if one can relate it to an example, for instance a generally known basic call service. One of the service features provided by such a service is an Invite feature. Providing this feature requires collaboration between different service roles, following a rather standard pattern. By modelling only this collaboration one can abstract unessential details that are of no interest at this stage, as for instance detailed design decisions. Collaborations also represent another way of presenting and discussing functionality with the customer because the collaborations may be more intuitive compared to for instance message sequence diagrams (MSCs). This may again be referred to the communication problem described in section 4.1. When it is decided to model services with behavioural composition, the next question is to determine which notation is the best. Several conditions must be considered, for instance, how can collisions between different roles be discovered, preferably at the earliest stage as possible? This modelling task can be related to the CIM of the MDA,

38

NTNU

Composition of UML collaborations

described in chapter 2. The point is that the collaborations shall be a part of the service specification, which among other things can serve as a visual communication medium between developers, customers and users. The specification can also be in help revealing weak points, discovering reusable features at an early stage in the development process or enabling capability checking and validation of the composition. UML collaborations, as was introduced in chapter 3, makes it possible to model services as collaborations. Such a modelling approach is a bit collaboration-oriented, and therefore UML 2.0 collaborations are advantageous because of several reasons [33]: • •

• •

The concept corresponds closely with the definition of a service as collaboration between roles. Using collaborations as part of the specification support both system designers and end-users because they represent a preferred view for all of them. This also makes UML 2.0 collaborations well fitted as a communication medium between the designers and the customers in the development process. Support the so-called semantic interfaces which define the visible interface behaviour and the goals of the collaboration. Collaborations make it possible to focus on behaviour across objects [12].

In [13] it is also stated that UML 2.0 collaborations “…enable services to be defined separately in terms of role structures and behaviours.” Furthermore, [33] states that semantic interfaces, which will be defined in the next section, can be made operational by collaborations. 5.2.1 Method As mentioned in chapter 3, the UML standard has some shortcomings when it comes to determining how behaviour of a collaboration can be described for the purpose of service specification. The method proposed in [33] will be cited here and serve as a guide when modelling with UML collaborations in chapter 7. Four points have to be considered: 1. 2. 3. 4.

Collaboration structures Collaboration goals Collaboration behaviour Semantic interfaces and compatibility

The first item on the list defines the structure of collaborations that together provide the service. This stage requires roles to be identified, before describing how they interact with each other. The result of this stage is possibly several collaboration diagrams specifying the structure of the collaborations that provide the service. The second item deals with goals. Identifying and expressing goals is a rather complex task of service composition. Expressing precise goals, in an easily understood way is still an area of research. Expressing advanced goals will not be the main focus in this

39

NTNU

Composition of UML collaborations

assignment, but the author will only focus on expressing the positive goals of the collaborations. Third, the behaviour of collaborations will be described by using state diagrams and sequence diagrams showing the detailed interactions of the collaborations. State diagrams show states of a collaboration and the relation between the states. However, it is important to be aware of the fact that the states of a collaboration are not connected to instantiated objects of any kind. Such states are only an expressing of the combined states of the roles involved in the collaboration, meaning no entity actually finds oneself in a collaboration state. The states of collaborations exist only in an abstract way. Sequence diagrams show message interactions for collaborations. Such diagrams are only meant to be partial descriptions, primarily showing the successful cases leading to the achievement of service goals. Like the state diagrams of collaborations, sequence diagrams are abstract in the way that they are not implemented directly. The diagrams serve more as overview descriptions of the service. As pointed out in [32], the descriptions mentioned in the two previous paragraphs are not necessarily complete. If that was the case, the behaviour description must have included all interactions of a component over all interfaces, which is more complex than required. Typically, only the behaviour over some chosen interfaces is described. This behaviour is called the interface role behaviour [32]. This leads to the fourth item which is about semantic interfaces and compatibility. A semantic interface is defined as [32]: “…a collaboration including the role behaviour of the participating components and the progress goals that should be reached by the collaboration.” Simplified, one can say that the purpose of semantic interfaces is to describe both the required and the provided behaviour of roles [33]. When it comes to the concept of compatibility, a specific classifier, for instance a UserAgent, playing two roles must have visible interface behaviour that is compatible with the interface behaviour of both roles. In addition, the classifier must also be compatible with the service goals of the collaboration, which is also pointed out in [33].

40

NTNU

Composition of UML collaborations

6 Service creation framework The development process has so far described how developers can form functional requirements into models. The next step is to describe how the models can be used to create a design. ServiceFrame is a framework supporting service creation, service deployment and service execution. This chapter introduces ServiceFrame and ActorFrame in a brief manner and mainly builds on the ServiceFrame Whitepaper [12], ActorFrame Developers Guide [24] and the RAM architecture reference [19]. For more information about the design framework, the reader is referred to the referenced literature. At the end of this chapter some remarks are given with a view to transform collaborations into actor design.

6.1 ServiceFrame objectives ServiceFrame is an application server in the service network [24]. The main objective of the ServiceFrame project is to enable rapid service development of advanced, hybrid and personalized services without sacrificing the quality [12]. This will be achieved through the following sub goals: • • • • •

Enable model-driven service development using UML2.0 to achieve both short time to market and controlled quality Enable horizontal, end-to-end, services and the widest possible range of advanced hybrid services Provide architectural support for incremental service development and deployment Support personalized services and mobility Serve as a test case for UML 2.0

Advanced services mean a combination of traditional tele-services, multimedia services, web- and information services, messaging services and personalized-, location- and context-aware services. Hybrid services mean services that are provided across heterogeneous networks such as PSTN, IP, GSM and UMTS. These networks may be provided by different service providers like for instance Telenor. The objective of ServiceFrame is possible to obtain, by the very fact that the industry is moving away from the vertically integrated networks towards horizontally layered networks. Then it is possible to locate service control in its own service network.

41

NTNU

Composition of UML collaborations

ServiceFrame is a service-centered approach. This means that the focus is on serving the environment, and not system and network specific aspects. As opposed to for instance the Intelligent Network (IN) which defines a basic call control as a core service that other services run on top of, the ServiceFrame has no assumptions about such specific services. In ServiceFrame, functionality like basic call control from IN is treated as a service itself, among other services. The advantage of this approach is that it opens to a much wider range of services than the traditional IN; and this is what underlies the service-centered approach. ServiceFrame is an application of ActorFrame, which is a framework that supports Actors and Roles. Both of the frameworks are implemented in Java, using JavaFrame. The great advantage of JavaFrame is that it provides support for asynchronously communicating state machines. Then service developers can concentrate on modeling the service functionality without considering technicalities that are not service specific, like low level implementation details. As illustrated in Figure 6-1, the three layers, JavaFrame, ActorFrame and ServiceFrame, form an architectural support for service creation, service deployment and service execution.

Figure 6-1: Layers, from [12]

The topmost layer in Figure 6-1 is the Application layer, which allows applications to use services provided on the ServiceFrame layer, for instance, a Location Tracker Service. Also note that services on the ServiceFrame layer can be provided to many applications at the same time. A service itself is an application of ServiceFrame that are defined by specializing and instantiating Actors and by defining and deploying Roles, provided by ActorFrame. These concepts are described in the next section.

42

NTNU

Composition of UML collaborations

6.2 ActorFrame The implementation of ActorFrame is called EJBActorFrame because ActorFrame is implemented using the Enterprise Java Beans (EJB). The concepts of EJBActorFrame are described in the following section. An actor is an object having a state machine and an optional inner structure of Actors, as shown in Figure 6-2. The state machine defines the generic behaviour common to all actors and the inner actors define the roles to play for an instantiated Actor. All actors start to play an initial role when they are created. A role is the part that an actor plays in a service. This supports the approach of service composition with roles, described in chapter 5. The fact that an Actor may consist of several inner Actors makes it possible for an Actor to play different roles, in different situations.

Figure 6-2: Actor, from [24]

Other actors in the system can request an actor to play a role, by using the so-called RoleRequest Protocol defined in ActorFrame. If the requested actor is able to play the requested role, it creates an inner actor to handle the role request, and to play with the requestor. If not, the RoleRequest is denied, also by using the RoleRequest Protocol. As well as roles and plays can be created, they can also be ended. This means that the lifetime of actors, roles and plays can be different. For example, the initial role does not stop playing until the enclosing actor is ended, even though inner actors can be created and ended in the meantime.

6.3 The RAM Architecture The Role and Actor Modeling (RAM) architecture is a conceptual model that is implemented on top of the EJBActorFrame platform.

43

NTNU

Composition of UML collaborations

The RAM architecture supports the provision of services by means of actors and roles. The provision of a service is a result of collaboration among actors that play appropriate service-roles Environment mirroring is one of the principles behind RAM. RAM uses a special kind of actors, called agents, to mirror entities in the environment. An agent knows relevant data about the entity it represent. For instance, UserAgent and TerminalAgent mirror a user and a terminal respectively. A UserAgent usually knows data about a specific user, like for instance username and password. In the RAM architecture an Agent consists of two types of inner parts: session-roles and service-roles, as shown in Figure 6-3. In principle they are standard actors, but with different purposes. A session-role handles service session requests to create inner serviceroles. It also informs about capabilities of the actor to other actors. An actor can contain several session-roles in case it wants to participate in several sessions with other actors. A service-role dictates the behavior of the actor in the provision of a service.

Figure 6-3: Actor, from [19]

6.4 Transforming collaborations into actor design As described in chapter 2 about MDA, a CIM can to be transformed into a PIM. In this relation it is of interest to consider how UML collaborations can be used, or transformed into for instance ActorFrame objects. It is not a straightforward task, but the question is if any common guidelines can be found. Figure 4-2 shows the developing process that end in service models represented by collaborations. But that figure only shows a part of the whole process. Figure 6-4, from [13], completes the process cycle.

44

NTNU

Composition of UML collaborations

Figure 6-4, from [13]

The figure shows that service models, represented by collaborations, can be transformed into actor models through design composition. Then the actor models can be transformed into code, possibly by automatic code generation. This was done in a former project assignment by the author [21]. The question now is rather how collaborations can be transformed into actor models? There is now clear guidelines of that aspect, but it may be possible to answer the question in more details after the collaborations are created in chapter 7.

45

NTNU

Composition of UML collaborations

7 Group communication service This chapter has for its intention to model a service by composition. The service itself was also described in chapter 4.5. The composition is based on the theory presented in chapter 5. The reader are requested to read section 4.5 to get an idea of what the service is about. In addition, the functional requirements are described in Appendix C. They will also help the reader to understand the totality that the collaborations try to model.

7.1 Service composition In order to illustrate various aspects of service composition, the functional requirements in Appendix C are supplemented by some extra requirements. These include: 1. 2. 3. 4.

creating new user groups removing user groups adding group members removing group members

The first step in the specification process is to identify and define the various collaborations that exist. The collaborations are simply called collaborations definitions. The most important thing is to pull out the most general service features that can be identified. Such basic features make it possible to reuse functionality in the further work. Each collaboration is also followed by a state diagram and a sequence diagram describing the collaboration’s behaviour. The three first collaborations are the most basic ones, in principle also valid outside the service. This means that the collaborations can be reused in several services. The Invite collaboration is partly defined in [33], but is specified here as well, a little modified in Figure 7-1. Two roles, A and B, of type Inviter and Invitee respectively, are needed to establish a connection. A connection is just what is defined as the goal of the collaboration, expressed by Connection(A, B). It is simply a logical addition of the goals of A and B [33].

46

NTNU

Composition of UML collaborations

Figure 7-1: Invite collaboration

As expected, the collaboration does not say anything about its behaviour. This must be defined by the following diagrams.

Figure 7-2: Invite state diagram

The state machine diagram in Figure 7-2 shows the different states that the collaboration can be in. Notice, that the states are not connected to one particular role, but related to the collaboration as a whole.

47

NTNU

Composition of UML collaborations

Figure 7-3 shows the sequence diagram that is related to the Invite collaboration. The states from Figure 7-2 are repeated to show how sequences are related to states.

Figure 7-3: Invite sequence diagram

The Transfer collaboration is specified as shown in Figure 7-4. Three roles participate; A, B and C, of type Original party, Controller and Third party respectively. The goal is to give A a reference to C. A transfer can be initiated by the Controller which gives A a reference to C such that a session between A and C can be established.

48

NTNU

Composition of UML collaborations

Figure 7-4: Transfer collaboration

Figure 7-5 defines the state diagram for the Transfer collaboration.

Figure 7-5: Transfer state diagram

The Transfer sequence diagram is shown in Figure 7-6.

49

NTNU

Composition of UML collaborations

Figure 7-6: Transfer sequence diagram

Figure 7-7 specifies a Communicate collaboration. Two roles are needed of type Caller and Callee, and a communication path between instances playing these roles must exist.

Figure 7-7: Communicate collaboration

Figure 7-8 and Figure 7-9 define the collaboration’s behaviour. The transition from the state “no communicating” to the state “communicating” is executed by a message from the caller to the callee.

50

NTNU

Composition of UML collaborations

Figure 7-8: Communicate state diagram

Figure 7-9: Communicate sequence diagram

The next collaboration to be specified is more service specific, although it may also be reused in other relations. Figure 7-10 shows the GroupManage collaboration, and is a presuppose to fulfil the requirements described introductorily in this section.

51

NTNU

Composition of UML collaborations

Figure 7-10: GroupManage collaboration

The related figures showing the behaviour are shown in Figure 7-11 and Figure 7-12.

Figure 7-11: GroupManage state diagram

52

NTNU

Composition of UML collaborations

Figure 7-12: GroupManage sequence diagram

Figure 7-13 shows the collaboration called CommunicateWithEmployee. Three roles participate, caller, invitee and callee, of type Employee, GroupService and Employee respectively. The goal of this collaboration is to set up communication between the caller and the callee. This is done indirectly by using a third role, the GroupService. This collaboration is a presuppose to fulfil all functional requirements in Appendix C, which all depend on communication.

53

NTNU

Composition of UML collaborations

Figure 7-13: CommunicateWithEmployee collaboration

The collaboration in Figure 7-13 can be refined to show reuse of collaboration definitions, shown in Figure 7-14. The same roles participate as in Figure 7-13, but it gives a more detailed description of what happens. The ordering of the collaboration uses are shown in the state diagram in Figure 7-15. The goal of the collaboration is to let the caller and callee communicate. Figure 7-16 shows the sequence diagram of the CommunicateWithEmployee collaboration.

Figure 7-14: CommunicateWithEmployee collaboration refined

54

NTNU

Composition of UML collaborations

Figure 7-15: CommuicateWithEmployee state diagram

Figure 7-16: CommuicateWithEmployee sequence diagram

The CommunicateWithEmployee collaboration can further be used in a new collaboration use. This is shown in Figure 7-17. The advantage of specifying a new 55

NTNU

Composition of UML collaborations

collaboration use is that this collaboration may possibly consist of more roles and collaboration uses than specified in the CommunicateWithEmployee collaboration. This proves at the same time that the use of collaborations supports the composing approach in a good way.

Figure 7-17: Communication collaboration

Figure 7-18: Communication state diagram

The Communication state diagram is shown in Figure 7-18. In Figure 7-19 the sequence diagram of this collaboration is shown, which is very simple because it just refers to the previous sequence diagram.

56

NTNU

Composition of UML collaborations

Figure 7-19: Communication sequence diagram

The Positioning collaboration, shown in Figure 7-20, consists of two roles. A requester and a PositioningService. The PositioningService is a role which provides the requester’s position. The goal is to let A know it’s own position. Figure 7-20 can also be refined to show which collaborations it uses, shown in Figure 7-21. In this case the Invite collaboration and the Communicate collaboration, as shown in Figure 7-1 and Figure 7-7 respectively, are reused. Figure 7-22 shows the state diagram of the Positioning collaboration. Figure 7-23 shows that the position must be sent from the PositioningService to the Requester in a message after entering the communicate state.

Figure 7-20: Positioning collaboration

57

NTNU

Composition of UML collaborations

Figure 7-21: Positioning collaboration refined

Figure 7-22: Positioning state diagram

58

NTNU

Composition of UML collaborations

Figure 7-23: Positioning sequence diagram

Furthermore, the Positioning collaboration is used in another collaboration as well. Figure 7-24 shows a collaboration which goal is to forward the user’s position reference to the GroupService. The order of the collaborations can be seen in Figure 7-25. This collaboration is a presuppose for the functional requirement number 2, in Appendix C.

Figure 7-24: PositionUpdate collaboration

59

NTNU

Composition of UML collaborations

Figure 7-25: PositionUpdate state diagram

Figure 7-26: PositionUpdate sequence diagram

These models then complete the specifying of the service. The collaborations’ state diagrams and sequence diagrams specifies the needed behaviour and composition needed to fulfil the functional requirements.

60

NTNU

Composition of UML collaborations

8 Discussion The previous chapters have presented possible approaches on service development, modelling notations, paper prototyping and role playing. An example service has also been worked out, first by demonstrating some core concepts about paper prototyping, and then by modelling the service in a service-oriented approach. This was mainly done by using the concept of UML collaborations, supplemented by state diagrams and sequence diagrams. This chapter discusses different aspects of service composition in section 8.1. In section 8.2 some comments are made on the advantages and drawbacks of using paper prototypes and role playing as a pre-stage before specifying services with UML collaborations. Finally, section 8.3 presents some ideas for future work on this topic. The objective of this discussion is not to give an absolute conclusion whether the approaches are reasonable or not, but to point out aspects that speak in both favour and disfavour. In that way, the findings of this assignment might also be a contribution to further work.

8.1 Service composition Service composition, as presented in this assignment, represents a somewhat new approach on service engineering. One can say that it calls for a more abstract way of thinking, because developers are forced to think of service behaviour as something that cannot necessarily be related to specific software components. In other words, it is about identifying behaviours across objects, which is connected to the idea of the serviceoriented view. As a way of achieving reusable collaborations it is desirable to define collaborations that are as general as possible. In the group communication service in chapter 7, three elementary service collaborations were identified. They described basic functionality like Invite, Transfer and Communicate, which most likely are used in many different services because of their capabilities. However, there are some limitations when it comes to what can actually be reused. Usually when talking about reusability, one thinks about for instance a reusable class or a reusable method. When it comes to the abstract nature of collaborations it is difficult to think of what can actually be reused. It is evidently not in all cases some specific code fragments, because collaborations may often be defined independent of object classes. Based on the work with specifying collaborations in chapter 7, they are more focused on reusing the structure of the behaviour. For instance, the behaviour of the Invite collaboration is described with both a state diagram and a sequence diagram. It is perhaps more likely to reuse the logical behaviour of a collaboration, than the concrete

61

NTNU

Composition of UML collaborations

implementation. This means that it is maybe only the order of states that a collaboration walks through that are reused. An arising question is then why to use collaborations. As argued in [33], collaborations allow for validation and compatibility checking. In such a way, collaborations represent a great advantage, because one can validate and ensure compatibility at an early stage in the engineering process. Semantic interfaces, as was described in chapter 5, are one capability that can be used for these objectives. As referred to in [33], semantic interfaces can be made operational by defining collaborations. However, to be able to check compatibility this probably requires tools to be able to analyze all relations between participating roles, especially when there are many collaborations. In addition, to be able to utilize all the proposed suggestions belonging to the theory about semantic interfaces, the UML standard must also be changed a bit to allow a more general description of semantic interface behaviour, as argued by [33]. In chapter 6, the transformation from collaborations to actor models was mentioned. After creating collaborations is should be easier to discuss how the transformation can be accomplished. In [33] it is stated that collaborations can influence on the design of the classes and state machines. For instance, collaborations can tell which roles a class must play over time. Furthermore, the collaborations give information of which connections must be established to reach the collaborations’ goals. This means that by summing up all collaborations one can get an idea of how a specific class must be designed. Related to the collaboration definitions specified in this assignment, such an approach mean that all role types participating in the collaborations must first be mapped to specific classes. However, such as the collaborations are defined, they allow for instance both a role of type Caller and a role of type Employee to be mapped to the same class. In this assignment the transformation is not performed, but it is evidently not a straightforward task. As described, collaborations model behaviour. When it comes to actor models, an actor also defines behaviour. If one relates an actor to ActorFrame it can be thought of as a concrete object. In this connection, roles of collaborations may in reality describe the possible behaviour of several actors. This makes it difficult to actually map these roles to actors, because roles may be difficult to split into several actor objects. However, being aware that UML collaborations represent a service-oriented view, and in that way also may be seen as complementary to an object-oriented view, it is reason to believe that collaborations may not be the only basis for transforming models towards classes. It is possible to imagine that UML collaborations at first will be used as a supplement to other sort of models. For instance, the RAM architecture, described in section 6.3, may be used in addition to UML collaborations. The RAM architecture defines actors that are easy to transform into classes, even automatically. In that way, collaborations may be used as a supplement when performing validation and ensuring compatibility.

62

NTNU

Composition of UML collaborations

8.2 Paper prototyping and role playing The paper prototyping of the service in chapter 4, showed one possible technique to cope with the communication problem between developers, customers and users. Even though it was not performed with real users, it pointed out that it may help developers to understand what to focus on. Furthermore, paper prototyping may also enable users and customers to be conscious about different roles related to the use of the service. One possible advantage of that is that the mindset about roles in collaborations may be more intuitive to understand for them when they communicate with developers. However, in many cases it will not be possible to map all roles from a role playing directly to roles participating in UML collaborations, or vice versa. This also has to do with the fact that the concept about roles in role playing is not necessarily completely transparent with the concept of roles in UML collaborations. Another important aspect of paper prototyping and role playing is the role of the developers. The importance of careful observation was mentioned in chapter 4 and may in many cases be decisive in what extent the method will be a success or not.

8.3 Future work Using UML 2.0 collaborations for compositional service specification is part of an ongoing research project at NTNU and many issues still need to be clarified. First of all, some research must be done on finding out how UML collaborations can be transformed into, for instance actor objects. Secondly, tools must be developed to support the use of UML collaboration, for instance when it comes to validation. Thirdly, it would be interesting to see how role playing and paper prototyping can be carried out in real, and then be related to the use of UML collaborations.

63

NTNU

Composition of UML collaborations

9 Conclusion This chapter concludes the findings described in this report. In order to achieve rapid software development, the service-oriented approach seems to be an important contribution. In that respect, UML collaborations represent a flexible way of modelling a service-oriented view. This is true, because one can model services partly as collaborations of several basic services. This represents an advantage because developers do not need to think of services as concrete implementation objects at an early stage. Nevertheless, it is still some vagueness of how UML collaborations are supposed to be part of a whole. There is no clear answer on whether they will replace more objectoriented models, or if they just will be a supplement in service specification. In addition, the abstract mindset is a challenge for developers, especially when there are no tools to validate the collaborations or check compatibility. The author thinks that in the nearest future, UML collaborations will serve most as a supplement enabling validation and compatibility checking. In that way, wrong or incompatible compositions can be discovered at an early stage in the developing process. Furthermore, together with paper prototyping and role playing, they can possibly serve as a contribution to decrease the communication gap between developers, customers and users.

64

NTNU

Composition of UML collaborations

10 References [1]

Amyot, D., Eberlein, A.: An Evaluation of Scenario Notations and Construction Approaches for Telecommunication Systems Development, Telecommunications Systems Journal, 24:1, p. 61-94, September 2003

[2]

Audestad, J. A.: Distributed processing in telecommunications, Department of Telematics, Tapir Akademisk Forlag, 2003

[3]

Baeten, J. C. M.: A brief history of Process Algebra, Technische Universiteit Eindhoven, Department of Computer Science, Workshop on process algebra, Bertinore, July 2003

[4]

Bass, L., Clements, P., Kazman, R.: Software Architecture in Practice, Second edition, Addison-Wesley, 2003

[5]

Bekic, H.: Towards a mathematical theory of processes. Technical Report TR 25.125, IBM Laboratory Vienna, 1971

[6]

Binder, T.: Setting the Stage for Improvised Video Scenarios, Ext. Abstracts CHI’99, p. 230-231

[7]

Booch, G., Martin, R. C., Newkirk, J.: Object Oriented Analysis and Design with Applications, 2d. ed., Addison-Wesley Longman, 1998, chapter 4

[8]

Brandt, E., Grunnet, C.: Evoking the future: Drama and props in user centered design, Proc. Participatory Design Conference (PDC’00), 11-20

[9]

Brown, A.: An introduction to Model Driven Architecture, PART I: MDA and today’s systems, IBM, January 2004, http://www106.ibm.com/developerworks/rational/library/content/RationalEdge/feb04/3100. pdf, accessed June 2005

[10] Brown, A. W., Conallen, J.: An introduction to model-driven architecture, Part III: How MDA affects the iterative development process, IBM, http://www128.ibm.com/developerworks/rational/library/may05/brown/, accessed June 2005 [11] Bræk, R., Engineering Real Time Systems, Prentice Hall, 1993, ISBN 0-13034448-6 [12] Bræk, R., Husa, K. E., Melby, G.: ServiceFrame Whitepaper, Draft 2002 [13] Bræk, R. et al.: Lecture lesson: Compositional and Model Driven Service Engineering, www., accessed June 2005 65

NTNU

Composition of UML collaborations

[14] Cockburn, A.: Lecture lesson, http://seal.ifi.unizh.ch/fileadmin/User_Filemount/Vorlesungs_Folien/SOPRA/S S05/UseCases-short.pdf, University of Zurich, Department of Informatics, accessed June 2005 [15] Dey, A. K., Abowd, G. D.: Towards a Better Understanding of Context and Context-Awareness, GVU Technical Report GIT-GVU-99-22, June 1999 [16] Flooch, J.: Using UML for architectural design of SDL systems, SINTEF Telecom and Informatics, 2000 [17] Gavras, A.: Disrtibuted Platform for Telecommunications Applications, Telektronikk 4, 2000 [18] Hamadi, R., Banatallah, B.: A Petri Net-based Model for Web Service Composition, The University of New South Wales, School of Computer Science and Engineering, Australasian Database Conference, Australian Computer Society, 2003 [19] Hansen, H., Nerbråten, F., Castejón, H. N.: RAM architecture: Quick reference, Department of Telematics, NTNU, September 2004 [20] Iacucci, G., Iacucci, C., Kuuti, K.: Imagining and experiencing in design, the role of performances, NordiCHI, October 19-23, 2002 [21] Isaksen, Ø.: Designing a group communication service to be used by nurses in a hospital ward, Department of Telematics, 2004 [22] Layzell, P.: Adressing the Software Evolution Crisis Through A ServiceOriented View of Software: A Roadmap for Software Engineering and Maintenance Research, University of Manchester Institute of Science and Technology, Proceedings of the IEEE ICSM’01, http://csdl2.computer.org/comp/proceedings/icsm/2001/1189/00/11890005.pdf, accessed June 2005 [23] Lønsethagen, H.: Introduction to RM-ODP – A Reference Model of Open Distributed Processing, Telektronikk 1, 1998 [24] Melby, G.: ActorFrame Developers Guide, Master Thesis, Norarc, August 2004 [25] Miller, J., Mukerji, J.: MDA Guide Version 1.0.1, June 2003, http://www.omg.org/docs/omg/03-06-01.pdf, accessed June 2005 [26] Muller, M. J., Catalogue of Scenario-Based Methods and Methodologies, Lotus Research, Technical report #99-06

66

NTNU

Composition of UML collaborations

[27] PATS lab: Intention and vision, www.pats.no, accessed June 2005 [28] Quartel, D., Pokraev, S., m.fl.: Analysis of Freeband Service Modelling Languages, Telematica Instituut, CTIT, GigSoft, December 2004 [29] Reeskaug, T., Wold, P., Lehne, O. A.: Working With Objects, The OOram Software Engineering Method, Manning Publications Co., 1996 [30] Regnell, B., Kimbler, K., Wesslen, A.: Improving the Use Case Driven Approach to Requirements Engineering, Proceedings of Second IEEE International Symposium on Requirements Engineering, York, U.K., March 1995, p. 40-47 [31] Rumbaugh, J., Jacobsen, I., Booch, G.: The Unified Modeling Language Reference Manual, Second Edition, Addison-Wesley, 2004 [32] Sanders, R. T., Bræk, R., Bochmann, G. von, Amyot, D.: Service Discovery and Component Reuse with Semantic Interfaces, 2005 [33] Sanders, R. T., Castejón, H. N., Krämer, F. A., Bræk, R.: Using UML 2.0 Collaborations for Compositional Service Specification, Models UML conference, 2005 [34] Seland, G.: Kreativ systemutvikling gjennom dramatisering av brukersituasjoner, Note for workshop, NTNU, May 2003, (CD) [35] Snyder, C.: Paper prototyping, IBM, http://www.snyderconsulting.net/uspaper.pdf, accessed April 2005 [36] Svanæs, D., Seland, G.: Putting the Users Center Stage: Role Playing and Lowfi Prototyping Enable End Users to Design Mobile Systems, Department of Computer and Information Science, NTNU, 2004 [37] Telelogic: Telelogic TAU SDL Suite, Telelogic, http://www.telelogic.com/products/tau/sdl/index.cfm, accessed June 2005 [38] Vliet, van H.: Software Engineering, principles and practice, John Wiley & Sons Ltd., 2001 [39] White Paper: Rational Unified Process – Best Practices for Software Development Teams, Rational Software Corporation, 1998, http://www128.ibm.com/developerworks/rational/library/may05/brown/, accessed June 2005

67

NTNU

Composition of UML collaborations

Abbreviations ARTS – Arena for Research on Advanced Telecom Services ITU – International Telecommunication Union MDA – Model-Driven Architecture MSC – Message Sequence Chart ODP – Open Distributed Processing OMG – Object Management Group RAM – Role and Actor Modelling RUP – Rational Unified Process SDL – Specification and Description Language UML – Unified Modelling Language

68

NTNU

Appendix

69

NTNU

Appendix A

APPENDIX A. 5 ODP views in 5 minutes The Reference Model of Open Distributed Processing (RM-ODP) is a conceptual framework for architectures for distributed systems. It has been standardized in the X.900 series of ITU-T Recommendations and was defined by both ISO and ITU-T. The reason to create such a standard was the need to establish a common understanding of the variety of aspects that characterize distributed systems [17]. There exist five different viewpoints for specification of ODP systems, each showing different aspects of the system. More concrete, a viewpoint in RM-ODP is defined as [23]: “… a subdivision of the specification of a complete system, established to bring together those particular pieces of information relevant to some particular area of concern during the design of the system”. The viewpoints of RM-ODP are: • • • • •

Enterprise viewpoint Information viewpoint Computational viewpoint Engineering viewpoint Technology viewpoint

This list represents a top-down approach, meaning an enterprise viewpoint is a very abstract description of a system, while the technology viewpoint gives a detailed and concrete description of the same system [2].

Enterprise viewpoint The objective of the enterprise viewpoint is to describe the overall environment in which the system is to operate. Referring to the definition of the enterprise viewpoint of ODP, its main issue is among others to identify [2]: • • • •

The purpose of the system to be modelled How the system interacts with the environment Policies that the system should support, for instance information security or protection of third parties Non-functional requirements like performance, reliability, availability, etc.

70

NTNU

Appendix A

ODP also defines the concept of domain which is related to distributed systems. A domain indicates ownership, and may for instance split a system into a user domain and a service domain. Further, interactions between different domains are called sessions. Error! Reference source not found.-1: shows an example of a two party interaction between two domains.

Figure A- 1: Enterprise viewpoint, from [2]

Information viewpoint The information viewpoint of ODP is a specification that defines [2]: • • •

The informative qualities of an ODP system Requirements for information handling in an ODP system Relationships between information bearing entities

This viewpoint concerns mainly about describing structures both in static and dynamic terms independently of how the information is distributed or who owns each information element. In short, one can say that this viewpoint is concerned with how information about the system and information contained in the system could be modelled. It is also interesting to show how the information elements are related to one another, for instance by using standard entity-relationship (ER) notation. In other cases an information model tries to specify how a system is composed. The intention is to increase the understanding of the system and how the different components are related to one another.

Figure A- 2: Information viewpoint 1, from [2]

71

NTNU

Appendix A

Computational viewpoint The computational viewpoint is concerned about how processes interact in order to perform a given task. The processes can be both software and hardware entities, meaning this viewpoint is at a stage not concerned with distinguishing between hardware and software. One can also say that the computational viewpoint describes the dynamical behaviour of the system while performing a given task. This is distinct from the information viewpoint which is concerned with the structure of information elements and the static structure of the system itself. In this case it is more interesting to describe how and when information elements are accessed and used. A computational viewpoint consists only of what is called computational objects. A computational object encapsulates data and processing. The set of capabilities offered by such an object is called a service. Each object might provide several services which other objects may use, and these services are provided through computational interfaces.

Figure A- 3: Computation viewpoint, modified from [2]

Engineering viewpoint The engineering viewpoint is concerned with control and transparency mechanisms, processing devices, memory organisation and communications capabilities. The system is described in terms of engineering objects which interact on an abstract infrastructure. Related to the computational viewpoint, the engineering viewpoint describes how the computational part of the system is distributed. In that way it represent the way in which operating systems and communications engineers look at the system. As stated in [23], the correspondence between an engineering interface and a computational interface is one-to-one. This means that a computational viewpoint is realized as one basic engineering object, except when engineering objects are replicated.

72

NTNU

Appendix A

Technology viewpoint A technology viewpoint specification is often a concrete interpretation of a specification written for the other viewpoints. This viewpoint represents how those responsible for configuration, installation and maintenance view the system [2]. The technology language is important when it comes to testing of ODP systems, but in many other situations it can be treated separately from the ODP systems development process [23].

Mapping between different viewpoints The viewpoints described in the previous sections have different significance as related to various applications or domains [23]. The information viewpoint and the computational viewpoint together, as defined, contains all functional aspects of a system. However, ODP does not prescribe any guidance on how to achieve a mapping or to ensure consistency between the two viewpoints [23]. For instance, according to [23], it may not be trivial to map the computational viewpoint and the information viewpoint to each other in a real-time telecom system. The computational viewpoint specifies many communicating components or computational objects. On the contrary, the information viewpoint usually specifies constraints related to associations among computational objects. This results in an information specification which becomes very “fragmented”. In other cases, like the case of network management, it may be simple to find correspondence between an information specification and a computational specification. The RM-ODP neither provides a methodology supporting the mapping of a computational specification onto an engineering specification [17]. This also means that it is not a straightforward task to map computational objects onto engineering objects.

73

NTNU

Appendix B

Appendix B. Service composition by process algebra A system can be defined as anything showing behaviour. Process algebra comes into the picture because it takes an algebraic approach when referring to behaviour of a system [3], and it enables one to calculate with behaviours. The use of process algebra in computer science is widely known and can be traced back to the seventies of the twentieth century [3]. Bekic, who was one of the people studying the semantics of parallel programs and how to give a denotational semantics for parallel composition at that time, made the following statement about process algebra in [5]: “Our plan to develop an algebra of processes may be viewed as a high-level approach: we are interested in how to compose complex processes from simpler (still arbitrarily complex) ones. To be able to compose processes with an algebraic approach, there was a need of some notation to express for instance concurrency and communication. Today, there exist different languages for such behaviour expressions. Petri-Nets and calculi such as Calculus of Communicating Systems (CCS) and Pi-calculus are just some examples. Just to show how composition can be done with the use of algebra, some basic notations will be shown. Two processes, P and Q, can be composed in parallel. This is usually written P|Q. Such parallel processes are allowed to proceed simultaneously and independently. They can even interact with each other, and this can be expressed by using operators. Operators are usually divided into input operators and output operators. For instance an input operator can be defined as x(v), and an output operator as x. In x(v), v plays the role as a placeholder to be substituted by data, when it arrives. An algebraic expression of interaction between the two parallel processes P and Q, may look like this: x.P | x(v).Q

P | Q(y/v)

This means that the process x.P sends a message y along the channel x, to Q. Also Web services can be modelled by using algebra. Web services often depend on other web services, hence being composite [18]. The syntax and semantics of the service algebra operators will not be described in details, but a simple example will be shown. ⊕ is an operator of alternative. Then, S1 ⊕ S2 represents a composite service that behaves as either S1 or S2. If S1 and S2 are mapped to Petri nets, the composition of S1 ⊕ S2 can be illustrated as in Figure B-1.

74

NTNU

Appendix B

Figure B- 1: : S1 ⊕ S2, from [18]

For more information about process algebra, the reader is referred to the referenced literature.

75

NTNU

Appendix C

Appendix C. Functional requirements. Based on the specific scenarios, different functional requirements (FRs) are composed and described next. FR 1 A nurse should be able to send context information to the system. FR 1.1 A nurse should be able to manually change context information like presence, role and primary group. FR 1.2 When context information is changed, a context-update message should automatically register the context information in the system. FR 2 When location changes, the context information about the user should be automatically updated. FR 3 A nurse should be able to receive context information about other nurses in the same primary group. FR 4 A nurse should be able to send a help-message to another nurse. FR 4.1 The terminal should then display a “Waiting for reply” message. FR 4.2 The requesting nurse should receive a reply. FR 4.2.1 If the request has been accepted, the terminal should display a “Help coming” message, with the name of the responder. FR 4.2.2 If no one has accepted the request, the terminal should display a message saying that no one could accept the request right now. FR 5 A nurse should be able to receive help-messages from other nurses, saying who needs help, in which room. FR 5.1 The receiving nurse should be able to accept or reject the message. FR 5.1.1 The nurse should be able to accept the help-message by pressing the “Accept” button. FR 5.1.2 The nurse should be able to reject and pass the help-message on to another nurse by pressing the “Reject” button. FR 5.1.2 If the nurse is busy and cannot answer the message, it should be rejected automatically after 10 seconds and passed on to another nurse.

76

NTNU

Appendix C

FR 6 A nurse should be able to send an emergency-message to other nurses, not in the same room as the calling nurse. FR 6.1 The terminal should then display a “Waiting for reply” message. FR 6.2 The calling nurse should receive a reply. FR 6.2.1 If the emergency-message has been accepted, the terminal should display an “Accepted” message. FR 6.2.2 If the emergency-message has not been accepted, the terminal should display a “Not accepted or detected” message. FR 7 A nurse should be able to receive emergency-messages from other nurses, saying who needs help, in which room. FR 7.1 The receiving nurse should be able to accept or reject the message. FR 7.1.1 If the requested nurse changes location, that should be taken as identification that the message is accepted. The terminal should then be able to automatically send an accepting-message to the alarming nurse. FR 7.1.2 The nurse should be able to reject and pass the emergencymessage on to another nurse by pressing the “Reject” button. FR 7.1.3 If the requested nurse do not respond at all, or does not change the location within 10 seconds, the emergency-message must be passed on to another nurse, automatically. FR 8 A nurse should be able to send an information message and specify the attributes that defines who the receiver should be. These attributes can be context of the receiver and what hour the message should be sent. FR 9 A nurse should be able to receive an information message from other nurses.

77