Software Architecture

• Describe in single document
• Close to the requirement
• Design constraints that apply systemwide
• Change of the architecture is expensive during the construction

Typical Architectural Components

• If you are building the whole system yourself, your work on the architecture will overlap your work on the more detailed design
• If the architecture is designed by someone, you should be able to find the important components by yourself

Program Organization

• The architecture provides the rationale for the system organization and show that each class has been carefully considered
• The architecture should define the major building blocks in a program
  • single class
  • subsystem consisting of many class
  • routine work together on high level function
• Building block should have one area of responsibility
• Minimizing what each building block knows about other building blocks
• The communication rules for each building block should be well defined

Major Class

• Identify the responsibilities of each major class
• Specify the 20 percent of the class that make up 80 percent of the system behavior

Data Design

• Data should normally be accessed directly by only one subsystem or class
• It should describe alternatives that were considered and justify the choices that were made.

Business Rules

• If the architecture depends on the specific business rule, the impact to the system from it should be described

User Interface Design

• Should be specified in the software architecture
• The architecture should be modularized so that a new user interface can be substituted without effect the business rules and output of the program

Resource Management

• Memory constraint
• Network connections

Security

• Rules for handling untrusted data
  • user input
  • cookies
  • configuration
• Encryption
• Level of detail contained in error messages
• Protect secrete data in memory

Performance

• Speed vs memory
• Space and time budgets for each class or object

Scalability

• Ability of a system to grow to meet future of the demands
  • Number of user
  • Number of server
  • Size of database record
  • Number of network nodes
• If the system is not expected to grow and scalability is not the issue

Interoperability

• Share data or resource with other software or hardware should be described

I18n

• program to support multiple locales

Error Processing

• One of the thorniest problem
• Handle them consistently should be spelled out in the architecture
• Is error corrective or merely detective?
• How does the program propagate error?
  • Immediately discard the data that caused the error and enter the error processing state
  • Wait until all the process complete
• What are the conventions for handling error messages?
• Level of responsibility of each class
  • Each class validate their own data
  • Group of class responsible for validate the data
  • Can class at any level assume that the data received are clean?

Fault Tolerance

• The architecture should indicate the kind of fault tolerance expected

Architectural Feasibility

• If infeasible in any area could render the project unworkable, the architecture should indicate how those issues have been investigate through PoC or research
• These risk should be resolved before full-scale construction begin

Overengineering

• An architecture specifies a more robust system than that specified by the requirement

Buy vs Build Decisions

• The most radical solution to build software is not to build it at all
  • buy it instead
  • use open-source
• If the architecture isn’t using off the shelf components, it should explain how self built component surpass ready make libraries and components

Change Strategy

• Making the architecture flexible enough to accommodate likely changes
• The strategy for handling change should be described

General Architecture Quality

• The problem with large system is to maintain the conceptual integrity and consistency
• Good software architecture is largely machine and language independent
• Identify the risk