CafePrint: Behind the Scenes

CafePrint SaaS described in the previous posts was one of the projects where I practiced my UML and modelling skills. Since the service consists of the two subsystems (the Print and Outdoor), I designed independent diagrams for each.

I started off with IDEF0 diagrams, which are part of the SADT approach. This is the structured approach for modelling a system.

IDEF0 diagram for Print subsystem

IDEF0 diagram for Print subsystem

IDEF0 diagram for Outdoor subsystem

IDEF0 diagram for Outdoor subsystem

A1 can further be decomposed:

A1 decomposition

A1 decomposition

I then moved on to the object-oriented approach and built some UML diagrams for the Print and Outdoor subsystems. Even though UML diagrams are characterized by higher abstraction level, they really facilitate transition from a model to the programming code. The standard procedure here would be to find out the data requirements (State Model), the functional requirements to the system (Behavior Model) and how objects are changing over time (State Change Model). This information is then later being used as a foundation for each of the respective models, upon which we build UML diagrams.

Here’s how I usually design the system to be built:
1. Identify the requirements for the system. Who are the actors that will be interacting with the system?
2. Identify use cases by looking into what actors expect from the system.
3. Create a table with the requirements and put in line actors and use cases for each of the requirement.
4. Draw Use Case diagrams to take into account steps 1-3.
5. Draw Class diagrams (collection of static model elements and their relationships)
6. Draw Activity diagrams (models logic within the system).
7. Draw Communication diagrams (instances of classes, their interrelationships, and the message flow between them).
8. Draw Sequence diagrams (models the sequential logic).
9. Draw State Machine diagrams (object states and transitions).

State Model

Class Diagram for Print

Class Diagram for Print

Class Diagram for Outdoor

Class Diagram for Outdoor

Behavior Model

Use Case diagram for Print

Use Case diagram for Print

Use Case diagram for Outdoor

Use Case diagram for Outdoor

Activity Diagram for use cases related to managing lists of records

Activity Diagram for use cases related to managing lists of records

Activity Diagram for use cases related to editing

Activity Diagram for use cases related to editing

Communication diagram for Print

Communication diagram for Print

Communication diagram for Outdoor

Communication diagram for Outdoor

Sequence Diagram for Print

Sequence Diagram for Print

Sequence Diagram for Outdoor

Sequence Diagram for Outdoor

State Change Model

For the classes whose state can change, it’s good to have State Machine diagrams. In the two subsystems under revuew, only three classes can have more than two states – Order for Print subsystem, Campaign for Outdoor subsystem and Invoice.

state_invoice

State Machine class for Invoice class

state_order_campaign

State Machine class for Order/Campaign classes

After completing the above steps it’s safe to start the actual development.

Discuss