39.3. Example: A NextGen POS SAD
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 ProjectIntroduction: Architectural Representation This SAD summarizes the architecture from multiple views. These include:
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 memoa 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 Factors See the Supplementary Specification factor table of architecturally-significant requirements starting on p. 548.Architectural Decisions (Technical Memos) |
Technical Memo: Issue: ReliabilityRecovery from Remote Service FailureSolution Summary: Location transparency using service lookup, failover from remote to local, and local service partial replication. Factors
Solution Achieve protected variation with respect to location of services using an Adapter created in a ServicesFactory. 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 AdaptabilityThird-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.Motivation 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 Issuesnone 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: LegalTax Rule ComplianceSolution Summary: Purchase a tax calculator component. Factors … Figure 1. Package diagram of the logical view.[View full size image] Figure 2. Deployment view.Figure 3. A data flow view for a Process Sale scenario.67. By implementing this use case, most of the key architectural issues were confronted and resolved. A key system operation is enterItem ; see Figure 4 for a partial interaction scenario across some noteworthy logical boundaries. Figure 3. A partial use-case realization in a Process Sale scenario.[View full size image] |