Robustness Diagrams

[MichaelRuschena]

Hi folks,

I'm trying to create some robustness diagrams in EA. (e.g. something like...)

The problem I'm having with EA is in the creation of the Interface, Entity and Control objects. In order to get the effect I'm after, I'm using a logical diagram, and using objects of sterotype 'case worker', 'entity' and 'worker'.  This is a) somewhat inconvient, and b) ends up with little men in the Control and Interface objects (what does this stick figure signify anyway?)

What I'd prefer is to have the icons available in the toolbar. (They are sort of available in the sequence diagram. But - this includes an object lifeline, and is always positioned at the top of the page.)

Is there an easier way to make robustness diagrams than changing the sterotypes of classes or objects?

Thanks,

Michael Ruschena

[PhilR]

Try double clicking on a class to display the class properties and then select the drop down list for 'stereotype' (directly under the class name).

If you select the 'entity', 'control' or 'boundary' stereotype the correct icon should be displayed in the diagram.

Phil.

[MichaelRuschena]

Yes, that gives the right icons. Cool.

Thanks.

[kelly_sumrall]

Another technique is to get the Icons displayed on the Outlook toolbar.  You can do this from the menu.  Select View -> options from the menu.  From there, select the Outlook Toolbar option.  You can then select the Show Robustness Icons in Analisys checkbox.  The Icons will now show in the Analisys Outlook Toolbar.

[MichaelRuschena]

Kelly, that rocks.  

Thanks.

[Rafael Gonzalez]

A coment on your diagram:

According to what Jim Connallen says in his book "building web applications with UML", page 132:

- Actors can only interact with boundary objects
- Entity objects can interact only with controller objects
- Controller objects can interact with any objects

If this is true, then you need controller objects between your boundary and entity objects. These carry out the processes outlined in your message labels. Entity objects would be merely persistent data objects with no behaviour.

Hope you find it useful
Rafael

[MichaelRuschena]

This diagram is just what I could find that looked vaguely like what I was after. That diagram is on a web page somewhere. Thruth be told, I barely looked at it.

I don't have any capacity to post to the web, so I couldn't make my own image. (Also, I couldn't make the images I was after, cos I didn't know how to get EA to make them - that's why I made the post in the first place.   )

So, I agree that the diagram is wrong.

[PhilR]

Be careful that you don't end up with stacks of controller classes.  I tend to view them as a rather abstract concept i.e. not every controller will become an actual class in the design.  The opposite problem is to create 'god' controllers that do (and know) too much.

Also if you adopt the model-view-controller pattern, boundary classes (GUI elements) can directly request the state of an entity class thus breaking the "rule" that boundary classes can only talk to controllers.

Also like to include another type of "boundary" class which is a data management class (boundary between the application and database).  This approach decouples the application from a specific database.  For example, the boundary classes encapsulate all the necessary SQL.  This class also talks directly to entity classes.

My robustness diagrams then look something like this:

ACTOR<-->Boundary (GUI)<-->Controller<-->Entity<-->Boundary (SQL)<-->DATABASE

This just happens to map rather neatly to an n-tier architecture.

Conclusion? Modelling rules where just made to be broken which is why EA is such a cool tool - it doesn't enforce lots of fussy rules ;-)

Phil

[Rafael Gonzalez]

Good point !

Now that I think of it, Conallen's book is about Web applications. He adoptes this approach in analysis because he maps boundary objects as HTML pages and forms and controller objects as servlets or ASPs that may handle entity objects.

In this framework, his "rules" makes more sense.

Rafael

[MichaelRuschena]

My robustness diagrams then look something like this:

ACTOR<-->Boundary (GUI)<-->Controller<-->Entity<-->Boundary (SQL)<-->DATABASE

I'm an analyst in an intranet environment, so Conallen's book is extremely useful to me. But I also do some C++ programming, and I use the diagrams the same way. So I'm curious about robustness diagrams with a single controller. What value does it add?

Let me explain my thinking. I put robustness firmly after a Use Case. The robustness diagram allows me to divide out chunks of work that the algorithm. For example: gather the parameters (talks to GUI), validate the input, build an appropriate query (talks to report object), run the query itself (talk to database), do something with the results (talk to report again), display them. So we have six discrete steps that have to be performed to accomplish a workflow in the Use Case, without getting bogged down in the details of a sequence diagram. Its easy to specify what each controller will do (if it isn't, then the controller is too big). It's also easy to relate the steps back to the original Use Case.

I can't help thinking that if there's a single controller, then either

• the sequence of steps has been decided, and it's too late for the robustness to add much value, OR
• the controller is doing way too much.

I'd be interested to know what benefits you get from single controller robustness. If it's simply to allocate functions to various tiers, wouldn't one of the other UML diagrams be more appropriate? (I'm thinking the physical diagram, but I don't venture much into such lands, so I'm not sure.)

[PhilR]

I pobably didn't explain myself too well.  I am not really advocating a single control class but rather warning about generating masses of contol classes as a result of developing a robustness diagram.

I believe that control classes on robustness diagranms are not really classes but represent responsibilities of some other class.  This is because they are pure function.  Classes that are pure function can lead to weak OO designs.  Peter Coad derides such classes as "functional blobs".

However, having said this, I agree with your comments.  Used in the correct way, robustness diagrams are powerful technique for generating a first cut design.  Sequence diagrams require too much attention to sequence which is of course their strength in other situations :-)

Maybe what is required is a stereotype for a class <<responsiblity>> which can be used on a robustness diagram instead of a <<control>> class?

Finally, I am influenced by J2EE where control classes map naturaly to Session beans.  Sun's recommendation is to go for coarse-grained session beans rather than lots of fine-grained session beans.

Thanks for your thought-provoking comments.

Phil.

[MichaelRuschena]

Thanks Phil, that makes sense. I can't really comment on J2EE   though.

I did come across one reading where the control classes ended up as function calls in a first cut of a sequence diagram. (Boundaries and Entities formed the classes). They were then progressively turned into discrete functions.

[PhilR]

Mmm... that sounds interesting.  Do you have the reference by any chance?

Perhaps there are four things involved  :-/

<<entity>> and <<boundary>> classes as normal
<<responsibility>> which replaces the <<control>> classes in the roubustness diagrams
<<responsibility>> is then allocated to the <<entity>>, <<boundary>> classes as per your description
<<control>> classes can be introduced to represent the use case and some of the responsibilities could be allocated to them as well?

Rules for allocating repsonsibilities might go something like this:

responsibility for querying <<entity>> state allocated to <<boundary>> classes
responsibility for responding to user gestures (clicks etc) allocated to <<control>> classes
responsibility for collaborations which realise the use case to <<entity>> classes

In effect this approach provides a bridge between the mode-view-controller pattern and robustness diagrams.

[MichaelRuschena]

Mmm... that sounds interesting.  Do you have the reference by any chance?

The quote is firstly Aarti, who works at the desk next to me.  

I pressed her for a bit of detail. It was first an observation made from the examples in Applying Use Case Driven Object Modelling With UML by Doug Rosenberg and Kendall Scott. Drilling a bit deeper, the book mentions "Putting methods on classes involves converting the controllers from you robustness diagram, one at a time, to sets of methods and messages that embody the desired behaviour" (page 89, their emphasis).

I can't honestly say I use the stereotypes well enough to give much in the way of feedback on your suggestions. However, I'd have expected Boundary to come in stereotypes of <<GUI>> and <<interface>>, and Entities to come as things like <<database>>, <<Mainframe>>, <<Container>>, etc.

Then you'd say that <<GUI>> is expected to handle user input, <<database>> is expected to receive SQL or whatever, <<container>> is a persistent object created for processing, and so on. Just a thought.

What are you hoping to achieve with the stereotypes?

[PhilR]

What are you hoping to achieve with the stereotypes?

Good question  

Mainly an understanding of how useful they are.  I have read the book you mention and the point of robustness diagrams did not jump out and grab me.  Mainly because I missed the bit about control objects you quoted.

I get the point now - Thanks.
Phil.