DOC PREVIEW
UT EE 382V - Design Rationale Modeling Representations

This preview shows page 1-2-3 out of 9 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

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

UT EE 382V - Design Rationale Modeling Representations

Documents in this Course
Load more
Download Design Rationale Modeling Representations
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Design Rationale Modeling Representations and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Design Rationale Modeling Representations 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?