Model Driven Architecture (MDA) for Telecom application ... · This report discusses the Object...

Model Driven Architecture (MDA)

for Telecom application development

Tom Vasset

Tor Einar Lyngset

{vasset, lyngset}@idi.ntnu.no

Abstract This report discusses the Object Management Group’s Model Driven Architecture (MDA) and a tool supporting MDA development, Interactive Objects’s ArcStyler, for solving problems in Telecom application development. The basis for this discussion is:

• A littrature study of MDA. • A tutorial of ArcStyler. • An MDA development case study.

MDA is coined by the OMG as the next big step in solving system integration and interoperability problems. MDA is supposed to ensure:

• Portability. • Increased application reuse. • Reduced development time. • Improved application quality.

This report found the MDA capable of providing all these benefits, but that the tool support for this technology is currently immature. This was indicated by the discussion of ArcStyler, which had quite a few problems with its support for some of the key MDA concepts.

2

Preface This project was worked out at the Norwegian University of Technology and Science (NTNU), Departement of Computer and Information Science (IDI) in the period August 2002 to Desember 2002. The background for the project is Telenors involvement in the EURESCOM projects on MDA for the telecommunications domain, and especially the IST MODA-TEL project. Our participation in Telenors work on this subject is to a look at MDA and one of the few tools available that supports the MDA, Interactive Objects ArcStyler. We want to thank our two supervisors Babak Farshchian at Telenor and Associate Professor Monica Divitini at NTNU, and Sune Jakobsson and Erik Berg both at Telenor, for valuable feedback and support during the project. Trondheim, 22. November, 2002 Tom Vasset Tor Einar Lyngset

3

Table of Contents 1 Introduction .............................................................................................................................. 8

1.1 Motivation ......................................................................................................................... 8 1.2 Introducing MDA .............................................................................................................. 9 1.3 Project Context .................................................................................................................. 9 1.4 Project Description and Objectives ................................................................................... 9 1.5 Project Approach ............................................................................................................. 10 1.6 Report Structure............................................................................................................... 10

2 Survey of state-of-the-art ....................................................................................................... 12 2.1 Model Driven Architecture (MDA)................................................................................. 12

2.1.1 Why the MDA........................................................................................................... 13 2.1.2 Concepts.................................................................................................................... 13 2.1.3 Models....................................................................................................................... 15

2.1.3.1 Platform Independent Models in UML .............................................................. 17 2.1.3.2 Platform Specific Models in UML..................................................................... 17 2.1.3.3 Mapping ............................................................................................................. 19 2.1.3.4 Packages and viewpoints.................................................................................... 20

2.1.4 OMG standards in MDA........................................................................................... 21 2.1.4.1 The Core............................................................................................................. 21 2.1.4.2 Pervasive Services.............................................................................................. 21 2.1.4.3 Domain Specifications ....................................................................................... 21 2.1.4.4 Lifecycle............................................................................................................. 22 2.1.4.5 UML (Unified Modeling Language).................................................................. 23 2.1.4.6 XMI (XML Metadata Interchange).................................................................... 24 2.1.4.7 MOF (Meta Object Facility) .............................................................................. 24 2.1.4.8 CWM (Common Warehouse Metamodel) ......................................................... 24

2.2 ArcStyler.......................................................................................................................... 25 2.2.1 ArcStyler Architecture .............................................................................................. 25 2.2.2 ArcStyler 3.0 – Tool Details ..................................................................................... 26

2.2.2.1 The Chat Example.............................................................................................. 26 2.2.2.2 The Convergent Business Object Modeler (C-BOM)........................................ 27 2.2.2.3 The Convergent Refinement Assistant (C-RAS) ............................................... 31 2.2.2.4 The Convergent Refiner for Rational Rose (C-REF)......................................... 33 2.2.2.5 The Convergent Generator (C-GEN) ................................................................. 35 2.2.2.6 JBuilder support and Code customization.......................................................... 37 2.2.2.7 The Implement, Deploy and Test tool (C-IX).................................................... 38 2.2.2.8 The Convergent Generator IDE (C-GEN-IDE) ................................................. 40

3 Telenor Case Study: MDA redevelopment of InTouch ......................................................... 41 3.1 InTouch............................................................................................................................ 41 3.2 System requirements........................................................................................................ 42

3.2.1 Functional Requirements .......................................................................................... 42 3.2.2 Implementation restrictions ...................................................................................... 44

3.3 Detailed Design ............................................................................................................... 44 3.3.1 Business Model......................................................................................................... 44

4

3.3.1.1 InTouch Call Handling....................................................................................... 44 3.3.1.2 InTouch Web Configuration Portal.................................................................... 46

3.3.2 Platform Independent UML Model .......................................................................... 47 3.3.2.1 InTouch Call Handling....................................................................................... 47 3.3.2.2 InTouch Configuration Web Portal.................................................................... 48

3.3.3 Platform Spesific UML Model ................................................................................. 49 3.3.3.1 InTouch Call Handling....................................................................................... 49 3.3.3.2 InTouch Configuration Web Portal.................................................................... 50

3.4 Implementation and deployment ..................................................................................... 51 3.4.1 Architectural description........................................................................................... 51

3.4.1.1 InTouch Call Handling....................................................................................... 51 3.4.1.2 InTouch Configuration Web Portal.................................................................... 53

3.4.2 Implementation ......................................................................................................... 53 3.4.2.1 InTouch Call Handling Implementation ............................................................ 53 3.4.2.2 InTouch Web Configuration Portal Implementation ......................................... 54

3.4.3 Deployment and Testing........................................................................................... 54 3.4.3.1 InTouch Call Handling....................................................................................... 54 3.4.3.2 InTouch Web Configuration Portal.................................................................... 54

3.4.4 Technologies used..................................................................................................... 55 3.4.5 Compliance with the requirements ........................................................................... 55 3.4.6 InTouch screenshots.................................................................................................. 56

4 Discussion .............................................................................................................................. 58 4.1 MDA: Strengths and Weaknesses ................................................................................... 58

4.1.1 Strengths ................................................................................................................... 58 4.1.2 Weaknesses ............................................................................................................... 60

4.2 ArcStyler and MDA......................................................................................................... 61 4.2.1 Modeling in Arcstyler ............................................................................................... 61

4.2.1.1 Business Modeling ............................................................................................. 61 4.2.1.2 PIM and PSM..................................................................................................... 61

4.2.2 Transformations ........................................................................................................ 62 4.2.3 Code generation ........................................................................................................ 63 4.2.4 Additional MDA features ......................................................................................... 63 4.2.5 ArcStyler in general .................................................................................................. 63

5 Conclusion and further work.................................................................................................. 65 5.1 Conclusion and summary ................................................................................................ 65

5.1.1 MDA ......................................................................................................................... 65 5.1.2 ArcStyler ................................................................................................................... 66 5.1.3 Concluding remarks .................................................................................................. 66

5.2 Evaluation of contribution ............................................................................................... 66 5.3 Further work .................................................................................................................... 67

6 References .............................................................................................................................. 68 7 Appendix ................................................................................................................................ 71

7.1 Appendix A: ArcStyler Cartridges and Extensibility ...................................................... 71 7.1.1 The Cartridge Runtime Environment........................................................................ 72 7.1.2 ArcStyler Model Transformation.............................................................................. 73

5

7.1.3 CARAT – The ArcStyler Cartridge Architecture ..................................................... 74 7.1.3.1 CARAT Foundation ........................................................................................... 74 7.1.3.2 The Generatable Hierarchy ................................................................................ 76

7.1.4 Building and Extending ArcStyler Cartridges .......................................................... 77

6

List of figures Figure 2-1: Model Driven Architecture [2] .................................................................................. 12 Figure 2-2: Zooming on objects [2] .............................................................................................. 14 Figure 2-3: Zooming on interactions [2]....................................................................................... 15 Figure 2-4: Three different levels of abstraction [2]..................................................................... 16 Figure 2-5: Mapping from PIM to PSM [2].................................................................................. 17 Figure 2-6: A CORBA stereotype [2]........................................................................................... 18 Figure 2-7: Notes in UML [2]....................................................................................................... 18 Figure 2-8: Viewpoint correspondence [2] ................................................................................... 20 Figure 2-9: Refinement relation [2] .............................................................................................. 20 Figure 2-10: Sofware Development Lifecycle.............................................................................. 23 Figure 2-11: ArcStyler Core Modules [11]................................................................................... 25 Figure 2-12: ArcStyler C-BOM - CRC Diagram.......................................................................... 29 Figure 2-13: ArcStyler C-BOM – Scenario .................................................................................. 30 Figure 2-14: ArcStyler C-RAS ..................................................................................................... 32 Figure 2-15: ArcStyler C-REF (Rational Rose)........................................................................... 34 Figure 2-16: ArcStyler C-GEN..................................................................................................... 36 Figure 2-17: JBuilder .................................................................................................................... 37 Figure 2-18: ArcStyler C-IX......................................................................................................... 38 Figure 2-19: Simple Chat Application.......................................................................................... 39 Figure 2-20: ArcStyler C-GEN-IDE [11] ..................................................................................... 40 Figure 3-1: MDA Development Process....................................................................................... 41 Figure 3-2: InTouch call example................................................................................................. 42 Figure 3-3: MDA Development Process....................................................................................... 44 Figure 3-4: Creating CRC diagrams ............................................................................................. 45 Figure 3-5: Example scenario for the InTouch application .......................................................... 46 Figure 3-6: InTouch platform independent UML model.............................................................. 47 Figure 3-7: UML model of the InTouch Configuration Web Portal ............................................ 48 Figure 3-8: Activity diagram stating the page flow...................................................................... 49 Figure 3-9: InTouch PSM ............................................................................................................. 49 Figure 3-10: MDA Development Process..................................................................................... 51 Figure 3-11: InTouch Call Handling Architecture........................................................................ 51 Figure 3-12: InTouch Call Handling Architecture........................................................................ 52 Figure 3-13: InTouch Configuration Web Portal Architecture..................................................... 53 Figure 3-14: InTouch Configuration Portal, the Customer Page...................................................54 Figure 3-15: InTouch Simulator Console, Caller..........................................................................55 Figure 3-16: InTouch Simulator Console, Answer........................................................................55 Figure 4-1: MDA Development.................................................................................................... 59 Figure 7-1: Overview of Cartridge Runtime Environment........................................................... 72 Figure 7-2: Model transformation from UML to text [23] ........................................................... 73 Figure 7-3: Main Abstractions in CARAT Foundation [23] ........................................................ 75 Figure 7-4: The Generatable Hierarchy [23] ................................................................................ 76 Figure 7-5: ArcStyler C-GEN Framework (Top-Level) [23] ....................................................... 77

7

1 Introduction This introduction sets the stage for the report, describing the motivation, introducing the key technology, followed by the project context, objectives, and approach, ending with the report structure.

1.1 Motivation Market situation in telecommunication is changing rapidly due to the convergence of Internet and telephony networks and the removal of monopoly situations in many countries. This change poses great challenges and opportunities for telecommunication operators and service providers. One such challenge has been the increased competition in providing advanced value-added services to the customers. The abandoning of monopolist market models has brought with it a pressure on incumbent carriers, to make available their network resources to be used by third-party service and application providers. This creates a specialization of the telecommunication application development business that again puts pressure on both network operators and third-party application providers to optimize their development processes. Value-added services and applications in convergent networks increasingly contain a large software part, opposed to traditional telecommunication services where software played a more modest role. Application developers resort to (often complex) software solutions for accessing and deploying network resources offered by network operators. Software is also used in order to create innovative applications that make use of a mixture of network resources (e.g. applications operating transparently on both Internet and telephony networks and utilizing corporate databases). Increased competition and the innovative nature of convergent networks make it necessary to deploy development processes that allow for rapid application development so that developers can experiment with different application types without binding too much resources. Issues that have been of central importance for the software engineering community, such as reuse and object-oriented software development are becoming more and more important also in the telecommunication domain [1]. The situation in telecommunications software development today, is that applications have to be redeveloped for each new proprietary platform they are deployed on. Needless to say, this is a highly ineffective way to develop applications. Another issue is that third party service and application providers don’t have a single uniform interface to develop towards, which makes the integration of an application timeconsuming and costly. A method that provides the means to reuse exiting models and code, ensure portability of applications, improve application quality and reduce development time could prove very beneficial. One solution to these problems could be to apply the Object Management Group’s Model Driven Architechture (MDA).

8

1.2 Introducing MDA Model Driven Architecture (MDA) [2] is coined by the Object Management Group (OMG) as the next big step in solving system integration and interoperability problems. In the face of heterogenous and evolving technology, MDA is supposed to ensure:


MDA, when realized, allows application developers to completely decouple business modeling (such as UML models) from platform-dependent implementations of applications (such as implementations in J2EE, Web services, Parlay etc.). This separation is made possible by formal semantics defined in the Meta Object Facility (MOF) [3]. MOF enables interoperability and automatic transformation of models and is the metamodel used to express UML and a number of other OMG standards.

1.3 Project Context Telenor Research & Development is involved in two IST and EURESCOM [4] projects that are investigating MDA for the telecommunication domain:

1. EURESCOM P1149 “Impacts of changes in enterprise software construction for telecommunications” [5], where they aim to employ MDA as a means to increase interoperability among telecommunication applications, and to increase reuse in telecommunication application development.

2. IST MODA-TEL [6] which is “a joint effort of European stakeholders with business

interest in component architectures, to develop a sound methodology and tools to support the application of MDA in the telecommunication domain”.

The project work presented in this report is a part of Telenors involvement in these projects, and a basis for a future Master Thesis on the subject.

1.4 Project Description and Objectives This project will look at the MDA and one of the few tools supporting MDA, Interactive Objects ArcStyler. The objectives with the work are to:

• Provide a state-of-the-art survey of MDA and the ArcStyler tool.

9

• Discuss MDA and ArcStylers support for MDA. A few key research questions to answer with this discussion are:

o Will the MDA in practice actually provide increased reuse, reduced development

time, ensure portability and increase application quality? o Does ArcStyler support MDA adequately? Are there possibilities for

improvement, to better support MDA towards gaining the benefits the process promises?

1.5 Project Approach The project takes on an experimental approach to ArcStyler and MDA development. For this purpose Telenor provided a telecom case study: to redevelop parts of their InTouch application using ArcStyler and the MDA. InTouch is a service available to Telenor customers, providing a higher degree of availability by enabling “intelligent” and highly user configurable redirection between fixed- and mobile phones. The most important features provided are call redirection (from your fixed phone to any mobile phone in the household, or to voicemail) and call screening. The InTouch case study, together with the state-of-the-art survey, provides the basis for the MDA/ArcStyler discussion.

1.6 Report Structure The report is structured as follows: Chapter 1: Introduction sets the stage for the report, describing the motivation, introducing the technology and project description, objectives and approach. Chapter 2: Survey of State-of-the-art looks at the Model Driven Architecture and the ArcStyler MDA tool in detail. The MDA part is mainly a littrature study, while the survey of ArcStyler can be read as a tutorial with our simple development example, illustrating the tools core functionality. Chapter 3: Telenor Case Study: InTouch MDA Redevelopment describes the InTouch case study. The focus is on the redevelopment of InTouch in a MDA context, looking at the different stages of MDA development. Chapter 4: Discussion presents the discussion of MDA and ArcStyler, looking at strenghts and weaknesses with these technologies. 10

Chapter 5: Conclusion and further work concludes and summarises the project work, answering the research questions posed in section 1.4, followed by an evaluation of the project contribution and pointers to future work on the subject.

11

2 Survey of state-of-the-art This chapter describes the Model Driven Architecture (2.1) in detail and provides a survey/tutorial of a tool supporting MDA development, Interactive Objects’ ArcStyler (2.2).

2.1 Model Driven Architecture (MDA) Model Driven Architecture as standardized by the Object Management Group (OMG) is a new strategy for designing software systems. MDA is not a completely new architecture, but is built on well known standards like Meta-Object Facility (MOF), Unified Modeling Language (UML) and Common Warehouse Metamodel (CWM). One of the main goals for the MDA is to continue to allow the coexistence of different types of implementation technologies and standards, while simultaneously provide a clean separation of the different layers of abstraction. The vision behind MDA, and subsequently MDA itself, addresses the whole lifecycle of a program: From business modeling to system design, to component construction, to assembly, integration, deployment, management and evolution.

Figure 2-1: Model Driven Architecture [2]

To better integrate both new and old standards, MDA

1. embraces technologies like JAVA, CORBA, XMI/XML, .NET. 2. offers improved portability by making the first part of the design process platform

independent. The design is later realized on multiple platforms by auxiliary mapping, or

12

mapped to a specific platform by point mapping. This can either be done automatically by a mapping tool, or manually by a given mapping standard.

3. broadens the usability of standards by improving the integration based on models of relationships across different domain applications.

The next three chapters are concerned about the concepts, models and OMG standards concerning MDA. The litterature study presented here summarise and elaborates on the key points in OMG own article about the technical details of MDA [2]. 2.1.1 Why the MDA One of the underlying motivations for the MDA concept is to improve the productivity of the software development process. This is meant both as a goal to improve the short-term productivity of developers, and to improve long-term productivity by minimizing software artifacts’ sensitivity to change. In the early days of IT the introduction of high level languages to some extent abolished the need for programmers that wrote assembly or binary directly. The most effective software development concept in most areas today, is undoubtably the principle of obect-orientation. Encapsulation, inheritance and polymorphism allow applications to be extended without affecting other parts of the system. But new kinds of IT requirements, including dynamic addition to applications at run-time, need new kinds of solutions. A concept that aims to meet these requirements is the MDA. The modeling part of software development will play an extended role compared to earlier. Models will become the primay artifacts developed by humans, and code - at the level defined by todays’ programming languages – will be a derived artifact, generated by tools. This will allow developers to focus on describing business logic and problem concepts in a concise and abstract manner as possible, leaving tools to handle the routine implementation issues [7]. 2.1.2 Concepts This chapter aims to give a brief summary of the main concepts used in the MDA. A model in the MDA is a representation of a part of the function, structure and / or behavior of the system. A formal specification is one that is based on a language that has well-defined syntax and semantics, and possibly rules of analysis, inference or proof of its constructs. The syntax of a formal specification can be represented both textual and graphical; the semantics should be defined more or less formally. In the context of MDA, a non-formal specification is not a model, but merely an informal diagram or text.

13

Abstraction is defined as a suppression of irrelevant details. Abstraction criteria are useful to determine what level of detail should be included where in a model. The viewpoint, or simply view, of a model is defined by the abstraction criteria of the system. MDA provides guidelines on the architectures of models, where as the abstraction criteria of the viewpoint are a modeling choice. A model is refined by making it less abstract. This is a realization of a model. An example of a refinement of a model is the stage where it’s transformed from a platform independent model to a platform specific model. MDA also allows zooming on models. Figure 2-2 shows how objects are zoomed on to show different levels of detail. “Zooming in” shows more details, while “zooming out” hides details of an object.

Figure 2-2: Zooming on objects [2]

Figure 2-3 shows how MDA enables zooming on interactions in models. As for object-zooming, “zooming in” shows more details (if any) of an interaction while “zooming out” hides these details.

14

Figure 2-3: Zooming on interactions [2]

MDA allows the “zooming in” operation to result in multiple alternative models depending on the refinements. This flexibility is needed to support the ability to model multiple platform specific systems. A Platform Independent Model (PIM) is a formal model where technical details about programming languages and operating systems etc. are excluded. A Platform Specific Model (PSM) is a model where these details are included. 2.1.3 Models The MDA design strategy is mainly divided into tree key levels of abstraction, namely the Business Model, the Platform Independent Model and the Platform Specific Model. The Business Model is a computation independent model in which computational details, are hidden or as yet undetermined. This model can for example be realized by CRC-cards. The PIMs provide formal specification of the structure and function of the system and abstracts away technical details. A Platform Independent Component View is derived by refinement from the Business Model and shows the Computational details of a system without displaying platform specific details. In the refinement to one or more PSMs all technical details are added. Both the PIM and PSM are realized by UML. Figure 2-4 states the relationship between the business model, the PIM and the PSM. As seen from the figure the Business Model is within the scope of the PIM.

15

Figure 2-4: Three different levels of abstraction [2]

The idea of abstracting out the precise structure and behavior of a system in the PIM to separate it clearly from the PSM has three main advantages:

1. It’s easier to verify the completeness and correctness of a model without platform specific semantics.

2. It’s easier to construct a model which can be refined into implementations of several different platforms. The Business Model is also an excellent tool to catch business goals and policies in a computational independent manner.

3. Integration and interoperability across systems can be defined more clearly in platform-independent terms.

If there exist generic mapping methods that are shared across multiple applications, it may be possible to automatically transform a PIM to different target PSMs, either fully or partially via some mapping tool. Figure 2-5 shows an example of a shared mapping from a PIM to a CORBA application.

16

Figure 2-5: Mapping from PIM to PSM [2]

2.1.3.1 Platform Independent Models in UML As earlier stated, both PIMs and PSMs make use of the UML for modelling. [2] gives the following reasons why UML is preferred over IDL based object models, Java interfaces and Microsoft IDL interfaces:

1. UML is defined using core UML modelling concepts and this enhances the power of MDA.

2. UML can be expressed both textually and graphically. 3. UML models can be semantically much richer than models in other declarative model

languages mentioned above, which can express syntax but very little about constraints on usage and behaviour such as:

• Static invariants constraints on combinations of attributes. • Pairs of pre- and post-conditions for specifying operations. • Whether a single value parameter is allowed to be null. • Whether an operation has side effects. • Whether subtypes of a super type are disjoint or form a partition. • Patterns of specifications, designs and refinements.

2.1.3.2 Platform Specific Models in UML Because UML is independent of middleware it is not obvious how a model is specified in a platform specific manner. Decisions on what an UML class actually represent in a PSM context can be defined by using an UML profile. Profiles are a set of extensions to UML which uses the built-in extension facilities of UML, stereotypes and tagged values. Stereotypes label a model

17

element to denote that is has some particular semantics. In the graphical UML notation stereotypes are denoted by angle brackets as shown in figure 2-6.

Figure 2-6: A CORBA stereotype [2]

OMG made a complete profile for CORBA, adopted in 2000. UML profiles for other platforms can be defined in a similar way to provide the necessary tool for constructing PSMs. To further enhance the semantics of a UML model, notes containing comments and OCL-code can be attached to classes. This is shown in figure 2-7 where a note is attached to the AccountManager class from figure 2-6 to specify that a number must be between 1000 and 9999.

Figure 2-7: Notes in UML [2]

Both stereotypes and notes can be used to enhance the semantics of PIMs as well, but has to be applied in a “platform-inspecific” manner.

18

2.1.3.3 Mapping One of the key features of MDA is the notion of mapping. Mapping is a set of rules and techniques used to modify one model in order to get another model. Mappings are used for transforming:

1. PIM to PIM. This transformation is used for refining a PIM. Here models are enhanced filtered or specialized in a platform independent manner. The most obvious transformation is the analysis to design model mapping.

2. PIM to PSM. This transformation is used when a PIM is sufficiently refined to take the

step into becoming platform specific. The mapping is based on the platform characteristics. These characteristics should be described using UML. An example of such a mapping is going from a local component model to a commercial existing component model like EJB for J2EE.

3. PSM to PSM. This transformation is needed for component realization and deployment.

PSM to PSM is generally related to platform dependent model refinement. 4. PSM to PIM. This transformation is needed for transforming an existing implementation

in a particular technology into a platform-independent model. To implement mapping, one needs to know the metamodel of the input and output models and their mapping rules. The execution of transformation rules can be done inside UML via scripting or by using external tools like for example XMI. There are multiple ways to transform a UML PIM to one or several UML PSMs:

• The first approach is that a human could study the PIM, and manually constructing the refinement between the PIM and the PSM.

• In the second approach a human takes advantage of known refinement patterns to simplify the construction of a PSM from the PIM.

• In the third approach an algorithm is applied to construct a PSM skeleton using the refinement patterns in the second approach. These skeletons are manually enhanced.

• The fourth approach is fully automated using an algorithm that constructs a complete PSM from a complete PIM. This approach would need an advanced refinement tool.

Note that the four approaches above do not address the production of executable code from a PSM, only refinement between PIM and PSM. Fully automated transformations are feasible in certain constrained environments. The degree of transformation can be enhanced considerably if:

• There are no legacy to take into account • The model taken into account is semantically rich

19

• The transformation algorithms used are of high quality

2.1.3.4 Packages and viewpoints The UML package, a construct for grouping model elements, provides an important modeling element for separating viewpoints and refinements in the context of MDA. A package can import other packages, making them available for its use. Packages help understand MDA since the models being interrelated for integration are typically in different packages. Models of a system from two different viewpoints, unrelated by refinement (or models of two distinct interfaces of a component, or models of two different systems to be integrated) would be defined by two different packages like in figure 8. The relationship between the two is defined by a model correspondence (large arrow.)

Figure 2-8: Viewpoint correspondence [2]

A refinement in the same system can be defined by another correspondence. Refinement is a relation between model elements that can be in different packages, not between the packages themselves. See figure 2-9.

Figure 2-9: Refinement relation [2]

20

2.1.4 OMG standards in MDA MDA is built on several other OMG standards, some of which are illustrated in figure 2-1. This chapter will attempt to explain how MDA integrates these standards, and to look at the overall picture of MDA.

2.1.4.1 The Core The core of the MDA is built upon the MOF, UML and CWM standards. In addition to these standards the core also holds a number of UML profiles. Each profile will contain specialiced environments like Entreprise Computing with its component structure and transactional interaction, and Real-Time computing with its special needs for resource control. The idea is that the number of profiles at all times is kept low. Each profile represents the common features of the middleware platforms appropriate for its category of computing, but is independent of any specific platform. The first step when constructing an MDA-based application will be to create a PIM of the application expressed in UML using the appropriate UML profile. Platform specialists will transform this application model into one targeted to a specific platform such as EJB, .NET, etc. Standard mappings allow this transformation to be automated. The PSM represent both the business and technical run-time semantics of the application. A PSM is still in UML, but is expressed in a dialect (i.e. a profile) of UML that precisely mirrors technical run-time elements of the target platform.

2.1.4.2 Pervasive Services All applications, independent of their context rely on a set of essential services. The list varies somewhat depending on the source but typically includes Directory services, Event handling, Persistence, Transactions, and Security. See outer ring of figure 2-10. When these services are defined and built on a particular platform, they necessarily take on characteristics that restrict them to a platform. To avoid this, MDA defines such services as pervasive services at the PIM level in the UML. Only after the features and architecture of a pervasive service are fixed will platform-spesific definitions be generated for all of the middleware platforms supported by the MDA.

2.1.4.3 Domain Specifications As seen in figure 2-10, outside the outer ring, OMG also tries to integrate domain facility specifications into their MDA concept. Traditionally this has not been an area of modeling with

21

too much focus, but this is to change with the MDA. OMG tries with MDA to standardize the frameworks for standard functions in their application space. The domain facility specifications will be in the form of normative PIMs expressed using UML, augmented by normative PSMs expressed using UML and interface definitions for at least one target platform. An example of this, taken from [2], is a Finance standard for accounts receivable facility that includes a PIM expressed UML, a CORBA-specific UML model and IDL interfaces and a Java-specific UML model and Java interfaces. XML DTDs or schema generated via XMI-based mapping rules could be included as well. All of which would be normative. Since accounts receivable is an Enterprise Computing application, the normative, platform-specific artifacts would be derived at least partially through standard mappings of the Enterprise Computing profile to the platforms. Today OMG has ten such Domain Task Forces (DTF) and several others are coming soon. These DTF’s are shown as rays from the “MDA circle” in figure 2-10.

2.1.4.4 Lifecycle IT systems have historically been developed, managed and integrated using a range of methologies, tools and middleware. The last few years this has to some extent changed to more complete semantic models as well as data representation interchange standards. This change is mainly due to OMG- and W3C’s work on the area. OMG contributions include CORBA, UML, XMI, MOF and CWM. W3C contributions include XML, XML Schema and the ongoing work of the XML-P working group. The life cycle of an application can vary dramatically depending on whether a new application is built from scratch or if a wrapper is added to an existing application. The cost of enhancement and maintenance of an application far exceeds the cost of initial development. In addition the application lifecycle itself can be quite complex, involving several vendors in each of the lifecycle phases. Hence the need for information interchange and interoperability between tools and middleware provided by different vendors is very important. The MDA supports many of the commonly used steps in model driven component based development and deployment. A key aspect of MDA is that it addresses the complete lifecycle covering analysis and design, programming which includes testing component build or component assembly, and deployment and management. As mentioned earlier the core is based on MOF, UML and CWM. These technologies are used to describe PIMs. A PIM can be refined n-times until the desired system description level is obtained. The model is then transformed to one or several PSMs. The PSM can again be refined as many times as needed. Figure 2-10 shows a software development lifecycle and the different transformations involved.

22

Figure 2-10: Sofware Development Lifecycle

2.1.4.5 UML (Unified Modeling Language) UML addresses the modeling of architechture, objects, interactions between objects, data modeling aspects of the application life cycle, as well as the design aspects of component based development, including construction and assembly. Artifacts captured in UML models can easily be exported to other tools in the lifecycle using XMI. UML profiles bridge the UML community (model based design and analysis) and the developer community (Java, VB, C++ developers), middleware community (CORBA, EJB, SOAP developers) etc. Additional profiles that focus on systems and application management are not yet adopted but will bee needed.

23

2.1.4.6 XMI (XML Metadata Interchange) XMI is a standard interchange mechanism used between vaious tools, repositories and middleware. XMI can also be used to automatically produce XML DTDs from UML and MOF models, providing an XML serialization mechanism for these artifacts. XMI, which connects the world of modeling (UML), metadata (MOF and XML) and middleware (UML profiles) plays a key role in the use of XML in MDA.

2.1.4.7 MOF (Meta Object Facility) MOF provides the standard modeling and interchange constructs that are used in MDA. Other standards like UML and CWM are defined in terms of MOF constructs. This common foundation provides the basis for model/metadata interchange and interoperability, and is the mechanism through which models are analyzed in XMI.

2.1.4.8 CWM (Common Warehouse Metamodel) CWM is the OMG data warehouse standard. It covers the full lifecycle of designing, building and managing data warehouse applications, and supports management of the lifecycle. Please refer to the OMG specifications [3, 8-10] for more information on the standards above.

24

2.2 ArcStyler ArcStyler is a model-driven architecture and development platform that supports the entire application process from analysis to deployment and management. Interactive Software describes ArcStyler as an “Architectural IDE”, assuring architectural standards and integrity, leveraging the system above and beyond programming IDEs. This section starts out with a look at the ArcStyler Architecture (2.2.1) followed by a tutorial of the ArcStyler tools in section 2.2.2. 2.2.1 ArcStyler Architecture ArcStyler is made up by a number of tools/modules supporting the different stages of the development process. Figure 2-11 show the core architecture, the different development phases and how the ArcStyler modules fit into the development process.

Figure 2-11: ArcStyler Core Modules [11]

The Business Object Modeler allows domain experts and business analysts to impart their knowledge on how the organization functions through high level business models. This includes modeling both business objects and dynamic behavior of the target system. The tool tightly integrates the following concepts and techniques:

• Object-oriented technology and component based design. • Responsibility-driven design. • Design analysis using walk-through techniques.

25

The Pattern Refinement Assistant refines the business model into a basic UML component model. This is an important process, bridging the business model level and the more detailed UML models. The Generator Engine is responsible for the creation of a fully-functioning technical infrastructure. The ArcStyler Cartridges are used to optimize the infrastructure to a specific runtime environment, e.g. the creation of EJBs (Enterprise JavaBeans) for a specific J2EE application server, e.g. BEA WebLogic Server. When the model is finished, ArcStyler provides support for code generation, building, deploying and testing the application. ArcStyler is available in three editions:

1. The ArcStyler Web Edition, which provides MDA Cartridges for Web technologies, e.g. Web services, XML, .NET, J2EE.

2. The ArcStyler Enterprise Edition, which enhances the Web Edition with support for all

levels of an n-tier architecture, adding the Business Object Modeller and the Refinement Assistant.

3. The ArcStyler Architect Edition, which comprises the Enterprise Edition plus the MDA

Development IDE. This enables the organisation to develop its own architectural style through visual development or extension of MDA Cartridges.

2.2.2 ArcStyler 3.0 – Tool Details This section will look at the ArcStyler tools in more detail [12]. The focus will be on the core functionality, each section followed by our brief illustrative chat example.

2.2.2.1 The Chat Example A simple Java Chat application was developed to illustrate the different ArcStyler tools. The application provides the following simple functionality:

• A chat server responsible for: o Receiving client connections. o Broadcasting chat messages and events (clients connecting to or leaving the chat)

to the connected clients.

• A chat client responsible for

26

o Displaying the chat messages and events from the server, and which users are currently connected to the server.

o Sending messages typed in the chat textfield to the server. The Java Chat example was implemented using the following tools:

• The ArcStyler Enterprise Edition. • Rational Rose Enterprise Edition 2002. • JBuilder7.

2.2.2.2 The Convergent Business Object Modeler (C-BOM) The Convergent Business Object Modeler supports design of business objects using CRC (Class, Responsibility, and Collaboration) Cards. The CRC cards contain a description of the business object, its responsibilities, collaboration with other business objects and the documentation of specific design themes. The business objects are classified into a basic set of design abstractions:

• Organizations: Groups of people in charge of carrying out specific business processes. • Resources: Sources of value, cost and action in the organization. • Processes: Goal directed sequences of business activities. • Accessors: Interface objects for accessing the business system. • Utility objects: Technical objects, e.g. transactions. • Classes: Represents business objects in general (without classification).

The responsibilities of the business objects are specified as the responsibilities for:

• Knowing: Typical object state information. • Doing: A business object is able to do something. • Enforcing: A business object should enforce a specific condition.

These responsibilities also have a visibility, either marking them visible or hidden. Business models interact by providing services to each other, maybe by collaborating with other objects. This collaboration describes a relationship between business objects, either as for the association concept in UML or simply as a usage dependency. Once the business objects of the model are finished, the key business processes are modeled with visual use-case scenarios. The scenario consists of a start and end point, steps between these points and (conditional or unconditional) transitions between the steps. Each step consists of a requesting client, a responding server, and which task is to be performed by the server. Both client and server are business objects with corresponding CRC cards.

27

Walk-troughs and run-throughs of the use-cases, under various conditions, ensure that the model is tested for correctness and completeness. The C-BOM tool also provides a configurable verification mechanism to verify the structural correctness and completeness. The goal of the C-BOM business modeling is not only a business model and requirements for a particular application, but also to focus on modeling the business as a set of reusable components. Traditional modeling focuses more on the application, modeling certain parts of the business specific to the application, rather than the business itself. The complete business model from this stage will have undergone extensive refinement at a high level of business abstraction, before any technical and application specific refinement. The deliverables from the C-BOM design phase include:

• Detailed domain requirements. • A (validated) structural and dynamic business model. • Documentation of specific design themes (e.g. migration, security, host-integration). • HTML documentation. • XML/XMI representation of the business model.

28

Chat Example: C-BOM Figure 2-12 shows the ArcStyler C-BOM after the development of the initial CRC cards. Looking at the CRC cards for the Server business object, we see the different responsibilities of the chat server, e.g. to connect clients and to broadcast their messages, which objects it collaborates with and which objects it owns. The K and V columns are for marking the responsibilities as (K)nowing/(D)oing/(E)nforcing and (V)isible/(H)idden respectively.

Figure 2-12: ArcStyler C-BOM - CRC Diagram

For this example all the objects were modeled with the general class abstraction. An improvement of the design would be to use the Accessor abstraction for the ClientGUI object, as it is meant to be an interface object for accessing the chat system. 29

Figure 2-13: ArcStyler C-BOM – Scenario

Figure 2-13 shows a C-BOM scenario for a new client connection. The first step shows the ClientGUI object as the requesting client, the Client object as the server and the responsibility of the Client to connect the user. The next steps show the Client object connecting to the Server and the Server broadcasting to all clients that there is a new user. The walk-through and run-through mechanisms work as follows:

1. First the user selects which steps the walk-through should contain, from start- to end point.

2. The toolbar at the bottom of the scenario window is used to control the run-through. 3. At the start of a run-through all the steps are marked blue, and turn red as the run-through

procedes through the scenario.

Figure 2-13 shows the end of such a run-through. This mechanism is not of much use in a small and simple scenario as is the case here, but for a large process, this feature would probably prove usefull. It is important to notice that these scenarios are not used by ArcStyler in any MDA context. This is a feature to help the designers verify that the CRC business objects actually support the processes, analogous to use-case diagrams and classes in UML. 30

2.2.2.3 The Convergent Refinement Assistant (C-RAS) The next step in the process is the refinement of the business model using the Convergent Refinement Assistant. The C-RAS module refines the business model into a basic, platform and programming language independent UML model. This includes refining the responsibilities and collaborations into UML model elements such as attributes, operations and associations. The refinement process is graphically-driven, with the user selecting fitting attributes, associations and operations for the various business objects created in the C-BOM design. The knowing responsibilities are usually refined as attributes or associations. In case of the attribute refinement, the modeller only has to select the attribute type. Associations require the specification of classifier or component type of the other association, multiplicity and navigability. The Doing or Enforcing responsibilities are usually defined as operations, with a specified signature, parameters, and return type and any pre- or post condition documentation. The C-RAS tool, as do C-BOM, provides a model verifier, which checks if the business model is correctly refined to the UML model. This verifier can work in two modes: strict and weak, with different rule sets. During the model refinement, the model elements are marked on-the-fly with either a check mark for verified or an exclamation mark for an incomplete refinement. The deliverables from a completed C-RAS refinement include:

• A refined business model. • A validated UML model. • An XML/XMI representation of the UML class diagram.

31

Chat Example: C-RAS

Figure 2-14: ArcStyler C-RAS

Figure 2-14 shows the C-RAS tool for the Chat example. The hierarchical menu to the left of the screenshot shows the different business objects and their responsibilities, collaborations and ownerships. These are as stated before refined to attributes, associations and operations towards a UML model. The example here is the update connected users responsibility of the ServerThread object. This is a visible responsibility for doing and is refined to an updateUsers operation with no return value and with one parameter, the new users list. It is possible to add classes and responsibilities in C-RAS and these will automatically follow through to the C-BOM tool. This is also true the other way around, enabling the designer to go back and forth between the CRC diagrams and the refinement assistant. When the refinement of the business model is complete, the next step is to open the project in the ArcStyler UML refinement tool: Rational Rose.

32

2.2.2.4 The Convergent Refiner for Rational Rose (C-REF) ArcStyler is tightly integrated with Rational Rose and embeds and extends Rose as a module for technical UML refinement. Interactive Objects has extended many of the features of Rational Rose, such as architecture-driven modeling assistants, MDA model management and verifiers for design quality and precision. In brief the C-REF tool provides the following features:

• Technology projection-specific modeling support. • Technology projection-specific model verification. • ArcStyler repository model import and export.

The model from the C-RAS module is written to an ArcStyler repository which in turn is imported into the ArcStyler extended Rational Rose. Here the model is refined towards a language and platform specific implementation. This refinement includes the modeling and platform specific configuration of:

• Packages. • Interfaces. • Classes. • Exceptions. • Dependant values (requiring serializability). • EJBs and EJB component interfaces. • Java and EJB archives. • Attributes, operations and dependencies. • Finite state machines.

33

Chat Example: C-REF (Rational Rose)

Figure 2-15: ArcStyler C-REF (Rational Rose)

The model from the C-RAS module is automatically converted to the UML model we see in Figure 2-15. Here a more detailed design emerges where the initial CRC business objects are refined to classes with operations, attributes and associations realizing the responsibilities. The next step is to further refine this UML model into a more platform specific model. Since this example is a simple Java2 application, there is not much refinement needed prior to the code generation. The model here does lack a few Java specific attributes to make the example application fully work, e.g. Sockets and Streams to implement the communication between the clients and the server, but this can just as well be added to the generated source code. For a more complex application model, there would be a lot more UML refinement, e.g. a J2EE application where EJB classes are refined by using the provided EJB stereotypes. Another example is the refinement of attributes to be static, final etc., classes to be abstract, serializable, implementing some interface, adding custom constructors and so forth.

34

2.2.2.5 The Convergent Generator (C-GEN) The Convergent Generator is the ArcStyler code generator. It automates a large portion of the design implementation activity and provides the following features:

• Code generation for different application servers using the projection cartridge concept. • Support customization of the generated code through protected areas or timestamp

control mechanisms. • Customizable templates for the chosen technology projection. • Extendible by writing new templates and new cartridges.

Based on the style-conform UML model from the previous stage, C-GEN uses a technology projection cartridge to generate a number of different artifacts:

• Editable files with protected areas. • Editable files with timestamp control. • Non-editable artifacts.

A protected area is a concept used by the cartridges to support round-trip development. These areas are code segments which are preserved across subsequent runs of the code generator, and are used to enter business logic and other information which cannot be specified in the model. Examples of editable files with protected areas are Java source code files, EJB deployment descriptors and ANT build support files. For some of the generated files, the concept of protected areas does not work. This is the case of files customized using specialized tools outside the ArcStyler integrated environment. For these files ArcStyler provides a timestamp control mechanism to enable incremental, model-driven generation and code customization. Examples of editable artifacts with timestamp control are JBuilder project files and Java ServerPages.

Non-editable artifacts are files that are not supposed to be modified by the developer. Examples of such files are diverse support files and JBuilder libraries which are generated based on model information.

35

Chat Example: C-GEN

Figure 2-16: ArcStyler C-GEN

Figure 2-16 shows the C-GEN module for the Chat example. Before any code generation the user has to select a MDA Cartridge for the projection. In this case it is the Standard Java2 Cartridge described in the figure. After selecting “Generate source code”, the C-GEN tool generates:

• Source code for the UML model. • Build files for the application, based on the selected platform. • JBuilder project and library files, supporting the use of JBuilder as the Java IDE. • A JUnit test case class for testing the application.

The next step is to customize the generated code, which for this example was done in JBuilder.

36

2.2.2.6 JBuilder support and Code customization ArcStyler supports JBuilder as the programming IDE. This support is, as stated before, through the C-GEN module JBuilder project and library files generation. It is also possible to start JBuilder directly from the C-GEN tool. It is important to notice that any text editor can be used for code customization. ArcStyler have the same protected area and timestamp support for the source code files, regardless of the program used to edit these. Rational Rose also supports code editing, but the editor provided here is probably too limited for anything but small applications. Chat Example: JBuilder

Figure 2-17: JBuilder

Figure 2-17 shows the Chat example in the JBuilder environment. The editor textarea show the Server class and the implementation of the broadcastMessage and recieveConnections methods.

37

Notice the protected areas that suround the method implementation. The code in these areas is kept after subsequent code generations, such that customized code is not lost after a new generation run. If the programmer whishes to change/add methods at this stage of the development, this can be done in two ways:

• Add the method or attribute in the protected areas at the start or end of the source file. These method or attributes will not appear in the model, but will be kept in the file after subsequent generation runs.

• Add/change the method or attribute in the Rational Rose UML model first and then

regenerate the code in C-GEN.

2.2.2.7 The Implement, Deploy and Test tool (C-IX) The Implement, Deploy and Test tool assists the developer with deployment and testing of the system components. The C-IX supports the following features:

• Builds the physical components modeled in UML. • Runs a test server for the each component. • Provides a test runner to execute the modeled and implemented test cases.

Chat Example: C-IX

Figure 2-18: ArcStyler C-IX

38

Figure 2-18 shows the default test of the Chat example being run in C-IX module. As stated before the ArcStyler C-GEN module generates a JUnit test case for each deployable component (e.g. JAR file) in the UML model. For the Chat example there is only one JAR file, Chat.jar, containing the entire application. The default test class generated is just a source code skeleton, and must be customized by the tester. Other test cases can be modelled in Rational Rose by using the test stereotype and run in the same way as the default test case through C-IX. All the test cases generated from C-GEN follows the JBuilder project file, enabling testing in the JBuilder environment as well as in the C-IX module. Figure 2-19 shows the final running Chat application.

Figure 2-19: Simple Chat Application

39

2.2.2.8 The Convergent Generator IDE (C-GEN-IDE) The Convergent Generator IDE is a tool for developing templates for the code generator. It provides the following features:

• An editor providing template specific support. • Debugging support for templates and related JPython scripts. • JPython expression evaluation. • Navigation through the cartridge architecture. • Code generation backtracking.

Figure 2-20: ArcStyler C-GEN-IDE [11]

For more information on ArcStyler Cartridges and extensibility, please refer to Appendix A.

40

3 Telenor Case Study: MDA redevelopment of InTouch For further study and discussion of ArcStyler and MDA, Telenor provided a case study called InTouch. InTouch is a service already developed and used commercially by Telenor. Further details about InTouch are described in section 3.1. The focus for this redevelopment was not on extending ArcStyler with MDA Cartridges (see Apendix A) for the telecommunication domain, but rather to look at ArcStyler “out of the box” by redeveloping a telecom specific application. Chapters 3.2 through 3.4 describe this redevelopment, looking at the InTouch system requirements, detailed design and implementation. The description of this development is coupled with the different stages of the MDA development process, providing a comprehensive development example. Figure 3-1 illustrates the MDA development process used for the InTouch development. The process is a simplified version of the one described by Jon Siegel and the OMG Staff Strategy Group [13].

ArcStyler Business Model

Platform Independent UML Model

Platform Specific UML

Model

Source Application Deployment code, config

files etc.

Figure 3-1: MDA Development Process

3.1 InTouch InTouch [14] is a service available to Telenors customers, providing a higher degree of availability by enabling “intelligent” and highly user configurable redirection between fixed- and mobile phones. The most important features provided are call redirection (from your fixed phone to any mobile phone in the household, or to voicemail) and call screening. Figure 3-2 shows a possible call sequence to an InTouch subscriber. If there is no answer on the fixed line phone, the call is redirected to the subscribers’ mobile phone. If the subscriber does not answer the mobile phone, the caller is redirected to the subscribers’ voicemail.

41

Figure 3-2: InTouch call example

Other features include:

• Screening of callers both to the fixed line and mobile phone. A predefined set of

callers are sent directly to the voicemail without getting through to the subscribers fixed or mobile phone.

• Predifined selection lists of mobile phones and/or voicemail services for the same

fixed line subscription, e.g. the caller can select whom in the household to contact on their mobile phone or whom to leave a personal message.

The InTouch service can be configured through several configuration portals including the Web, telephony and WAP.

3.2 System requirements 3.2.1 Functional Requirements The following points will act as the systems functional requirements and are extracted from the InTouch User manual [14] and the Telenor InTouch Web site [15]:

• InTouch redirection can be turned on or off by the subscriber. • InTouch on:

o No answer on the fixed line: Results in a redirection to a mobile phone. The InTouch subscriber can set up a selection list of mobile phones which

the caller selects from. The names of the mobile phone owners can be recorded by the subscriber. If there is no recording, the phone numbers will be read as default.

If there is no answer on the mobile phone, the call will be redirected to the selected person’s answering service.

o Busy on the fixed line:

The caller is redirected to the answering service (default). The caller receives a speech message stating that the line is busy and is

redirected to the answering service.

42

The call is redirected to a mobile phone, if this is busy; the caller gets the answering service.

o The subscriber can select a number other than for his/her mobile phone for direct

redirection. o The subscriber can enable direct redirection from the fixed phone to the mobile

phone, when the mobile is on. If the mobile phone is off, the call goes through to the fixed phone.

o The subscriber can predefine for how long the phone will ring before redirection.

Default will be 20 seconds.

o The subcriber can specify a screening list for incoming calls, thus being able to control who gets through to the fixed line, the mobile phone or who gets redirected to the answering service.

o Business customers have an extra redirection feature. If there is no answer, the

caller can choose between the following: Leave a message. Redirection to secretary. Redirection to collegue. Redirection to company reception.

• The subscriber can view information about:

o Callers phone numbers. o Date and time of calls. o If the call were answered by fixed or mobile phone. o If the caller left the subscriber a message. o If the caller hung up before any answer.

• InTouch off:

o If there is no answer on the fixed line, the call is redirected to the answering service.

o If there is more than one person to contact on the fixed line, the caller can select

who to leave a message prior to the answering service redirection.

43

3.2.2 Implementation restrictions Telenor had an implementation specific requirement:

• The InTouch application should use Telenors Incomit Parlay Gateway, and thus the Parlay Spesification [16], to access the telephony network.

This is due to Telenors interest in Parlay as an interoperable specification for accessing the telecommunication networks. Selecting other fitting platform specific technology was left to the implementors. It was also agreed to focus the implementation on the core call handling logic of the intouch system, and given enough time, on a simple web portal for customer configuration.

3.3 Detailed Design This chapter outlines the design of the InTouch service. Section 3.3.1 describes the business model design, followed by the platform independent model in 3.3.2 and the platform specific model in 3.3.3. These sections cover the first three phases of the development process:




Model


files etc.


3.3.1 Business Model

3.3.1.1 InTouch Call Handling The business model was constructed by defining the business objects, extracted from the InTouch system requirements, in the ArcStyler C-BOM toolkit. A CRC card of the main logic of the InTouch business model can be seen in figure 3-4. The design was made as generic as possible so that parts of it can be reused in later application development.

44

Figure 3-4: Creating CRC diagrams

The next step of the business modeling was to create scenarios describing the InTouch business logic. This is a good way to ensure that all the aspects of the requiremens are covered in the business model. The scenarios are primarily a tool for showing customers/domain experts the business logic, but they also proved valuable when implementing the system. An example of a scenario for newCall is shown in figure 3-5. This scenario shows how a new call is received, logged and where the caller is sent, i.e. fixed terminal, mobile terminal, voicemail, etc.

45

Figure 3-5: Example scenario for the InTouch application

3.3.1.2 InTouch Web Configuration Portal Since the focus of development was on the call handling part of the InTouch application and because of limited time with the project, no business model of the Web Configuration Portal was made.

46

3.3.2 Platform Independent UML Model

3.3.2.1 InTouch Call Handling Figure 3-6 shows the InTouch platform independent UML model generated from the business model. The ITLogic class contains the main logic of the call handling. This class has a Call, holding the call information, an ITConfiguration class for InTouch specific configuration, an ITCommunication class connecting the application to other systems, a CallLog logging call information and a Customer. The Customer class holds customer specific information specialized in the BusinessCustomer and PrivateCustomer classes. A Customer has a Terminal, in our case specialized as MobilePhone, Voicemail and FixedPhone. CustomerProfile and BusinessCustomerProfile hold profile related information and Screening holds the screening and VIP lists. The RedirectionAlternativeList contains the list used by a business customer for choosing alternative redirection (secretary, collegue or reception).

Figure 3-6: InTouch platform independent UML model

47

3.3.2.2 InTouch Configuration Web Portal The InTouch configuration web portal was modeled in the ArcStyler C-REF tool using the web accessor cartridge for web development. Accessors, in this case only the InTouchConfiguration accessor, are special classes holding the information and the logic connecting the web application to the InTouch main application. These are coupled to views representing the different JSPs in the web application. The views, or representers, contain the textfields, checkboxes, buttons, etc. needed. Figure 3-7 illustrates the platform independent UML model of the InTouch web application.

Figure 3-7: UML model of the InTouch Configuration Web Portal

When the UML design is finished, the pageflow is modeled in an activity diagram. The different pages in the web application are represented in this diagram by accessor- and representer states. For the InTouch web application only representer states were needed. The diagram has a start state where the execution starts and an optional end state. The arrows between the states represent pageflow. Flows between states are executed by triggers like buttons or links, or are executed directly without special triggers when unspecified. The activity diagram for the InTouch web application is shown in figure 3-8. The index page displays the login form. If the login is successful the user is sent via the login page (which authenticates the user) to the customer page. If not, the user is sent back to the index page with a message stating an unsuccessful login. The customer page displays the InTouch configuration options. Depending on the type of customer different options is made available to the user. Callog shows all incoming and outgoing InTouch calls for a cusotomer. The list page shows the the different lists (VIP, screening etc.) of editable terminal numbers for a customer. 48

Figure 3-8: Activity diagram stating the page flow

3.3.3 Platform Spesific UML Model

3.3.3.1 InTouch Call Handling Figure 3-10 shows the platform specific UML model for the InTouch call handling. This model is refined from the platform independent UML model described in the previous section.

Figure 3-9: InTouch PSM

49

The resource stereotypes from the platform independent UML model have been refined to regular UML classes, specific for the application. The other differences from the PIM is

• The ITSimulator and the PhoneImpl classes from the simulation package. • The three CORBA interfaces Communication, Simulator and Phone from the

communication package. The ITSimulator simulates a gateway to a telephony network. In a non-simulation implementation of the system, this could have been a Parlay gateway1 as illustrated in section 3.4.1.1. The ITCommunication class communicates with the simulated gateway through CORBA, as does the PhoneImpl class. The PhoneImpl class is meant to implement both a phone GUI and the CORBA interface needed for communication with the ITSimulator.

3.3.3.2 InTouch Configuration Web Portal Because the ArcStyler Entrepise Edition’s webaccessor cartridge we used for the project only supports JSP web applications, it’s difficult to talk about PIMs and PSMs in an MDA context. At what stage a PIM is actually refined to a PSM in ArcStyler is not always easy to know. We define here that we have a PSM when we choose the webaccessor cartridge. The problem is that in the ArcStyler tutorial for accessors [26], this cartridge is chosen already at the project setup. So in theory web development in the ArcStyler C-REF is always platform-specific. We tried to follow an MDA approach to this and modelled the application before we chose the webaccessors cartridge. This had no effect on the model; hence the PSM is the same as the platform independent model in figure 3-7.

1 The simulation does not use or simulate the Parlay/OSA specification, but this does in no way limit the ArcStyler/MDA discussion, as ArcStyler has no support for Parlay.

50

3.4 Implementation and deployment This chapter outlines the architecture, implementation and deployment of the InTouch application. Section 3.4.1 describes the architecture of the InTouch call handling application and the web configuration portal, followed by the implementation and deployment in section 3.4.2 and 3.4.3. Section 3.4.4 takes a brief look at the technologies used in the implementation, 3.4.5 describes the compliance with the requirements and 3.4.6 show a few screenshots of the final system. These sections cover the last two phases of the development process:




Model


files etc.


3.4.1 Architectural description

3.4.1.1 InTouch Call Handling Figure 3-12 illustrates the architecture of the InTouch call handling for a “real world” implementation of the application. .

Parlay/OSA Fixed Network (CORBA)

Client terminal

Parlay Gateway

InTouch Call Handling

Parlay/OSA Mobile Network(CORBA)

Client terminal Parlay

Gateway

Figure 3-11: InTouch Call Handling Architecture

51

The InTouch Call Handling application communicates with a Parlay Gateway through the Parlay/OSA specification, which is CORBA based. The Parlay Gateway is a gateway to a specific network, which for the InTouch application would be either a fixed or mobile telephony network. The client terminal is either a fixed or mobile phone, connected to the networks. Due to practical problems with the Parlay Gateway at Telenor, it was not possible to implement the application with actual access to the telephony network. It was decided to simulate this communication as figure 3-13 illustrates. CORBA Client

terminal InTouch CORBA Call Handling

Simulation

Server

Client terminal

Figure 3-12: InTouch Call Handling Architecture

The client terminal is a Java application, communicating directly with the simulated gateway; the simulation server. The simulation server in turn communicates with the InTouch Call Handling application. The communication is implemented with CORBA, as for the “real world” InTouch application. The difference is that the CORBA interfaces for the simulation are not based on the Parlay/OSA specification.

52

3.4.1.2 InTouch Configuration Web Portal Figure 3-14 illustrates the architecture for the InTouch Configuration Web Portal. JavaServer Pages

HTTP InTouch Configuration

MySQL 3.23

Apache/Tomcat Server 4.1

DatabaseWeb browserJDBC

Figure 3-13: InTouch Configuration Web Portal Architecture

The InTouch users log on to the system through a web browser, connecting to an Apache/Tomcat Web Server. The InTouch Web application is a set of JavaServer Pages (JSPs), using parts of the InTouch application here named the InTouch Configuration. The InTouch Configuration part of the application connects to a MySQL database through Java DataBase Connectivity (JDBC). The technologies meantioned here are briefly described in section 3.4.4. 3.4.2 Implementation This section describes the source code and config files phase of the MDA development process described in figure 3-1.

3.4.2.1 InTouch Call Handling Implementation The initial source code was generated from the platform dependent UML model with the ArcStyler Java2 MDA Cartridge. The source code produced from this generation was mainly skeletons, containing the metods and class- and association attributes from the model. The source code from the generation was in turn refined (in a text editor) to contain the business logic described in the business model. The scenarios (see section 3.3.1.1 or 2.2.2.2) from the business model provided valuable information for the implementation of the call handling logic, and were used as “blueprints” for the implementation.

53

Changes during the implementation phase affecting the design, was directly updated in the platform dependent UML model, to ensure consistency between the design and the implementation. This is of course important in any object oriented design and implementation, but the MDA process supports it directly with transformations between the models.

3.4.2.2 InTouch Web Configuration Portal Implementation The code generated from the web application model is based on a complete web applications framework, and was so complex that we decided that it would be more efficient to implement the source code manually from the model. This was mainly because of the restricted time limit on the project, and that we would have had to make major customization of the generated code. 3.4.3 Deployment and Testing

3.4.3.1 InTouch Call Handling Since the call handling part of InTouch is a Java application, it was not nessesary to have any deployment configuration files for a specific platform. This follows the choice of Java as the programming language, as Java with its Java Virtual Machine (JVM) is platform independent. The system was tested, but not with the ArcStyler deployment and test tool (C-IX, see 2.2.2.7). This was a choise made due to the distributed nature of the system (parts of the application runs on different servers), and our very subjective opinion of this tool. The choise does not effect the use of the MDA process. The actual testing was done by using the scenario diagrams from the business model. The system was tested by following the “paths” in the scenarios, thus validating the implementation versus the initial business modeling.

3.4.3.2 InTouch Web Configuration Portal ArcStyler supports the Apache/Tomcat Web server, and the code generation produced the nesessary configuration files for the Web Configuration Portal. These files were not used in the actual deployment, as described for the implementation in 3.4.2.2. As with the InTouch Call Handling, the Web Portal was not tested using the ArcStyler C-IX tool. Having no Web Portal business model to base the testing on, this was done in a more ad hoc manner.

54

3.4.4 Technologies used This section briefly describes the technologies used and provides pointers to more detailed presentations. Any technologies providing similar functionality could have been used in this study.

• Java 2 Platform Standard Edition (J2SE) [17]: The Sun Java programming language was the language of choice, and J2SE provided the essential compiler, tools, runtimes, and APIs for the InTouch Call Handling.

• Java 2 Platform Enterprise Edition (J2EE) [18] and JavaServer Pages (JSP) [19]: These

technologies support the InTouch Configuration Web Portal.

o J2EE technology provides a component-based approach to the design, development, assembly, and deployment of enterprise applications.

o JSP technology allows you to easily create Web content that has both static and

dynamic components.

• Common Object Request Broker Architecture (CORBA) [20]: Was used for communicating between the distributed parts of the InTouch Call Handling application. CORBA is OMG's open, vendor-independent architecture and infrastructure that computer applications use to work together over networks.

• MySQL [21]: MySQL is a very popular, easy to use open source database. Both the

InTouch Call Handling and the Configuration Web Portal use a MySQL database.

• Apache Tomcat [22]: Tomcat is the servlet container that is used in the official Reference Implementation for the Java Servlet and JavaServer Pages technologies. The InTouch Configuration Web Portal runs on this platform.

3.4.5 Compliance with the requirements All the functional requirements described in section 3.2.1 were satisfied. The restriction on the implementation described in 3.2.2 was not satisfied. This was, as meantioned before, due to practical problems with the Parlay Gateway at Telenor.

55

http://java.sun.com/products/servlets

http://java.sun.com/products/jsp

3.4.6 InTouch screenshots Figure 3-14 shows a screenshot of the InTouch Configuration customer page for a business customer.

Figure 3-14: InTouch Configuration Portal, the Customer Page

Figure 3-15 and 3-16 shows an InTouch call simulation where 3-15 is the caller. The caller is first redirected to a selected mobile phone, and then to voicemail (as there are no answer neither on the fixed nor the mobile phone).

56

Figure 3-15: InTouch Simulator Console, Caller

Figure 3-16: InTouch Simulator Console, Answer

57

4 Discussion This chapter contains the discussion of MDA (4.1) and ArcStyler and MDA (4.2). Section 4.1 presents strengths and weaknesses with the MDA, while 4.2 discuss ArcStyler and its support for MDA.

4.1 MDA: Strengths and Weaknesses Initially, in section 1.2, we meantioned that the MDA is supposed to ensure:


This discussion looks closer at these points and other issues with the MDA, highlighting strengths and weaknesses. 4.1.1 Strengths An important aspect with the MDA is the focus on formal models: on business modeling and the clear distinction between platform independent and platform specific models and on the transformations between these. After this first hand experience with MDA and MDA development, the immediate reaction to this focus is positive. Figure 4-1 illustrates a more generic version of the MDA development model used in the design chapter (figure 3-1).

58

Platform Specific


files etc. UML Model

Platform 1

Business Model


Platform Specific



Platform 2

Platform Specific



Platform 3 Figure 4-1: MDA Development

The business model is an effective starting point for a high level description of how the system works. The informal requirements from the customer (typically a list of functional requirements) can be described more formally in intuitive models (e.g. CRC cards and scenario type diagrams) readable by customers and domain experts. Designers and customers/domain experts working together on a system model easily understandable by both, ensures that the system functionality is mirrored in the design, increasing application quality. The Platform Independent UML Model is an automatic transformation from the business model, which both saves design time and makes sure that the business model and the platform independent UML model are consistent. In object oriented development today, the design and modeling is usually done with the system architecture in mind from the start. Both the design/modeling and the implementation are done towards a specific platform, greatly reducing the possibility for reuse and portability. The MDA distinction between the PIM and the PSM enables designers to create models independent of the platform, opening the possibility for reuse of models or parts of models from other development projects. Model reuse can also be done more generic by designing domain specific profiles, e.g. for the telecommunications domain. The platform independen UML model in section 3.3.1.1 illustrates this. The Call, Customer, Terminal resources etc. are examples of entities typical for the domain. Generic profiles based on such entities can be reused in several development projects within the same domain. This will again lead to increased reuse and possibly increase the amount of code generated (if the MDA tools provide built in or customized support for these profiles).

59

Another aspect of this model reuse is illustrated in figure 4-1, by the same PIM being transformed to several PSMs, generating code and being deployed on several different platforms. This is a very important feature of the MDA, in a rapidly changing IT world where today’s state-of-the-art technology is tomorrows “junkware”. Porting systems to other platforms and technologies will require a lot less resources, when large parts of the work is done by reuse of PIMs and code generation from MDA tools providing support for the new platform. How much code is generated from the PIM will vary and depend on both the tool supporting the MDA and the semantics of the PIM model the code is generated from. What is certain is that the MDA provides the possibility for large savings in development time with the automatic code generation. The MDA focus on design and modeling will also benefit and increase application quality. As the double arrows in figure 4-1 indicate, the possibility to move back and forth between the models, at different levels of refinement, towards a finished application ensures consistency. We found this formal coupling between the different models very usefull in our MDA development, especially for testing and for validating the implementations compliance with the system requirements. 4.1.2 Weaknesses The MDA is based on several large OMG standards, including the Meta-Object Facility, the Unified Modeling Language and the Common Warehouse Metamodel. It will probably be a major challenge for vendors supplying MDA tools, to support the MDA process to a degree where you reap all the benefits from the technology. Our discussion of the ArcStyler MDA tool (described in the next section) indicates this. The immaturity of the tool support may not be a weakness with the standard, but none the less a challenge for its acceptance. One of the major strenghts of the MDA is, as meantioned before, the focus movement from code and implementation to design and modeling. This will be very beneficial if these models allow major code generation. If not, this design and model focus may seem like extra work on top of all the implementation, with few noticable benefits (maybe even increasing development time!). It is no secret that many programmers dislike design and modeling, though it is definetly critical for the success of the development. Picturing the extreme case where a MDA tool generate and deploy the application with no or only minor code customization, would probably get the most sceptical programmer to embrace MDA development. The question the previous paragraph raises is how well the standards MDA are based on, and then especially UML, provide the possibility for extensive code generation. Model integration requires clear semantics and some of the criticisms of UML has been related to ambiguity and lacking semantics. This is definitely a problem with regards to code generation. Another problem is that the component support is not sufficient for the new component based technology, e.g. J2EE and Microsoft .NET. These and many other issues are addressed in the work on UML 2.0, a revision still in progress at the time of writing.

60

UML 2.0 promises closer support for the MDA, improved support for component developing, architectural specifications, business process modeling, more able meta-data interchange, and more. The next generation of MDA tools based on this specification will probably enable better support for code generation. The Object Constraing Language (OCL) revision will also open for more business logic on the PIM level, opening for more generated platform specific code. One of the suggestions for further work in section 5.3 is to look closer at the MDA, UML 2.0 and to what extent these enable code generation.

4.2 ArcStyler and MDA This section discusses ArcStyler and its support for the key concepts in MDA, looking at modeling in ArcStyler, model transformations, code generation and additional MDA features. The section ends with a brief discussion of ArcStyler in general. It is important to note that ArcStyler is a large and complex tool and that we have only used the core functionality of the Enterprise Edition in our development. This section is not meant to be a complete tool evaluation of ArcStyler, but to highlight the tools support for key MDA concepts in the evaluated case study. 4.2.1 Modeling in Arcstyler

4.2.1.1 Business Modeling The business modeling toolkit was one of the more useful modules of the ArcStyler Entreprise Edition. It was easy to create, manage, restructure and redevelop good CRC cards. Another good feature was the scenario concept, which helped us make the business model consistent in terms of the system requirements. The scenarios were also useful while implementing and testing the InTouch call handling application.

4.2.1.2 PIM and PSM The mapping from a business model to a platform independent UML model in the UML-mapping tool (C-RAS) was simple, and easy to use and understand. The problems began when the model was exported to the UML refinement tool, C-REF. One of ArcStyler’s main weaknesses in an MDA context is that it is built on an existing tool (Rational Rose) which does not support MDA. To get an overview over all the drop down and context menus, understand which functions are ArcStyler specific and which are not, and where to manouvre in the hierarchy can be difficult. Another issue is where does ArcStyler draw the line between a PIM and a PSM?

61

There is no clear or distinct seperation between the platform independent and the platform specific model. The mapping is done on several levels, like implementing stereotypes or selecting appropriate cartridges. The chosen cartridges provide the profile for refinement to a specific platform. When a PIM model is sufficiently refined it has to be saved separately as an .mdl Rose file so that its platform independent properties are not overwritten when platform specific information is added to the model. A better separation between the two types of models would enhance the understanding of MDA modeling in ArcStyler. Another problem is how to know if a feature belongs to ArcStyler or Rose, if these features are integrated, or supported by ArcStyler at all. An example of such a problem is the steps from a PIM model with generic stereotypes, which are refined to a language specific model with specific stereotypes, to code generation based on the model. ArcStyler supports stereotypes on classes, interfaces, method, attributes, and relations, both as generic and java specific stereotypes. Rose supports C++ stereotypes, but what part of the program supports CORBA, and is it possible to generate all the specific code from this model. We tried this, but there was no good way to combine the different classes and interfaces in one model. 4.2.2 Transformations One of the key ideas behind MDA is the distinct separation of the different levels of modeling and development. Because ArcStyler integrates other tools like Rational Rose (compulsary) and JBuilder (optional), this separation is not always clear. The following points try to sum up how ArcStyler approaches MDA transformation:

• PIM to PIM: If you look at both business modeling and platform-independent UML modeling, the PIM to PIM mapping includes the C-BOM business modeller, the C-RAS, business to UML mapper, and the C-REF UML refinement tool. ArcStyler supports the ability to go back in the tool hierarchy from C-RAS back to C-BOM to add additional features, but does not support the same transformation for the C-REF tool. If a model is taken from C-REF back to C-BOM it only shows the classes from the UML model, hence all information about CRC-cards, etc. is lost.

• PIM to PSM: As mentioned earlier it’s not always easy to draw a distinct line between a

platform independent- and a platform specific UML model in ArcStyler. A broader spectre of platform independent stereotypes that easily are mapped to specific stereotypes is something we would have liked in our development.

• PSM to PSM: This refinement is to a certain degree supported. One big problem for our

development though, is that it was not possible to make the model specific to the degree we wanted. It was not possible to model the platform specific UML model with the classes we wanted from the Java API, e.g. set an attribute to be a Java ArrayList. We had to define the attribute as a Collection (in Java, the super class of ArrayList) and manually

62

write the code to use (instansiate) this attribute as an ArrayList. There were several other Java specific API classes that could not be used in the platform specific model, and when used giving errors in the code generation.

• PSM to PIM: The only way to do this transformation in ArcStyler is to manually convert

the platform specific model to a platform independent one. No automated procedures are available.

4.2.3 Code generation The ArcStyler code generation is based on MDA Cartridges supporting different technologies, e.g. Java2, J2EE, .NET etc. (see Appendix A for more on Cartridges). What kind of code and how much code is actually generated, depends on what cartridges are used. An EJB or RMI application will typically generate more of the source code and necessary configuration files, e.g. EJB deployment descriptors, than for example a “regular” Java2 application. The “regular” Java2 application may only generate simple source code skeletons with getter and setter methods (which was the case with our InTouch call handling application). A main disadvantage with ArcStyler code generation is that it only supports the Java programing language. One of the main ideas behind MDA is that a platform independent model can be refined to one or more platform specific models to generate or manually implement code from. When the only platform/language in essence is Java, this feature of MDA cannot be said to be fully supported. 4.2.4 Additional MDA features Zooming is not supported in ArcStyler as the tool is based on the UML 1.4 specification (zooming is part of the new UML 2.0 specification). 4.2.5 ArcStyler in general As mentioned in chapter 4.2.1 both the business modeling and the business to UML mapper tools are very good, easy to use programs. In our opiniton, this is not the case with the UML refiner, C-REF. Adding more complexity to a large development tool like Rational Rose can easily make the tool confusing and difficult to use. The key weaknesses with the C-REF tool are the transformations involving PIM and PSM, poor solutions for stereotypes, integration with Rose and the complexity of the user interface. These are all things that IO-Software could have solved in a different and better way. During business modeling we developed very detailed scenarios that were very helpfull during the implementation of the InTouch business logic. If it had been possible to use the information

63

in the scenarios to automatically generate a UML model for the business logic (e.g. sequence diagrams), which in turn could be used for code generation, this would have been very helpfull. It would also increase the amount of code generated from the platform specific UML model and enabled a closer coupling between the business modeling and the actual implementation. Providing such a feature is probably very complex and would depend on the semantics of the models, and if these could actually support such a transformation unambigously. The modeling of web applications in ArcStyler was relatively simple and easy to understand. It’s actually possible to model an application and get ready-to-run source code, or at least code needing a minimum of customization. A running Tomcat server is also automatically set up for the application to run on. The problem with this feature was that the source code generator is based on a rather complex framework for web applications developed by IO-Software. This causes the code that is generated to be very large (for a small web application) and in our opinion difficult to read and understand.

64

5 Conclusion and further work

5.1 Conclusion and summary This project has looked at the OMGs Model Driven Architecture (MDA) and at one of the few tools supporting this standard, Interactive Objects ArcStyler. The first part of this work was a state-of-the-art survey of MDA and ArcStyler, followed by a MDA devlopment case study; redeveloping the Telenor InTouch service. 5.1.1 MDA Initially, in section 1.4, we posed the following question:

• Will the MDA in practice actually provide increased reuse, reduced development time, ensure portability and increase application quality?

Based on our discussion in section 4.1, our answer is “yes, but it depends...” Increased reuse, and then especially at the model level, is definetly ensured by the MDA. Especially the profile concept following UML 2.0 will enhance this. Portability is ensured by the distinction between the platform independent and the platform specific models, and the transformations between these. PIMs can be transformed to PSMs on several different platforms. The focus on design and modeling will benefit and increase application quality. The possibility to move back and forth between the models, at different levels of refinement, towards a finished application ensures consistency between the initial business model and the actual implementation. Why the “but it depends”? Reduced development time will probably depend a great deal on the quality of the MDA tools and on the MDA support for code generation. Increased reuse and portability will reduce the development time, and so will code generation from the platform specific models. If the code generated is more or less skeletons of the classes modeled in UML (which is already supported in many “pre-MDA” tools), the increased focus and time spent in design and modeling may not reduce the development time. Our experience with the ArcStyler tool indicated this, though it should be meantioned that we did not have any model reuse! The next generation of MDA tools, based on the UML 2.0 specification, will probably have improved code generation.

65

5.1.2 ArcStyler Initially, in section 1.4, we posed the following questions concerning ArcStyler and the MDA:

• Does ArcStyler support MDA adequately? Are there possibility for improvement, to

better support MDA towards gaining the benefits the process promises? Interactive Objects ArcStyler is a first generation MDA tool, heavily integrated with tools that currently do not support MDA. This becomes especially appearant when you look at the lack of distinction between the PIM and the PSM, and the lack of backwards compability in models transformations. Though the tool lack many essential parts of the MDA, the important process from business modeling, through UML model refinement towards code generation and deployment/testing is supported. So the conclusion and answer to the first question is; ArcStyler supports several key aspects of MDA to a certain degree, but adequately? No. There are just too many key MDA features that are not well enough supported. When it comes to possibilities for improvement, there are several things IO-Software can do to gain better MDA support. We have already mentioned the lack of distinction between PIM and PSM, and lack of backwards compability in transformations. Other features to improve include better model transformation support, better stereotype/profile support, and better usability for the UML refinement tool (maybe a separation from Rose would have been beneficial?). 5.1.3 Concluding remarks Our experience with MDA through the case study work was a very positive one. The benefits the MDA suggests will probably have a major influence on future software development, though there are challenges regarding tool support and industry acceptance. When the work with the next UML specification is finished, we will probably see several tool vendors claiming support for the MDA. Much of the acceptance of the MDA will probably rise or fall with how well these tools support the specification. In our opinion, the MDA might well be the developing standard for the future.

5.2 Evaluation of contribution A problem for the project presented here was the scope and timeframe for the work. To set the project scope in perspective, we’ve looked at:

66

• MDA, a technology built upon several large standards. • ArcStyler, a complex development tool. • A discussion of these technologies based on a non-trivial development project.

The concequence of this is that both the discussion of the MDA and of ArcStyler could have been done more indepth. Still we feel that the project has made a good contribution on the MDA, and that we managed to narrow the scope to answer the research questions posed initially.

5.3 Further work There are several possibilities for further work on MDA and MDA tool support. The following is a list of proposed work related to this project:

• Look closer at MDA tool support, e.g. compare ArcStyler and other MDA tools. There are currently few tools supporting the MDA, but several vendors have anounced upcoming support for it. Some of these are probably waiting for the UML 2.0 specification, but there are already alternatives to ArcStyler, e.g. Borland Enterprise Studio and Compuware's OptimalJ. A closer look at MDA tool support could give further insights into MDA development in practice.

• Do a tradeoff study of MDA development vs. traditional object-oriented development. It

would have been interesting to see a development comparison between MDA development, supported by a MDA tool, and traditional object-oriented development supported by “traditional” design tools.

• Couple Parlay and MDA by developing an ArcStyler MDA Cartridge for Parlay. Parlay

is a very interesting specification for the telecommunications domain, and ArcStyler support for this technology would be interesting to explore.

• Look at UML profiles for the telecom domain. A well-defined set of UML profiles for the

telecommunication domain will definetly open the possibility for increased model reuse.

• Look closer at MDA, UML 2.0 and the support for code generation. A closer look at the standards MDA are based on, especially the upcoming UML 2.0 specification, in regards to code generation, would be very interesting. How much application code can we expect to be generated from the next generation of MDA tools? Does MDA and UML 2.0 enable automatic generate, deploy and run applications with a minimum of code customization?

This work done in this project is the basis for a Master Thesis on the MDA, which will look at some of proposals above. The details of this thesis work are at the time of writing not decided.

67

6 References [1] Farshchian, Jakobsson, Berg, “Coupling MDA and Parlay to increase reuse in telecommunication application

development” [2] OMG Architecture Board MDA Drafting Team,

“Model Driven Architecture – A Technical Perspective”, http://cgi.omg.org/docs/ormsc/01-07-01.pdf

[3] Object Management Group, “Meta Object Facility (MOF) Specification”, http://cgi.omg.org/docs/formal/02-04-03.pdf [4] EURESCOM (European Institute for Research and Strategic Studies in

Telecommunications), http://www.eurescom.de

[5] EURESCOM P1149,

“Impacts of changes in enterprise software construction for telecommunications” http://www.eurescom.de/public/projects/P1100-series/P1149/default.asp

[6] MODA-TEL (Model Driven Architectures for Telecommunications System Development and Operation), http://www.eurescom.de/public/ec-programmes/moda-tel.asp

[7] Interactive Objects Software, “Model Driven Architecture at Work”,

http://www.iosoftware.com/news/puclications/english/Workshop_ffeCommerce_0502.pdf [8] Object Management Group,

“Common Warehouse Metamodel (CWM) Specification”, http://cgi.omg.org/docs/fomal/01-10-01.pdf

[9] Object Management Group, “OMG Unified Modeling Language Specification”, http://cgi.omg.org/docs/formal/01-09-67.pdf [10] Object Management Group, “OMG XML Metadata Interchange (XMI) Specification”, http://cgi.omg.org/docs/formal/02-01-01.pdf

[11] Interactive Objects Software,

“The Architectural IDE for MDA”,

68

http://cgi.omg.org/docs/ormsc/01-07-01.pdf

http://cgi.omg.org/docs/formal/02-04-03.pdf

http://www.eurescom.de/

http://www.eurescom.de/public/projects/P1100-series/P1149/default.asp

http://www.eurescom.de/public/ec-programmes/moda-tel.asp

http://www.iosoftware.com/news/puclications/english/Workshop_ffeCommerce_0502.pdf

http://cgi.omg.org/docs/fomal/01-10-01.pdf



http://www.io-software.com/as_support/factsheets/iO.ArchStyler_Overview.pdf [12] Interactive Objects Software,

“ArcStyler Modelling Style and User’s Guide for ArcStyler 3.0”, http://www.io-software.com/as_support/docu/Users_Guide.pdf [13] Jon Siegel and the OMG Staff Strategy Group

"Developing in OMG's Model Driven Architecture (MDA)" ftp://ftp.omg.org/pub/docs/omg/01-12-01.pdf

[14] Telenor InTouch User Manual, http://intouch.telenor.no/InTouch/intouch/brukerstyring/InTouch_innmat_15042002.pdf [15] Telenor InTouch web site, http://intouch.telenor.no/InTouch/intouch/ [16] The Parlay Group, http://www.parlay.org/ [17] Java 2 Platform, Standard Edition (J2SE), http://java.sun.com/j2se/ [18] Java 2 Platform, Enterprise Edition (J2EE), http://java.sun.com/j2ee/ [19] JavaServer Pages, http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/JSPIntro.html [20] Common Object Request Broker Architecture (CORBA), http://www.omg.org/gettingstarted/corbafaq.htm [21] MySQL, http://www.mysql.org/ [22] Apache Tomcat,

http://jakarta.apache.org/tomcat/

[23] Interactive Objects Software, “ArcStyler Extensibility Guide For ArcStyler 3.0”,

http://www.io-software.com/as_support/docu/extensibility_guide.pdf [24] Richard Soley and the OMG Staff Strategy Group,

“Model Driven Architecture”, ftp://ftp.omg.org/pub/docs/omg/00-11-05.pdf

69

http://www.io-software.com/as_support/factsheets/iO.ArchStyler_Overview.pdf

http://www.io-software.com/as_support/docu/Users_Guide.pdf

ftp://ftp.omg.org/pub/docs/omg/01-12-01.pdf


http://intouch.telenor.no/InTouch/intouch/brukerstyring/InTouch_innmat_15042002.pdf

http://intouch.telenor.no/InTouch/intouch/

http://www.parlay.org/

http://java.sun.com/j2se/

http://java.sun.com/j2ee/

http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/JSPIntro.html

http://www.omg.org/gettingstarted/corbafaq.htm

http://www.mysql.org/

http://jakarta.apache.org/tomcat/

http://www.io-software.com/as_support/docu/extensibility_guide.pdf


[25] Colin Atkinson “The Role of Metamodeling in MDA” http://www.metamodel.com/wisme-2002/papers/atkinson.pdf [26] Interactive Objects Software “ArcStyler Accessor Tutorial” http://www.io-software.com/as_support/docu/Accessor_Tutorial.pdf

70

http://www.metamodel.com/wisme-2002/papers/atkinson.pdf

http://www.io-software.com/as_support/docu/Accessor_Tutorial.pdf

7 Appendix

7.1 Appendix A: ArcStyler Cartridges and Extensibility With the ArcStyler Architect Edition and its MDA-Cartridge IDE, an organization can visually develop, test and deploy MDA support to meet its specific requirements. This can be done by either extending existing MDA support or developing cartridges for completely new types of infrastructures and architectures. ArcStyler enables model transformation (model-to-model and model-to-code) according to the OMG’s MDA. Model transformations accepts an input model and a set of annotations based on a UML Profile and map it to one or more output models, output code or other infrastructure. The metamodels defining the source and the target models normally differ. The current ArcStyler versions are shipped with a metamodel based on UML 1.3. New annotations to create MDA support for new UML Profiles are expressed in ArcStyler by using standard UML extensibility features such as properties and stereotypes. A model transformation is implemented in an MDA-Cartridge. In addition to containing transformation rules, a cartridge can provide verification rules, which when applied to an input model, check the model for correctness with regards to the transformation implemented by the cartridge. A set of standard MDA-Cartridges is available with ArcStyler, providing MDA support for Java2, J2EE, .NET and CORBA. The next sections describe in more detail the ArcStyler Cartridge concept and architecture [23].

71

7.1.1 The Cartridge Runtime Environment

Executes

C-GEN CartridgeUses output

Access additional configuration Access source

C- C-CFG

Figure 7-1: Overview of Cartridge Runtime Environment

Figure 7-1 illustrates the Cartridge Runtime Environment. The cartridge contains a set of features that are executed by the C-GEN module. C-GEN passes a set of elements from the source model to the cartridge feature. These elements are initial references into the C-MOD model repository that the cartridge use to navigate through the source model and that indicate to the cartridge which pieces of the model shall be handled by this call. In addition to the source model, the cartridge may obtain input from configuration settings, made accessible by the ArcStyler C-CFG module. A simple example of a configuration setting is the cartridge output directory. When creating a text-based target model, a cartridge will make use of the C-GEN’s APIs that provide means for text-based artefact management. This includes stream management and management of the editable protected areas described in section 2.2.2.5.

72

7.1.2 ArcStyler Model Transformation

Figure 7-2: Model transformation from UML to text [23]

An MDA Cartridge transforms source models into target models, e.g. UML-based source models into text-based target models. Models consists of a set of model elements, e.g. a UML model consists of classifiers, operations, attributes, associations etc., whereas a text-based model consists of ASCII files containing ASCII characters. The main purpose of the cartridge is to specify how the elements of the source model affect the creation of the elements of the target model. The cartridge structure consists of four key concepts:

• Artifacts are elements of the target model that are created during the transformation, e.g. a file for a text-based model.

• Artifact Sections (or Generatables) are elements of the target model that are subordinated to an artifact and cannot stand alone, e.g. a region in a file for a text-based model.

• Artifact Sets group artifacts that are always created together, triggered by some condition based on the source model.

• Blueprints know how instances of a particular source metamodel type, e.g. an operation or an attribute, are represented in the various contexts defined by artifacts and artifact sections.

73

7.1.3 CARAT – The ArcStyler Cartridge Architecture The ArcStyler Architect Edition has a JPython framework for cartridge development, called the CARAT Foundation. This framework structures the model transformation process, in particular transformations into text-based target models. The previous section introduced the four key cartridge structures: Artifact, Artifact sections, Artifact sets and blueprints. These lead to two natural structural patterns in the implementation of a cartridge:

• The first pattern structures parts of the cartridge according to the artifact structure: Artifact sets, artifacts and artifact sections.

• The second pattern structures parts of the cartridge according to the input metamodel: Attributes, operations, features, classifiers, etc.

7.1.3.1 CARAT Foundation The most important general means for structuring in CARAT is a composition pattern, CARATComposite, and together with the Selector class, this pattern makes up the main abstractions in the CARAT Foundation (see Figure 7-3). The most important methods to notice here are the perform, mapModelElement and dispatch methods. The perform method is the entrypoint into the CARATComposite instance’s functionality. This method gets passed a single model element, which are mapped by the mapModelElement method. For each model element returned from the mapping, the perform method executes the beforeOperation (if valid), followed by the dispatch method and the afterOperation (if valid).

74

Figure 7-3: Main Abstractions in CARAT Foundation [23]

Instances of CARATComposite can have other instances of the same class as their subs (subordinate composites). A typical example for the use of this relation would be artifact sets that have the artifacts of which they are constituted as their subs. Selectors are special CARATComposites that are tied to a specific model element. An example would be a class that knows how to generate contributions for an attribute model element in all kinds of contexts. It would hold the attribute model element in its modelElement member. The SelectorRegistry decides how to retrieve the appropriate selectors from a set of selectors for a given model element.

75

7.1.3.2 The Generatable Hierarchy An important specialization of CaratComposite is the Generatable class. It defines two operations, generate and finishedGeneration which are intended to be used as the beforeOperation and afterOperation for a perform call on a Generatable (see figure 7-4).

Figure 7-4: The Generatable Hierarchy [23]

The generate operation can be used by subclasses of Generatable to deliver their contribution to the generation process. Possible actions are, e.g., to ask the generator to open a stream, writing output to the generator’s current stream, or simply return a value that one of the triggering CARATComposite instances can postprocess. The subclasses of the Generatable class include:

• Artifact, which adds knowledge of managing generator output streams.

76

• TemplateBasedArtifact and OverwritableTemplateBasedArtifact, which are specialized Artifacts that add knowledge of generating an artifact from a template file and to manage output files.

• OverwritableTemplateBasedArtifac and TemplateBasedArtifactWithNoEditClass are further specializations dealing with the generation of editable files needing timestamp control (described in section 2.2.2.5) and no edit files.

• Blueprint and ArtifactSet, are special in the way that they also inherit from the Selector class.

For more detailed information on how the classes described here interact and make up the CARAT Foundation, please refer to the ArcStyler Extensibility Guide [23]. 7.1.4 Building and Extending ArcStyler Cartridges Figure 7-5 shows an overview of the ArcStyler C-GEN Framework. Each cartridge offers a set of cartridge features that can be queried dynamically by calling the cartridge describe method. The resulting cartridgeFeature instance indicates the name of the provided features, a user interface representation that can be used for a GUI presentation, and an optional reference to the cartridge’s root generatable that can be used to configure the pieces of the cartridge to be executed.

Figure 7-5: ArcStyler C-GEN Framework (Top-Level) [23]

Each cartridge can define a set of cartridge properties that provide an easy and standardized way for the user to specify additional configuration information for the cartridge. An example of a

77

78

cartridge property is the usePrecompiled that tells the C-GEN framework wether to use the precomiled version of the cartridge implementation: <cartridge_properties name = ”usePrecompiles” type = ”Boolean” label = “Use precompiles templates” defaultvalue = “false” category = “Generator” /> The ArcStyler configuration stored in an instance of the class ConfigModel keeps information concerning which cartridges are currently loaded and usable. This information is used for configuring the execution of a generator run. The Generate class’ execute method is called when a user requests a generator run, to perform a single feature of one or more cartridges for a set of model elements. The other methods in this class implement the logic for artefact generation and management. An implementation of a cartridge consists of at least an instance of the TPRInfo class or one of its subclasses. This instance is initialized from the contents of an XML file which is expected to use the filename extension .tpr. The standard implementation provided by TPRInfo uses a JPython implementation of the cartridge interface which it delegates. For this purpose the TPRInfo instance is associated with a PythonInterpreter which it initializes from the .tpr file, loading all JPython definitions contained in the .py and .inc files that are referenced in the .tpr file. The cartridge developer is free to implement all operations specified by the cartridge interface in the JPython class. Though is possible to implement all the operations, it is recommended to utilize the functionality of the CARAT Foundation Framework described in section 7.1.3.1. A standard ArcStyler cartridge (the CARAT Cartridge) is provided and supports the generation of cartridges from UML models in the ArcStyler Architect Edition. For more information on MDA Cartridge Development with ArcStyler, please refer to the ArcStyler Extensibility Guide [23].

Model Driven Architecture (MDA) for Telecom application ... · This report discusses the Object...

Documents

Transcript of Model Driven Architecture (MDA) for Telecom application ... · This report discusses the Object...