An Outline for a Course on Software Architecture

This is taken from the Shaw and Garlan book, Software Architectures: Perspectives on an Emerging Discipline

Introduction (3 lectures)

• Orientation. What is the architectural level of software design, and how does it differ from intra-module programming?
• What Is a Software Architecture? Constructing systems from modules. Some familiar kinds of architectures. Some common kinds of modules.
• Classical Module Interconnection Languages. (from procedural to object-oriented)

Procedure Call (3 lectures)

• Objects. Information hiding, abstract data types, and objects. Organizing systems by encapsulating design decisions, or "keeping secrets."
• Modular Decomposition Issues. Keyword In Context, KWIC, problem introduction. Considering how to weigh the benefits of various decompositions for a system.
• Formal Models. Basic notation of the Z Specification Language. The schema calculus.

Dataflow (4 lectures)

• Batch Sequential and Pipeline Systems. Systems where data flow linearly through a sequence of discrete processing steps. Contrasts executing to completion at each step with continuous flow through a system and incremental processing
• Tektronix Case Study. Specific example of a pipeline system used as part of a larger application. Example of formally modeling components and connectors.
• Implementation Using Unix Pipes. The Unix paradigm connects independent processes by dataflow. The organization of the processes, and the style and tools for connection are substantially different.
• Formal Models for Dataflow. Formal model of pipes and filters. Use of formalism to explain what a software architecture is and to analyze its properties.

Repositories (3 lectures)

• Databases and Client-Server Systems. Databases and client-server systems use a centralized, persistent store of information. This contrasts with dataflow architectures.
• Blackboard Systems. Sharing complex knowledge about a problem; making progress when you can't tell in advance what order to impose on the subproblems.
• Architectural Evolution and Industry Issues. Historically, the requirements of users coupled with advancing technology have produced an architecture evolution from batch sequential systems through pipelines to repositories. Consideration of how industry deals with choices.

Events (2 lectures0

• Models of Event Systems. Distinguishing implicit invocation from client-server communication and point-to-point message passing. Using formal models to define a general architecture which can be further specified as needed.
• Implementations of Event Systems. Examines and compares two implementations which enable components to communicate via events. Presents alternatives for the underlying implementation of implicit invocation mechanisms.

Processes (2 lectures)

• Communicating process architectures. Topologies and techniques for orchestrating multiple, independent but communicating processes to collectively solve a problem.
• Formal Models for Processes. Introduction to CSP for modeling sequences of execution. Comparison between CSP and Z schema calculus.

Other Architectures (1 lecture)

• Interpreters, Process Control and Heterogeneity. Two examples of architectures frequently found in practice. Examples of how "pure"architectures often appear combined in implemented systems.

Design (9 lectures)

• Design Assistance. The selection of a software architecture should depend on the requirements of the application. This example of a system shows how to make the structural design of a user interface explicitly dependent on the functional requirements.
• Classification of Architectural Constructs. Presentation of a partial taxonomy for architectural styles, components and connectors.
• Interface Matching.
• Aesop
• UniCon
• Heterogeneity and Mismatched Parts.
• Information Architectures for Cyberspace.
  
• Architectural Languages
• Patterns and Pattern Languages. Identifying patterns in the use and combination of architectural styles and components, as well as recording and communicating the patterns in useful ways.

*************************

One section that must be added is the documentation of non-functional requirements. Without an agreed upon way to capture the requirements, it is difficult to explain what is meant by quality software or the power these requirements can exert over the shape of the system.