Skip to content

UML Modeling Myths


Michael Chonoles, the author of “UML 2 for Dummies”, talks about “Modeling Myths” – damaging misconceptions people have that prevent them from adopting modeling in their projects. Below is a script and slide that is used in this video.


AYM You don’t have to model everything in UML


I am Michael Chonoles. I’m here to speak about “Modeling Myths”. “Modeling Myths” are these damaging misconceptions people have that prevent them from adopting UML on a project.

One of the big ones is “Do I Really Need to Model Everything?” Do I model the extra information? The redundant information? It seems very expensive, very time consuming, too much resources. And the problem is, that they are really right. People who think that Modeling everything is expensive are quite correct. But luckily, you don’t have to model all of it.


AYM You just have to model “the biggest risks”


Every project, every team has different risks. You will hear some examples that you might find similar on your project.
UML_Modeling_myth1

– Domain
For example, you might find that there’s not everyone understands the domain or the problem space. So, what you might use is conceptualization and domain-style modeling of your Class Diagrams or State Diagrams, so that it shows what the real world is like.

– Purpose
You might have problems where people on your project don’t know what the purpose of the project is. What are the things, what problems you are solving. Well, use UseCases and Actors to show you what you are trying to accomplish.

– Organization
Sometimes you have a problem with the organization. People don’t quite understand what tasks they are assigned, and who’s doing what. Use Package diagrams

– Implementation Approach
Sometimes Use Case diagrams to help you split them up into individual tasks and problems to work on. Sometimes you find that there are implementation issues. People don’t really get a feel for how this thing might be implemented. Use Sequence diagrams or Collaboration diagrams to help you understand how that might work together.


AYM Don’t model everything – spend your time where there is a high ROI


DON'T

DON’T

Don’t model:
things like Legacy Code if it’s well understood.
statemachines of simple on/off switches because they’re trivial, they are on or off – and it’s a waste of time.
parts of the system that are already known or similar to the other parts. If you model it the first time, and the second time around, you are modeling a different part of the system that works like the first, just reference the first one.
anything doesn’t really address a risk. Spend your time modeling where there’s a big return on investment.

Let’s give an example that might help you understand. You can see here some modeling that is a little confusing.
UML_Modeling_myth3

If everyone in the project is working on different parts, you are going to come up with something pretty confusing and hard to understand, and hard to see if there is any problems. So, what we are going to have to do is take some of this stuff out.
There’s some stuff that’s “already known” – take that out. We don’t need to model that.
after_alreadyknown alreadyknown

 

 

 

 

But there’s more. It’s still confusing. Let’s take out stuff, and not model “anything doesn’t address a need”. Get rid of that.

modeling_myths_5uml_modeling_myth4

 

 

 

 

 
Still confusing, still hard to see. What else could we avoid spending or wasting money, and time, and resources on?
We could have not modeled the “Unwanted Information”.
UML_modeling_myths_7 modeling_myths6

 

 

 

 

So now, things are improving. So what else could we take out? Things that are trivial like the statemachines, the easy stuff. Let’s get rid of “the Easy Stuff”.

UML_Modeling_Myths9 UML_Modeling_myths8

 

 

 

 

 

And we are getting better. And get rid of “Useless Detail”.

UML_Modeling_Myths10 UML_Modeling_myths_useless_detail

 

 

 

 

 

So what’s left is the biggest risk. But now we can see there’s some problems. Things aren’t straight. That’s one of our problems. We didn’t do it really right, so we can straighten this.

UML_modelingMyths11 UML_Modeling_Myths10

 

 

 

 

 

And then we see one more problem left. the serious one. we spelled “risk” incorrectly. so now we fixed that. If we would have started with just the area of biggest risk, we would have addressed our problems and not spent our resources on things we didn’t need.UML_modeling_Myths12


Watch more of Michael’s videos:
UML Modeling Myth
UML History

Advertisements

1 Comment »

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: