1: |
What is it possible and not possible to say about data flow by looking at a view in the module viewtype? What about control flow? What can you say about which modules interact with which other modules? |
2: |
Which properties of a module might you think of as worthy of having special notational conventions to express them, and why? For example, you might want to color a commercial-off-the-shelf (COTS) module differently from modules developed in-house. |
3: |
The depends-on relation among modules is very general. What specific types of dependencies might be reflected in a style in the module viewtype? |
4: |
A primary property of a module is its set of responsibilities. How do a module's responsibilities differ from the requirements that it must satisfy? |
5: |
When documenting a particular system, you might wish to combine modules into an aggregate, to market them as a combined package, for example. Would this package itself be a module? That is, are all aggregates of modules themselves modules? |
Software Architectures and Documentation
Part I. Software Architecture Viewtypes and Styles
The Module Viewtype
Styles of the Module Viewtype
The Component-and-Connector Viewtype
Styles of the Component-and-Connector Viewtype
The Allocation Viewtype and Styles
Part II. Software Architecture Documentation in Practice
Advanced Concepts
Documenting Software Interfaces
Documenting Behavior
Choosing the Views
Building the Documentation Package
Other Views and Beyond
Rationale, Background, and Design Constraints
References