Intended normative content: clauses 2, 3, 5.2, 5.3, 5.4.1 at a minimum will be normative; 5.5, 5.6, 5.7 will be normative, while 5.6.2 is guidance; clause 6 is newly separated into: 6.1 is normative and 6.2 is guidance.
All action items due for May 23rd videoconference:
General. RH retire all comments except those in green background; those comments may be left for final decision May 23rd or as TBD] and create TOC in d4.0 for May 23rd teleconference.
Note: P1016 D0.39 represents the text version with some changes in clause 5 and 6 in the text without highlight so it is a de facto 'original' to be worked on.
Clause 2. RH add IEEE 830, 1471 and ISO 12207.0 as required references.
Clause 3. TBD: Add term "modeling technique". Definition of the term as a near synonym for design language?
Clause 4. JS to present streamlined narrative, Dr J and RH to revise/complete metamodel.
Clause 5. Dr J to consolidate order of clauses, text as appropriate, esp. 5.8. Requirements for modeling techniques and design languages -- and complete 5.8.2 simple waivers, apply old 4.4.1, and, supported by RH in clauses analogous to IEEE 1471, like 5.4
RH separate table 6.1 into two and arrange viewpoints into 6.1 (required) and 6.2 (recommended as examples of additional viewpoints).
Re 6.1 candidate Required Viewpoints, possible clarifications and text consolidations, point to key references maybe etc.
1. Ten days to prepare designated materials (see below) and have another conference, May 23rd, then consolidate all; if feasible provide D0.5 to reviewers.
2. Plan face-to-face meetings 4-6 months apart until balloting.
3. Future meeting locations: Bar Harbor in late September/early October, Savannah in January, DC in April.
Software Product[less accurate but more informative]
Concrete. Visually separate Composite subtype relationship with a
Concrete (Software Product).
Collection(an example may be a library of related patterns or templates) to aggregate
Abstract (software product)and
Language-System(an example may be a pattern language) to provide rules via relationship with a Collection.
Design Relationshipclass, besides its relationship with
Design Entityis it necessary to declare 'used' relationship with a View? Furthermore a relationship tying SDDs with other SDDs [promoting reusability of designs] may be in place; it is also necessary to analyze and explain
Design Relationship[Types, if their instances are
aggregateetc. then what they generalize, aggregate etc., maybe SDDs as well as
Add explanation: Traceability from Requirements to Design. Implying a recursively defined Requirements (with a Composite Requirement) similarly to Software Product. Backward from SDD to Requirement, the same relationship, implies that Requirement must exist. One aspect of (weak) completeness, for the design may be verified related to traceability by insisting that each R. must have at least one SDD, while spurious/dubious SDD can be found if there is no related R (ditto for some 'missing' requirements, if SDD is indeed useful what are the requirements or what is the requirement? Question of cardinality of associative relationship is significant; the principle being that to connect on the higher level provides generality while on the lower precision [the goal the highest level with a 'tight' fit].
Traceability from Design to Software Product is obvious, and as Software Product is recursively portrayed, traceability follows the lowest level of established connection via 'describes' relationship. Obviously longer traces can also be followed, from Requirements to Software Products (via SDD). A detailed metamodel for Requirements will be of interest but is out of scope of 1016 (it fits 830 scope).