1Software Development ToolsSaad Godil & Rashid HameedApril 11, 2006EE 382V – Software Architecture and Design Intent2Introduction| Paper 1: Design Rationale (DR) Systems research paper| Paper 2: Integrating DR with Process Model research paper| Conclusion| Questions3Research Paper I1. Jintae Lee. "Design Rationale Systems: Understanding the Issues". IEEE Expert, Vol. 12, No. 3, 1997, pp. 78-854The Why| Motivation:z Design rationale system can improve:• Management• Collaboration• Reuse• Maintenance• Learning• Documentation25The Why| Objective:z Purpose of paper to help researchers and developers of future design rationale systems understand the options and tradeoffs 6The HowMethodology:| Informal Survey of major existing design rationale systems| Discussion with workshop participants, including those in the 1992 AAAI Design Rationale Capture and Use Workshop7The WhatNarrowed down to Seven main issues:1. What Services to Provide2. What to Represent Explicitly3. How to Represent Rationales4. How to Produce Rationales5. How to Access Rationales6. How to Integrate the system7. How to Manage Rationales Cost-Effectively8The What1. What Services to Provide2. What to Represent Explicitly3. How to Represent Rationales4. How to Produce Rationales5. How to Access Rationales6. How to Integrate the system7. How to Manage Rationales Cost-Effectively39The What: Issue 1Common Services classified into four major groups (and who benefits):1. Better design (designers)2. Better Maintenance (system maintainers)3. Learning (new trainee, students …)4. Documentation (future designers and maintainers)10Issue 1: Better Design| Dependency Managementz Design as a process of managing dependenciesz DR can make explicit dependency relations among: • Design parts• Decisions• Arguments• Alternativesz Allows all of these to work together consistently11Issue 1: Better Design| Collaboration/ Project Managementz DR provides common foundation when multiple parties are involvedz Ex: Shared-DRIM: system checks for conflict whenever design makes recommendation, informs all relevant parties, identifies cause of change, and looks for constraint violations12Issue 1: Better Design| Reuse/Redesign/Extension Supportz Serves as indices to past knowledge• EX: SoftDA acquires relationship information about design and requirements and uses it to index documents and codesz Designers reuse the rationales themselves• Ex: Sibyl uses the goals from past decision rationales to suggest potentially relevant alternatives, and uses both goals & alternatives to retrieve the arguments for the alternatives413Issue 1: Better Maintenance| DR explains design decisions and therefore will also be helpful for maintaining the design| Most existing systems provide this service using “comments”| Ex: EES extracts richer development rationales, using them to generate more sophisticated explanations for system maintenance14Issue 1: Learning Support| DR helps both people and system learn mutually| Ex: Janus has “critics” which provides designer with appropriate recommendation if it encounters a sub-optimal decision15Issue 1: Documentation| Automatically generate documentation| Helps other than designerz Managers can use to evaluatez Lawyers can use to determine if design is Intellectual Property16The What1. What Services to Provide2. What to Represent Explicitly3. How to Represent Rationales4. How to Produce Rationales5. How to Access Rationales6. How to Integrate the system7. How to Manage Rationales Cost-Effectively517Issue 2: What to RepresentThere are two aspects to this:1. Functional Dependency2. Generic Structure| Decision Layer| Design Artifact Layer| Design Intent18Issue 2: Functional DependencyRepresentation depends on use:| Argumentation Perspectivez Used by designers for problem solvingz Logical structure Æ explicit| Documentation Perspectivez Enable outsiders to understandz Only results need to be captured| Project Managementz Metrics for project status must be captured• Ex: pending issues, deadlines and people responsible for them19Issue 2: Generic StructureDesign Layer| Issue| Argumentz Explicit arguments underlying a decisionz Relation: support, refutes qualifies| Alternativez Explicit individual alternativez Relation to the argument| Evaluation z Explicit evaluation measurez Relation: nominal, ordinal, real values | Criteriaz Explicit criteriaz Relation: mutually exclusive, tradeoffs20Issue 2: Generic Structure…Design Layer:| Not all sub-layers always present| gIBIS only represent issue, alternative and argument| DRL same as gIBIS, but adds criteria layer/constructs| DRCS provides evaluation layer| Note: extra layers come with extra over-head621Issue 2: Generic StructureDesign Artifact Layer| Makes explicit the decision making steps and their relation to design components| How info relates to individual decision| Both not always present| Ex: FR only expresses relation between design components and requirements z Useful for simulation, verification….z Not able to show alternatives and arguments explored22Issue 2: Generic StructureDesign Intent Layer| Represents info behind design decisions:z Intents, strategies, goals and requirements| Allows system to reason about the goal or intentz Ex: using the goals, system can derive criteria for evaluating alternatives23The What1. What Services to Provide2. What to Represent Explicitly3. How to Represent Rationales4. How to Produce Rationales5. How to Access Rationales6. How to Integrate the system7. How to Manage Rationales Cost-Effectively24Issue 3: How to Represent| Informalz Unstructured formz Ex: audio/video recordings, raw drawingsz Easy to create but ill-suited for computational services| Semiformalz Parts are usable by computer, rest is informalz Ex: Sibyl: users fill put templates and forms. Some fields are natural language, others are selected from a menu of options| Formalz Object and relation defined as formal objectsz Costly but provides many more computational services725Issue 3: How to Represent| Incremental Formalizationz Transforms semi-formal to formalz Reduces costsz Less overhead• Captured in semi-formal way• Increased benefits when formalizedz Ex: uiSibyl: • Starts with informal requirement descriptions• Tries to map keywords to existing formal objects26The What1. What Services to Provide2. What to Represent Explicitly3. How to Represent Rationales4. How to Produce Rationales5. How to Access Rationales6. How to Integrate the