Discussion Questions

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?





Documenting Software Architectures(c) Views and Beyond
Documenting Software Architectures: Views and Beyond
ISBN: 0201703726
EAN: 2147483647
Year: 2005
Pages: 152
Simiral book on Amazon

Flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net