Example: A NextGen POS SAD - UML

In this and subsequent examples, my goal is not to exhaustively show a thorough 10 + page SAD with fully descriptive text and detailed diagrams, but to give a flavor of what may be included.

Software Architecture Document NextGen POS Project

Introduction: Architectural Representation

This SAD summarizes the architecture from multiple views. These include:

  1. logical view: ...brief definition
  2. data view: ...
  3. process view: ...

In addition, this SAD references the Supplementary Specification where you will find the architecturally - significant requirements recorded in a factor table. It also summarizes the key architectural decisions in a format called a technical memo - a short one - page description of a decision and its motivation.

Note that each view includes a discussion of motivation, which may help you when you need to modify the architecture.

Architectural Decisions (Technical Memos)

Technical Memo

Issue : Reliability - Recovery from Remote Service Failure

Solution Summary : Location transparency using service lookup, failover from remote to local, and local service partial replication.


  1. Robust recovery from remote service failure (e.g., tax calculator, inventory)
  2. Robust recovery from remote product (e.g., descriptions and prices) database failure


Achieve protected variation with respect to location of services using an Adapter created in a Services - Factory. Where possible, offer local implementations of remote services, usually with simplified or constrained behavior. For example, the local tax calculator will use constant tax rates. The local product information database will be a small cache of the most common products. Inventory updates will be stored and forwarded at reconnection.

See also the Adaptability — Third - Party Services technical memo for the adaptability aspects of this solutions, because remote service implementations will vary at each installation.

To satisfy the quality scenarios of reconnection with the remote services ASAP, use smart Proxy objects for the services, that on each service call test for remote service reactivation, and redirect to them when possible.


Retailers really don't want to stop making sales! Therefore, if the NextGen POS offers this level of reliability and recovery, it will be a very attractive product, as none of our competitors provide this capability. The small product cache is motivated by very limited client - side resources. The real third - party tax calculator is not replicated on the client primarily because of the higher licensing costs, and configuration efforts (as each calculator installation requires almost weekly adjustments). This design also supports the evolution point of future customers willing and able to permanently replicate services such as the tax calculator to each client terminal.

Unresolved Issues - none
Alternatives Considered

A "gold level" quality of service agreement with remote credit authorization services to improve reliability. It was available, but much too expensive.

Technical Memo

Issue: Legal - Tax Rule Compliance

Solution Summary: Purchase a tax calculator component.

Factors ...

Figure 1.Package diagram of the logical view

Discussion and Motivation

A classic layered architecture is used. No application layer of sessions objects was inserted between the Ul and Domain layers, as the system operations are simple, without much workflow coordination. The primary controller receiving the system operation requests from the Ul layer is the Register class. Note that a facade is placed in front of access to the Jess rule engine as we may wish to use an alternative in the future.

Figure 2.Deployment view

Discussion and Motivation

The product database, inventory system, and tax calculator are deployed to different computers for performance and reliability goals. The tax calculator is centralized, rather than replicated on each POS terminal, because of its high licensing cost; there is a chance that in the future it will be inexpensive enough to replicate locally on each POS terminal.

Data View

Discussion and Motivation

A Process Sale use case scenario is a good example to understand the major data flows. A UML activity diagram is applied in a data - flow flavor to illustrate the major flows and data stores.

Transformation of data read from the Products database into Java objects is done with the Hibernate O - R mapping system.

Transformation of sale data written to the ERP databases (inventory and accounting) is done by a custom NextGen adapter, usually into an XML format required by the ERP system.

Transformation of the payment request data sent to the external payment authorization service is done by a custom NextGen adapter, usually into the well - known VISA format (and protocol).

Motivation? These external systems and databases were a hard constraint that we had to conform to.

Figure 3. A data flow view for a Process Sale scenario.

Use - Case View

The most architecturally significant use case is Process Sale. See the use - case text starting on. By implementing this use case, most of the key architectural issues were confronted and resolved. A key system operation is enterltem; see Figure for a partial interaction scenario across some noteworthy logical boundaries.

Figure 3.A partial use - case realization in a Process Sale scenario

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

UML Topics