Added By: Feedage Forager Feedage Grade B rated
Language: English
architect  case  cases  good  model  much  product  rational rose  rational  rose  software  support  tools  uml  version 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics

Last Build Date: Tue, 06 Mar 2018 08:47:14 +0000


Outlines for Courses I Teach

Fri, 22 Apr 2011 20:23:00 +0000

Hear are some outlines for courses I teach or have taught in recent years...

(image)  Intro to C++ for the Microsoft .NET Framework, Spring 2004

(image)  Intro to Rational Requsite Pro, Spring 2009

(image)  Intro to Rational Rose, Spring 2009

(image)  Intro to UML, Fall 2009

Rational Rose is alive and well with Version 7.

Mon, 24 Sep 2007 12:29:00 +0000

Rational Rose is getting more support from IBM with a new release for June 2007. The new version is called "Rational Rose Version 7". What is really interesting is that Rose XDE has been withdrawn and the migration path for the XDE product is back to Rational Rose (see June 2006 announcement).

The product line follows past versions with a basic modeling version (no code generation or reverse engineering), developer versions for C++ and Java, a data modeling version, and the "Enterprise" version which includes just about everything.

Product support include a version that runs on Linux. There is also a "real-time" version, what some people used to call "red box" Rose, with a version that is now called "Rational Rose Technical Developer". See the product information sheet (PDF) for additional information that compares the products, describes the system requirements, etc.

Trial versions are available for download from the IBM download page.

I've downloaded and had some hands-on time with the Version 7 trial. It preserves the same basic interface, menus, features, etc. as with the 2000-2004 versions. The product is so close to the previous versions that I was still able to use Quatrani's books on the 2002-2003 versions as the lesson guide for students in a recent class.

Rose V7 remains strong as a UML 1.4 product (with some UML 2 notation possible). It also remains strong for modeling independent of code or models that need to connect to code in several languages (C++, Java, XML, SQL, etc.).

Still, Rose V7 may not be the best fit for every project needs. Some projects will be better suited with Rational Software Architect or another product.

With IBM's June 2007 announced acquisition of TeleLogic, it remains to be seen how that product or it's technology will impact the established Rational product line.

- Brian

UML References

Thu, 26 Jul 2007 04:03:00 +0000

Here are some of my recommended references for the Unified Modeling Language (UML) with and emphasis on UML2.

Model-Driven Architecture?

Thu, 15 Feb 2007 21:35:00 +0000

I have mixed reaction to some of the current enthusiasm on Model-Driven Architecture (MDA). Some of it is good stuff but much of that is actually just new names on long established ideas. Some of it is arcana that I can't make heads or tail of and this part seems to have little impact or benefit to practical systems development.For example, a prominent element in Model Driven Architecture (MDA) is the difference between the Platform Independent Model (PIM) and the Platform Specific Model (PSM). Conveniently, these terms mean pretty close to what you would guess from the words. They are also very similar to the definitions of an "analysis" model versus a "design" model in the guidebook for my first job out of college... over 20 years ago. So, good ideas about the benefits of having levels of a distinction between "what" is to be built and "how" it gets built....but hardly novel. It is also valuable to have a model because "model" conveys the expectation of completeness. It allows one to impose a little more engineering rigor than is common in free-text narratives of the system behavior. For example, in a model, you can do things like test for the logical correctness of a system based upon all the combinations and permutations of system inputs. You can check for race conditions and boundary conditions.... good stuff as well. It is valuable to be able to go from "dumb" pictures in Visio, to a systems engineering model in Rational Rose, and from there to "executable UML" (another MDA) buzzword that lets you run your model to observe the behavior and validate the results. Again, cool but several real-time engineering tools like Rose RealTime, Rhapsody, and Popkin System Architect with the appropriate plug-in) have supported this functionality for years. There is also a pretty long history out there for related simulation tools (e.g. Simulink)...though more common in other industries (e.g. defense or telecomm).So, there are good parts to MDA but I'm at a loss to see how many are innovative. It is handy to have a new buzzword and to have some new enthusiasm for some old ideas. It also seems to be an effective vehicle for popularizing into general business systems development some ideas from real-time, mission-critical, etc. systems development....which is appropriate given the increasing complexity and criticality of modern software-intensive business systems in a highly connected world. There are also some parts of MDA that strike me as impractical and I just don't get why people spend so much time writing papers or going to conferences on these ideas.The first is the idea, or the expectation, about how automated the translation should be from the platform-independent model to the platform-specific model. This is an idea we (humanity and specifically the IT community) have been chasing around for years.....what a waste of time. It sounds good, that with a "click-click" and "drag-drop" we will be able to express our business functionality and the technical specifics of generating code, configuring servers, etc. will happen for us automatically (at this point speakers on this topic are usually making a dismissive hand waving gesture). There is a germ of a good idea here (see analysis v. design above) but taken too far it is just impractical. Products and technologies in a competitive capitalist society necessarily differentiate themselves and we (hopefully) deliberately select the elements of the technical architecture (language, database, rules engine, web app server, etc.) on those differences. So, when MDA zealots ignore this then they fly in the face of huge amounts of human endeavor....and continue to lose. Another way of looking at this problem is that there is a vast set of tools that are proceeding nicely to be used for all sort of projects....and there are no mechanisms to support these tools within any significant MDA toolkit.Kennedy-Carter is a pretty popular MDA influenced tool (supports C++) but neither it nor any other tool supports A[...]

Rational Rose versus Rational Software Architect

Tue, 05 Dec 2006 20:55:00 +0000

IBM/Rational currently offer two products to support analysis and design using UML.  The first, and older, product is called Rational Rose. The second, newer product is called Rational Software Architect.  Each has its merits, and drawbacks, so it is only prudent to evaluate the differences in order to make an informed selection or to use the chosen tool properly. Support.  Rational Rose is the elder product and has been around since the early/mid 90's - Rational Software Architect is a much newer product.  Because Rose is older, there is a much larger installed base of documentation (books, white papers, commercial courses, etc.) on how to use the tool and a much larger installed base of practitioners.  Organizations are also much more likely to have an installed base of product (i.e. licenses) which they apply to a project/program needs for modeling. IBM is very enthusiastic about supporting Architect but the reality of the total support situation in the IT world is that (for now) Rose still has more resources in this area. Support for UML 2.  Rational Rose is fundamentally a UML 1.x tool and Rational Software Architect is intended as more of a UML 2 tool.  The differences here are not enormous (since most of UML 1 is still a part of UML 2) and may not mean very much if your project lacks UML 2 needs or practitioners.  The gap is also narrowed in that many of the enhancements in UML 2 (e.g. regions in sequence diagrams) can be improvised fairly easily in Rational Rose.  Finally both omit support for some UML 2 features - including some of the ones which are the most novel and potentially valuable. Language (C++, Java, etc.) Support. Rational Rose provides at least some level of modeling (code-generation and reverse-engineering) for a very large number of programming languages - including C++ (ANSI and Microsoft API), Java (J2SE and versions of J2EE), XML, Database, Ada, Visual Basic, etc.  While the language support in Rose is broad, it isn't very deep and the tool is best thought of as a design tool that can be coupled to some of the code - I've rarely found full code generation (or reverse engineering) between any language and Rose to be effective.  In contrast, Architect primarily supports Java and C++ only but does so much more deeply.  In this regard Architect draws from the XDE legacy and can not only be used as a design tool but as uber-IDE tool.  Whether tight integration between the analysis/design effort and the coding is necessary, or a good idea, depends upon the project. Support for modern design techniques.  In this area Architect enjoys an advantage - though some improvisation can be done in Rose.  For example, while patterns have been part of the UML/OOAD world for many years now, Rose does not have any specific support for patterns - the modeler has to do all the work "by hand".  Architect is more similar to the contemporary competitors (e.g. Borland Together) in providing more explicit support for pattern-based modeling.  Similarly, Rose draws from a tradition of analysis/design as more discrete from requirements, testing, etc. - Architect draws more from the traditions of RUP and XP.  On can argue about if iterative and overlapping the development disciplines is a good idea but, if you've chosen this route, you will probably find Architect better suits your needs. Extensibility.  Both tools provide mechanisms for you to customize or extend the tool but do so differently.  Rose provides the Rose Extensibility Interface (REI) which is basically a VB-like scripting engine.  It is pretty powerful as demonstrated by that most of the items on the Tools menu were at one time products of a cottage industry in Ro[...]

Some Use Case Guidelines

Fri, 10 Nov 2006 01:57:00 +0000

Here are just a few suggestions:Use Cases generally are broad enough to contain alternative scenarios.  For example, a use case to "Sell Products" might contain the scenario of selling a UPC coded item and also a scenario for selling an item that has to be weighed on a scale.  This is why UML models have activity diagrams (which, like flow charts, can contain branches and loops in the logic) and can have attached to them multiple sequence diagrams (for various scenarios thru the use case).  So if you have a use case that doesn't contain alternative scenarios, that suggests it isn't really a use case. The breadth of scenarios generally varies by more than the fine grained data inputs.  For example, while selling an item that costs $1.50 could be considered a different scenario than selling an item that costs $9.45, this doesn't add much breadth.  We get appropriate breadth in a use case when the contained scenarios not only vary by value but also by repetition, by order, and by participation.  So, for our Sell Products use case, it adds more meaning to capture the scenario about buying several items and then getting a discount, about being able to display the total even though all the items aren't priced yet, and taking a credit card rather than accepting only cash.  All of those variations, and their collaborations, fit beneath the use case. The scope of a use case usually is in terms that justifies a sub-system or system to the use (actor).  So, you shouldn't have a use case called "Login" because no business stakeholder ever bought a system for the purposes of logging in.  Selling Products, Detect Aircraft, Identify Employee, Pay Taxes, Transmit Cargo, etc. are good use cases by this standard.  Login, Update Database, Display Results, etc. are much too fine-grained to be use cases by this standard.  It isn't uncommon for a use case to have a level of abstraction that is on par with release - e.g. a release may contain scope in the range of a couple of use cases to scenarios of a use case. There generally shouldn't be a similarity between the use cases on the Use Case Diagram and the activities on the Activity Diagram.  If your Use Case Diagram has use cases called "A", "B", "C", etc. then generally you shouldn't see the same names for activities ("A", "B", etc.) on the Activity Diagram.  You might see this for a very high level activity diagram for the system as a whole that shows the flow through the system uses from the scale of the external actors - even so, the scale is as the uses level - Sell Products, Transmit Cargo, etc. and not Login, Update Database, etc.  More often, your high-level activity diagrams are at a level of abstraction below the use cases.  So, if the use case is Sell Products, then the activities are Price Item, Weight Item, Collect Payment, etc. The comments above reflect what I would consider mainstream use of Use Cases - influenced heavily by Jacobson and the influence he had on Use Cases and UML coming out of Object Oriented Systems Engineering (OOSE).  One of the guiding factors is that general use of Use Cases is as a part of a model that includes many other UML diagrams.  In that case, you use Use Cases in a certain way because other work is done by other diagrams.  That is amplified by how most of the current UML tools work - the Use Case diagram implementation is relatively modest and more capabilities are put into the other diagrams. If you are primarily, even exclusively, using Use Cases then some other factors come into play.  It would be easy to dismiss such a plan as a "when all you have is a hammer the world seems full of nails" approach but there is some legitimate work in this area.  Cockburn's Effective Use Cases has a much more elaborate approach to use cases as do some of t[...]

Open-Source UML/XML/Java/etc. Course Materials

Tue, 15 Aug 2006 18:21:00 +0000

I am converting much of my personal (not done for MITRE or any other employer) work into open-source or creative commons works that are available to the public. The bulk of this material will be in the area of UML/OOAD or in related areas like MDA, Java development, etc. and from the book reviews, presentations, course materials, etc. I've done.  My model for this effort is the Open CourseWare project at MIT. Some of these materials are from courses I teach at the MITRE Institute but they are all copyright to me and I've chosen to make them available to the public.  This was done in conformance with MITRE policy - specifically the incentive award program for instructors at the MITRE Institute.  Though copyright by me, my intention is for these to be "open-source" materials and they will all eventually be marked with either as either MIT Open Source, Creative Commons Attribution-NonCommercial or something similar.  That these materials were used for courses at the MITRE Institute does not represent an endorsement by MITRE of this material.  They are the work of me only and I am solely responsible for the information conveyed within them.  The copyrights of other, previous, employers are also being respected in this effort. Most of the material will be on UML because that is where I have the most material available.  I have been teaching courses on the Unified Modeling Language (UML) for almost 10 years now. Started in 1997 with Advanced Concepts Center  - formerly part of GE Space Systems, then part of Lockheed Martin Business Systems and now privately-owned as ACC Learning.  Later that year I became a Rational certified consultant and instructor.  I continued to work with the Rational materials while at the ACC and also while I worked at Number Six (2002-2003).  Since joining MITRE in 2003, I've given up public or for-profit courses and only teach thru the MITRE Institute.  One of the problems of working with for-profit teaching courses is that those materials are the property of the copyright holders and those companies keep pretty close hold on those materials because they are part of revenue producing lines of business.  This can make developing materials for the common good a bit difficult. In contrast, one of the benefits of working for a federally-funded research and development center (FFRDC) is that there are mechanisms to develop your own intellectual property and to contribute your work to the public.  You also get the opportunity to work on larger, broader and more demanding technical challenges.  So, I am combining both and following the example of the Open CourseWare project  in an effort to make as many of my lessons and presentations available to the public as possible. I don't have a slick website the way MIT does (at least not yet) but for now my UML materials are available on the web and to the public. I'm also posting materials on related topics such as Rational Rose and Rational Requisite Pro.  I have a list of courses and some presentations that I will convert/publish as I have the time to work on this.  The initial stuff you see probably won't have very much re-use value.  I've never put much effort into highly polished slides and relied more in my teaching on having a good dynamic, a good conversational flow, with the students.  As a result, most of my materials are "scraps" of ideas that I pull out as the need arises in the teaching situation.  Perhaps I am a better teacher than author and this whole idea may be a flop but we'll see. But going forward I'm going to try and make them more stand-alone - things that other people could incorporate into a mini-lesson or include as an appendix to a their own presentations/lessons&nbs[...]

Suggestions on using UML Associations

Tue, 01 Aug 2006 11:09:00 +0000

Here are some of my suggestions on using the UML association in Rose and other UML tools.... Arrows mean navigation and not data flow.  One of the most common misunderstanding in using the UML class diagram is to think that the arrows on the association relationships between classes convey data flow - they don't.  What they convey is navigation - who "knows" about whom or who "can get to" whom.  For example, if you have a class called "Mother" and a class called "Baby" it is clear that there is some relationship between the two.  In modeling the human participants, one can't navigate from a baby to the mother (asking the baby, "Who is your mother?" doesn't generally work) but only from the mother to the baby (The mother says, "This is my baby" or "That is my baby").  In this case the navigation arrow, at the analysis model level, is appropriately only indicating navigation from the mother to the baby.  However, in the implementation model, it might be valuable to be able to navigate from a baby record back to the mother record (e.g. thru some kind of foreign key) and in this circumstance it would be appropriate to model bi-directional navigation (arrows on both ends of the association relationship). To make it clear that navigation is different from information flow, reconsider the analysis model mother and baby classes. Even though the navigation is from the mother object to the baby object, once the mother has "navigated" to her baby there is plenty of information that comes back to the mother - crying when tired, requests for food, etc. Association navigation does not define object creation.  It is too far to assume that a navigation adornment (the arrow) on an association relationship conveys object creation.  It is quite possible, and common, that an object has a navigable link to an object that it did not create.  Consider objects of the class "Driver" and objects of the class "Car".  In modeling the use of automobiles it would be appropriate to have an association between the two (such a relationship obviously exists), to have the navigation from Driver to Car (remembering that data still flows back the other way) but to rely upon another class, "AutomobileFactory" for example, to have the responsibility of creating Car objects.  Driver objects can request Car objects from the Factory (Factory::CreatCar():Car) or the Driver objects can accept Car objects ( Driver::Accept(:Car) ) but in both cases the Driver isn't responsible for object creation - that is what the AutomobileFactory does. Association relationships without arrows have meaning but this can be confusion.  An association between two classes without navigation arrows may be understood in two ways - the navigation is unspecified (yet) or the navigation is bi-directional (the default for associations).  This is an obvious source of lots of confusion.  Many tools make it worse in that as the model is refined, the relationship may start unspecified (no arrows), acquire a navigation one-way (one arrow), but if navigation is added the other way the association reverts back to a line with no arrows.  Technically, this is correct but is sure is confusing.  How is the reader to tell the difference between an unspecified association and a bi-directional association?  Style guides can be help here - the team should document and develop a consistent usage in this area.   It is also a really good idea for models to learn from maps in this area....and include a legend that addresses how the notation was used for the diagrams shown. One association relationship with arrows on both ends is not the same as two one-way arrows.  The basic principle to remember here is that multiple association relationships are possible between cla[...]

Comparing Rational Rose and Rational Software Achitect

Wed, 19 Jul 2006 15:01:00 +0000

It is tempting to come to the conclusion that IBM/Rational has abandoned the Rational Rose product and that one must upgrade to the Rational Software Architect product - especially to get UML2 support.   That is certainly the position put forward by the IBM/Rational sales teams (and their business partners).  Development teams new to these tools might have good reason favor Architect but organizations already using Rose should consider if the switch is worth the effort. I 'd describe the situation with IBM/Rational and Rose slightly differently than to say "Rose is dead".  For example, the Rational Rose product is still for sale , still supported with training, and actively supported with patches, forums, etc.  I'd also assert that it remains a viable (though admittedly not "cutting-edge") product for UML2 work.It is true that IBM/Rational froze the version number/name at "Rational Rose 2003" for many years.   However,  IBM/Rational has continued to update the Rose product  - they have just kept these as point-releases underneath the "2003" version number.  It is not much of a secret that the main motivation here was to name/version the products in such away as to encourage customers (especially new customers) into the XDE and now Architect products. However, I use version "2003.06", there is a version "2003.15" available, and updates are available as recently as June 2006 - Rose is far from "dead".  If you go by product names, the "new" Rose is actually called "Rational Rose Enterprise 7" but users of Rose 2003 will find the product very familiar.  The differences between "Rose 2003", "Rose 2003.06" to "Rose 7" are proof that you can't tell much just from the name.  But what about UML2 support?  Rose supports UML2 better than you might think.  First, we have to remember that UML2 includes most of the UML1 constructs - so it is pretty easy to build models with UML1 tools that are still consistent with newer UML2.  Also, many of the notational forms formalized in UML2 were practices that people had been improvising on top of UML1 for years (e.g. regions in the sequence diagrams or iconic representations of stereotyped classes) - they may have become "official" with UML2 but Rose (and many other older UML tools) can support many of these constructs.  Finally, Rose (like most of the tools in this space) is very extensible.  So, there are mechanisms to add-on to the product many of the UML2 features/notations that your organization or project need. Finally, the cost and disruption to an organization isn't trivial.  Many organizations have struggled to accumulate the in-house tools and expertise they have now with the tools they have now - re-tooling gives them new products in a box but may undue much of their ability to execute.  Many of the people I see using any of the UML tools are hanging to some basic skills by their fingertips - it is actually frightening to imagine how far down the system development capabilities of these teams would fall if they had to start over with a new tool.  For most budgets are also factor - they can barely afford the maintenance on the existing tools (and many don't) so buying new or upgrades isn't realistic. Some organizations are also rightly suspicious of the "Rose is Dead" and "Switch to Architect" mantra given that IBM/Rational said the same thing about Rose and XDE a couple of years ago and has since withdrawn XDE...and the migration path for XDE customers is back to Rose! There are some areas of UML2 that Rose just can't support though and this should be factored into the decision.  For example, actions on the activity diagram.  There isn[...]

Using UML2 in Rational Rose 2003

Wed, 28 Dec 2005 18:51:00 +0000

Rational Rose hasn't had a major update in a few years (since 2003) and in the interim the UML 2 has come out so lots of people ask about using the UML2 in Rational Rose.   Here are my thoughts:
UML 2 is a super-set of UML 1.x.  The consequence of this is that lots of teams, projects and tools can claim they "support UML 2" using the same UML 1.x notation they have used for a decade or more.  Out-of-the-box Rose 2003 is geared to UML 1.x but the backward compatibility between UML2 and UML1 means that Rose 2003 supports lots of the UML2 notation as well.  It  is a cheap "win" but true.
Rose is highly configurable. You don't have to use Rose very long before you figure out  that there is an underlying repository/engine and on top of that is layered lots of mini-tools for various tasks - models can be viewed in Booch, UML or  OMT notation; you can associate your own icons with <>, the Rose model files are just structured text files easily scripted/manipulated by other applications, etc.  In short, if is far from rocket science to customize the Rose environment to support UML2 or almost any other notation/process/etc. you want. Not free but  possible.
The functional intent of some UML2 notation can be relized with Rose 2003 and UML 1 notation. A good example of this is in the new regions for Sequence Diagrams.  While UML2-style regions aren't supported in Rose 2003 you can accomplish the same purpose in how Rose 2003 provides comments that link one  diagram to  another. Lots of  other "UML 2" notation has  either been  long  supported in Rose or can  be easily improvised in Rose.
Does UML2 add value to your project?  Don't assume that UML2 is automatically better for you than UML 1.  Begin with the notational needs of the project and then select a notational solution - UML, UML2 and/or other. Forcing  arbitrary UML2 conformance may introduce only small changes that have big disruptions for little benefit.
If you have to ask, the answer is "no"...or "doesn't matter".  There is a big difference between a casual "blueprint" and one that can pass city inspection, be used to build a home, etc. - same with UML.  Even when used on serious projects, lots of UML documents are more glorified PowerPoint slides than engineered artifacts.  Many of the biggest, highest impact, UML2 features are intended for serious engineering use of the notation and they aren't accessible, effective, or safe for use by novices. 

- Brian Lawler

Books on UML2

Tue, 13 Dec 2005 16:21:00 +0000

UML 2 Toolkit - For those of you with some UML skills but looking to catch up on the UML 2 updates, I recommend the book UML 2 Toolkit published by OMG press. Make sure you get UML2 Toolkit and not UML Toolkit. One of the reasons I like the UML2 Toolkit is that it does a good job of making clear the changes/additions/etc. in the UML2 - most chapters have a section at the end titled "Relevent Changes in UML 2".

n.b. I know two of the author and am mentioned in the credits of UML 2 Toolkit but do not profit from the sale of this book. UML User Guide, 2nd Edition - Updates the widely popular text on the UML. Be sure you get the 2nd edition for the UML2 material. Covers almost all of the UML - even the parts you will rarely use. UML Distilled, 3rd Edition - As the title says, a distilled version of the UML and a great one as well. Focuses on those parts of the UML you will use most often. Be sure you get the 3rd edtion for the UML2 material. n.b. Booch et al. in the UML User Guide and Fowler in UML Distilled cover material on which there remains some dispute. For example, they contradict each other on the expanded/revised notation for the activity diagrams.

References on 4+1 Architectural Views (OOAD/UML)

Mon, 12 Dec 2005 20:44:00 +0000

"The 4+1 View Model of Architecture", by Philippe Krutchen, IEEE Software,  November 1995 - One of the definitive works on this topic.  This is available on-line via the IEEE's Computer Society website at in the Digital Library.  It is also available thru the ACM's digital library at  You may also be able to find PDF scans of this document by doing a Google - especially of .edu sites since it is so often included as a course handout.

"Documenting Software Architectures: Views and Beyond" by Clements et al, 2003. Covers the more general topic of documenting software architectures but includes discussion on using UML, the 4+1 Views, and related topics.  See

"Architectural manifesto: Designing software architectures, Part 5: Introducing the 4+1 view model" by Mikko Kontio, published on IBM developerWorks, 02 Feb 2005 - This is in the midst of a series on wireless development but still provides a good 1-2 page summary of the 4+1 views. See:

The "Handbook of Software Architecture" at by Grady Booch. Includes a 2004 presentation on software architecture that discusses software architecture in general and includes several slides on the 4+1 views.  See: