11Design Rationale Modeling RepresentationsEE382V Software Architecture and Design IntentPankaj Adhikari, Bill Reinhart7 MAR 2006Design Rationale Modeling RepresentationsEE382V 2Agenda Why Rationale? Design Rationale’s Roots Modeling Rationale IBIS / gIBIS / Tailored IBIS / PHI DRL QOC Model Comparison SummaryDesign Rationale Modeling RepresentationsEE382V 3As we know … Requirements are in problem domain terms; architecture often in solution domain terms. Rationale determines the mapping between the functional and non-functional requirements and the architecture. Requirements Æ (rationale) Æ Architecture Design Rationale Modeling RepresentationsEE382V 4As we know … Rationale tells “WHY” Criteria Plans Alternatives Non-Functional Requirements Capturing Design Rationale is a key aspect in effective Communication (inter-organization), effective Documentation (external record), and system evolution2Design Rationale Modeling RepresentationsEE382V 5Why Formalize Design Rationale? Formalization will/can lead to identification of weak or inconsistent design logic The development of more powerful/succinct SW Formalization will provide ideal mechanism for indexing / retrieving the design Without some form of retrieval mechanism, Design Rationale capture in useless Effective retrieval mechanism will reduce future maintenance costs Design Rationale Modeling RepresentationsEE382V 6Design Rationale RootsDesign Rationale Modeling RepresentationsEE382V 7DR Roots (Formalizing Argumentation) Goal: A system in which creation and retrieval of trails of relevant information mimics human reasoning & memory Key Hypothesis: By making the structures of arguments explicit, they can be more rigorously constructed, explored and communicated Design Rationale Modeling RepresentationsEE382V 8DR Roots (Formalizing Argumentation) Formal. (ie. full written documentation) Overly costly Can bog down creative thought & development Informal. (ie. memos, email, meetings etc) Created by numerous everyday artifacts Difficult to coalesce into single coherent artifact Semi-Formal. (approaches to be discussed) Provides framework without limiting cognitive exploration3Design Rationale Modeling RepresentationsEE382V 9DR Roots (Representing Concepts) Hypertext capabilities Auto-links, Pop-up Formats, Coloring, etc Strikes a balance between computational needs (a structure) and natural human thought processDesign Rationale Modeling RepresentationsEE382V 10DR Roots (Research and SW Support) Research into the development of computational support for reasoned discourse or argumentation Toulmin – (1958) analyzed and depicted the structure of argumentation graphically Engelbert – (1963) one of the first to envision the use of technology for manipulating “concept structures” Kunz and Rittel – (1970) developed argumentative approaches to design (IBIS - Issue-Based Information System) Xerox PARC – (1987) Argnotertool (argumentation spreadsheet) for representing arguments in group designDesign Rationale Modeling RepresentationsEE382V 11IBIS - Issue-Based Information System First true approach to representing design rationale. (1970’s) 3 components the model Issues = Design Questions Positions = Answers to the Design Questions Arguments = Either Support or Refute Positions Used successfully in a number of non-engineering applications. gIBIS, tailored IBIS and PHI : attempts to use IBIS to model engineering design. Design Rationale Modeling RepresentationsEE382V 12IBIS – Structure4Design Rationale Modeling RepresentationsEE382V 13IBIS – Benefits / Drawbacks Benefits (+) Captures human reasoning (+) Foundation for numerous other models (+) Highlighted importance of distinctly addressing rationale ina design process Drawbacks (-) Extremely complex and hard to parse (-) No mechanism for associating Issues to a design decision (-) No mechanism to control/focus discussions (-) Only models/captures design questions that can be deliberated (directly design related issues)Design Rationale Modeling RepresentationsEE382V 14gIBIS – graphical IBIS Hypertext system of the IBIS model Simplified the capture of design rationale Used the IBIS structure and Link typesDesign Rationale Modeling RepresentationsEE382V 15gIBIS – Improvements over IBIS Graphical / hypertext interface Provides mechanism to stop deliberation Provides “other” nodes/links to enable thoughts to be expressed outside of the IBIS framework/rule set Provides “external” node to link non-IBIS artifacts (ie. requirement documents, diagrams, code, etc) Permits Positions to “modify” other positions; Arguments to “modify” other argumentsDesign Rationale Modeling RepresentationsEE382V 16Tailoring IBIS Addresses the shortfall of IBIS in not tying Issues to a Design Decision5Design Rationale Modeling RepresentationsEE382V 17EXAMPLE: Tailored IBIS-based Notation Artifacts are listed in bold, I=Issue, A=Argument, J=JustificationDesign Rationale Modeling RepresentationsEE382V 18PHI – Procedural Hierarchy of Issues Offshoot of IBIS and addresses IBIS shortfalls: Lacking a mechanism to focus discussion Lacking ability to model/discuss non-design issues Issues can “serve” to resolve another Issue (ie. a hierarchy of issues/work) Issues that do not serve the stated aims of the design are (can be) thrown out as irrelevant Also for previous issues that become “stale” Design Rationale Modeling RepresentationsEE382V 19Overview Benefits of IBIS/gIBIS/PHI Provides qualitative decision support tool Methods do decompose issues into sub-issues Can help to tailor conversations Provides means to serve as group memory Note: care must be taken not to unduly prolong the design processDesign Rationale Modeling RepresentationsEE382V 20DRL – Decision Representation Language Major Components: ISSUE: represents the problem that admits alternatives ALTERNATIVE: represents an option being considered GOAL: represents a desirable property used for comparing the alternatives and is elaborated further in terms of its sub-goals Every relation in DRL is a subclass of a CLAIM Possible to manipulate different decisions to see shortfalls/ramifications before commitment Dependency, Precedence,
View Full Document