Architecture Description

• The highest level of abstraction of a system– the ‘bigger picture’.
• Describes top level decisions which guide development and provide conceptual integrity.
• Specifies choice of frameworks, languages, scope, goals, and high-level methodologies.
• Guides programmers; provides a reference.
• Explains rationale for choices which is useful for maintenance.

Considerations Include

• Program Organization
• Major Classes/ Functions
• Data Design
• Business Rules
• User Interface Design
• Resource Management
• Security
• Performance
• Scalability
• Internationalization
• Input/ Output
• Error Processing
• Fault Tolerance
• Feasibility
• Over Engineering
• Buy vs Build
• Reuse
• Changing Strategies
• Time

Program Organization

• Can vary in scope, from the subsystem level down to individual classes.
• Depends on size of project.
• Each building block should provide a high level function.
• Every requirement should have at least one building block which addresses it.
• Requirements can appear in more than one block because they should cooperate; this communication should be described.

Major Classes/ Functions

• Identify major classes and their responsibilities.
• Which classes perform the majority of the operations.
• Include class hierarchies, state transitions, persistence.

User Interface Design

• Describe major elements
  • Format for pages
  • GUIs
  • Command lines
• Should be modular; a new interface should be able to be substituted.

Performance

• If there are performance goals in the requirements then explain why the proposed architecture can meet them.
• If there are parts of the system that might not meet the goals then identify them.
• Explain algorithms and data structures which were chosen for performance (justification).

Scalability

• How can the system grow in the future? Is it expected to grow at all?
• Describe in terms of number of users, servers, database records, transactions, etc. where relevant.

Error Processing

• Up to 90% of a program can be for error handling
• Detect or correct errors?
  • Correction means the program tries to recover.
  • Detection means ignoring the errors or quitting after reporting them.
• Active or Passive?
  • Active means the program expects errors, continuously checks for valid input.
  • Passive means the program only responds when the error causes a problem.
• Where are errors handled?
  • Detected in error handling class?
  • Passed up to higher level in architecture for detection?

Changing Strategies

• Describe the strategy for handling change.
  • Show that possible enhancements have been considered.
  • Describe the easiest to implement
• Possible changes include:
  • New data types.
  • New file formats.
  • Different or new functionality.

Time

About 20-30% of development time is spend on:

• Problem definition.
• Requirements gathering.
• Architecture.