Days of ... (uml)

Ruby on Rails books teach wrong OO

Wed, 22 Nov 2006 09:41:17 GMT

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 logic constraints.

Take, for example, books dealing with making simple online store. They all say that there is no way to add products into shopping cart because products can be in many shopping carts. Because of that you have to add LineItems, which will point to a product description.

This is true when we speak about database design, but completely untrue when we speak about software design. From OO point of view there is no such thing as LiteItem. It has no value to a business logic and it must be dropped from model.

This model look much cleaner and causes no confusion. Additional work must be done on model layer, but this is just to avoid database limitations.

Sequence Diagram Guidelines revisited

Wed, 26 Jul 2006 13:52:39 GMT

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 class.
Include a prose description of the logic.
Not always needed, but helps in complicated places.
Place proactive system actors on the left-most side of your diagram.
Actors are always start interactions. This is whe they called actors - they act.
Place reactive system actors on the right-most side of your diagram.
No actors in the right side of the diagram at all. This is the rule!
Avoid modeling object destruction.
Model object destruction freely if it whats you modeling.
Don’t sweat activation boxes.
Again - if it is required you have to model it. Don't leave it for developer to decide.
Name objects when you reference them in messages.
Don't do it. It will add much more complexity to the message signatures with no added value.
Name objects when several of the same type exist.
Name all objects. This is what developer will do anyway.
Apply textual stereotypes to classifiers consistently.
Apply visual stereotypes sparingly.
Focus on critical interactions.
Justify message names beside the arrowhead.
Don't waste your time. This will not be appreciated.
Create objects directly.
Is there another way? I think not.
Apply operation signatures for software messages.
Apply prose for messages involving human and organization actors.
Prefer names over types for parameters.
This is true, but you should also set the types for all parameters too.
Indicate types as parameter placeholders.
Apply the > stereotype for use case invocations.
No use case invocations in sequence diagrams! It is possible, but will not help developer. Remember: sequence diagram is for developers.
Do not model obvious return values.
Model them! Let developer know that return value is expected.
Model a return value only when you need to refer to it elsewhere on a diagram.
Model it everywhere.
Justify return values beside the arrowhead.
Waste of time!
Model return values as part of a method invocation.
Before it was said that we don't have to model return values and not we need to model them? As I said - model return values all time.
Indicate types as return-value placeholders.
Model them in the method signature.
Indicate the actual value for simple return values.
Indicate the type of the return value. Anything else goes into comments.

Activity Diagrams Guidelines revisited

Wed, 26 Jul 2006 09:03:36 GMT

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 on top and in center. This way looks more visual.
Include an ending point.
What? No ending point? So activity never ends? I always have at least one ending point
Simplify operations requiring flow charts.
The whole goal of activity diagrams is to visualize and, if possibly, simplify the process.
Question “black-hole” activities. Question “miracle” activities.
I would question any activities. It is very usual to have some unneccesary work only because analyst and/or client do not fully understand what is needed and what is achievable
Reflect the previous activity by using decision points.
Avoid superfluous decision points.
Ensure that each transition leaving a decision point has a guard.
If there is no guard then what this flow is trying to decide?
Do not overlap guards.
Huh?
Ensure that guards on decision points form a complete set.
And if they not - why do you have decision point, by the way?
Ensure that exit transition guards and activity invariants form a complete set.
Apply an [otherwise] guard for “fall-through” logic.
This one support the thesis about having the complete set of the guards next to each decision point.
Model guards only if they add value.
If you don't have real guards - you should not have the decision point in this place
Ensure that forks have corresponding joins.
Not always true - some of the forked processes may be terminated before they go to the join. Messaging is a good example.
Ensure that a fork has only one entry transition.
Ensure that a join has only one exit transition.
Avoid superfluous forks.
Order swimlanes in a logical manner.
It is all about logic, why say more?
Apply swimlanes to linear processes.
Have less than five swimlanes.
I would say that is you trying to add fourth swimlane, you are already creating something bigger, than anybody in your team can comprehend without asking you more questions. It is time to simplify the activity.
Consider swimareas for complex diagrams.
Consider to use UML2 and include sub-activities in this activity
Reorganize into smaller activity diagrams when swimareas include several activities.
Yes, very good point.
Consider horizontal swimlanes for business processes.
Well, it depends on business process and your preference.
Model the key activities in the primary swimlane.
Good point. If you don't have key activities in the primary swimlane chances are that you modeling incorrect activity.
Place shared action objects on swimlane separators.
Apply state names when an object appears several times.
Reflect the life-cycle stage of an action object in its state name.
And use color, if your modelling program allows it.
Show only critical inputs and outputs.
Depict action objects as smaller than activities.

Rational Software Architect: simple guide

Wed, 25 Jan 2006 15:34:00 GMT

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 structure design files, so the design will be understandable by anyone in the project.

At the end of page is a little gem: Software Architecture Document for the project, described in the article. Very very helpful!

architecture, rational, UML, RUP

Activity Diagram Guidelines

Wed, 15 Jun 2005 13:56:20 GMT

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 points form a complete set.

Ensure that exit transition guards and activity invariants form a complete set.

Apply an [otherwise] guard for “fall-through” logic.

Model guards only if they add value.

Ensure that forks have corresponding joins.

Ensure that a fork has only one entry transition.

Ensure that a join has only one exit transition.

Avoid superfluous forks.

Order swimlanes in a logical manner.

Apply swimlanes to linear processes.

Have less than five swimlanes.

Consider swimareas for complex diagrams.

Reorganize into smaller activity diagrams when swimareas include several activities.

Consider horizontal swimlanes for business processes.

Model the key activities in the primary swimlane.

Place shared action objects on swimlane separators.

Apply state names when an object appears several times.

Reflect the life-cycle stage of an action object in its state name.

Show only critical inputs and outputs.

Depict action objects as smaller than activities.

]]>

Sequence Diagram Guidelines

Wed, 15 Jun 2005 13:55:02 GMT

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 boxes.

Name objects when you reference them in messages.

Name objects when several of the same type exist.

Apply textual stereotypes to classifiers consistently.

Apply visual stereotypes sparingly.

Focus on critical interactions.

Justify message names beside the arrowhead.

Create objects directly.

Apply operation signatures for software messages.

Apply prose for messages involving human and organization actors.

Prefer names over types for parameters.

Indicate types as parameter placeholders.

Apply the > stereotype for use case invocations.

Do not model obvious return values.

Model a return value only when you need to refer to it elsewhere on a diagram.

Justify return values beside the arrowhead.

Model return values as part of a method invocation.

Indicate types as return-value placeholders.

Indicate the actual value for simple return values.

]]>

Package Diagram Guidelines

Wed, 15 Jun 2005 13:54:21 GMT

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 names.
Make packages cohesive.
Indicate architectural layers with stereotypes on packages.
Avoid cyclic dependencies between packages.
Reflect internal relationships in package dependencies.

]]>

Class Diagram Guidelines

Wed, 15 Jun 2005 13:53:37 GMT

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 line of an association class.

Use common terminology for class names.

Prefer complete singular nouns for class names.

Name operations with a strong verb.

Name attributes with a domain-based noun.

Do not model scaffolding code.

Do not model keys.

Never show classes with just two compartments.

Label uncommon class compartments.

Include an ellipsis ( . . . ) at the end of incomplete lists.

List static operations/attributes before instance operations/attributes.

List operations/attributes in decreasing visibility.

For parameters that are objects, list only their type.

Develop consistent operation and attribute signatures.

Avoid stereotypes implied by language naming conventions.

Indicate exceptions in an operation’s property string.

Reflect implementation language constraints in interface definitions.

Name interfaces according to language naming conventions.

Prefer “lollipop” notation to indicate realization of an interface.

Define interfaces separately from your classes.

Do not model the operations and attributes of interfaces in your classes.

Model relationships horizontally.

Model collaboration between two elements only when they have a relationship.

Model a dependency when the relationship is transitory.

Tree-rout similar relationships to a common class.

Always indicate the multiplicity.

Avoid a multiplicity of “*”.

Replace relationship lines with attribute types.

Do not model implied relationships.

Do not model every dependency.

Center names on associations.

Write concise association names in active voice.

Indicate directionality to clarify an association name.

Name unidirectional associations in the same direction.

Word association names left to right.

Indicate role names when multiple associations between two classes exist.

Indicate role names on recursive associations.

Make associations bi-directional only when collaboration occurs in both directions.

Redraw inherited associations only when something changes.

Question multiplicities involving minimums and maximums.

Apply the sentence rule for inheritance.

Place subclasses below superclasses.

Beware of data-based inheritance.

A subclass should inherit everything.

Apply the sentence rule for aggregation.

Be interested in both the whole and the part.

Place the whole to the left of the part.

Apply composition to aggregates of physical items.

Apply composition when the parts share their persistence life cycle with the whole.

Don’t worry about the diamonds.

]]>

Use Case Diagram Guidelines

Wed, 15 Jun 2005 13:53:00 GMT

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, not job titles.

Use > to indicate system actors.

Don’t allow actors to interact with one another.

Introduce an actor called “time” to initiate scheduled events.

Indicate an association between an actor and a use case if the actor appears within the use case logic.

Avoid arrowheads on actor-use case relationships.

Apply > when you know exactly when to invoke the use case.

Apply > when a use case may be invoked across several use case steps.

Apply > associations sparingly.

Generalize use cases when a single condition results in significantly new business logic.

Do not apply >, >, or >.

Avoid more than two levels of use case associations.

Place an included use case to the right of the invoking use case.

Place an extending use case below the parent use case.

Apply the “is like” rule to use case generalization.

Place an inheriting use case below the base use case.

Apply the “is like” rule to actor inheritance.

Place an inheriting actor below the parent actor.

Indicate release scope with a system boundary box.

Avoid meaningless system boundary boxes.

]]>