Home

Premiere Issue Winter 1998/99 Spring 1999 Summer 1999 Search Archived Articles

About Rational Rose

About the UML

Premiere IssueOctober 1998

The Visual Modeling of Software Architecture for the EnterpriseGrady BoochSoftware Architecture and the UML

Making the Earth MoveChristian Buckley & Darren PulsipherThe Paradigm Shift to OO Development

Inside Rose: Building Data-Centric ApplicationsSunny Gupta & Christopher C. ArmstrongAccessing and Manipulating Data with RoseDA

The Process and the ProGeorge BullockRational Product Integration Focus -- Rose and RequisitePro

When Vision Become RealityLisa DornellRose Case Study Featuring MCI Systemhouse

Partner Perspective: Quantifying Quality in Your OO ModelsBrian LyonsMetrics Magic from Number Six Software

Death to the Web WormLisa DornellRose Case Study Featuring Visient Corporation

Bonus Article . . . On-Line OnlyDoug RosenbergOptimizing Rose 98 to Support Use Case Driven Object Modeling

Publisher's Note Adam Frankl

Letters to the Editor/Ask the ExpertTerry Quatrani

Amigo Page Grady BoochRational Rose: Past, Present, and Future

Rose 101 Naveena BerenyRose Basics for the Beginner

Extreme Rose Tom SchultzTips and Tricks for the Experienced Rose User

Magnus Opus Magnus ChristersonFrom Use Cases to Components

UML NewsBook Review: UML Toolkit

Extending RoseJohn HsiaAn Architectural Overview

Veronica's WebVeronica HerreriaThe Rose Architect Constructs a Web

RoseLink Review Rich OisethThe Rose Business Process Link from Ensemble Systems

Copyright © 1998 Rational Software and Miller Freeman, Inc., a United News & Media company.

Home

Premiere Issue Winter 1998/99 Spring 1999 Summer 1999 Search Archived Articles

About Rational Rose

About the UML

Grady Booch is Chief Scientist at Rational Software Corporation.

The Visual Modeling of Software Architecture for the Enterprise

by Grady Booch

A successful software organization is one that consistently deploys quality software that meets the needs of its users. An organization that can develop such software in a timely and predictable fashion with an efficient and effective use of resources, both human and material, is one that has a sustainable business.

There's an important implication in this message: the primary product of a development team is not beautiful documents, world-class meetings, great slogans, or Pulitzer-prize winning lines of source code. Rather, it is good software that satisfies the evolving goals of its users and the business. Everything else is secondary.

Unfortunately, many software organizations confuse "secondary" with "irrelevant." To deploy software that satisfies its intended purpose, you have to meet and engage users in a disciplined fashion, so as to expose the real requirements of your system. To develop software of lasting quality, you have to craft a solid architectural foundation that's resilient to change. To develop software rapidly, efficiently, and effectively with a minimum of software scrap and rework, you have to have the right people, the right tools, and the right focus. To do all this consistently and predictably, with an appreciation for the life time costs of the system, you must have a sound development process that can adapt to the changing needs of your business and technology.

Modeling is a central part of all of the activities that lead up to the deployment of good software. We build models to communicate the desired structure and behavior of our system.

We build models to visualize and control its architecture. We build models to better understand the system we are building, often exposing opportunities for simplification and reuse. We build models to manage risk.

The Importance Of Modeling

If you want to build a dog house, you can pretty much start with a pile of lumber, some nails, and a few basic tools such as a hammer, a saw, and a tape measure. In a few hours, with little prior planning, you'll likely end up with a dog house that's reasonably functional, and you can probably do it with no one else's help. As long as it's big enough and doesn't leak too much, your dog will be happy. If it doesn't work out, you can always start over, or get a less demanding dog.

If you want to build a house for your family, you can start with a pile of lumber, some nails, and a few basic tools, but it's going to take you a lot longer, and your family will certainly be a lot more demanding than the dog. In this case, unless you've already done it a few dozen times before, you'll be better served by doing some detailed planning before you pound the first nail or lay the foundation. At the very least, you'll want to sketch out several ideas of what you want the house to look like. If you want to build a quality house that meets the needs of your family and of local building codes, then you'll need to draw some blueprints as well, so that you can think through the intended use of the rooms and the practical details of lighting, heating, and plumbing. Given these plans, then you can start to make reasonable estimates of the amount of time and materials this job will require. Although it is humanly possible to build a house alone, you'll find it to be much more efficient to work with others, possibly subcontracting out many key parts or buying pre-built materials. As long as you stay true to your plans and stay within the limitations of time and money, then your family will likely be satisfied. If it doesn't work out, you can't exactly get a new family, and so it's best to set expectations early and manage change carefully.

If you want to build a high rise office building, it would be infinitely stupid for you to start with a pile of lumber, some nails, and a few basic tools. Since you are probably using other people's money, they will demand to have input into the size, shape, and style of the building. Often, they will change their minds, even after you've started building. You will want do to an extensive amount of planning, because the cost of failure is high. You will be just a part of a much larger group responsible for developing and deploying the building, and so the team will need all sorts of blueprints and models to communicate with one another. As long as you get the right people and the right

tools and actively manage the process of transforming an architectural concept into reality, you will likely end up with a building that will satisfy its tenants. If you want to keep building buildings, then you will want to be certain to balance the desires of your tenants with the realities of building technology, and you will want to treat the rest of your team professionally, never placing them in any risk or driving them so hard that they burn out.

It's a curious thing, but a lot of software development organizations start out wanting to build high rises, but approach the problem as if they were knocking out a dog house.

Sometimes, you get lucky. If you have the right people at just the right moment in time and if the planets align properly, then you might, just might, get your team to push out a software product that dazzles its users. Typically, however, you can't get all the right people (the right ones are often already over-committed), it's never the right moment (yesterday would have been better) and the planets never seem to align (instead, they keep moving, entirely out of your control). Given the increasing demand to develop software in Internet time, development teams often fall back on the only thing they really know how to do well, namely, pound out lines of code. Heroic programming efforts are legend in this industry, and thus often its seems that working harder is the proper reaction to any crisis in development. Oft times, however, these are not necessarily the right lines of code, and furthermore, some projects are of such a magnitude that even adding more hours to the work day is just not enough to get the job done. If you really want to build the software equivalent of a house or of a high rise, the problem is always more than just a matter of writing lots of software-in fact, the trick is in creating the right software and in figuring out how to write less software. This makes quality software development an issue of architecture and process and tools. Even so, many projects start out looking like dog houses, but then grow to the magnitude of a high rise, simply because they are a victim of their own success. There comes a time when, if there was no consideration given to architecture, process, or tools, that the dog house now grown into a high rise collapses of its own sheer weight. The collapse of a dog house may annoy your dog; the failure of a high rise will materially impact its tenants.

Unsuccessful software projects all fail in their own unique ways, but all successful projects are alike in many ways. There are certainly many elements that contribute to a successful software organization, but one common thread is the use of modeling.

Modeling is a proven and well-accepted engineering technique. We build architectural models of houses and high rises to help its users visualize the final product. We may even build mathematical models in order to analyze the effects of winds or earthquakes on our buildings.

Modeling is not just a part of the building industry. It would be inconceivable to deploy a new aircraft or an automobile without first building some models, from computer models to physical wind tunnel models to full scale prototypes. New electrical devices, from microprocessors to telephone switching systems require some degree of modeling in order to better understand the system being built and to communicate those ideas to others. In the motion picture industry, storyboarding is central to any production, and each storyboard represents a model of the project being produced. In the fields of sociology, economics, and business management, we build models so that we can validate our theories or try out new ones with minimal risk and cost.

What, then, is a model? Simply put: A model is a simplification of reality.

A model provides the blueprints of a system. Models may encompass detailed plans, as well as more general plans that give a 30,000 foot view of the system under consideration. A model may be structural, emphasizing the organization of the system, or it may be behavioral, emphasizing the dynamics of the system.

Why do we model? There is one fundamental reason: We build models so that we can better understand the system we are creating.

Through modeling, we achieve four things:

● Models help us to visualize a system as it is or as we want it to be

● Models permit us to specify the structure or behavior of a system

● Models give us a template that guide us in constructing a system

● Models document the decisions we have made

The Unified Modeling Language

The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The UML gives you a

standard way to write a system's blueprints, covering conceptual things such as business processes and system functions as well as concrete things such as classes written in a specific programming language, data base schemas, and reusable software components. The UML is a widely-adopted standard that represents best practices and lessons learned from well over a decade of experience of modeling complex software-intensive systems.

Software Architecture

Visualizing, specifying, constructing, and documenting a software-intensive system demands that the system be viewed from a number of different perspectives. Different stakeholders-end users, analysts, developers, system integrators, testers, technical writers, and project managers-each bring a different agenda to a project, and each look at that system in different ways at different times over the life of the project. A system's architecture is perhaps the most important artifact that can be used to manage these different view points and so control the iterative and incremental development of a system throughout its life cycle.

What exactly is software architecture?

Software architecture encompasses the set of significant decisions about the organization of a software system: the selection of the structural elements and their interfaces by which a system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization.

Software architecture is not only concerned with structure and behavior, but also with usage, functionality, performance, resilience, reuse, comprehensibility, economic and technology constraints, and aesthetic concerns.

Architecture is design, but not all design is architecture. Rather, architecture focuses upon significant decisions, where significant is measured by the impact of changing that decision. For this reason, architectural decisions tend to concentrate upon identifying and controlling the seams in a system, which are described in terms of interfaces and mechanisms and so typically mark the units of change in the system.

As Figure 1 illustrates, the architecture of a software-intensive system can best be modeled by five interlocking views, with

each view being a projection into the structure and behavior of the system, and each view focused on a particular aspect of that system.

The design view of a system encompasses the classes, interfaces, and collaborations that form the vocabulary of the problem and its solution. This view primarily supports the functional requirements of the system, meaning the services that the system should provide to its end users. With the Unified Modeling Language (UML), the static aspects of this view are captured in class diagrams and object diagrams and the dynamic aspects of this view are captured in interaction diagrams, statechart diagrams, and activity diagrams.

The process view of a system encompasses the threads and processes that form the system's concurrency and synchronization mechanisms. This view primarily addresses the performance, scalability, and throughput of the system. With the UML, the static and dynamic aspects of this view are captured in the same kinds of diagrams as for the logical view, but with a focus on the active classes that represent these threads and processes.

The deployment view of a system encompasses the nodes that form the system's hardware topology upon which the system executes. This view primarily addresses the distribution, delivery, and installation of the parts that make up the physical system. With the UML, the static aspects of this view are captured in deployment diagrams, and the dynamic aspects of this view are captured in interaction diagrams, statechart diagrams, and activity diagrams.

The component view of a system encompasses the components that are used to assemble and release the physical system. This view primarily addresses the configuration management of the system's releases, made up of somewhat independent components that can be assembled in various ways to produce a running system. With the UML, the static aspects of this view are captured in component diagrams, and the dynamic aspects of this view are captured in interaction diagrams, statechart diagrams, and activity diagrams.

As this figure goes on to show, requirements are the main drivers of any software architecture. By drivers, we mean the most important forces that shape the architecture. Requirements manifest themselves primarily in the use case view. The use case view of a system encompasses the use cases that describe the behavior of the system as seen by its end users, analysts, and testers. With the UML, the static

aspects of this view are captured in use case diagrams, and the dynamic aspects of this view are captured in interaction diagrams, statechart diagrams, and activity diagrams. Additionally, there's often a need for supplemental requirements, which encompass all of the non-functional requirements of the system, as seen by its end users, analysts, and testers. These elements typically have no meaningful visual model, and so are represented in the UML as just textual requirements.

Each of these different views can stand alone, so that different stakeholders can focus on the issues of the system's architecture that most concern them. These views also interact with one another: nodes in the deployment view hold components in the component view that in turn represent the physical realization of classes, interfaces, collaborations, and active classes from the design and process views.

When you design a building, you must consider a number of different views: floor plans, elevations, electrical plans, heating and cooling plans, and so on. This is same idea behind these different views of a software architecture. Similarly, when you design a building, you choose a particular style that meets the functional, non-functional, and aesthetic needs of your users: you might build a house with a French country, Victorian, or ranch style. It's the same with software: the architectural style with which you build an embedded event-driven hard real time system will be quite different than what you'd use for a globally distributed GUI- and data-intensive system for the enterprise.

One of the most useful architectural styles for software that you'll find is the three-tiered architecture. This is a layered architecture, in which layers close to the user build upon lower layers that are closer to the machine. For many globally distributed GUI- and data-intensive systems for the enterprise, you'll find the following three tiers:

1. User Services, which format the information, and present it to the user.

2. Business Services, which implement the system's business rules.

3. Data Services, which maintain the Customer and Catalog Data of the application.

The main advantage of a three-tired architecture is that it provides a clear separation of concerns. In GUI- and data-intensive applications, the most volatile parts of your system

will be the user interface and the system's business rules. By separating user services from other services, the system's user interface can be changed without impacting the rest of the application. Similarly, by separating business services from other services, it's far easier to change the business rules of your system with minimal impact to the rest of your system. This kind of resilience to change is important in many organizations. Following this architectural style helps you build systems that are resilient.

The Software Development Process

Successful mission critical software of quality doesn't just happen over night. Rather, most successful software is grown in a controlled fashion. This is the antithesis of heroic programming, which is never a sustainable process for systems of scale.

A process is a set of partially ordered steps intended to reach a goal. In software engineering, your goal is to efficiently and predictably deliver a software product that meets the needs of your business.

The UML is largely process-independent, meaning that you can use it with any number of different software engineering processes. The Rational Unified Process is one such life cycle approach that is especially well-suited to the UML. The goal of the Unified Process is to enable the production of highest quality software that meets end-user needs within predictable schedules and budgets. The Unified Process captures some of the best current software development practices in a form that is tailorable for a wide range of projects and organizations. On the management side, the Unified Process provides a disciplined approach on how to assign tasks and responsibilities within a software development organization.

The Unified Process is an iterative process. For simple systems it would seem perfectly feasible to sequentially define the whole problem, design the entire solution, build the software, and then test the end product. However, given the complexity and sophistication demanded of present day systems, this linear approach to system development is unrealistic. An iterative approach advocates an increasing understanding of the problem through successive refinements and an incremental growth of an effective solution over multiple cycles. Built into the iterative approach is the flexibility to accommodate new requirements or tactical changes in business objectives. It also allows the project to identify and resolve risks sooner rather than later.

The Unified Process' activities emphasize the creation and maintenance of models rather than paper documents. Models-especially those specified in the UML-provide semantically rich representations of the software system under development. They can be viewed in multiple ways, and the information represented can be instantaneously captured and controlled electronically. The rationale behind the Unified Process' focus on models rather than paper documents is to minimize the overhead associated with generating and maintaining documents, and maximize the relevant information content.

The Unified Process is architecture-centric. The Unified Process focuses on the early development and baselining of a software architecture. Having a robust architecture in place facilitates parallel development, minimizes rework, and increases the probability of component reuse and eventual system maintainability. This architectural blueprint serves as a solid basis against which to plan and manage software component-based development.

The Unified Process is use case-driven. The Unified Process places a strong emphasis on building systems based on a thorough understanding of how the ultimately delivered system will be used. The notions of use cases and scenarios are used to align the process flow from requirements capture through testing, and to provide traceable threads through development to the delivered system.

The Unified Process supports object-oriented techniques. Each Unified Process model is object-oriented. Unified Process models are based on the concepts of objects and classes, and the relationships among them, and use the UML as its common notation.

The Unified Process is a configurable process. Although no single process is suitable for all software development organizations, the Unified Process is tailorable and can be scaled to fit the needs of projects ranging from small software development teams to large development organizations. The Unified Process is founded on a simple and clear process architecture that provides commonality across a family of processes, and yet can be varied to accommodate different situations. Contained in the Unified Process is guidance on how to configure the process to suit the needs of a given organization.

The Unified Process encourages objective on-going quality control and risk management. Quality assessment is built into the process, in all activities and involving all participants, using

objective measurements and criteria, and is not treated as an afterthought of a separate activity performed by a separate group. Similarly, risk management is built into the process, such that risks to the success of the project are identified and attacked early in the development process, when there is time to react.

In the Unified Process, the software development life cycle is divided into phases. A phase is the span of time between two major milestones of the process where a well-defined set of objectives are met, artifacts are completed, and decisions are made to move or not into the next phase. As the following figure illustrates, the Unified Process consists of the following four phases:

● Inception Establish the business case for the project● Elaboration Establish a project plan and a sound

architecture● Construction Grow the system● Transition Supply the system to its end users

Within each phase are a number of iterations. An iteration represents a complete development cycle, going from requirements capture to implementation and test, resulting in the release of an executable project.

During the inception phase, you establish the business case for the system and delimit the project's scope. The business case includes success criteria, risk assessment, estimates of the resources needed, and a phase plan showing a schedule of major milestone. During inception, it's common to create an executable prototype that serves as a proof of concept. At the end of the inception phase, you examine the life cycle objectives of the project and decide whether or not to proceed with full-scale development.

The goals of the elaboration phase are to analyze the problem domain, establish a sound architectural foundation, develop the project plan, and eliminate the highest risk elements of the project. Architectural decisions must be made with an understanding of the whole system This implies that you describe most of the requirements of the system. To verify the architecture, you implement a system that demonstrates the architectural choices and executes significant use cases. At the end of the elaboration phase, you examine the detailed system objectives and scope, the choice of an architecture, and the resolution of major risks, and decide whether or not to proceed with construction.

During the construction phase, you iteratively and incrementally develop a complete product that is ready to transition to its user community. This implies describing the remaining requirements and acceptance criteria, fleshing out the design, and completing the implementation and test of the software. At the end of the construction phase, you decide if the software, the sites, and the users are all ready to go operational.

During the transition phase, you deploy the software to the user community. Once the system has been put into the hands of its end users, issues often arise that require additional development in order to adjust the system, correct some undetected problems, or finish some of the features that may be been postponed. This phase typically starts with a beta release of the system, which is then replaced with the production system. At the end of the transition phase, you decide whether or not the life cycle objectives of the project have been met, and possibly if you should start another development cycle. This is also a point where you wrap up the lessons learned on the project in order to improve your development process to be applied to the next project.

Each phase in the Unified Process can be further broken down into iterations. An iteration is a complete development loop resulting in a release (either internal or external) of an executable product constituting a subset of the final product under development, which then is grown incrementally from iteration to iteration to become the final system. Each iteration goes through the various process work flows, although with a different emphasis on each process work flow, depending upon the phase. During inception, the focus is upon requirements capture. During elaboration, the focus turns toward analysis and design. In construction, implementation is the central activity, and transition centers upon deployment.

Going through the four major phases is called a development cycle, and results in one software generation. The first pass through the four phases is called the initial development cycle. Unless the life of the product stops, an existing product will evolve into its next generation by repeating the same sequence of inception, elaboration, construction, and transition phases. This is the evolution of the system, and so the development cycles after the initial development cycle are its evolution cycles.

Wrapping Up

Successfully deploying a software-intensive system for the enterprise involves much more than sitting down and banging

out piles of code. You have to build the right system, and that involves driving the development process with use cases. You have to build a resilient system, and that involves selecting the right architectural style. You have to grow your system, and that involves building it up iteratively and incrementally from a number of different views.

The UML helps to visualize, specify, construct, and document a software-intensive system. Imagine, then, when you attack problems of much greater complexity, how much more important it is for you to model your system from different views using the UML.

Read the case study that illustrates these issues. For more information about the UML please visit the UML Resource Center at www.rational.com/uml/.

Portions of this article are excerpted from Booch, G., Rumbaugh, J., and Jacobson, I., The UML User's Guide, Menlo Park California: Addison-Wesley Publishing Company, 1998.

Figure 2

About the Author

Grady Booch is Chief Scientist at Rational Software Corporation.

Back to Contents

Copyright © 1998 Rational Software and Miller Freeman, Inc., a United News & Media company.

Home

Premiere Issue Winter 1998/99 Spring 1999 Summer 1999 Search Archived Articles

About Rational Rose

About the UML

Christian Buckley is co-founder of Qoses.

Darren Pulsipher is co-founder of Qoses.

Making the Earth Move: The Paradigm Shift to Object-Oriented

by Christian Buckley & Darren Pulsipher

Death, taxes, and change are the only constants in life. But while most people have learned to deal with death and taxes, the fear of change endures as one of the greatest maladies of modern society. So why haven't we mastered our fear of change? Well, for one thing, it can be downright scary. In the business world, change is commonly associated with negative results, such as department reorganizations, politically motivated technology decisions, and the dreaded 'D' word-downsizing. Life has taught us that, in general, people have a difficult time making adjustments to their individual comfort levels. Compound their anxiety by throwing the word 'change' into the mix with all of the negative connotations it entails, and suddenly asking your team to "expand their area of expertise" becomes as simple as home dentistry.

Effective Change Through Communication

So how does a manager effectively "coerce" his team into adopting the object-oriented paradigm? Let's set the record straight-this is no small task. But every project has a beginning. The first step is to build a relationship of trust with your team. It takes preparation and a lot of listening, but once established, this relationship will allow you to help others recognize the benefits of implementing object-oriented methodologies by removing the fear. People fear what they do not understand. The next step is to help them recognize the benefits (and the risks) of the change by providing detailed answers to their questions. People are driven by what they feel. Present a clear

and concise message by offering a well-organized tactical and strategic plan for each level of the organization, thoroughly outlining the roles and responsibilities of each team member. If people understand the proposed change, they are less likely to fear it.

The three greatest barriers to change are communication, communication, and communication. If you cannot effectively communicate your ideas for change, you will not succeed. As the 'Evangelist of Change', you must uncover the concerns of the project team and be prepared to provide solutions.

Communication is a two-way street. You must listen to your team's questions without bias until you fully understand their concerns, and are able to respond with the appropriate solutions. As stated by Stephen R. Covey, "Seek first to understand, then to be understood." Remember that the move to object-oriented systems is a fundamental change in the way your engineers have been trained-a change in the way they think. Don't mandate change-instead, invite your team to make this shift in paradigms. For change to be successful, people must willingly follow.

But don't think you have to go through all of this alone-during preliminary steps of the process you will begin to identify those in your company who embrace your ideas, and who will act as Change Agents within each level of the organization. If you set an example by keeping on top of your team's questions, resolving the concerns that will undoubtedly pop up at every phase of the project, potential Change Agents will feel empowered to come forward and offer their support. Ultimately, without their help you will be unable to wage your multi-leveled attack. Understand the magnitude of this change-and realize that you cannot do it alone. Every organization within the company and all departments involved in the project need to buy into the idea of change. Inevitably, each business area will have different concerns about the project and the move to an object-oriented methodology.

Managing Management

Ok. You now have a plan, your team is behind you, and you have Change Agents strategically entrenched throughout your organization. There's just one small group of individuals standing between you and the successful implementation of your strategic goals-management. When the opportunity to make your proposal arrives, you will most likely feel like you are walking into a lion's den. Undoubtedly, they will counter your proposals with a barrage of calculated questions designed to

pick apart even the most water-tight project plans: How much will it cost? How long will it take? What will make this project a success? Is this just another fad in software development? What will the company have to learn? Will we be inadequate with this new technology?

Before you have a chance to catch your breath, middle managers may sense any doubts you exhibit and decide to pounce. They want to know: How am I going to get this product out on time? How do I keep my engineers happy and productive? Have our competitors also made this change? What will this do to our bottom line?

Your breathing is slow and deliberate as you pull yourself from the floor-your body bruised and beaten. As the lions surround you, waiting for you to run or assume some kind of defensive position, you reach desperately for your briefcase, searching for something to stay these beasts ...and you find it. Your detailed project plan with time and cost estimates. Your Work Breakdown Structure. Your systems architecture design and specification documents. Your business and process flows. Your descriptions of employee roles and responsibilities.

The lions back down for a moment, but they have seen these tactics before and start to move in for the final attack. But what they do not realize is that the key to your entire proposal goes beyond this documentation. You understand the need to clearly demonstrate the advanced utility and scalability of the powerful new channel of communication you are propounding. High-level presentations and cleverly written proposals are insufficient for communication of today's complex systems. A common modeling language is essential to the development of products in today's competitive marketplace-one that can be used by all departments and levels of the company, from Engineers to Marketing management, Business Analysts to the VP of Sales.

You reach into the deepest recesses of your arsenal and remove a tool-the crux of your proposal. You propose the Unified Modeling Language (UML).

Communication is the Solution

Following the UML methodology, you explain, Marketing, working together with Business Analysts and Technical Writers, builds its requirements based on Use Cases and Use Case Diagrams. Using these fundamental building blocks, they are able to piece together the specific functionality and tangible results of the project. Once the basic system components have been established, Scenarios and Sequence Diagrams are used

to define processes, relationships, and communications between components.

From there, Engineering uses Marketing's same Sequence Diagrams to expand the project, tying Objects together using Collaboration Diagrams. As the project becomes more complex, groups of Objects become classes, and the Engineers create Class Diagrams and State Diagrams that describe the behavior and identify attributes of the key classes of the system. Following this flow, Classes are allocated to language-specific Components for creation and implementation of code.

QA and Manufacturing also use the Sequence Diagrams created by Marketing and Engineering to further the project. While QA may improve or introduce new product Scenarios, Manufacturing utilizes Deployment Diagrams to construct the system or product.

The key to this process, you explain, is that every part of the company is working from the same model. If one group makes changes, everyone will see the changes and instantly understand the connections and impacts to their teams and processes. This instant communication is the greatest selling point of UML.

A Common Language

Communication channels must be kept open for any project to be successful. Whether your focus is manufacturing, software engineering, information systems, or telecommunications-a common language is the key to your project mastery. All departments and all levels of your company must buy into the idea that it is critical to align your development efforts under a single communication methodology. Driving your organization toward an object-oriented reality may seem as difficult as making the earth move. In fact, convincing your team to adopt this new paradigm may be one of the biggest challenges of your career-but it isn't impossible. Start with your team relationships. It is critical to build relationships of trust, recognizing and quickly removing the fear factor through clear communication of the benefits of UML, and by providing solutions. Present a clear and concise message by offering a well-organized tactical and strategic plan for each level of the organization, thoroughly outlining the roles and responsibilities of each team member, and, most importantly, establishing UML as the defacto communication vehicle.

If people understand change, they are less likely to fear it. And if you remove the fear, you can accomplish anything.

About the Authors

Darren Pulsipher and Christian Buckley are cofounders of Qoses, an OOA/D consulting and training company based in Tracy, CA. (http://www.qoses.com) Before Qoses, Darren spent most of his time working as a Software Engineer for Imation and Lucent Technologies. Christian has been a Project Manager and Technical Writer, but most recently a Channel Manager for Pacific Bell Mobile Services.

Back to Contents

Copyright © 1998 Rational Software and Miller Freeman, Inc., a United News & Media company.

Home

Premiere Issue Winter 1998/99 Spring 1999 Summer 1999 Search Archived Articles

About Rational Rose

About the UML

Christopher C. Armstrong is President of Armstrong Consulting.

Sunny Gupta is Product Manager for Data Engineering at Rational Software Corporation.

Inside Rose: Building data-centric applications with Rational Rose

Rational Rose 98 Enterprise Edition addresses the issues of accessing and manipulating data with its new add-in, Data Access Add-in.

by Sunny Gupta and Christopher C. Armstrong

Data Access Add-In automates building the data services tier of a multi-tier architecture and integrates your business objects with corresponding databases. Multi-tier architectures have separate layers or tiers representing different components of the application. The three primary logical tiers are the view layer that represents the graphical user interface (GUI), the business layer that includes the business object model and application code, and the data services layer that handles data access and manipulation. These logical tiers can be further distributed on many physical machines. With the advent of the Internet and other distributed technologies, other layers are now appearing in the architecture. See "Multi-tier Architectures..." for more information.

Data Access provides an architecture that you can use to build applications more quickly and with higher quality, as opposed to building the persistence architecture yourself. Data Access helps build the data services tier in your application and provides an interface for business layers that encapsulates the data storage and retrieval details. The Data Services tier contains mappings or translations between classes/ objects in your model and

tables in databases. Custom writing the data services tier can take anywhere from 20%-35% of the total effort in the analysis, design, and construction of your application. This requires considerable energy and resources to create redundant database calls and necessitating long-term maintenance over many years. When you use Data Access, you can be relieved of having to create and maintain a great deal of the data services tier. Figure 1 shows where Data Access fits into the multi-tier architecture.

Data AccessUsage Scenario

Using Data Access with Rational Rose allows your team to work in various development and run-time scenarios. One of the most common scenarios is when you first start designing your object model in Rational Rose. Your initial task is to define the classes, attributes, and relationships using the UML. These classes can then be generated into Visual Basic environment. Rose/Oracle8 can be used to visualize and generate a logical database schema, using standard UML associations and stereotypes to display relationships between different tables. Rose also generates and executes the appropriate DDL, which creates the physical database structures in the database. Once database and Visual Basic classes exist then Data Access queries them and provides capabilities to define translations by mapping class attributes and relationships to the columns of a table or view. Using Data Access's state-of-the-art wizards, you can generate the object to data mappings or translations from the Rose UML model to database model. Data Access uses Microsoft's ODBC technologies to access databases. ADO/OLEDB technologies will be supported in future releases. This allows Data Access to access major relational databases such as IBM DB/2, Oracle and Microsoft SQLServer. Data Access also maps relationships between classes using primary key and foreign key relationships between tables. Relationships in classes are implemented via references to other classes while database relationships are implemented via primary key and foreign key pairs. All class definitions, table definitions and their mappings are stored in a catalog and displayed in an Explorer-like interface. Because the design goals of object-based systems are quite different than the design goals of relational systems, you can un-map any class, attribute or relationship and re-map it.

Data Access uses code generation to implement persistent methods such as Load, Save, Delete and Refresh into each business object. These methods are generated in Visual Basic target language. All Microsoft COM languages such as VC++, VB and VJ++ will be supported in subsequent releases. Also for each mapped relationship, methods are inserted to manage relationships between objects (e.g. Customer has many Orders-

therefore a Customer class will have an Orders method which will return back a collection of Order objects). This is where you get real bang for your buck because Data Access allows you to map these relationships at design-time and resolves them for you at run-time.

Now that you understand the capabilities of Data Access you are ready to see how it works with your application. You use Data Access in two phases: design-time and run-time.

Designing with Data Access

You access Data Access through Visual Basic, and Data Access uses the information from the Visual Basic classes. This means that it has access to all classes and attributes or properties and relationships defined in the code generated from the Rose model. You also specify the data sources from which Data Access will access the data.

At design-time, Data Access allows you to:

● Query Classes and databases into the visual interface. ● Specify translations that indicate how classes, their

properties, and relationships defined in Rose will be made persistent in databases.

● Specify how to handle concurrency, transaction management, and data conversions.

● Test the mappings or translations to verify that you will access the correct data.

All this information is saved in a file called a catalog that your application will use at run-time. After you specify this information, you generate persistent methods which are used during run-time into the VB environment.

Data Access saves you a great deal of time and effort by automating the mappings or translations that derive object instances from data instances, and vice versa. Mappings are not very difficult to do manually, but they are usually very labor-intensive. For example, a Customer class implemented in Visual Basic might have the following methods for inserting a new object or for retrieving, updating, and deleting an existing object. If you were hand writing your data services tier you might write a data services class called CustomerData to handle persistent issues for class Customer (error handling has been omitted for brevity purposes). Figure 2 shows how load method would be implemented if a persistence layer was developed on its own.

There would be similar types of methods for Save and Delete. For the Save method, the data services class would need to issue either an SQL INSERT statement when inserting a new object or an SQL UPDATE when changing an existing object. The Delete would be pretty straightforward and would issue a SQL DELETE statement. Therefore, you can multiply the Load code above by about four times to get an idea of the extent of the work required for each class in your application. Now, the same code automated by Data Access can be see in Figure 3. The reduction in code size and having the mappings in a visual tool helps build more maintainable applications. However, all we have covered here is basic translation and persistence services. We have not dealt with concurrency, transaction management, security, or most importantly, the relationships between classes. When you create your mappings with Data Access, it handles all these issues for you.

If, for example, the Customer class had a one-to-many relationship with the Order class, you will have to write the following method (see Figure 4) in the Customer class to get a collection of Orders.

The same Relationship method generated by Data Access Add-In can be seen in Figure 5. That might not seem like a great deal of work, but all that we've only shown is how to get an instance of an object and a collection of related objects with a uni-directional relationship. Suddenly, a whole host of other questions arise, including concurrency and transaction management.

Data Access handles advanced issues such as relationships, concurrency and transaction management which has saved us 60-70% of tedious, error-prone data services coding effort at various projects during our consulting assignments. We found that it also increased the quality of our applications. For example, to load an object from the database without using Data Access, we would have to code directly to database API's such as ODBC (making over 15-20 calls to issue a "Select" SQL query), then massage the data when it came back, and convert tables into objects. With Data Access we only needed to make one API call into our run-time components. Using Data Access to define how your application accesses data can save you a great deal of time and effort at design time. It can also make your life easier at run-time.

Running Applications with Data Access

Once you have defined the mappings and other catalog information, Data Access provides run-time components to

serve up objects directly out of the database. In some sense, it abstracts the relational database to look like an object database.

The primary benefits of using Data Access at run-time are:

● It helps you build applications that encapsulate the object-relational translation code. Otherwise, custom object-relational translation code can proliferate throughout the system. This greatly reduces the amount of SQL that you typically have to embed in an application.

● The run-time engine is COM-based and language independent. Therefore, it will translate Customer.Load, Customer.Save calls from objects to databases and vice versa regardless of the language in which the request was made. Users only need to issue save, delete or load methods and Data Access converts objects to tables and vice versa. In the future, Data Access will be integrated with MTS in the future so that save and delete operations are running under MTS's transaction context.

● Data Access can retrieve relationships between objects without knowing the underlying database relationship structure. From Customer object, users can issue Customer.Orders call and the appropriate collection of orders will be to be retrieved back. Data Access knows how to traverse one-to-one, one-to-many, many-to-one and many-to-many relationships. As relationships are accessed, appropriate SQL calls are issued under the covers and database relationships are converted into object relationships.

● Data Access provides concurrency management. It allows multiple users to access the same data from the database by using optimistic concurrency. Users identify certain database columns (usually a timestamp column) during design time as concurrency column(s). Data Access caches the timestamp for the object when it is retrieved. Before updating that row, Data Access checks the concurrency column in the database row against the value for the data originally retrieved. If another user has updated the row, then an error is signaled to the user indicating the data has changed.

Although these benefits are useful to know, it's easier to understand the true value of Data Access when you see how it works at run-time. Figure 6 is a scenario diagram that shows the tasks and actors in the run-time scenario.

The following steps correspond to the diagram:

1. The order entry clerk opens the Customer screen.

2. The screen in turn sends the request to "getAll Customers" from the Customer process layer.

3. CustomerProcess layer communicates with Data Access run-time library to issue a "findAll" request.

4. The Data Access run-time libraries return a collection of customers, which are then displayed on the screen.

5. The order entry clerk selects a particular customer.

6. The screen in turn sends a message to the Customer object for its "AllOrders".

7. Data Access run-time libraries retrieves related orders for a customer and returns the result back, which is then displayed on the screen.

Many successful projects have been implemented using Data Access. Key benefits which customers realize are the ability to model components, data, and components that access data from within one tool. The UML, the industry standard modeling language, is used consistently to visualize object and data models. Data Access run-time capabilities save 20-25% of total development time. These tools facilitate iterative development because as the object model changes, the database model and the data access mappings can be automatically changed and vice versa. One customer, Logicon, Inc., is using Data Access to help them develop software for federal government agencies. This solution provides them with a well-defined logical and physical application architecture, which in turn leads to a scalable solution for their customers. These key features are only available as part of Rose 98 Enterprise.

Sidebar

Application Architecture: What are your options?

The term application architecture refers to the way in which software applications are logically and physically designed. The logical design specifies the structure of the application and its components without regard to where the components are physically located. The primary components of the logical design are the view layer, the business services layer, and the data services tier. Further, each one of these layers is broken down into other application-specific components.

The physical design specifies where the software components are going to be physically deployed. There is not a one-to-one correspondence between the physical design and the logical design of an application. A properly constructed logical design can easily be mapped to a variety of physical layouts and can change as the application's needs change and grow. The following figure illustrates three of the primary physical architectures: Fat Client, Distributed Client/Server, and Thin Client/Web Server.

Physical Architectures

The Fat Client physical architecture applies when the view layer, business layer, and data services layer all reside on the client machine. The database typically resides on a separate server. Client A shows the Fat Client architecture.

In Distributed Client/Server architectures the logical components are physically distributed on different machines as shown by Client B. The machines communicate with each other via a distributed component model such as DCOM, CORBA, or EJB. In Visual Basic 5.0 you can implement your components as ActiveX components and then distribute them via DCOM and deploy them at run-time using MTS.

The Thin Client/Web Server architecture, shown by Client C, is quite similar to Distributed Client/Server, except the view layer is completely written in HTML/ASP/Java. Web server technology such as Microsoft Internet Information Server (IIS) can be used to manage interactions between the client and the web server, the business components, and the run-time transaction processing.

Sidebar Figure 1

About the Authors

Sunny Gupta is product manager for Data Engineering Technologies at Rational. Sunny was co-founder and Vice-President at Vigor Technology which was acquired by Rational in 1998. He has served in many leadership roles in product development and product consulting. Sunny also worked as senior consultant and product architect for VMARK Software and IBM. You can reach Sunny at sgupta@rational.com.

Christopher C. Armstrong is President of Armstrong Consulting (http://www.armstrongconsulting.com) a Rational Enterprise Partner serving the Minneapolis/ St. Paul area. Chris is a Microsoft certified solutions developer, Rational certified consultant/ trainer, specializing in OOAD using UML. In addition, Chris recently presented at the Rational User Conference on multi-tier architecture and data services. You can reach Chris at chris@armstrongconsulting.com.

Special thanks to Amber Swope for her help on this article.

Back to Contents

Copyright © 1998 Rational Software and Miller Freeman, Inc., a United News & Media company.

Home

Premiere Issue Winter 1998/99 Spring 1999 Summer 1999 Search Archived Articles

About Rational Rose

About the UML

The Process and the Pro

Rational Product Integration Focus: Rose and Requisite Pro

by George Bullock George Bullock has been developing PC-based software for the last 8 years. His emphasis has been on database applications for business process automation. George is an accomplished musician who concentrates on solo jazz guitar arrangements. He lives in Glendale, CA with his lovely wife Julie, and his amazing son Penn.

In my years in the field of software development I've learned that there are three factors that contribute to making the process relatively painless: a comfortable chair, good music, and the best tools. About 18 months ago I began using Rational Rose and now it's fundamental to the way I design software. It's a big part of the way I work because it does what I want it to, when I want it to, how I want it to. Lately though, I've branched out into other Rational tools, and have begun using RequisitePro for our requirements management. And once again, Rational doesn't disappoint.

I must explain that I work in a small shop, but we program big. Case Parts is a commercial refrigeration parts company, but we understand the importance of quality software design-in part due to the vision of our president, Jon Jilg, who shares my enthusiasm for seriously cool technology. I've found that Rational has always been a great company for keeping in touch with their customers and for making reliable products. In terms of integration, Rose and RequisitePro are the first Rational tools we've used in tandem and I find the integration to be very nice. It's saved us a lot of time by taking over the chore of documentation; of making sure this document looks like that document, and ensuring that all of our documents stay in synchronization. It's hard enough to get programmers to do documentation, let alone to maintain it, so we all appreciate the ability of these tools to take over a lot of the grunt work and free us up to do the fun stuff.

RequisitePro allows us to start at a very conceptual level with the requirements for a product. We begin at a very sketchy level where we're just making lists: lists of business objects and, more importantly with ReqPro, lists of use cases. At this conceptual level

we write a paragraph of text describing the use case in very general terms. Then, as we continue to refine that use case, we can put in more detail.

A large part of my responsibility here has been to hammer out a workable N-tier architecture making use of a lot of the new Microsoft technologies such as Transaction Server and Active Data Objects. Rose has been especially helpful in helping me design applications and systems that fit the Microsoft COM specification. It's a complicated model, made simpler by Rose and ReqPro. The tools help me handle a lot of complexity in a manageable way. There's a lot of thought that has to go into how to architect systems of this size, and these tools help me keep track of that. Yes, it's in my head-but since my team isn't psychic, it really does no good to keep everything in my brain. With the clear documentation of ReqPro and the modeling functionality of Rose, all my ideas can be conveyed to the rest of the development team. It just takes the complexity off of my mind, takes over the juggling I have to do to keep in mind what the framework is and which pieces are talking to which other pieces; which pieces implement which parts of the architecture. I don't have to think about that so much with these tools acting as my memory base.

Figure 1

The main elements that we move from ReqPro to Rose are use cases, actors and business objects. We start with the basics, typing away, describing the system, and making lists of business objects, business rules and use cases. Once we've done that we highlight the portions of the documents that represent, say a business object, and with a few mouse clicks we turn those words into an actual elements in the ReqPro database. Then when we first go to generate the beginnings of a Rose model from ReqPro, the process is simply to map these requirement types onto model elements in the Rose diagram. For us, this is pretty much straight across the board correspondence. Use cases in ReqPro, which are simply titles like "User Creates Account" map to use cases in Rose. And actors in ReqPro correspond to actors in Rose; business objects in ReqPro correspond to business classes in Rose. Because you set this up yourself, it's a very flexible process. You generate, and all the elements of the ReqPro document that you need in the Rose document now appear as those elements in Rose.

Using these products together has two key benefits for us. The first is that it gives us a repository for elements of our software design and architecture. So when I draw a rectangle to represent a class, I'm not just scribbling on paper-I'm creating an element in a repository. I draw a class and add properties to it. Then, when then I need to use that class in another document or on another diagram all I really need to do is create a pointer to it in the

repository. So as you add methods to the element as represented on one document, you know that element, or property, or whatever is going to become part of the repository, not just a visual artifact on a piece of paper.

The other feature I really appreciate is the ability to keep various artifacts in sync, such as design documents and code; use cases and business classes. This ability is crucial. There are times during the lifecycle of a software system where you really need to be careful not to go down and start coding too early. You need to stay up in the design and conceptualize and massage it on the road to making it more implementation-specific. But then there are times when you've just got to get down and do some coding. And that's often the point where the design documentation and the code artifacts get out of sync forever. It's at this point when the code takes a cruise. It cuts loose from the dock and sails out to sea while the design documents stand on the shore and wave goodbye, never to see the code again. This tends to happen because nobody wants to do the ugly task of keeping the design documents in sync with the code artifacts. But Rose and ReqPro take over that job so your code and your documentation never lose sight of each other.

My team and I have found that using these tools in tandem has significantly improved our design efforts and removed a lot of the ground-level headaches you experience when designing software. And while I'm not yet willing to concede that they are more important than a comfortable chair and the music of Miles Davis, I must confess that they're close.

For more information about Case Parts and their development efforts, please visit http://www.rational.com/connection/success/caseparts.html or http://www.caseparts.com

Back to Contents

Copyright © 1998 Rational Software and Miller Freeman, Inc., a United News & Media company.

Home

Premiere Issue Winter 1998/99 Spring 1999 Summer 1999 Search Archived Articles

About Rational Rose

About the UML

Lisa Dornell is Features Editor of Rose Architect.

When Vision Becomes a Reality

Rose Case Study Featuring MCI Systemhouse

by Lisa Dornell

In 1726, Jonathan Swift wrote, "Vision is the art of seeing things invisible." In 1998, MCI Systemhouse is turning that art into a masterpiece with VISION* Solutions. Headquartered in Ottawa, Ontario, Canada, with project offices in the US and the UK, the VISION* Solutions business unit of MCI Systemhouse is a worldwide innovator in the field of enterprise IT systems for large organizations. Specializing in the automated mapping, facilities management, and geographic information systems (AM/FM/GIS) industry, VISION* Solutions cover all areas of utilities management, including engineering design, work order processing, customer service, maintenance records, and scheduling.

What is VISION*? Well suppose you're the Acme Electric Company, or some other utility or municipality with a network of facilities spread out across the map. VISION* keeps track of your actual physical equipment and its position in relation to everything else in your system. It can tell you what wires are connected to a specific pole. What gauge of cable connects two conduits. If adverse weather interrupts power supply, VISION* lets you quickly and easily see which of your customers will be affected. When you send a repair crew, it can tell you what equipment they will need, if the parts are in stock, and how much manpower will be needed to get it up and running again. The results of a query to the system can be displayed in a table, on a map, or both, facilitating the tracking of your crews, their work orders, and your equipment. Everyone from the scheduler making up work orders for the day, to the repairman out in the field can have access to the data they need. And any changes they make to the data become available to everyone else in the system.

VISION* has been built with a solid dedication to open systems at every level of its architecture, using Rational Rose to create object models that include spatial data and relationships. These models are designed with class hierarchies for the pipes, wires, roads and

other real-world objects from the customer's domain. Spatial data and attribute data are managed together in an Oracle database with a single system view throughout the enterprise. And in doing so, VISION* Solutions has entered a new era of domain object modeling.

"We use Rose to model complex, information-rich business systems," explains Stephen Fanjoy, Manager of Marketing and Alliances for VISION* Solutions. "These systems are typified by complex management infrastructures and a vast array of physical objects to support. In the past, maintaining these systems was a daunting task. But Rose and the UML are huge steps forward in helping the whole AM/FM/GIS industry to manage complexity. Our designers were able to extend Rose to handle VISION*'s spatial data. As a result, VISION* can now represent complex systems in a way that is at once more powerful and easier to use. Our customers get more accurate representations of their business workflow, improved decision-making, and the ability to lower their operating costs."

"VISION* started as a great technology idea," explains Stephen Hill, Managing Director of VISION* Solutions, "storing spatial information in a commercial relational database." This idea led to a decision in the mid-80's to use Oracle as the repository for that data. By making spatial information available in an open relational database, VISION* gave access to far more people than was previously possible. 90% of the information in VISION*'s market environment is spatially related. But for 20 years, this crucial information was unavailable to the vast majority of people inside of these organizations, due to the isolation of departmental systems and the difficulty of keeping track of equipment and personnel on paper.

In the past, utilities had to create and maintain mountains of blueprints, drawings, and plans of their network, with different departments and regions each maintaining their own sets, unaware of changes being made by other groups. Clerks and draftsmen fought a never-ending battle to keep up with the natural evolution of a utility's services. Not only was this difficult to develop, it was nearly impossible to maintain. For a large telecommunications company, for instance, the number of maps that need to be monitored could easily number in the hundreds of thousands. "And when you put something on a piece of paper, it's static," says Geoff Zeiss, VISION*'s Director of Software Engineering. "As soon as you've got something done, it's obsolete. There's no way to maintain it. But with VISION* and with Rose, it's maintainable."

As Technical Architect Stephen Brockwell explains, "VISION* is part of a completely object-oriented service offering." The core components of which are the Oracle database, Rational Rose

application modeler for both client and server, and VISION* Services for the spatial versioning of complex objects. In addition, the product suite includes a client ActiveX API, a server object model stored in a relational database, and Rational Rose-based development customization tools. "This allows VISION* to deliver to the customer a solution with immediate business benefits," he continues. "They can start converting information into the VISION* data model immediately. This is a benefit of having an open system of APIs, rather than a fixed system where new interfaces constantly have to be created."

For the VISION* team, getting this solution to the customer isn't enough; what counts is getting the right solution, customized to fit the client's specific needs. For while utilities may have similar problems, they often have very different infrastructures and business cultures. "The implementation of our product in six different telecommunications companies is basically six totally different implementations of the product," states Hill. The people at VISION* understand that and know it is impossible to create a software solution that meets the needs of every customer right out of the box.

"VISION* is also not a static product." According to Brockwell, "It is designed to evolve as the needs of the business evolve. As new requirements are found, new components can be added by simple customization. As new relationships and classes are discovered by analysis, these can be added to the model and deployed at the database level and in the business rules. Because the business rules are determined at run-time, the configuration management issues are minimized." Creating a customized, easily adaptable solution for their clients is of paramount importance to the developers of VISION*, and a key motivation behind their technological choices.

The people at VISION* see their business as being made up of four parts. First is their core technology, which includes the Oracle database, Rational Rose, and the UML. Second are the applications for specific business problems, such as the engineering analysis of circuits or the management of construction projects. Next comes methodologies, most specifically VISION* Works, a knowledge base of process management tools. Finally there are the service organizations-VISION* developers and partners who are conversant with the technology and methodologies of VISION* and who provide expert assistance in the areas of project planning, analysis and design.

According to Geoff Zeiss, Director of Software Engineering, a large part of VISION*'s total commitment to their clients is this final customization phase. When it comes to time to work on this part of the VISION* solution, he explains, "The tools I'll bring with me are

Rational Rose, the data model, and things like the Visual Basic shell of the application and the ability to tailor it. One of our governing design principles around the application was that it had to be extensible. And so we make use of things like Rational Rose, providing component-based architectures that we can take all or part of to craft a solution specific to our customers' needs."

Figure 1

It is this flexibility where the VISION* team most appreciates the power of Rational Rose. "We've used Rose to provide the main framework for the VISION* model," explains Brockwell. "You can go in and change any of the names of the objects and add new superclasses. You can change the table structure and change the associations until it all makes sense to your business. You've got working object rules, and the applications just plain work. For a complete redeployment of the model, for instance, not one single line of application code needs to be changed. And this is the real benefit. The framework of VISION* and the Rose model and the domain object model don't know anything about each other, which makes the solution easy to modify and deploy. But they're still interdependent, so Rose is crucial to what VISION* is and how it works."

The premise behind VISION* seems deceptively simple: create a system in which utilities and municipal organizations can store complex data and yet have multiple users both accessing and updating this material. To do that, an open database was needed. But to make the process truly effective, VISION* had to deal effectively with high volume data processing, long transactions, and incredibly complex data models.

VISION* uses Oracle as the underlying technology, which is vital when dealing with databases of this size. Customer databases are now approaching 100 gigabytes, and some are expected to be a terabyte by the end of the year. These are online transaction processing systems, not data warehouses, so it's a terabyte of data that must be accessed and updated concurrently by hundreds of individuals. In addition, the transactions are high volume in the sense that users have to hit a lot of rows in Oracle to get a screen full of data. For example, a map of San Francisco that shows property boundaries, roads, and the electric network might involve 10,000 table rows of information from the database. And when users want to update the information, typically dozens of rows and tables are involved. With large numbers of users concurrently updating vast numbers of tables, the overall transactional volume is immense.

The Lock is the Key

Another factor that places VISION* at the head of the AM/FM/GIS industry is its ability to handle long transactions that persist for weeks or months. A typical use would be a construction project that modified existing facilities and extended services into new areas. VISION* developers have recognized that the data management system has to be flexible in order to match the way people really work in an organization; protecting the data while still providing access as required.

For example, engineers on a project might need to put an exclusive lock on some facilities data, allowing other users to see it, but preventing them from changing it. Alternatively, they can apply a shared lock, in which case multiple users can create their own versions of the data. Users can also create new versions based on an existing version, as a sort of "design on design" collaborative effort. The locking strategy includes a number of configurable checks and balances to ensure that versions are not inadvertently overwritten and that the right version is ultimately committed to the permanent database.

This sharing of information is a real differentiator between VISION* and its competitors, who mostly work on a "check-in/check-out" system. In that format, data can be checked out of the system, but only the person working on that information can see it-all other individuals are blocked. "With VISION*, it's all there in the database," Zeiss explains. "If I want to see your stuff, I can. Depending on the work process, I may not be able to modify it. But we provide a transparent environment for all transactions. And the key thing is, we implement this functionality in Oracle, which nobody else in the business does."

Figure 2

VISION* not only keeps the data visible, it shows it in the manner appropriate for the individual user. According to Hill, "Because it's in Oracle, you can apply different symbology as you pull it out of the database. A field engineer wants to see a transformer with the in and out voltage and maybe the date of manufacture, the type of transformer, that kind of thing. But at the management level, they just need a spot on the map that shows the transformer location."

As Alex Wood, Director of Technology for Vertical Applications explains, "Our notion of developing a vertical application is to provide end users with a product that maps to their job function. It's a way to show end users that it is possible to bring these abstract bits of technology together in a way that reflects their job process." For example, mobile field crews can be provided with an application on a hand-held terminal. This lets them use pull-down menus and panels to record several dozen attributes of outdoor

equipment without writing a single word. In the design office, applications can automate routine calculations and processes so that when an engineer maps out a new cable, the system can provide a list of required materials and estimated construction cost.

The next challenge, complex data models, stems from the huge number of objects to be considered and the tremendous interconnectivity between elements of a single utility. The numbers can be intimidating. As Zeiss explains, "One of our large telecommunications customers, for example, has about 230 classes, or types of equipment." That means for this client, VISION* has to handle 230 classes from the data model, keeping track of each individual object and how it is connected to everything else. Another customer has a data model that represents 900 pages of documentation. "And," Zeiss adds, "there are engineers updating this stuff in real time. Now with mobile solutions, people out in the field are looking at what's actually in the ground and when they see something that's different from their data, they can access the information, enter the corrections, and update the central database."

Zeiss explains that part of the present challenge for VISION* is to stay ahead of the technology. "This year, the really hot item is domain object modeling with Rational Rose. It allows us to do enterprise data models and to actually generate the data maintenance application, and it keeps those two things tightly together. The traditional method was to do the data modeling and then do an object-oriented application development somewhere else. When you changed your data model, then the object model for the application also had to be changed. The nice thing with Rose is that both functions are tightly fit together."

"Because we use Rational Rose as a tool for modeling both the client and the server side," Brockwell adds, "we get immediate deployment and then a way to iterate with the industry-leading tool. So we iteratively model changes to the components and then deploy them, check them out, make changes again, and evolve to a complete solution. This is much better than trying to get it right the first time. How many projects have failed because of that kind of thinking? We believe that we have an approach that allows us to avoid those risks. And that's largely due to Rose."

The object rules technology that VISION* has developed is applied to actual objects from the customer's domain: poles and cables and transformers, for instance. VISION* provides the mapping between the logical object model and the actual implementation with the relational database. "In other words," Zeiss explains, "Rose is used to model the facilities, including their relationships with each other and methods of working with them. Our clients can push a button to generate the relational schema, then push another button to

actually generate the 'object rules' that drive the application development process. That's real software automation."

As part of the complete solution delivered by VISION*, clients are provided with the Rose model for reference and documentation. "Besides the benefits of code reuse," Zeiss continues, "Rose really helps to simplify complexity. We take an object, put it into Rational Rose, and all of a sudden you see something that wasn't there before. It's unambiguous; a clear representation of the system." "And," adds Fanjoy, "people who are business process experts rather than computer experts can easily see the models, understand them, and validate them."

The benefits that Rose brings to VISION* are not limited to technological rewards; they include those of partnering with the market-leading tool vendor. As Hill explains, "When we show Rose to prospective customers in the context of our product, they're flabbergasted in a very positive way. We hear words like 'stunning.' Some of our competition has their own set of tools that they've tried to make work. But Rose provides true object-oriented programming and our clients get the benefits of it. Rose has made a striking difference in our product in the marketplace. The Rose integration with VISION* means quicker time to implementation for our customers. That's very important."

Sense and Scaleability

Fanjoy concurs, "Without Rose, our value proposition would be quite different. This is a real strategic advantage for us." The VISION* team has taken core Rose business and technical strategies and made them an inherent part of an important solution in very IT-intensive markets. "And in doing that," he continues, "we can be an example to other application vendors that could and should be considering building their development and integration strategies around Rose. Rose should be of profound importance to the big ERP vendors. New application areas are emerging that have enormous complexity. There is a real need to manage complex data applications, simplify application design, and simplify system maintenance. It demands flexible tools so that the system can be customized over time. That's where Rose can help. And Rational Software is in a unique position, not just with Rose, but with its integrated tool strategy of potentially convincing other vendors to build this into their product. Rose is very much central to our strategy with VISION* on both a technical and a business level. It makes perfect sense for us."

It also makes perfect sense from the Rational side. Following a recent demo of VISION*, Rational Chief Scientist Grady Booch said, "The VISION* Solutions project is a wonderful example of how

Rational Rose technology can be used in innovative and powerful applications. The most interesting aspect is that Rose and the UML are being used to model both software objects and physical objects such as telephone poles and fiber optic cable. VISION* allows its customers to have object models of business processes, client/ server systems, and complex enterprise data models-all integrated, built, maintained, and managed in the same system. VISION* demonstrates the extensibility of the UML and Rose, making visual modeling development and maintenance dramatically easier for mission-critical applications."

David Sonnen, Senior Consultant with the International Data Corporation, has been watching VISION* for several years, and feels that its use of Rose is really breaking new ground. "VISION* has created a powerful business object modeling tool for the regulated sector and local governments," he points out, "and their approach could have significant payoffs for the IT community in general. It reduces a lot of the frustration that business people have traditionally had with the abstract nature of the modeling process. It has been very difficult to translate their business experience into the semantics of object-oriented design. Now VISION*'s business object model makes analysis and design a lot more manageable and useful. It gives business people a usable framework that they can modify to fit their unique processes. Coupled with Rose's requirements tracking and OO design and analysis capabilities, VISION*'s domain-specific business object model should help reduce cost and risk in enterprise information system projects. We believe that VISION*'s approach can move business object modeling to much broader commercial acceptance."

By allying themselves with market leaders such as Oracle and Rational, VISION* gains additional value in the marketplace. According to Zeiss, "This is a differentiator in our favor right now because we use the standard UML and we use the industry-standard tool, Rational Rose." Fanjoy adds "From a business perspective, we can leverage the branding, the awareness, and the third-party support and infrastructure that Rose has build around its business. We can leverage all of that for our customers. From a technical perspective we can leverage the functionality of Rose, and then with our focused R & D we can create value for our customers that is really quite profound."

So who are VISION*'s customers? Primarily large utility companies and municipalities, though VISION* has potential uses in areas far beyond their original marketplace, such as airports, fire departments, and government agencies. VISION* counts among their installed base telecommunications companies such as MCI, U S West, British Telecom, and Telstra (Australia), electric utilities such as New England Electric and FirstEnergy, and cities such as

Vancouver and Ottawa. VISION* customers are characterized as having the largest enterprise deployments in the AM/FM/GIS industry. Currently many customers have over 1000 user licenses, with many more expanding their use of VISION* every year.

But VISION*'s customers aren't the only ones with big plans. "From our point of view," Zeiss states, "as far as the future goes, the Rational full lifecycle is going to be our key methodology. Starting off with requirements and going all the way through delivery. Right now in using Rational Rose, we've already combined two things: one tool for doing data modeling and application development. The next thing will be to start getting into requirements, delivery, and deployment. We really want to use Rational from cradle to grave." As Wood puts it, "Rather than build our own modeling environment, we decided to leverage the best available product and, in the process, give a really strong value proposition to the customer. It's not just us saying 'we're the greatest,' it's a team of recognized best-of-breed vendors saying, "here's an integrated, comprehensive solution." And Rose is very much a part of that solution."

As explained by Hill, VISION*'s goal is simple: "we have a real passion for this business, and for seeing customers use our solution to dramatically improve their day-to-day operations." With a little help from Rational Rose and Oracle, this vision is truly a reality.

For more information about VISION* Solutions, please visit their web site at http://www.gis.shl.com

About the Author

Lisa Dornell is one of America's least known writers. In addition to her work as Features Editor for the Rose Architect, she writes fiction and poetry. She is also an AIDS activist and has been known to write marketing copy in her copious free time. She can be reached at lisad@rosearchitect.com

Back to Contents

Copyright © 1998 Rational Software and Miller Freeman, Inc., a United News & Media company.

Home

Premiere Issue Winter 1998/99 Spring 1999 Summer 1999 Search Archived Articles

About Rational Rose

About the UML

Iggy's owner is Brian Lyons, Chairman of Number Six Software.

Partner Perspective: Quantifying Quality in Your OO Models

And Doing Something About It!

by Brian Lyons

The metrics of the functional era just don't measure up anymore. Let's examine how modern object-oriented metrics can be used to improve your design by bringing to light areas of high complexity in your model. To do this, we'll discuss computing object-oriented complexity metrics on a Rose model to assess the quality of the design. We'll also suggest some concrete steps for improving the quality once issues are unearthed.

Choosing the Metrics

Function-oriented metrics sought to measure the size and complexity of systems made up of large algorithmic code units. Typically you considered the lines of code it took to implement an algorithm and the complexity based on the number of branches within it. One of the pitfalls of object-oriented development to be avoided is using the wrong metrics.

In object-oriented systems the complexity and size are not found within functions. They come from the set of collaborating objects. We need new ways to measure these modern systems.

For this discussion, we'll choose a small set of measurements from a growing volume of research in the area of object-oriented metrics. The metrics discussed herein are taken from sources noted in the bibliography.

In choosing the metrics to discuss, let's start with an academically sound approach. We'll use the Goal Question Metric (GQM) strategy proposed by Victor Basili of the University of Maryland2. (Heck, it had better be academically sound; he is a professor at my alma mater.) This strategy prescribed establishing a measurement plan by presenting ideas in a predefined format, along the lines of what

is being done today in the software patterns community.

The measurement plan is set up hierarchically. The three levels of the measurement plan are a conceptual goal, a set of operational questions associated with the goal, and a set of quantitative metrics associated with each question. First, start with an overall goal for the metrics plan. Next, devise a set of questions whose answers characterize the object of measurement with respect to the selected quality issue. Finally, propose a set of metrics that can quantitatively answer the questions. Some of the metrics chosen may support multiple questions. The hierarchy is shown in Figure 1.

Table 1

A more robust metrics plan is called for in an actual project setting, but this simple example will suffice for the purposes of this article.

The metrics being suggested here are seen in Table 2.

Assessing the Metrics

Tom DeMarco said "you can't control what you can't measure"4, well we are on our way; we are measuring. So let's see what we can learn from our results.

We can start by discussing thresholds and the issue of how high of a value is too high within our quantitative metrics results. Be warned, while the data on proposed object-oriented metrics is widely available, a set of prescriptive heuristics for interpreting the values will be hard to find.

In their OO metrics text, Lorenz and Kidd include the three class metrics described above. They do not specify a suggested threshold for class coupling, but they suggest that operation summation yield no more than 20 operations and that depth of inheritance not exceed six. The threshold for operation summation can be increased to 40 for user interface classes. The depth of inheritance threshold is only counted below the environment framework.

Those that propose any thresholds for acceptable values typically do so with significant caveats (e.g. in addition to the caveats above, Lorenz and Kidd often propose one threshold for C++ and another for Smalltalk). These caveats are necessary. We must consider the metrics in a context.

In truth, there can be no universal thresholds. You must determine the values that are appropriate for your own particular solution domain. Solution domain here refers to your language, platform, architecture, and the mechanisms you have in place. For depth of inheritance, the boundary classes that are within your graphical user interface framework might have higher values than your entity classes. Server-side packages might be expected to have more dependencies than client-side packages. Embrace the diversity!

Your particular thresholds will mature over time. After an iteration or two of gathering these object-oriented metrics (along with traditional error count and resource utilization metrics), you can fine-tune the thresholds for your own implementation domain.

There are no "right" numbers out there, so then what can we do with metrics today? We can leverage immediate value by closely monitoring the classes and packages that represent the most severe values in our models. Even though we don't have an exact idea of how high is too high; we can keep an eye on the modeling elements that represent the highest values we have.

Armed with a metrics report, high-risk areas of the design can be located. Review and testing resources can be allocated to the most complex classes and packages. Not to say that all parts of the system do not need an appropriate level of review and test, but knowing which are most complex can give you an idea of where to spend a little extra time.

Responding to the Metrics

While Tom DeMarco made a good point, to paraphrase Deming, measures alone do not necessarily lead to improvement5. Let's see what we can do about our results.

As an exercise, let's walk through our key class metrics and suggest some design solutions to consider when the values get high. These are just a few ideas to get you thinking about metrics as a gateway to higher quality software. Get yourself a book that describes quality designs such as design heuristics text by Riel6. Add to that a couple of pattern texts such as the Gamma, et al text7, the Buschmann, et al text , or one of the Pattern Languages of Program Design books.

Class Coupling

There are two primary issues that can cause high class coupling. The class might be doing too much, or the performance of its

responsibilities might require too many collaborators.

Sometimes, through a number of iterations spent refining your object model, a class can become the bloated KitchenSink or Swiss Army class. In these circumstances, the class should be reexamined and its responsibilities distributed amongst a family of classes each taking on some cohesive subset of the behavior.

This activity of splitting up a class is a natural part of moving from an analysis model to a design model. The analysis model might have instances of a particular class participating in the realization of numerous use cases. A shifting focus to design issues leads us to consider how this will really be implemented in the actual software system. One boundary class becomes many, entities are broken up, and a family of simpler classes replaces a heavyweight controller.

Then there are occasions in which the issue is not that the class takes on too much responsibility. Instead, certain underlying mechanisms required of the class take a high toll in coupling. Perhaps it takes a handful of classes to send each simple transaction to your legacy system. Perhaps your persistence library requires a dozen classes to retrieve one object. Perhaps this happened due to breaking up some classes as suggested above ...

Internal to the collaboration, it is often appropriate to have a family of classes work together to perform some work. But this can put undue burden on the client classes. We can choose a design pattern that gives us the best of both worlds: the facade. The facade pattern "defines a higher-level interface that makes the subsystem easier to use"8. A new facade class can be created to sit in front of the set of classes working together to provide the service.

Depth of Inheritance

Looking at inheritance in the most simplified way, there are two key benefits. The author of the child class gets the benefit of some amount of reusable code. The clients of the parent class get the benefit of using the new child class without any extra effort or concern. The first benefit described here is a nice convenience; the latter is of profound importance and the key to writing powerful OO applications.

In examining your metrics results, you might find that a branch or two of the inheritance lattice has become a little lanky. Maybe one clever designer found four classes in the inheritance tree between Employee and Person. Maybe another designer always wants to start with an existing business class before adding and overriding

behavior. Take some time to review the use of inheritance and judge whether it is for convenience or it is fully leveraging polymorphism.

If you examine a particular usage of inheritance and find that there are no cases of a client needing to use the polymorphic nature of the relationship, get rid of the inheritance. Inheritance (sometimes referred to as white-box reuse) introduces significant complexity. If you are only using inheritance to get some code for free, replace it with composition. Composition (sometimes referred to as black-box reuse) introduces less complexity. Composition is the strongest form of aggregation. The composite "part" is constructed and destroyed along with the class that represents the "whole". With this tactic you replace the inheritance of a base class X with an aggregation relationship to an instance of X. Then, locate any operations provided by class X that you want clients to be able to access. For each of these operations, add an operation to your class that simply invokes the operation in the composite X. You now have all the same capabilities with respect to shared code, just no polymorphism. And your design is less complex.

Operation Summation

When working to reduce a high operation summation number, you must attack it from two directions. You must consider whether inheritance is being overused and whether the class is taking on too much responsibility. These issues coincide with the design issues handled above.

If the cause of a high operation summation count is the number of operations inherited, examine those operations. If a number of those operations are not really required by this class or its clients, reconsider inheritance. The issues with examining the need polymorphism come into play as described above.

If the class is taking on too much responsibility-or even if a number of its ancestors are each taking on a little bit of extra responsibility-consider the breakup strategy described above for dealing with a high class coupling measure.

A higher number of simpler classes is one part of a higher quality OO model.

Automating the Metrics

No metrics plan is feasible if it requires heavy manual computation. This is particularly true in the face of an iterative and incremental development process such as the Rational Unified Process. Unlike the days of the waterfall process, metrics must be gathered at

regular intervals.

Let's talk about automating our metrics with Rational Rose. Since extending Rational Rose is covered elsewhere in this publication, we'll just hit the basics.

The Rose Extensibility Interface allows us to walk the model, examining its contents. All the metrics above can be computed, albeit at various degrees of difficulty, by walking the classes and packages and examining their relationships and contents. This can be done either from within Rose via scripting or from an external application that communicates with Rose.

Check the Rose Architect web site for scripts that support these metrics, courtesy of Number Six (this is a script download).

If you want a full solution to your metrics needs, check out Metrics ONE, a Rose Add-In tool that computes 40 object-oriented metrics on your model and writes the results to an excel spreadsheet for easy analysis. To download a demo of this tool, visit http://www.numbersix.com/metricsone/.

Summary

Metrics represent a valuable tool in your arsenal of quality software development techniques. Not just any metrics though, object-oriented metrics. Pick a set of metrics that will allow you to assess the quality of your model. Even without a discrete set of threshold values, you can get started. The metrics will point out areas of highest risk in your model. Automate the collection of metrics data and use a set of heuristics and patterns to improve your model.

Inside your current object model is a less complex model trying to get out. Object-oriented metrics provide the key.

About the Author

Despite being characterized by Grady Booch as a madman, Brian spends his days working along with other Number Six consultants leading customers to success. He is the co-founder of Number Six Software, a training and mentoring company specializing in object-oriented technology insertion. Mentor, trainer, consultant, madman ... you decide.

Footnotes

1. Webster, Bruce F., Pitfalls of Object-Oriented Development,

1995, M&T Books, (ISBN: 1558513973).

2. Basili, Victor with Gianluigi Caldiera and Dieter H. Rombach, The Goal Question Metric Paradigm, Encyclopedia of Software Engineering - 2 Volume Set, 1994, John Wiley & Sons, Inc. (available at ftp://ftp.cs.umd.edu/pub/sel/papers/gqm.ps.Z)

3. Martin, Robert C., Designing Object-Oriented C++ Applications Using The Booch Method, 1995, Prentice-Hall, (ISBN: 0132038374)

4. DeMarco, Tom, Controlling Software Projects, 1982, Prentice-Hall, (ISBN: 0131717111)

5. Deming, W. Edwards, Out of the Crisis, 1986, MIT Center For Advanced Engineering Study, (ISBN: 0911379010)

6. Riel, Arthur J., Object-Oriented Design Heuristics, 1996, Addison-Wesley, (ISBN: 020163385X)

7. Buschmann, Frank, et al, Pattern-Oriented Software Architecture, 1996, Wiley Press, (ISBN: 0471958697)

8. Gamma, Erich, et al, Design Patterns, 1995, Addison Wesley, (ISBN: 0201633612)

Back to Contents

Copyright © 1998 Rational Software and Miller Freeman, Inc., a United News & Media company.

Home

Premiere Issue Winter 1998/99 Spring 1999 Summer 1999 Search Archived Articles

About Rational Rose

About the UML

Lisa Dornell is Features Editor of Rose Architect.

Death to theWebworm

by Lisa Dornell

Chances are when you're in the produce section of your local supermarket, you're not thinking about Webworm. And you probably spend very little time worrying about Late Blight as well. But that's ok, because American Cyanamid Company is thinking about it for us. Also on the minds of American Cyanamid's scientists are the dangers posed by confusing software, inefficient computer systems, and the kinds of bugs you can't kill with any dose of pesticide.

"Webworm" is not geek-speak for some annoying loser who spams you on the Net. The Webworm (Order Lepidoptera, Family Acrolophidea, for those of you who aspire to win at Jeopardy) is a serious pest that has been known to destroy up to 80% of an individual field's crop of corn, beets, sorghum or rye. Late Blight, is a fungal disease which made world history back in 1845 when it completely wiped out Ireland's potato crop and led to the death by starvation of an estimated 1 million people. Late Blight is an entirely different threat than that posed by the Webworm (or the Wireworm, the Seedcorn Beetle and a veritable host of other plagues) but each can result in ruin for a farmer, and a resulting loss in the world's food production. Agricultural threats from insects and plant diseases are not something that keeps the majority of the world awake at night. But it is of vital importance to the world's food supply that crops are protected from these potential disasters. Luckily for farmers who depend upon a healthy crop for their livelihood, and for those of us who depend upon agriculture for a portion of our dietary needs, there is American Cyanamid, which provides solutions for a wide range of agricultural problems.

Figure 1

Founded in 1907, American Cyanamid is a subsidiary of American

Home Products Corporation, a world leader in pharmaceutical and health care products. The American Cyanamid Agricultural Products Group is the eighth largest crop protection chemical company in the world, and the third largest in the United States; developing, manufacturing and marketing herbicides, insecticides and fungicides, to protect the world's food supply. It has been estimated that the world's population will grow to eight billion people by the year 2025, making efficient agricultural production a matter of global importance. Scientists at the American Cyanamid Agricultural Research Center (CARC) in New Jersey, are working now to develop the new products required to take agriculture into the 21st century, by testing chemical compounds for properties suitable as pesticide products.

The V-Team

When a redesign of the CARC data capture software was needed, they turned for help to Visient Corporation. This Parsippany, New Jersey based company of software developers and consultants is a Rational RoseLink Partner and a provider of innovative solutions to a variety of industries. From the start, Visient realized there were two key factors to be considered in designing this system. First, they knew that end-user satisfaction would be a critical factor in the success of the project; the entomologists, plant pathologists, chemists and biologists working to discover new compounds would have to be consulted at every step of the way, to ensure that all their requirements were being met. Secondly, this system not only had to work efficiently: it had to work efficiently for two divisions.

The end product had to be an effective data collection and compound screening process for two separate CARC groups: the Fungicide group and the Insecticide group. "It started out as two separate projects." explains Dr. Cynthia Gagne, Group Leader of Discovery Applications at CARC, "We were asked to make enhancements to a program the scientists were using to collect data for the experiments they ran. And then another group had similar problems and I was able to talk them into shifting their time requirements around so that we could make this a joint project. The original goal was to modify the programs so that they could do business in a more logical, efficient way. And that remained the goal, except we replaced the words "modify the programs" with "write two new programs using new technology." To ensure the end-users were satisfied, and to establish the requirements of both divisions, Visient put together a unique group. In addition to Dr. Gagne and the Visient developers, two developers from within American Cyanamid were part of the development team, as well as two CARC scientists.

Figure 2

This proved to be a crucial part of the design process because, "the whole system was to collect and analyze the data that these scientists receive when they are screening chemicals," continues Yao-Jung Yang, Senior Systems Architect at Visient, and Technical Team Leader for the American Cyanamid project. "So having them there was a big help."

Figure 3

The joint Visient/American Cyanamid team developed this system using Rational Rose for PowerBuilder. According to Yang, "Rose was the main tool I used to do high level and detailed design. With the help of Rose I could very easily express my ideas using various design patterns, and to communicate the architectural design to the rest of the team." Each group's scientific representative was included from the beginning. "We did use case analysis," explains Yost, "that was one of the first steps we did to capture requirements, in the use case technique. And every single use case analysis session that the team had involved both of these scientists. So that was an excellent way of making sure we were getting it right. We had to satisfy both groups, so it was very important to have both groups represented in these requirements analysis sessions. And then they went on to take the use case scenarios and from them, build test cases. And that was really the responsibility of the scientists, to define what the test cases were for the project." Then the scientists would hand these test cases back to the developers prior to the developers giving the scientists an incremental release. In that way, the developers could examine the test cases and know that each incremental release would pass the requirements for that particular release version.

Agricultural Groups Use Rose to Hybrid Their System

Additionally, Rose was invaluable in handling the complexities involved in dealing with the individual requirements of each system. "Because I used to be one of the people who ran experiments in the insecticide world, " Dr. Gagne states, "I could see some similarities between the two groups, but I could also appreciate the differences, the complexities, and the special components of each. The goal has been to capitalize on those components that are generic and yet still allow the customization that is necessary for them to do their specific experiments." Yang explains, "When I was first speaking with the user representatives, they expressed their desire to have a new system which would be universal yet reconfigurable to their specific needs. That was quite a challenge. We had to think in terms of the two groups at the same time and try to maximize the reusability of the components I was designing and building. Rose helped." Yost adds, "We would build, in Rose, scenario diagrams for each use case. Basically we

took the use case scenarios and built interaction diagrams, kind of identifying the objects. And then from there we took the objects and went to classes, methods, operations, you know, we followed the whole process. And that was all done in Rose. We were able to create a very interesting model." Through modeling and the ability to restructure the architecture of this system, the team was able to take advantage of the system's universal qualities, while allowing for extensibility for individual needs. Furthermore, should CARC's Herbicide group wish to utilize the same system, adding their individual requirements would be a relatively simple matter. According to Yost, "We developed an architecture that allows the system to accommodate many types of changes. And Rose was instrumental in the process of creating that architecture."

The basic outcome of the project was to streamline the compound screening process, which is at the heart of CARC's research efforts. Yost continues "The idea is that if you screen 10,000 compounds per year, you might get 1 new product every 3 years out of the other end of the process. But if you refine the screening process, you can examine, say, 100,000 compounds per year. And that's going right to the bottom line." With the system having been in place since August of 1997, Dr. Gagne reports that the people using the system are "absolutely satisfied. They definitely consider it a very big success. It saves them time. They've found they can do more than what they thought, so now they're using it in more areas than they expected. I consider that testimony a true sign of success."

For more information on Visient Corporation, please call 973-455-1800 or visit their website at http://www.visient.com.

Back to Contents

Copyright © 1998 Rational Software and Miller Freeman, Inc., a United News & Media company.

Home

Premiere Issue Winter 1998/99 Spring 1999 Summer 1999 Search Archived Articles

About Rational Rose

About the UML

Optimizing Rose 98 to Support Use Case Driven Object Modeling

by Doug Rosenberg and Kendall Scott

INTRODUCTION

There are many styles of doing UML modeling, but one of the more popular and more successful approaches involves driving the object modeling process by exploring the use cases (usage scenarios) of the system being modeled. ICONIX has been teaching use-case-driven object modeling since about 1993, shortly after the pioneering book on the topic by Ivar Jacobson. More recently, we've been leveraging the extensibility mechanisms within Rose98 to provide better support for a use case driven approach.

This article will take you through the most important elements of a use case driven UML model, and introduce you to a variety of tips and tricks that we've developed as we've taught UML modeling workshops with Rose.

There are a number of UML diagramming elements, but when following a use case driven style, five of them have proven to be the most important. While we're not suggesting the other elements are not important, we'll focus mainly on the following elements within this article:

1) Packages, which are used to organize your UML models.

2) Class diagrams, which form the static portion of your UML object model.

3) Use Case Diagrams, which are used to organize the use cases within a package.

4) Robustness Analysis diagrams, for which you will need to use the Objectory stereotypes

5) Sequence Diagrams, which form the core of your UML dynamic object model.

We'll be explaining these different elements of a UML model, how they relate to each other, and how they fit together within Rose.

Organize your models into packages

Packages, represented by tabbed folder icons within the Rose browser, and on the use case diagramming palette, are used as containers for other UML modeling elements. Packages can contain

both use cases and classes. In a use-case driven process, both robustness analysis diagrams and sequence diagrams are done for each use case, and are organized in this manner in the Rose broswer.

Rose allows import and export of packages. This becomes especially significant when working in a multi-user, configuration controlled environment. The package becomes the fundamental unit of control; that is, check-in and check-out are done on a package by package basis. Rose provides two default packages at the high level (Use case view and Logical view), but it's often desirable to group a set of related use cases and the classes which they are closely related to within a single package inside the use case view. Keep in mind that you can't import and export the top level packages such as Logical View or Use Case View, so it's a good idea to keep your diagrams, classes, and use cases in subpackages. This organization facilitates partitioning of work across a team of developers.

Build a model of the conceptual objects in your problem domain

Generally, you'll start your UML static modeling efforts with what's called a domain model, which contains the conceptual objects from the problem domain you're trying to address, and then evolve this domain model into a detailed static class model, which you can generate code from.

Classes are the basic building blocks of a UML design. They are the fundamental organizing units for software, grouping together a set of data attributes with the operations that access them. There are many details about a class that are captured using the class specification dialog within Rose. These include attributes, operations, and other descriptive information about a class, as well as information needed during code generation. Later in this article, you'll learn how you can tailor the information in the specification dialog using custom properties.

Classes are linked by associations, and there are a number of these to choose from, including generalization (a superclass/subclass relationship used to describe different kinds of objects), aggregation (used to describe complex objects that are broken into piece parts), and link classes (which are used to capture properties that belong to the association between two classes rather than to either of the classes themselves).

Keep focused on what the users are doing on the screen

If you're driving your UML modeling effort from use cases, that means you're breaking your system apart according to the ways that the users of the system are interacting with it, and using this this breakdown to organize your modeling efforts. Details about the objects within your system are uncovered by exploring the use cases...first in narrative text, then on robustness analysis diagrams using the Objectory stereotypes, and finally in great detail on sequence diagrams. The associations between a group of related use cases are shown on a use case diagram.

There's a certain style of writing use cases that works very effectively for this kind of development, which we've covered in depth in our process tutorials. Briefly, this involves writing the narrative text of the use cases in active voice, driven from the point of view of the user of the system, and working inwards from the user interface to uncover the functionaity required for a given usage scenario, and ultimately the objects that are needed to provide that functionality. Unfortunately, much confusion exists about the right and wrong ways to write use cases, and a lack of understanding in this area is a common cause of failure and inefficiency when doing modeling.

There is a little known feature of Rose that allows you to link pictures of the screens (perhaps from a prototype) directly to the use cases within your Rose model. We've found this to be a very useful technique for keeping your use case modeling efforts focused on user interactions and system responses.

Don't skip preliminary design

Robustness Analysis diagrams, part of the Objectory process, serve a number of useful purposes in a use case driven modeling effort. Robustness analysis involves working through the text of a use case, and taking a preliminary peek at how you might design some software to implement a given use case,

using the objects you've discovered up to this point. Obviously one of the main purposes of this activity is to discover when you don't have all the objects you need, and then add them to your class diagram. While you're exploring possible designs, its useful to classify objects into one of the three stereotypes (boundary, control, entity) provided.

The robustness model provides a bridge between the "analysis level" view provided by the text of the use case and the "detailed design" view shown on a sequence diagram. Since it's very difficult to jump from analysis directly to detailed design, it's hard to do modeling successfully without this step.

In order to do robustness analysis, you'll need to extend Rose 98 with the Objectory Add-In from Rational, which contains everything you need to quickly install and make use of the Objectory stereotypes, which are a key element of Rational's Objectory process. Once you've installed the Add-In, you can easily add these stereotypes for boundary, control, and entity objects to Rose, to extend the drawing palette within Rose with the icons for these stereotypes. This will be extremely helpful to your UML modeing efforts.

A robustness diagram provides a graphical view that matches the narrative text of a use case. The use case is described in terms of boundary objects (these are often GUI elements, although they don't have to be), control objects, and entity objects.

Drawing the robustness diagram for a use case provides a visual completeness check that shows that the entire use case has been accounted for. It also serves to enforce the "active voice" style that is most effective when writing use cases.

Making the transition from preliminary design to detailed design

Sequence diagrams show a detailed description of the runtime behavior of a collaborating set of objects. This view show all objects that participate in the scenario, and the messages that are passed between them. Having taught many UML training classes, I can assure you that one of the most common places for people to get stuck in modeling is when they're trying to get a sequence diagram started. If you've followed the steps we've shown you, first writing your use cases correctly, and then drawing the robustness diagram for the use case, you'll find that there are three easy steps to get started.

Step 1) copy/paste narrative text from the use case Step 2) drag actors and boundary objects from the rose browser onto your sequence diagram Step 3) drag entity objects from the robustness models onto your sequence diagram

Once you've done these three simple steps, you're off to a good start on your sequence diagram. You've still got to go through the hard work of deciding which messages should go to which objects, but at least you're started.

By using RoseScript, you can automate the process of getting a sequence diagram started from a robustness analysis diagram. The following script, from the "Rose 98 for Power Users" multimedia tutorial CD-ROM, creates a new sequence diagram and automatically populates it with selected actors, boundary objects, and entity objects from a robustness diagram:

Update your classes with operations as you draw the sequence diagrams

In object-oriented programming languages, operations belonging to classes are invoked by passing messages between objects as the program runs. This message passing is shown on the sequence diagram, and deciding where to draw the message arrows is the "hard part" of drawing the sequence diagram (now that we've automated the process of getting it started).

As you are drawing the message arrows between objects, be sure to take advantage of another feature of Rose, which allows you to add operations to the classes in the static model directly from the sequence diagram. This is accomplished by simply right-clicking the mouse on the arrow on the sequence diagram. Make sure you don't just type the message name on the arrow after you draw it as this does not update the static model (class diagram) -- you MUST right-click near the arrowhead on the message arrow and either pick an operation from the pop-up menu or select "New Operation" in order for this to work. When you add a new operation, you'll have to right-click again in order to see the operation name on the message arrow.

What you're really doing when you do this is driving the design of your classes from the sequence diagram, which is simply a refinement of the use case. This is what use-case-driven object modeling is all about.

Measure your progress

As you proceed through use case driven object modeling on your project, you're going to want to easily be able to get an idea of how much progress your project team is making in working through the use cases. The following code segment shows how easy it is to leverage Rose's OLE Automation capabilities to export the names of use cases within a Rose model, along with information about whether robustness and sequence diagrams exist for that use case into a Microsoft Excel spreadsheet. When sequence diagrams have been drawn for every use case, and the message arrows labeled with operations from classes in the static model, we're getting very close to being able to generate code, so this is a very useful "management window" into the project.

Note that Rose can function as both an OLE server and an OLE client. This means that data from your Rose model can be output into productivity tools such as Word and Excel, or imported from those or other OLE compliant applications, and that the data transfers can be controlled either from RoseScript or from Visual Basic scripts running inside other OLE clients.

Verify requirements traceability across use cases and classes

It's important to be able to verify that the system we're modeling will satisfy it's requirements. We can extend Rose to support this capability by using custom property files.

Properties define data that is stored within elements of a Rose model. It's possible to change the schema definition of a model, either by script, or by using a custom property file. These property file

have a .pty extension. Within the specification dialog, groups of properties appear on "Tools", which are the tabbed "pages" within the dialog. Properties are essentially "name-value pairs" which can appear and be edited when the tabs are clicked. Both visible and invisible properties can be accessed from your scripts.

The following is an example of a custom property called Requirements, that we've added to use cases. The complete property file also adds the Requirements property tab to the Class specification dialog. This allows us to write scripts that verify that requirements are satisfied in both the static and dynamic parts of the model.

SUMMARY AND ADDITIONAL RESOURCES

In this article, we've introduced you to a number of useful features that are built into Rose, as it comes out of the box, that can directly support a use case driven approach to UML modeling. We've also tried to provide useful guidance on some strategies for making the most effective use of the product, including a number of tips and tricks that we've found make Rose work better. At the same time, we've given you an introduction to several extensibility mechanisms which allow you to tailor Rose to your environment and to the use case driven modeling style.

Over the years, we've learned that lots of folks think that use case driven object modeling is a good idea, for some obvious reasons, but that many people don't quite understand all the details of how to do it. We've been working for several years to provide this information, in a variety of different ways. These include:

Book: Use Case Driven Object Modeling with UML, by Doug Rosenberg and Kendall Scott, soon available from Addison Wesley.

CD-ROMs: http://www.iconixsw.com/CDcourses.html Rose 98 for Power Users, Mastering UML with Rational Rose, A Unified Object Modeling Approach

On-Site Training: http://www.iconixsw.com/UMLTraining.html We've been teaching use case driven object modeling since 1993. When you need to get your project team moving forward with UML modeling and Rose as quickly as possible, we're ready.

Back to Contents

Copyright © 1998 Rational Software and Miller Freeman, Inc., a United News & Media company.

Home

Premiere Issue Winter 1998/99 Spring 1999 Summer 1999 Search Archived Articles

About Rational Rose

About the UML

Welcome to the Premiere Issue of Rose Architect

by Adam Frankl

Adam Frankl is Publisher of Rose Architect and former Director of Marketing for Rational Rose. Prior to his stint at Rational he was a software engineer at the Lockheed Skunkworks, a systems analyst at the RAND Corporation, and an infantry captain in the U.S. Army.

At the time of this writing, Rational has just shipped the 100,000th copy of Rational Rose, the world's leading visual modeling tool. The 90th software vendor has joined the RoseLink Partner Program to develop Rose Add-Ins. Over 20 authors have written books on modeling with the UML and Rose. Over 200,000 people have watched the Inside the UML multimedia CD, and over 600,000 people have visited the UML Resource Center web site. (http://www.rational.com/uml)

Now more than ever software developers are turning to visual modeling to define and communicate software architecture, and to:

● Accelerate development, by improving communication among team members

● Improve quality, by mapping business processes to software architecture, and

● Increase visibility and predictability, by making critical design decisions explicit visually.

This growing community needs an authoritative source of the latest information on visual modeling. To meet this need Rational Software, the creator of the UML, and Miller Freeman, publishers of Software

Development and Microsoft Systems Journal, have teamed up to publish the first quarterly magazine dedicated to visual modeling with Rational Rose and the UML.

The Rose Architect's mission is to help ensure the success of developers using Rational Rose to communicate the architecture of software systems. To accomplish this, we will feature the latest research from the creators of the UML, Grady Booch, Ivar

Jacobson, and Jim Rumbaugh, who all sit on our advisory board. We will publish case studies of real-world software projects. Rational developers will examine technology directions for Rose and the latest news on the UML. We will also review RoseLink Partner products and include advice columns for both the novice and power Rose user.

I am very proud to introduce the Rose Architect editorial team. Terry Quatrani, Editor-in-Chief, is the author of Visual Modeling with Rational Rose and UML, the #1 best selling book on the UML, and is a popular speaker at software industry conferences. Laura Mullins, Managing Editor, has been with the Rose team since before it was called Rose, and is the producer of the hugely successful Inside the UML multimedia CD-ROM. Lisa Dornell, Features Editor, is an award winning writer with over 18 years experience writing and editing magazines. Veronica Herreria, Web Editor, is the creator of the critically acclaimed UML Resource Center web site. Naveena Bereny, Technical Editor, has been on the Rose team helping Rose users be successful for over 4 years.

Enjoy!

Adam Frankl, Publisher

Back to Contents

Copyright © 1998 Rational Software and Miller Freeman, Inc., a United News & Media company.

Home

Premiere Issue Winter 1998/99 Spring 1999 Summer 1999 Search Archived Articles

About Rational Rose

About the UML

Terry Quatrani is the author of the best selling book Visual Modeling with Rational Rose and UML.

Letters to the Editor/Ask the Expert

by Terry Quatrani

My name is Terry Quatrani and I am the Editor-in-Chief of this exciting new magazine. The Rose Architect is YOUR magazine, which means I want to hear from you. Each issue, I will have two regular columns-Letters to the Editor and Ask the Experts. The Letters to the Editor section is your chance to tell us what you like and what you don't like. You can also use this column to tell us what you would like to see in future issues of the magazine. The Ask the Experts page is where you can get your Rose questions answered by the experts-the people who develop and market Rational Rose, the world's leading visual modeling tool. If you have a question for our experts, or comments for our editorial page, please send them to me at tq@rosearchitect.com.

Since I don't have any letters or questions for our first issue, I thought I would take this chance to tell you a little about myself. I started my professional career many years ago teaching 8th grade math. I lasted 3 years until I decided that there had to be an easier way to make a living. I then went to General Electric Company where they said "Degree in Math? You're a programmer". I spent the next 6 years doing some heavy duty Mathematical programming in FORTRAN before moving into the R&D area where I learned all about UNIX and C. In 1988, I had my first introduction to OO. I was in the System Integration department at GE and had a customer doing an Object-Oriented Requirements Specification. After this experience I was hooked. OO seemed to be the way to go. In 1991, I was one of the founding members of the GE Advanced Concepts Center. I spent the next two years doing training and consulting using the OMT methodology. In 1993, I left GE and joined Rational so I moved from OMT to Booch and then to UML. Today, Editor-in-Chief is just one of the hats that I wear at Rational. My other hat is as the Rose Evangelist-this means that I preach the visual modeling gospel according to Grady, Jim, and

Ivar. My husband sums up this job nicely. He says "my wife has finally found a job that she does extremely well-she talks!"

As Editor-in-Chief I invite your feedback on this premiere issue, and ask for your help in ensuring that future issues of the Rose Architect are informative, entertaining, and useful to you. Please send me your comments and questions-I look forward to hearing from you.

Back to Contents

Copyright © 1998 Rational Software and Miller Freeman, Inc., a United News & Media company.

Home

Premiere Issue Winter 1998/99 Spring 1999 Summer 1999 Search Archived Articles

About Rational Rose

About the UML

Grady Booch is Chief Scientist at Rational Software Corporation.

Rational Rose: Past, Present, and Future

by Grady Booch

Great software doesn't just happen; it's engineered to be that way. Great software doesn't just spring up in a vacuum either; rather, it must be evolved continuously in order to incorporate feedback from its users and adapt to changing technology.

The Present

Rational Rose is a great piece of software. To date, Rational has shipped over 100,000 copies of Rose. Over 90 partners are now part of our RoseLink program, and each is working to build upon Rose, integrating it with other tools and adding new functionality. Perhaps what sets Rose apart is that it's not so much just a modeling tool, it's a developer's tool that helps a team to manage the complexity of software development and to tie together all of the disparate artifacts generated and manipulated by the team.

You'll find Rose being used in every corner of the software industry, including telecommunications, management information systems, transportation systems, medical electronics, command and control systems, computer gaming, and financial services. From systems being built by individuals to systems staffed by hundreds of developers. You'll even find Rose being used to develop hardware systems and to model businesses. You'll find Rose all over the world as well. Rational's global distribution network has brought Rose to every major center of development in the world. Rose is not only being used by mainstream developers, but it's being used in many places in academia as well, as a tool that introduces the importance of modeling to a whole new generation of developers.

The Past

Rose didn't just happen and it didn't just spring up overnight. To understand how Rose came to be, let me take you on an archeological dig that uncovers Rose's past.

Rose had its beginnings in an underground project at Rational that started in late 1987, way before objects were cool. That first project, called by the engineer-driven name OODW (Object-Oriented Developer's Workbench) was an exploration of the visualization of a software's architecture using the then-evolving Booch notation. OODW was prototyped on a combination of a Macintosh (serving as the GUI client, written in ObjectPascal against the MacApp framework) and Rational's R1000 (serving as the domain server, written in Ada). OODW beget a product called Ada Illustrator, which was provided as a means of visualizing Ada systems. In late 1989, Rational developed a product called the Design Facility, which was focused on helping our larger customers manage the design artifacts of their projects. Although mainly textually based, it did have links to Ada Illustrator.

In 1990, the first edition of my book Object-Oriented Design with Applications was published, followed shortly thereafter by Jim Rumbaugh's Object-Oriented Modeling and Design and Ivar Jacobson's Object-Oriented Software Engineering. The floodgates of object-oriented modeling had opened, soon to be followed by the emergence of some 50 identifiable object-oriented development methods.

In the summer of 1990, Rational made the decision to commit resources to develop OODE (Object-Oriented Development Environment-we weren't especially good at coming up with approachable names for this product at this time, as you can see). We did some early joint exploration with IBM, which manifested itself in a fairly complete prototype of the product, written entirely in Smalltalk and supporting the Booch notation.

In the fall of 1990, we began to assemble a full development team. It was our assessment that Smalltalk was not the right long term solution that would scale, and so we undertook Rational's first C++ project (around the time when C++ was really just maturing), evolving and porting the Smalltalk system to Unix. Around that time, Rose was given its current, much nicer name, replacing the less friendly OODE.

The initial Rose team hit critical mass in early 1991, and a new business unit was formed around the team. Rose 1.0 shipped in August of 1992, and at that year's OOPSLA, held in Vancouver, Rose had its official coming-out party with the shipping of Rose 1.1.

Rose 1.1 had its limitations. It supported only a subset of the Booch notation, and it was Unix only at a time when the Windows platform was just starting to see some serious momentum. Therefore, in the fall of 1992, Rational began discussions with Palladio Software, which at the time had developed a product called Object System/Designer that was Windows only and supported the Booch notation. Object System/ Designer was written using C++/Views. Rational licensed that product and began selling Object System/ Designer under our own brand, Rose 1.0.7, in early 1993. This was our first Windows solution, and won the Jolt award that year, the first of many awards for the Rose product line.

In the fall of 1993, Rational delivered Rose 1.5 for Unix (our move to a multiple platform code base using Wind/U by Bristol). Joint development by Rational and Palladio began in 1993, updating the product to the second edition of Object-Oriented Analysis and Design and supporting our first form of C++ round trip engineering. The result of the effort, Rose 2.0, shipped in mid 1994 and was basically a fusion of the Rational Unix product and Palladio's Windows product. Our joint development with Palladio ultimately resulted in our acquisition of the company in January 1995. In mid 1995 we shipped Rose 2.5 with new notational support.

By this time, the method wars were reaching critical mass. Three methods had emerged as being the most widely used: the Booch method, OMT, and OOSE. In the fall of 1994, Rational made the strategic move to end the method wars: we hired Jim Rumbaugh, and he and I set out on a quest to unify our two methods. In the fall of 1995, we produced the first version of our work, the Unified Method 0.8, which we released at OOPSLA 95. At the same event, we announced Rational's acquisition of Objectory, and so Ivar Jacobson joined our merry band, working together to unify the three leading methods.

A direct result of Jim Rumbaugh joining the team was Rose 3.0, which shipped in early 1996, introducing support for OMT in addition to Booch. Rose 3.0 won another Jolt award that year. Rose 3.0 also introduced our support for additional languages, such as Visual Basic, which could also benefit from an architectural design.

UML 0.9 was developed around the same time, providing the union of the Booch, OMT, and OOSE methods. In late 1996 we announced our alliance with Microsoft, a move that would later have many important implications. Rose 4.0 shipped in mid 1997, and began supporting the UML, which was delivered to the OMG in January of that year. By this time, the UML team had grown from Jim, Ivar, and myself to include IBM, Microsoft, HP, Oracle, TI, ObjecTime, MCI Systemhouse, I-Logix, ICON Computing, Platinum, Takson, and Unisys. Rose 4.0 grew our development team to

include a group in Kista, Sweden. By that time, a truly distributed team was developing Rose: Santa Clara, Oregon, Milwaukee, Philadelphia, and Kista. Rose 4.0 took advantage of the techniques developed at Ivar's company, Objectory, added support for use cases, and included many variants for C++, Visual Basic, Java, Powerbuilder, and Smalltalk. Rose 4.0 introduced our first scripting language and an API, thus beginning the rudiments of Rose Add-In technology.

In early 1997, we also shipped Microsoft Visual Modeler; essentially an entry-level subset of Rose distributed by Microsoft to support Visual Studio. The inclusion of MSVM into Visual Studio technology was striking: it signaled the importance to Microsoft of modeling for the enterprise. Modeling had entered the mainstream, and the UML was now being exposed to hundreds of thousands of developers.

Figure 1

In November 1997, the OMG accepted the UML 1.1 as a standard, a milestone in the growing maturity of the object-oriented marketplace. In 1998, the UML won a Jolt award (we are getting close to a six-pack by now).

Rational Rose 98 shipped in March 1998 and shortly thereafter received a number of awards, including one from VB Journal and Object Magazine's editor's choice. Rose 98 provided a fairly sophisticated Add-In mechanism and that facility made it possible for the RoseLink program to explode, with many third parties choosing Rose as the foundation for their products. Rational Rose 98 Enterprise is currently our flagship product in the visual modeling market; Rose Java Professional Edition is the fastest growing.

The Future

One clear trend is that Rose is no longer just a modeling tool: it's a tool for developers, central to integrating the many artifacts and activities that are a part of every development team. For example, today you'll find integrations of Rose with RequisitePro for requirements capture, Rose with SQA Suite for testing, and Rose with ClearCase for CM. With the delivery of the Rational Unified Process, we now have a complete and consistent approach to development, within which Rose plays a central role for automation.

So, for the foreseeable future, Rose will continue to evolve. In each release you'll see more and more support for the UML, which is just reaching stability (the OMG will be releasing version 1.2 of the UML this year). More than just modeling, you'll also see Rose take

advantage of component based development and web-centric systems, continuing its tighter integration with the rest of Rational's product line, covering activities across the entire software development lifecycle.

Rose didn't just happen, and it didn't just spring up overnight. Rose is the product of hundreds of person-years of effort. Rose is grounded in very sound technology and is well-architected so as to support extensions by our partners. We listen to our users, and Rose will evolve to adapt to your changing needs.

Back to Contents

Copyright © 1998 Rational Software and Miller Freeman, Inc., a United News & Media company.

Home

Premiere Issue Winter 1998/99 Spring 1999 Summer 1999 Search Archived Articles

About Rational Rose

About the UML

Component Modeling with Rose 98

by Naveena Bereny

Naveena Bereny is the Marketing Engineer for Rational Rose. She has a Master's degree in Computer Science from Arizona State University and five years of experience using, supporting, and marketing object-oriented methods and tools. She can click a mouse around a Rose diagram faster than your eyes can follow.

The definition of a component is "a non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture." It is my intention to make the Rose 101 column a "non-trivial and irreplaceable part" of the Rose Architect. If you're new to visual modeling and the UML, hopefully Rose 101 will help to demystify some of the more complex aspects of visual modeling. And even if you are an expert, chances are you might just learn something too. Which brings me to my first column, an overview of component development focusing on COM, CORBA, and Java Beans.

So what is a component? Working from the above definition, I can continue by adding that a component is "any standard, reusable, previously implemented unit that is used to enhance the programming language constructs and to develop applications." A component conforms to and provides the physical realization of a set of interfaces. Components have separate interfaces and implementations. A component can have multiple clients, but does not need inherent knowledge of who is requesting the service. A client, in turn, does not need to know where the components exist.

Components are not objects. Component development and object-oriented programming are two very different beasts. Component-based development is the creation and deployment of software intensive systems assembled from components. OOP on the other hand, is a way to build object-based software components. To put it simply, object-oriented programming is concerned with the creation of objects while component-based development is concerned with making those objects work together.

With the rise in popularity of component-based development, new technologies have emerged to facilitate this process. Here is a brief

look at the most popular of these technologies:

COM: The Component Object Model. Developed by Microsoft, COM defines an open, extensible standard for software interoperability. Automation and ActiveX make it possible for the software components that you create and the software components that you buy to work together. A COM component like ActiveX, is a unit of executable code, like an EXE or DLL file that follows the ActiveX specification for providing objects. These reusable software components can be assembled into applications and services through ActiveX technology.

CORBA and Java Beans: CORBA stands for Common Object Request Broker Architecture, and is the brainchild of the Object Management Group. Like COM, the intent of CORBA is to create an open, extensible standard for software interoperability. CORBA defines self-describing components with the specification separate from implementation. CORBA, has an intermediate form (IDL) which resolves to client (stubs) and server (skeleton) bindings. The Object Request Broker (ORB) then connects the stubs on a client to the skeletons on a server.

Java Beans are platform-neutral Java software components, they are interoperable with both CORBA and ActiveX. Like CORBA components, Java Beans are self-describing. Enterprise Java Beans are transaction-capable, server-side beans.

UML and Components: The Unified Modeling Language (UML) combines the best of the best from data modeling, business modeling, object modeling, and component modeling. It is the standard language for visualizing, specifying, constructing, and documenting the artifacts of a software intensive system. Long recognized as the de facto industry standard, it is now the standard notation for software architecture since OMG acceptance in November of 1997.

The UML supports logical design and component design, as well as the inherent dynamics between them. Within the logical design, the UML supports packages, classes, interface classes, and the realizes relationship. The UML also supports the component diagram which shows the dependencies among software components, including source code components, binary code components, and executable components. The diagram may also be used to show interfaces and calling dependencies among components, using dashed arrows from components to interfaces on other components.

So how does all this apply to Rational Rose? Rose 98 supports the UML/COM lollipop notation natively, allowing you to model components and interfaces effectively. By stereotyping a class to

<<interface>> you can display the class as a lollipop in both the component diagram and in the browser. In addition to assigning classes to components, which represent source files, you can also assign classes to binary components such as DLLs and EXEs. Furthermore, a class can be assigned to several components, each of which can be of a different language. Rose 98 lets you model a component and generate the code for that component in the language of your choice.

COM components can also be reverse-engineered to derive interfaces for them. To do this, simply drag and drop a component such as a DLL over to the component diagram. Rose 98 then reads the published type libraries for these components and visualizes both the components and their interfaces using the standard COM notation.

By the way, did you know that Rose 98 is itself a COM object with a published type library? To visualize Rose, drag the file RationalRose.tlb over to the component diagram. Be warned though, this will take a while due to the many published interfaces of Rose 98.

Figure 1 is a simple component diagram of the Rational Rose executable interacting with the rvbcgwiz.exe-the code generation for the Visual Basic wizard in Rose 98.

When it comes to components, there's far more information to be shared than I can discuss here. You can download movie files with an audio explanation of component building and reuse from the Rational Rose web site at www.rational.com.

Before I sign off, let me dispel a common misconception. Rose 98 is often mistaken as a visual programming tool like Visual Studio, or PowerBuilder. Wrong! Rational Rose is a visual modeling tool. It is not a programming tool, although we do support design level code-generation, generating class definitions and function prototypes. Rational Rose does not build components. Instead, we help model and then integrate components with various IDEs such as Visual Studio. It is the IDE that is used to build and implement the component for you.

À bientôt.

Back to Contents

Copyright © 1998 Rational Software and Miller Freeman, Inc., a United News & Media company.

Home

Premiere Issue Winter 1998/99 Spring 1999 Summer 1999 Search Archived Articles

About Rational Rose

About the UML

Inside Rose Associations

by Tom Schultz

Tom Schultz is Director of Technology for the Rose Business Unit. He is responsible for the overall product direction for Rational Rose and has also been the head of engineering for Rose.

Welcome to Extreme Rose, the column devoted to the discussion of features and areas of interest that go beyond the basic concepts and understanding of Rose and UML, focusing on deeper usage patterns and techniques with the tool. It is my hope that this column will be a forum for the discussion of concepts, tips and techniques for the daily, "extreme" Rose user community.

As an introduction, this first issue will delve into a discussion of Rose associations-one of the most powerful communication features of Rose that also at times creates confusion in their use.

Anatomy of an Association

In the UML, associations are defined as a bi-directional semantic connection or relationship between classes. The association exists because there is a link between the associated classes. They provide the conduit for all object interactions. An association is comprised of several properties that are important to its utilization as a communication vehicle and, as we will see, greatly affect how you utilize associations in the design and implementation of software systems.

The Name of an association is an active verb or phrase that communicates the meaning of the relationship. It is usually read from left to right. Roles are nouns that denote the purpose a class is in association with another class. It is not required to supply names or roles, but they do provide an enormous amount of information in conveyance of the meaning of the model. Rose takes advantage of whatever information is placed in the model as when it is used to design and implement the code for the system.

Associations in Generation of Code

The effect of the bi-directional nature of associations in generation of code artifacts is best shown by the following example of two classes called Unit one class and Unit two class, with an association named connection between them. Unit one class plays a role as Unit one in the connection association, and Unit two class similarly plays the role Unit two. Figure 1 represents our example model.

We will begin with a C++ example. This connection association will generate, without any intervention, as the code shown in Figure 2.

This model generates code, with cross class pointing variables, that may or may not be what the correct design desires. In this case, if one wishes this implementation, you will need to modify the C++ generation ForwardReferenceOnly property, so that your compiler will not complain. The Forward Reference Only association role property specifies that the C++ Generator will produce a forward declaration for the supplier class of the association relationship before the class definitions in the module.

It is usually discovered in the design of the system that while the bi-directional nature of associations is correct and valid in the understanding and analysis of the system, the association needs additional design effort to get the model to one that generates just what the designer wishes. In our C++ example we could proceed with the code as generated, with the forward references, but we would have to validate whether it is essential for each object to contain a pointer to the other. Usually, these occurrences are designed into an unidirectional association using navigability. Navigation will make the connection association into a unidirectional association, as shown in Figure 2. In our example, Unit two can navigate, or have knowledge, of Unit one, but Unit one does not have knowledge of Unit two. The impact of this can be seen in the following example, this time using SQL Data Definition Language (DDL).

If we Generate from Figure 1, we get these table definitions.

While this might look interesting, it is highly improbable that most database servers will enjoy trying to create this self-referencing duo of tables. We can see the change in table design when we add the navigation to the model from Figure 2.

The connection association is now meaningful in terms of communication, but also carries the semantic information and knowledge in the model to generate proper code design and implementations.

Rose Implementation of Associations

Rose today supports the UML in terms of associations by a Rose Association. Associations in Rose are independently created entities in a Rose model that contain all of the pertinent association information: Name, Documentation, Multiplicity, Navigation. It further contains two pieces of information that become important to understand when we use Rose in a team environment with controlled units: roles and client-supplier.

Rose stores the roles of the association with the association. The roles then reference the class that plays the role in the association. Therefore, without the association existing in the model, the information about the association is hidden to the class. The second piece of data that is contained in the association is the concept of client-supplier. This information is captured when an association is drawn. When an association is placed, it is dragged from one class to another. The class where you start will be known as the client, the other side as the supplier. The real importance of this will come into play in a large model team environment, as we will see later.

When we use Controlled units and associations we need to understand one important rule: Rose stores associations within the package that contains the diagram on which the association was originally drawn. Since associations are independent entities in Rose and the UML, and are bi-directional, this is the proper way to treat these associations when we draw them. If you break your model into controlled units, you need to understand this concept, or you can have issues.

For example, if you have diagrams directly under the logical view (or use case view, or component view) then the associations are stored in the main Rose model file, even if you have controlled units and subsequently move the diagrams down into some controlled package. If you move both classes involved in the association and the diagram it was drawn on, the association doesn't move. You must understand and control the associations just as you would the classes.

Associations, Packages and Controlled Units

So how do you control and manage these associations? There are several ways to work in a controlled unit environment, but I have found the following to be my personal favorite. It involves the use of the concept of client-supplier to clarify the information in the packages that get controlled, and makes for a cleaner representation, both in presentation of information to the users of

the model, and to the internal storage of the controlled units. If we continue with our little example, we now look at the top-level diagram in the logical view and see Figure 3.

Figure 1 is a diagram created in Unit three. It represents Unit one class, that was created in the Unit one package, and Unit two class, belonging to the Unit two Package. The connection association was drawn from Unit one class to Unit two class. This means that the connection association belongs to Package Unit three. If we control the three packages as three independent controlled units, the association between the two classes is managed in neither controlled unit that holds either role end of the association. This may be what we want early in the analysis, but as the need for more concurrency to the model increases, we need to mange the model in ways that allow an individual team member to operate.

I have found that one easy and simple approach to managing associations is to use the client-supplier concept. Its premise is that when people draw the association, they start with the class that they want to be the "owner" or client of the association, and drop the other end on a class that will "supply" information to that class via the association. I will use this knowledge to insure that all associations are then stored with the class that is its client. The easy way to do this is to create a diagram in Unit one, drag the class that you wish to work on into the diagram, and then use the Query: Add Class menu item feature. Selecting the class, perform a Query: Add class with just the clients of the class and you will see an association which, in our example, identifies Unit one as the client. In the example, the connection association will appear. Then select any or all associations that appear and do an Edit:Relocate. This will move the "ownership" of the association to the client side, Unit one package. When we control the package, the association is now managed with the client class.

Another way is to use Navigation, but this can not directly be manipulated through the Rose menus. This concept would be similar to the above one, but the association would be moved to the unidirectional side of the association role. In our example, this would be to move the association from Unit three package to the Unit two package, since the navigation is from class two.

Summary

Associations are important constructs in the understanding and communication of object interaction and collaboration. They are rich with semantic knowledge that is interpreted and used by Rose when it implements the design. They carry independent existence in a Rose model. Understanding how Rose utilizes this knowledge and an understanding of the creation and management of

associations as entities in a Rose model can greatly enhance and expand the usage of these powerful UML constructs.

About the Author

Tom Schultz is the Director of Technology for the Rose Business Unit of Rational Software Corporation. For the last six years, he has focused exclusively on Rational Rose, with positions in the organization ranging from Technical Representative, Rose Developer, and Development Manager to Director of Engineering for Rose. He has almost twenty years experience in the development and deployment of large software systems, the last ten years employing Object-Oriented approaches and languages. He can be reached at toms@rational.com.

Back to Contents

Copyright © 1998 Rational Software and Miller Freeman, Inc., a United News & Media company.

Home

Premiere Issue Winter Issue Spring Issue Search Archived Articles

About Rational Rose

About the UML

From Use Cases to Components

by Magnus Christerson

Magnus Christerson, Senior Product Manager for Rational Rose, co-authored with Ivar Jacobson the Jolt Award winning book Object-Oriented Software Engineering: a Use Case Driven Approach.

You are just starting your first project using object technology with a component architecture. So how do you go about arriving at that architecture in the component world? The following gives you an approach that you can use to iteratively derive such architecture from use cases.

Use Cases

Perhaps you have some experience with use cases. If so, then you know that use cases are a terrific way to solicit input from end users and get them actively involved in defining requirements. The key to successful use case modeling is to keep it simple, so that the business objectives become the focus, not the notation or tools being used. I have seen far too many projects focusing on getting the <<uses>> relationships right at the cost of end user involvement. Instead, focus on what are the actual business tasks for the actors, and then detail in the use case descriptions how you want to support those business tasks in your system. At this point, changes to design are cheap, and you stand a good chance of getting most of your design right. Once you have started to build your architecture however, changes become more expensive.

A good use case description is extremely useful in a systems design. It is fairly detailed and expresses such items as:

● what is the interaction pattern between the user and the system

● what information is manipulated in the use case● what are the business rules to manipulate information● what side effects are there for a use case● what error cases need to be covered

The most important factor is that the user understands the use cases, and is happy with its contents. To make it easy for the user to understand, the best way to construct a description is often to express the flow in structured English, clearly stating exactly what will happen in the key scenarios of the use case and what events trigger what changes. Rational Rose allows you to link in use case descriptions from external documents or even from web pages, facilitating the description process.

In many cases, the best people to write the use case descriptions are the end users themselves. Typically a use case description is 5-15 pages long, though it can be longer if you include such details of the user interface, as storyboards. Remember though, that longer use case descriptions are harder to review and have everyone buy into.

Do not try to get every use case description complete before you start your system design. This exposes your project to too much risk. It is better to plan and develop your project in iterations. That way you can initially focus on getting some of the key use cases, or even some key scenarios, done, and start deriving an architecture for them without waiting for all use case descriptions to be completed.

Components

The use cases give you the content. Now you want to place this content in an architecture. In small projects you can build this architecture from the bottom up, starting with classes, etc. However, for larger projects this is not feasible, you need a higher level architecture to allow your team to work independently of each other and yet in parallel.

Components and interfaces are an excellent way to define such an architecture. They provide very strong encapsulation and information hiding by preventing any access to its internals except from its published interface. They also handle such popular component models as COM, CORBA and Java Beans, as well as various messaging architectures. In addition, they give you much of the middleware as well as many system services like transactions, event handling and access to databases.

Figure 1

Figure 2

A great way to derive a component architecture is to isolate functionality in the use case and encapsulate this functionality

behind interfaces in components. Think separation of concern. What functionality is related to what, and what will need to change as a side effect of another change? A popular approach, advocated both in the Rational Objectory Process as well as Microsoft Visual Studio design guidelines, is to separate out functionality managing the user interfaces (user services) from business logic (business services) and from storage aspects (data services). Although some components might cross some of these boundaries, most of them should not.

Another way of thinking of components is that they are hierarchical in structure. You will have certain components built on top of other components. These can be components that are part of your infrastructure, as the examples I mentioned earlier, or something you interface with. Or you can choose to decompose your own components into "sub" components just to get a cleaner architecture. Rational Rose allows you to easily bring in COM components with a type library into the model-simply drag the component onto a component diagram, and drop it. Rose will then import the component including all its interfaces.

Interfaces

So once you have an idea of what components you want, you will start fleshing out its interface. Remember that the interface is what customers will see, and it really pays off to spend time in getting a solid and well thought out interface. Try to group operations in your interface around an artifact that you also expose. An object-oriented interface is much easier to understand, and therefore use, compared to a functional interface. Maybe one of the parameters in your operations can be represented as an object in itself and some of the other operations can be grouped around this object. This object can then become an interface in its own right. This technique will decompose your interface to a more object centric interface that will have a structure you can understand, instead of a long list of functions. Remember that a component can expose many interfaces, and make sure you benefit from this.

The operations of the interface typically evolve and grow as the component matures. A good way to get a head start on your interfaces is to flesh out your use cases in a sequence diagram using the interfaces you have come up with so far. By going through a few scenarios, you will verify that you have the interfaces required for the scenarios; and if not, you can easily create new operations as part of this process. Rational Rose allows you to mix interfaces with classes in the sequence and collaboration diagrams, as well as create new operations on the interfaces, so you can flesh out how your scenarios will use your interfaces.

Executable Architectures

I mentioned earlier that you should not try to flesh out all details in the use cases initially before you move on. Quite the contrary, you should plan a set of iterations to develop your system. This allows you to mitigate risks early and control your project better. However, I emphasize that you need to plan and control these iterations so that you can measure your project's progress and not end up in a hacking chaos ending in death marches ...

A good proof of concept for an early iteration is to deliver an executable architecture. This architecture can be constituted of essentially empty components that just allow you to execute one or a few key scenarios. Having the necessary components nailed down and implemented as skeletons only, with the necessary interfaces, and knowing that you can execute this architecture is a big boost for your project! Suddenly you know you are on track. The following iterations should then leverage this architecture and add more functionality to it. Many times you learn a lot from this early iteration and want to modify the architecture, or even redo it. This might be ok, the purpose of these early iterations is to increase your understanding and ensure you build a solid system. Without an iterative approach, you would not have this chance to correct mistakes.

Also, do not try to be overly optimistic about the first iteration. It's more work than you think to arrive at an executable architecture. Do not plan to deliver a big chunk of the use cases in this first iteration. Select one or a few architecturally significant scenarios, and deliver those according to plan.

Distributed Systems

If you are building a distributed architecture, the deployment will also affect how you define your components. Normally, components cannot cross nodes, or even processes. So you might want to flesh out a deployment model which specifies the maximum distributed nature of your system. This would be your "worst case topology" of how you could deploy your system. This deployment will constrain your component architecture. If a component crosses a boundary, you need to split the component to (at least) two components. Therefore, if you are building a distributed system, you do want to describe the deployment model early on in your project.

About the Author

Magnus Christerson is Senior Product Manager for Rational Rose. He loves to travel, which is good, considering how many frequent

flier miles he's racked up as part of the Rose team. But he far prefers visiting new places with his wonderful wife. Recently he's been spotted playing floorball with the Silicon Vikings. His email is magnus@rational.com.

Back to Contents

Copyright © 1998 Rational Software and Miller Freeman, Inc., a United News & Media company.

Home

Premiere Issue Winter 1998/99 Spring 1999 Summer 1999 Search Archived Articles

About Rational Rose

About the UML

It's Tool Time

UML ToolkitHans-Erik Eriksson & Magnus PenkerPaperback-397 pages Bk&CD-Rom edition (October 1997) John Wiley & Sons ISBN: 0471191612

Lately it seems there are as many books on the UML as there are on the "VB Programmers are from Mars, Java Programmers are from Venus" theme. With so many choices on the market, how do you find the good ones? We asked an expert:

UML Toolkit hits the sweet spot in both coverage and readability," says John Dunbar, President of Dunbar & Co., a Houston, TX-based firm of Custom Business Software Consultants, Designers, and Programmers. "I give this book a rating of "10" because it is the best of the practical books I have found so far on the complete UML approach." Which is high praise coming from someone who has been in the business of systems analysis for over 15 years.

"When I started my own company back in 1983, I concentrated in systems analysis. Back then I tried to create a systems analysis process to nail down customer requirements. Along the way, I tried many of the methodologies: Booch, Jacobson, some of the others. I wanted to find a good way to express user needs and then document them, show them to the customer, review them to make sure both groups were in agreement, and then hand those documents to the programmers as specs for the design. And that's what the UML does."

From the early method wars, through to the OMG's acceptance of it as the industry standard, Dunbar was working with the UML. "With the UML, finally the big guys came together and created a method we could all work with. And the UML fits object-oriented programming perfectly."

To help him fully utilize the UML, Dunbar picked up UML Toolkit. "I looked at several other books, and they were lacking in implementation examples and details. This book has a lot of helpful

graphics illustrating the points raised in the book. Of the UML books I looked at, this was the best at covering all the issues in a clear and interesting way."

Detailed explanations, simple guidelines, and several real-world examples help even the most basic beginner learn how to use the UML, though the book has much to recommend it to the expert UML user as well. A case study using the UML to develop an application is used to illustrate points covered, and a glossary of UML notations makes all terms easy to understand. More advanced issues covered include such topics as evaluating an OO design, modeling patterns with the UML, and step-by-step instructions on how to move to the UML from Booch, OMT, and Objectory.

Overall, UML Toolkit is a nice blend of expert tips and beginner basics, and would make a useful addition to any Rose architect's bookshelf.

Our thanks to John Dunbar of Dunbar & Co for taking the time to talk to Rose Architect. Please visit http://www.dunbarco.com for more information.

Back to Contents

Copyright © 1998 Rational Software and Miller Freeman, Inc., a United News & Media company.

Home

Premiere Issue Winter 1998/99 Spring 1999 Summer 1999 Search Archived Articles

About Rational Rose

About the UML

Rose Extensibility: An Architectural Overview

by John Hsia

Trevor's father, John S. Hsia, is a Technical Lead Engineer with the RationalLink Partner Program. Between games of choo-choo and horsey, John trains and supports RoseLink Partners in their effort to create new Rose Add-Ins. John has spent almost ten years working with visual modeling tools, object-oriented methodologies, structured methodologies and meta-CASE tools. John can be reached at jhsia@rational.com.

Introduction

Since the 4.0 release of Rational Rose in January of 1997, most users have become increasingly aware of the "Rose Extensibility" in Rational's marketing literature, online help files, the 600-plus pages of hardcopy documentation, dozens of RoseLink Partner press releases and even in day-to-day e-mail messages over Rose_Forum. Beyond awareness of RoseScript (Rose's built-in scripting language), COM exposure of model semantics and the newly introduced Rose Add-In manager, most users still don't know what the Rose Extensibility really is. So to inaugurate the first issue of the Rose Architect, it's only fitting to begin this Rose Extensibility series with a discussion on the extensibility architecture of Rose.

By understanding Rose's architecture from an extensibility perspective, a toolsmith can better weigh the available options. Before discussing the architecture itself, several topics must be explored-specifically, what is Rational Rose, why extend Rose, and what is Rose extensibility.

What is Rational Rose?

We all know that Rational Rose is a visual modeling tool, or what was previously called an object-oriented analysis and design tool. But what is Rose from an extensibility perspective? I like to think of Rose as a UML platform. Given that the UML is a process independent notation used for one aspect of the development lifecycle, then Rose could be characterized as process independent

and as simply one tool within a collection of project-specific development tools. So it's only natural for Rose to be extensible or even adaptable in order to support a chosen development process and to support data exchange with its sibling development tools.

Why Extend Rose?

Of course, there are the obvious needs of the chosen process and the need to exchange information with other development tools. In the case of processes, it can be convenient to have wizards that help guide users and it can even be crucial to have process guidelines enforced. For example, the Rational Objectory Process is delivered as an Add-In for Rose with wizards and reports.

As for development tools, not only can the sharing of information be a major timesaving feature; it can potentially create a level of traceability within the development lifecycle. As one example, the requirements management tool, RequisitePro, creates requirements out of Use Cases from Rose as well as creating Use Cases in Rose out of requirements. As an additional example, there are multiple RoseLink Partners that map model information from Rose into various development frameworks, IDEs, languages and project management tools.

So from Rational's perspective and from a RoseLink Partner's perspective, extending Rose makes a lot of sense. But beyond the potential synergistic combinations between various commercial products, why should an end-user be interested in extending Rose? As it turns out, most projects also have special needs that go beyond what the tool architects and methodology gurus originally had in mind. These needs could include:

● Metrics gathering● Project-specific or company-specific interpretation of a

process● Project guidelines for completeness of models● Project progress and estimation reports● Automation of certain activities

So by addressing some of the needs stated above, Rose could be tailored to fit the specific needs of a project's development process rather than changing the development process to fit the modeling tool.

What is Rose Extensibility?

Rose Extensibility isn't just one scripting language or one COM interface or one template file. Rather, Rose Extensibility is a collection of Rose features that allow users to change its look and

feel, extend the model information captured, change its behavior, exchange data and model information with other applications and, finally, package these extensions as Rose Add-Ins.

Look and Feel. Users can customize menus, create custom dialogs, define icons for stereotypes and even add new tabs on the specification dialog. As shown in Figure 1, users can customize menus with new submenus (e.g. More Commands), menu options (e.g. Run My Script) and even conditionalize menu options (e.g. Report on Selection). In Figure 2, examples are shown of how users can enhance stereotypes with custom graphical icons in the diagram editor (e.g. actor), the browser (e.g. Oracle 8 Add-In) and the ToolBar (e.g. Microsoft Lollipop for interfaces). And finally in Figure 3, the specification dialog for packages is shown with additional custom properties (e.g. Owning Team, Approver ...) grouped with a custom tab (e.g. QA).

Model Information Captured. Since Rose is a generic UML platform, it is important that Rose allows customization of what model information is captured. This is done by adding new properties, and by defining new stereotypes.

Also known as UML TaggedValues, properties are essentially name-value pairs that can be attached to any model element. These properties are visually grouped as tabs. In Figure 3, five separate properties (e.g. Rating(1-10), Passed ...) are shown within the grouping called QA, or Quality Assurance, for the model element packages.

In addition to properties, users can define their own textual and graphical stereotypes. As defined in UML, stereotypes allow further classification of existing modeling elements. Beyond the UML defined textual guillemots (e.g. <<interface>>), users can define additional visual cues in the diagram editor, the browser and the tool bar-as shown in Figure 2.

Behavior. Some of the previously mentioned items could easily be considered as behavior changes but some less obvious ones are events and target languages.

A few select events (e.g. OnNewModel, OnAppInit) have been exposed in the windows registry for Add-Ins. Each Add-In can register for a particular event and when that respective event occurs, Rose will either invoke the registered RoseScript file or a specific method on a COM object. For example, the Framework Wizard in Rose Enterprise is invoked whenever a new model is created to help with pre-population of the new Rose Model.

In Rose 98, the concept of target languages was introduced. Essentially, multiple languages could be the target of code generation from a single model. This manifests itself in the form of an assigned language for a component in the component view. By allowing RoseLink Partners to define new Add-Ins associated with a new target language, users will have more coverage of the different languages, frameworks and development tools from the same model.

Exchange Data and Model Information. Modeling as an individual task is extremely beneficial but sharing this information with other tools and environments can increase productivity even more. To facilitate sharing, RoseScript includes the ability to read and write ASCII files; Rose exposes model semantics through the Rose Extensibility Interface (REI); and Rose has COM support.

From within RoseScript, built-in functions can be used to parse and generate ASCII files. There are even functions that can read and generate CSV (Comma Separated Value) files. Not necessarily an ideal situation but occasionally this is the only approach.

Within Rose, the REI is the COM server that exposes most, if not all, model information. In the REI, most model elements are first class objects with attributes and operations. Users can access this model information from both RoseScript as well as external languages that support COM. Type libraries are provided with Rose 98 to support those COM clients that only have early binding (e.g. Java).

Finally within RoseScript, users can access COM servers in order to access information from repositories, applications and servers. Definitely a much cleaner approach than ASCII files.

Rose Add-Ins. One of the most frequently requested features since Rose 4 was the ability for Rose extensions to co-exist in the same installation. With the release of Rose 98 March of this year, Rational addressed this need with the concept of an Add-In. Very similar to many of the Microsoft Office products, all the items (e.g. menus, properties, event response ...) that make up a functional extension are packaged into something called an Add-In. Add-Ins are cataloged in the Windows registry and users interact with it through the Add-In Manager (see Figure 4). Then users can interact with the Manager's dialog to dynamically activate and deactivate Rose Add-Ins. Now Rose Add-Ins created by Rational or our RoseLink Partners are more easily installed and managed by users.

The Rose Extensibility Architecture

Most readers are probably wondering when we would finally get to the Extensibility Architecture. As it turns out we've already discussed components of this architecture. We simply haven't tied it all together. So let's take a look at Figure 5 (comments refer to numbered blocks):

1. To begin with, within Rose itself the REI is the foundation for extensibility. This is where model semantics, diagram layout and crucial application functionality (e.g. controlled units, load model) is exposed. Remember from our earlier discussion, the REI is the Rose COM server. Whatever is exposed in the REI for RoseScript is also exposed to the outside world.

2. Outside of Rose, there can be Exchange Data Files or ASCII files that need to be generated, updated or parsed by the Rose Add-In. These files could be complex language-specific source files or a simple CSV format. By today's standards, this is somewhat primitive but this is still the primary way of exchanging data with some external sources.

3. A more ideal situation is one where there's a development repository or application that is COM enabled with a COM Server (e.g. Microsoft Repository). Just like the Exchange Data Files, there is information here that needs to be created, updated or read.

4. In some cases, an external application needs to access Rose model information. Either this is an existing application that is already COM enabled as a COM client or this is simply where the logic of the Add-In resides. Since Rose can be a COM server, any COM client can access model semantics through the REI.

5. Of course, users can choose to locate their logic within RoseScript. From this in-process scripting language, the REI can be accessed. In addition, there is enough functionality in RoseScript to parse and generate external ASCII files, to call COM servers and to invoke external programs that then turn around and become COM clients. Licensed from Summit Software (http://www.summsoft.com), RoseScript comes with a mini-IDE (e.g. debugger, language-sensitive editor, stack monitor, variable watch), a rich set of predefined functions (e.g. ODBC, COM, dialogs), and even a dialog editor with hooks for custom event handlers.

6. Because Rose is a generic UML platform, most Add-Ins require target specific properties. Since this information is really stored as part of the REI, both RoseScript and COM clients can access it. For the purposes of this diagram, I've located the Extensible Properties in a separate block as new properties have to be defined in a separate property (*.pty) file.

7. To make the Add-In more accessible to the user, menus can be customized. Here we've expressed the ability for custom menu options to invoke RoseScripts as well as external programs. Menus are also defined in a separate menu file (*.mnu).

8. Add-Ins can register for a select number of events where either RoseScript or a method on a COM object is called. Right now, the number of events is limited. We hope to enhance this dramatically in the future.

9. Users can define new stereotypes for model elements. All custom stereotypes along with an optional graphical representation (bitmaps and windows meta files) are defined in an INI file.

10. An Add-In within Rose consists of RoseScripts, custom menus, custom extensible properties, events and custom stereotype definitions. In most cases, an Add-In will also include an OLE server but that is something that the Add-In Manager doesn't control.

11. Add-Ins are registered in the windows registry. This means that all aspects that make up an Add-In are in the registry.

This architecture is accurate for all Rational Rose supported platforms. In fact, all the functionality described is included with every Rational Rose license-no developer kits needed. For UNIX users, the only difference worthy of noting is that utilizing COM within your Add-In will require a copy of Wind/U from Bristol Technology (http://www.bristol.com) during development.

Summary

As a generic UML platform, Rational Rose includes an extensibility capability that allows it to better adapt to a project's development environment. With different interpretations of processes and a wide assortment of possible development tools, it is crucial that extensibility be accessible by users and RoseLink Partners alike. Even with 90 RoseLink Partners actively creating Rose Add-Ins, there is still a need for users to tailor Rose, as every user's needs are different.

The Rose Extensibility Architecture is really very simple yet functional. In fact, all of Rational's own commercial Add-Ins (e.g. C++, Java, PowerBuilder, Forte, VB, Data Access Add-In ...) utilize these same extensibility features. Using Rational Rose's Extensibility Architecture, users can create add-ins such as simple metrics scripts and process wizards written in RoseScript or

complex language generators and parsers written as a COM client. With the multitude of available commercial add-ins and with the ability to create Add-Ins, users have the unique opportunity to customize Rose to fit their specific development environment and to create a development environment where tools can exchange data seamlessly.

Back to Contents

Copyright © 1998 Rational Software and Miller Freeman, Inc., a United News & Media company.

Home

Premiere Issue Winter 1998/99 Spring 1999 Summer 1999 Search Archived Articles

About Rational Rose

About the UML

by Veronica Herreria

Veronica Herreria is a Web Marketing Manager for Rational Software and is also the Web Editor for the Rose Architect web site. She can be reached at veronicah@

rosearchitect.com.

As Web Marketing Manager for Rational Software Corporation, it has been my job to develop and maintain the Rational Rose and UML Resource Center pages for the Rational web site at www.rational.com. Now, as Web Editor for the Rose Architect, I have the additional pleasure of developing and maintaining the magazine's web site at www.rosearchitect. com.

At the time of this writing, the Rose Architect pages are still under construction, but we have great plans for how they will appear. The Rational Rose pages have been and will continue to be your main source of news regarding Rational Rose. But the new Rose Architect pages will provide additional information about software development with Rose and the UML, as well as features and articles available only on the Rose Architect site. An online version of each issue will always be available plus models, scripts, interviews, contests, interactive polls and other features designed to inform and entertain. Subscription information, letters to the editor, submission forms, and writer's guidelines can also be found there.

This month the pages feature an expanded version of Grady Booch's article on Visual Modeling, containing a case study of software architecture for the enterprise. Also featured are downloadable scripts by Brian Lyons of Number Six Software, and by Rational Software contributors, Patrick Rutledge, Rose Senior Technical Support Engineeer, and Kevin Kelly, Technical Lead.

While the Rose Architect continues to invent itself, I invite your input. If you have any suggestions for improvements, any advice about content, or if you have Rose scripts or models you'd like to share, please let me know. Drop me a line at veronicah@rosearchitect.com and tell me what you think.

In the meantime ... I'll see you online.

Back to Contents

Copyright © 1998 Rational Software and Miller Freeman, Inc., a United News & Media company.

Home

Premiere Issue Winter 1998/99 Spring 1999 Summer 1999 Search Archived Articles

About Rational Rose

About the UML

The Rose Business ProcessLink from Ensemble Systems

by Rich Oiseth Rich Oiseth is a Technical Representative with Rational's Link Programs group. He recently completed an integration between Rose and UNIFACE, Compuware's 4GL development environment. Before joining Rational in early 1996, he spent ten years at TRW, Inc., specializing in relational databases and object technologies. Rich is based in Arlington, VA.

The Rose Business Process Link (RBPL) Add-In from Ensemble Systems, Inc., provides a simplified approach to business process modeling using Activity Diagrams. The business process model defined in the tool can be used for the analysis and improvement of business processes and the specification of future software systems. The usage context identified during business process modeling can be used as the basis for the requirements analysis for the system under development. Activity diagrams permit the definition of the workflow for the system. When business process modeling and analysis has been completed, the RBPL supports the export of Use Cases, Actors, and classes to Rose. The tool also permits the export of text and diagrams to Windows MetaFiles (.WMF), Rich Text Files (.RTF), and Microsoft Word for generation of HyperTextMarkup Language (HTML).

Ensemble Systems has focused on supporting a process decomposition approach to business modeling with this version of the RBPL. Activity diagrams are an effective way to represent the workflows identified with this approach. Ensemble targeted three key objectives in developing the RBPL: emphasize tool approachability, permit different analysis approaches, and support a clean hand-off from business modeling to software analysis and design. Tool approachability was considered essential because business analysts using the product have a wide range of technical skills and experience. Different approaches are supported to accommodate varying work-styles. The analysis products generated by the RBPL provide sufficient detail to permit system development, leading to a clean hand-off.

Business processes can be modeled as flows of activities. ("Flows" meaning distinct activities start and end in sequence, often passing

an object from one to the other, and possibly diverging into concurrent parallel sequences which merge by the completion of the process.) An event coming from outside the business, such as a customer request, triggers a sequence (or multiple parallel sequences) of activities. Each activity can be further decomposed into sub-activities, to the level of detail required to convey the operation of the business clearly.

An activity diagram presents a flow of activities in response to an event. Each activity is shown, connected to the activity that follows it by an arrow indicating a transition from the one activity to the next. The RBPL approach permits the usage of additional UML notation elements on activity diagrams including actors, use cases, dialogs representing a user interface, classes implementing dialogs, and packages to partition complex diagrams. People or support systems (called actors) that participate in the activities are shown associated with their activities by dependency arrows in the RBPL. Where an object is produced as output or an object is required as input for a particular activity, that object can be shown in the diagram. An activity diagram can also show decisions between alternative paths, concurrency, and synchronization between parallel paths.

Figure 1

An activity model is the set of activities that are performed by the business and the relationships between these activities and the actors. The activity model reflects the decomposition of complex activities into sub-activities. Each activity is documented to provide a description of the scope and objectives of the activity. A model of a complex activity can contain diagrams showing details in terms of sub-activities that the activity encompasses. An activity or object that is repeated in a number of diagrams need only be documented once in the activity model.

Using the Rose Business Process Link

Most users of the RBPL employ one of three different business analysis approaches: (1) define a large number of small use cases; (2) create a small number of large business use cases; (3) or a hybrid approach utilizing process modeling. If a large number of small use cases are identified, workflow diagrams are attached to each use case and the business workers (actually roles) are mapped to system actors. When working with a small number of business use cases, one high-level activity diagram is defined for each use case with a hierarchy of lower-level workflow diagrams. The hybrid approach decomposes activities into a process model and uses a single top-level activity diagram to represent the system workflow with lower-level activity diagrams being placed

into a package. Most business analysts using the RBPL employ the hybrid approach in their business modeling activities because it is consistent with their backgrounds and provides an effective way to show a business system to a user.

When using the hybrid approach with the RBPL, the following steps represents a typical cycle:

1. Identify system use cases representing business processes and business workers (becoming roles).

2. Define activities within the use cases and construct activity diagrams.

3. Model the user interface with the GUI builder provided.

4. Identify the workflows for the system.

5. Use story boards to walk-through the analysis model (this permits the animation of a model by walking through the sequence of events in an automated fashion.)

6. Use the workflow model to validate the use case model.

7. Define system features and map them to the activities identified.

8. Plan software release contents and the delivery schedule based on features.

One of the risks associated with the hybrid approach is defining the scope of the system too early in the development cycle. Another risk is that the functional decomposition used in process modeling may produce inappropriate use cases.

Evaluation Criteria:

1. Ease of installation and configuration: The Setup Wizard provided with the RBPL does an effective job of automating the installation and configuration of the Add-In including required registry settings.

2. Ease of use: The layout of the graphical user interface of the RBPL closely resembles the Rose paradigm of a browser, documentation window, and diagram surface. To reduce complexity, fewer options are presented in the RBPL user interface than Rose provides.

Navigation through the tool directly mimics the behavior of Rose. It would be helpful to have an online tutorial and more examples provided with the RBPL.

3. Integration with Rose: The RBPL supports the export of use cases, actors, and classes in the form of a Rose model file. Relationships are not exported to Rose (the RBPL permits only dependency relationships and state transitions). OLE automation is not included in the current version but would be useful in interacting with Microsoft Word.

4. Adherence to standards:

All of the modeling elements specified for activity diagrams in the UML standard are provided in the RBPL. The tool permits the use of additional UML modeling elements (use cases, actors, packages, classes, and dialogs) on activity diagrams, producing non-UML compliant diagrams. Users of the RBPL will need to assess their own needs and determine if using non-UML standard elements on activity diagrams is appropriate for their situation.

5. Value Added: The tool represents a valuable addition to Rose by supplying one of the eight basic diagrams defined in the UML standard: an activity diagram. The business engineering capabilities provided in the RBPL add significant value by enabling linkage between business processes and use cases. The usage model described in the RBPL also supplies a requirements framework for further systems development.

6. Vendor support: Ensemble Systems provides training classes, consulting services and technical support for the RBPL.

The two key capabilities provided by the Rose Business Process Link (activity diagrams and business modeling) are important elements in a comprehensive software development process. The activity diagram support is important for workflow modeling and as a communication vehicle between business analysts and software analysts and designers. The RBPL provides excellent support for the process modeling (functional decomposition) approach to business engineering. Process modeling is the most widely used business engineering approach and is understood by many business analysts. Object-oriented business engineering techniques as prescribed by the Rational Unified Process are not supported in the RBPL. The approach of using activity diagrams to model business processes has limitations when attempting to support UML-compliant use case diagram functionality (for example, "communicates" relationship between an actor and a use case is not supported).

Future Directions

Key features planned by Ensemble Systems for future versions include OLE automation, integration with RequisitePro, and activity-based costing. Ensemble is also planning a new software product called "Product Manager" which will focus on feature-based requirements.

Other Business Engineering and Workflow Products

RoseLink partner IDS-Scheer is constructing an integration between the ARIS Product Suite and Rose. The ARIS Product Suite is a widely used business-engineering toolset supporting business process improvement, benchmarking, process-oriented standard software implementation (such as SAP and Baan), workflow implementation, and activity-based costing.

Technical Environment

The RBPL operates in Windows NT and Windows95 environments.

Pricing

The Rose Business Process Link is priced at $995. 30-day evaluation copies are available for download from Ensemble's web site http://www.ensemble-systems.com.

Contact Information at Ensemble Systems

Mike Bacinschi(604) 231-9510 Ext. 33mikeb@ensemble-systems.comNick Mellios(604) 231-9510 Ext. 55nickm@ensemble-systems.com

Back to Contents

Copyright © 1998 Rational Software and Miller Freeman, Inc., a United News & Media company.