An Emphasis on the need for IDE/ITE A Step ahead into the Modeling Technology

S.N.Sivanandam Professor and Head B.Swaminathan S.Bharath C.P.Jagannath G.Sriram Department of Computer Science and Engineering P.S.G College of Technology, Coimbatore - 641004. G.R.Karpagam Asst. Professor

Abstract The increasing number and variety of platforms has forced the IT industry to design and develop applications that are compatible with the targeted platforms. However, the contemporary approach is proving costlier and time consuming. Thus, the need for the two key aspects of software engineering viz., reusability and interoperability are realized to a great extent. Fully specified platform independent models can enable intellectual property to move away from technology-specific code, helping to insulate business applications from technology evolution, and further enable reusability, interoperability and portability. Model-Driven Architecture (MDA) is an approach to system-specification and interoperability based on the use of formal models that separates the functionality from the implementation of that functionality on a specific technology platform. Models developed so using MDA tools become dependent on the tool and hence such a model cannot be used in another tool. This work aims to propose an IDE/ITE (Integrated Development Environment/Integrated Transformation Environment) that encompasses a modeling environment and interpreters that can transform a model of any particular tool into a standard model and vice-versa thereby providing tool independency.

1. Introduction The current trend of object technology could not provide solutions for increasing volume of data, increase in business issues and heterogeneity of platforms and languages. The complexity of the software development and the software itself needs to be managed

not via code but via models. Hence modeling technology which provides solution to the above problem needs to be adopted. Modeling, in the broadest sense, is the cost-effective use of something in place of something else for some cognitive purpose. It allows us to use something that is simpler, safer or cheaper than reality instead of reality for some purpose. This allows us to deal with the world in a simplified manner, avoiding the complexity, danger and irreversibility of reality. The Object Management Group s Model-Driven Architecture (MDA) is an approach to system-specification and interoperability based on the use of formal models. A model represents reality for the given purpose (the model is an abstraction of reality in the sense that it cannot represent all aspects of reality). The MDA separates certain key models of a system and brings a consistent structure to these models thus making the modeling technology invaluable. In course of time, a number of tools that assist the modeler in developing such models have emerged.

2. Model Driven Architecture 2.1 Need for MDA Everything is an object was one of the strongest technology improvements in the last twenty years. As long as this principle was followed, steady progresses were achieved. But as time passed, the OT (Object Technology) had to face many problems such as Increasing Volume (Data, Code, functional and non-functional Aspects) Increasing evolution of the business part (globalization, concentrations, reorganizations, increasing competition, etc.,) and the execution platform. Increasing heterogeneity (languages and paradigms, data handling and access protocols, operating systems and middleware platforms, technologies) OT did not succeed in finding good internal solutions to these challenges. The MT (Model Technology) based on the principle that Everything is a model , was in a position to meet some of these challenges to which OT was not able to find internal solutions [2, 4]. MT seems able to subsume OT and to offer a realistic migration path from present object and component solutions to more ambitious regular and scalable

organizations. But there is a problem of model transformation from one model to the other. The OMG's MDA is aimed at using modeling and meta-modeling to drive the design and implementation of distributed systems. Business applications freed from technology specifics will be able to evolve at a different pace. Technology neutral models of systems can be mapped to implementations that use a variety of middleware technologies. MDA aims to separate the application logic from the underlying platform technology [4]. It provides an open, vendor-neutral approach to the challenge of business and technology change. A technology independent model would help bring about Reusability of components Interoperability & portability across platforms. MDA development focuses first on the functionality and behavior of a distributed application or system, undistorted by idiosyncrasies of the technology or technologies in which it will be implemented [3]. MDA divorces implementation details from business functions. Thus, it is not necessary to repeat the process of modeling an application or system's functionality and behavior each time a new technology (e.g., XML/SOAP) comes along. Other architectures are generally tied to a particular technology. With MDA, functionality and behavior are modeled once and only once. The MDA approach and the standards that support it allow the same model specifying system functionality to be realized on multiple platforms through auxiliary mapping standards, or through point mappings to specific platforms, and allow different applications to be integrated by explicitly relating their models, enabling integration and interoperability and supporting system evolution as platform technologies come and go. Thus, the MDA approach future-proofs the design and provides the advantage of smooth integration across intra and inter-business boundaries thereby lowering costs and maximizing reusability.

2.2 MDA Concepts Recently, the Object Management Group introduced the Model-Driven Architecture (MDA) initiative as an approach to system-specification and interoperability based on the use of formal models. In MDA, platform-independent models (PIMs) are

initially expressed in a platform-independent modeling language, such as UML. The platform-independent model is subsequently translated to a platform-specific model (PSM) by mapping the PIM to some implementation language or platform (e.g., Java) using formal rules. At the core of the MDA concept are a number of important OMG standards: The Unified Modeling Language (UML), Meta Object Facility (MOF), XML Metadata Interchange (XMI), and the Common Warehouse Metamodel (CWM). These standards define the core infrastructure of the MDA, and have greatly contributed to the current state-of-the art of systems modeling. The core standards of the MDA (UML, MOF, XMI, and CWM) form the basis for building coherent schemes for authoring, publishing, and managing models within a model-driven architecture [2]. The MDA has significant implications for the disciplines of Metamodeling and Adaptive Object Models (AOMs). Metamodeling is the primary activity in the specification, or modeling, of metadata. Interoperability in heterogeneous environments is ultimately achieved via shared metadata and the overall strategy for sharing and understanding metadata consists of the automated development, publishing, management, and interpretation of models. AOM technology provides dynamic system behavior based on run-time interpretation of such models. Architectures based on AOMs are highly interoperable, easily extended at run-time, and completely dynamic in terms of their overall behavioral specifications (i.e., their range of behavior is not bound by hard-coded logic).

2.3 Models in MDA 2.3.1 What is a model? In the MDA, a model is a representation of a part of the function, structure and/or behavior of a system. A specification is said to be formal when it is based on a language that has a well defined form (syntax), meaning (semantics), and possibly rules of analysis, inference, or proof for its constructs. The syntax may be graphical or textual. The semantics might be defined, more or less formally, in terms of things observed in the world being described (e.g. message sends and replies, object states and state changes, etc.), or by translating higher-level language constructs into other constructs that have a

well-defined meaning. The optional rules of inference define what unstated properties you can deduce from the explicit statements in the model. In the MDA, a specification that is not formal, in this sense, is not a model. Thus a diagram with boxes and lines and arrows that does not have behind it a definition of the meaning of a box, and the meaning of a line and of an arrow is not a model it is just an informal diagram. An MDA model

must be paired unambiguously with a definition of the modeling language syntax and semantics, as provided by the MOF. In this sense, a UML-based specification is a model whose properties can be expressed graphically via diagrams, or textually via an XML document.

2.3.2 Architecture of MDA models The MDA separates certain key models of a system and brings a consistent structure to these models. The models of different systems are structured explicitly into Platform Independent Models (PIMs), and Platform Specific Models (PSMs). How the functionality specified in a PIM is realized is specified in a platform-specific way in the PSM, which is derived from the PIM via some transformation. Computation Independent Model is one in which the Computational details are hidden or as yet undetermined. It is sometimes referred to as the business domain model. Platform Independent Model provides formal specifications of the structure and function of the system that abstracts away technical details. A Platform Independent Component View describes computational components and their interactions in a platform-independent manner. These components and interfaces, in turn, are a way of realizing some more abstract information system or application, which itself helps realize a computation independent Business Model. Platform Specific Model combines the specifications in the PIM with the details that specify how that system uses a particular type of platform. A PSM is expressed in terms of the specification model of the target platform.

2.3.3 Transformation of models In MDA, one of the key features of the whole approach is the notion of mapping. A mapping is a set of rules and techniques used to modify one model in order to get another model. Mappings are used for transforming: PIM to PIM transformation is used when models are enhanced, filtered or

specialized during the development lifecycle without needing any platform dependent information. One of the most obvious mappings is the analysis to design models transformation. PIM to PIM mappings are generally related to model refinement. PIM to PSM transformation is used when the PIM is sufficiently refined to be projected to the execution infrastructure. The projection is based on the platform characteristics. Describing these characteristics should be done using a UML description (and eventually a profile for describing common platform concepts). Going from a logical component model to a commercial existing component model is a kind of PIM to PSM mapping. PSM to PSM transformation is needed for component realization and

deployment. For example, component packaging is done by selecting services and preparing their configuration. Once packaged, the components delivery could then be done by specifying initialization data, target machines, container generation and configuration, etc. PSM to PSM mapping are generally related to platform dependent model refinement. PSM to PIM transformation is required for abstracting models of existing implementations in a particular technology into a platform-independent model. This procedure often resembles a "mining" process that is hard to be fully automated. It may be supported by tools, though. Ideally, the result of this mapping will match the corresponding PIM to PSM mapping.

2.4 Modeling Tools Designing, building, programming and configuring computer systems are tasks with a level of complexity that has been previously unseen. Modeling has been given a boost by the computer age in several ways. Computer programs can now be used to build

models. The application is straight forward: convenient graphical interfaces provide drawing and visual presentation for models, while the programming logic beneath maintains and enforces strict compliance with modeling rules. Computers are also suitable for automatic processing of models, thus making maximal use of them. While manual process is tedious, all kinds of information (lists, reports, executable code, documentation, etc.,) can be extracted and formatted from the model data at the press of a button once the data has been inserted into a computer system. In course of time, various modeling tools have evolved which aid in building models and thus helping the modeler to clearly understand and define the crux of the problem domain [9].

3. Investigations on need for IDE/ITE The modeling tools host many features that aid the modeler in defining, managing, validating and customizing the models. On studying the various tools, the following were found to be the key features of a modeling tool: Layers/Levels of Modeling supported Modeling standards supported Managing projects Defined semantics and syntax (Tool Meta model) Support for various viewpoints of the model Workbench for modeling Store models textually in a standard language (such as XML) Import models Code Generation User-friendliness

3.1 Tool Dependency The models developed in a particular tool are strongly bound to the syntax and semantics of the tool. The inability of the tool to understand a model developed using another tool and represented using a language such as XML which is the same used by the former, is the cause of tool dependency. With the increasing number of modeling tools, the organizations face a serious problem when trying to migrate from one tool to

another. Also, as different organizations adopt different tools, models developed by an organization cannot be used by another, thereby the very idea of reusability being mislaid. Thus, there is a problem of tool dependency in the sense that the models developed using the various modeling tools become dependent on these tools. The underlying idea can be clearly understood by the following study. Let us consider a common domain such as an internet banking system to illustrate the idea of tool dependency vividly. The MDA modeling tools GME (Generic Modeling Environment) and Arc Styler are chosen to best illustrate the given problem. GME is a generic, configurable modeling environment [11]. The configuration process itself is a form of modeling - the modeling of a modeling process. This is called meta modeling. The output of the meta modeling process is a compiled set of rules, the paradigm that configures GME for a specific application domain.

Figure 1 Model for Internet Banking System In the model shown in Figure 1, the customers can access their accounts through a web server which is connected to the bank s server. The customers are authenticated and authorized by the authenticating server and the security service provider. This model captures the various aspects of the Internet Banking System.

The tools like GME and Arc Styler[10] support features to export the model to a standard language such as XML and also import models. But a model in XML can be imported into a particular tool if and only if the model has been modeled using that tool, thus implying tool dependency. The model of an Internet Banking System modeled using Arc Styler was converted to a standard language such as XML using its Export feature. However when the same was imported into GME, a parsing error occurred as shown in Figure 2. This is because the representation and interpretation of the models in different tools vary widely. Thus the tool dependency of the models is clearly exemplified from the above investigation.

Figure 2 Error Importing XML file.

3.2 Achieving Tool Independency The implementation of the models varies largely from tool to tool. So, the overhead involved in reproducing the models again will disavow the very purpose of modeling. Hence, the need for tool independency is greatly realized. Such a property, inherent, can be provided only by a tool that encompasses the various inter-tool transformation programs.

Figure 3 XML Codes of GME and Arc Styler Hence in order to realize the real importance of achieving tool independency we need to take a look into the above investigation. Shown above in Figure 3 are the XML codes of the Internet Banking System in GME and Arc Styler respectively. On examining the two XML codes it is evident that there is a subtle variation in the representation of the models via XML code by the various modeling tools. Hence there is a need to develop an IDE/ITE in order to facilitate interoperability of models between tools thus satisfying the issue of tool independency.

3.3 IDE/ITE The aspects of the development environment that our proposal aims at can be understood in two folds. First, the transformation facility that converts the existing models from a particular tool to this environment and models from this environment to other tools that the environment supports. Second being the development facility it hosts to create models of its own and to work on models that hail from other tools. The concept of transferring a model from one tool to the other is bisected into two equally important transformations, from a tool to the IDE and IDE to a tool. This is because the idea of "directly" transforming the model doesn t provide the modeler an

opportunity to create or modify the model in the standard form provided by the IDE/ITE. The modeler must be given the facility to work on the models from other tools, to either enhance or to store them for later use. This will strongly support the idea of reuse of abstractions as emphasized by MDA.

Figure 4 Snapshot of the proposed IDE/ITE Our proposed IDE leverages Extensibility Customization Ability to plug-in transformation programs for new tools Storage of models Support for development of component level models guided by MDA The Integrated Transformation Environment (ITE) is a repository of transformation utilities. The ITE initially converts a given model in a particular tool to the model that can be represented in the IDE. The ITE imports the models in textual format using a standard language such as XML. The transformation utility parses through the given textual model and extracts the details. These abstract details are organized into a standard model that can be used in the IDE. The standard model can be transformed

into any tool for which the Transformation rules have been identified and defined. Whenever a new tool is to be added into the ITE, a thorough study of the structure in which the new tool stores the models is identified. An interpreter is then written to transform the model to the standard IDE format. Our proposed IDE/ITE can be customized to a specific context with its derived constraints and its objectives. The IDE would thus aid the organizations to reuse models developed by other organizations enabling tool migration thereby providing a panacea for tool dependency.

4. Summary and Suggestion Our proposed IDE/ITE provides a comprehensive solution to the contemporary problems viz., inability to achieve reusability and interoperability, and tool migration in the software industry. IDE/ITE not only provides solution to these problems but also pertain to the MDA standards. Nevertheless, developing such an IDE/ITE requires an in depth analysis and understanding of the syntax and the semantics of the various modeling tools. Such proposals are not only made for descriptive reasons but are intended to support a strong operational view for an interoperability framework for a model management. The key feature of the IDE/ITE is to represent the model in a standard form such as XML. When this model is abstracted to a higher level what we might obtain is a MDA component[13, 14]. An MDA component must comprise the following properties, Independent of any given proprietary platform. Independent of any given specific CASE TOOL. Can be STORED and RETRIEVED in a UNIFORM way. Can be deployed in the context of different software process or methods.

Thus an IDE/ITE that can store models in the form of MDA component enables one to integrate what you've built, with what you're building, with what you're going to build .

REFERENCES [1] S.N.Sivanandan, G.R.Karpagam. Using MDA for implementing security services in distributed systems , International Conference on Advanced Computing, PSG College of TechnologyDecember 17-20, 2003 [2] [3] MDA Guide (2003). Version 1.0, Object Management Group, omg/2003-05-01. J. Miller and J. Mukerji, "Model Driven Architecture (MDA)", OMG: Specification. 2001. p. 31. [4] [5] Richard Mark Soley, OMG Model Driven Architecture , www.omg.org. D'Souza, D., "Model-Driven Architecture and Integration: Opportunities and Challenges", Version 1.1. [6] John D. Poole, Model-Driven Architecture: Vision, Standards And Emerging Technologies . [7] Jean Bzivin, Sebastein Gerard, Pierre-Alain Mullar, Laurent Rioux, MDA components: Challenges and Opportunities , France, http://www.sciences.univnantes.fr/Metamodelling4MDA.York/MDAComponentsC hallengesOpportunities.V1.3.PDF. [8] OMG Architecture Board ORMSC; Model Driven Architecture (MDA) . July 9, 2001 http://www.omg.org/cgi-bin/doc?ormsc/2001-07-01 [9] Mike Rosen, Which MDA Tools are Right for You?

[10] ArcStyler Web Site, Interactive Objects Software, 2002. http://www.iosoftware.com. [11] GME 2000 and MetaGME 2000, Institute for Software Integrated Systems, Vanderbilt University, 2002. Available at http://www.isis.vanderbilt.edu [12] Objecteering / UML Web Site, Objecteering Software SA, 2002. http://www.objecteering.com [13] Jean Bezivin, MDA components: Challenges and Opportunities, available from www.omg.org. [14] J. Bzivin and S. Grard, "A Preliminary Identification of MDA Components", OOPSLA 2002 Workshop: Generative Techniques in the context of Model Driven Architecture. 2002.