A reality-check step proposed by Ivar Jacobson in his book on OOSE1 wherein the objects in a proposed system are broken into distinct Interface, Control, and Entity stereotypes. All the objects in system should fit cleanly into one and only one of these classes, and moreover the Interface classes should never talk directly to the Entity (data) classes.-- Steven Black
Here are some web links that discuss robustness diagrams:
Here is a diagram showing the gerneric robustness diagram elements.
(1) Jacobson Ivar et al (1992), Object Oriented Software Engineering - A Use Case Driven Approach, Addison Wesley, Reading, MA, ISBN 0201544350. Note that I'm not 100% sure that Robustness diagrams are actually discussed by name in this book. I'm on the road and I can't check. He certainy alludes to the process in this book, however, and robustness diagrams are discussed in his later works (books and articles).
I've been wanting to get my hands on the book mentioned above for a long time now!! I guess that's why I never heard of a Robustness Diagram. Is this actually a type of diagram like the name implies, or a step in the design process for review like the description above seems to imply? -- Rox
Yup. Here's an example. Note that each class is either an interface, controller, or entity class and the interface classes never talk to the entity classes.-- Steven Black
I take it you would only have one Robustness Diagram per use case in your design? -- Rox In general, yes, but in a big honkin' use case there might well be several.-- Steven Black
Whereabouts in the Jacobson book did you see these diagrams? -- Dafydd Rees These diagrams are my own, adapted from diagrams in articles and books subsequently published by Ivar Jacobson.-- Steven Black
( Topic last updated: 1999.11.12 07:54:38 PM )