Architectural Guidance for Composite Smart Clients

Outlining the Development Process

1. First requirement analysis, overall user case
2. Overall Shell-design
3. Shell implementation and tests
4. Infrastructure services implementation and tests
5. Use Case Analysis
6. Overall WorkItem design
7. Use Case refinement
8. Final WorkItems design and packaging
9. WorkItem implementation and tests

Indentifying WorkItems

                RootWorkItem acts as central entry point for global services and WorkItems added by modules.

                ModuleController WorkItem acts as a root WorkItem within a module.

                Firs-level WorkItems are directly added to RootWorkItem or the ModuleController WorkItem without having any other parents in between. They are entry points into a specific business-related task.

                Design WorkItem based on use case diagram, in most cases, one WorkItem and user case is 1:1 mapping, WorkItems are nothing else than use case controllers implement the UI processes necessary for completing a use case(task) and putting together all the required parts for doing so.

                Relationships between use cases can be of two different types: a use case is either a sub-use case of another use case  or use case is used by many other use cases and not only by its own parent. Pure sub-use cases are sub-WorkItems that are not accessible from outside their parents. Use case used by many other use cases in addition to its own parent need to be accessible directly or through their parent WorkItem. When a use case logically belongs to parent use case, but it does not share state, context, or anything else with other sub-use cases and that it does not also depend on shared state, context or other commonalities. To avoid unnecessary overhead in that case, you should also make these WorkItems first-level WorkItems, such as “Find Stock” and “Find Business”.

Packaging WorkItems into Modules

Basically, one package logically related WorkItems that address the same space of business into a module. The following are also required for deciding how to package of WorkItems into Modules:

1. Security. Modules can be configured based on role membership of a user.
2. Configurability.
3. Reusablility.

If the configuration requirements, security requirements and reusability requirements are equal for some of the WorkItems that are outsourced into separate modules, one can package them into one module instead of three modules.

CAB Infrastructure Usage Guidelines

Relationship between use cases represent interaction between use cases. Two types of interaction between components exist in CAB:

1. Active communication through an implementation of the command pattern
2. Passive communication through event broker system

Using the Event Broke System

Use the event broker for loosely coupled types of communication. That means if a CAB component(WorkItem, controller,presenter,SmartPart,Service)wants to provide information to other without getting immediate response and without requiring knowing who receives events, the event broker is the right way to go.

Using the Command Pattern

If your component needs something to be done immediately by another component or is passing control on to this other component, the Command Pattern infrastructure can help accomplish these goals. Use commands for launching WorkItems (or sub-WorkItems) instead of events.