AWebFactory
Depot App Process

Why search for an appropriate process at all? Why not just start generating code with Rails and filling in the blanks?

The answer is that when we go to the Analysis And Design of an application of our own, we immediately perceive that there is a missing link (kind of swept under the carpet in the AWDWR book, see Thorough Critique of Chapter 5): Where did the Depot app site map web flow diagram come from??? How do I generate one for the app I’m working on right now?

Let’s answer these questions in a practical (agile?) manner (skip to (ICONIX method step by step) if you can’t bear the suspense…).

First of all, as per Chapter 5, we identify the Actors.

Second, we ask of what possible use the Depot App is to them (identify the Use Case)?

Here are the possible Use Cases I have drawn up, which are specified in AWDWR, but in very compact form:

Now we pose the classic question, as clearly presented in the ICONIX: how do we get from the Use Case to the code???

According to what would pass for Best Practices in the ICONIX method, the next step is:

Elaborate the Domain Model

“Identify the main abstractions present in the problem domain. In other words, we need a domain model”

The way I do this is to make a lexical analysis of the text of all the requirements so far, and shove all nouns “in order of appearance” into an analytical class diagram, a rough and ready incipient Object Soup:

Next, I pick out the adjectives and stick in attributes, and the verbs, which allows me to stick in some basic methods and/or associations between the nouns => Analytical Class, which also prompts a reordering of the objects in the domain:

All we have actually done so far (be patient, we will hook up with MVC in a moment) is to have captured the “main abstractions in the problem domain”. This result is very similar to what we would have obtained with a CRCCards role-playing session. We have also settled the semantics of the problem domain in a unified fashion, and this is the “vocabulary” we shall use to write the use cases, which will thereby gain considerably in consistency.

Write the Use Case Text

To proceed, we need to write the Use Case Text (see) for each Use Case.

Now, a set of User Story which represent all the alternative flows can replace a single Use Case Text, no problem. But we need to see all the alternative flow somewhere.

Now, we sure have a lot of Use Case Text to write. Eight, in actual fact. But before we go on, we should ask ourselves the question, do they all stand up to the critieria of what constitutes a Use Case? Let’s review the following:

(Taken from a slide from Jim Heumann’s video Writing Good Use Cases)

Requirements for a Use Case to be a Use Case

  1. Must provide value to a stakeholder
    • Goal orientation
  2. Must be a complete narrative describing how the value is provided
    • Must have main and alternative flows
  3. Must stand alone
    • No sequencing of use cases [but see AWebFactory note below]
  4. Must not describe design
    • What not how

Note: Based on the work of Ivr Jacobson, Kurt Bittner and others at IBM Rational Software.

AWebFactory note: This is a somewhat polemic requirement. There could be cases when you need to use the “precedes” stereotype.

Correct Level of Detail

So according to these criteria we will coalesce the original eight Use Case (see diagram above) into three Use Case, one for the Actor Buyer and two for the Actor Seller:

Note that in the Use Case and in the Domain Model (first two stages) no mention is made of interface: the actor is associated directly to the functionality (chunk of functionality) that is being specified, and communicates with the amorphous “System” actor (which in turn registers information in a mysterious “Database”), which will only now all be separated out into interface, or persistent data entity, or business logic controller, in the Robustness diagram. No mention is made of Web App or Desktop App, nothing ties the models to any one implementation. That way we are sure we have isolated the functional requirements in the Use Case.

Create a Robustness Diagram for each Use Case

Now comes the moment we have all been waiting for, the point at which we start to set the stage for going beyond What the functionality is, and start to get into How that functionality will be implemented. To Drill Down into the “formless” functionality and discover the separated interfaces, controllers and entities which are to implement that functionality. That is why we speak of the Robustness Diagram as the link or bridge between the Use Case and the Analysis Model and beyond.

And it is while we are working with the Robustness Diagram that we specify the analysis classes, the entities, boundaries, and controllers (MVC, get it? But one which emerges from the analysis naturally!).

Use Case Robustness Diagram
Depot Use Case Specification UC001 Purchase Products Robustness Diagram Depot UC1
Depot Use Case Specification UC002 Maintain Products Robustness Diagram Depot UC2
Depot Use Case Specification UC003 Ship Orders Robustness Diagram Depot UC3

It should be remembered that the main purpose of the Robustness Diagram is that of validating both the business logic as well as the consistency of the terminology used in all the Use Case (so the Use Case will most often be updated several times at this point); and of serving as a springboard for Use Case Realization, that is, it will act as a bridge to Analysis (Sequence Diagram) and Design (Class Diagram) elements.

(It is while you’re elaborating different versions of the Models and of the Use Case Text that the use of a Version Control System comes in.)

ICONIX method step by step

So the steps taken according to the ICONIX method, in of course an iterative fashion and not mechanically in that order either, would be, basically:

Actors <=> UseCases <=> Domain Model <=> Use Case Text <=> Robustness Diagram <=> Sequence Diagrams <=> Analysis Model <=> Discover Classes <=> Design Model <=> Implementation Model

User Experience (UX)

Now, before we go whole hog into Analysis And Design, we need to see what can be gained from the technique of generating User Experience Storyboards and a User Experience Model (either as an alternative to Robustness Diagram under certain circumstances, or in conjunction with it if we felt the effort were justified).

TO DO: develop UX tuturial thread: Link the User Experience Storyboards we developed in the course of this Depot App Process, and go on to Fitting Depot Storyboards With Rails.

On to Analysis And Design

The Analysis Model includes Use Case Realization and the creation of at least a Sequence Diagram for most of the Use Case, based on the completed Robustness Diagram, and may involve the use of other UML artifacts.

The Design Model includes the creation of several Class Diagram, and the application of Design Patterns taken from our Patterns Repository, which in the case of Ruby On Rails, is heavily influenced by MVC.

TO DO: develop…

Generate, fill out and refine the Implementation Model (code)

Using the Ruby On Rails generators and scaffolding, generate the code, fill it out and refine it iteratively.

TO DO: Clearly link all model elements to Ruby On Rails elements, even though this is done in the next step:

See Fitting Depot Storyboards With Rails.

So, we have connected the Use Case to the Implementation Model, that is, to the Code!!!

Content Copyleft Victor Kane (ProjectMaster) and awebfactory.com.ar
Email me at info at awebfactory dot com dot ar
Full content (RSS 2.0) and Headlines (RSS 2.0)