ISBN-10:
0782142052
ISBN-13:
9780782142051
Pub. Date:
05/23/2003
Publisher:
Wiley
Mastering Rational XDE / Edition 1

Mastering Rational XDE / Edition 1

by Wendy Boggs, Mike Boggs

Paperback

Current price is , Original price is $59.99. You
Select a Purchase Option
  • purchase options

Product Details

ISBN-13: 9780782142051
Publisher: Wiley
Publication date: 05/23/2003
Series: Mastering Ser.
Pages: 614
Product dimensions: 7.52(w) x 8.98(h) x 1.33(d)

About the Author

Wendy and Mike Boggs authored Mastering UML with Rational Rose and Mastering UML with Rational Rose 2003, both for Sybex. Wendy, a Rational Rose certified instructor, has provided consulting services in object-oriented analysis, design, and modeling to firms, such as Toyota, Electronic Data Systems, and ADP. Mike is a project manager with extensive object-oriented design experience. He has managed large-scale projects and advised organizations in the adoption of an object-oriented methodology.

Read an Excerpt

Mastering Rational XDE


By Wendy Boggs

John Wiley & Sons

ISBN: 0-7821-4205-2


Chapter One

Introduction to Rational XDE

Rational has developed an exciting new tool designed especially for designers and developers of Java and Microsoft .NET applications. This tool combines the modeling power of Rational Rose with the Integrated Development Environment (IDE) of a programming tool. This chapter introduces you to this new tool-Rational eXtended Development Environment (XDE)-some of its features, and how it can be used in systems design and development.

Featured in this chapter:


* Evolution of XDE


* Introducing visual modeling


* Introducing Java and visual modeling


* Introducing .NET and visual modeling


* Features of Rational XDE


* XDE user interface


* Versions of Rational XDE

In the Beginning ...

It is evening. The sky is still and there is a hush across the savannah as the cavemen gather excitedly around the stony wall. A small lizard scurries in and then, as if sensing the tension in the air, hastily scuttles away again. Grunting nervously, the leader of the cavemen reaches for a jagged rock and carefully begins marking the wall's surface. One of the others grunts out a name. Gradually, a stick figure emerges, then an oval. Some in the group yell and point wildly as the leader scratches a thin line between the other symbols. The excitement grows as he inscribes names for these items: "Actor" and "Use Case." It is evening, and a system has been born.

This was the world before XDE.

Okay, so maybe it wasn't that bad, but we have evolved a little. Back in the good old days, we would work with a Unified Modeling Language (UML) tool such as Rational Rose to design our system and its architecture. Then we would move all that stuff over to a development environment such as IBM's WebSphere to write the actual code to the design specifications. The UML tool would help a lot in this transition by automatically creating at least some skeletal code from the design. So there we were, switching to a new tool. But then, oops! We would need to change the system design, so we'd have to switch back to the UML tool. We'd work on the design a little, but then we need to switch back to the development tool to code some more. So we'd make the transition again, using the round-trip engineering features of the UML tool. But once again, we'd discover we needed to change the design, so it would be back to the other tool. After a while, we'd make some changes and, gulp! We'd realize that we forgot to synchronize those changes back in the model. So then our model would be out of sync with the code. A few dizzying cycles of this, and an aspirin or two, and we'd probably have gotten a little frustrated.

And so it went. We were still able to design and code our system, but the switching back and forth between tools could become a bit of a headache. Once the model and code were out of sync, it became an increasingly difficult task to realign them.

One of the problems was that constantly switching environments led to a shift in focus. We'd take off our designer hats and put on our programming hats to work in WebSphere, and then we'd put our designer hats back on to work in Rose. This type of transition does not always lead to good code. The developers should always be thinking about the system design as they're building the code. Chances are, as they are working on code, they'll find areas of the design that could use a little optimization. On the other side, the designers always have to keep the code in mind as they are building the system design. On many projects, the developers and designers are actually the same people. Aside from the split personality issues, they have to use multiple tools and switch back and forth between them to accomplish their goals. Rational XDE changes all that.

XDE was specifically designed to break down the "brick wall" barrier between design and coding -to help us keep in mind that they are just different perspectives of the same solution. Just as requirements can't be thrown over the wall to designers, the system design shouldn't be thrown over the wall to the developers. XDE helps us see the system design and code as we go along, rather than allowing us to become too focused on one or the other. It combines the design and development environments into a single, comprehensive tool. We will spend a lot of time in this book discussing the two main perspectives of XDE-code and design-and how these integrate into a system.

Another challenge the development teams ran into was keeping the code and the design synchronized. Although tools would help with this process, it was still a laborious effort, and in many cases, it caused teams to let the two get out of sync. As a result, the systems became difficult to maintain. Teams didn't have a clear picture of the system design without poring over hundreds or even thousands of lines of code. Frequently, the team undertaking an enhancement to one of these systems would need to reconstruct a goodly portion of the design in order to get their arms around the system and be able to proceed with the changes.

Sometimes the development teams want to rework some code in their systems to bring them into current standards or take advantage of new ideas. This kind of reworking really occurs during the first development of a system. If you are a developer, take a look at some code you wrote early in a project compared to that from a later iteration. Are you still willing to claim authorship of the original code? Or would you rather make some changes to it before showing it to others?

This concept of reworking the code is referred to as refactoring. It is often done, but very informally and on an ad-hoc basis. The problem is that some chunks of the system become optimized and standardized, but other chunks go untouched. Different people can refactor different chunks of the system without using a consistent method to do so. This causes many of the true benefits of refactoring-code standardization, optimization, consistency, and readability-to go unfulfilled. As you go through a project, you should always be looking for opportunities to improve the design and code. But if refactoring is such a great thing, why aren't more companies doing it? Some of the reasons we've heard are


* There is barely enough time in the project to finish it, let alone think about making it better.


* Refactoring is perceived to be a manual and difficult process.


* Developers like working on new and exciting things, not on tweaking the things they've already built.

With all these issues floating around, no wonder refactoring isn't done more often! But XDE can help make this task more palatable and even enjoyable. Granted, XDE can't bend the laws of time and space to give you more time on the project, but it can help make some of the more tedious tasks of design and development easier and quicker. For example, XDE can keep the model and code synchronized at all times. You can now invest the time you've been spending doing this tedious task in refactoring. XDE can also decrease the amount of time you need to use patterns. Before XDE, you selected a pattern you wanted, designed it, and coded it. Now you can select the pattern you want, walk through a short wizard, and it is built for you. Again, you can now invest the time you save in refactoring-or in going home on time for once! Now that XDE has given you all this extra time to spend refactoring, we're going to sweeten the deal by explaining how you can cut the refactoring work itself in half. Because the model and code are synchronized, you only have to refactor one or the other. Without the synchronization, you would need to refactor both the code and the model, and then manually check to be sure the two are synchronized.

Finally, another problem you encounter when you use separate design and development tools is not being able to easily take advantage of reuse. Reusability is the holy grail of object-oriented development, yet few developers really achieve it. Some of the reasons for this are


* Project teams don't have time to look into reusing pieces of other projects.


* Frequently, there is no repository of reusable items that a team can browse. By the time they track down the potentially reusable items, they've lost the time advantage that they would have gained from reuse.


* A project may be perceived as "so different from anything that's been done before that we couldn't possibly reuse anything."

Promoting reuse is one of the major reasons Rational created XDE. It incorporates both design and implementation patterns into a single environment. The tool lets you browse and incorporate elements of multiple models. Rather than have you research patterns in a book, learn how to use the ones you want, and then manually design and code them, you can simply walk through a few wizards to incorporate the patterns into your model and code. Because XDE lets you implement patterns at a granular level, you are working with patterns that can apply in just about any system. Even if the organization's business processes are unique, you can take advantage of reuse as much as possible. We will be focusing a great deal on patterns and refactoring in this book, and we'll show you how XDE can help in both of these areas.

Introducing Visual Modeling

Visual modeling is, as its name suggests, a way to visualize the design and architecture of a software system. The concept has been around for a long time, but the notation has changed. Remember those flowcharts we had to create in college before we wrote the code? (Actually, most of us built the flowcharts after we wrote the code, but that's another issue.) Visual modeling is essentially the evolution of that concept. It is a blueprint we create before we code, so that we know the code will have a solid design foundation.

One of the key advantages to visual modeling is that you can use it to make changes to a software system relatively cheaply. Let's go back for a minute to the practice of creating the flowchart after we wrote the code. It was nice to eventually have a documented design, but we lost the ability to really analyze the system architecture before the code was written. Once the code is built, it can be extremely difficult to make changes to the design, especially extensive changes. If we build a visual model, though, we can analyze, tear apart, and restructure the system's architecture before the code is even built. Over the lifetime of a system, this can save thousands or even hundreds of thousands in maintenance costs.

This is especially relevant for large-scale systems. Without a blueprint, there is no guarantee that the code created by different developers will integrate. There is also no guarantee that the same design approach was taken in different parts of the system, or that the code is consistent. The only way for someone to understand the system structure is to go through the code itself, trying to visualize how the system was put together and how it can best be modified.

We wouldn't do this with buildings (imagine someone trying to build a skyscraper with no blueprints), but we've been able to get away with it, at least to a certain extent, in information technology. This is because an information system is somewhat unique-it is possible to go back in and change the architecture of a system that has already been built. It may not be easy, it may not be cheap, but it is possible. This practice has come at a great cost, though, and we in the information technology industry are moving past this informal way of designing applications to a more systematic approach.

A fairly recent development in visual modeling is the creation of the UML, which is used by XDE, and will be used extensively in this book. The UML is a series of diagrams and a set of notation that is used to visually model system design. It was first developed in the mid 1990s, as the three methodologists Grady Booch, Ivar Jacobson, and James Rumbaugh (collectively known as the "three amigos") sought to unify their different modeling approaches. These three experts worked with other methodologists to incorporate best practices from the many different modeling notations available at the time, such as Object-Oriented Software Engineering (OOSE), Booch, and Object Modeling Technology (OMT). UML version 0.9 was released in 1996. In 1997, a consortium of individuals and companies organized by Rational Software responded to a request for proposal by the Object Management Group (OMG) for a common metamodel to describe software-intensive systems.

Over time, the UML has been modified and expanded to incorporate ideas from new techniques and technologies, such as web application development and formal business modeling. However, it has remained independent of any specific tool, programming language, or development methodology. Instead, it is intended to be a general notation that you can use to analyze and design any object-oriented system.

The UML is currently controlled and maintained by the OMG, a vendor-independent standards body. Many companies, both large and small, have worked with the OMG to contribute to the growth and development of the UML. For more information about the OMG, or to download the latest UML specifications, see omg.org.

The UML contains many different types of diagrams, as shown in Table 1.1. Each of these is intended to give you a slightly different perspective of the system. Use Case diagrams, for example, give you a sense of what the system will do from the customers' point of view. Class diagrams are created from the developers' point of view, and Component diagrams from a system integrator's point of view. Taken together, these diagrams give the team a complete picture of the system and its architecture.

With the complete blueprint provided by the UML diagrams, the team can debate and then document the decisions made in the system architecture. More importantly, the diagrams become a repository of information that the team members can use to communicate more effectively with one another. Anyone needing to see information related to the system design can simply examine the UML diagrams.

The UML appears to be rapidly becoming the standard modeling language used in the industry. It has been adopted as a standard by numerous organizations, and more and more tools are being created to support the notation.

What's New in UML 1.4

The most recent version of the UML is version 1.4, which was made public in 2001. Some of the major changes made in this version include the following:

Refinement of component modeling This is to better support the modeling of component-based systems using technologies such as Enterprise JavaBeans (EJB) or COM+.

Refinement of collaborations and collaboration instances The UML specification now includes formal descriptions of collaborations (a set of roles and associations that define the participants needed to accomplish a specific task), interactions (the communications between the participants), instances, and collaboration instance sets. The new UML specification also introduces the concept of a parameterized collaboration, which is a generic way of representing a design pattern. These types of collaborations can be used for documenting design patterns and frameworks.

Refinement of profiles Profiles are used to model a specific implementation of the UML. The UML specification now more clearly defines how the UML can be extended and customized for a specific domain. It requires that profiles extend, rather than modify, the documented UML specifications.

In addition, many other minor changes and refinements were made to the specification. For a complete copy of the UML 1.4 specification, see omg.org. Work is currently underway to develop version 2.0 of the UML, which will be a major revision of the standard. Visual modeling is becoming increasingly important. In fact, UML 2.0 is designed to pave the way for executable models. See the OMG website for more information.

Introducing Java and Visual Modeling

Due to the richness of the UML and the fact that Java is a pure object-oriented language, the majority of Java constructs can be easily modeled in the UML. UML can be used with Java 2 Standard Edition (J2SE) or Java 2 Enterprise Edition (J2EE).

(Continues...)



Excerpted from Mastering Rational XDE by Wendy Boggs Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Table of Contents

Introduction.

Part I: Liberated Development with Rational XDE.

Chapter 1: Introduction to Rational XDE.

Chapter 2: XDE in the Software Development Lifecycle.

Chapter 3: Introduction to the Exercises: A Study for Real-World Application Development.

Part II: Visual Modeling with XDE.

Chapter 4: Integrated Use Case Management.

Chapter 5: Modeling Java and J2EE Elements in XDE.

Chapter 6: Modeling Visual Studio .NET Elements in XDE.

Chapter 7: Modeling Databases with XDE.

Chapter 8: Publishing and Reporting Models.

Part III: Patterns.

Chapter 9: Using Patterns.

Chapter 10: Gang-of-Four Patterns.

Chapter 11: Introduction to Reusable Asset Specifications.

Chapter 12: Creating Your Own Patterns.

Appendix: Getting Started with the UML.

Index.

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews