« Slowing down to go fast| Main | Winter at Goshen »

Derived Confusion from the Unified Process

| | Comments (0)

I had a customer recently that just had fits over derived artifacts. I felt badly for them, because derived artifacts take a little bit of consideration.

We were going over the Unified Process, how most architectures consist of two things: behavior and structure. Anything you talk about, whether at the level of Business Analysis or System Analysis is going to consist of those two things. At the highest level of conceptualization, we use use cases and class diagrams to represent behavior and structure.

The two are the yin and yang of system development. The use cases describe the behavior the users are interested in the system performing, and the class diagram describes the pieces that are going to be necessary for that behavior to happen. If I point to a use case, you should be able to walk me through the class diagram to show how it happens (either formally or informally). Likewise, if I point to a class in the diagram, you should be able to tell me what kinds of system activity it supports.

What happens sometimes is that we get two pieces that imply that there is a piece in the middle . For instance, we may have use cases that represents Action A occuring. We may also have a use case that represents Action C occuring. At some point, an analyst looks at these use cases and asks "What happens between these two use cases? Isn't there a piece in the middle? An Action B?"

Now the users never gave us an "Action B" that they wanted to happen. But Action B has to happen nonetheless. In addition, we never modeled for Action B. So what to do?

The same thing happens over in the class diagram. This customer had a Person class that they had modeled, and an Address class that they had modeled. Once again, looking at the model some analyst said "But a person can have many addresses, and any address may have many peple. It changes with time"

So we added a PersonAddressLog class, which had the responsibility of keeping track of which people lived where during which times. But once we started mapping our classes to tables, one of the programmers had a good question.

"So what's the point in treating this PersonAddressLog table the same as the other classes? It's just a joining table and doesn't do anything but hook up these other two tables"

Translation: There is no behavior the system has to perform that involves this class.

But of course not! Because the class was _derived_, not specified. In the same way, our Action B use case has not corresponding classes to support it -- nobody thought that the system had to do Action B.

So what to do? Do we change the class diagram to accomodate Action B or do we just make the existing model work? Do we add new use cases to handle the PersonAddressLog class or just ignore it as much as we can?

Derived Use Cases and derived Classes have to be treated a little differently. This is because the users want you to make the system DO stuff -- behavior. They usually could care less HOW the system does it. When you find a use case that is implied or derived from your other use cases, that means you have scoping issues. You've got something the system used to not have to do that it's got to do now. So yes, by all means make sure your class diagram is updated, and make sure you go through your scope-change procedures. It's going to cost more, it's going to be more testing, and also, it's going to be a more complete system. Hopefully, the user is going to be happier with your work.

Derived classes, on the other hand, are a different animal entirely. It's extremely important that you treat derived classes the same as any other class in your model -- they are not second-rate artifacts simply because they're required only to do something for other classes.

Why's that?

That's because all of your classes represent concepts in the problem or solution space. They represent the pieces of "stuff" that you're going to use to put this baby together. It's critical that you have a complete and thorough understanding of all the "stuff" your user thinks is important, and all of the stuff that holds the model in one piece. Users, being the humans that they are, sometimes don't know exactly what they want. So they'll come to you with more behavior they want from the system. The goal of analysis is to capture at a broad conceptual level all of the concepts that exist in the user's world

That means, make your model wide and fat, not skinny and clever. A conceptually complete model will have classes for anything the user can request. In our earlier example, if the user came to us with a question like "I'd like to know who was living at a certain address when we mailed them that flyer" the system has a spot to handle it. They may have all kinds of new behavior around that newly derived class, and they may have none. As an architect, you don't have to predict the future. 900-Numbers should not be part of your planning! Keep the model broad and the use cases tight and focused and you'll do fine.

Leave a comment

About this Entry

This page contains a single entry by DanielBMarkham published on January 16, 2007 1:42 PM.

Slowing down to go fast was the previous entry in this blog.

Winter at Goshen is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Social Widgets





Share Bookmark this on Delicious

Information you might find handy
(other sites I have worked on)





Recently I created a list of books that hackers recommend to each other -- what are the books super hackers use to help guide them form their own startups and make millions? hn-books might be a site you'd like to check out.
On the low-end of the spectrum, I realized that a lot of people have problems logging into Facebook, of all things. So I created a micro-site to help folks learn how to log-in correctly, and to share various funny pictures and such that folks might like to share with their friends. It's called (appropriately enough) facebook login help