The new IBM Rational design and construction products for Rose and XDE users

Transcription

1 The new IBM Rational design and construction products for Rose and XDE users For Rose and XDE users who want to come to grips with the new, automated model-driven development paradigms manifested in the new family of IBM Rational modeling tools William T. Smith Product Manager IBM Software Group V 0.03 November 17, 2005

2 Table of Contents Notices Introduction...6 Intended Audience...6 Scope and Other Resources...6 Organization Basic Concepts and Terminology...8 Levels of Abstraction...8 Models...8 Diagrams...8 Metamodels...8 Model Taxonomies...9 Conceptual Models and Conceptual Modeling...10 Implementation Domain Models and Implementation Domain Modeling...10 Code-Model Synchronization, a.k.a. Round Trip Engineering, in Rose and XDE...11 Implementation Domain Modeling in RSA and IRAD...12 Why The Change from RTE to 3GL Domain Modeling?...14 Topic Diagrams...15 Browse Diagrams...15 Patterns and Pattern Assets...16 Transformation and Transformation Assets...19 Asset-Based Development...21 Mixing Metamodels and Abstraction Levels...23 Code Harvesting...27 Transformation Options...31 Reverse and Inverse Transformations...32 Reconciliation Common Approaches To Modeling...35 Models as Documentation of Implementations...35 Models as Implementation Level Development Tools...35 Disposable or Replaceable Models...39 Models as Blueprints...39

3 Basic Model Driven Development...40 Hybrid Approaches Automated Model Driven Development...43 Automated MDD Fundamentals...43 Iteration and Reconciliation...45 Heterogeneous Development...50 Business Value of Automated MDD Summary and Conclusion...55 Appendix A: Rose/XDE and New Tools Theories of Operations Compared...56 Common Misconceptions...56 The new tools do not support Reverse Engineering...56 The new tools do not support Round Trip Engineering...56 Rose and XDE Round Trip Engineering keeps the implementation in sync with a design model...56 Development Cases Compared...57 Scenario: Model Driven Approach, New Development...57 Scenario: Reverse Engineering...59 Scenario: Incorporating Existing Code As Part of New Development...61 Appendix B: Business-Driven Development...63 References...64 Additional Resources...65 Notices This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-ibm product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

4 This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-ibm Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-ibm products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-ibm products. Questions on the capabilities of non-ibm products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces. Copyright IBM Corp All rights reserved. Page 4 of 66

5 Trademarks The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: IBM Rational Unified Process Rational RUP Rational Rose XDE WebSphere Redbook developerworks The following terms are trademarks of other companies: EJB, Java, Javadoc, JVM, J2EE, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Microsoft, Visual Studio, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Model Driven Architecture is a trademark of the Object Management Group Other company, product, and service names may be trademarks or service marks of others. Copyright IBM Corp All rights reserved. Page 5 of 66

6 1. Introduction Intended audience This article is offered in the spirit of the [Pick Your Topic] for Dummies books. Obviously, those books are not targeted at dummies. They are offered as a vehicle to help you quickly grasp the major concepts of a new subject area. Similarly, this article is intended to help you and other users of IBM Rational Rose and IBM Rational XDE (XDE) grasp some of the major new concepts they will encounter as they migrate to the newer family of IBM Rational model driven development tools: IBM Rational Software Architect (RSA), IBM Rational Software Modeler (RSM), and IBM Rational Application Developer (IRAD). Through the rest of this article, RSA, RSM, and IRAD will sometimes be referred to collectively as the new tools or the new products. The new tools reflect a Russian Doll packaging model; that is, RSA represents a superset of RSM plus IRAD, with RSM and IRAD each available as a separate product offering. This is illustrated in Figure 1 (the lists of product features are highlights, and by no means complete). Rational Software Architect Mix UML Modeling and Domain Modeling Java Static Code Analysis C++ Development Tools UML-to-Java, UML-to-EJB, and UML-to-C++ Transformations Rational Software Modeler UML Modeling and Publishing MDD Automation Asset Development Profiles Pluglets Patterns Transformations Reusable Asset Management Integrated Requirements Management Supports Business Driven Development when used with WebSphere Business Integration Modeler Rational Application Developer Professional Java EE and Web Services IDE Java, EJB, and Data Domain Modeling Web Development Tools Enterprise Integration Tools (e.g. J2C) Figure 1: Overview of new IBM Rational modeling tools architecture Scope and other resources As a Rational Rose or XDE user who is new to these tools, you have a number of adjustments to make. One example is adjusting from UML 1.x to UML 2.0. Another is adjusting to a different look-and-feel and a more streamlined set of diagramming gestures. This article does not cover these issues, and therefore won t help you make those adjustments (for help with those topics, see the Resources section). This article is concerned with some basic model-driven development concepts, and even more specifically with the differences in the theory of operations between Rational Rose or XDE, and the new tools. While the article describes how to apply the features and techniques of the new tools to a variety of development scenarios, it does so briefly and in the abstract. It does not offer a detailed case study per development scenario, nor does it include step-by-step instructions for using any of the new tools Copyright IBM Corp All rights reserved. Page 6 of 66

7 features. For such case studies, check out the RSA Samples Gallery and Tutorials Gallery in the Resources section. You can also check for additional resources on developerworks. A deeper discussion of the technologies (such as the Eclipse Modeling Framework) that enable the new product capabilities may be found in the References section; see [Nally, Leroux, and Hussey]. A higher level, market-oriented view of the evolution of the IBM Rational modeling product lines may be found in [Cernosek]. Organization Following this introductory section, Part 2 will introduce Basic concepts and terminology to establish a working vocabulary, and to provide some general information about how models and diagrams are implemented in the new tools. Some of the new tools approaches and capabilities are compared and contrasted with Rational Rose and XDE in this section. Part 3 looks at some of the ways models are used in developing software and the kinds of value that can be realized from different approaches to the use of modeling. The purpose of Part 3 is to provide a general context for the discussions in Part 4 and in Appendix A. Part 4 introduces automated model-driven development, which is really just a handy name for the kind of process the new tools were designed to support. This section will look at various aspects of that process, as well as how it can be applied across enterprises that develop for a heterogeneous mix of runtime platforms. We ll also discuss the business value that can be realized by applying this process. Part 5 just recaps the high points from Parts 1 through 3, and throws in a little pitch on why you should consider migrating to the new tools. Appendix A is for those who, after reading this article, still want a fuller comparison of the key differences between the Rational Rose and XDE theory of operations, and that of the new tools Appendix B is a very brief description of business-driven development, which can be thought of as an extension of automated model-driven development that shifts the use of modeling to earlier in the lifecycle, in other words to business process modeling and the use of business process models to drive systems development. Copyright IBM Corp All rights reserved. Page 7 of 66

8 2. Basic concepts and terminology Levels of abstraction Abstraction is a powerful and widely-used technique for developing complex systems. As a complement to problem decomposition, it improves outcomes in terms of system quality and time-to-value. Specifications formulated at higher levels of abstraction help manage complexity by initially concealing certain details that can be elaborated later. Put another way, abstraction is about separating concerns. Applying principles of abstraction throughout the development process leads to implementation that separates concerns with intelligent, automated, repeatable mediation between them. Models As a user of Rational Rose or XDE and a seasoned modeler, you know that a model is a complete specification of a problem or solution domain from a particular perspective. Models are created using a well-defined language with well-defined semantics. A problem domain or a yet-to-be-built system may be specified by a number of models that represent different perspectives and levels of abstraction. Diagrams A common misconception on the part of those who have never worked with modeling tools is that models equate to diagrams. As a Rational Rose or XDE user, you know that in fact they are distinct concepts: A model is a collection of semantic information plus diagrams. A diagram is a projection of a particular view of the semantic information. So a single semantic element -- such as a Class element in a Unified Modeling Language (UML) model -- might appear in zero or more diagrams within the UML model. And a UML model can contain zero or more diagrams. Metamodels As a user of Rational Rose or XDE, whenever you think of a model you are probably inclined to think of a UML model. A UML model is a type of model that is good for expressing a wide variety of systems and software concepts and constructs. We could say that UML is a modeling language that is well-suited to the general-purpose domain. Q: What makes a UML model a UML model? A: The fact that it is based upon a UML metamodel. Q: What is a metamodel? A: A metamodel is the formal specification of a modeling language: it defines the types of semantic elements of which instances can be created in a model that is based on that language. UML is not the only metamodel that is in common use today. Data architects tend to use data modeling tools that use a SQL-based metamodel. Software developers are increasingly starting to wield modeling tools that use Java-based, C#-based, or XML-based metamodels. So just as UML serves as a good language for modeling in the general-purpose domain, other modeling languages may serve better for modeling in special-purpose domains. In this context, a domain could refer to a specific implementation technology, a particular industry, or perhaps to some common business problem domain such as supply-chain management. For any such domain, a domain-specific language (DSL) could be defined by a metamodel. For instance, a DSL for Copyright IBM Corp All rights reserved. Page 8 of 66

9 Java modeling could be defined by a Java language Abstract Syntax Tree (AST). Model taxonomies Models themselves can be characterized and categorized in various ways. For instance, the Rational Unified Process describes a particular taxonomy of business and system models that correspond to various perspectives and levels of abstraction: o Business Use Case Model o Business Analysis Model o System Use-Case Model o System Analysis Model (may be subsumed in Design Model) o Design Model o Implementation Model o Deployment Model o Data Model 1 The OMG s Model-Driven Architectures (MDA) initiative 2 describes another approach to classifying models in terms of their levels of abstraction: o Computation-Independent Model (CIM): addresses the environment and the requirements of the system without considering the system s structure or processing o Platform-Independent Model (PIM): addresses the structure and operation of a system without details related to a particular target platform o Platform Model (PM): defines the technical concepts, elements, and services that comprise a specific platform o Platform-Specific Model (PSM): combines the PIM with the PM to describe the structure and operation of a system, including details necessary to enable it to be deployed to the target platform described by the PM It should be noted that context and perspective becomes very important when considering the model categorizations that the MDA initiative defines. One person s PIM may be another person s PSM, the underlying question being what constitutes a platform?. The MDA categories, while certainly useful, do have some fluidity to them. 1 Data architects would typically further decompose the Data Model into two or perhaps three different levels of abstraction: o o o A domain object model that simply tries to describe the entities of the real-world problem domain and their real-world relationships A logical data model that casts the domain object model as a normalized collection of tables A physical data model that derives from the logical data model but de-normalizes the schema to optimize it in terms of balancing performance and resource utilization when actually implemented in a database 2 See [MDA] in the References section Copyright IBM Corp All rights reserved. Page 9 of 66

10 The RUP and MDA taxonomies align to some degree, as shown in Figure 2. Computation-Independent Model Business Use Case Model Business Analysis Model Platform-Independent Model System Use Case Model System Analysis Model Design Model Platform-Specific Model Implementation Model Platform Model Deployment Model Figure 2: Comparing RUP and MDA This aligned model taxonomy partially describes the set of models recommended as candidates for use in the new tools. But the new tools also classify models from yet another, somewhat unrelated perspective, as described in the following sections. Conceptual models and conceptual modeling Even as a user of Rational Rose or XDE and a seasoned modeler, you may have never stopped to consider the fact that some models are purely conceptual in nature, whereas others directly reflect the state of a corresponding implementation. Unless the only Rational Rose or XDE models that you ever used were synchronized to code, then you have done some conceptual modeling. You may have modeled business processes, business use cases, system use cases, analysis classes, design classes, interactions, activities, and so on, all of which reflect concepts and intent, not implementation. As noted previously, open-standard UML is a great general-purpose language for all sorts of conceptual modeling related to problem domains, systems, and software. Through the use of UML profiles and modeling tool customizations, UML can be adapted to create special-purpose languages that support conceptual modeling for particular industries (insurance, automotive), architectures (SOA), or methodologies (RUP, SOMA) without actually changing the UML metamodel per se. This approach can be a simple alternative to developing specialized DSL metamodels Rational Rose and XDE are great tools for doing conceptual modeling with UML. As will be shown throughout this article, RSA and RSM are even better. Implementation domain models and implementation domain modeling If conceptual models reflect concepts and intent, what about models that directly reflect the state of an implementation? This article will call them implementation domain models, and will call the process of working with such models implementation domain modeling. In this context, an implementation domain refers to a particular implementation technology -- such as Java, Enterprise JavaBeans (EJB ), C#, C++, XML, WSDL, DDL, or BPEL -- so you will also see the term 3GL (third-generation language) domain Copyright IBM Corp All rights reserved. Page 10 of 66

11 model being used. In MDA terms, an implementation domain model corresponds to a Platform Specific Model. Code-model synchronization (or Round Trip Engineering) in Rational Rose and XDE If you have ever used Rational Rose or XDE models that were synchronized to code, then you have done something that is very close to implementation domain modeling. Figure 3 depicts how Rational Rose and XDE supported implementation domain modeling for 3GLs such as Java, EJB, C++, C#, and others: Round Trip Engineering in Rose and XDE CODE synchronization technology UML MODEL OF CODE, CONTAINING DIAGRAMS A UML model persists code semantics redundantly. The model is at the same level of abstraction as the code Figure 3: Round Trip Engineering in Rational Rose and XDE Rational Rose and XDE both use an independently persisted UML model that maps directly to the actual 3GL domain elements. The UML in the model is customized by applying special 3GL-specific property sets (in the case of Rational Rose) or a 3GL-specific UML profile (in the case of XDE). Rational Rose and XDE contain technology that can synchronize the customized UML model to the actual 3GL code. Using the UML model, you build diagrams that document your code. Using the synchronization, you can effect corresponding changes in the code by changing the model, and by changing the code you can effect corresponding changes in the model (and hence, in the diagrams). This process is called Round Trip Engineering (RTE) -- a term that originated as part of the RUP methodology. RTE was an industry innovation when it was introduced, one that has now served well for the better part of a decade. However, as a technical approach, RTE has become dated. Copyright IBM Corp All rights reserved. Page 11 of 66

12 Implementation domain modeling in RSA and IRAD Figure 4 depicts a simplified view of how RSA and IRAD support 3GL domain modeling. Instead of putting a separate, persisted UML model between you and the code, the new tools use simple diagram files that contain nothing more than notational and layout information, plus references to the corresponding code elements. The notation in the diagrams looks like UML, albeit somewhat stylized. The only place semantic information is stored is in the code itself. 3GL Domain Modeling is a DSL ( Domain-Specific Language ) The only source of semantic information is here CODE Diagrams that directly reflect and in some cases edit the source code Figure 4: 3GL domain modeling In the new tools there are actually a few different types of diagrams that are used at the 3GL domain modeling level. One type is edit diagrams, those that enable you to control the layout of the diagram itself, and to edit the code by changing the diagram (just as in Rational Rose or XDE, but more efficiently). There are also some special diagram types that are read-only: Static Method Sequence Diagrams: these are sequence diagrams that depict the logic of a specific 3GL method (at the time of this writing only Java is supported, but comparable support for other languages is anticipated in future versions). You cannot edit the method body code through this type of diagram. Browse Diagrams: these are diagrams that are designed to help you understand the relationships among elements of a code base. (Note: Browse Diagrams are also supported for UML models in RSA and RSM). Browse diagrams are discussed in more detail later. In the new products, 3GL domain model diagrams reside in files with a.dnx extension. They appear in the project explorer denoted by this red icon: Copyright IBM Corp All rights reserved. Page 12 of 66

13 This distinguishes them from conceptual (UML) model files, with have a.emx extension and appear in the project explorer denoted by this blue icon: As a Rational Rose or XDE user accustomed to doing implementation domain modeling through an intermediate UML model, you may sense an asymmetry about this: Implementation domain models reside in multiple types of files, such as source code files and diagram files, where the semantics are in one type of file and diagrams in another Conceptual models reside solely in.emx files that contain both semantics and diagrams If this feels foreign and maybe a bit uncomfortable, perhaps this will help: due to the fact that RSA is Eclipse-based, all files belong to projects. So you can look at a project that contains source code plus diagrams of that code, and think of it as representing an implementation domain model that contains both semantics and diagrams, as shown in Figure 5. A UML Project Modeling files containing UML conceptual models (semantics plus diagrams) A project containing implementation artifacts plus diagrams of those artifacts think of the project as a modeling file that contains an implementation domain model (in this case, for the Java implementation domain) Blue model icon indicates a UML conceptual model file Red model icon indicates an implementation domain model diagram file Figure 5: Consider this project an implementation domain model RSA and IRAD support implementation domain modeling for multiple domains. In our marketing materials, we refer to some of these capabilities -- those that support 3GL domain modeling -- as UML Visual Editing to reinforce the message that you use UML notation to edit and document your code. Notable among those domains are Java, EJBs, and ANSI C++ -- some of the same 3GL domains you may have worked with in Rational Rose and XDE. Copyright IBM Corp All rights reserved. Page 13 of 66

14 Why the change from RTE to 3GL domain modeling? Both RTE and 3GL domain modeling provide the same capability: they enable you to document and edit an implementation using diagrams. Why does IBM Software believe that the newer products 3GL domain modeling approach is better? There are a number of reasons, enumerated in Table 1. Table 1: Comparing RTE with 3GL domain modeling RTE Can tend to drag the abstraction level of your conceptual design model downward to the implementation level. Design and construction activities become indistinguishable. Focus on architecture is compromised 3. Sluggish performance Synchronization sometimes has unexpected outcomes (sometimes semantically significant, sometimes just code formatting) May place marker comments in code to ensure unambiguous mapping of code constructs to corresponding UML model constructs RTE results in complex, labor-intensive workflows when diff-merge must be done in team development. Semantic diffs must be merged in two places: code and model. If some coders don t use RTE, things get even more convoluted. Steeper learning curve. Coders must learn the principles of working with a conceptual modeling tool, and must learn aspects of UML semantics. Developers must also learn the mapping of UML to the 3GL language. (For example, the UML property isreadonly might map to a const qualifier in a 3GL; the UML property isleafnode might similarly map to a final qualifier in a 3GL). Must explicitly draw traceability relationships (dependencies) between code-equivalent classes and conceptual classes 3GL domain modeling 3GL domain models are independent of conceptual models and don t alter their abstraction levels. Quick response Change model and the code changes as expected.; change code and the diagrams change as expected. No exceptions. No code markers needed Only one copy of semantics to merge. Merge of notational differences between versions of diagram files is a simple file-level choice: choose A or choose B. 4 Coders need only learn to use a diagram editor, and a little bit of UML notation. However, 3GL domain modeling does make a nice intro to some UML concepts for those interested in moving up the food chain to conceptual modeling Traceability is implied between generated code and the higher-level conceptual design model from which it was generated. Can drag a 3GL visual reference onto a conceptual UML diagram and see traceability between conceptual and 3GL elements. Also, code-generating transformations can generate explicit traceability linkages between conceptual and 3GL domain model elements. 3 This could be avoided with care. In Rational Rose, you could maintain two partitions on the Logical View -- one representing a more abstract design and not linked to code, the other expressing the implementation level and used for RTE. In XDE you could maintain both an abstract design model, and a corresponding code model. But the fact that in either tool you must first create a UML model that is refined to code-equivalent level before you can generate any code, leads to the temptation to refine one s design model in place and let it devolve into an implementation model. 4 Note that the new tools also do a much better job of handling team workflows involving conceptual models. For merges without conflicts, the model diff-merge capability in the new tools is 10,000 times faster than the diff-merge capabilities in Rational Rose and XDE. In addition, the new tools provide vastly improved tool support for working through merges with conflicts -- including true diagram-oriented diff-merge support. Copyright IBM Corp All rights reserved. Page 14 of 66

15 RTE Must use UML library models (reference models in XDE or framework models in Rational Rose) to support type references to 3GL types already implemented (for instance, jdk) 3GL domain modeling It s all code, so of course you can just reference at that level. Types from libraries (for example, in jdk Java Archive or JAR files) can be domain-modeled based on binaries. In fairness it must also be acknowledged that there are a few things that can be done with Rational Rose and XDE RTE models that currently are not supported by 3GL domain modeling in the newer products. These exceptions are cited in Table 2. Table 2: RTE functionality not supported at time of writing in 3GL domain modeling RTE You can annotate the code-equivalent UML classes with additional properties. You can create requirement record linkages directly to code-level elements. You can generate model reports and Web-publish sets of models that span both conceptual and code-bound models. You can apply UML patterns and code templates into the code-equivalent model. You can create diagrams that mix elements that correspond to the different tiers of an n-tier architecture. For instance, you can create a diagram that depicts a UML <<JSP>> element that is synchronized to JavaServer Pages (JSP ) code, a UML <<Servlet>> element that is synchronized to servlet code, some UML classes that are synchronized to helper beans, some UML <<EJB>> components that are synchronized to EJB code and deployment descriptors, and some UML <<Table>> classes that are synchronized to DDL, all in the same diagram. 3GL Domain Modeling Not yet, but this will be forthcoming (using code annotations) Not at this time Not at this time Not at this time Not at this time. The new tools do support implementation domain modeling for Java, EJBs, and DDL (data), as well as for Web tier (using Site Designer and Web Diagram features). And you can combine Java classes, EJBs, and data tables on one diagram. However at this point you cannot combine Web tier elements (for example, a JSP page from a Web Diagram) on the same diagram with Java classes or data elements. Apart from the above points of comparison, there is another aspect of the tooling support in the new products that makes implementation-level modeling easier than in Rational Rose or XDE. This has to do with the ease of creating diagrams. There are two features in the new tools that can help you more quickly compose diagrams, and spend less time maintaining diagrams over time: Topic Diagrams and Browse Diagrams. Topic Diagrams In contrast to normal diagrams, wherein you manually place the elements you wish to depict, the contents of a Topic Diagram are determined by a query that is run against existing model contents. To create a Topic Diagram you select a topical model element, then define what other elements you wish to appear in the diagram based upon the types of relationship(s) they have to the topical element. The diagram is then automatically populated and laid out (you can adjust the formatting if you wish). Topic Diagrams are persisted, along with their associated query, so as the semantic content of the model changes the Topic Diagram adjusts itself accordingly the next time you open it. Browse Diagrams Like Topic Diagrams, Browse Diagrams facilitate discovery and understanding of model content without having to manually compose diagrams. To create a Browse Diagram you select a particular element -- for instance a Java class -- which becomes the focal element. Then you define a filter for the types of Copyright IBM Corp All rights reserved. Page 15 of 66

16 relationships you wish to analyze (associations, dependencies, refinements, and so on) and the diagram is automatically populated with other elements that are related to the focal element in the ways defined per the filter. From there you can double-click on one of the related elements, and it becomes the focal element of a new browse diagram. You can repeat the process, and in this way walk an entire model or code base. The diagram browser supports the ability to navigate through the collection of diagrams with buttons for back, forward, and home (that is, the diagram for the original focal element with which you started the session). Unlike either Topic Diagrams or normal (manually composed) diagrams, Browse Diagrams are not persistent. They only exist while you re browsing them. Patterns and pattern assets Now, turn your attention away from implementation domain modeling and toward some concepts that cross-cut model types and abstraction layers. It is assumed you are familiar with the general concept of a design pattern 5. And as a Rational Rose or XDE user you may already be familiar with the more specific concept of a pattern asset as used in a modeling tool. In a modeling tool, a pattern asset is an expression of a design pattern, as a sequence of model generation instructions that are to be understood by the tool. In the tool, you apply a pattern asset to a specific context (that is, to the model of the system under design). The tool then executes the pattern asset, expanding it into the model. The outputs of the expansion consist of additional model content. This is illustrated in Figure 6. Design Model Before Design Model After Interface X New Class Interface X Class C Input parameters 1 Class A Pattern Definition content injection Class A Class D * * Class B Class B Interface Y Figure 6: Applying a pattern asset 5 If not, see [Gamma et al] in the References section Copyright IBM Corp All rights reserved. Page 16 of 66

17 A pattern asset is most often designed to be applied to a particular model at a particular level of abstraction (and based upon the same underlying metamodel), with the expectation that the outputs will be additional content at the same level of abstraction. 6. Also, a pattern asset is most often applied to a small subset of a model. For instance, the application context for a pattern asset can often be represented in a single diagram. Figures 7 through 10 depict this. Context for pattern application Figure 7: Application context for a pattern asset 6 This is not a hard-and-fast rule -- a pattern asset could be used to refine a model to a lower level of abstraction -- but it does describe the most common usage of pattern mechanisms in modeling tools. Copyright IBM Corp All rights reserved. Page 17 of 66

18 Instance of pattern asset dropped into context Pattern s formal parameters Figure 8: Pattern asset in context Contextual elements assigned as actual parameters (dragged and dropped them onto the pattern s formal parameters) Figure 9: Assigning contextual elements Copyright IBM Corp All rights reserved. Page 18 of 66

19 Resultant relationships depicted Figure 10: The resulting relationships Transformation and transformation assets A transformation asset is similar to a pattern asset; it takes a set of model elements as inputs and produces a set of corresponding outputs. A transformation asset does differ from a pattern asset in a few key regards: A transformation asset is most typically used to move from one level of abstraction to another A transformation asset is more apt to produce outputs that are based on a different underlying metamodel than the inputs From a tool usage standpoint, a transformation asset is more typically applied to an entire model or to a large subset of a model, as opposed to a confined context within a model This is illustrated in Figure 11. Let s walk through the illustration from left to right: 1. An architect has composed a model at a certain level of abstraction, shown as L If this is a UML model, the architect may have applied one or more UML profiles to the model, where those profiles are concerned with abstraction levels L+1 or higher. 3. To prepare the model for transformation, the architect may also apply one or more profiles that mark the model with additional information that pertains to a lower level of abstraction. The architect then supplies values for the properties defined by the marking profiles. 4. The architect next configures a transformation asset, attending to such details as the physical location(s) at which the transformation outputs should be placed. 5. The architect then executes the configured transformation asset. The asset extracts elements from the source model according to a set of extraction rules. It then maps the extracted elements to corresponding sets of output elements. Sometimes the mappings are as simple as one-for-one substitution. Other times the mappings may take on the character of complex patterns, resulting in a significant fan-out of elements in the target model. 6. A second model is produced, at a different (in this case lower) level of abstraction, shown as L. Copyright IBM Corp All rights reserved. Page 19 of 66

20 Model (L+1) L+1 Profile(s) (e.g. generic architectural profiles or business domain profiles) Model (L) Marking Profile(s) Model File Transformation Extraction Rules Mapping Rules Embedded Patterns Figure 11: Transformation asset Some typical applications of this workflow could be cases in which: L+1 represents a UML use-case model and L represents a UML analysis model L+1 represents a UML design model and L represents an implementation model (perhaps expressed as a Java implementation domain model) If you have studied the Model Driven Architecture s specification 7 of the OMG, these concepts will already be quite familiar to you. In this context, transformation assets could be used to transform from a Compute- Independent Model (CIM) to a Platform-Independent Model (PIM) to a Platform-Specific Model (PSM). Similarly, if you think in terms of the abstraction levels suggested by the modeling guidance of the RUP methodology, you should recognize that model-based transformation assets 8 could be used to transform: From a UML Business Use-Case Model to a UML Business Analysis Model or a UML System Use- Case Model (or both) From a UML System Use-Case Model to a UML System Analysis Model From an UML Analysis Model to a UML Design Model From a UML Design Model to an Implementation Domain Model (code and diagrams) To reinforce some of the concepts presented in previous sections, note that in Rational Rose or XDE an Implementation Model is typically persisted in two redundantly persisted formats (that is, a UML model and 3GL code). While it is possible to do that with the new tools, the preferred method when using the 7 If not, see [MDA] in the References section 8 Note that other kinds of transformation assets (that are not model-based) are also useful in software development -- for instance, compilers and virtual machines that transform implementation model code to executable code. Copyright IBM Corp All rights reserved. Page 20 of 66

21 new tools is to persist only one representation of the implementation, in the form of a 3GL domain model. Asset-based development Asset-based development (ABD) is a methodology for reusing assets including, but not limited to, pattern assets and transformation assets. Types of reusable assets other than patterns and transformations include: Models (UML or other) UML Profiles Components Web Services Architectural Frameworks Templates Recipes In the most general terms, illustrated in Figure 12, an asset is a collection of interrelated artifacts that: Provides a solution to a particular problem in a particular context Exposes points of variability (in other words, is parameterized so it can be adapted to the context) Includes rules for its usage Problem Asset Asset documentation and rules for usage Artifact Artifact Artifact Artifact Artifact = variability points Figure 12: An asset A recipe is, as you might expect, a set of instructions that specify how to apply particular assets and perform other development tasks in a particular order to accomplish a particular outcome, as shown in Figure 13. Figure 13: A recipe Copyright IBM Corp All rights reserved. Page 21 of 66

22 Kinds of artifacts that might comprise an Asset include: Other assets (coarse-grained assets can be created as compositions of finer-grained assets) Source code Tests Documents As a process, illustrated in Figure 14, ABD involves these activities: Asset Identification: for instance, identifying recurring patterns Asset Production: for instance, harvesting patterns, codifying them into executable pattern assets, and packaging them for discoverability Asset Management: the process of vetting candidate assets, maintaining and versioning them in a repository (such as IBM Rational ClearCase ), managing and tracking those activities (using a tool such as IBM Rational ClearQuest ), and perhaps eventually moving vetted assets to a more sophisticated RAS (Reusable Asset Specification) repository that supports queries and tracks metrics of asset usage Asset Consumption: the process of finding, understanding, and applying assets Reuse Program Management: dealing with the business aspects of setting up and managing a reuse program, and measuring that program s benefits Realizing An ABD Process Asset Production Asset Management Asset Consumption RSA Create, modify & refine package & submit All In The Eclipse Shell ClearQuest review & test ClearCase Development apply & customize RSA promote ClearCase Production Ready Asset Repository search & browse Other Asset Repositories search & browse Figure 14: ABD RSA and RSM both include capabilities for consuming assets, as well as for authoring assets such as UML2 profiles, patterns, transformations, and of course code. They also include an asset explorer you can use to connect to asset repositories, browse and examine assets, download assets, unpackage them, and deploy them into the tooling environment and start using them. Moreover, they include tools with which to package assets per the RAS standard and export them to repositories. As such they represent complete tooling solutions for producing and consuming reusable assets. The new tools also support ABD with process guidance (RUP plug-ins for ABD). The process guidance suggests who should do what and when, and how to use the tooling to develop well-architected assets and asset-based solutions. Copyright IBM Corp All rights reserved. Page 22 of 66

23 Mixing metamodels and abstraction levels As a Rational Rose or XDE user, you may be accustomed to creating models and diagrams that reflect a mix of conceptual UML elements and UML elements that directly reflect implementation code. Because all of the elements are based on the same underlying UML metamodel, any type of relationship that is legal in UML can be drawn between conceptual and code-bound elements. The situation in the new tools is a bit different because, as previously discussed, 3GL domain modeling in the new tools is based directly upon 3GL metamodels instead of UML. The modeling platform in the new tools enables you to create diagrams that reside within UML models, yet contain a mix of UML conceptual elements and 3GL domain model elements. An example is provided in the following set of Figures. Figure 15 shows the content of a RSA workspace using the Model Explorer view. Java project (Java domain model) Java types, generated from UML types in A UML Conceptual Model A 3GL (Java) Domain Model Diagram UML project UML modeling file UML model logical root UML types (conceptual elements) Figure 15: Model Explorer view of an RSA workspace Note that there are two projects: 1. a UML project named A Conceptual Modeling Project 2. a Java project named A Java Project The UML project contains two UML conceptual models: 1. One named A UML Conceptual Model 2. One named A Second UML Conceptual Model You see that there are four Java types in the Java project. These correspond to four UML types in A UML Conceptual Model and were in fact generated from them, using an RSA Java transformation asset. There is also a Java domain model diagram in the project, named A Java Domain Model Diagram.dnx. Copyright IBM Corp All rights reserved. Page 23 of 66

24 Figure 16 shows a UML Class Diagram that depicts the four UML types (conceptual elements) from which the Java elements were generated. Figure 16: UML Class Diagram Figure 17 shows a Java domain Class Diagram that depicts the four generated Java types. Figure 17: Java domain Class Diagram Copyright IBM Corp All rights reserved. Page 24 of 66

25 Figure 18 shows a diagram in a UML model that depicts a mixture of UML types (conceptual elements) and Java types. All items on the diagram are notational elements. Some of them (the «Java Class» elements) point to Java code files. The others point to the definitions of UML semantic elements stored in a model file. Glyphs mark elements that (semantically) are defined somewhere other than in the UML modeling file (.emx) that owns the diagram. Java type ( visual reference or Vizref or code proxy ) UML type (conceptual element, basis of code generation) Traceability relationship (created by Java code-gen transformation) Figure 18: Freeform UML diagram mixing UML and code elements The case above depicts UML conceptual elements along with Java elements that were generated from those conceptual elements by a transformation asset that used simple one-to-one element mappings. Notice that this kind of one-to-one code generation asset provides the functional equivalent of the code generation capabilities provided by Rational Rose and XDE. Also note the little glyphs ( ) on the Java classes. These indicate elements that reside outside of the UML model that owns the diagram. Next, Figure 19 once again shows a UML conceptual element and Java domain elements on the same diagram. This time, however, the conceptual element and diagram are within A Second UML Conceptual Model and in this case the Java elements were not generated from the UML element. Instead the Java elements were placed onto the diagram, and dependency relationships were drawn between the Java elements and the UML element. Copyright IBM Corp All rights reserved. Page 25 of 66

26 UML type (conceptual element) Dependency relationship (hand-drawn) Java type ( visual reference or vizref or code proxy ) Figure 19: UML diagram with placed Java elements and drawn dependencies In this case, consider two things: The UML Component could represent the Java project (itself a development component) expressed at a higher level of abstraction Given the proper transformation asset, the Java project could have been generated from the UML Component The point is that with the new tools you can create diagrams that depict elements at different levels of abstraction -- including both conceptual and code-bound elements -- just as you can with Rational Rose and XDE. Here are some specific examples of ways you can use code visual references within UML model diagrams using the new tools: Place a reference to an existing implementation class into a UML Class or Freeform diagram Draw a «refine» relationship between a visual code reference and a UML conceptual element (such as a Class or Component) Draw an association from a UML conceptual Class to a visual code reference, as shown in Figure 20. Note that in this example Java code subsequently generated from UML type Class1 would have a member variable of type Class3. Use an existing implementation class as a lifeline in a UML sequence diagram 9 9 In the currently shipping version of the new tools, when you do this you will not see the «Java Class» keyword appear on the lifeline. Copyright IBM Corp All rights reserved. Page 26 of 66

27 Figure 20: Drawing an association from a UML conceptual Class to a visual code reference Code Harvesting The new tools also support ways of bridging (as opposed to mixing) levels of abstraction. One of those -- transformations -- has already been discussed. Another is code harvesting. Code harvesting provides you with a way to select 3GL elements from a diagram, harvest them, and then paste them into a UML model. You do this in a way that creates new UML semantic elements, as opposed to simply visual code references. Figures 21 through 26 depict this process. We start with some Java classes in a Java project, and an empty UML model, as shown in Figure 21. Java types in Java project Java types depicted in Java domain modeling diagram Empty UML model into which types will be harvested Figure 21: Java types and an empty UML model Copyright IBM Corp All rights reserved. Page 27 of 66

28 Select the Java types, right-click, and select Harvest. Figure 22: Harvesting the Java types Next, paste them into the empty UML model by right-clicking it and clicking Paste. Figure 23: Pasting the Java types into the UML model Copyright IBM Corp All rights reserved. Page 28 of 66

29 This creates new UML conceptual elements. New UML conceptual elements Figure 24: The newly-created UML conceptual elements At this point you can place the new elements into the default diagram of the UML model by dragging them to the diagram from the Model Explorer. After some slight format adjustments your model should resemble that in Figure 25. Copyright IBM Corp All rights reserved. Page 29 of 66

30 Figure 25: The new UML model Just to be thorough about illustrating the harvest concept, let s put the visual references to the original Java elements onto that UML diagram. Figure 26: Adding visual references to the original Java types Copyright IBM Corp All rights reserved. Page 30 of 66

31 Notice that there are no relationships between the original Java elements and the harvested UML elements. Transformation options The previous discussion on mixing metamodels and abstraction levels included an illustration of some Java classes that had been generated from some UML conceptual classes, where the transformation employed simple one-to-one mapping rules (much like the code generation provided in Rational Rose and XDE). In that illustration you may recall that the transformation created traceability relationships between the Java types and the UML types from which they were derived. Let s take a closer look at that illustration, shown in Figure 27. Java type ( visual reference or code proxy ) UML type (conceptual element, basis of code generation Traceability relationship (created by Java code-gen transformation) Figure 27: Traceability between Java types and derived UML types In the new tools, transformation assets can be configured to behave in various ways. The options that are currently supported include: Generate traceability links from source elements to target elements (as done in the previous section). Substitute target elements for source elements. If this option had been used in the prior example, here is what would have happened: 1. The UML conceptual elements (the semantic elements) would simply have been removed 2. In the diagrams within the UML model, all depictions of the UML conceptual elements would have been replaced with visual references to the code elements (also known as code proxies). This option -- substitution of source elements with target elements -- is sometimes called the morph option. Do nothing but generate the outputs. Do not morph and do not create traceability links from output elements back to the source elements. Within the tools, these options are available in the dialog via which you configure transformations, Copyright IBM Corp All rights reserved. Page 31 of 66

32 depicted in Figure 28. Figure 28: Options for configuring transformation assets Reverse and inverse transformations As you studied the previous descriptions and illustrations of transformations, they may have seemed to imply that transformation always proceeds from higher to lower levels of abstraction That really isn t the case. Transformations can also be used to automate the process of removing details to derive a more abstract model. But the most common use of transformations in the new tools is to automate generating additional detail, while perhaps at the same time translating between one metamodel and another (for example, between UML and Java). So in subsequent discussions in this article, when you see the term transformation it will connote transformation from higher to lower abstraction level; reverse transformation will mean transformation from lower to higher abstraction level. There is also the notion of an inverse transformation. Inverse transformations are those that invert the effects of some other transformation. For example, this would be a pair of inverse transformations: A reverse transformation that can be applied to an EJB-based implementation to derive a more abstract UML design model A transformation that can be applied to the derived UML design model to reproduce the original implementation In the scenario just described, the transformation that produces an EJB implementation from a UML design model need not be able to produce every detail of the EJB implementation in order to have practical value. For instance, if the UML-to-EJB transformation can produce structural and boilerplate code but not business logic code, it is still useful so long as it is non-destructive to any business logic code or other functional code modifications in a previous version of the implementation. The practical Copyright IBM Corp All rights reserved. Page 32 of 66

33 value of such a partial inverse transformation is to support the process of reconciliation. Reconciliation Reconciliation refers generically to the process of bringing a set of related specifications -- where each constituent specification represents a different perspective or level of abstraction -- into agreement with one another. Here are some examples of reconciliation in the context of model-driven development: Suppose you have a system use-case model and you also have a design model that elaborates how the use-cases are fulfilled. Simultaneously you have: o Some analysts modifying the use-cases (as new requirements come to light) o Some architects modifying the design model. Chances are that the two specifications will drift out of conformance. The design model may not elaborate the correct behavior as stated in a revised use-case description. The use-case model may suggest a set of steps that an architect has discovered a way to streamline, thereby cutting out a couple of steps. These are changes you may want to reconcile so that the specifications remain in sync. Suppose you have a design model that expresses architectural constructs at a high level of abstraction. You also have a partial implementation of that design expressed as a mixture of Java, XML, DDL, and other types of code and metadata. Within a particular release project, you follow an iterative development process such that simultaneously: o Architects are evolving the high-level design (to reflect architectural improvements or to add new second-iteration features) o Developers are completing additional implementation details of the first-iteration features. Chances are good that the two specifications will drift out of conformance. The design model may stipulate a change to a component design contract that must be reflected in the second iteration. The developers have modified (at code level) the design contracts of two other components that the architects had no intention of changing. These are changes you may want to reconcile so that the specifications remain in sync. It may be that the architects decide that one of the developers changes was a good idea, so they want to harvest that change back into the design model. They may decide that the other developers changes were off-base, and need to be rolled back so the implementation once again conforms to the original design. And finally, the architects second-iteration changes must at some point be applied to the implementation. Suppose you have a UML model that expresses the structural details of an implementation. You also have that same implementation expressed as a mixture of Java, XML, DDL, and other types of code and metadata, such that there is a one-to-one mapping from structural elements in the model to structural elements in the code. You have a mix of architects and developers working with the model and the code, each changing things in different ways. Chances are, the model and code will drift out of conformance, and you may want to synchronize these changes. Note the use of the term synchronize instead of the term reconcile in this example. Whenever you have a 1:1 mapping, by definition you are not dealing with different levels of abstraction. You are merely dealing with different modes of representation. Reconciliation becomes trivial, devolving to mere synchronization, which simply involves either/or choices such as: o o In short: pick a or pick b. Accept what the model element says, or accept what the code element says Accept what the use-case requirement record in a requirements database says, or accept what a UML use-case that is linked to that requirement record says As previously discussed, Rational Rose and XDE provide simple code generation from UML models based upon 1:1 mappings from model elements to code elements. Rational Rose and XDE also provide Copyright IBM Corp All rights reserved. Page 33 of 66

34 the capability to keep a code and model synchronized, based on those 1:1 mappings. Similarly, the new tools support 3GL domain modeling, which accomplishes the same thing but uses a different technical approach that ensures the code and the model never go out of sync (because they are one and the same). Neither RTE nor 3GL domain modeling represents a reconciliation capability. This article will return to the issue of reconciliation later, when it discusses the principles of Automated Model-Driven Development. Then we ll compare the theories of operations of Rational Rose and XDE with the theory of operations of the new tools. Copyright IBM Corp All rights reserved. Page 34 of 66

35 3. Common approaches to modeling Modeling and modeling tools are used in a wide variety of ways, and perhaps no other entity has been better positioned to observe this than IBM Software with its Rational family of products. Let s take a look at a few of them. Before we do, though, note that the new tools support all of these various approaches. Models as documentation of implementations Some use models -- which is placed in quotes because in this case what is really being used is just diagrams -- for no other purpose than to document existing implementations, as shown in Figure 29 This cannot be considered a Design activity, as it is really just a documentation task undertaken as part of the Construction activity. Construction Activity 2. Create diagrams to document the content of the implementation 1. Build an implementation using code-level tools. Figure 29: Using a model (diagram) to document an implementation Models as implementation-level development tools Some use modeling tools such as Rational Rose, XDE, and the new tools to work with code-level models as an approach to not only documenting, but creating and editing their implementations, as shown in Figure 30. This too represents primarily a Construction activity; however, code-level models do help you think about aspects of software design at a low (very detailed) level of abstraction. That is particularly true if the tool you are using supports both structural and behavioral diagramming capabilities at the implementation level. Copyright IBM Corp All rights reserved. Page 35 of 66

36 Construction and Low-Level Design Activity Build an implementation using codelevel tools that present a diagrambased editing experience. Can be supported by two different technological approaches: Model-code synchronization 3GL domain modeling Figure 30: Using a model to document and edit an implementation As was discussed in several sections of Part 2 of this article, from a tooling technology standpoint there are two different approaches to supporting this modeling style: model-code synchronization (as supported by Rational Rose and XDE), and 3GL domain modeling (as supported by the new tools). As illustrated in Figure 31, both of the implementation-level modeling practices that have been described thus far bring a certain amount of value to the development process: Working with models at this level of abstraction -- focusing on just a couple of diagram types and a limited set of notational elements -- affords developers an easy entrée to the modeling arena, and helps them start building new skills that then enable them to move up the food chain and start wielding higher-value conceptual modeling techniques. Documenting implementations in diagrams that use a standardized set of notations has the potential to enable both technical reviewers and business stakeholders to gain a better understanding of the system, and of some of the issues that may be associated with its design. Copyright IBM Corp All rights reserved. Page 36 of 66

37 Value of Implementation-level modeling For developers, as an easily consumable introduction to modeling notations and techniques EJB Class Diagram Sequence Diagram visualization of a method For reviewers, as a more easily understood representation of the actual state of the implementation Figure 31: Some benefits of implementation-level modeling Other modeling practices include the use of conceptual models. Figures 32 and 33 show that conceptual models have a number of characteristics that bring additional value to the development process, including: Conceptual models are abstract, so as you consider some specific aspect of a problem domain or a tobe-built solution -- or are at a particular phase of the development lifecycle -- you can focus on what is pertinent to that aspect or phase without getting lost in lower-level details. Good models also tend to be predictive, not just of the characteristics of the to-be-built solution, but also of the dependencies and work product requirements that must be dealt with from a product management perspective. In this way, models add business value by helping to reduce project risks. Models are a good way to capture the knowledge of your top domain experts and solution architects so that it may be efficiently imparted to the rest of the development team. Copyright IBM Corp All rights reserved. Page 37 of 66

38 Value of conceptual modeling Abstract Emphasize important aspects while eliding irrelevant ones Understandable Expressed in a form that is more readily understood by a variety of stakeholders Predictive Inexpensive Can be used to derive correct conclusions about the modeled system and the project that will produce it Much cheaper to construct, study, and modify than the implementation artifacts of the modeled system Figure 32: Additional benefits of conceptual modeling Models are fairly easy to change compared to typical textual specifications, or to actual code. They also avoid the notable drawback of prototypes: the common trap of evolving the prototype to be the production system, resulting in a crafted instead of architected design. This makes models a great medium via which to reason about requirements, and to experiment with a variety of ideas and approaches before committing anything to code Higher-level conceptual models are more effective than implementation-level models for communicating about approaches, designs, and issues with customers and other business stakeholders Models help us reason and communicate about The nature of the problem domain how do things actually work in the real world? The requirements of an application The best architecture Optimal work breakdowns & resource assignments Using concise notations that can be changed / experimented with easily, incrementally, and inexpensively (compared to other forms such as pseudo-code, prototypes, actual code ) be understood by all types of stakeholders (business, development, operational) emphasize important aspects while eliding irrelevant ones Figure 33: Using models to explore design concepts Copyright IBM Corp All rights reserved. Page 38 of 66

39 Now let s look at some modeling approaches that include conceptual modeling. Disposable or replaceable models In this practice, models are created quickly and without consideration to maintaining them throughout the lifecycle. The theory behind this approach is that conceptual models (or portions of them) will be useful to a certain point, after which they can be discarded (or replaced with implementation models) and never referred to again. Note that this is a generalization of approaches such as sketching 10 and model storming 11, but in terms of actual practice it predates those codifications. The use of disposable or replaceable models may or may not involve the use of modeling tools. If it does, as shown in Figure 34, then the tooling might be able to generate implementation artifacts from the conceptual models before they are discarded 12. However, in some cases disposable models (in this case actually just diagrams, because no store of semantic information is created) are created using nothing more sophisticated than a whiteboard or even the back of an envelope. Of course, models expressed in a tool will, if nothing else, prove much more scalable as a means of communicating the ideas they express. Tools also make it easier to collaborate in distributed development teams, for example using fast drawing with shared screens or projection. 1. Create a low-overhead conceptual rendering of your design that can subsequently be discarded Design Activity Construction Activity 2. Build a corresponding implementation using code-level tools. The implementation evolves to become the sole meaningful representation of the architecture Figure 34: Using disposable models Models as blueprints In this practice, conceptual models are treated as first-class development artifacts and considered to be 10 The notion of using models as sketches and blueprints has also been described by Martin Fowler in his book UML Distilled Third Edition 11 See Software Development, October 2004, Scott Ambler, The Best-Kept Secret? which begins Model storming occurs when a few people get together and use simple tools to quickly model a critical issue. This unsung practice is probably the most common approach to modeling. 12 Or in the case of the new tools, you can not only generate implementation artifacts but (by transforming to code using the morph option described earlier) you can also replace conceptual elements in model diagrams with diagrammatic references to the actual code. Copyright IBM Corp All rights reserved. Page 39 of 66

40 the blueprints for how systems should be implemented. In this case, illustrated in Figure 35, the conceptual models are constantly updated throughout the lifecycle, and it is expected that implementations should adhere to them on an ongoing basis. The mindset is that the model is the master. Through a (manual) reconciliation process, good ideas that arise out of construction activities are reflected back into the conceptual models. The use of tools to generate code from the conceptual models may or may not be part of the practice. 1. Create a formal conceptual rendering of the design - a blueprint model that is persisted over the lifetime of the solution and is intended to constrain the implementation ongoing Design Activity Construction Activity 2. Build and evolve a conformant implementation using code-level tools Reconciliation Activity 3. Improvements and requirements discovered during construction drive revisions of the blueprint Figure 35: Using a model as a blueprint Basic model-driven development Basic Model-Driven Development (MDD) is a slight variation of Models as Blueprints that adds the element of generating code from the blueprint models, as shown in Figure 36. The basic principle remains the model is the master, and the development process is still iterative: all changes are driven top-down from the models, and there is a manual reconciliation process to accommodate discoveries made during construction. Copyright IBM Corp All rights reserved. Page 40 of 66

41 5. Repeat 1. Conceptual models are the masters Design Activity Construction Activity 2. Generate code from models Reconciliation Activity 4. Improvements and requirements discovered during construction drive revisions of the blueprint 3. Evolve a conformant implementation using code-level tools Figure 36: Basic MDD Hybrid approaches In practice, the modeling approaches discussed thus far -- models as documentation of implementations, implementation domain models as construction tools, disposable models, and models as blueprints -- are combined in a variety of ways. Figure 37 shows one such example. 1. Disposable conceptual models Design Activity 2. Generate seed code Construction Activity 3. Evolve implementation using domain modeling tools Figure 37: Combining disposable models with basic MDD Figure 38 illustrates the ability to leverage the unique morphing capability of the new tools code generating transformations. Copyright IBM Corp All rights reserved. Page 41 of 66

42 1. Replaceable Conceptual models ITERATE 3. Evolve design and implementation using diagrams in conceptual models that contain a mix of conceptual and implementation elements Design Activity 2. Generate code, morphing the diagrams to point to generated code Construction Activity Figure 38: Leveraging the new tools' morphing capabilities In all cases, modeling adds business value. Now we will take a look at how IBM Software proposes that the practice of Automated MDD using the new Rational products can be leveraged to higher levels of business value than have historically been realized. Copyright IBM Corp All rights reserved. Page 42 of 66

43 4. Automated MDD In short, Automated MDD is the admixture of: Elements of the RUP and MDA philosophies, especially the use of models at different levels of abstraction and transformations that automate the progression from higher to lower levels of abstraction The concepts of ABD and the new tools support of those concepts (RAS, recipes, patterns, transformations, and so on) Judicious use of domain-specific modeling languages, notably for 3GL domain modeling As shown in Figure 39, these components are woven together into a cohesive modeling tool theory of operations, and supported by a rich complement of MDD automation assets such as Recipe Assets, Pattern Assets, and Transformation Assets. Automated Model Driven Development MDA RUP Transform (embedded patterns) Apply Patterns Apply Patterns CIM Business Use-Cases Business Analysis Business Process Design Application Use-Cases ITERATE Transform (embedded patterns) Transform (embedded patterns) Apply Patterns TRACEABILITY LINKS Apply Patterns PIM Application Analysis Application Design Transform (embedded patterns) Apply Patterns, snippets, etc. PSM Implementation Implementation domain modeling (Java, EJB, C++, C#, DDL, CORBA, WSDL, XSD, SCA ) Figure 39: The process of automated MDD Automated MDD fundamentals These are the core principles of Automated MDD: Layered models: use different types of models that provide a variety of perspectives on problem and solution domains, successively addressing higher levels of detail (or stated conversely, lower levels of abstraction) as appropriate to successive phases of the development process. This does not mean Copyright IBM Corp All rights reserved. Page 43 of 66

44 you must use all of the types of models reflected in Figure 39. As always, you should use as much process, and as many models, as you believe will add cost-effective value -- no more, no less. For instance, at the business (CIM) level, some teams will use only business process models, while others may use a combination of business use-case and business analysis models instead. Still others may use just textual requirements and perhaps some informal diagrams. Modeling automation: the activity of composing models is not purely a manual process of creating one element at a time. It is automated by the application of re-usable assets such as patterns and transformations. It might also be improved by a variety of supported customizations -- for instance (through profiles) customizing UML to better suit a particular problem or solution domain. Traceability: the outputs of those asset expansions include the creation of traceability links -- the refinement relationships that document how you proceeded from one abstraction level to the next. This has many benefits, and in today s compliance-charged atmosphere takes on even greater importance as a governance tool. Asset-Based: the identification and development, or the acquisition, management, and deployment of reusable assets is a core competency in the automated MDD process. (If you missed it earlier, go back now and read the section on Asset-Based Development in Part 2.) Iteration: use an iterative development process. Either you follow a strict model-driven (top-down) approach or you practice reconciliation to harvest and incorporate discoveries made at lower abstraction levels into the higher-level specifications (models). Tool extensibility: you rely on your development tools being very open and extensible, and supported by a vital vendor ecosystem. You want the ecosystem to provide a rich variety of MDD automation assets, so you want openness and extension authoring support so that you can develop any highly specialized customizations and automation assets you may need. Platform heterogeneity and open standards: you protect and leverage your investments in Automated MDD by basing your practice on open standards such as UML and RAS, and a highly extensible open tools platform such as Eclipse. In this way you ensure degrees of flexibility and vendor independence, and your practice can be applied to development for a heterogeneous mix of target runtime platforms. In the words of Grady Booch, referring to the approach of using UML versus the approach of using proprietary Domain-Specific Languages: in the kinds of systems people are building these days, there is a far greater need for interoperability, and that demands a common understanding of standards against which we build all sorts of things. So we think that kind of openness is necessary for the current and future generation of systems. IBM Rational: Rival Microsoft Faces Uphill Battle, interview with Grady Booch, pub. July 29, Copyright IBM Corp All rights reserved. Page 44 of 66

45 Of course, as shown in Figure 40, Rational products have an illustrious history of driving and supporting MDD-related open standards such as the UML, MDA, and RAS. Rational and Automated MDD-Related Standards Reusable Asset Specification Created UML (Booch, Rumbaugh, Jacobsen) Released to public domain Now an OMG standard Continuing high level of contribution as IBM Rational Active in MDA-related standards (UML, MOF, QVT, ) Deliver numerous technologies to the industry that support use of MDA principles Business functionality and behavior Business Expert (RAS) IBM Rational-driven OMG adopted standard for classifying, describing, and packaging reusable assets Standard mapping Platform- Independen t Model Platform- Specific Model Platform Architect Application Developer Design of the solution based on a specific platform like J2EE Figure 40: IBM Software's Rational products have long supported open standards Earlier sections of this article discussed abstraction levels, models and model taxonomies, and assets and ABD. The general notion of reconciliation in an iterative development process was also introduced. However, to this point there have been no discussions about how: Reconciliation might in the future become a tool-assisted process The new tools can be used in a consistent process to support a variety of target runtimes, including the Microsoft.NET platform Iteration and reconciliation The concept of reconciliation was introduced in Part 2, and its role was described briefly in the discussions in Part 3. The challenges of reconciliation have existed since the dawn of specification-driven software development. Historically, the process of reconciliation has been one of manually examining and comparing specifications and their realizations (that is, artifacts at adjacent levels of abstraction) to determine where they do not agree, and then changing one or both specifications to bring them into conformance. IBM Software sees the potential for tooling to assist with the reconciliation process. It may prove that there is no single technical approach that can support reconciliation across all specification domains and metamodels, and while attacking the problem from that perspective is worthwhile as a research project, it is currently not a practical approach as a product development project. Therefore, IBM Software is likely to pursue the challenge on multiple fronts. From an Automated MDD standpoint, we consider the border between conceptual design model 13 and its 13 A PIM in MDA terms. Typically a UML conceptual design model in the new tools. Copyright IBM Corp All rights reserved. Page 45 of 66

46 corresponding implementation model 14 to be the one most in need of reconciliation support. What will be described here is one approach to addressing that particular reconciliation challenge, specifically the approach in the context of a typical iterative development process. Please note that this does not describe existing capabilities of the new tools. It describes an approach the new tools might exemplify to support design-implementation reconciliation in future versions. This example will start with the first Construction iteration of a project. At this point the project vision has been established, as have the business-level requirements for the features to be delivered by the first construction iteration. The architect has cast the design for those first-iteration features as a conceptual UML model. In addition, he has configured and executed a transformation to generate the seed code for the basic architecture and the first-iteration features. This state is depicted in Figure 41. Iterative Automated MDD (1,2) Requirements Design Construction Test IRM Architect works with UML, Profiles, Patterns to develop 1 st iteration design model 1 i1 D.M. 2 Transform Architect Invokes transformations to seed 1 st iteration implementation model (structural, boilerplate, and possibly some behavioral code, and code-level diagrams) Iteration 1 Iteration 2 Iteration N Figure 41: The first Construction iteration 14 A PSM in MDA terms. Typically a collection of 3GL domain models in the new tools. Copyright IBM Corp All rights reserved. Page 46 of 66

47 At that point, the development team picks up the seed code and begins to flesh out the remaining details of the implementation. Along the way they are likely to see opportunities to improve some aspects of the design, and if the prevailing process philosophy enables them, they will seize those opportunities. At the same time, the architect moves on to start extending the conceptual design to reflect new (seconditeration) features and perhaps make some adjustments to the overall architecture. Clearly, by the time the Iteration 1 implementation has stabilized, there will likely be some disagreements between that implementation and the design model (Figure 42). Iterative Automated MDD (3) Architect refines architecture, designs 2 nd iteration features IRM Requirements Design Construction Test i1 D.M. 3a i2 D.M. The concurrent activities of architects and developers result in a set of uncorrelated changes I1 I.M. 3b Test Automations and Code Analytics Developers implement details of 1 st iteration features Write business logic Use Implementation Domain Modeling to assist with understanding code structure and behavior Use static and runtime code analysis features to guide refactoring decisions which are then implemented using visual refactoring capabilities Iteration 1 Iteration 2 Iteration N Figure 42: Differences have emerged between the design model and implementation Copyright IBM Corp All rights reserved. Page 47 of 66

48 So reconciliation is in order. How might that work? Figure 43 shows one approach that IBM Software has been considering as a possible feature addition to the new tools Iterative Automated MDD (4) Requirements Design Construction Test IRM i2 D.M. Reconciliation Tooling (Hypothetical) Identifies and flags code that Is not traceable to model (i.e. new types, methods, introduced by the developers) Is traceable to model, but no longer agrees with model Configurable filters So that implementation details that are without designlevel relevance can be ignored during the reconciliation process i1 I.M. 4 Reconcile Architect Who Is Using Tooling Sets disposition of flagged code Code change is desirable, harvest into model Code change is not desirable. Some options: file defects generate TODO comments Next PIM-to-PSM transformation re-apply will overwrite undesirable PSM changes Iteration 1 Iteration 2 Iteration N Figure 43: A possible approach to automated reconciliation First of all, the process depends upon provision of a transformation that is the inverse, or at least the partial inverse, of the transformation that originally generated the code. That inverse transformation is executed, and it produces an in-memory UML conceptual model that abstracts the current state of the architecturally significant aspects of the implementation. The in-memory model and the current-state design model that the architect has been working on are presented to the architect in a specialized GUI, somewhat akin to a model compare and merge differences (or simply diff-merge) GUI. The architect, ideally in collaboration with the development team, makes decisions as to which of the developers changes should be captured into the current version of the design model, and which should be rolled back (that is, overwritten by the next code generation pass). Copyright IBM Corp All rights reserved. Page 48 of 66

49 Finally, as depicted in Figure 44, the second-pass code generation is invoked, and the process continues with Iteration 3 design concurrent with Iteration 2 construction. Iterative Automated MDD (5,6) Requirements Design Coding Test Architect re-applies transformations to update implementation model IRM with architectural refinements and 2 nd iteration features I2 D.M. i3 D.M. 5 6a i2 I.M. 6b Architect proceeds to design of 3rd iteration features Developers adopt architectural refinements and implement details of 2 nd iteration features Iteration 1 Iteration 2 Iteration N Figure 44: The iteration following reconciliation Copyright IBM Corp All rights reserved. Page 49 of 66

50 Heterogeneous development If you are like most customers using IBM Software s Rational products, you work in a shop where development includes the use of a variety of languages (Java, ANSI C++, MVC++, C#, VB, XML) and targets a variety of runtimes. In such environments, Automated MDD using tools based upon open standards and platforms such as UML, RAS, and Eclipse becomes a powerful unifying technology: The use of language- and platform-independent conceptual models lets you defer platforming decisions until later in the lifecycle. The use of open-standard UML for modeling lets you develop a modeling practice that doesn t lock you in to a single platform (as a pure DSL-based practice would). The use of Eclipse as an open modeling technology platform opens up a world of possibilities for automating MDD, integrating models based on a variety of metamodels, and supporting high-value development approaches such as Business Driven Development (see Appendix B). Re-training personnel on platform technologies and tools is a major cost concern for 90% of IT shops. IBM helps you minimize those costs by providing a common solution for all platforms: the only lifecycle tooling that supports such heterogeneous platforms. By using Rational lifecycle tooling products, you can report and manage all of your development projects using a single infrastructure, simplifying installation and avoiding finger pointing among vendors if issues arise. Clearly the two preeminent runtimes today -- for new development, legacy transformation, and application integration including migration to SOAs -- are Java 2 Platform, Enterprise Edition (J2EE ) and the.net framework. Supposing you use both, how would you use the new tools -- and in fact the entire extended 15 IBM Rational Software Development Platform (SDP) -- to support your whole team with a consistent process and set of tools? Let s walk thru Figure Extended meaning the Rational SDP supplemented with other IBM Software Group products -- such as IBM WebSphere Business Integration Modeler -- that integrate with the Rational products Copyright IBM Corp All rights reserved. Page 50 of 66

51 WBI Modeler Requisite Pro Business Modeling Requirements Mgmt RSM /RSA UML Business & Use-case Modeling RSM / RSA UML Analysis & Design iterate VS.NET RSM / RSA RAD / RWD / Eclipse View Web-published Models RFT P+ RPT R U P / R P M UML 3GL Transformation Prep Code, Build, Unit Test, Debug Visually edit / diagram code Functional Testing Runtime Analysis Performance Testing CC CQ Change management Configuration management Figure 45: How IBM Software tools support an ideal development process 1. Business modeling and requirements management a. You can use IBM WebSphere Business Modeler (WBM) for modeling, analyzing, and optimizing your business processes. You can leverage this activity and bridge the Business-IT gap by utilizing the seamless integration of WBM and the new tools (for more details see Appendix B, Business-Driven Development) b. You can use IBM Rational RequisitePro and its integration with Microsoft Word to manage both business and technical or application requirements that are expressed textually. You can link textual requirements to corresponding UML model elements using the integration of RequisitePro and the new tools. 2. Automated MDD: conceptual modeling and design, and implementation seeding a. You can use RSM or RSA for performing conceptual modeling at various levels of abstraction, including CIM and PIM levels. Your UML conceptual models can have traceability to business process models and managed requirements as described in Step 1 previously. b. When you are ready to start introducing platform-specific concerns, you can mark your conceptual design models with platform-specific UML profiles, and configure them to use platform-specific code-generating 16 transformations. Then you can execute those transformations when the first design iteration feels complete, to produce a portion of the actual implementation artifacts. c. This illustration focuses on just two platforms -- Java and.net -- but UML profiles and transformations can be developed for practically any language or runtime. We expect that over time IBM and its Ready for Rational Software (RfRS) business partners will introduce a broad array of platform-specific markup and transformation offerings. A RfRS offering for.net markup and C# code generation based on RSM models is already available from Interactive Objects Software. d. If you are targeting.net, you would use RSM for modeling as opposed to RSA, because you 16 Or more generally, text-generating Copyright IBM Corp All rights reserved. Page 51 of 66

52 won t need any of the Java IDE capabilities that are packaged as part of RSA. 3. Automated MDD: implementation domain modeling and construction a. During Construction, it s IBM Software s position that you should use the best tools for the job. If you are targeting J2EE technology, there are no better tools than IRAD and RSA. If you are targeting.net, there is no better tool than Microsoft Visual Studio.NET. b. Either way, construction can be undertaken with the support of 3GL domain modeling, because not only do RSA and IRAD support implementation domain modeling for Java, EJB components, and Data, but Visual Studio.NET 2005 supports implementation domain modeling for C#, VB, and J#. 4. Functional and performance testing a. For functional testing you can use IBM Rational Performance Tester, which is available in both Eclipse-hosted and Visual Studio-hosted editions. (Currently Visual Studio 2003 is supported, with support for Visual Studio 2005 also planned). Test scripting can be done in either Java or VB.NET. b. Rational Performance Tester can be used to load test your solutions, whether they are J2EE platform-based or.net-based 5. Team Collaboration a. Regardless of which IDE you use, you can have the same level of deep integration with ClearCase and ClearQuest for configuration and change management. This provides you with a highly scalable solution that supports server clustering, replication, and wide-area (Web access) configurations. Furthermore, you can exploit ClearCase-ClearQuest integration (including UCM) and ClearQuest-RequisitePro integration. The integration of the various Rational SDP tools integrations with SoDA can be used for reporting, and with Project Console and IBM Rational Portfolio Manager for project management. Business value of Automated MDD Using Automated MDD can yield tremendous business value. This is particularly true when Automated MDD is practiced across a heterogeneous environment using the extended Rational SDP as described in the previous section. Then you gain business value from: Minimizing training and administration costs across the enterprise Greater agility in terms of being able to defer platforming decisions Minimizing runtime and vendor lock-in The business value of Automated MDD is also maximized when it is applied in SOA environments. This is true for the following reasons, illustrated in Figure 46: SOAs have the effect of standardizing an application s architecture across the enterprise. When substantial numbers of projects target a common application architecture, applications themselves begin to share consistent patterns of structure and boilerplate code -- recurring types of components (such as adapters and facades), and recurring patterns of interaction. Copyright IBM Corp All rights reserved. Page 52 of 66

53 SOAs and Automated MDD: Made for Each Other Enterprise Service Bus 1:n Utility Service 1:n 1:n External Requester Integration Integration Service Service n:1 n:1 1:n Façade Provider Façade 1:1 External Provider n:n Integration Service Figure 46: Increasing business value This creates a very rich environment from which to harvest patterns and transformations for automated re-use, in the form of model-based pattern assets and transformation assets. As shown in Figure 47, this adds even more business value. Copyright IBM Corp All rights reserved. Page 53 of 66

54 Automated Model Driven Development Transform (embedded patterns) Apply Patterns Apply Patterns Business Analysis Business Process Design Application Use Cases ITERATE Transform (embedded patterns) Transform (embedded patterns) Apply Patterns Apply Patterns Application Analysis Application Design Transform (embedded patterns) Construction Complete implementation details with assistance of visual development tools Figure 47: Benefits of Automated MDD The more you leverage reusable assets, the more consistency you will have across both your designs and implementations. Hand-designing and hand-coding are reduced. Solutions are of higher quality, with less rework along the way. All of this drives out costs and shortens time-to-value. Copyright IBM Corp All rights reserved. Page 54 of 66

55 5. Summary and conclusion In this article you have been introduced, or perhaps got a refresher course, on a number of important concepts such as Models Metamodels Conceptual modeling vs. implementation domain modeling The differences between the Round Trip Engineering vs. 3GL Domain Modeling approaches to implementation domain modeling Automation assets such as pattern and transformation assets, and ABD Different approaches to the use of modeling in the development process You also saw how the capabilities of the new tools compare with those of Rational Rose and XDE, and how the new tools represent substantial improvements over Rational Rose and XDE in areas such as Implementation domain modeling Automated diagram production ABD Finally you saw how IBM Software defines Automated MDD, how Automated MDD can be applied in heterogeneous environments, and how it holds the potential for tremendous return on investment. Along the way you may have shed some misconceptions about what is involved in moving from Rational Rose and XDE to the new tools. At least, that is the hope and the primary purpose of this article (while at the same time striving to be forthright about any functional gaps that currently exist). Adopting any new development tool requires some effort, and involves the loss of some specific processes with which you have become comfortable. Migration from Rational Rose or XDE to the new tools is no exception, but hopefully this article has demonstrated that whatever creature comforts you may give up, the new tools afford better ones -- they ll just take some getting used to. Additionally, this article should have made clear that the potential business value of the new tools -- particularly in the area of lifecycle automations based upon cross-metamodel integrations, pattern assets, and transformation assets -- far exceeds what could be achieved with Rational Rose or XDE. Copyright IBM Corp All rights reserved. Page 55 of 66

56 Appendix A: Rational Rose and XDE compared with the new tools theories of operations Common misconceptions The new tools do not support Reverse Engineering It is literally correct to say that the new tools do not support Reverse Engineering in exactly the same way that Rational Rose and XDE did. Nevertheless it is not correct to say that the new tools do not support Reverse Engineering. In fact, the new tools support Reverse Engineering much more effectively than Rational Rose and XDE do. Consider: In Rational Rose or XDE You reverse engineer your code, which does little more than produce a UML model that captures the structural semantics of the code. For the most part, you then must create your own diagrams in UML. The diagrams must then be synchronized to the code on an ongoing basis (that is, you must either use auto-synchronization or periodically repeat the reverse engineer step). In the New Tools You simply start creating diagrams of your code. Compared to Rational Rose or XDE, the new tools provide better capabilities for automatically populating and formatting diagrams. The new tools also provide the Topic Diagram and Browse Diagram capabilities, meaning you will invest less effort in creating and maintaining your code-level diagrams over time. Furthermore, when you change the structural semantics of your code, all diagrams that depict that code are automatically updated. The new tools do not support Round-Trip Engineering Again, it is correct to say that the new tools do not support Round-Trip Engineering in exactly the same way that Rational Rose and XDE did, using a UML model to capture code structural semantics. Instead, the new tools support 3GL Domain Modeling that lets you diagram code structural semantics directly. The functional utility of Round-Trip Engineering and 3GL Domain Modeling is the same, but 3GL Domain Modeling works better in many regards. Refer to the discussion in the previous section entitled Why the change from RTE to 3GL domain modeling? Rational Rose and XDE Round-Trip Engineering keeps the implementation in sync with a design model This is simply not true. Rational Rose and XDE s Round-Trip Engineering enables you to keep the implementation in sync with a UML implementation model that expresses the same level of abstraction as the code itself. That is effectively the same thing that is accomplished with 3GL Domain Modeling in the new tools. If you use Rational Rose or XDE to maintain both a UML code-level model and a more abstract UML design model, then you know that neither Rational Rose nor XDE provides tools to help keep those two UML models in sync. Similarly, if you maintain a design model, an analysis model, and a use-case model, you must keep them all aligned without tooling assistance. Note that the new tools do not prevent you from defining UML models at a code level of abstraction and generating code from them, and in fact this type of usage is expected. But they do not provide technology for keeping such models synchronized with code. This type of usage generally corresponds to the Replaceable Models practice depicted in Figure 48, wherein the transformed conceptual elements in the design model are considered dispensable Copyright IBM Corp All rights reserved. Page 56 of 66

57 once code has been generated, and 3GL domain modeling is used thereafter. 1. Replaceable Conceptual models ITERATE 3. Evolve design and implementation using diagrams in conceptual models that contain a mix of conceptual and implementation elements Design Activity 2. Generate code, morphing the diagrams to point to generated code Construction Activity Figure 48: Process using the new tools Development cases compared Scenario: MDD, new development This example considers what today is an atypical scenario -- few organizations these days are doing wholly green field development -- that nonetheless makes for a clean and simple illustration of the differences in the Rational Rose or XDE and the new tools theories of operation. Suppose also that in this scenario you are following a fairly traditional MDD process such as that suggested by the RUP methodology. As illustrated in Figure 49, with Rational Rose or XDE you would: 1. Start with business models (business use-case and business analysis) 2. Identify use-cases that should be automated and represent them as system use-cases 3. Elaborate those use-cases using interactions among hypothetical analysis classes 4. Refine and refactor the analysis model into a high-level conceptual design 5. Then you do one of the following: Keep refining the design model to add all details necessary to achieve desired code generation Copyright IBM Corp All rights reserved. Page 57 of 66

58 based on the simple 1:1 code generation mappings supported by Rational Rose and XDE (this effectively turns the design model into an implementation model) Create a UML implementation model, starting as a clone of the high-level conceptual design, and refining it to add all details necessary to achieve desired code generation. 6. Generate code 7. Keep the code and the implementation model in sync using manual or automatic model-code synchronization (Round-Trip Engineering) 8. if you decided to retain your high-level design model at Step 5, keep it in sync with the implementation model through a process of manual inspection, comparison, and revision. (This is also true for reconciliation between specifications and models at other abstraction levels.) Rose & XDE 1 Traceability done manually (or not at all) Business Models refine 2 System Use-Case ITERATE 8 5 refine refine Analysis Early Design Refine design model to codeequivalent level of abstraction Implementation Generate code, sync model and code while fleshing out Implementation ( RTE ) 7 Figure 49: MDD in new development using Rational Rose or XDE As shown in Figure 50, with the new tools you will: 1. Start with business models (business use-case and business analysis), potentially with the aid of business-level modeling pattern assets. 2. Identify use-cases that should be automated, and represent them as system use-cases, potentially by generating the system use cases based on the business use-cases using a transformation asset. 3. Elaborate those use-cases using interactions among hypothetical analysis classes, potentially generating a substantial number of the analysis classes and collaborations from the use cases by using a transformation asset or systems analysis pattern assets. 4. Refine and refactor the analysis model into a high-level conceptual design, potentially using pattern and transformation assets. 5. Generate code from the design model, ideally using sophisticated transformations that implement 1:m mappings from model elements to code elements, allowing you to keep the design model expressed at a higher level of abstraction. Copyright IBM Corp All rights reserved. Page 58 of 66

59 6. During construction, use 3GL domain modeling so that you have code-level diagrams that always reflect the true state of the code, and through which you can directly edit the code. 7. Keep the design model in sync with the implementation model through a process of manual inspection, comparison, and revision. (Again, also do this for reconciliation between specifications and models at other abstraction levels.) New Tools Transform (embedded patterns) Apply Patterns refine 1 2 Apply Patterns Traceability provided in part by transformations Business Models System Use-Case ITERATE 7 Transform (embedded patterns) Transform (embedded patterns) Transform (embedded patterns) 5 refine Apply Patterns refine 3 4 Apply Patterns Application Analysis Application Design Abstraction level remains higher than code, transformations will fill in the finer details as appropriate to the target platform and infrastructure. Implementation 6 Implementation domain modeling Figure 50: MDD using the new tools Scenario: Reverse Engineering Figure 51 illustrates how with Rational Rose or XDE you would: 1. Use the tool to Reverse Engineer the code into a UML implementation model. 2. Build diagrams in the UML model. 3. Keep the code and the implementation model in sync using manual or automatic model-code synchronization (Round-Trip Engineering), along with manual formatting adjustments to the diagrams. Copyright IBM Corp All rights reserved. Page 59 of 66

60 Rose & XDE Compose more abstract views by hand (or not at all) Regenerate or commence model-code sync (RTE) 3 Modify UML implementation model Modify code 1 Reverse Engineer code into separately persisted UML implementation model ( code model in XDE s case). Then build diagrams. 2 Figure 51: Reverse Engineering using Rational Rose or XDE Figure 52 illustrates how you would accomplish this with the new tools: 1. Just start creating diagrams using UML-like notations, and use them to visually edit, explore, refactor, and extend the implementation code. New Tools Composition of more abstract views aided by Harvest capability and possibly by reverse transformations 1 Compose and generate diagrams, visually explore, edit, and extend the solution (3GL Domain Modeling) Figure 52: Reverse Engineering using the new tools Copyright IBM Corp All rights reserved. Page 60 of 66

61 Scenario: incorporating existing code as part of new development In this scenario, you are working on a project to design and build a new system, application, or component. Existing components that were developed outside of your project are available. You wish to incorporate them into your solution by calling on them via their exposed APIs. These may include a mix of APIs to components developed within your organization (infrastructure, services) as well as APIs to components acquired from other sources. These would also include the APIs of the SDKs for the language(s) you are using. With Rational Rose or XDE, as shown in Figure 53, you would: 1. Start with one of the following: a. Create a UML implementation model following a top-down MDD process as previously described in the MDD, new development scenario b. Create a UML implementation model by reverse engineering from existing application code c. use a mix of the two approaches 2. Reverse engineer the APIs of the existing components into UML library models (Rational Rose calls them frameworks, and you build your application models directly in the framework model. XDE calls them reference models, and you build your application models in their own model files, separate from the library model files). To some extent, Rational tools will have already done this work for you and packaged the library models with the Rational Rose or XDE product In your Rational Rose or XDE implementation model, draw associations to the library model types, or simply specify the types of the attributes and parameters in your implementation model by spelling out the fully-qualified name of the desired type as the value of the attribute s or parameter s type reference property 4. As you move to updated versions of language SDKs or other APIs, you must install or reference the newer version of the corresponding library models, and re-resolve references from your application model to the library model. Rose & XDE refine 1a 1b refine refine Create relationships between your application s implementation model elements and library model elements 4 X 3 2 Reverse Engineer code into UML library models ( framework models in Rose, reference models in XDE). Figure 53: Incorporating components using Rational Rose or XDE 17 This level of support is limited primarily to the Java and J2EE framework APIs. In Rational Rose there are VB6 and VC6 frameworks. The XDE edition for Visual Studio automatically reverse-engineers assembly models as needed for the.net runtime types. Copyright IBM Corp All rights reserved. Page 61 of 66

62 Figure 54 shows how you will accomplish this using the new tools: 1. See the existing types in an Explorer view (for example, the Package Explorer) 2. For implementation domain modeling, just drop the components on diagrams, and create relationships from the implementation types of your application. 3. For conceptual modeling, just drag them onto diagrams in your UML model thereby creating isual references or code proxies in those diagrams. Create relationships from your conceptual elements to the visual references. Or, to specify the type property of attributes and parameters, use the available type selection dialog to find and select the desired type. Another option (as in XDE) is simply to spell out the fully qualified name of the existing type in the type property of the attribute or parameter, or use the : notation to specify the type when you edit the name of your attribute or parameter. New Tools Relationships drawn between conceptual elements and visual references have semantic meaning in the conceptual model (no code is generated for the existing implementation type, but the code generated for the referencing conceptual type does make the correct type reference) Conceptual design model for new app 3 Drag previously developed type from Package Explorer onto conceptual model diagram, creating a visual reference 1 2 Existing implementation artifacts, depicted in 3GL Domain Model diagrams, Package Explorer view, etc. Figure 54: Incorporating components using the new tools Copyright IBM Corp All rights reserved. Page 62 of 66

63 Appendix B: Business-Driven Development In a modeling context, Business Driven Development (BDD) refers to a MDD approach that bridges the traditional gap between Business (the modeling notations and techniques applied by business process analysts) and IT (the modeling notations and techniques applied by software architects). The main focus of BDD is on formal relationships between business goals and objectives, the business processes that realize them, and the business services that realize tasks in the business processes, as shown in Figure 55. Create domain models Business IT Business Domain Model Define process models Map business model tasks to system use cases and component/service design contracts Business Process Model Business Application Model Figure 55: Formal relationships expressed in BDD BDD is enabled in the new tools by virtue of their being built atop the open modeling infrastructure of Eclipse. As shown in Figure 56, that infrastructure enables a business process model (built with IBM WebSphere Business Integration Modeler, which is based on a metamodel known as BOM) to be simply opened in RSM or RSA with the result that The process can be viewed as a UML Activity model UML use-cases are generated for the tasks in the process UML components and interfaces are generated that represent the usage contracts for a set of candidate services that could automate some of the tasks Design/Build Run/Manage Business Modeling (BPM) IT Modeling (UML, SQL) J2EE/Web Services Development Wrapping Orchestration (J2EE, BPEL) Deployment J2EE App Svr Web Services Management Component Mgmt App Mgmt Biz Rules BOM UML SQL C++ SPEM J2EE CWM BPEL Java UML2 J2EE WSDL BPEL XML J2EE SQL J2EE XML CIM Metamodel-to-Metamodel Transformations and Traceability Links Copyright IBM Corp All rights reserved. Page 63 of 66