ICONIX Process

Activity diagrams are a dynamic UML diagram that can be used to better describe use cases, business flow, software flow or any other type of behavior. Activity diagrams are general purpose in their application.

• Activities can have multiple arrows in but only 1 out (except object flows).
• Activities must have 1 arrow out (never 0).
• Decisions – diamonds – can have multiple arrows in but only 2 out (no more, no less).
• Forks (start of parallelism) can have multiple arrows in and multiple out.
• Join (end of parallelism) can have multiple arrows in and only 1 arrow out.
• Anything that forks must also join at the end.
• It’s OK to have multiple finals on an activity diagram, but you can have (and must have) only 1 start.

In my last blog I talked about rules for domain models. Here are a few rules for requirements:

Requirements are rules to which the system or business must adhere. They are usually updated as the software development progresses and are usually written as text (although diagrams can be used to augment the requirements).

• Complete: Requirements should be as complete- no open endedness.
• Testable: Must be able to create a test for all requirements
• Consistent: Requirements must be consistent with each other; no conflicts
• Feasible: Possible to do
• Design Free: Software requirements should be specified at the requirements level and not at the design level. Keep out of the system
• Unambiguous: Use “Shall” and Related Words. Don’t be wishywashy

Here are a few hints that I’ve put together for creating domain models and using a class diagram to express the model.

Domain models describe the business. We use a UML class diagram (static) to describe our domain model. The domain model helps us to understand the business before we dive into requirements and acts as a sort of glossary of terms, eventually leading to a system model which describes the software.

• Nouns are either classes or attributes. Classes and attributes are NOT verbs.
• Attributes have a value that is either a word or a number, classes have a value that is compound.
• An attribute has a value and a class has an instance.
• Multiplicity only works on compose and aggregate, never on generalization.
• Don’t overuse multiplicity.
• Generalization arrow points to the more general.
• Containment diamond (aggregate or compose) is on the end of the line next to the class that does the containing.
• Attributes are generally private (-) while methods are generally public (+).
• Association is the least important relationship and means “knows about or does”.
• Aggregation (open diamond) normally means “contains or has a”.
• Composition (black diamond) normally means “is made up of”.
• If you’re not sure of aggregation or compose, just start with aggregation.
• Generalization normally means “is a type of” (usually).
• Generalization is only used when a class has a different structure or behavior – example a blue truck and a red truck are not subclasses of truck – they differ only on value but a semi is a type of truck with different behavior and characteristics.
• When determining relationships, aim for 90% of generalization, 80% of containment, 10% of associations.
• Containment (aggregation and composition) on a parent class is typically inherited by the child.
• Keep the focus on the business, not the software when developing domain models.