This is the next entry in my series of tutorials on how to effectively use the Rational Software Architect (RSA) product to design, construct, and test software-centric systems.
In the last post, I talked about Rational's version 6.0 design and construction products, including how the different products relate to each other and the different features that each possess. RSA has many, many features and can be used for many different purposes, but for these tutorials we'll be focusing on using RSA to visually model software systems. In this particular tutorial, we'll discuss the reasons that we model visually and introduce the Unified Modeling Language, or UML.
Please note that discussions on modeling often get very abstract and theoretical. Though modeling theory is very interesting, I will keep this tutorial very concrete and basic, so as not to frustrate folks who are new to these topics.
If you're reading these tutorials I assume that you have some experience designing software-intensive systems. If this is the case, it is very likely that at some point you have drawn a diagram to represent aspects of your system. Why do you do this? Why do you draw diagrams of your system and its parts?
I'm serious, think about it for a minute.
We draw diagrams because it helps us to understand and reason about these very complex and very intangible things we call software systems. We draw diagrams because it helps us to capture knowledge that is hard to express verbally. We draw diagrams because it gives us something tangible to discuss with colleagues. We draw diagrams because, of the many moving parts inside a complex system, we only want to consider a few of them at the moment and ignore the rest.
So what sorts of diagrams do people draw to communicate software design? People often draw diagrams like the one below:
An example of a typical architectural diagram
At first glance this looks like a fairly useful diagram. But upon closer examination it has some major problems. What do the boxes represent? Applications? Components? What do the lines represent? Data flow? Service invocation? Why is one of the boxes blue while the others are yellow?
The problem is that all of the elements in this diagram - boxes, lines, arrows, and words - lack precise meaning. A reader of the diagram, for instance, may interpret the arrows to represent service invocation, while the author intended them to represent data flow. More likely, the author of the diagram never really considered what the lines meant.
There are a number of ways to avoid this ambiguity. The first way is to create a simple key that describes the meaning of each diagram element; like a roadmap will indicate which type of line represents an interstate highway and which type of line represents a country road. But if everyone invents their own notation, there is a learning curve to look at a diagram from anyone else because their notation is different from yours.
Members of the object-oriented (OO) software community found themselves in a similar situation in the early 1990s. The growing popularity of OO programming languages like Smalltalk and Objective-C led to the creation of a number of OO methods that documented techniques and best practices for OO design. Unfortunately, these different methods, though in basic agreement on the most important concepts and practices, used different terminology and notation, leading to a great deal of unnecessary confusion.
Grady Booch, Jim Rumbaugh, and Ivar Jacobson of Rational Software (now IBM Rational), three very popular and influential methodologists, decided to work together to unify their various methods and create a common set of concepts, terminology, and notation to describe software systems in a consistent way and make life easier for practitioners. They called this the Unified Modeling Language, or UML. The Object Management Group (OMG) adopted UML as its standard approach for object-oriented modeling in 1997 and has managed the development of UML since then.
UML defines a set of object-oriented software concepts (e.g. "class", "subsystem") and the relationships between these concepts (e.g. "association", "generalization") as well as a number of diagram types to visualize these concepts. Though UML is not formally defined using mathematics, it is "formal enough" to allow tool makers (such as Rational) to provide UML modeling and drawing tools and for practitioners from different teams to understand each others' UML diagrams.
Since UML's creation and standardization, it has emerged as the most popular general purpose language to model software systems. There are many tools that support UML and many books that describe its notation and how to apply UML to software projects.
Still, UML is not without its flaws. It is a very large language and it was created by a committee, so it's not always self-consistent. The OMG recognized some of the problems with UML and decided to give it a major overhaul. This resulted in the UML version 2.0 standard which was finally accepted last year. UML 2.0 cleans up many of the overlapping and incorrect concepts found in prior versions. Rational Software Architect and Software Modeler use UML2 and thus it will be the language that we use in these tutorials.
So going back to the diagram above, there is one very positive thing to say about it; it is easy to draw. Fire up PowerPoint, drop in a couple of boxes, some arrows, a few words, and in just a couple of minutes, you're good to go. But you must ask yourself: will the readers of your diagram understand what it's trying to convey if its notation is ambiguous? You could argue that your particular team already understands the systems involved so well that it will make sense to them, but in that case, why even draw it? Also, it is likely that your diagram and the system it represents will continue to be read after you have moved on from the project, so this argument doesn't really hold up.
Now just as the semantic-free diagram was easy but meaningless, UML is meaningful but challenging to the uninitiated. There are two reasons for this. The first is that you have to learn UML's collection of concepts and notation, which is rather large. The second reason is that specifying something with precise semantics involves more rigor than just drawing anything. For instance, PowerPoint won't spit out an error if you diagram something that doesn't make sense; RSA will.
Yet despite the learning curve, it is my opinion that understanding UML is worth the effort. In your effort to learn UML, you will gain a much deeper and more precise understanding of software concepts; you will also be conversant in the emerging lingua franca of software architecture.
So what's the best way to learn UML? First, it really helps to have a background in object-oriented analysis and design, since UML is built upon OO's foundations. If you're new to OO, a great book to start with is Craig Larman's Applying UML and Patterns (3rd edition). Not only does it provide a good introduction to OO, but also to UML and iterative development.
Once you understand OO fundamentals and are ready to focus on UML, I'd recommend a concise overview book like UML Distilled by Martin Fowler. You could be ambitious and dive into the thousand-odd-page UML2 specification, but you'd probably just end up discouraging yourself (it's really targeted at tool-vendors, not end-users). Another good learning mechanism is to experiment with modeling tools like RSA or RSM, which enforce UML rules and provide context-sensitive help on notation.
There's actually quite a bit more to say about UML, but I don't want these tutorials to bury you in theory before you've gained some practical experience using RSA. Be warned, we have only seen the tip of the UML iceberg, but this will be enough to get us going. In the next tutorial, we will gain some practical experience with RSA and UML by creating our first UML model and a basic class diagram within the model.
In the meantime, I highly recommend that you invest some time and money in the books mentioned above and below.
(Note - there are many books on the market that describe UML version 1.x. Because of the fact that RSA/RSM support UML2 and the fact that UML2 is very different from prior versions, favor UML books that have been updated for UML2. The editions of the books mentioned below have been).
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition) by Craig Larman.
UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition) by Martin Fowler.
The UML User Guide (2nd Edition) by Grady Booch, Jim Rumbaugh, and Ivar Jacobson.
Rational's UML Resource Center
"The Value of Modeling" by Gary Cernosek and Eric Naiburg.
Other IBMers who blog about UML
Thanks to Anand Narayanan, Bobby Woolf, Charles Rivet, Jim Rumbaugh, and Simon Johnston for providing feedback on earlier drafts of this article. Thanks to Grady Booch and Simon for their mentoring on visual modeling and UML over the past two years.
Jazz platform development
with Tags: tutorials X
I mentioned yesterday that I'm going to start an experiment of mentoring some IBMers on the effective use of Rational Software Architect via this blog. This is the first real post on this topic. If you have no interest in the Software Architect tool, you may as well stop reading now.
In late 2004, Rational announced a new wave of desktop products, codenamed the "Atlantic" wave. Each product was built on top of the Eclipse v3.0 platform and packaged based on the different roles in the software lifecycle. They included:
Tools for Design and Construction roles:
Tools for Software Quality roles:
So lets assume that you have the title of "architect" (or something thereabout). Which one of the above tools above would you use? Your first reaction would probably be: "I'll use the Software Architect product of course!" but before I'd agree with you, I'd ask you to describe the key activities that you, as an architect, perform. This is key, because different groups define the role of the software architect differently.
To grossly simplify a complex argument, let's just say that we have two basic types of architects:
Now looking at the tools above we can safely say that the Software Modeling product, with its focus on pure UML modeling and requirements integration, supports the type of architect who doesn't write code, while the Software Architect product, which includes both UML modeling and coding tools, supports the type of architect who does write code.
The Software Architect product is quite simply a superset of all of the other Atlantic desktop products. It has all of the development capabilities of Application Developer and Web Developer, and all of the modeling capabilities of Software Modeling, plus several features that are unique to it including model-to-code transformation capabilities, integration with the Rational Unified Process (RUP), architectural discovery capabilities (a.k.a. structural analysis), and C++ tools. A comparison of the tools and their features in the tool stack below. In this diagram, the colored boxes represent products. Also, if one product is above another in the diagram, it includes the features of the product(s) below it. Since Software Architect is at the top of the stack, this indicates that it includes the features of all other products.
Relationships between several of the Rational Atlantic desktop tools; tools higher in the stack include tools lower in the stack (click to enlarge)
Because of the fact that Software Architect includes everything, it is naturally much bigger than Software Modeler. Luckily, most people these days have more disk space than they could ever use, so this shouldn't be an issue. Also, Software Architect is more expensive than Software Modeler, which may be an issue for some people.
Almost all of the architects in my IGS Systems Engineering and Architecture department are architects who do not code, so it might make sense for these articles to focus on Software Modeler. But I'd like to keep my options open to eventually delve into model-to-code transformations and application analysis, so I will focus on the Software Architect product.
So the first assignment for anyone following these tutorials is to get the tool. If you work for IBM, you can get it internally from the Xtreme Leverage portal downloads page. If you do not work for IBM, you can get a trial version from the Rational trials and betas page. As I said before, it's big. Go ahead and download all of the different pieces (even the optional ones) to ensure that you're not missing functionality later.
So that's enough for an initial entry on learning Software Architect. In the next entry, I will discuss the origins of the Unified Modeling Language (UML), how modeling fits into the software lifecycle, and some of the controversy surrounding formal modeling.
For some perspective on the controvery surrounding the role of the architect, you may enjoy the article "Who Needs an Architect?" by Martin Fowler of ThoughtWorks.
Thanks to Emeka Nwafor and Charles Rivet of the Software Architect / Software Modeler product management team for their help on explaining the different capabilities of the different tools. Thanks to James Governor of RedMonk for some valuable advice on using the blog as a mentoring mechanism. Thanks to Bobby Woolf for pointing out that I hadn't defined what "Atlantic" was in the original post (since revised).
Technorati: rational software architect, rational software modeler, software modeling, uml
One of my responsibilities in my IBM Global Services Systems Engineering and Architecture group is to build up our skills in relevant software engineering tools. For client engagements where we have someone playing a consulting architect role, we're moving the department towards the standard use of the Rational Software Architect and Software Modeler products.
For modeling software systems, traditionally our more junior architects tend to use PowerPoint or Visio, while our more experienced architects use Rational Rose or XDE (which are now bundled as one product). So ramping up skill on Software Architect and Software Modeler faces two types of resistance:
So to help encourage adoption of RSA/RSM and to help build up our skills, I'm starting an experiment on my blog. Over the next couple of months I'm going to attempt to write up an ongoing series of posts about how to effectively use these tools to design software-intensive systems.
My goal with this effort is two-fold:
I have some basic ideas of topics to cover, but I'm open to suggestions, so feel free to post a comment below or send me an email if there's a general modeling topic or a specific RSA/RSM topic you'd like me to cover. Additionally, I've asked several members of the RSA/RSM team to monitor these posts and elaborate on key points and point out any mistakes I make. Hopefully they'll take me up on this offer.
Look for a first post later this week on the differences between RSA and RSM which should help you decide which one is right for you.
In the meantime, I'd like to suggest that you read the article "The Value of Modeling" by Gary Cernosek and Eric Naiburg, both of IBM Rational. It provides good background on why you should care about modeling in the first place.
Technorati: rational software architect, rational software modeler, software modeling, uml