- 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.
- Program Organization
- Major Classes/ Functions
- Data Design
- Business Rules
- User Interface Design
- Resource Management
- Input/ Output
- Error Processing
- Fault Tolerance
- Over Engineering
- Buy vs Build
- Changing Strategies
- 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
- Command lines
- Should be modular; a new interface should be able to be substituted.
- 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).
- 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.
- 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?
- 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.
About 20-30% of development time is spend on:
- Problem definition.
- Requirements gathering.