Download - The View From the Front: Publisher's Note Changes …...both subclassing and subtying, as some describe it). Most of its previous stereotypes have been eliminated, except for "implementation",

Home

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

About Rational Rose

About the UML

Spring Issue, April 1999

The View From the Front: Changes to UML by the Revision Task ForceDr. James Rumbaugh

Integration Focus: Rose and SoDADavyd Norris

Business Modeling, Teenagers, and Primal Scream TherapyChristian Buckley, Darren Pulsipher

CORBA and Rational Rose -- An Insider's ViewJeffrey Hammond

Creating Your Own Rose Add-Ins with Visual BasicJim Conallen

Real-Time System Architecture Comes AliveScott Frohman, Elizabeth Leek

User-Defined Tags with Rose ScriptingKevin E. Kelly

Using UML to Design Database ApplicationsMichael Blaha, William Premerlani

Bonus Article . . . On-Line OnlyWhat's New in Rational Rose 98iNaveena BerenyExpanded version of the Rose 101 column

Publisher's Note Adam Frankl

Editor's E-mail/Ask the ExpertTerry Quatrani

Amigo Page Dr. James RumbaughThe View from the Front: Changes to UML by the Revision Task Force

In the News How Suite It Is

Rose 101 Naveena BerenyWhat's New in Rational Rose 98i

Magnus Opus Magnus Christerson, Niles UndénModeling Large Systems

Extending RoseJohn HsiaRational Rose 98i Customizing Shortcut Menus

Rose Around the World Nasser Kettani

RoseLink Review Patrick RutledgeRose 98 for Power Users from Iconix

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

http://www.therationaledge.com/rosearchitect/index.html


http://www.therationaledge.com/rosearchitect/mag/index.html

http://www.therationaledge.com/rosearchitect/mag/backissu.html

http://www.therationaledge.com/rosearchitect/mag/archives/9901/index.html

http://www.therationaledge.com/rosearchitect/mag/archives/summer99/index.html


http://www.therationaledge.com/rosearchitect/sm/index.html

http://www.therationaledge.com/rosearchitect/products/index.html

http://www.therationaledge.com/rosearchitect/book/book.html


http://www.therationaledge.com/rosearchitect/contact/index.html

http://www.rational.com/rose


http://www.rational.com/uml


http://www.rational.com/

http://www.mfi.com/

http://www.unm.com/

http://www.unm.com/



http://www.mfi.com/

http://www.unm.com/

http://www.unm.com/

Home


About Rational Rose

About the UML

The View from the Front:Changes to UML by the Revision Task Force

by Dr. James Rumbaugh

Dr. James Rumbaugh is one of the leading software development methodologists in the world. Along with Rational colleagues Grady Booch and Ivar Jacobson, Jim developed the Unified Modeling Language (UML), the industry-standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. Jim has a B.S. in physics from MIT, an M.S. in astronomy from Caltech, and a Ph.D. in computer science from MIT.

UML Revision Process

The Unified Modeling Language (UML) is the result of years of work by many persons, including not only the Amigos (Grady, Ivar, and myself) but also many others who developed methods, proposed modeling concepts, served on task forces, and wrote documents. After several iterations, version 1.1 of the UML proposal was submitted to the Object Management Group (OMG) in September 1997 by a coalition of 17 companies led by Rational Software. The proposal was sent to the OMG membership for a vote and was adopted unanimously in November 1997, at which time it became an OMG standard.

No standard is ever perfect as initially submitted, however. The OMG charters a Revision Task Force (RTF) to fix bugs and clarify ambiguity in new standards. I was the Rational representative on the UML RTF with about a dozen others representing various submitters, under the chairmanship of Cris Kobryn of MCI Systemhouse. The committee began work in November 1997 and is scheduled to submit its final report this Spring. At that time, UML version 1 will be complete.

A revision task force is not empowered to significantly change or extend the scope of the original standard. It is not an opportunity for members to get a second chance to insert their pet concepts that were rejected the first time around (although they try). Its purpose is to fix problems with the existing standard, not to redesign it. The following kinds of changes are appropriate to an


















RTF:

● Fixing typos and obvious errors in wording.● Clarifying unclear or ambiguous statements.● Correcting internal inconsistencies.● Providing for special cases and combinations that were

overlooked by the original documents.● Adjusting minor discrepancies in naming, notation,

semantics, or organization that would confuse users.● Inserting features that were mistakenly omitted from the

original documents or garbled in their explanation.

Obviously good judgment must be used in deciding whether a change exceeds the scope of the original proposal. We adopted the following guidelines to the kinds of changes that are out of scope for an RTF:

● Adding new kinds of functionality that are orthogonal to existing functionality or significantly extend the scope of the original request.

● Revisiting matters of style and individual preference that were deliberated and resolved in the original proposal (unless an overall review shows that some decisions were clearly inconsistent with the rest of the standard).

● Addressing technically difficult issues that require research or take too long to complete.

● Making significant changes the effectiveness of which requires user experience with the existing standard.

Matters that are out of scope for an RTF are appropriate topics for a future full-scale enhancement of the standard. For UML, this would take the form of a new Request for Proposals (RFP) followed by the normal open competitive submission process.

One of the main drivers of a revision is comments from the general public. The OMG received hundreds of comments from scores of individuals, including several well-known methodologists as well as many ordinary users. We organized these into a database for easy access and reorganization. We used the database to track our decisions, update the documents, and prepare responses to the submitters.

The people on the RTF became exceedingly familiar with the details of the UML metamodel and documents. During our work on the original UML proposal, I had suggested to Grady that he needed to "get a life" when he was able to quote UML chapter and verse numbers from memory. However, during the UML RTF work I found that I and several others were casually throwing around UML metamodel figure numbers, quotations from semantics

descriptions, and OMG document numbers. I guess the quality of life of any standards committee member must be questionable. The members of the UML RTF did work together in a cooperative manner focused on technical solutions without political posturing, even though they represented various companies with different market interests. Potential standards committee members should be warned, however, that many standards committees are not so free from politics.

UML Changes

Most users want to know how much UML has changed and what the changes are. We received one complaint from a user that he had bought UML books that were now obsolete. Unfortunately, any living language or system undergoes changes in response to its use, so any document starts becoming outdated the moment it is completed. I have an old copy of Bjarne Stroustrup's Annotated C++ Reference Manual that contains a chapter on the experimental concept called templates, which have long since been added to the language. (Some users would claim that templates should still be considered experimental, but that is another matter.) Most of the book is still useful, because the subsequent changes to C++ did not change most of the original content. It is the same with the UML revisions: there are a few changes that will be noticeable to most users, a number of small things that may be important in certain specialized areas but won't affect most users in their everyday work, and a great many internal changes that only an obsessive UML methodologist, tool implementor, or fanatic would care about. (If you fall in those categories, get a life!)

I will briefly summarize some of the more important changes in this article. For a complete description of the revised UML, see The UML Reference Manual by myself, Ivar Jacobson, and Grady Booch, which has recently been published by Addison-Wesley. That book does not discuss the changes from the original proposal, however. Its purpose is to describe UML as it finally exists.

I will organize the description by UML subject areas. Note that this is only a brief summary of the more visible changes and not a complete list. For the full report, see the OMG web site at www.omg.org. I also cannot describe the details of semantics and notation in this brief space; see The UML Reference Manual for a full description of them.

Use Cases

We recognized that the "uses" relationship in the original proposal was being used in two different ways for different purposes. Therefore, we split it into two distinct relationships, each with a

http://www.omg.org/

clear meaning and purpose. (The name "uses" has been retired as a use case relationship but lives on as a dependency among Classifiers, a different meaning in any case.) You can define generalization between use cases. This means that the child use case inherits all of the behavior, constraints, and meaning of the parent use case and can be substituted any place that the parent use case could be used. For example, Perform Retinal Scan might be a specialization of use case Verify Person. The child use case can insert new behavior steps between behavior steps of the parent, however, so the behavior sequence of the parent is embedded in the behavior sequence of the child, but not necessarily contiguously.

The other meaning of "uses" is now captured by the "include" relationship. This relationship allows one use case to incorporate a behavior sequence defined by a target use case. There is no implication of substitutability. This is similar to a macro or subroutine call-it allows several use cases to share common fragments of behavior without deeper semantic implications.

The syntax and semantics of extension points have been clarified. These are used in an "extend" relationship in which one use case adds behavior to a base use case. (By the way, one naming cleanup was to drop the 's' from many relationship names so that all such names are in the imperative.) An extension use case may contain a list of behavior segments, each specifying a separate insertable piece of behavior; the "extend" relationship must reference the same number of locations, called extension points, within the base use case. These are the points where each segment is inserted into the base behavior. The most common case will have a single segment, however.

Static Structure

We received many comments that the set of subclasses and stereotypes of Dependency was confusing in the original proposal. Some specializations used subclassing, some used stereotypes, with no overall pattern. The set of relationships among Classifiers was reorganized to be more coherent. Relationships are Association, Generalization, Flow, and Dependency. A Flow connects two values at successive times in an interaction (using the <<become>> or <<copy>> stereotype). Dependency is specialized as Abstraction, Binding, Permission, and Usage. Abstraction represents relationships among different semantic views or levels, including the variations Trace, Refinement, Realization, and Derivation. Binding connects a parameterized element (a template) to its various instantiations. Permission allows a Package to reference elements in other packages, by simply referencing them (<<access>>) or by adding them to its own namespace (<<import>>). Usage represents various

dependencies induced by the implementation of a class, such as <<call>>, <<instantiate>>, and the use of parameters. From the average user's viewpoint, most relationships (except Generalization, Association, and Realization) are notated by a keyword on a dashed arrow, so the taxonomy can be ignored.

A number of other small changes have been made. An Interface may be referenced by another Classifier through an association and may be a parameter of an operation, but an Interface may not itself have visibility across an association to another element (that is, the association must be one way toward the Interface, as the Interface has no implementation structure). Classes can declare signals as well as operations that they handle. Generalization has been reaffirmed to require full substitutability (that is, it implies both subclassing and subtying, as some describe it). Most of its previous stereotypes have been eliminated, except for "implementation", which indicates implementation inheritance without substitutability (use with care for programming reasons only, or better yet, don't use it at all). The semantics of templates have also been clarified.

State Machines

The concept of <<currentEvent>> was added to handle entry transitions that might be activated by various outer-level transitions triggered by events with different signatures. During the processing of the transitions and actions triggered by a single event, the event is available as the "currentEvent" even on actions nested deeply within a state. The signature of the current event cannot be declared statically, because it might correspond to several possible events, so an action may discriminate on its actual type at run time in a case statement to obtain a concrete signature. This means that the same entry action can respond differently to different trigger events.

The caret notation (^eventname) for sending an event was dropped and treated as just another action with the keyword "send". This permits send actions to be properly interleaved with other actions.

In addition to actions, a state may contain an activity. An activity is a continuous operation that is performed as long as the state is active. Unlike an action, it need not be completed before another event can be handled; it can be interrupted or aborted by a transition that causes a transition to another state. Activities are useful for modeling long nonatomic computations and real-world processes.

The meaning of call events was clarified. They represent a distinct

mechanism for implementing operations using a state machine control instead of a fixed method. Calls are synchronous. The caller does not know how an operation is implemented. The receiver can choose to implement it as a method or a call event on a state machine. Sending a signal is an asynchronous communication among objects.

Activity Graphs

A number of conveniences were added to support usage patterns commonly accepted by the activity modeling community. Most of these things could have been modeled using existing concepts, but with considerable convolution. Some of them represent general state machine capabilities but they are discussed here as their main use.

An event can be declared to be deferred within a given state. This prevents it from being lost if it occurs before the current activity is complete. It occurs when the state machine activates a different state in which the event is not deferred. This capability is very useful when there is indeterminacy about when an event will occur.

Concurrent activities can communicate using "synch states" (short for synchronization). These are communications channels that queue tokens between states in different threads of control. Without this capability, some common kinds of interactions were impossible to represent.

Some notational conveniences were added, such as icons for sending and receiving events and for executing conditional threads.

Sequence Diagrams

The <<become>> flow shows a change in state, value, or location of an object on a collaboration diagram. But there was no way to do this on a sequence diagram. It can now be shown by placing a state or object symbol directly on the lifeline of an object at the point where the change occurs. This is simple and intuitive.

The concept of "timing mark" has been eliminated. Instead, the time that a message is sent and/or received can be represented by an operation "sendTime" or "receiveTime" on the name of the message. This approach is more general and permits defining additional operations on messages, such as stochastic measures.

A distinction can now be made between a sequence diagram that shows roles in a collaboration and one that shows actual objects. The latter case is underlined, the former is not. It is also possible

to show both the name of an object and the role or roles that it plays within a collaboration as well as its actual class. This usage will probably be rare, however.

Collaboration Diagrams

If an association line is drawn in a collaboration without an underlying base association, then it implies an association that is meaningful only in the context of the collaboration. It is implicitly declared by the collaboration. This is a common situation, as the purpose of a collaboration is to define a context-dependent relationship among classes.

The <<become>> and <<copy>> flows may have sequence numbers on them to show where they occur relative to a sequence of actions.

An action with a set of target objects is applied to each of the objects concurrently. If the order of application matters, the actions should be placed in a control loop instead. Concurrent application on a set of objects is a fairly common and useful thing. The broadcast and vote constraints have been eliminated as unnecessary and too complicated, respectively.

Model Management

The meaning of the permission relationships has been clarified. The "import" relationship has been split into <<access>> and <<import&gr;&gr;. These are relationships between packages, not individual elements. The <<access>> relationship permits elements of one package to reference elements of another package, without modifying the namespaces of the packages. The <<import>> relationship loads the names of the public elements of the target package into the namespace of the importing package. A package can reference any element of a containing package, but must access or import an internal package to see its elements. (In other words, packages are transparent outward but not inward.)

The meaning of Subsystem has been defined more clearly, with contents divided into specification elements and implementation elements.

Technical Changes

There are a large number of internal technical changes to the metamodel and the semantics documents, mostly to correct small bugs; most of these changes would be of interest only to a methodologist or implementor. The specification of the OCL

language has been updated and the IDL specification of the language has been regenerated.

Future Plans

As the first version of UML comes to completion, I feel that we have accomplished what we set out to do over four years ago: bring the OO community together with a widely accepted standard notation and semantics that cover all or most of the concepts the leading methods had included under varying notation and terminology. UML has been a big success, primarily because it evolved from its origin as the work of three methodologists and involved a large number of contributors in its development.

UML is not perfect now, nor will it (or any other language) ever be. We knew that some issues were important, but we lacked the time or the consensus to solve them during the first version of UML. For example, the stereotype mechanism is useful, but it is also a bit of a kludge and should eventually be replaced by a first-class extensibility mechanism. But to do that right is technically challenging and would have been a diversion in the beginning, so we put it off until a future version of UML.

Other issues will come up as technology progresses. The past ten years have seen the explosion of the Internet, vast increases in computing power, and the widespread use of components. We provided some support underlying such technology, but who knows what surprises the next ten years will bring? Some additional UML features may be needed to support new technologies.

As people use UML in wide numbers and many tools begin to support it, we will probably find that some aspects of it don't work as well as expected. This is also true of most programming languages - they evolve over a period of time as users learn how to use the language.

Some issues are already being addressed. A proposal for exchanging stream-based model information using XML is nearing adoption, and an RFP has been issued to define an executable action language for UML, important for those who want executable models.

For the other issues, I would expect that eventually a UML version 2 will be developed. For this kind of major update, the OMG will probably issue a new RFP and go through the same kind of open development process that produced the existing UML. But that doesn't mean that you should wait to begin using UML. Every language, every tool, every living system evolves, and you have to live with it. With the completion of UML version 1, it is ready for

widespread use today on almost any kind of application.

References

1. James Rumbaugh, Ivar Jacobson, Grady Booch. The Unified Modeling Language Reference Manual. Addision-Wesley, 1999. ISBN 0-201-30998-X.

2. Object Management Group. See web site www.omg.org and follow links to UML for official documents.

Back to Contents


http://www.omg.org/



http://www.mfi.com/

http://www.unm.com/

Home


About Rational Rose

About the UML

Davyd A. Norris is a Software Engineering specialist with Rational Software. He is based in Sydney, Australia and works with the Australia North Field Sales team, providing training, consulting and mentoring to corporate clients. Davyd has been playing with computers since he was underage, and put himself through college by playing in rock bands and hacking code. You can write him at [email protected]

Make Mine a Double!

by Davyd A. Norris

Towards the end of a tough development grind, your burnt-out mind daydreams of a shady oasis bursting with lush vegetation and bubbling springs. The boss has no money left for that Hawaiian jaunt you've been planning, but all is not lost -- Rose is smelling sweet and your virtual oasis is just a SoDA or two away!

Introduction

If you are anything like me, the thought of writing project documentation is a lot like going to the dentist. It is boring, painful, and ends up being put off for so long that eventually there is little point in going through with it anyway. What makes the task more futile is that a project's written documentation and reports are static artifacts representing a snapshot of the project at a particular instant in time. Unless you put in constant effort to maintain them, they quickly diverge from project reality, becoming little more than bookshelf filler.


















mailto:[email protected]

With the advent of automated tools such as Rational Rose, RequisitePro and MS Project, your project can be documented directly in the tool repository and can be maintained and managed as a natural part of the development process. There will be times, however, when documentation must be created for an external audience who do not have or care about tools, or who have to formally sign off on an aspect of the project. Good examples of these are the various Use Case Model reports that the client must review and sign.

Reports may also sometimes need to be assembled from a mixture of free format text and bits scattered throughout the different models. A good example of this is the Software Architecture Document, where key design mechanisms from each of the architectural views are documented and described. The mechanisms may be defined in Rose in different diagrams, but most of the document is free text describing decisions and trade-offs made as the architecture evolves.

On a different note, much of the information in your models can be reused in different contexts. It may be possible to reuse information stored in one repository to produce seemingly unrelated artifacts in another. This idea, coupled with sheer laziness and my dislike for writing documentation, prompted me to see if I could reuse the work I had done during Use Case Analysis to help me automate the creation of some of my test design documents.

Scenario-based Testing

Testing a component-based architecture is different from testing traditional structured designs. If you are striving for a sound level of reuse, a percentage of your application will be either borrowed from previous projects or purchased as off-the-shelf components. These components have already undergone extensive testing, so the issue is no longer one of whether the components work, it's one of whether they work together. I break this sort of testing down into three areas:

● Functional Testing - Verify that the system correctly delivers the requested functional requirements, ie., an ATM allows you to retrieve your account balance.

● Non-functional Testing - Verify that the system conforms to the requested usability, reliability, performance and supportability requirements, ie., account balance retrieval is carried out in less than 5 seconds.

● Dysfunctional Testing - Verify that the system exhibits no antisocial or undesirable behaviour, ie., you cannot get at someone else's account balance as well as your own.

With a little forethought during the Use Case Analysis stage of design, it is possible to come up with a small set of sensible scenarios that cover every possible flow through a use case. This minimal spanning set of scenarios can then be used to create both the use case realisations in the design model, as well as test cases that cover all three of the above testing areas in the test model. The big advantage of this scenario-based testing is that there is an almost direct and unambiguous translation of the requirements into the tests, thereby increasing the coverage and quality of your test model.

Using this method, I document each scenario in Rose by creating initial high-level UML sequence diagrams grouped under each use case. I then use these diagrams to create the test case designs directly, or I create another package called 'Test Model' and copy the entire structure into it (Figure 1). The benefit of the latter approach is that you can document additional test scenarios for those supplementary requirements not easily expressed in the use cases. The principle drawback is that you then have an additional set of diagrams to change manage.

Serving Up Some SoDA

The next step is to take the contents of the scenario diagrams from Use Case Analysis, and translate them into a form that can be used as a script for test procedures. The fastest way to do this would be to simply copy and paste the relevant graphics and text straight from Rose into your test design document, but this approach looks patchy and does not allow testers to add things like inputs, outcomes and verification points. It is also extremely manual and quickly leads to inconsistencies.

A more sophisticated technique is to use RoseScript to automatically extract information contained in the diagram and insert it into a document as text. This operates just like a mail merge and uses pre-defined templates to create professional-looking test design documents. However, any added text would be obliterated each time you generated a new report, unless you spent extra time scripting around the problem.

This is the approach used by the current Rose 98/SQA TeamTest link which uses RoseScript to automatically create a test requirements hierarchy and linked test procedures in SQA Manager. The script then fires up a COM link to Microsoft Word to create and fill test design documents with use case information from the model. (NB: If you have the Rose/SQA link installed, the exptosqa.ebs RoseScript source file is installed

http://www.therationaledge.com/rosearchitect/mag/archives/9904/f2fig1.htm

along with the link and can be examined and/or edited.)

Then there is SoDA (short for Software Documentation Automation). SoDA extracts information just like the last approach mentioned, with several key differences:

● It is not specific to Rose. SoDA comes with translators (known as SoDA domains) for Requisite Pro, Rose, SQA, Word, and the OS file system. Domains for other Rational products are currently under development.

● Multiple domains may be used within a single document, allowing you to create complex reports that link individual repositories.

● It comes in flavours for Microsoft Word 95 and 97, as well as FrameMaker on both Windows and Unix platforms.

● It implements an in-place merge, allowing you to regenerate the document without losing any added text.

What Puts the Fizz in SoDA?

SoDA works by inserting macro commands into documents as pairs of annotations. Anything between the annotations will be replaced when you generate a report, while anything outside the annotations will be preserved. There are four basic commands SoDA uses:

OPEN opens a data source via one of the registered SoDA domains.

DISPLAY extracts and displays the requested items of data. These may be text or diagrams.

REPEAT iterates over collections of items in a repository with sorting and filtering.

LIMIT suppresses display of sections based on user-defined criteria.

SoDA is simple to use and comes with wizards and templates to get you up and running quickly, but commands can also be added and edited individually to achieve fine-grained control over your output document format. What's more, the Rational Unified Process ships with a set of SoDA templates for its artifacts, and templates are also available for other processes such as Mil498 and IEEE standards.

Automating Scenario-based Test Design

The format for my test design document was simple. (Figure 2) I wanted a header consisting of the name and description of the


scenario, followed by the name and description of the use case the scenario belonged to. Then a list of files that contained any required input data sets. Following this, I wanted a table with columns showing the sequence of steps the tester needed to perform, any required input data, the expected system response, and how that response should be verified.

To set this up, I first created a new SoDA template and inserted an OPEN command, followed by several DISPLAY commands that retrieved the scenario and its parent use case. I then created a table with headers and a single row. I highlighted this empty row and added a REPEAT command for all the messages on the interaction diagram in order.

The last part was a little tricky. If the sender of the message was an Actor, I wanted to display it in the second column as a required user action. Messages coming from anything else should be displayed as a system response in the fourth column in the format "The <server object> will <message>". This was done using appropriate LIMIT and DISPLAY commands in the two table cells.

To create the document, I simply copy the template to its destination, and generate. The first time SoDA runs on each template, it will pop up a dialog asking for the name of the model to OPEN. It will then minimise Word, generate the report, and restore Word once finished. Any errors will be listed in a new Word document with hyperlinks to the place in the original template where the error occurred.

Summary

SoDA eliminates nearly all the objections I had over writing documentation, and almost makes it an enjoyable experience. I now incorporate a SoDA documentation update step in my weekly build process, so my reports are no more than a week out of date. My test designs are nearly finished, my Architecture document is done, and with a SoDA spring making Rose blossom, my oasis awaits.

Download testing documentation.

Back to Contents


http://www.therationaledge.com/rosearchitect/db_area/testdoc.zip



http://www.mfi.com/

http://www.unm.com/

Home


About Rational Rose

About the UML

Christian Buckley is co-founder of QOSES.

Darren Pulsipher is co-founder of QOSES.

Business Modeling, Teenagers, and Primal Scream Therapy

by Christian Buckley & Darren Pulsipher, QOSES

Management of daily interactions with a demanding set of customers, internal or external, can be a time consuming and sometimes frustrating endeavor. An expanding project definition is a battle hard fought. The client wants more gadgets, faster processing time, less back-end management. I don't know about your clients, but mine seem to invite every other software vendor to give a presentation on the latest products -- after which I am buried under a barrage of phone calls and e-mails asking "Can our software do this too?" or "What would it take to add in this functionality?" or even "I've changed my mind about that piece -- I'm really more interested in taking the software in this (new) direction."

Come to think of it, talking to customers sometimes resembles conversations with teenagers. What a fickle lot. How do you talk to a teenager, anyway? That's one of the questions passed down from generation to generation -- and one that may never be completely answered. It seems that each and every day is full of new problems, new adventures, and growing pains. I submit that the same is true with most customers, and I'd like to illustrate these similarities by analyzing four of the most


















prevalent issues affecting most projects (in no particular order): unrealistic timelines, scope creep, funding issues, and changes in technology decisions.

1) Unrealistic Timelines. Customers have been known to make requests with unrealistic timelines. While their intentions may be good, they are often unfamiliar with the process and tools necessary to complete the task, or they may not comprehend the impacts on your scarce team resources. Teenagers, on the other hand, are known to make unrealistic time estimates -- whether it affects your time or their time -- when dealing with such topics as cleaning their room, mowing the lawn, or taking the family car out to "get some gas." In these situations, they clearly do not comprehend (if you're an optimist) or are ignoring (for those of us who are pessimists) the family ground rules.

2) Scope Creep. The dreaded expansion of a product or project where the definition has not clearly been defined and, more than likely, documentation is not being tracked. What usually happens is an agreement is reached on some limited functionality, but as soon as the project is underway, the scope falls under attack. Compare this to teenagers. No matter how clear you are on "house rules" or "family guidelines," teenagers will push definitions of the finer points of your instructions to the legal limit. Don't fall into the all-too-familiar trap of "You said to be home by 10, but you didn't specifically say 10 PM!" Most teenagers find safety in the "gray area" of even the most explicit statements, always expanding the scope of your original intentions.

3) Funding Issues. Customers want a Mercedes, but only want to pay for a Yugo. Who doesn't want the best possible product for the least possible cash outlay? This problem is usually the result of the aforementioned project scope creep. While the project definition gets tweaked, adjusted, expanded, altered, refitted -- whatever you want to call it -- rarely (if ever) is the financial support appropriately expanded. Do I need to even interpret the parallels to teenagers on this point? Let me put it this way -- how many times have we given our teenagers money for work and chores they should be doing anyway (cleaning their rooms, doing the dishes, etc.)?

4) Changes in Technology. One of my major fears is the perceived technological jump amidst a major development effort. Not that I fear change in general, or the wealth of technological leaps and jumps being made in many industries, but customers are often drawn like mosquitoes to a light bulb when a vendor plays the technology card. Even more applicable than the insect analogy is that of teenagers and any consumer

product. They endlessly pursue the latest/greatest toy, gadget, or trinket. Hey, who am I fooling -- this is one problem that extends to all of us. We want the newest car, the latest fashions, and the fastest computer. Why would it be any different with our customers?

Seek First to Understand...

So what does all of this mean? Hopefully my somewhat entertaining depiction of the similarities between customer behavior and teenage behavior illustrates that both of these entities can be demanding, temperamental, and even illogical. Most of us can relate to some of these examples, having lived through them on a number of projects. Now that we've identified some of the major problems, let's discuss the process for obtaining solutions. How do we get past these barriers in communication, allowing us to fully realize our customers' needs and to build software that meets their requirements? Here's the secret -- you need to understand your customers (and your teenagers).

I know what you're thinking -- this is an over-simplified answer to a very complex issue. How does one "understand" a given project? Let me suggest that the answer can be gained through business modeling. The purpose of business modeling is to determine who and what the customer is -- but not necessarily the requirements of the project. The point is to seek to understand the client's perspective, and not make any judgements about possible solutions or what the customer thinks he or she needs. We are not trying to identify the requirements at this stage -- the business model is the 'problem domain' while the requirements are the 'solution domain,' which come later in the development process. Instead, it is critical to know what you are building and why -- and yet this step is often downplayed. In fact, I would venture that business modeling is the most undervalued part of the software development process.

Let me put it to you this way -- a sick man enters a doctor's office with severe pain in his chest and abdomen. The doctor doesn't simply prescribe medicine based on the external symptoms the man is exhibiting. The doctor examines the patient, takes x-rays, and performs blood tests. Only when he truly understands the cause of the symptoms does the doctor assign a prescription. And yet many developers dive right into solving their customer's problems without truly understanding the root cause. Business modeling begins much like that of normal system modeling, but we need to remember the focus is on the current state of the business -- i.e. the problem domain, and not the solution domain.

To further illustrate my point, let's take a look at how most development efforts begin. How often do we start the development of a system with the Use Case Analysis? While this is an integral part of the model, we really are putting the cart before the horse. Instead of thoroughly defining and understanding the customer and their mode of operation, we often create several use cases for what we perceive to be the customers' needs, only to have the customer come back and make changes later down the development cycle. This process of building blindly continues throughout the development of the system unless recognized and corrected up front. The result? Unrealistic timelines. Scope creep. Funding issues. Poor technology decisions. Ultimately, without understanding the business needs behind the system, your company will end up building the wrong product.

"7 Habits" author Stephen Covey hit the right note when he suggested the secret to communication is "Seek first to understand, and then to be understood." To fall back on my original analogy, the process of understanding your teenagers (and your customers) begins with listening. And I mean really listening -- not just to the words that come out of their mouths, but to the meaning behind the words. How often do we lecture our teenagers without actually listening to them first? Think about how easy it is to jump to the wrong conclusions when all of the pertinent data is not before us. As consultants, software developers, and managers, it is our role to anticipate the needs of our customers (as with our teenagers) by looking beyond the words and, like the doctor, revealing the illness behind the symptoms.

Business modeling is a mechanism that guides you through the listening phase of your project, helping you to understand every part of the system being designed and to properly integrate all of the functions. The modeling process helps to organize the information gathered from the customer and/or the users of the system. The Rational Unified Process includes many steps and deliverables that, if met, will start you out in the right direction:

● System Glossary -- This living document establishes a common vocabulary for your project, and, if properly maintained, will prove invaluable to the success of your project. The glossary is developed from common words and phrases used throughout the business, and is regularly updated and revised by modifying use case names to fit those in the glossary, and vice-versa. Sometimes a word can be used to mean several different things -- this should be noted and tracked. Having a common vocabulary will strengthen communication. It is

important that new terms are documented and presented to the customer as soon as possible.

● Use Case Model - This thoroughly describes the functional roles and processes of the current business. Just as in the normal system analysis, the use case model defines the boundaries of the problem by identifying the actors of the problem domain. Although it seems to be fairly simple, this step can take a considerable amount of customer interaction and communication. Don't get into the trap of making the boundary of your system too broad or too narrow. After the actors have been found, begin identifying the use cases that they use in the current system, and the interactions between them. Once use cases have been identified, scenarios need to be developed. Start with the most common scenario for the use case. Each use case should, at the very least, have its most common scenario developed. It is also important to describe the scenarios that you and your customer consider the highest risk. Don't forget to consult and modify the system glossary for consistency.

You may, at this point, find it difficult to keep from jumping into the solution phase. Remember to model the current system, not the future system.

● Class Model - In the previous step of the process we defined the use cases and scenarios of the business and the problem domain. Each scenario has objects and messages between those objects. The next step is to segregate those objects into classes. Many times these objects will be deliverables, documents, or physical things that are currently used by the business and its processes. It may be beneficial to stereotype these classes according to deliverable type. Sometimes, depending on the customer, it may be beneficial to design an icon for the stereotype to aid in communication. Once again -- this should capture what is happening now, not what will happen later.

● Business Specification - Many times customers require documentation for the newly developed model. The business specification is the culmination of all of your efforts to understand -- the System Glossary, the Use Case Model, and the Class Models are the deliverables that define your understanding of the customer and his or her problems. The result of these steps should be a detailed description of what your project or process looks likes today. These pieces are combined into one document and used to convey your understanding to the customer, and, once ratified by the customer, is the foundation of the solution phase of the development effort. Use these to generate a document such that the

customer understands you.

... And Then to be Understood

When focusing on business modeling, the key is to remember that you are not trying to solve the problem outright -- instead, your purpose is to meticulously capture and document the state of the business, therefore revealing a clear picture of the problem your software must solve. Now that you understand the customer and the customer agrees with your assessment of the current state of the system, it is time to work on the second half of Covey's equation -- how to be understood. Basically you go about this with the same level of detail applied to your efforts to understand the system. I highly recommend finding and following a well-crafted methodology and sound software development practices ... a topic for future articles.

More gadgets, faster processing time, less back-end management. Each and every workday can be full of new problems, new adventures, and maybe even one or two adjustments to the technological direction of your company (I'm still clinging onto past demons). The purpose of my customer/teenager analogy was to present the concept of understanding your customers -- and to illustrate that it all begins with listening. (Hopefully I have accomplished this.) Listening is not a problem if you understand the underlying motivations behind your customer requests. If you can identify the current system first, your development efforts will more aptly deal with the unrealistic timelines, scope creep, funding issues, and changes in technology decisions that will inevitably crop up during the project. It would be naïve to think that this method is a catchall for every possible system issue -- but you will find that by taking the time to document the current system up front, many potential problems will be diverted, and your chances for success will increase exponentially.

By the way -- you're probably wondering where the primal scream in the title fits into all of this. Well, all I can say is that every project is different -- with some more stressful than others. For those few projects against which time and space seem powerless, I have found that driving to a remote part of town and screaming at the top of my lungs every once in a while can be very therapeutic. This also applies when dealing with teenagers.

About the Authors

Darren Pulsipher and Christian Buckley are both co-founders of QOSES, a software and process development company based in Tracy, CA. (www.qoses.com) Before QOSES, Darren spent most of his time working as a Software Engineer for Lucent Technologies, while Christian managed Wholesale Services at Pacific Bell Wireless.

In addition to writing articles for Rose Architect, QOSES has created Florist, an add-on to the Rational Rose tool that helps in the development of UML models and the generation of effective documentation. At QOSES, we believe in making software development a logical, manageable, and repeatable process. Our mission is to offer creative leadership, quality solutions, and sound technical expertise to building the future of software development and management.

Back to Contents


http://www.qoses.com/



http://www.mfi.com/

http://www.mfi.com/

http://www.unm.com/

Home


About Rational Rose

About the UML

Jeffrey manages the CORBA and Java product line for Rational Rose. Before joining Rational, Jeffrey consulted on many object-oriented engagements for Andersen Consulting in the pharmaceutical and insurance industry. In addition to Java and CORBA, his interests include design patterns, XML, and an occasional game of golf.

CORBA and Rational Rose -- An Insider's View

by Jeffrey Hammond

One of the newest features in Rational Rose 98i Enterprise Edition is the CORBA add-in. This add-in provides state of the art support for developers who need to develop mission critical systems in heterogeneous environments. In this article, I will describe some of the considerations that went into designing this new language add-in, some of its most compelling features, and will explore future directions in the CORBA world and their impact on Rational Rose.

The Common Object Request Broker Architecture (CORBA) is arguably the most important middleware project ever undertaken by our industry. Led by the Object Management Group (OMG -- the same group who initiated the proposal that resulted in the Unified Modeling Language), the CORBA object bus defines the shape of the components that live within it and how they interoperate.1 Many vendors have released Object Request Brokers (ORBs) that implement the CORBA specification and allow components written in a variety of languages to talk to each other across a distributed network.

The basic function of the CORBA add-in in Rational Rose 98i is to automate mapping between the UML and Interface Definition Language (IDL). IDL is a neutral specification that is used to specify contracts between client and server objects. It is the lingua franca of CORBA-based systems.


















Building a Language Add-In

The first step in building a language add-in is to create a mapping between Rational Rose and the target language. All relevant UML constructs are lined up against all the constructs in the target language (in this case IDL). Where the intent of the constructs are similar (for example, a UML interface and the IDL interface) a direct mapping is made. In other cases (for example, an IDL union) a direct mapping between a target language and UML may not exist. In order to address this gap, the UML provides a number of extensibility mechanisms, including Stereotypes and Tagged Values. The CORBA language add-in uses both of these mechanisms to fully map the constructs articulated in IDL.

With a completed mapping, the development team uses the Rational Rose Extensibility Interface (REI) to build the language add-in. This approach provides an extreme amount of flexibility for implementation. To date, language add-ins for Rose have been implemented in Rose script, VB, Java, and C++. While the previous IDL add-in was written in an older proprietary scripting language called Code Mapper, the new CORBA language add-in was implemented entirely in C++ to facilitate performance and portability across all platforms that Rose supports. While the Rose 98 add-in will still be available on the web on the Rational Rose owner's page, the new Rose 98i add-in will supersede it.

CORBA Language Add-In Features

The CORBA language add-in supports the most current revision 2.2 of the CORBA specification (www.omg.org/library/specindx.html). While all features and benefits are documented in the help files and product literature, there are a few items that deserve special mention and explanation here.

CORBA Stereotypes -- The CORBA language add-in introduces the following stereotypes:

Stereotype Element Purpose

<<CORBAModule>> Package Use to map model structure to IDL structure, while avoiding namespace conflicts.

<<CORBAConstant>> Class Makes a UML class an IDL constant

http://www.omg.org/library/specindx.html

<<CORBAEnum>> Class Makes a UML class an IDL enum

<<CORBAException>> Class Makes a UML class an IDL exception

<<CORBAStruct>> Class Makes a UML class an IDL struct

<<CORBATypedef>> Class Makes a UML class an IDL typedef

<<CORBAUnion>> Class Makes a UML class an IDL union

All mappings are self explanatory with the exception of the <<CORBAModule>>. While an IDL module could have been mapped directly to a UML package, a stereotype was chosen for two reasons. First, a stereotype allows a developer to use a structure of packages and subpackages in the Rose logical view to best categorize and abstract a model. This structure is not necessarily the structure that is desired for the IDL modules when they are generated. Since module statements will only be generated for packages that are stereotyped, the logical and physical mapping of IDL modules in a Rose Model can be distinct. Second, many Rose models that use IDL also have elements targeted towards a second language like Java or C++. A common usage scenario is to define a class in IDL, generate it, and use an ORB's compiler to create C++ or Java interfaces, stubs, and skeletons. The developer will then reverse engineer these classes into the same Rose model. In many cases the generated Java or C++ interfaces will be named the same as the IDL class, which can result in cross-language name conflicts. Using the <<CORBAModule>&gr; stereotype allows a developer to place all IDL constructs in a subpackage, thus avoiding namespace clashes. (See Figure 1.)

New Specification Windows -- One of the key new features in Rational Rose 98i is the capability for language add-ins to override the standard Rose specification windows. While the standard specification window is functional, it uses a least common denominator approach to support multiple languages. In Rational Rose 98i, many language add-ins have built specification windows that are targeted toward a specific language. This is true for the CORBA add-in. In particular, you will notice that different specification windows are presented depending upon what CORBA stereotype a UML element has. The result is that the CORBA language add-in can present specifications that incorporate terminology specific to IDL. In addition, it simplifies the implementation of tagged values for CORBA. For example, a CORBA constant requires a specific implementation type. This is mapped by the CORBA language


add-in to a UML tagged value called ImplementationType. If you open the Rational Rose standard specification window for a class that is stereotyped as a <<CORBAConstant>> and select the CORBA tab, you will see a number of UML tagged values, including ImplementationType. Contrast this with the custom specification window designed for CORBA constants. It presents only relevant information, expressed in CORBA-specific terminology. The base UML mappings and the extensions to it are presented in an identical manner. The result is ease of use and greater productivity. (See Figure 2.)

Reverse Engineering of IDL -- One of the key values of language add-ins in Rational Rose is that they support the concept of iterative development. In order to fully support this concept, it is important to represent existing language artifacts in a Rose model. This is accomplished by allowing a developer to "reverse engineer" an existing IDL file. Reverse engineering is a new feature in the CORBA add-in. Like the Rational Rose J language add-in, the CORBA language add-in uses a parser-based approach. A language grammar was developed based on the CORBA 2.2 specification. This grammar is used to produce a parser, which is then integrated with an IDL-UML mapping component. This is a similar approach used to build most language compilers. While the approach is complex, many long-term benefits accrue from this approach. As we look forward to future versions of the CORBA language specification, it is likely that changes will occur. A grammar-based parser approach is relatively easy to maintain and extend. The result is that the time required to support language changes is reduced. In addition, developers can use the CORBA language add-in with any ORB that complies with the CORBA language specification. When an IDL file is reverse engineered into Rational Rose, it is mapped to the corresponding UML constructs. The resulting UML constructs are added to both the Logical and Component View as appropriate. While this process defaults to a one-to-one logical to physical mapping, a user can then change the structure of the packages in the Logical View to suit their needs.

Browsing IDL -- One popular feature in Rose is the capability to select a UML element and browse the associated language artifact. For some language add-ins (VB, VC++), the choice of browser is obvious. When using CORBA language add-in, developers have a choice of using their own editor or the built-in editor provided with the CORBA language add-in. The built-in editor is color-coded for IDL, and is enabled upon installation. To use a different editor, select Project Specification from the Tools:CORBA menu, and under the Detail tab change the Editor setting from "BuiltIn" to "WindowsShell". When you browse a CORBA objects, the CORBA language add-in will examine the Windows registry, find the application associated with the IDL


file extension, launch it, and pass the location of the IDL artifact.

Future Directions -- While the CORBA 2.2 specification has proved very successful, the CORBA movement is still evolving, and there are new developments on the horizon that will impact how developers will use Rose. Two of these efforts are the CORBA component model and the Meta-Object Facility (MOF). The CORBA component model effort is designed to enhance CORBA with the features required to design, develop and manage robust interoperable components. Features such as introspection, statefulness, and transactability will enable CORBA system features similar to Enterprise JavaBeans™ and DCOM components, as well as provide interoperability with these component models. As more commercial tools support the MOF specification, developers will want to use Rational Rose models to import and export model objects with MOF-based repositories. While it is difficult to predict the future of these efforts, they bear close watching, as they have the potential to significantly impact the way CORBA developers work, and the way they use Rose. Of course, the primary driver for future features in the CORBA language add-in is customer input. We encourage any feedback you may have on the Rational Rose98i CORBA add-in.

Footnotes

1. Robert Orfali, Dan Harkey, Jeri Edwards. Instant CORBA. John Wiley & Sons, Inc. New York, 1996.

Back to Contents




http://www.mfi.com/

http://www.unm.com/

Home


About Rational Rose

About the UML

jim conallen is an object evangelist and self proclaimed Rose zealot.

Creating Your Own Rose Add-ins with Visual Basic

by jim conallen

If you've used Rose for a while, you're probably familiar with add-ins. A Rose add-in is an ActiveX DLL invoked through the Tools menu that can interact with the model to do things like generate code, compute metrics, prepare documentation and even reverse engineer existing code. It makes Rose a very extensible tool.

Creating your own simple add-in is surprisingly easy, requiring only a compiler that can create ActiveX DLLs. I'd like to show you how to create Rose add-ins with Visual Basic 5. This article is not intended to be a discussion on creating industrial strength add-ins for resale. Rational's RoseLink program is the avenue for companies interested in building commercial add-ins. This is intended for Rose power users.

The idea for the add-in came after many hours of working with class diagrams. I usually compose my diagrams in a certain style, where enumeration classes are colored and have suppressed attribute and operation compartments. For some classes I like to show all attributes and operations, especially if the diagram focuses on the class. Doing this via the Rose Edit menu can be tedious, especially when the defaults are set differently. To make life easier, I've created an add-in called Rose/Style that stores sets of display styles which can be applied to classes in a diagram.

Using the add-in is easy; select some classes in a class diagram and then select the add-in from the Tools menu. The add-in displays a small dialog box with a list of previously defined


















styles. Double clicking on one will apply the style to the selected classes.

To create a Rose add-in with Visual Basic there are only three things you have to do:

1. Create an ActiveX DLL with a public interface and sub that accepts a RoseApplication object reference as a parameter.

2. Add a few entries in the Registry to let Rose know about the new add-in.

3. Create a menu file that calls the add-in from the Tools menu.

Of course being a good Rose user, you realize several important parts are missing; define requirements, model the domain, build a use case model, etc. For the sake of brevity we'll forgo some of these and dive right into design and implementation.

One word before we continue. Building Rose add-ins will make you very familiar with the Rose Extensibility Interface (REI). The REI is the public interface to the Rose meta model, and your key to manipulating and extracting information about the model. If you've already created scripts you'll notice that the class names of REI objects look different. As a general rule when accessing the REI from VB all classes begin with the word "Rose". So if you've written a Rose script that uses a ClassDiagram object, the corresponding REI object in VB would be RoseClassDiagram.

Create ActiveX DLL

When Rose activates an add-in, it creates an instance of the ActiveX component and invokes a method on it, passing it a reference to the RoseApplication instance. This instance represents the application itself. Calling the RoseApplication's CurrentModel method returns a reference to a RoseModel object. This object is the main container object of all the elements in the currently loaded model file. Through it we have access to all the classes, associations, and diagrams of the model.

To start I created a new ActiveX DLL project with Visual Basic 5. The wizard creates a single class and names it Class1, the project is named Project1. I renamed these IRoseStyle and RoseStyle respectively. I set the instancing property of the class IRoseStyle to MultiUse. A reference to the Rose type library must be set via the Projects|References menu item in order to get those drop down hints when coding and to enable type

declarations of Rose automation server objects. (You must have Rose installed on the development machine to do this.)

Next I added a Public Sub to the class IRoseStyle and named it SelectStyle. It accepts a single parameter of type RoseApplication, and is the method invoked when the add-in is selected from the Rose menu.

I then created a new form called frmSelectStyle. To begin with I added two buttons, Apply (cmdApply) and Close (cmdClose), and a list box (lstStyles) to the form. (Figure 1) Finally I added a click handler to the Close button that unloads the form.

Back in the Sub SelectStyle, I added some code that let me test the architecture. This let me ensure that my development environment was set up properly and that all the pieces were working. It also gave me a warm, fuzzy feeling that everything was fine. The code just displays the names of all the currently selected classes in the list box.

The code to do this is simple (see below). First I got a reference to the model instance, and then asked it for all the currently selected classes. This was returned to me in the form of a specialized collection object. One nice thing about the REI is its consistency. Every operation that returns a collection of something always does so in the form of a specialized collection object whose name ends with the word "Collection." Iterating over the list I added each class's name to the list box. Finally I told the form to show itself. The form must be opened with the vbModel parameter. Writing an add-in is that simple!

Public Sub SelectStyle(aRoseApp As RoseApplication) Dim mainFrm As New frmSelectStyle Dim Model As RoseModel Dim SelectedClasses As RoseClassCollection Dim aClass As RoseClass

Set Model = aRoseApp.CurrentModel Set SelectedClasses = Model.GetSelectedClasses

For i = 1 To SelectedClasses.Count Set aClass =SelectedClasses.GetAt(i) mainFrm.lstStyles.AddItem aClass.Name Next i

mainFrm.Show vbModal

End Sub

Update the Registry


Next, update the registry to let Rose know about the new add-in. I used regedit to create the necessary entries and exported them to a file so they could be easily entered again. I named the file RoseStyle.reg (see below). The reg extension tells Windows that this file contains registry entries. Double clicking on this file will automatically create the necessary keys and values in the registry.

REGEDIT4[HKEY_LOCAL_MACHINE\SOFTWARE\Rational Software\Rose\AddIns\RoseStyle]"Active"="Yes""InstallDir"="C:\\Program Files\\DevStudio\\VB\\Projects\\RoseStyle""MenuFile"="rosestyle.mnu""OLEServer"="RoseStyle.IRoseStyle""Version"="1.0"

You may want to examine some of the registry entries of other Rose add-ins with regedit to get a feel for what information is appropriate to keep there.

Each entry in the registry has a purpose:

Active A yes indicates that this add-in should be enabled in the Rose Tool menu. (It also indicates that the add-in should receive special event notifications when Rose starts and stops).

InstallDir The directory where Rose can find the menu file. (The double slashes in the directory is just because REG file entries use it as an escape key. If you enter in this value from regedit they don't need to be there.)

MenuFile The name of the file with the menu commands. This file specifies the menu entry name for the Tools menu, and the method to invoke in the automation server.

OLEServer The name of the registered automation server (ActiveX DLL) and the name of the interface to associate with this add-in. This is also called the ProgID.

Version The version to display when the user requests the list of known add-ins.

Create a Menu File

The last step is to create the menu file. Rose allows you to augment the menu system with custom items that invoke compiled Rose scripts or add-ins. To include Rose/Style in the menu I created a menu file called RoseStyle.mnu. This is a simple text file containing the following:

Menu Tools{ Separator option "Select &Style" { InterfaceEvent RoseStyle SelectStyle }}

Most of this file's syntax should be obvious. The InterfaceEvent keyword tells Rose that this item represents an add-in which is specified in the registry under the AddIns key. The parameter RoseStyle indicates the name of the subkey under AddIns where the name of the automation server (OLEServer) for the add-in can be found. The menu file should be placed in the directory specified by the InstallDIR registry entry, and must have the name specified by the MenuFile entry.

First Test

Once the VB project is compiled, the menu file created, and the registry updated, everything is ready for the test. Successfully compiling this project will automatically register the automation server. If all went well, then the Rose Add-in option should be available in the Tools menu the next time Rose is started. If the menu is not there check the Log for any errors. Most likely the trouble will be either the values in the registry or the placement of the menu file.

To test I started Rose, loaded a test file and invoked the add-in from the tools menu. Invoking the add-in produces a simple form with the names of all the classes currently selected in the model. If you are familiar with the REI and VB this should be all you need to get started on your own Rose add-in.

The Real Work: Design

The next step is to actually design and build the add-in. First I reverse engineered my existing code into a Rose model. I created three packages in the Logical View to represent the user interface, business objects and persistence utilities, and relocated the form and IRoseStyle classes appropriately. (Figure


2)

I created the Utils package because I knew that I'd need to wrap a few of the Win32 Registry API's not directly accessible in Visual Basic.

Finally it was time to design the guts of this add-in. After only a few rounds of iteration I created a simple business object model with three classes. (Figure 3)

The central class is ClassStyle; representing a set of display, stereotype, and property set values that can be applied to a selected class in a Rose diagram. Its Apply method accepts a reference to a RoseClassView instance. The RoseClassView object has the methods and properties to set the view options.

If the class style specifies that the stereotype or tool property set should also be applied, then these are applied to the view's underlying RoseClass object, and not the RoseClassView. A RoseClassView object represents a class icon in a diagram, not the class itself; the stereotype and property set belong to the RoseClass object. The RoseClass is accessed with the Item property on the RoseClassView. The following code in the Apply method sets the class's stereotype:

If SetStereotype Then aClassView.Item.Stereotype StereotypeEnd If

SetStereotype is a Boolean indicating the stereotype should be set (not every style sets the stereotype), aClassView is an instance of RoseClassView and Stereotype is a string containing the value of the stereotype.

ClassStyle also contains two collections of PropertyStyles. A PropertyStyle is just a wrapper around two strings; a tool name and a property set name. The PropertyStyles aggregation represents a VB Collection of ProperyStyle instances that should be applied to the RoseClass. I added a second collection of PropertyStyles to cache property sets the user wants deleted from the ClassStyle (and removed from the registry) when the dialog box closes. I used a separate collection instead of immediately deleting them; allowing the user the option to abort the operation (by pressing the cancel button).

Managing the lifecycle of ClassStyle instances is a StyleRegistry object. It has methods like CreateNewStyle and RemoveStyle. It also has a method to return all previously created styles:



GetAllStyles. Begging forgiveness from the object purists, I decided to have this object also hold the collection of Rose tool names and valid property set names for each tool that can be applied to Rose class objects. I designed these three classes exclusively with Rose, and forward engineered them into my project.

The User Interface

Designing a user interface is much easier to do with VB than Rose. I added a few more buttons to the frmSelectStyle form and created another form allowing the modification of ClassStyle's properties. I also added a dialog form prompting the actor for a style name when creating a new style, and created a separate form allowing the actor to select a specific property set for a given Rose tool. I reverse engineered the forms, created a diagram, and added some dependency associations to express the relationships between these forms. (Figure 4)

The first form displayed is frmSelectStyle: the one I started the project with. In the final iteration the list box is filled with available ClassStyles. It also has buttons to: apply a selected style to selected classes, close the add-in, display the help file, create new styles, modify a selected style, and behind a picture control with my company's logo in it, display an about box. Figure 5 shows the final dialog.

The only other form with significant behavior is frmModifyStyle. It's a tabbed dialog with controls to set all the options of the ClassStyle. The first tab (Figure 6) controls the ClassStyle's view options (formatting commands that apply only to the selected view in the Rose class diagram).

The second tab (Figure 7) modifies the stereotype and property sets. Since each tool can have its own property set, I created another dialog allowing the actor to select the property set for that tool.

Implementation

I'm the kind of programmer that likes to test things early and often, so I created a Sub Main in a new module unit testing. I also changed the VB project to a Standard EXE instead of an ActiveX DLL, and set the start up function to be Sub Main. The main sub contains code to create and display a new instance of Rose. The code continues on to load a test file that I had previously prepared, and selects all the views in the first class





diagram. Next I created an instance of the IRoseStyle interface and called it SelectStyle method, passing it the reference to the RoseApplication instance. This simulates the calling of the add-in, only now in the context of the Visual Basic IDE. Typically I set a break point and walk through the code I'm interested in. The following is the code of my Sub Main:

Public Sub Main() Dim theIRoseStyle As New IRoseStyle Dim aRoseApp As New RoseApplication Dim theModel as RoseModel Dim ClassDiagrams As RoseClassDiagramCollection Dim RootCategory As RoseCategory Dim ItemViews As RoseItemViewCollection Dim anItemView As RoseItemView Dim i As Long

aRoseApp.Visible True ' =forces the Rose ' application to be displayed this is helpful ' when keeping track of active instances aRoseApp.OpenModel "d:\projects\RoseStyle\ test.mdl"

Set theModel = aRoseApp.CurrentModel Set RootCategory =theModel.RootCategory Set ClassDiagrams = RootCategory.ClassDiagrams Set ItemViews = ClassDiagrams.GetAt(1).ItemViews For i = 1 To ItemViews.Count Set anItemView = ItemViews.GetAt(i) anItemView.SetSelected (True)=

Next i

theIRoseStyle.OpenStyleSelector aRoseApp

aRoseApp.ExitEnd Sub

With this Sub I can easily start debugging the add-in from within the IDE. Towards the end of implementation I changed the project's settings back to ActiveX DLL, unset the starting function, and re-set the IRoseStyle instancing property to MultiUse for my final testing.

My main purpose in creating Rose/Style was to present a non-trivial example of how to create a Rational Rose add-in. In the end I was surprised at how much time was spent on the management of the user interface, over working with the REI. Coding event handlers, and wrapping the Win32 registry APIs turned out to take the most effort. Once a good degree of familiarity with the REI is established, creating a Rose add-in is no more difficult than any software application.

Downloads:

rosesetup.zip is an install program that installs the already compiled add in on a Win95/98/NT computer. It works with both Rose 98 and Rose 98i.

rosevbsrc.zip is a zipped copy of all the source code for the add in, and the Rose MDL file.

About the Author

jim conallen is an independent consultant with Clarity Development, LLC and specializes in full life cycle object oriented and web application development. In addition to working with Rose and building add-ins to make his life just a little easier, jim has been concentrating on developing a set of UML extensions for web applications. The most important things in jim's life are his wife, two sons, and his sailboat; a 23 foot Hunter (which by the way is up for sale). Jim can be contacted at [email protected].

Back to Contents


http://www.therationaledge.com/rosearchitect/db_area/rosesetup.zip

http://www.therationaledge.com/rosearchitect/db_area/rosevbsrc.zip




http://www.mfi.com/

http://www.unm.com/

Home


About Rational Rose

About the UML

Beth Leek, Process Leader, ARINC Incorporated

Scott Frohman, Technical Representative, Rational Software

Real-Time System Architecture Comes Alive

by Elizabeth Leek, ARINC Incorporated; Scott Frohman, Rational Software

Contrary to popular belief, elves do not come in to empty airplanes, bringing fresh supplies of peanuts and tiny bottles full of alcohol. Information about such detail is, like everything else these days, handled far more efficiently than by relying on something as unpredictable as elves. Better by far to trust the future of your individual bottle of vodka to a new global messaging system being developed by our project team at ARINC Incorporated. To make sure we correctly develop this system (which, by the way, does a bit more than manage snack supplies), we're using Rational Rose, UML, Rational RequisitePro, Visual C++, the PRISM PSOS embedded development environment, and Rational SoDA.

As a project leader (Beth) and project consultant (Scott), we are enjoying being a part of this mission-critical, complex system that will touch the lives of so many people. A lot of important technologies and concepts are coming together to ensure the success of this momentous project: real-time/embedded development, visual modeling, software and system architecture, effective requirements management, and


















effective team development.

ARINC Incorporated is a $300 million company with a corporate history of serving customers in aviation, government, and other industries, since 1929. Employing more than 2,200 people at our headquarters in Annapolis, Maryland, and at over 50 operating locations worldwide, ARINC is owned by airlines and aircraft operators both in the United States and internationally. Our list of owners includes all major US airlines. The five business units of ARINC support two major focuses: communications and information processing services for the aviation and travel industries; and systems engineering, development, and integration for government and industry.

The project currently under development by ARINC is designed to allow aircraft to communicate with ground control and airline services (mmm, where those little vottles of bodka come from), and will be extensible enough to accommodate increasing traffic through the year 2020. The operational system will, at completion, be composed of the ground-based hardware, communication protocols, and the management infrastructure that will allow users to access this service.

The system design decomposes the overall system into domains, areas of functional breakdown created for the purpose of managing complexity and providing modularity. These domains focus on areas like the air-to-ground data link, subnetwork connectivity for aircraft to attach to, monitoring and management of the links between aircraft and ground stations. We must deal with architectural challenges such as creating a design where network parts can be replaced as new technology becomes available. We also need to provide a means for the existing messaging systems to pass messages over our new network.

Our project has benefited greatly from the flexibility of the UML and Rose. Both have accommodated our atypical real-time development dynamics quite well. Both have been effectively leveraged to help define and communicate our system infrastructure as well as dynamic system activities.

The main objectives in using UML and Rose were to effectively communicate both the system architecture and software architecture, capture the detailed design, generate C++ code, and capture 70% of the documentation. The final documentation will be fully automated using Rational SoDA.

The target processor for each domain is an embedded Motorola board. Each board is capable of running one executable. Each

domain will consist of the software executable configured to provide the necessary functionality, the hardware to support it, and the network elements necessary for inter-domain communications. We needed three views into our system architecture. The first view, the Operational view, would portray the interactions necessary between domains to complete a set of sequential interactions. The second view, the Inter-Domain Protocols View, would convey the protocols used for communication between domains. The third view would be the System Level Use Case view containing traditional use cases and their related scenarios.

Operational View

The first view, the operational view, conveys the sequential, inter-domain interactions needed to complete end-to-end system threads through the system. Each single, unconditional thread through the system is called an operational scenario. There would be one or more operational scenarios related to each system level use case. A UML class is used to represent each of the domains. This system view, it was decided, would not constrain the software architecture.

An initial study of the operational scenarios to be completed for the first iteration revealed many reusable interactions within the operational scenarios. For instance, the following interaction is used in more than 15 different operational scenarios:

1. Aircraft stimulates a domain by sending a request.

2. The stimulated domain responds to the aircraft.

3. The stimulated domain (Domain A) notifies the domain responsible for request management.

The system gurus determined that if the operational scenarios were broken down to a domain-centric sequence of events, called operational sequences, these operational sequences could be used across multiple operational scenarios. Domain-centric is one of those overloaded terms that simply implies that each operational scenario is centered around one domain. The activity contained in an operational sequence is contained to one domain. A stimulus from a separate domain triggers the operational scenario, and the response will be delivered to either the stimulating domain or to a third domain. For example, in Figure 1, the operational sequence is centered around Domain A. The aircraft domain provides stimulus to the domain, and the stimulated domain responds to the aircraft and forwards information to the domain responsible for request


management. This operational sequence can be used in many operational scenarios. The goal is to maximize reusability and minimize maintenance costs in the system architecture. Thanks to this approach, we can specify a boatload of comprehensive interactions in our system using the approach of joining these reusable "interaction pieces." Design patterns and reuse opportunities present themselves naturally throughout the process of identifying these partitioned operational sequences.

The operational sequence "Domain A responds to Aircraft Stimulus" is used in multiple operational scenarios. Each operational sequence is captured on a sequence diagram and related to a use case. The operational scenario is shown through a use case diagram that links the appropriate operational sequences together to form an end-to-end system thread. Since each operational sequence is unconditional, the operational scenario diagram becomes a sequential, unconditional end-to-end thread. The operational sequence in Figure 1 is called OP_Seq_Domain A_001:Domain A responds to AC stimulus (you know our work is impressive because of these long, fancy names). Figure 2 shows an operational scenario using the operational sequence in Figure 1.

A UML use case icon represents each operational sequence, fully modeled in a UML scenario diagram. Each operational scenario has an accompanying description to spell out what's going on, kind of like a system-level flow of events. Each operational sequence also has its own document, used to describe what happens in the domain during the sequence.

The browser structure of the sequences and scenarios is shown in Figure 3.

We chose to use the sequence diagrams because they offered the flexibility we required to achieve our modeling goals. We wanted to show sequential processing, but we also needed to use a component-based approach to modeling our system threads of activity. This approach let us illustrate system-level interaction without impinging on the namespace of our model while enjoying the modeling benefits of visualization, team participation, and reuse due to our modular approach.

We wanted a joint focus on the software and system aspect of architecture. An added benefit of using Rose to capture this section of the system architecture was it engaged the system engineers in the use of Rose along with the software engineers. This allowed our system engineers to become comfortable with the environment and process by which the rest of the system would be developed.





Inter-Domain Protocols View

The second view, the Inter-Domain Protocols View (IDPV) of the system architecture, portrays the protocols that will be used between domains. When an aircraft communicates to an Air/Ground Router (located in Domain B), it uses a standard avionics protocol to communicate with Domain A. Domain A then uses a proprietary protocol to create a virtual link between the aircraft and Domain B. Subsequent communications from that point may involve further changes in protocol. This profoundly heterogeneous protocol environment demands a thorough understanding of who's talking what to whom. We also need to track who initiates communication and where one-way communication occurs. The directionality of the dependency relationship indicates that. The Rose component diagram is used for this view as shown in Figure 4.

We also expect that these protocols will change as new, more efficient protocol technology is developed. In addition to allowing system architects to specify which domains need to utilize the protocols available, we can track the history of what protocol was used between a set of domains.

System-Level Use Case View

The third view, the System Level Use Case (SLUC) View, is the driving force of our system-level planning and modeling efforts. The SLUC scenarios that are defined in this view are the drivers for each iteration. This view involves use cases, interaction diagrams, and textual (Word) documents.

Much as in traditional use case modeling, these use cases portray interactions between external actors and the operational system. This is a "black box" view of the system. The main flow of events, exceptions that may occur, and alternative processing are all documented for the use case. A list of possible scenarios is then defined. Each scenario presents a single path through the use case; it shows a particular combination of conditions, choices, and possibilities that could occur within the context of the use case. Each use case is represented in the Rose model (as the Use Case Template as shown in Figure 5) and the Word file is linked to the use case in the model. There are still software-level use cases to be developed for each domain. At this point, we are only talking about use cases that model system-level interaction.

To provide a means to visually model the SLUC scenarios, we again used sequence diagrams in the Rose Model. This time, we



used them for their original intention. One or more sequence diagrams were created to model the interactions necessary to support the system-level use case. The classes identified during this process are to be the basis for the software interface classes, as this is an architecture effort and not detailed software design. This is a coordinated effort between system architects and software architects and is the first step in the migration from system to software architecture. Figure 6 provides a sample SLUC scenario interaction diagram for Use Case 10010 Aircraft Establish Link.

The foundation is now laid for continued work, where a system-wide framework has been constructed. There remains to be put into place software architecture for each domain, one that will allow the responsibilities of the domain to be carried out in a robust and reliable manner. One that will permit change as the system evolves over the next two decades. One whose design is not biased or impeded based on the system architecture created using the techniques discussed here. But that's another article.

Rational SoDA

The project aim is to have at least 70% of the content for the final documentation in the Rose model itself. Therefore, as much documentation as possible is put into the Rose model for the operational scenarios and operational sequences. SoDA templates are used to generate model review documentation as well as meet our documentation deliverables. These generated review documents are then linked to elements within our model via Rose's file link capability in the specification dialog.

The flexibility of Rose and UML enabled the project to produce independent software and system architectures that are proving to be robust, understandable, and maintainable. The project realized a great return on our Rational investment by using Rose to model a complex system architecture, something not typically available in software modeling tools.

The model-level reuse the project is enjoying, helps to ensure that the next time you imbibe a bit too much on the plane, the vodka refill order will make it from the aircraft to ground services safely. Not to mention safe delivery of your captain's flight path.

About the Authors

When she is not tending to her farm and two children, Beth Leek defines software processes and implements software architecture. She has nine years experience with the Rational


Tool suite, starting with the R1000 dinosaur. She has spent time consulting and teaching in SEI CMM and Object Orientation. Beth can be reached at [email protected].

Scott Frohman is a Rational technical representative, consulting and mentoring his clients in areas such as process and project management. Prior to joining Rational, Scott spent his time managing and performing software development on telecommunications and DoD projects and playing with matches. Scott can be reached at [email protected].

Back to Contents






http://www.mfi.com/

http://www.unm.com/

Home


About Rational Rose

About the UML

Kevin E. Kelly is an Account Executive at Rational Software in Denver, Colorado. Kevin has been with Rational for over three years and has been a Technical Representative and District Technical Lead. Kevin holds a B.S. in Computer Science from Mercer University and a Masters in Administrative Science from the University of Montana. He can be reached at [email protected]

User-Defined Tags with Rose 98 Scripting

by Kevin E. Kelly

One of the best features of Rose is its adaptability. For example, the creation of user-defined tags is a highly desirable feature that isn't exactly available out of the box with Rose 98. However, through the versatility of Rose scripting it is possible to associate anything, including names, numbers, requirement identifiers, or labels, with an individual Rose model element. This can then be permanently added to the Rose model. The flexibility of the scripting language lets you add unique attributes to any Rose modeling element, enabling you to further customize your Rose model to fit your individual needs.

To illustrate this functionality, let's examine a script that can be used to create user-defined tags. Once the tags are created, you can attach them to Rose model elements and save them in the model. This script was developed completely within Rose Script and uses the Rose 98 extensibility features provided by the API to gain access to, or to add and/or modify, the user-defined tags of the Rose model elements. Once the tags are part of the Rose model and are associated with specific Rose model elements, these tags can then be reported or queried upon and can also serve as the basis for an integration to other tools. This particular script lets you attach tags to packages, use cases, classes or actors, attributes, operations, and associations. In addition, some simple reporting to the screen, to Microsoft Word, and to Microsoft Excel, are provided as well as a simple query for finding which Rose Model elements are currently mapped to a given tag.



















What does the script do?

The script displays a single screen which allows you to enter and edit tag content while navigating the Rose model through drop list boxes. Navigating the model is done by first selecting the package you want in the Packages drop list box (the default package is that which appears alphabetically first in the list). When a package with use cases is selected, the use cases are then displayed in the Use Cases drop list box and the Classes or Actors drop list box will list the actors. If the selected package has classes in it, then appropriate classes, attributes, operations, and associations are listed. If a package is selected without use cases in it, then the Use Cases list box is empty.

The example in Figure 1 shows a package (Enterprise) and the attributes, operations, and associations, of the currently selected class (Employee) with the values of the associated tags in the Tags field.

A Rose modeling element may have a user-defined tag such as the name of the developer responsible for maintaining it. It is also possible to attach requirement identifiers to attributes, operations, and associations. In fact, this tag mechanism can be used to attach any text that is not appropriate for the documentation text window, or that you may want to report or query on later. If an unnamed association exists, then it will appear in the Associations drop list box with a blank name. If more than one unnamed association exists, then more than one blank selection will appear in the drop list box - so this script works best when you have named all of the associations to which you wish to attach tags.

When the appropriate tags have been entered, the OK and Apply buttons behave the same as they do in Rose. If you want to continue entering tags for other modeling elements then simply hit Apply to save the current changes and use the drop list boxes to navigate to the next relevant item.

The Query button presents a small dialog (Figure 2) that asks you to enter the text of the tag you're searching for. If your tags have unique text, then you can type in that text; if not, you can enter any string and all Rose model elements with tags attached to them will be searched for a match. Only matches will be displayed.

The query will find all occurrences of the text entered in the query dialog, including embedded matches. Entering "Wally" in Figure 2 yielded the results in Figure 3. (All query results are





piped to the BasicScript ViewPort window.)

The Report buttons list all Rose model elements with or without tags attached to them in one of three output options: the BasicScript ViewPort window (To Screen), in a new Microsoft Word document (To Word), or in a new Microsoft Excel spreadsheet (To Excel). In all three reports any Rose model element that does not have a tag defined will report with <Undefined>. A Microsoft Excel example of this can be seen in Figure 4. When reporting to Microsoft Excel, a new cell is created for each comma-delimited entry in the requirements entry field. This works well for numbers, labels, or identifiers, but may not make much sense for long textual tags.

How does the script work?

The navigation capability through the drop list boxes is straightforward and uses string arrays loaded with the appropriate Rose model elements in loops using the GetAt() operation. Each time a change is required (i.e. you select a new package which means that the class, attribute, operation, and association drop list box arrays must be updated) the string arrays are redimensioned and reloaded for display and selection from the dialog.

Dim AllClasses As ClassCollectionSet AllClasses = dlg.CurrentPackage.GetAllClasses()If dlg.CurrentPackage.Classes.Count > 0 Then ReDim AllClassNames$(dlg.CurrentPackage.Classes.Count - 1) For i% = 1 to dlg.CurrentPackage.Classes.Count AllClassNames$(i% - 1) = dlg.CurrentPackage.Classes.GetAt(i%).Name Next i% ArraySort AllClassNames$Else ReDim AllClassNames$(1) AllClassNames$(0) = " "End If

The tags that are added and retrieved from the Rose model elements use two simple operations: SetStringPropertyValue() and GetSingleProperty(), as seen in the following code. The argument theRose Item is of type RoseItem. This is compatible with Category, Use Case, Class, Attribute, Operation, and Association types, so these routines can read from and write to any of these types. The argument theSingle Prop is the name of the property, in this case Tag. The argument theValue for the set procedure is the


actual value of the tag; its value is what is returned by the get function. The set operation will overwrite any existing property with the same name or add a new one if the property does not exist.

Private Sub SetStringPropertyValue(theRoseItem As RoseItem, theString As String, theValue As String) Dim prop As Property Dim bAdded As Boolean Set prop = theRoseItem.FindProperty(ToolName, theString) If prop Is Nothing Then bAdded = theRoseItem.CreateProperty(ToolName, theString, theValue, "String") If bAdded = False Then WriteWarning("Cannot create property " & theString) Else If Not theRoseItem.OverrideProperty (ToolName, theString, theValue) Then WriteWarning("Cannot override property " & theString) End If End If Else If Not theRoseItem.OverrideProperty (ToolName, theString, theValue) Then WriteWarning("Cannot override property " & theString) End If End IfEnd SubFunction GetSingleProperty(theRoseItem As RoseItem, theSingleProp As String) As String GetSingleProperty=theRoseItem.getpropertyvalue(toolname, thesingleProp)End Function

A call to the SetStringPropertyValue function looks like this:

' Sets tag value of class from string SelectClassTagCall SetStringPropertyValue (dlg.CurrentClass, SingleProperty$, dlgText$("SelectClassTag"))

The additions made to the Rose model look like this in the model (.mdl) file:

(object Class_Category "Enterprise" attributes (list Attribute_Set (object Attribute tool ""

name "Tag" value "Dilbert"))

Script requirements and comments

This script requires 1024 x 768 or higher resolution and does not contain any scroll capability in the dialog it presents. Be aware that the added properties are not visible as code generation properties. Also, as the report generated into Microsoft Word is not elaborate it may require some modification to make it suitable for a specific organization, process, or standard.

The ability to add user-defined information, or tags, to any Rose modeling element and then query and report on it demonstrates the power of extensibility in Rational Rose 98. The flexibility inherent in Rose's built-in scripting capability and its completely documented extensibility interface makes developing project specific scripts easy and efficient. I urge you to explore the Rational Rose 98 Extensibility Reference Manual and this script to see how easily you can customize your Rose models. This script can be downloaded from the Scripts and Models section.

Back to Contents


http://www.therationaledge.com/rosearchitect/db_area/Tags98.ebs



http://www.mfi.com/

http://www.unm.com/

Home


About Rational Rose

About the UML

Michael Blaha, OMT Associates, Inc.

William Premerlani, General Electric R & D

Using UML to Design Database Applications

by Michael Blaha, OMT Associates, Inc.; William Premerlani, General Electric R & D

Our previous article1 presented a systematic approach to choosing a data store for data-intensive applications. There are various alternatives including in-memory storage, files, object-oriented databases, and relational databases. This article shows how to implement UML models with relational databases. We assume familiarity with the UML object modeling notation and relational databases.

1. Introduction

Many persons assume that object-oriented concepts and relational databases are at odds with each other and do not fit together. The reality is quite to the contrary! With skillful use, a relational database can provide an excellent implementation for object-oriented (OO) models. The same model can be used to develop programming code and relational database structure.

Relational database technology is profound and powerful, but it


















is more difficult to use than many vendors would have you believe. Individual tables are straightforward and intuitive. But applications that incorporate hundreds of tables (this is common) are often difficult to fathom. This is where OO models are helpful.

OO models let you think deeply and coherently about a problem. OO models provide a means for thinking about the superstructure of a problem which can then be implemented with the lower level building blocks of relational databases.

This article discusses relational database technology in general and does not focus on specific products. We will not address physical design details (such as storage allocation and physical clustering) because they are product dependent.

There are two aspects to implementing UML models with relational databases: mapping structure (Section 2) and mapping functionality (Section 3). Section 4 comments on object-oriented extensions to relational databases. Section 5 summarizes the article.

2. Mapping Structure to Tables

The UML object model is essentially just an extended Entity-Relationship (ER) model2. The use of ER models for designing databases is well accepted and we use UML object models in a similar, but more powerful, manner. The primary advantage of OO models is that the same model addresses both programming and databases. Also we stress navigation of OO models as a means of thinking about functionality (Section 3). This section shows how to implement the major constructs of the UML object model.

2.1 Identity

The first step for implementing an object model is to deal with identity. We begin by defining several terms.

● A candidate key is a combination of one or more attributes that uniquely identify the records within a table. The collection of attributes in a candidate key must be minimal; no attribute can be discarded from the candidate key without destroying uniqueness. No attribute in a candidate key can be null.

● A primary key is an arbitrarily chosen candidate key that is used to preferentially reference records.

● A foreign key is a reference to a candidate key. A

foreign key must include a value for each constituent attribute or it must be wholly null. Foreign keys are used to implement associations and generalizations.

You should normally define a primary key for each table, though there are occasional exceptions. We strongly advise that all foreign keys refer only to primary keys and not to other candidate keys.

There are two basic approaches to defining primary keys:

● Existence-based identity. You should add an object identifier attribute to each class table and make it the primary key. The primary key for each association table consists of the identifiers from one or more related classes. Existence-based identifiers have the advantage of being a single attribute, small, and uniform in size. Existence-based identifiers have no performance disadvantage as long as your relational database management system (RDBMS) has support. (Most RDBMSs provide sequence numbers for efficient allocation of existence-based identifiers.) The only disadvantage is that existence-based identifiers have no intrinsic meaning during maintenance.

● Value-based identity. Some combination of real-world attributes identifies each object.

Value-based identity has different advantages. Primary keys have intrinsic meaning to the user, facilitating de-bugging and maintenance of the database. On the down side, value-based primary keys can be difficult to change. A change to a primary key may require propagation to many foreign keys. Some objects do not have natural real-world identifiers.

We recommend that you use existence-based identity for RDBMS applications with more than 30 classes. Both existence-based and value-based identities are viable options for all RDBMS applications.

2.2 Domains (Attribute Types)

Attribute type is the UML term that corresponds to the term of domain in the database literature. Domains promote a more consistent design than direct use of data types and facilitate porting of an application.

Simple domains are straightforward to implement. You merely substitute the corresponding data type and size. Also for each

attribute that uses a domain, you must add a SQL check clause for each domain constraint. Some examples of simple domains are: name, longString, and phone-Number.

An enumeration domain restricts an attribute to a set of listed values. Enumeration domains are more complex to implement than simple domains and Figure 1 shows four approaches.

2.3 Classes

Normally we map each class to a table and each attribute to a column. You may require additional columns for a generated identifier (existence-based identity), buried associations (Section 2.4), and generalization discriminators (Section 2.5).

2.4 Associations

Now we discuss implementation of associations. We have divided our presentation into recommended mappings (mappings that we normally use), alternative mappings (mappings that we occasionally use), and discouraged mappings (mistakes that we encounter and which you should avoid). We use existence-based identity for all our examples.

2.4.1 Recommended mappings

● Many-to-many association. Implement a many-to-many association with a distinct table (Figure 2). The primary key of the association is the combination of the primary keys for each class. The ellipses (. . .) denote attributes that are not shown in the model. Primary keys are shown in bold font.

● One-to-many association. Bury a foreign key in the "many" table (Figure 3). Role names become part of foreign key attribute names.

● Zero-or-one-to-exactly-one association. Bury a foreign key in the "zero-or-one" table (Figure 4).

● Other one-to-one associations. Bury a foreign key in either table.

2.4.2 Alternative mappings

Normally we use the recommended mappings. But there are occasional situations where alternative mappings are more appropriate.

● Distinct table. You can also implement one-to-many





and one-to-one associations with distinct tables (Figure 5). Distinct tables give you a more uniform design and greater extensibility. However, distinct association tables fragment the database and increase the number of tables. Furthermore, distinct association tables cannot enforce a lower multiplicity limit of "one".

2.4.3 Discouraged mappings:

We have noticed that some developers choose flawed mappings. We call attention to them so you can avoid them.

● Combination. Do not combine multiple classes and an intervening association into a single table (Figure 6). This reduces the number of tables but can violate third normal form.

● Double buried one-to-one associations. Do not bury a one-to-one association twice, once in each class (Figure 7). This is redundant and does not help performance.

● Parallel attributes. Do not implement the many role of an association with parallel attributes (Figure 8). Parallel attributes complicate programming and compromise extensibility.

2.5 Generalization

Now we discuss generalization. We only treat single inheritance here.

2.5.1 Recommended mappings

The simplest approach is just to map the superclass and each subclass to a table. The tables share a common primary key. Applications must enforce the partition between subclasses because an RDBMS will not. (See Section 4 for an elaboration of this latter point.)

● Distinct tables. Map the superclass and each subclass to a table (Figure 9). The tables share a common primary key. The discriminator indicates the appropriate subclass table for each superclass record.

2.5.2 Alternative mappings

There are several alternative mappings for generalization.

● Elimination. You can optimize away classes that have no








attributes other than a primary key (Figure 10). This reduces the number of tables but provides a less regular implementation.

● Push superclass attributes down. You can eliminate the superclass table and replicate superclass attributes for each subclass (Figure 11). This has the advantage of describing each object in one table. However, it causes redundancy of database structure and you may need to search multiple subclass tables to find an object.

● Push subclass attributes up. As a third alternative, you can eliminate the subclass tables and store all subclass attributes in the superclass table (Figure 12). This describes each object in one table, but violates second normal form.

2.6 Referential Integrity

Once you have established tables, you should define referential integrity actions to enforce the meaning of the object model. (Don't use SQL triggers to implement referential integrity!) If you use existence-based identity, you will not need to propagate the effect of updates. We recommend the following referential integrity guidelines for deletions:

● Generalization. Cascade deletions for foreign keys that arise from the implementation of generalization.

● Buried association, minimum multiplicity of zero. Normally set the foreign key to null, but sometimes you may forbid deletion.

● Buried association, minimum multiplicity of one. You can cascade the effect of a deletion or forbid the deletion.

● Association table. Normally we cascade deletions to the records in an association table. However, sometimes we forbid a deletion.

We have quickly covered referential integrity, because it is an advanced topic. Reference3 has further explanation and examples.

2.7 Indexes

The final step for implementing a database structure is to add indexes to tune the database. Normally, you should define a unique index for each primary and candidate key. (Most RDBMSs create unique indexes as a side effect of SQL primary key and candidate key constraints.) You should also create an index for each foreign key that is not subsumed by a primary key or candidate key constraint.




We emphasize the importance of indexes. Indexes on foreign keys and primary keys enable the fast traversal that is implicit in an object model. You must include these indexes or you will frustrate users. You should incorporate indexes in your initial database design because they are straightforward to include and there is no good reason to defer them.

The database administrator (DBA) may define additional indexes for frequently asked queries. The DBA may also use product-specific tuning mechanisms.

2.8 Normal Forms

A normal form is a guideline for relational database design that increases the consistency of data. Our book3 discusses normal forms, but we misspoke about the issue. We will use the opportunity of this article to clarify our position. If you are not familiar with normal forms you can skip this section. Our comments are aimed at relational database designers who are trying to reconcile their existing skills with object-orientation.

Normal forms are mathematical principles for proper design of relational databases. As such, they hold no matter which development technique is being used - attribute-based design, entity-based design, object-oriented design, or something else.

With the attribute-based design approaches of the past, developers had to pay close attention to normal forms; normal forms provided the basis for grouping data. In contrast, normal forms are unimportant for OO-based (or entity-based) development. If you adopt an OO approach and your models are well conceived, you are organizing data into meaningful units that intrinsically satisfy the prescriptions of normal forms. You can still check the normal forms if you want, but such a check is unnecessary.

2.9 Summary

Figure 13 summarizes the mapping rules that we have presented. A complete example of these mapping rules, including a UML object model, can be found in the expanded version of this article (Adobe Acrobate PDF file (download the Acrobat Reader)).

3. Mapping Functionality to SQL Commands


http://www.therationaledge.com/rosearchitect/mag/archives/9904/RATL-2.PDF


http://www.adobe.com/prodindex/acrobat/readstep.html#reader

Object models serve three major purposes for database applications:

● Structure. An object model specifies the structure of a database. We explored this aspect in Section 2.

● Constraints. An object model also specifies important constraints on the data that can be stored. A suitable implementation must strive to honor these constraints. Our treatment of mapping rules and referential integrity in Section 2 addressed many constraints. Additional UML constructs, not covered in this article, can capture further constraints.)

● Potential for computation. An object model specifies the potential for computation; it is a blueprint for what queries can be posed and how they can be formulated. Section 3 will briefly illustrate this third purpose.

Object models are not merely passive data structures, but they can help you think about the functionality of an application. You can specify much functionality in terms of traversal of an object model. For example, we think in terms of traversal when we check use cases against a model. This emphasis on the computation capabilities of object models is especially important for RDBMS applications, because traversal expressions can be directly mapped to SQL code.

The UML Object Constraint Language (OCL) is helpful for expressing traversals. The dot notation navigates from object to object and object to attribute. The square brackets denote filters on collections of objects. We add the colon (:) operator to denote traversal of generalization; explicit traversal is helpful since we normally use multiple tables to implement a generalization hierarchy.

The sample traversal expressions in Figure 14 are based on the UML object model we created (see the expanded version of this article (Adobe Acrobate PDF file (download the Acrobat Reader))) and we map them to SQL code. We preface SQL programming variables with a colon.

4. OO Extensions to RDBMSs

The database community is interested in OO extensions to RDBMSs. Products and the SQL standard are attempting to add OO extensions. We will briefly comment on the direction of this technology.

● Abstract data types (ADTs). These are a good idea



http://www.adobe.com/prodindex/acrobat/readstep.html#reader

and extend the power of RDBMSs. The vendors use various names for the technology, such as Oracle cartridges and Informix data blades. The disadvantage of ADTs is that they tie you to a specific vendor; the details of ADTs are beyond the SQL standard. Consequently, you should only use ADTs when their benefit is compelling.

There has been some confusion in the literature about how ADTs fit in with database development. If you use the OMT development process, you can implement simple domains as attributes and complex domains as ADTs. You should still implement classes as tables.

● SQL3 pointers. The latest revision of the SQL standard, SQL3, adds the notion of a pointer as a data type. Apparently, the intent is to support navigation and object-orientation. Our kindest comment about SQL3 pointers is that they are grafted on and can be ignored. The deeper criticism is that pointers are theoretically unsound, add complexity, and do not extend the expressive power of SQL. CJ Date eloquently made this point at last September's Object/Relational Summit.4

OK, so we are lukewarm about abstract data types and critical of SQL3 pointers. But we are quite fond of object-oriented technology and relational databases. There are two extensions for RDBMSs that would make them easier to use with OO techniques. We would like to see the RDBMS vendors add these capabilities to their products.

● Extend referential integrity actions to support generalization. The current referential integrity mechanism is one-way. To properly support generalization, we need a two-way mechanism. Then a superclass record can depend on a subclass record. And a subclass record can depend on a superclass record. We can best explain this by example.

Figure 15 is an excerpt from our financial case study in3. We have the asset superclass to unify some common data and functionality that is not shown in the excerpt. An asset can be a stock or a stock option. A stock can have many stock options written against it. For example, IBM stock can have put and call options written for various strike prices and expiration dates.

Our recommended implementation of generalization is distinct tables - map the superclass and each subclass to a table. Then we can use referential integrity to make the records of stock option and stock depend on asset. The


deletion of an asset record cascades to deletion of the appropriate subclass record, stock option or stock. We can also define a referential integrity action so deletion of a stock cascades to deletion of the associated stock option records.

Now the problem is as follows. If we delete an asset that is a stock, deletion of the asset record cascades to cause deletion of the stock record. Subsequently, deletion of the stock record cascades to cause deletion of any stock option records. But now referential integrity fails us; deletion of a stock option record does not cause deletion of an asset record. The deletion cascade only goes downward from the superclass to the subclasses. For proper behavior, the cascade should go both ways.

The workaround with the currently available referential integrity is to do more programming (and consequently do more work and risk more bugs). In our implementation of the case study, whenever the user wants to delete an asset that is a stock, we had to write additional code to first check for the existence of associated stock options and delete them.

● Support partitioning of records across tables. The meaning of single inheritance (the most common form of generalization) is that each instance of a superclass is instantiated by at most one subclass. The current RDBMSs cannot readily enforce this constraint. For example, there is nothing to prevent the following situation. A stock could be entered in the Asset table with an ID of 18, in the Stock table with an ID of 18, and also in the Stock-Option table with an ID of 18. Once again, we have to do additional programming, rather than write a simple declarative constraint, to ensure proper behavior.

5. Conclusions

This article has presented a quick overview of implementing UML models with relational databases. We hope this article has demonstrated to you that the technologies are quite compatible. A skilled developer can prepare an excellent implementation of OO models with a relational database. If you want more details on the mechanics of implementation, Reference3 has additional information, and also covers some advanced object modeling constructs we did not discuss here.

Footnotes

1. Michael Blaha and William Premerlani. Object-Oriented Design of Database Applications. Rose Architect 1,2 (Winter, 1999).

2. PPS Chen. The Entity-Relationship model - toward a unified view of data. ACM Transactions on Database Systems1, 1 (March 1976).

3. Michael Blaha and William Premerlani. Object-Oriented Modeling and Design for Database Applications, Prentice Hall, Englewood Cliffs, New Jersey, 1998.

4. CJ Date. Don't mix pointers and relations! Presentation at Third Annual Object/Relational Summit sponsored by Miller Freeman, Washington D.C., September 16-19, 1998.

About the Authors

Michael Blaha is an alumnus of General Electric R&D in Schenectady, New York. For the past five years he has been an independent industrial consultant in the areas of object-oriented technology, modeling, database design, and reverse engineering. Dr. Blaha has authored numerous papers, five patents, and two books. Contact him at www.omtassociates.com, or [email protected].

William Premerlani has been on the staff at General Electric R&D since 1975. His primary research interests are in the areas of software engineering, metamodeling, database technology, and complex engineering applications. Dr. Premerlani has authored many papers, twenty-five patents, and two books. Contact him at [email protected].

Back to Contents


http://www.therationaledge.com/rosearchitect/mag/archives/9901/f1.html

http://www.therationaledge.com/rosearchitect/mag/archives/9901/f1.html

http://www.omtassociates.com/





http://www.mfi.com/

http://www.unm.com/

Home


About Rational Rose

About the UML

What's new in Rational Rose 98i

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.

Let me begin by clearing up what the 'i' in the 98i stands for -- it stands for integration.

This release of Rose focuses on improved integration with the tools you use everyday, and includes several cool add-ins and features.

Also, the big news is that Rational Rose 98i on Windows is now a licensed product. We use the Flexlm license manager from Globetrotter Software (http:// www.globetrotter.com). And licenses are available as temporary/start-up key, node-locked, and floating.

So, what about those cool add-ins and features of Rational Rose 98i Enterprise Edition?

Integration with Visual Studio 6.0

Rational Rose 98i offers seamless integration with Visual Studio 6.0. The new VC++ add-in was covered in the last issue, so I won't wax eloquent about it. However I can definitely tell you that it's great and that I love it. ;-)

Both VC and VB now share a common framework. For example, after creating a model a user can bring up the VB Model assistant (MAT). This model assistant helps guide you in the evolution from business model to code. You are also given alternatives in the MAT to add VB- (and VC-) specific properties to the model, and then have the opportunity to preview the code that will be generated.

The TypeLib Importer has been improved to provide two kinds of import -- quick and full. The quick import is fast, giving only class


















http://www.globetrotter.com/

information. The full import provides all information. Individual components can be brought into Rose as a quick import, and then "upgraded" to full import on demand.

VB Language -- Rose now has the ability to RTE ActiveX Designers, as well as RTE ENUMS and TYPES in VB. (This was a much-requested feature.)

Rose 98i will provide integration with the Visual Component Manager 2.0 available with Visual Studio 6.0. Rose 98i is the only tool which will be able to publish models directly to Visual Component Manager, as well as support the drag and drop of models, classes, and packages from VCM onto Rose. Users of VCM will be able to browse models and the contents of models, and drag and drop the portions of the models they wish to reuse.

Integration with ClearCase

The Rose 98/Clear Case integration moves to the second generation in Rose 98i. Use cases involving Rose and ClearCase have been simplified. You no longer need to go to a separate dialog to perform them. You can now select one or more packages (in browser or diagram), and perform frequent CM operations directly from the context menu. Also, the visual feedback of state of units has been improved.

New features include:

● Multi select of units in browser -- you can select several packages to be checked in from the browser.

● Add to version control, check in, checkout directly from context menu on the diagram.

● Unit manipulation (control, load, unload, etc) from context menu.

● Configuration Management works for external files -- if you have an external file linked to a package, when you check in that package, you are given the option to check in the external file as well.

Many manual tasks will also be automated; for instance adding a package to source control will automatically make it a controlled unit.

The SCC Add-in will be renamed to "Version Control Add-in" and will support ClearCase as well as Visual SourceSafe using the SCC API.

CORBA Add-In: The current IDL add-in has been replaced by a new

CORBA add-in. This add-in is based on the new CORBA 2.2 definition. It supports the forward and reverse engineering of CORBA IDL. This add-in also supports other CORBA-specific language features as Stereotypes, Constants, Enums, Exceptions, Interfaces, Structs, Typedefs and Unions. It also includes a built-in color-coding editor which allows the editing of IDL syntax files from within Rose 98i.

Java Add-In: The new Java add-in has been further enhanced to make installation and usage much easier. Some feature highlights are: support for Zip, Jar and Cab files in the classpath, user extensible classpath within the model, smart component mapping on generation, support for a default package, improved support for inner classes, support for anonymous classes, bean property generation (Get/Set), and a built-in color-coded editor.

Data Access Add-In: This add-in allows you to map ActiveX objects developed in VB, VC++ and VJ++ to databases. The add-in utilizes the code generation capabilities of Rose to generate code into an IDE. This will include persistent services like save, delete, and load. You can take class models defined in Rose and generate logical database models and physical database scripts (DDL). You can also take existing databases and reverse engineer them into logical database models and class models within Rose, and be able to visually model relational databases (logical models) in Rose. Once the model has been designed, then DDL can be generated into the database.

Internet Web Publisher: The Internet Web Publisher for Rational Rose is a tool for formatting and distributing software design information on the world wide web, which allows easy access to all aspects of analysis and design information. The Internet Web Publisher for Rational Rose 98i enables you to export your analysis design model to the HTML format, which can then be viewed using a standard browser such as Microsoft's Internet Explorer or Netscape. Unlike sequential formats, like paper or text files, the Web Publisher for Rose lets you browse, search, and navigate non-sequentially in the design documentation. You can use the web publisher to publish successive iterations on an evolving model for reviewing or for just plain information sharing. Another potential use is to publish documentation for a frozen API or framework. This has been a much-awaited tool to complement the existing Rose 98 features.

The preceding was just a few of the new and improved features in Rational Rose 98i.

That's all folks. It's been great writing for you as usual.

À Bientôt

Back to Contents




http://www.mfi.com/

http://www.unm.com/

Home


About Rational Rose

About the UML

Welcome to the 3rd issue of Rose Architect

by Adam Frankl

Adam Frankl is Publisher of Rose Architect and CEO of Resounding Technologies, www.resounding.com.

The impact of visual modeling and the UML continues to expand. In March the first-ever UML World conference was held in New York City, uniting developers and methodologists from all over the world. Our Editor-in-Chief, Terry Quatrani, was a prominent speaker, and enjoyed meeting many of you. In this issue, UML co-creator Jim Rumbaugh takes us to the front lines with his article on the current status and the future of the UML.

Popular contributors Christian Buckley and Darren Pulsipher are back with a look at what teenagers and primal scream therapy have to do with business modeling. And we've got expert advice from guest contributor jim conallen on creating your own Rose add-ins with Visual Basic, and from Rational's own Kevin Kelly, who takes us through the process of creating user-defined tags. Magnus Christersen and Nils Undén explore the issue of modeling large systems. Davyd Norris from the Rational Australia office has written a product integration focus on Rose and SoDA. And for a look at real-world examples of Rose and the UML in action we've got contributions from our European correspondent, Nasser Kettani, and a Rose case study that tells you just who you have to thank for that tiny bottle of in-flight vodka.

Inside Rose this time around we look at CORBA, courtesy of Jeffrey Hammond, product manager of the CORBA and Java technologies for Rational Rose. And we are pleased to present the second of a two-part exploration of UML database modeling by noted industry experts Michael Blaha and William Premerlani. An expanded version of this article, along with a model of the system they discuss, can be found in this month's on-line issue. There you will also find new book reviews, our Ask the Expert column, additional Letters to the Editor, more from Technical Editor, Naveena Bereny, on what's new in Rational Rose 98i, monthly contests and more. Also, in response


















http://www.resounding.com/


to many requests we've received, we're now making available on our Web site downloadable versions of code referenced in our articles. This will save you the trouble of having to type in the code yourself, as well as providing a more stable format for examining the code, since formatting restrictions in print occasionally result in incorrect formatting.

And in honor of this issue's cover, I urge you to visit Cafe Rose (http://cafe.rational.com/rose/) and the UML Cafe (http://cafe.rational.com/uml/), our online user groups. Become part of the Rose and UML communities, where you can follow topics of interest in your choice of e-mail or web responses.

Enjoy!

Adam Frankl, Publisher

Back to Contents


http://cafe.rational.com/rose/

http://cafe.rational.com/uml



http://www.mfi.com/

http://www.unm.com/

Home


About Rational Rose

About the UML

Editor's E-mail/Ask the Experts

by Terry Quatrani

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

Dear Terry,

Brian Lyons wrote in his Metric magic article: "The composite part is constructed and destroyed along with the class that represents the whole."

Robert C. Martin who has been co-authoring with Grady Booch has repeatedly stated in the OTUG forum that in composition, the whole has only the responsibility to destroy the composite part. According to him, UML states nothing about creation responsibility and UML allows the transfer of composite parts among different aggregates. If one accepts the idea that parts can be transferred from Class A to Class B, then nothing prevents A from creating the part and passing it on as an argument to B. B would have the responsibility to destroy this part to Robert C. Martin that is all that is needed to constitute a Composition relationship.

It has come to my attention that there seems to be no apparent consensus in UML books on this issue of creation responsibility. Some like Martin Fowler, agree with Brian and others speak of lifetime responsibility, without really defining it. I would be very pleased to hear that this apparent little contradiction has been resolved despite differing expert views.

And by the way, congratulations on your new magazine. I, for one plan, to read it regularly. I recognize many of the authors as either Rational staff or Rose Link Partners. Can articles only be written by them?


















Claudia Frers UML Trainer & Mentor [email protected], UML Academy Copenhagen, Denmark

According to Grady, in the case of composition, the intent is lifetime responsibility, which means that the whole is responsible for the birth and the death of its parts. However, "responsible" does not necessarily mean "direct". The whole might delegate the creation of a part (for example, a parent may have a surrogate for a child) as well as the destruction (the whole puts out a contract to kill the part). Also, we welcome article submissions from all of our readers. Please see our writer's guidelines for information.TQ

Dear Terry,

I am currently involved in the User Interface development for our company product which is being re-organized based on the CBD (Component Based Design) approach. For this development, we are using Rose98 as our UML modeling tool.

Now, for the UI also, we plan to identify the ((user action) -> (sequence of business methods)) in the UML model. This is being done for a variety of reasons (incl. the fact the actual UI development may be done offshore.)

So much for the background. Now to my specific question.

In my UML model for the UI, I am showing the possible user actions as sequence diagrams. However, the same action may be initiated from different controls (menu, keyboard shortcuts, buttons, etc. ) For this reason, I need a method so I can show in a sequence diagram that a user method (such as - selectmenu_ event_activate) invokes a particular sequence as drawn in a particular sequence diagram. (This seq. diagram may be "Activate an event".)

Is there a way to shown this in the sequence diagram without having to replicate the same in all the places it is referenced?

Is there some other standard way of performing the same task (relating a menu action to a sequence) other than a sequence diagram approach used by me?


Thanks for your response in this matter.Manoj Thakur

Manoj,

An actor can be a superclass of all possible sources of the event that triggers the action. This need not be a strict superclass, but could simply be a mixin or an interface.

Activity diagrams can also be used to convey the information you need. Activity diagrams are currently available as a partner add-in to Rose and they will be incorporated into a future edition of Rose.

Hope this helps,TQ

Back to Contents




http://www.mfi.com/

http://www.unm.com/

Home


About Rational Rose

About the UML

How Suite It Is...

Software development is a team sport. Individuals just can't develop the complex applications that businesses need to stay competitive. Realizing that, Rational Software has developed Rational Suite, a multi-platform line of product suites featuring a new architecture that tightly integrates updated versions of ten Rational products. Rational Suite is available in four editions -- AnalystStudio™, DevelopmentStudio™, TestStudio™, and Enterprise™ -- the latter containing all the market leading tools found in the other three editions.

Software teams are now unified thanks to the Team Unifying Platform and Team Integration Architecture, features that provide a common set of tools for team-based requirements management, change request and activity management, reporting, and process definition. This improves communication and automates workflow among all team members. These features are included in every edition of Rational Suite. And, recognizing that software teams are made up of developers working on many different facets of the same project, Rational Suite offers an optimized solution for these varied roles. Each edition provides a complete solution for a specific role, and a unique collection of Rational tools chosen specifically to optimize productivity.

Rational Suite simplifies the process of acquiring, deploying, training, and supporting multiple software tools by delivering tools in a single synchronized release cycle that ensures compatibility. Rational Suite is delivered on one CD, with one installation procedure, one license agreement, and one support vehicle to provide maximum convenience.

Rational Suite AnalystStudio includes the Rose Modeler edition. Analysts using Rose who want even more interaction with team members can trade up to AnalystStudio. Through the Team Unifying Platform, collaboration is made even easier. Developers and testers can share requirements, trace enhancement requests, defect and find/fix rates, and share Rose models with the development organization, ensuring requirements are supported by the architecture. The Team Unifying Platform also helps you keep track of testing by letting you see if your testing team has built


















tests for specific features.

Rational Suite TestStudio provides a complete, automated solution to unify testing professionals with other members of a project team. Including such features as new e-commerce testing technology, it contains comprehensive tools to verify operation of enterprise applications, whether they are custom client/server development, Web-based, or packaged applications such as ERP, and automatically tests coverage of requirements, GUI features and source code.

Recognizing that multi-platform development is becoming increasingly common, Rational Suite DevelopmentStudio is available on both Windows and UNIX: the Rose Enterprise Edition is including with the Window version, and Rose for UNIX in the UNIX version. Developers using Rose can trade up into DevelopmentStudio to gain the benefits of the Team Unifying Platform. This enables you to see new features when they are defined, and to see defects that are assigned to you and communicate the status of these defects to your project lead. Also provided are tools to help you in your development and unit-testing activities, run-time analysis, performance profiling, and coverage analysis tools.

Rational Suite will unify your software teams, is optimized for the individuals on your team, and it will simplify your development environment. Sounds like a suite deal....

To find out more about Rational Suite, please visit www. rational.com.

Back to Contents






http://www.mfi.com/

http://www.unm.com/

Home


About Rational Rose

About the UML

What's New in Rational Rose 98i

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.

By now many of you have already upgraded to Rational Rose 98i, but for those of you who are unfamiliar, I'd like to take this opportunity to discuss just a few of the new features included in this release.

First off, the "i" in 98i stands for integration, which means improved integration with the tools you use everyday, such as Visual Studio 6.0, Rational ClearCase, and other Rational tools.

Secondly, Rose 98i offers users even more functionality. Included in this release are a new CORBA add-in, a new Java add-in, and a data-access add-in which allows you to map ActiveX objects developed in VB, VC++, and VJ++ to databases. The capability to round trip engineer ActiveX Designers, as well as RTE ENUMS and TYPES in VB was a much-requested feature that we are proud to include in this version.

One of the best features of our Rational Rose 98i Enterprise Edition is the Internet Web Publisher, which lets you export your analysis design model into HTML which can then be viewed on the Web, allowing easy access to all members of your team.

We are very excited about Rose 98i, and I could easily take up this whole magazine talking about what's new. But the other editors wouldn't let me. For an expanded version of this article, please go to the bonus on-line article. And, as always, detailed descriptions about the latest and greatest can be found at www.rational.com/rose.

Until next time... À Bientôt



















Back to Contents




http://www.mfi.com/

http://www.unm.com/

Home


About Rational Rose

About the UML

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.

Nils Undén is Director of Business Architecture of Industri-Matematik International (IMI) Corp, a supplier of packaged application solutions in the Supply Chain Execution market.

Modeling Large Systems

by Magnus Christerson, Rational Software Corp., and Nils Undén, IMI Corp.

The question is, why are large systems so hard to build? Well to start off with, you may have several people involved in the design. And "several" can be anywhere from five up to hundreds or even thousands of people. Next, the projects are often filled with technical and political challenges (e.g. legacy, organizational divisions, etc.). So obviously you need a way to divide and conquer your application architecture to allow people to work in parallel across the lifecycle of your system. One of the characteristics of large systems is that you need to approach them top down, not bottom up (an approach which OO technologies handle well). Both the UML and the Rational Unified Process (RUP) can help in the modeling of large systems, especially when applied in Rose.

The key is to allow parallel work while keeping the conceptual integrity of the system design1 and to let that design evolve across iterations. So how can we support (and enforce) conceptual integrity in large systems modeling? We've already mentioned that it is important to use a top down design. We won't discuss the various approaches to reaching the architecture from such a design, but rather focus on how to model the system once the


















architecture is in place.

UML and RUP constructs

The UML and the RUP have good support for large systems modeling. Here we will use the UML concepts of Subsystems, Interfaces and Facades for modeling purposes.

Subsystems

Let's start off by looking at the definition of subsystems in UML: A subsystem is a grouping of model elements, of which some constitute a specification of the behavior offered by the other contained model elements.2

The RUP includes more clarification on how to use them: Design Subsystems are used to encapsulate behavior inside a "package" which provides explicit and formal interfaces, and which (by convention) does not expose any of its internal contents. It is used as a unit of behavior in the system, which provides the ability to completely encapsulate the interactions of a number of class and/or subsystems.3

A subsystem is like a black box package. It offers services to other subsystems through formal interfaces, but encapsulates its internal structure. A subsystem can contain other subsystems. Figure 1 shows a subsystem that encapsulates Order Management services as modeled in Rose.

As you can see, a subsystem is modeled as a package with the keyword "subsystem" described as a stereotype. Since it is modeled as a package in Rose, you can also choose to make this a separate controlled unit, something you normally would want to do.

Interfaces

The next construct we will use is Interface. The definition from UML is: An interface is a declaration of a collection of operations that may be used for defining a service offered by an instance.

And from RUP: A model element which defines a set of behaviors (a set of operations) offered by a classifier model element (specifically, a class, subsystem or component). A classifier may realize one or more interfaces. An interface may be realized by one or more classifiers. Any classifiers which realize the same interfaces may be substituted for one another in the system.

http://www.therationaledge.com/rosearchitect/mag/archives/9904/magfig1.htm

An interface offers services available for a client of the interface. It provides a contract between the client and the server of the interface. The interface construct maps well to COM, CORBA, and Java™ interfaces. Figure 2 shows how Interfaces can be represented in Rose. Interfaces transcend both the component view and the logical view in Rose, so the same interface may appear realized by a class and a component.

What is particularly useful with the interface definition is that we can use it to specify the services for both a component and a subsystem. Thus we can use the interfaces during modeling between subsystems, even before the components have been identified and specified. Not surprisingly, a subsystem maps very well to a component and can even be thought of as the component during analysis and design activities. To be precise, since subsystems can contain other subsystems, the lowest level subsystems map well to components.

Facades

According to the UML definition: Facade is a stereotyped package containing nothing but references to model elements owned by another package. It is used to provide a 'public view' of some of the contents of a package.

A Facade allows us to group the relevant interfaces for a subsystem. This lets other teams use the services from our subsystem with only the Facade of the subsystem. By making the Facade package a controlled unit in Rose, it can easily be shared. In this way we can release new versions and variants of the Facade. Note that a subsystem might have more than one Facade, usually one for every group of services. Figure 3 shows a subsystem with a Facade and a package which is the implementation of the subsystem.

What's inside?

By now we've covered the basic constructs and how to model them in Rose. But what is the structure inside and how can they be used, for example, in Interaction Diagrams? Well, there are a few different approaches you can choose. You want to keep your approach aligned with the implementation you are planning to use. Technologies like COM, Java, CORBA, and C++ all have ways to support these constructs.

COM

A CoClass in COM implements a component specified by one or



more interfaces represented as type libraries. All Visual Studio languages allow you to use these interfaces directly during programming. Each of the components implements one or more interfaces. The subsystem is the design of a component. A facade is the group of interfaces implemented in the component to be used by clients of the component. You might even have a Facade for each representing the COM view, the VB view and the VC++ view of the component. The classes within the subsystem can be CoClasses directly, or VB modules and forms, or VC++ classes. So these UML constructs map well to COM.

Java™

Java also has native support for these constructs. An interface in Java is the same as our interfaces. And a class realizes one or more of these interfaces. Java Packages provide namespace and group interfaces as well as classes.

CORBA

To no surprise CORBA also supports these constructs fairly well. Interfaces are native. Modules are groups of interfaces (our facades). Of course CORBA does not provide any implementation constructs; you will need to use your ORB vendor's IDL compiler to get skeleton (client and server) implementation hooks in C/C++, Java or whatever language you use.

Now let's go back and see how we might represent the interfaces and subsystems in Rose. In essence we would follow the approach above. Place all your interfaces in one or more facades for a given subsystem, which can then have one or more implementation subsystems (although only one in a specific system configuration) that holds classes which implements the interfaces.

In some cases you might want to delay the definition of the actual classes in your implementation part of the subsystems. In those cases you can create a proxy class (or classes) for the subsystem implementation. If you make this class a subclass of the interfaces in Rose, you can use this class as the proxy for modeling of the subsystem in interaction diagrams.

Example

This example is taken from the domain of supply chain execution and packaged applications (Figure 4). The subsystems are OrderManagement, WarehouseManagement and TransporationManagement.


Subsystems come in various sizes. In large, layered systems, the subsystems on the top-level are large. These subsystems will not be mapped 1:1 to a component during runtime, they are internally constructed of other subsystems which, on some level, will be mapped to a component. In the example, a product offering is made up of a client part (either Java- or Windows-based) and a server part. Each top-level subsystem contains all these parts. Normally a specific organizational unit is responsible for the top-level subsystem and its contained subsystems. The organizational unit handles product planning, release management and coordinates development for the top-level subsystem. During a development project the individual teams work in parallel on lower level subsystems, e.g., separate teams for OmJavaClient, OmWinClient, OmServer, etc. (Figure 5).

Subsystems will always, to some extent, be interdependent. Managing these dependencies is key to successful large-scale development. The dependencies govern if parallel work can be carried out and also enable subsystem substitution. An important principle in this work is to make the implementation packages dependent only of facades, i.e., interfaces, of other subsystems -- not their implementation. There also needs to be a common set of data types to use in the information interchange. This set should be as small and simple as possible, and be placed in one or in several packages.

E.g., the OmImplementation package is dependent on the WmGeneral facade, both of which are dependent on data types from a common package (Figure 6). By following this principle it is possible to substitute subsystems for other subsystems as long as the new ones are compliant with the interfaces. One example of this is if you want to offer different variants of a certain subsystem. The different variants may offer different functionality or support for different system environments. Another example, common in the packaged application business, is a customer that purchases only some of your product offerings, and decides to continue with legacy applications for other parts of a project. The task of integration is much easier if an interface exists. In these cases a thin adapter can be constructed that realizes the interface in question using the legacy applications as implementation.

WmLegacyAdapter together with WmLegacyImpl realizes the interfaces in the facade WmGeneral so that the standard product OmImpl can collaborate with it. (Figure 7) WmLegacyImpl is just a wrapper around the customer's legacy application, WmLegacyAdapter is responsible for mapping the warehouse management facade's interfaces to the legacy application and for converting the information to/from the common data types.




During top down design of subsystems, a good technique to use is sequence diagrams. Based on business processes and their workflow, high-level scenarios spanning several subsystems can be defined by the architects and the system analysts/business end users. The resulting sequence diagrams' objects will be subsystem proxies (a class that inherits from all interface classes). Each proxy offers the behavior of the subsystem it represents, this way the responsibilities of each subsystem and the subsystem interdependencies are defined in an iterative way, as more and more high-level scenarios are defined. The operations on the subsystem proxy can later be factored out to several interface classes.

During the design of each subsystem the development team defines sequence diagrams that depict the subsystem's internal flow of events, starting in one of the subsystem's interfaces and continuing over all involved implementation objects and other subsystem's interfaces.

So how do you do large-scale modeling? If you want to share your views, send us e-mails at the addresses below. If you have other topics you'd want highlighted in future articles, send me an e-mail on [email protected].

The authors would like to thank Grady Booch and Kurt Bittner for reviewing drafts of this article.

About the Authors

Nils Undén is Director of Business Architecture of Industri-Matematik International Corp. Nils has worked with OO, RUP and UML since 1990 focusing on large-scale development and the area between business and system engineering. Once upon a time Nils and Magnus were colleagues at Objectory AB where the basis of today's RUP was defined. Subsequently Nils has worked as Senior Consultant for among others IBM Object Technology Practice. You can reach Nils at [email protected].

Footnotes

1. Brooks Jr, Fredrik P., The Mythical Man-Month, 1975

2. The Unified Modeling Language, Semantics Guide 1.1, 1997

3. Rational Unified Process 5.0. Rational Software Corporation, 1998



Back to Contents




http://www.mfi.com/

http://www.unm.com/

Home


About Rational Rose

About the UML

Rational Rose 98i: Customizing Shortcut Menus

by John Hsia

John Sunda Hsia is the author of the training class "Extending Rational Rose". As a Technical Lead Engineer with the RationalLink partner program, he manages the training support of RoseLink, RequisiteLink Partner Program and ClearCaseLink partners in their effort to create add-ins and integrations. 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 [email protected].

Introduction

By now you've probably been exposed to most of the new features of Rose 98i. These new features fall within such areas as UML support (e.g., nested focus of control), ease of use (e.g., associations in browser), tool integrations (e.g., Visual J++ and MS Component Manager) and add-ins (e.g., CORBA and WebPublisher). The one area that has received less attention is Rose Extensibility.

For Rose Extensibility, improvements might be categorized as either full Rose Extensibility Interface (REI) exposure or support for Rose add-ins. For full REI exposure, otherwise known as REI Nirvana, Rose needs to expose all semantics of the model and all the physical characteristics of the diagrams. In this area, 98i has increased its coverage. Enhancements include new objects for line vertices (i.e., LineVertex) and additional methods (e.g., category.relocateAssociation, diagram.zoomFactor, and controllableUnit.getSubUnit Items). 98i is definitely an improvement, though not a major step towards Nirvana.

On the other hand, 98i has enhanced the infrastructure of add-ins dramatically. Now add-ins can override the specification dialog with custom specifications as well as add new menu items to the shortcut menus (a.k.a. context menus). Both of these features allow users to change the presentation of model element GUIs. Custom specifications are only available to language add-ins,



















whereas shortcut menus are available to all add-ins. As important as custom specifications are, most end-users aren't interested in creating new language add-ins, so this article will focus on the customization of shortcut menus.

What are Shortcut Menus?

Also known as context menus, shortcut menus appear when the user right mouse clicks within the browser or within a diagram. The composition of this menu will depend on the item(s) selected. Each active add-in can define menu options, submenus and separators specifically for each type of item (e.g., class, use case and diagram). Add-ins can also dynamically enable or disable menu items as well as checking them on or off.

In Figure 1, the shortcut menu for the model element class is shown. Since the selected class is a Java language class, the Java submenu is included in the shortcut menu. Also shown are the stereotype-related menu options that we have specifically defined for this article. Since this class is stereotyped as interface (see icon in browser), our customization selectively disables some of the stereotype options and even checks off the current setting.

Dynamic Shortcut Menus -- Under the Covers

So what does Rose do to dynamically create and manage shortcut menus? There are three basic user-initiated events that come into play -- start Rose, right mouse click on model element, and exit Rose. All of these events are illustrated as one sequence diagram in Figure 2.

User starts Rose. Rose calls the method OnActivate() for the registered COM servers on the active add-ins. This gives each add-in the opportunity to execute any initializations. This includes the definition of shortcut menu items for each type of model element that might be selected by the user. These menu items are appended to whatever hardcoded menu items Rose might already have defined. In our example, we add a separator, a menu item, and a submenu for the model element classes.

User right mouse clicks on model element. The user can initiate this action in the browser or the diagram editor. Before displaying the menu, Rose calls the OnEnableContextMenuItems() method. At this point, each active add-in that registers for this event can conditionalize their menu items. Then if the user selects a menu item, Rose will call the OnSelectContext MenuItem() method so the add-in can execute the appropriate action.

http://www.therationaledge.com/rosearchitect/mag/archives/9904/extfig1.htm


User exits Rose. Finally, when the user decides to exit Rose, each add-in's COM server is called (i.e., OnDeactivate() ) so any clean up can be completed before the respective COM server exits.

Now that we're familiar with how shortcut menus are dynamically composed, let's discuss the steps involved in defining shortcut menus for an add-in. Specifically, we'll take a look at our stereotype example.

Defining Shortcut Menus: Steps Involved

We begin by looking at the main steps in creating a shortcut menu customization including the registration of our add-in.

1. Design your shortcut menu customizations

2. Register your add-in and COM server

3. Define menu items

4. Conditionalize menu items (optional)

5. Define menu actions

6. Define clean up procedure for add-in (optional)

Step 1. Design Your Shortcut Menu Customizations

The purpose of this customization is to reduce the effort in setting and viewing commonly used stereotypes for classes. The shortcut menu will show the current stereotype and allow the user to set the class to the stereotype interface, actor, or none. So rather than bringing up the specification dialog, users can use the shortcut menu. This replaces what formerly required several mouse clicks and actual typing with just one mouse click.

Step 2. Register Your Add-In and COM Server

Before defining shortcut menu items, we have to define a new add-in where this customization will reside. We also have to define a COM server that will respond to various requests made by Rose. As discussed in my article in the inaugural issue of Rose Architect, an add-in is simply a packaging mechanism for extensions to Rose. The actual extensions (e.g., menu, stereotypes, properties, code generators ...) are typically found in COM servers, various ASCII files, and possibly in RoseScripts.

On Windows platforms, add-ins are contained in the registry. Figure 3 shows the registry settings for "MyAddIn". Add-In settings can be created directly in this editor or by creating a registry file as we have in Listing 1. Registry files typically have a .reg extension so Windows will automatically update the registry when this file is executed. The purpose of most fields in the registry is fairly obvious -- e.g., company, installation directory. As there is no documentation on this besides the "Extending Rational Rose" training class, the most common approach is to learn by example from looking at the settings for the numerous add-ins that come with Rose Enterprise. For this article, we'll concentrate on the shortcut menu specific settings:

2: The name of the add-in is implied by the name of the key -- i.e., MyAddIn.

9: Name of the COM server object that will respond to the various events raised by Rose. COM servers can be created with most IDEs that support COM such as Visual Basic or Visual C++. VB is usually the easiest -- specifically a VB ActiveX DLL.

10: This key name (viewed as a folder in the editor) stores all the events that our add-in has registered for and will respond to.

11: By setting this string value to "Interface", Rose will call the method OnActivate() on our COM server (i.e., AddInExample.EventHandler) when the user activates our add-in from the Add-In Manager or when the user starts Rose and our add-in is already active. The OnActivate method is where the menu should be defined. More details in step 3.

12: AddInExample.EventHandler.OnDeactivate() will be called when Rose exits (and this add-in is active) or when the user deactivates the add-in from the Add-In Manager. This is where the clean up will occur. More details in step 6.

13: AddInExample.EventHandler.OnSelectedContextMenuItems() will be called when an enabled menu item is actually selected. This is where the action associated with a menu item will occur. More details in step 5.

14: AddInExample.EventHandler.OnEnableContextMenuItems() will be called to allow the add-in to dynamically enable, disable and check menu items. This is where the menu items are conditionalized. More details in step 4.

Step 3. Define Menu Items (OnActivate)


http://www.therationaledge.com/rosearchitect/mag/archives/9904/exttab1.htm

The shortcut menu items for our add-in need to be defined when our add-in is activated. Listing 2 shows a partial listing for our registered COM object "AddIn Example.EventHandler". In this partial listing, the method OnActivate() for our COM server creates all the menu items below the Java submenu -- as seen in Figure 1.

1-5: Shortcut menu items are first class objects. Storing references to these menus will save us the time of having to look these up when we need to dynamically manipulate them.

6: Public method that is called when this add-in is activated. The Rose application object is passed as the only argument.

8: Get our add-in by its name "MyAddIn"

11: The <add-in>.AddContextMenuItem() adds a new menu item. The function is used to define a new menu item regardless of the type of menu item. In this case, a separator is added. This appends a physical line to the shortcut menu for classes (i.e., rsClass) to visually separate our menu items from previous menu items. Some of the additional model elements include rsUseCase, rsAttribute and rsOperation. These constants are available through COM only. Consult the on-line documentation for a complete list.

12: Adds the selectable menu item called "Clear Stereotype". If selected by the user, the string "SetStereotypeNone" will be used as an internal name for identification in step 5.

13: Creates a submenu called "Set Stereotype".

14-17: Additional selectable menu items for the submenu "Set Stereotype".

18: End of submenu declaration.

Step 4. Conditionalize Menu Items (OnEnableContextMenuItems)

Add-ins can conditionalize menu items based on whatever constraints the add-in deems appropriate. In our example, we want to conditionalize our menu items so that the current stereotype is checked and disabled. As soon as the user right mouse clicks on a model element, the function in Listing 3 will be called.

21: The OnEnableContextMenuItems() function is passed the Rose application object and the type of model element that has been selected.




22: We're only interested when a class or multiple classes are selected. "rsClass" is a constant available through COM.

23-27: By default, all menu items are enabled except for the "Other" stereotypes. "Other" is a placeholder for stereotypes beside Interface, Actor, or none, so we don't allow the user to select it. If we did allow the user to select it, we might pop-up a dialog where the user could specify a stereotype.

28: This checks the number of classes selected in the current model. If only one is selected, we will proceed to check off and disable the current stereotype.

29: Start by getting the current stereotype setting. Since only one class is selected, we need only look at the stereotype field for the first item in the selected class collection for the currently loaded model.

30-38: Disable and check the corresponding menu item for the current stereotype setting. rsDisabledAndChecked is a constant available through COM. Other possible constants include rsDisabled, rsDisabledAndUnchecked, rsEnabled, ... Check on-line documentation for more details.

This is an optional step -- by default all menu items are enabled. If you choose not to conditionalize your menu items, simply do not include the "OnEnable ContextMenuItems" key value in the registry (see line 14 in Listing 1).

Step 5. Define Menu Actions (OnSelectedContextMenuItem)

This step involves implementing the action for the shortcut menu items. In our example, we want to set the stereotype to the user's selection. So upon selection of an enabled shortcut menu item, the function in Listing 4 will be called.

44: OnSelectedContextMenuItem is passed the Rose application object and the internal name that corresponds to the menu selection. The internal names are set during the menu item definition (see lines 12, 14-17 in Listing 2).

45: The internal name for all set stereotype menu items start with "SetStereotype".

46-51: Find the stereotype selected by the user.




53: Get the selected classes for the current model.

54-56 Set the stereotype field for the selected class(es).

Step 6. Define Clean Up Procedure (OnDeactivate)

Like step 4, this is also optional. When an add-in is explicitly deactivated (add-in manager) or when the user exits Rose, this method gives the add-in an opportunity to perform any necessary clean up. In our example, we take the opportunity to free up some references (see Listing 5).

Summary

With Rose 98i, the support for Rose Add-Ins has dramatically increased. With the ability to override specification menus and to customize shortcut menus, Rose's user interface can now be tailored and, to some degree, even replaced. As shown in our example, new shortcut menu items can be added, conditionalized, and even checked. Most importantly, these customization features can be utilized with only minor additions to the registry and with a simple COM server. Finally without access to Rose source code, end users can now provide a more seamless presentation to custom functionality in exactly the same way that Rational developers and Rational RoseLink Partners do.

The complete example referenced in this article can be downloaded here.

Back to Contents



http://www.therationaledge.com/rosearchitect/db_area/AddInExample.zip



http://www.mfi.com/

http://www.unm.com/

Home


About Rational Rose

About the UML

Unilog Uses Object Technology and Business Modeling for Their Customer Success

by Nasser Kettani After 13 years working on several projects in different domain areas, Nasser Kettani joined Rational as senior consultant helping customers implement effective software development processes and technologies. He is the Marketing Manager of Rational Software France. He recently co-authored a book "De Merise a UML".

"Unilog is a major player in the software consulting business. Founded in 1968, Unilog is now employing over 3,500 people with a revenue of 180M Euros (206 M$) for 1997. Unilog operates in France, Germany, Austria, and Switzerland. The Group provides Consulting, Engineering and Training. Frederic Trouche, you are senior consultant at Unilog, you want to share with us some interesting work you are doing with your customers."

NK: How do you define the business of Unilog, especially in the consulting area?

FT: Committed to respecting different cultures, Unilog is proud to work together with its customers, to construct the innovative, integrated and adaptable solutions which make it possible for them to achieve their strategic objectives. Our consulting is basically twofold: consulting in organization and evolution of enterprise information systems, consulting in technologies and architecture of enterprise information systems. Our consulting business represents 25% of our total revenue.

NK: This means that you are involved with customers very early in the life cycle?

FT: We basically participate very tightly with our customers to identify enhancement directions in their business practices. We help implement their already identified strategies into well-organized business processes and practices. As such, we enter the enterprise information systems, the organizational structure, and


















also human aspects.

NK: Some analysts' reports claim you have a leading position in implementing ERPs in France (N°1 for JD Edwards, N°2 for Oracle Applications, N°4 for SAP). What is the secret here?

FT: Yes. As a company we provide all the services that ensure the success of our customers that implement ERPs. We help our customers mapping their business processes and practices with the business models offered by their ERPs of choice; we help them succeed in the change process, and finally we provide expertise in implementing the installation, the customization and the engineering of the packages.

NK: Can you explain to our readers what is the role of UML in this business?

FT: Our approach is to model the business before even making the final choice of the ERP. Our goal is to help them understand, formalize, communicate to all stakeholders, and make non-ambiguous their business processes. So we need an adequate tool. We found that Object Technology and the UML fit exactly this purpose.

The UML provides concepts that are consistent with business modeling. An Actor, a Use Case, an Object are business concepts that end-users understand. The UML is an international standard and as such, lets no place left open to misunderstanding. We can communicate with external people that know the UML, especially those that will implement the final software system (since they will use the same formalism; we have had much experience of this). Finally, the UML is supported by several products (like Rational Rose); and this is critical for business modeling.

Let me share something with you. Our hope (and we are even working on this) is that ERP vendors should offer (using the UML) the business models of the standard business processes they provide. That way, one can model the customers' business processes and evaluate the distance between these processes, hence facilitating the ERP implementation and customization. Unilog does not consider ERPs as a machine that generates consulting days. We need to minimize the alignment effort. Our added value resides in business modeling.

NK: Can you talk about some projects using these techniques?

FT: There are actually a dozen. At "Banque Populaire du Maroc", EDF (Electricité De France) and others. At EDF, we worked on the invoicing of industrial accounts. This is a complex process because

the invoicing process basically depends on the final customer. Using Object Technology to model their business helped them find out that they actually have generic models that could be reused. On another project, using business modeling with the UML helped the customer (which rents medical hardware) really have a good insight into his business. Business Modeling using the UML help highlight generic and specific processes.

NK: What about your customers? Do they buy into this approach?

FT: In fact, we have to impose it on our customers, because they are not used to these techniques and not even to modeling. As soon as the project starts and they are involved, they see the benefits. I am not sure they could do it themselves (it actually depends, they can have someone internally who can be an intermediate relays). However, they ultimately buy into it because it is the way they think; they become safeguards. It becomes a repository and an asset. Business processes change and it is easier to update and evolve existing business models. The fact that the UML is a standard reassures them that they are not alone and they will reuse their investment. Remember also, that modeling a business does not preclude that we necessarily implement a new software system.

NK: Is this approach systematic at Unilog?

FT: We have derived from Rational Objectory BE our own methodology because of specific experience, market and positioning. Though we have a formal process, it is still flexible and ensures final consistency of the result thanks to the UML. Flexibility is very important, otherwise there are risks and you lose time. We still have customers resisting for various reasons ("not required in this context", ...). In this case, we don't use the complete formalism and we use textual representations and still try to stick to the general approach.

NK: Did you train your teams, consultants, ...?

FT: Unilog is far ahead, having worked on these techniques for almost two years. We defined several phases. We identified highly motivated, experienced, and leading team of people that were willing to change and adopt a new technology and we trained them. We then used these techniques on ten different pilot projects in order to make sure that these actually work. We are now in the phase where we start deploying and generalizing the approach. Our leading pilot team is driving this and involving new consultants on real projects.

NK: Why did you choose Rational?

FT: Rational is the industry and thought-leader in the modeling arena. Also, when you look at this market, there is no real industrial, reliable alternative. We were also looking for a partner that would support us at an international level especially in the context of our international expansion and growth.

NK: How do Rational tools help you achieve your success?

FT: It is just useless to think modeling without tools support. A supporting tool is part of the whole method. We use tools because they increase team productivity, ensure maintainability of the models. A tool needs to drive you all through the process while providing flexibility. This is what the Rational tools offer.

Fréderic, I want to thank you for what you taught us about your experiences. I am sure our readers will be appreciative.

Back to Contents




http://www.mfi.com/

http://www.unm.com/

Home


About Rational Rose

About the UML

Rose 98 for Power Users from ICONIX

by Patrick Rutledge

Patrick Rutledge is a team lead on the Rational Rose technical support team in Cupertino, CA.

What It Is

The Rose 98 for Power Users CD-ROM from ICONIX Software Engineering, Inc. is a multimedia tutorial which introduces using Rational Rose in a use case driven modeling approach and how to extend the tool's capabilities. It includes Rational Objectory 4.1, utility scripts presented in the tutorial, a Rose model of the Rose Extensibility Interface, and an evaluation version of Rose 98 Enterprise. There is no printed component or manual.

The format of the tutorial is a series of slides, each of which contains a QuickTime movie of presenter Doug Rosenberg as a talking head familiar to any viewer of nightly news programs. The movie sits in the corner and the slide displays bullet points that are highlighted as Doug reaches its subject. When applicable, textual links to example movies are listed along the sidebar and can be accessed at any time. These example movies take up the entire display area and typically show a disembodied Rose user performing a process discussed in the slide.

The tutorial consists of three major sections, each made up of more detailed topics. The sections are an introduction, a presentation of the major diagrams used in the process, and a section on Rose extensibility. There is a map slide that lists the entire table of contents as textual links. The map can be reached with a button on every slide and makes it quick and easy to navigate between topics.

Why It Is

ICONIX provides the CD primarily as a way for potential clients of their training services to preview the lectures that they deliver on-site. The current field of UML/Rose training services is large enough


















that it can be difficult for a company to make an informed decision on which most closely matches their needs. The tutorial gives potential clients an abbreviated version of the training that ICONIX provides on-site, and is meant to be more informative than a brochure.

The second way that ICONIX uses the CD is as an introduction for their five-day Jumpstart training programs. The CD is sent to the site ahead of time so that the students get a walkthrough before the more intensive on-site training. Then they keep the CDs for review or to share the training with team members when they are added at a later date. The idea is that the on-site trainer can spend less time presenting the basics and more time on labs specific to the team's project if the students have watched the tutorial ahead of time.

The tutorial is used here in Rose support as an introduction of the product for new team members.

Conceptual Design

Conceptual Design was called Robustness Analysis in Objectory 3.8. In the current incarnation of Objectory, the Rational Unified Process (RUP), conceptual design is included in the so-called Analysis and Design Workflow. It is an initial exploration of a logical view of the entity, control, and boundary classes that will fulfill the use case responsibilities. Robustness Analysis figures prominently in the tutorial because, according to ICONIX, it can help to transition from use case descriptions to the detailed design views of the system, through the development of a preliminary design without implementation details. This evolution from use cases to implementation-aware designs is still captured in RUP in the use case realizations and the Architectural Analysis and Design activities, where emphasis is placed on constructing an architecture which is resilient to changes. According to the Rational Unified Process, it is optional whether to develop a separate analysis model or develop one model that is refined over time, while the older method always created a separate analysis model.

Presentation of the Diagrams

The main diagrams used to model a system in Rose are reviewed one by one in this section of the tutorial. In several cases there are supplementary movies demonstrating techniques to be used with these diagrams. This is probably the most beneficial aspect of the multimedia format. As a support engineer, I fully appreciate the challenge of creating written instructions that are clear enough for new users. The movies capture visually the details of a step-by-step process that a documentation writer struggles to encapsulate

in text and graphics snapshots.

These slides on the diagrams make a few points in particular that would be especially useful to students. There is, for instance, a demonstration of attaching graphics files to use cases for the purposes of referencing mockups of GUIs. There are movies that demonstrate manual and script-based techniques for beginning sequence diagrams. I was glad to see coverage of component diagrams that emphasized their importance in code generation and walked through the process of assigning classes to components.

As may be expected, this section is the least deep in its presentation of the subjects covered. The elements and use of all of the UML diagrams in Rose is a topic beyond the scope of a single tutorial. Although useful as an introduction to the diagrams, no one will be modeling complex systems immediately after viewing these slides. As befits the nature of a tutorial, the user will require more in-depth study or more detailed training to advance with UML.

Extending Rose

I am a consistent evangelist for Rose's extensibility features, and was glad to find training that is helping to spread the word. I often find myself introducing developers to Rose scripting or custom properties when they are deep into a project and it can be disruptive at that time for them to take advantage of this feature. If only one member on a team becomes capable with Rose scripting and using the REI, this can provide a great benefit to the whole team.

The tutorial introduces every aspect of Rose extensibility available to customize or enhance Rose. This includes scripts, menus, dialogs, properties, stereotypes, OLE, and add-ins. There is a very brief description of the elementary syntax of the Rose scripting language (a dialect of VB) and how to open and run scripts. Then the viewer is walked through the contents and operation of several utility scripts included with the tutorial. These include a script that produces metrics and a script that starts a sequence diagram from selected classes. These movies don't so much explain the scripts' code as provide examples of utility scripts and how to use them.

Some parts of the extensibility section in particular provide valuable information on customizing Rose. The tutorial describes how Rose functions as an OLE server and how to access OLE servers from Rose scripts. Two scripts demonstrate linking to Word and Excel and generating information about the model into documents in these applications. I've seen enough traffic on our Rose forum mailing list to know that many Rose users are interested in this capability (or should be). The samples and

explanations constitute a useful introduction to this feature.

The tutorial covers the somewhat murky world of using dialogs in Rose scripts. Not everyone is aware that Rose includes a WYSIWYG dialog editor that automatically generates the scripting commands to create dialogs. The editor is described and a movie demonstrates its use. This would be a thin introduction if the CD-ROM didn't also include an excellent script from Zoe Eason of Rational that uses a complex dialog to browse the sequence diagrams that reference selected class operations. Not only is the script a useful tool for examining the model, the code would be a valuable template for creating dialogs and controlling them with a dialog procedure.

Overall Evaluation

I would recommend the CD-ROM on the strength of its coverage of Rose extensibility alone. It's arguable that all of this information is available in some form somewhere, but the value of a tutorial is that it presents the fundamental information in a structured way. This tutorial is an effective way to get started in using this powerful feature of Rose.

The tutorial would also be useful as a preview of the training ICONIX offers. The company offers a 15-day money back guarantee on the CD-ROM, which gives the purchaser an opportunity of avoiding the $99 cost of the tutorial if doesn't seem to meet their needs. The cost of their training CD-ROMs is also creditable toward the price of their courses, which include the CD-ROMs for free.

I had only one real problem with the CD, which was that it took over my entire display so that I had to quit from it in order to access other applications. I found myself wanting to try something in Rose or to examine more closely a script being discussed. I think the tutorial would encourage more active learning if the user could switch to Rose and back easily. Fortunately, the tutorial didn't take long to launch on my machine, which mitigated this issue.

Contacting ICONIX

The CD-ROM can be purchased online through ICONIX's web site: http://www.iconixsw.com.

You can request more information from Tom Johnson at [email protected].

About the Author

http://www.iconixsw.com/


Patrick Rutledge is a team lead on the Rational Rose technical support team in Cupertino, CA. Patrick participated fully in the Silicon Valley experience by developing databases and application interfaces at two failed start-ups in a row before joining the impressively stable Rational Software in late 1997. He tells non-technical people that he has a B.A. in French literature.

Back to Contents




http://www.mfi.com/

http://www.unm.com/

Download - The View From the Front: Publisher's Note Changes …...both subclassing and subtying, as some describe it). Most of its previous stereotypes have been eliminated, except for "implementation",

Top Related