It is said that a C&C view illustrates a system in execution. Does this mean that it shows a snapshot of an execution, a trace of an execution, the union of all possible traces, some combination, or something else?
As we have mentioned, component is an overloaded term. Discuss the relationship between a component in a C&C view and (a) a UML component and (b) a component in the sense of the component-based software engineering community.
A communication framework, such as Enterprise JavaBeans (EJB), CORBA, or COM, can be viewed as a connector among components or as a component with its own substructure. Which is appropriate, and why?
A user invokes a Web browser to download a file. Before doing so, the browser retrieves a plug-in to handle that type of file. How would you model this scenario in a C&C view?
Figure 3.6 shows an overview architecture diagram for an electronic commerce store. Assume that you are new on the job, without the background of the symbology the organization uses, or perhaps you wrote this some time ago but now have to go back and review the system. Critique the diagram. List places where you think it is misleading, and list the questions that need to be askedand that the diagram fails to answerbefore you can understand its meaning.
Figure 3.6. An overview architecture diagram. Where is it misleading? What questions does the diagram fail to answer?
After you have critiqued Figure 3.6 and have enumerated the information you believe is missing, augment the diagram to make it tell a coherent story. Did you decide that the diagram is describing code-based entities, runtime entities, or both? Did you decide that the boxes called layers are, in fact, layers, or something else? What did you decide the arrows mean?
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
Documenting Software Interfaces
Choosing the Views
Building the Documentation Package
Other Views and Beyond
Rationale, Background, and Design Constraints