Modules have these characteristics: (i) they facilitate separation of concerns; (ii) they promote encapsulation; and (iii) module integration can be defined in terms of modules’ interfaces. These notions date back at least to Parnas [11]. The metaphor suggests these ideas: that views, like modules, address separate concerns; that to the extent that views can be non-interfering, those views “encapsulate” concerns; and that if we had some notion of “view interface,” it may be useful to talk about view integration via interfaces.
Pursuing the metaphor further, we might characterise interfaces in terms of the resources they provide and require from other views: a provides interface exports viewpoint elements to be used by other views. A requires interface identifies “formal parameters” of the view which must be supplied by another view. In the example, the Capability View provides components and connectors. The Commerce View requires that actors and values be instantiated from outside the view, etc.
Defines standard
Replaced/Superseded by document(s)
Cancelled by
Amended by
File | MIME type | Size (KB) | Language | Download | |
---|---|---|---|---|---|
Paper-Architectural Views hilliard01c-dont-ask-dont-tell.pdf | application/pdf | 18.4 KB | English | DOWNLOAD! |