ISO/IEC JTC1/SC7 /N3848

Transcription

1 ISO/IEC JTC1/SC7 Software and Systems Engineering Secretariat: CANADA (SCC) ISO/IEC JTC1/SC7 /N Document Type Title Source Report Frameworks in ISO/IEC (DIS 25961) WG42 Project Status Final Reference Action ID Distribution FYI or ACT AG No. of Pages 7 Note Please send comments to the WG42 Convener Address reply to: ISO/IEC JTC1/SC7 Secretariat École de technologie supérieure Department of Software and IT Engineering 1100 Notre Dame Ouest, Montréal, Québec Canada H3C 1K3 secretariat@jtc1-sc7.org

2 ISO/IEC JTC 1/SC 7/WG 42 N Title Frameworks in ISO/IEC (DIS 25961) Source Reference Status Replaces Document type Action ID Due date David Emery, ANSI ISO/IEC JTC 1/SC 7/WG 42 N0039 Final N/A Project input FYI and ACT ASAP Comments This Project input was submitted to the WG42 BoF on Architecture Frameworks already in November The document was discussed at the May 2007 meeting in Moscow, where a decision was taken to circulate it for informal SC7 comments prior to the Montreal meeting in October N0039_Frameworks in (DIS 25961).doc Page 1 (7)

3 Architecture Frameworks in DIS (or whatever we end up calling it David Emery (with much assistance from Rich Hilliard) Revision history: Version 1, 2006 November 06 (Limited circulation) Version 1.1, 2006 November 28 (includes comments from Rich Hilliard, Mark Maier & Paul Clements) Kommentar: Lesson learned with Model and other terms in 1471 was always prefix the term with architectural, lest there be misunderstanding. 1. Purpose & Organization This paper establishes an initial attempt to incorporate frameworks into the existing ISO DIS 25961/IEEE 1471 standard. It is a direct outgrowth from discussions at the WG42 meeting in Seoul, 2006 Oct-Nov. This paper is more-or-less laid out according to sections in the current IEEE 1471 standard, to facilitate eventual incorporation into the revised ISO Architecture Standard. The hope is that we can evolve both the text for the revised standard and our overall approach to dealing with Architecture Frameworks (both those that are ISO Standards such as RM-ODP and GERAM, and those in wide practice such as DoDAF, 4+1 or TOGAF). Everything in here is subject to discussion, the intent of this paper is to start that discussion, particularly as our frameworks BOF looks at integration of the standard with other ISO standards that provide what we hope fit the definition of architecture framework below. 2. Terms & Definitions architecture framework A set of predefined viewpoints, concerns, generic stakeholders and viewpoint correspondence rules, that have been established to capture common practice for architecture descriptions in specific domains or user communities. view correspondence A connection or mapping between elements of views in an architectural description, used to establish consistency or similar relationships that apply to the architecture being described. A view correspondence may be an instance of a viewpoint correspondence rule, e.g. as provided by an architectural framework, or may be established within the context of a given architectural description. (Example: One view V1 might establish a relationship between software elements and hardware elements. Another view V2 would list the software elements. A view correspondence would list each architectural element from V2, and show that it is assigned to a hardware element in V1. A second view correspondence would establish that all software elements in V2 appear in V1, perhaps through an aggregration that shows how multiple software elements in Kommentar: This may cause us to define view element. Of course, we always wanted to have view elements, because: that s the superclass for components, connectors and constraints

4 V2 are mapped to a single element in V1; but all elements in V1 can be traced to elements in V2. VP1 V1 VP2 V2) viewpoint correspondence rule A specification or declaration for a connection or mapping between elements identified in multiple viewpoints, i.e. the template for a view correspondence that should be present between the actual views of an architectural description. An architectural description is responsible for identifying the viewpoint correspondence rules that apply, and then demonstrating that the rules hold. Viewpoint correspondence rules are often provided by architectural frameworks, but could also be provided as part of an organization s architectural practices or may be provided solely for use in a single given architectural description. Where a viewpoint correspondence rule is provided, the architecture description should contain view correspondences that implement these rules for the given architectural description. Kommentar: There s a commutative diagam crying out to be included here. I ll draw it and related it to your terms tomorrow. Kommentar: This terminology should match whatever we use for viewpoints (which needs fixing). (Example: A viewpoint VP1 may require the identification of software elements that are composed into executable programs. A second viewpoint VP2 may associate executable software elements with hardware elements that execute them. A viewpoint correspondence rule between the two viewpoints would require that software elements identified in conforming views be traceable so that VP2 only references items known in VP1, and vice versa. A second view correspondence would provide that all software elements in V2 are accounted for in V1, and a third would provide that no element exists in V1 unless it also exists in V2. Together, these view correspondences provide that the two views have a consistent list of software elements.) generic stakeholder - In a library viewpoint, a generic stakeholder may be identified to establish concerns that the library viewpoint addresses, where the specific stakeholder for a given architectural description is not known. Architectural Frameworks often use generic stakeholders to motivate the concerns in the library viewpoints defined by the architectural framework. 3. Reference Model and General Concepts The short summary is that Architecture Frameworks exist to define library viewpoints for conforming architecture descriptions. To do this, the architecture framework must establish the concerns associated with its library viewpoints, and identify generic stakeholders that have these concerns. Architecture frameworks also provide viewpoint correspondence rules, that relate parts of viewpoints to each other. An architecture description conforms to an architecture framework by providing views that correspond to the architecture framework s viewpoints, and view correspondences that correspond to the architecture framework s viewpoint correspondence rules. By closure, the conforming architecture description must reference the architecture viewpoint s Kommentar: Probably makes most sense to make this a separate diagram from the picture in current figure 1. It probably has 3 parts: conceptual, concrete, framework

5 concerns and provide a mapping to the architecture viewpoint s generic stakeholders to the architectural description s actual stakeholders,. Reference Model with Framework added in Items in red above show the additions to the existing 1471 reference model added to address the notion of architecture framework. Note that Viewpoint Correspondence Rule and View Correspondence are not tightly coupled to Architecture Framework, these should be added to the base model as concepts we want to add in ISO The basic concept here is that an architecture framework consists of * A set of library viewpoints * A set of concerns associated with the library viewpoints * A set of generic- stakeholders who have these concerns * A set of Viewpoint Correspondence Rules

6 An architecture description may conform to 0 or more frameworks (it s possible for a given architecture description to conform to more than 1 framework, but that would imply some unification/reconciliation/deconfliction between each framework s set of stakeholders, concerns and library viewpoints.) The framework must identify at least one library viewpoint (otherwise why bother?, and by inheritance, that means that the architecture framework must identify at least one concern for that library viewpoint, and at least one (generic) stakeholder that has such a concern. An architecture framework may also specify Viewpoint Correspondence Rules, and a conforming architecture description must have View Correspondences corresponding to (meeting the requirements of) the Viewpoint Correspondence Rule. Question: Do we want to relate correspondences to model/model elements? My perspective right now is that s excessive detail. The main point is that there s some stated associations between stuff in viewpoints, and between stuff in views. What that stuff is we should keep as loose as possible as to not arbitrarily constrain what kinds of correspondences can be established. 4. Specific normative requirements need to capture the rules from above as shalls. 5. Existing Frameworks (in terms of this standard) a. DoD Architecture Framework (DoDAF) b. Kruchten s 4+1 c. Zachmann d. RM ODP e. GERAM f. TOGAF Others? 6. Bibliography/References

7 Comments 1. exchange: Maier, Hilliard & Emery Maier: I'm really uncomfortable with "View Correspondence." I think the notion of two views being consistent is central. But, I don't think any notion that assumes or implies that consistency and "mapping," as in the one-to-one example in the text, are the same thing. A system could have software that is allocated very dynamically to its hardware and in a fashion that would defy one-to-one tracing, and work very well. We don't want to create a situation where simple traceability tables to low levels in the component hierarchy are the assumed solution. Hilliard: Agree that 1-1 mapping of elements is too strong. Mathematically, view correspondences should be binary relations, i.e., given two views, V1 and V2, a view correspondence vc, is a relation: vc V1 x V2 This gets around the 1-1 problem which is too strict, and around the "mapping problem" which is also too strict: e.g., you might want to allocate a process to multiple nodes; you can't do that with a mapping, but can with a relation. Emery: Are we talking about the normative text or my (perhaps poorly chosen) examples? Hilliard: Note: It might be tempting to generalize binary relations to n-ary relations, (vc V1 x... x Vn) over N views at-a-time, but that might be harder for users to work with. Keeping correspondences as binary can be motivated by what users already know about traceability, and there ought to be some equivalences between a set of binary relations and an n-ary relation (I will have to brush up on my relational algebra). Also: we will need some notion of elements of views to make this approach to correspondence work. Element is not defined in the present conceptual framework. But, remember, in the prehistoric days (mid 1990s), we had an idea that each view was constructed out of components, connectors and constraints. Philippe has this in 4+1 paper: he shows the type of components and connectors for each type of blueprint. Maier: Rules for consistency are key, but are we going to be able to say thing generally about them? Are they going to be things we understand in the abstract but that defy any lower level standardization? Hilliard: I think we could use the same paradigm as we did for viewpoints and views; that paradigm was: Tell me what you are going to model with (the viewpoint definition) and then model it (the view). I think in this area we do the same:

8 Define a notion of viewpoint correspondence rule, and a notion of view correspondence. Every view correspondence must realize a viewpoint correspondence rule. Maier: In the figure, should it not be the case the "architecture framework" has elements that are abstract, but are concretely implemented in a given AD? What is the appropriate diagrammatic representation of that? Hilliard: I suspect we will want to put architecture framework into a separate diagram. Also, while talking through the current diagram at WG 42, I remembered it has two layers: * Mission, System, Environment,... is the CONCEPTUAL LAYER. * AD, View, Viewpoint,... is the CONCRETE LAYER. It might be time to make the separation clearer, because all our work in 1471 is only on the lower layer, it is "parameterized" by the constructs at the Conceptual layer.