Posts in the “uml” category

Every once in a while when your brain runs into a new concept, you really remember it: it stands out in your mind as an “Aha” moment. One of those moments for me was when I saw a particular “Model/View/Controller” (MVC) diagram, and the light bulb went on. This diagram made the MVC pattern very simple, and I’ve never forgotten it.

The Model / View / Controller diagram

The MVC diagram I’m talking about comes in two parts. The first MVC diagram shows the symbols the authors use for Model, View, and Controller objects. Here’s that diagram:

I was just updating my Example UML Use Case diagram article and it occurred to me that if you're a Business Analyst, there are a couple of questions you can ask yourself as you write a Use Case (or User Story) that will help improve the quality of your writing. Two questions specifically come to mind:

1. What are the main points of this use case? (Which might also be phrased, "What points about this business process do I need to make sure everyone really agrees about?")
2. Are the statements I've written testable?

UML Use Case FAQ: Can you share an example of a Use Case diagram?

As I've been preparing to let other writers write on the devdaily.com website, I started to think about what different things (processes) an author would need to do on the website. As I thought about this, I started realizing that I was once again thinking like a business analyst, and then I thought I'd create an example UML Use Case diagram to show these processes.

Model View Controller pattern FAQ: Can you provide some examples and definitions of MVC objects?

Earlier today I shared a Model View Controller (MVC) diagram that I think really simplifies the MVC design pattern. It lays out the interaction rules between MVC elements, i.e., which objects can communicate with each other in a proper MVC design.

In my Use Case quality article yesterday I wrote about a "User Story" for a fictional "User Logs In" requirement. To complete that article, I promised to write a Use Case version of that same user story. Here then is that sample "User Logs In" Use Case, which you can compare to yesterday's User Story.

Quite often when I’m asked to review a UML “Use Case” that someone else has written, I ask “Have you tested your Use Case with real data?” Sadly, the answer is usually “no.”

I don’t know why people don’t do this, but they don’t, and it seems like a very logical thing — essentially a unit test for Use Cases.

Here's a simple but interesting quote from a "Use Case" book I was reading last night: 

"If the actor is not part of the system, then the requirements cannot be a part of the system."

This statement seems obvious, but reflecting on some of my own work I can see where I have occasionally strayed in this direction, and having reviewed the work of other people, I have often seen these types of requirements in requirements documentation.

I took some time yesterday and reformatted my free example software requirements specification, whittling it down to 36 pages, from the original release, which was over 200 pages. As you might guess, the new pages are longer, and I've also reformatted the specification, both of which help to make it much easier to read.

Summary: A collection of UML Use Case examples (software requirements examples), based on a "real world" project.

I've been taking a little time lately to document a lot of what I know about UML Use Cases, and today I thought I'd take a few moments to link up to Use Cases I wrote for a client back in 2004. The client graciously allowed me to reprint these on this website, as long as I removed their name from all the documentation.

Free UML software tools FAQ: Can you recommend any free UML tools?

Over the last week or so I've been looking around again at free UML tools, and one that has really stood out is UMLet. While most UML tools try to do a lot of things, UMLet takes the "UML as sketch" approach, which I've generally come to agree with.

Last night I ran across a software requirements specification that I meant to share out here a long time ago, but unfortunately I never did. I created this software requirements specification for one of my customers, and they kindly gave me permission to publish this document out here (after I took out a few things specific to their business).

Summary: Notes on using Visio for UML diagrams (mostly why I don't like to use Visio).

I think it is okay to use Visio for UML diagrams when you're not going to be doing very many, especially if you already own a copy of Visio. But once the application you're modeling gets to be substantial at all, Visio has a major flaw:

You're trying to model a software application that has a data model with a drawing program.

To me, that's not a very good idea.

Note: Amazingly, I wrote this review way back in 2007. I just tried to use Poseidon UML again in 2010, and I wouldn't change a word of it. (Okay, I'll change one thing: I now use UMLet instead of MagicDraw UML.)

I don't know if you've ever had UML use case burnout, but I think I just hit the wall. Here's a link to some use case prose that shows I've written way too many use cases recently.

Maybe this is a good way to know when you need a vacation?

Question: I want to show how my application classes are segregated into packages. Is there a UML diagram for this?

Yes, you pretty much named it. A UML package diagram is good for demonstrating the packages (or packaging) in a software application, as well as the dependencies between packages.

Question: I want to look at the relationships between the classes in my software application. What UML diagram should I use?

UML Class diagrams are very good for showing the static relationships between classes, such as inheritance and aggregation, one to many relationships, and many other class relationship details.

Question: What UML diagram can I use to show how my application will be distributed in the real world?

Use a UML deployment diagram. They can be used to conceptually show the physical nodes and software components that will be distributed in a software application.

Question: What UML diagram can I use to show how an object state changes during its lifetime?

A UML state diagram will do the trick. A state diagram is very good for showing how an object state changes over the lifetime of a software application, and the triggers (triggering events) that cause the state to be changed.

Need to show how objects collaborate during the lifetime of a software application? You'll want to use a UML interaction diagram -- either a sequence diagram or a collaboration diagram.

I prefer the sequence diagram, because the time sequence of events it displays more easily demonstrates the interaction of objects over time, but other developers prefer collaboration diagrams.

Question: I want to visually model a multi-threaded software application. Can UML help?

Yes, UML activity diagrams can be a great tool for visually modeling the flow of control in a multi-threaded application. A UML state diagram can also be used to show the states objects can be in during their lifetimes.