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.

As usual our goal is to streamline the process of getting reliably from requirements to working, maintainable source code and tests. Sooo… to this end, over on the Downloads page, you can find some cool free stuff which we hope you’ll find useful on your own software projects.

The latest download, made available just yesterday, is the ICONIX/EPF zipfile: an “instant process website” generated from the Eclipse Process Framework (EPF). Thanks to our technical reviewer, Chuck Suscheck, for putting a serious amount of work into creating this. The result should make it easier to adopt, and follow along with, the ICONIX Process on new projects.

Two new reviews of Use Case Driven Object Modeling with UML: Theory and Practice this week. The first is on JavaLobby, where reviewer Meera Subbarao sums up with: “very informative and well written”… and adds: “The Top 10 list of guidelines, and the exercises at the end of each chapter in itself is worth the price of the book.”

The second review is over at The Register/Reg Developer, where reviewer Pan Patziarka gives the verdict: “Finally, it’s worth mentioning that the book scores highly in terms of clarity of writing, good design (and use of colour) and in providing a high-level of content.”

The review also states: “Software development proceeds by addressing the ambiguities, yielding progressively clearer specifications and a shared understanding between client and developer. It is this process, which the authors call ‘disambiguating’, that this book so clearly documents.”

It’s time we did something about our colleges and universities turning out armies of programmers who know how to code, but very little about how to get from a set of requirements through a well-factored design, and then to a maintainable set of code. One of the main goals of the Theory and Practice book is to provide a suitable text for a computer science course in this area.

We’ve written this book as a teaching book. Chapters are organized into Theory, Practice, and More Practice sections. The Theory sections explain the concepts, and include small, thought-provoking exercises. The Practice sections present examples with mistakes deliberately left in, and present the answers to these questions a few pages later. The More Practice section at the end presents challenge questions, half multiple-choice, and half essay. If you’re a computer science instructor and would like to build a course around this book, email us, we’d like to talk with you.

One process is much larger
And the other’s way too small
And the full UML that OMG gives you
Is incomprehensible to all . . .

(Sing to the tune of “Go Ask Alice” by Jefferson Airplane)

In theory, every single aspect of the UML is potentially useful, but in practice, there never seems to be enough time to do modeling, analysis, and design. There’s always pressure from management to jump to code, to start coding prematurely because progress on software projects tends to get measured by how much code exists.

The ICONIX Process is a minimalist, streamlined approach that focuses on that area that lies in between use cases and code. Its emphasis is on what needs to happen at that point in the life cycle where you’re starting out: you have a start on some use cases, and now you need to do good analysis and design.