I was reading a lot of Ruby on Rails books in order to start my own project. I found the thing, which really disturbes me: though Ruby is a proper OO language, none of OO desugn features are presented in Rails books. Proper Object Oriented Design should simplify software development by introducing abstraction from unneccessary [...]
Strive for left-to-right ordering of messages. And if you need to put right-to-left non-return message – consider using another instance of the swimline Layer classifiers Huh? Give an actor the same name as a class, if necessary. We are not dealing with classes in sequence diagrams, so give name to the instance of the actor’s [...]
Last year, after reading a book about UML, I wrote a set of posts with distilled UML guidelines. Now it is the time to look at them again and put some comments on usage. Place the start point in the top-left corner. I tend to create vertical activity diagrams, so I usually place the start [...]
Everybody, who worked with Rational tools could think that there is nothing rational in them. And frustration mounts when you’ll try to read the supplied documentation. The documentation is structured, but some pages are very shallow and others do not explain topics in undestandable language. This article is very helpful. It actually shows how to [...]
Place the start point in the top-left corner. Include an ending point. Simplify operations requiring flow charts. Question “black-hole” activities. Question “miracle” activities. Reflect the previous activity by using decision points. Avoid superfluous decision points. Ensure that each transition leaving a decision point has a guard. Do not overlap guards. Ensure that guards on decision [...]
Strive for left-to-right ordering of messages. Layer classifiers. Give an actor the same name as a class, if necessary. Include a prose description of the logic. Place proactive system actors on the left-most side of your diagram. Place reactive system actors on the right-most side of your diagram. Avoid modeling object destruction. Don’t sweat activation [...]
Create class package diagrams to logically organize your design. Create UML component diagrams to physically organize your design. Place inheriting packages below base packages. Vertically layer class package diagrams. Create use case package diagrams to organize your requirements. Include actors on use case package diagrams. Horizontally arrange use case package diagrams. Give packages simple, descriptive [...]
Identify responsibilities on domain class models. Indicate visibility only on design models. Indicate language-dependent visibility with property strings. Indicate types on analysis models only when the type is an actual requirement. Be consistent with attribute names and types. Model association classes on analysis diagrams. Do not name associations that have association classes. Center the dashed [...]
Name use cases using domain terminology. Imply timing considerations by stacking use cases. Place your primary actor(s) in the top-left corner of the diagram. Draw actors on the outside edges of a use case diagram. Name actors with singular, domain-relevant nouns. Associate each actor with one or more use cases. Name actors to model roles, [...]