William Regli Geometric and Intelligent Computing Laboratory Department of Computer Science

1. Special Topics in Computer ScienceComputational Modeling for Snake-Based RobotsDesign RationaleWeek 4 William Regli Geometric and Intelligent Computing Laboratory Department of Computer Science Drexel University http://gicl.cs.drexel.edu

2. Design Rationale Definition: an explanation of why an artifact is designed the way it is: • Constraints, functional models, behavioral models • Information • Deliberation, reasoning, decision making • Trade-offs • Design Rationale can be used to • Structure design problems • Provide basis exploration of more design options • Reason among collaborating designers • Record the history of design process • Modify and maintain exiting designs • Adapt existing design to similar design problems

3. Design Rationale is an explanation of why an artifact is designed the way it is It includes information • deliberation in design • reasoning in design • trade-off in design • decision-making in design

4. Advantages of using design rationale in computer aided engineering design • Helps to structure design problem • Provides a basis for designer to explore more design options • Used as a basis to discuss and reason among collaborate designers • Record the history of design process • To modify and maintain the exiting designs for design similar artifacts

5. Design Rationale • Prototypes to support design activity in: • Mechanical Engineering • Architecture, Engineering and Construction • Chemical Engineering • Software Engineering • Few systems have made it into practical use • Past work from many disciplines: • HCI, CSCW, Software Design, AI, Public Policy, Organization Mgt., AEC, Mechanical Design

6. Major Approaches • Process-orientedrepresents a history of an artifact • Feature-orientedlogical representation of an artifact

7. Fundamental Research Issues • Rationale Representation schema • How to represent the design rationale • Rationale Capture • How to record design information and convert it into logic structure • Rationale Retrieval • How to provide design rationale in a design context • System Architecture • How to integrate the many tools

8. Representation Schema • Approaches:Argument-based vs Descriptive • Goals: • Construction of logical structures based on captured information • Query specification and processing • Machine interpretable • Inclusion of multimedia information Some examples (Argumental): IBIS, PHI

9. IBIS:Issue-Based Information System Issue Responds Responds Responds Position 1 Position 2 Position 3 Supports Supports Supports Supports Argument Argument Argument Argument Kunz & Rittel, 70

10. PHI:Procedural Hierarchy of Issues ISSUE: What kind of conveyers should be used in material handling? SUBISSUE: 1. What kind of conveyers should be used in bulk material handling? … 2. Shat kind of conveyers should be used in unit material handling? ANSWERS: 1. Gravity conveyers SUBANSWERS: 1. Chutes, skate wheel conveyers 2. Roller conveyers ARGUMENTS: 1. Its advantage is low cost, relatively low maintenance, and negligible breakdown rate. 2. Its requirement is the ability to provide the necessary gradient in the system configuration. 2. Powered conveyers … 3. Chain-driven conveyers … 4. Power-and free conveyers … McCall, 1991

11. Design Rationale Capture • Two Phases • Knowledge Recording • Rationale Construction • Goals: • Unobtrusive • Conversion • captured information to formal knowledge • Conflict Resolution • Validity Maintenance • Capture and indexing of multimedia-based collaboration

12. Issues for Design Rationale System Architectures • CAD-based • Stand alone • CSCW-based • Document-based • Automatic vs Human Input

13. Capture of design rationaleIt can occur in the design team’s communications via Computer-Supported Collaborative Work (CSCW) tools • Electronic mail • Phone conversations • Archived design meeting • Designers notebooks

14. Goals forDesign Rationale Retrieval • Two Approaches: • Navigation • Automated/Semi-Automated Retrieval • Goals: • Ease of use • convenient, understandable, efficient and user-friendly query specification • Understandable results • Similar to problems in expert systems and KDD • Triggering when in certain design contexts • Agents that monitor design process • Integration with other design support systems

15. Recent and Relevant Work • EXPRESS Schema for Rationale (Shah et al, 1999) • Formal models, Gruber, 91 • McCall et al • PHI (91), Hypertext (89) • MacLean et al, 91 • Design Space Analysis (for HCI)

16. Recent and Relevant Work (cont.) • Concurrent teams, Klein, 93 • Machine Learning, Gruber et al, 91 • Rhetorical structures, decision justification: Garcia et al, 92, 97 • Automatic, Myers et al, 1999 • Text analysis, Dong and Agogino, 1997 • From CSCW, Shipman & McCall 97

17. Open Issues: Representation • Formal languages for Design Rationale • Can we use KIF, Ontolingua, LOOM, XML, DAML, etc? • Ontologies for Design Rationale • Domain specific vs General • Multidisciplinary representations, multiple views and lifecycle uses

18. Open Issues: Capture • Obtrusiveness: how much interference with design activities? • Knowledge Acquisition: how to infer of argumentation and rationale from design activity and raw communication? • Non-Monotonicity: how to resolve conflicts that arise as new knowledge is acquired?

19. Open Issues: Retrieval • Databases • Multimedia, distributed, latency, synchronization • Navigation • Filtering, hiding unneeded details, generation of different views • Higher-Level Indexing • Case-Based Reasoning

20. Generic Design Rationale System Architecture What should be considered? What have been done? Why designed this way? Is this against the criteria and rules? DesignRepositories Retrieval Interactive Design Rationale Design Feedback Product Knowledge-Base Answer designers’ questions Retrieve by query Review similar design cased Navigate Design Rationale Design Rationale Design Reasoning Formulate Design document Representation Schema ProductHistory Evaluate Designs Capture Design Case-base Capture from Design Reasoning Capture from communication TelecommunicationCollaborative Work Design Database CAD CAM CAE Analysis CAD system CAE system CAM system PDM system

21. Recent Work at Drexel • Integrate CAD tools with CSCW tools • email, chat, audio/video conferencing • Automate capture of design rationale in a distributed engineering environment • RepresentDesign Context • Structure captured information for future retrieval and case-based indexing of design process

22. Challenges • Represent design data as it changes over time • Relate collaboration/communication to design data • Add semantic content/context to automatically captured design process data and structure it for future retrieval

23. Approach • CAD: SDRC I-DEAS • CSCW: Collaborative Virtual Workspace (CVW) from Mitre Corp. • Email: Netscape Messenger • Design context and content: XML message model • Database: Oracle 8 Objective: retrieval of design collaboration associated with any model, part of a model, feature of a part, or participant.

24. CVW Experiments • Adapt CVW MOO to design space • Rooms become parts and design constraints • Design process archival agents • Follow discussions and designers • Archive raw design process • Archive audio via speech-to-text • CMU Sphinx

26. Studio Architecture Agents record design process collaboration in CVW MOOand significant events in design space. Email, chat, voice communications stored and cross-referenced with design events and changes.

29. Representation schema It should be designed in the way that • It is easy to construct the captured information into logic structure • It is easy to formulate answers for designers’ queries • It is machine understandable so that it could be processed by computer • It is possible to connect the multimedia information

30. subject of a particular type text - contents of the email, transcript of a audio conference, etc. file - link to the archived original communication attachment - link to optional attachment included with a communication (especially for email) Message Model Contents <!ELEMENTCOMMUNICATION (CONTEXT, CONTENTS)> <!ELEMENTCONTENTS (SUBJECT, TEXT, FILE, ATTACHMENT*)> <!ELEMENTSUBJECT (#PCDATA)> <!ELEMENTTEXT (#PCDATA)> <!ELEMENTFILE EMPTY> <!ELEMENTATTACHMENT EMPTY> <!ATTLISTCOMMUNICATION type (email | voicemail | chat | conference | whiteboard) #REQUIRED medium (text | video | audio | graphics) "text"> <!ATTLISTSUBJECT type (change_request | inquiry | inquiry_response | advisory | solution | problem | other) #REQUIRED> <!ATTLISTFILE src CDATA #REQUIRED> <!ATTLISTATTACHMENT src CDATA #REQUIRED>

31. list of participants, consisting of an author/originator and possibly more than one recipient text - contents of the email, transcript of an audio conference, etc. design data – selection of a designer using IDEAS, such as a part, in question Message Model Contexts <!ELEMENTCONTEXT (DATE, USERS, DESIGNDATA)> <!ELEMENTDATE (#PCDATA)> <!ELEMENTUSERS (INITIATOR, PARTICIPANT+)> <!ELEMENTINITIATOR (FIRSTNAME, LASTNAME, EMAIL?)> <!ELEMENTPARTICIPANT (FIRSTNAME, LASTNAME, EMAIL?)> <!ELEMENTFIRSTNAME (#PCDATA)> <!ELEMENTLASTNAME (#PCDATA)> <!ELEMENTEMAIL (#PCDATA)> <!ELEMENTDESIGNDATA (PROJECT,ASSEMBLY,PART*)> <!ELEMENTPROJECT (#PCDATA)> <!ELEMENTASSEMBLY (#PCDATA)> <!ELEMENTPART (ID, NAME, NUMBER, VERSION)> <!ELEMENTID (#PCDATA)> <!ELEMENTNAME (#PCDATA)> <!ELEMENTNUMBER (#PCDATA)> <!ELEMENTVERSION (#PCDATA)>

32. Lessons Learned to Date • Tight integration of CAD and CSCWneeded to capture design process • COTS software vs. open source • NetMeeting or CVW? • Netscape/Eudora/Outlook or JavaMail • Standard CAD API • Open I-DEAS, JMDL, Pro/DEVELOP… • Formal user studies needed for real design problems

33. Engineering Repositories: Digital Libraries for Design and Manufacture Engineering Digital Libraries contain CADmodels, assemblies, plans, revisions, S-B-F models, project information and workflows, design rationale, email, collaborative activity...

34. National Design Repository http://www.designrepository.org http://repos.mcs.drexel.edu • Over 55,000 CAD and assembly models • Over 10GBs of real data • Contributions from all major CAD vendors Our goal: integrate traditional CAD data with collaborative design process

35. Capturing Design Context in Distributed Communication of Software Engineers By Vera Zaychik Advisor: Dr. William C. Regli Committee Members: Dr. Spiros Mancoridis Dr. Michael E. Atwood

36. Overview • Motivation • Background research • Approach • Implementation • Demonstration (CodeLink) • Future work • Conclusion

37. Motivation • Improve communication between software developers • Software development is increasingly distributed • Communication tools lack context • Preserve development process history • Decisions made by the developers are poorly reflected in the documentation “It’s been said that if NASA wanted to go to the moon again, it would have to start from scratch, having lost not the data, but the human expertise that took it there the last time” - John Seely Brown, Paul Duguid “The social life of information”

38. Scenarios • Scenario 1: Communication • Need to insert a reference to code • Scenario 2: History • Need information about past decisions, alternatives considered, changes made

39. My Approach: Enhanced Collaboration • Extract context from development environment • Include context into email communication • Archive email exchanges • Provide search and browsing of the archives • Extract process history from archived information

40. Scenarios Modified • Scenario 1: Communication • Developer can insert links to specific code • Recipient just needs to click on the link • Scenario 2: History • Look at the messages associated with the code in question • Browse/search the collaboration archive

41. Issues • What data to capture • How to represent it • How to capture it • How to store it • How to retrieve it

42. Related Work - Email • Primary work tool – 97% of workers • Not adapted for context, workflow, and negotiation • Example systems: MESSIE, Coordinator, COSMOS

43. Related Work - Design Rationale • The how and why of development • Helps in correctness and speed during maintenance, redesign, etc. • Example systems in SE: Comet, COMANCHE, PPIS • All approaches can be categorized based on: • Capture (automatic vs. manual) • Structure (argumentation-based vs. descriptive) • Retrieval (navigation and query, trigger methods)

44. Automatic DR • User-intervention approach is rejected: • Alters the process • Intrusive, bothersome • Specialized domain systems: • SAAMPad • RCF • Communication perspective: • Communication contains process information • Difficult to structure • Design History/Design Notebook style

45. Related Work Summary Lessons: • Least Interference • Email – easy to capture, difficult to retrieve efficiently • Need context Conclusion: • Use automatic capture • Augment existing tools • Structure by context information

46. Our Assumptions • Group software project • Some communication by email • Version control software

47. Context • Background knowledge, cues

48. Context (cont.) • Discourse exists in context • Context can be more or less general • Time matters • Context enables enhanced recall and precision of results in searching • Context-aware applications in mobile and wearable computing (EDC, Augmented Reality, Conference Assistant, Anchored Conversations)

49. Context Formalization • C = <P,T,E> at time t • P - project information on different levels of abstraction • Name and location • File name and version • Class • Function name • Line number • T – Task • E – Personal Environment

50. Context in Current Implementation Language specific • Language unspecific • Project name and location • Line number