Special Topics in Computer Science
Computational Modeling for
Snake-Based Robots
Design Rationale
Week 4
William Regli
Geometric and Intelligent Computing Laboratory
Department of Computer Science
Drexel University
http://gicl.cs.drexel.edu
1
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
2
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
3
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
4
designs for design similar artifacts
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
5
Major Approaches
• Process-oriented
represents a history of an artifact
• Feature-oriented
logical representation of an artifact
6
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
7
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
8
IBIS:
Issue-Based Information System
Issue
Responds
Position 1
Supports
Argument
Responds
Responds
Position 2
Supports
Argument
Position 3
Supports
Supports
Argument
Argument
Kunz & Rittel, 70
9
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
10
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
11
Issues for Design Rationale
System Architectures
•
•
•
•
•
CAD-based
Stand alone
CSCW-based
Document-based
Automatic vs Human Input
12
Capture of design rationale
It can occur in the design team’s communications via
Computer-Supported Collaborative Work (CSCW) tools
•Electronic mail
•Phone conversations
•Archived design meeting
•Designers notebooks
13
Goals for
Design 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
14
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)
15
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
16
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
17
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?
18
Open Issues: Retrieval
• Databases
– Multimedia, distributed, latency,
synchronization
• Navigation
– Filtering, hiding unneeded details,
generation of different views
• Higher-Level Indexing
– Case-Based Reasoning
19
Design
Repositories
Product
KnowledgeBase
Design
Rationale
Generic Design Rationale System
Architecture
Retrieval
Interactive
Design Rationale
Answer designers’
questions
Retrieve
by query
Navigate
Design Rationale
Formulate
Design document
Product
History
Design
Database
CAD
CAM
CAE
Analysis
Review similar
design cased
Design Reasoning
Evaluate Designs
Capture
Design
Case-base
Design Feedback
What should be
considered?
What have been
done?
Why designed this
way?
Is this against the
criteria and rules?
Representation
Schema
Capture from
Design Reasoning
Capture from
communication
CAD system
CAE system
CAM system
PDM system
Telecommunication
Collaborative Work
20
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
• Represent Design Context
• Structure captured information for future
retrieval and case-based indexing of
design process
21
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
22
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.
23
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
24
25
Studio Architecture
Client Tools
CAD System
(SDRC I-DEAS)
Open I-DEAS
(CORBA-based
communication layer)
Design Repository
Internet Client (Browser)
Retrieval Server
Email Client
Archival Server
Conferencing Client
(Whiteboard, Video, Audio,
Text)
Conferencing Server
Collaboration Archive
Message
Message
Message
x
y
z
Client Support Modules
Agents record design process collaboration in CVW MOO
and significant events in design space.
Email, chat, voice communications stored and
cross-referenced with design events and changes.
26
27
28
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
29
Message Model Contents
<!ELEMENT COMMUNICATION (CONTEXT, CONTENTS)>
<!ELEMENT CONTENTS (SUBJECT, TEXT, FILE,
ATTACHMENT*)>
<!ELEMENT SUBJECT (#PCDATA)>
<!ELEMENT TEXT (#PCDATA)>
<!ELEMENT FILE EMPTY>
<!ELEMENT ATTACHMENT EMPTY>
<!ATTLIST COMMUNICATION
type (email | voicemail | chat |
conference | whiteboard) #REQUIRED
medium (text | video | audio |
graphics) "text">
<!ATTLIST SUBJECT
type (change_request | inquiry |
inquiry_response | advisory |
solution | problem | other) #REQUIRED>
<!ATTLIST FILE
src CDATA #REQUIRED>
<!ATTLIST ATTACHMENT
src CDATA #REQUIRED>
• 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)
30
Message Model Contexts
<!ELEMENT CONTEXT (DATE, USERS, DESIGNDATA)>
<!ELEMENT DATE (#PCDATA)>
<!ELEMENT USERS (INITIATOR, PARTICIPANT+)>
<!ELEMENT INITIATOR (FIRSTNAME, LASTNAME,
EMAIL?)>
<!ELEMENT PARTICIPANT (FIRSTNAME, LASTNAME,
EMAIL?)>
<!ELEMENT FIRSTNAME (#PCDATA)>
<!ELEMENT LASTNAME (#PCDATA)>
<!ELEMENT EMAIL (#PCDATA)>
<!ELEMENT DESIGNDATA
(PROJECT,ASSEMBLY,PART*)>
<!ELEMENT PROJECT (#PCDATA)>
<!ELEMENT ASSEMBLY (#PCDATA)>
<!ELEMENT PART (ID, NAME, NUMBER, VERSION)>
<!ELEMENT ID (#PCDATA)>
<!ELEMENT NAME (#PCDATA)>
<!ELEMENT NUMBER (#PCDATA)>
<!ELEMENT VERSION (#PCDATA)>
• 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
31
Lessons Learned to Date
• Tight integration of CAD and CSCW
needed 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
32
Engineering Repositories: Digital
Libraries for Design and Manufacture
 s  M(θ)  θ  V(θ, θ )  G(θ)  F(θ, θ )
Engineering Digital Libraries contain CAD
models, assemblies, plans, revisions, S-B-F
models, project information and workflows, design rationale,
email, collaborative activity...
33
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
34
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
35
Overview
•
•
•
•
•
•
•
Motivation
Background research
Approach
Implementation
Demonstration (CodeLink)
Future work
Conclusion
36
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”
37
Scenarios
• Scenario 1: Communication
– Need to insert a reference to
code
• Scenario 2: History
– Need information about past
decisions, alternatives
considered, changes made
38
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
39
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
40
Issues
1.
2.
3.
4.
5.
What data to capture
How to represent it
How to capture it
How to store it
How to retrieve it
41
Related Work - Email
• Primary work tool – 97% of workers
• Not adapted for context, workflow, and
negotiation
• Example systems: MESSIE,
Coordinator, COSMOS
42
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)
43
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
44
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
45
Our Assumptions
• Group software project
• Some communication by email
• Version control software
46
Context
• Background knowledge, cues
Task:
- user actions
- specific task
at hand
Social:
- role in the group
- alliances and
oppositions
Personal:
- pulse
- gaze
Spatio-temporal:
- time
- location
47
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)
48
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
49
Context in Current
Implementation
Language specific
Field
C++
Function name return_type
name (args) {
Class name
class name {
C
return_type
name (args) {
Java
return_type
name (args)
[throws
exception] {
not applicable class name
[extends,
implements] {
Perl
sub name
[(args)] {
not applicable
Package name not applicable not applicable package name; package name;
Language unspecific
–Project name and location
–Line number
50
Architecture
User Interface Component
Source Code
Editor
Email Client
(VM)
DR Component
Navigation
Annotation/
Structuring
Context Extraction Module
(CodeLink)
Client Side
Server Side
Email Server
Access Control
Module
CVS Repository
Archival Module
WWW Access
Module
Communication Repository
(PostgreSQL)
51
CodeLink
•
•
•
•
•
•
Context Extractor – VM, Emacs, Elisp
MIME Handler – Perl
CVS Access Control - Perl
Message Archiver - Perl
Web Interface – cgi Perl
Message annotated code - Perl
52
53
Message Ontology
54
Context Extraction
Email Client VM
1. codelinkinsert-context
CodeLink
9. vm-attachdaml/code-link
7. version,
location
CVS Access
Control Module
8. encode-daml
2. codelinkextract-context
4. CVSPUT
3. context 5. checkin
Code Editor Emacs
6. version
CVS
55
Retrieval
• Web Interface
– Browse or search
– Add links
– Add notes
– Grouping
• Annotated code
– Mapping back to artifact
56
Limitations
•
•
•
•
Ratio of code-linked messages to all
Extensibility
Security
Privacy
57
Future Work
•
•
•
•
Visualization
Inference
User studies
Integration with other tools and media
58
Conclusions
• Improved communication ability
– Less time
– Less ambiguity
• Automatic DR capture
– Less user intervention
• Better structured data
• Usability:
– Builds on existing software
– Point-and-click
59
For More Information
http://edge.mcs.drexel.edu/GICL/people/
zaychik/thesis.htm
This work was supported in part by the
National Science Foundation Graduate
Research Fellowship
60
Acknowledgments
National Science Foundation
Knowledge & Distributed Intelligence (KDI)
Initiative Grant # CISE/IIS-9873005
“Networked Engineering”
Graduate Research Fellowship Program
SDRC
Bentley Systems
AT&T Labs, Internet Platforms Technology
61
Representation Schema
Issue-Based Information System (IBIS) is one of the
example
Issue
responds to
Position 1
Supports to
Argument 1
responds to
Position 2
Supports to
Argument 1
responds to
Position 3
Supports to
Argument 1
Supports to
Argument 1
62
Representation Schema
Procedural Hierarchy of Issues (PHI) is another example
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
…
63
References
•
•
•
•
•
•
HCI Issues in Collaborative and Networked Engineering Design. Regli and
Hewett, ACM Conference on Human-Computer Interaction, Workshop on HCI in
Application Domains, 1999.
Digital Library Support for Engineering Design and Manufacturing. Regli. ASME
Design Technical Conferences, Eleventh Computers in Engineering Conference,
1999
Issues in Building and Evaluating Networked Engineering Environments. Regli,
Zaychik, Hewett and Sevy. Proceedings of the Fourth IFIP WG 5.2 Workshop on
Knowledge Intensive CAD, 2000
Evaluating Collaborative Engineering Environments. Sevy, Zaychik, Hewett and
Regli. IEEE Eighth International Workshops on Enabling Technologies:
Infrastructure for Collaborative Enterprises, 2000.
Design Rationale: Representation, Retrieval and Reuse. Hu, J. Pang, Y. Pang,
Regli, Atwood, and Sun. ASME Design Technical Conferences, Fifth Design for
Manufacturing Conference, 2000.
Managing Digital Libraries for Computer-Aided Design, Regli, Cicirello. Journal
of Computer Aided Design, 2000. Special Issue on ``CAD After 2000''
64