Category list

5.6 Summary Checklist

Styles in the allocation viewtype map software structures to structures in the environment of the software.
The software architecture and environmental structures influence each other. The available computing assets environmental structures may exert a strong influence on the software architecture, and software architecture most likely influences the structure of the configuration management system.
The deployment style describes the mapping of runtime software elements to the hardware on which the software executes.
The implementation style describes the mapping of modules on a configuration management scheme and helps the organization of the files that implement the modules.
The work assignment style describes the aggregation of modules according to the people, groups, or teams tasked with the development of the modules.

5.7 Discussion Questions

1:	Construct an allocation style that assigns the runtime files to a file system. Although this style carries important in-formation, seven of the authors voted not to include it in the allocation viewtype. Why do you suppose that was? Although we will not identify the lone supporter, what do you suppose her reasons were?
2:	Suppose that you needed to map the modules under test to the test harness that generates inputs, exercises the modules, and records the outputs. Sketch an allocation style that addresses this concern.
3:	In one project, short identifiers were assigned to every module. A module's full name consisted of its identifier, prefixed by its parent's identifier, separated by a period (.). The project's file structure was defined by a short memorandum stating the pathname of a root directory and further stating that each module would be stored in the directory obtained by changing each period in the module's full name to a slash (/). Did this memorandum constitute an implementation view for this system? Why or why not? What are the advantages and disadvantages of this scheme?
4:	Suppose that your system can be deployed on a wide variety of hardware platforms and configurations. How would you represent that?

5.8 For Further Reading

For more information about documenting the deployment style using UML, visit http://www.rational.com/uml.

Architectured-based management of software projects is discussed in [Paulish 01]. This is the place where the work assignment style comes into play. The relationship between the structure of systems and the structure of organizations that build them was first observed by Conway [Conway 68].

The implementation style is closely aligned with the very broad topic of software configuration management (CM). An in-depth treatment of CM is far beyond the scope of this book, but you can begin investigating the topic by visiting http://www.stsc.hill.af.mil/crosstalk/1999/mar/cmsites.asp, which contains links to other CM- related sites and resources.

Part II: Software Architecture Documentation in Practice

Part I laid the foundations for software architecture documentation by providing a repertoire of styles from which to choose and build views for a system; Part II presents information to complete the picture and to put the ideas into practice.

Chapter 6 explores advanced documentation techniques that apply to many real systems: refinement and chunking of information, context diagrams, creating and documenting combined views, documenting variability and dynamism , and documenting a new style.

Chapter 7 tells how to document the interfaces of architectural elements.

Chapter 8 explores another advanced but essential technique: documenting the behavior of an element or an ensemble of elements.

Chapter 9 provides detailed guidance for choosing the set of views to incorporate into a documentation suite, explores examples of sets of views, and gives two short examples for illustrating how to decide which views to use.

Chapter 10 prescribes templates and detailed guidance for documenting views and documenting information that applies to more than one view.

Chapter 11 examines other well-known prescriptions of software architecture documentation and places them in the context of the material in this book.