As many of you know, a while back, John Rooney and some other forward-thinking IBMers created an internal blogging portal for IBM that we call "Blog Central".
Alex Barnett of Microsoft blogged about IBM's internal blogs a few couple of weeks ago, and he included a screenshot that Phil Borremans recently posted on his blog.
Unfortunately, Phil showed a view of the blogs of a non-authenticated user, which basically just shows a list of recent postings. However, if you log-in to IBM's internal Blog Central, you get a very useful personalized view of your recent entries, and recent discussion around your entries and comments.
I've included a screenshot of the personalized view below for posterity.
Personalized view of IBM's internal blogs (click to view full size)
PS - I've obscured all of the email addresses, except my own, to protect the guilty.
contact me: firstname.lastname@example.org[Read More]
Jazz platform development
For the three or four of you who read my blog when it launched back in last October, you may remember I wrote a post about the apparent insanity of the Sun Java marketing group with regards to Java naming.
Here's an old (but real!) quote from Sun that I used in that post to demonstrate the then current state of affairs:
Due to significant popularity within the Java developer community, the development kit has reverted back to the name "JDK" from "Java 2 SDK" (or "J2SDK"), and the runtime environment has reverted back to "JRE" from "J2RE". Notice that "JDK" stands for "J2SE Development Kit". The name "Java Development Kit" has not been used since 1.1, prior to the advent of J2EE and J2ME.
Well, they're at it again, but this time making the "Java naming architecture" (as they call it) a little easier.
Henceforth, the legacy "2" will drop from the different editions, so J2EE becomes JEE, J2SE becomes JSE, and J2ME becomes JME.
Bravo. Viva simplicity. Viva common sense.
PS - Bobby Woolf and Ted Neward wrote about this as well.
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.
For my series of tutorials on Rational Software Architect, I've been busy working on the next entry, a primer on the Unified Modeling Language. Unfortunately, it's taking longer than I expected, but it's coming along.
In the meantime, I just noticed that Addison-Wesley has a couple of very good UML books on sale for 35% off. If you're serious about becoming expert with Rational Software Architect (or Software Modeler), I highly recommend you pick up one or both of these books. They are:
Note that both of these books were originally released in the late 1990s. Thse second editions have been fully revised to reflect the many changes present in UML version 2.
The Reference Manual includes a CD with an electronic version of the book, which is really handy if you want to quickly look up the definition of some element.
billhiggins 1000006JUS 383 Visits
I've been writing about the Genographic Project. Just saw the following on the IBM intranet:
The Genographic Project, a joint research initiative between IBM and the National Geographic Society, will make its American television debut this month. "Search for Adam," an episode of the "Explorer" program, will air Sunday, June 26, at 8 p.m. ET/PT on the National Geographic Channel. Encore presentations are scheduled for Wednesday, June 29, at 2 p.m. ET/PT and Saturday, July 2, at 7 p.m. ET/PT.
Check out the Explorer program's web site where they have a blog entry about the "Search for Adam" episode and a video preview.
Next stop, Tivo (because I have a horrible memory and would otherwise forget!)
Apple is famous for their ability to design very usable products. The iPod is the first Apple product I have ever owned or used, and I'm starting to understand why Apple has this positive reputation.
A few examples of the little things that Apple thought of to make the iPod more enjoyable:
These things may seem trivial individually, but all of them (and there are more) together result in a very enjoyable user experience.
Check out this article by Raymond Chen of Microsoft. It discusses some early usability problems with the Microsoft Windows date/time utility (this thing). This anecdote is a great example of how a designer's intended use case for a software tool can end up differing wildly from the way that the end-user uses the tool in practice.
"But you're not supposed to do that!"
For those who are interested in official company press releases, you may not have known, but IBM actually makes these available for syndication via RSS.
If you don't know what RSS is:
Now Ethan, when will there be Atom feeds of the press releases, since we love open standards here at IBM?
Join us tomorrow (Tuesday, June 21st) for the next Raleigh/Cary Bloggers meetup.
Here's a write-up I did of the last one.
What: An open meeting to talk about blogging, podcasting & whatever's on your mind
When: Tues @ 6:30 p.m.
Where: Cafe Cyclo, in Cameron Village
2020 Cameron St
Raleigh, NC 27605 (map)
Who: Bloggers & people who want to blog (Podcasters welcome!)
Feel free to email me (email@example.com) or call my cell (919-672-7993) if you have any questions.
People often rhapsodize quite breathlessly about the power of blogging. In the past I tended to put this off as transient excitement about the latest fashionable technology.
In a recent posting, I mentioned that despite the fact that Apple dropped IBM as its processor supplier, I was still eager to pick up one of those snazzy iPods. Well, that very night, one of my most faithful readers contacted me and offered to buy me one for my birthday. I graciously accepted and am now the proud owner of a snazzy new 20 GB iPod.
To the faithful reader let me simply say: thanks Mom!
This is off-topic, but it impressed me so I decided to blog it.
I was reading an article on Spielberg's upcoming War of the Worlds and really liked the following:
...while Steven Spielberg was shooting "The Terminal" in Montreal, screenwriter David Koepp flew north with a list of cliches that he believed "War of the Worlds" had to avoid. "Here are the things we could not have in this movie," Koepp says. "One: no destruction of famous landmarks. Two: no unnecessary beating up of New York City. Three: no politicians or scientists or generals as main characters. Four: no shots of military leaders pushing ships around on a big map with sticks. And five: no shots of world capitals."
Halleluja. Now I really want to see War of the Worlds; before I was thinking, "bleh, another big budget disaster movie".
PS - If you don't understand why this is a good sign, watch a few recent big budget disaster movies in a row and you'll see. E.g. Armageddon, Independence Day, Godzilla, The Day After Tomorrow, The Core, etcetera, etcetera, etcetera ...
I continue to believe that the term "requirement" is one of the most ambiguous and ill-defined terms in the software engineering lexicon (along with "component" and "service").
I was just reviewing an internal presentation on the Systems Engineering extension to the Rational Unified Process and read something that concisely states one of the key sources of the term's ambiguity:
Requirements are contextual; one person's design decision is the next person's requirements
Bingo. Thank you Murray Cantor.
billhiggins 1000006JUS 452 Visits
I made a few changes to the Rational Software Architect tutorial part 1 post below based on some very valuable feedback from Charles Rivet on the features in the different tools. I redid the diagram from a Venn diagram into a software stack diagram. This is because there are several important features common to all of the tools and this was difficult to show in the Venn diagram (not the overlapping circles, but rather putting readable text in overlapping circles).
It's going to be my policy on these RSA Tutorials that I will correct any factual errors at any point in time. Normally I don't change blogs after the fact, but these aren't simply journal entries or opinions; they're meant to educate people on the tool, so I want them to be as correct as possible.
To be clear, I will only change factual errors; if I state an opinion or make a judgement that I later regret, I will let this stand.