Methodologies for Maintaining and Comparing Designs in a Cooperative Design Environment
Methodologies for Maintaining
and Comparing Designs in a
Cooperative Design
Environment
Kudang Boro Seminar
B.Sc. Agricultural Engineering, Bogor Agricultural University
M .Sc. Computer Science, University of New Brunswick
A DISSERTATION
SUBMITTED
IN PARTIAL
FULFILLMENT
OF
THE REQUIREMENTS
FOR THE DEGREEOF
Doctor of Philosophy in Computer Science
in the
Faculty of Computer Science
This dissertation is accepted.
Dean of Graduate Studies
G
THE UNIVERSITY OF NEW BRUNSWICK
OKudang Boro Seminar, 1993
Abstract
This thesis examinedl the problem of how to support several designers working on one or more projects so that they can pool their design ideas and produce
improved designs from wmparing and integrating various designs. The core
of the syetem is a design repitory based on the triangle madel, which stores
the designs and computes the differences hetween them. The designs are rep
resented as sets of features and a language (FBSM) is provided to describe
them. Meta-features can be defined so that designs can be viewed at different
levels of abstraction and formed into groups. A query language is provided
to help users search for designs with specific characteristics. Communication
tools are provided to allow users on individual workstations to communicate
with one another and share design ideas.
A prototype implementation called CoDEv (Cooperative Design Environment) has been built that demonstrates the utility of the techniques. A design
environment is a set of software, or computer-based tmls that aid the construction, maintenance, evaluation, modification, and reuM of designs. This
thesis has p r o p o d and developed formal methodologiw for daign maintenance and comparison, which are incorporated into CoDEv . This contribution
will enhance computer supported tools for cooperative design, and foster more
creative involvement of diverse experts towards large-scale, multidisciplinary
design activities.
Acknowledgements
This dissertation has been made possible by the significant, cooperative
contributions of the following:
a
Dr. Robert Rnbson, my supervisor, who has been remarkably patient,
cooperative, and constructive in all phases of the thesis work. His encouragement and stimulating guidance has allowed us to integrate our
separate ideas into a coherent thesis. Rob has given m e a high degree of
freedom in the exploration of my research, while keeping me cognizant
of my research direction, and more importantly, its completion. Many
things I have learned and gained from it.
Dr. Bruce Spencer and Dr. David Fellows, members of my committee,
w h o have provided constructive comments and suggestions both in the
logic and style of my writing. Bruce provided insight in several use-
ful discussions on the formality of t h e FBSM and logic-based formulas
presented in this thesis. David Fellows suggested additional, useful in-
formation in the implementation of the lend-and-borrow paradigm for
building our prototype design environment, and pinpointed many flaws
of my writing. Nevertheless, I take credit for any remaining flaws in t h e
writing.
r
Dr. Maureen Tingly, the chairperson of my examining board, who significant ly improved the mat hematical presentation in the thesis.
Dr. Carolyn Watters, my external examiner from the Department of
Mathematics, Statistics and Computer Science Dalhousie University, who
provided fruitful suggestions and comments on t h e overall presentation
of the thesis.
Kirby Ward, who has taught me many things about the ART-IM expert
system shell and programming language to implement the system prototype described herein. His time was rarely unavailable for me to ask
many fuzzy, boring questions.
a
Dr. Eldo Hildebrand and Dr. L. M. Waugh from Civil Engineering Department of UNB, who have provided me with useful information about
structural engineering processes that need the generation and cornparison of design alternatives.
Mrs. Taylor, my son's teacher in Montgomery Elementary School, who
has inspired me with the use of comparison for identifying Canadian
coins - quarters, dimes, nickels, and pennies - in a classroom session in
which I was invited to attend. Each pupil participating in the session was
stimulated to cmperatively enumerate and learn the distinctive features
of the coins.
The Government of Indonesia, that has generously granted major financial support and a valuable opportunity to pursue my graduate degrees
in Canada.
Faculty of Computer Science, University of New Brunswick, Canada,
that has kindly pravided partial financial support for my study.
Meitrisia, my beloved wife, who has kept my optimism high in many
difficult situations, and has patiently and cheerfully taken care and entertained our son and daughter, while I was engrossed with my work.
They are all always lovely, warm, and stimulating.
Bonang, my beloved son, who has helped me correct spelling errors in my
thesis. I must admit that, in some cases, his English is better than mine.
H e has also helped me enurrerate the common and distinctive features
of wild animals I used to illustrate my ideas in this thesis.
Annisa, my beloved daughter, who has given me plenty of times for
reading books while T was accompanying her to play ball in the play
ground of Regent Mall or Fredericton Mall, or to play at either Ode11
Park or LVilmott Park. These were the unforgettable occasions she Iet
me deal with my work without her disturbance.
My
parents who have provided me with continuous moral support that
will never end during their lifetime. Supardi, my father, who first taught
me various Boolean logic circuits. His enthusiasm and many other inter-
esting aspects of his teaching have stimulated m e to love and enjoy logic.
Sunarti, my beloved (late) mother, who had been waiting too long for
my study. Her sincere love and cares are impossible to repay.
Suman and Hanizur, my parents in law, who always encourage my wife
and me to be steadfast in pursuing knowledge, and discourage unnecessary, too early abandonment of any efforts.
W h a t is PHD?
At the start of my progrdrn, it was dark
Times after limes, dificulties after dificulties, I had
gone
through
No wonder, PHD has been popularly interpreted as
I Permanent Head Damaae 1
Despite these difticulties, I wanted not to stop &ere
I kept going with all that were supposed to go with m y struggle
Alas, the time came, I found ihat the interpretation was untrue
Rather, 1 envisioned PHD as a strategy for accomplishment; that was
I Patient
in Hunting o Degree ]
W i e n my sf.raf.egy worked out successfully
I felt
so proud of
bringing myseij unto climax
As an ordinary human being, I, at that moment, recalled
I Proud
of Holding
the Degree
PHD
as
I
Nevertheless, I wanted not to stay too long up high
It could be a source of various weaknesses
I
wanted to come down, and worked
pio~slgrwith the endowed degree
This motivated me to reJorrnulate the semantics of PHD as
1 Pious in Having the Degree I
I know it is uneasy to realize
Yet it should be exercised right jrom t h e start
I wish it uill be anofher contribution of my work
Thnl I sincerely invite and challenge all o j us
To more towards such
a
prestigious
Contemplation
So, verily, with every dificulty there is a relieve
Verily, with every dificulty there is a relieve
Thus, when you are free (relieved), still labour hard
And unto your LORD turn (all) your attention.
Contents
Abstract
1
Acknowledgements
I Introduction
....................
Thesis Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Design Comparison: Why is it Important? . . . . . . . . . . . .
A Design is Specified as a Set of Features . . . . . . . . . . . . .
Design Process . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diversities of Designs . . . . . . . . . . . . . . . . . . . . . . . .
Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
..................
8
...............
1.7.3 Object-Oriented Approach . . . . . . . . . . . . . . . . .
1.7.4 Distributed Computing Environments . . . . . . . . . . .
1.8 Thesis Contributions . . . . . . . . . . . . . . . . . . . . . . . .
1.9 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
1.1 Towards Cooperative Design
1
1.2
2
1.3
1.4
1.5
1.6
1.7
1.7.1
1.7.2
2
1
Set-Theoretic Approach
Logic Programming Approach
Related Work
3
7
7
8
10
11
12
13
15
...................
2.1
Existing Design Environments
2.2
. . . . . . . . . . . . . . . . . . . 16
Related Work on Differential-Based Analysis . . . . . . . . . . . 19
2.3.1 Design Space Analysis . . . . . . . . . . . . . . . . . . . 19
2.3.2 Viewpoint Resolution . . . . . . . . . . . . . . . . . . . . 19
2.3
Concurrent Engineering Tools
2.3.3
2.3.4
2.4
15
. . . . . . . . . . . . 20
Differential Qualitative Analysis and Exaggeration . . . . 20
Derivation by Andogical Approach
Software Reuse Systems
......................
3 A Methodology for Storing Designs
3.1 Theore tical Background . . . . . . . . . . . . . . . . . . . . . .
22
25
27
. . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.2 Lattice Theory . . . . . . . . . . . . . . . . . . . . . . .
28
3.1.2.1 Partial Order Relations . . . . . . . . . . . . . 28
3.1.1
Set
Theory
............
.......................
3.1.2.2
Upper and Lower Bounds
30
3.1.2.3
Lattice
31
. . . . . . . . . . . . . . . . . 31
3.1.3.1
Defined Functions . . . . . . . . . . . . . . . . 33
3.1.3.2 The Formal Notion of is-a Relationships . . . . 34
3.1.3.3 ClassConstructionbySetOperations . . . . . 36
3.2 Abstracting Design Objects . . . . . . . . . . . . . . . . . . . . 39
3.2.1 Feature-Based Specification Model (FBSM) . . . . . . . 39
3.2.2.1 AssociatingOhjectstoFeatures . . . . . . . . . 40
3.2.1.2 Feature Hierarchy, Meta Feature, and Norm . . 41
3.2.1.3 The Formal Description of FBSM . . . . . . . . 44
3.2.2 Organizing Objects with Lattice Networks . . . . . . . . 45
3.2.2.1 LatticeNetwork . . . . . . . . . . . . . . . . . 45
3.1.3 Object-Oriented Approach
3.2.2.2 The Reasoning Mechanism . . . . . . . . . . . .
3.2.2.3
ConstructingaLatticeNetwork .
........
3.2.2.4
The Importance of Knowing Object Creation
3.2.2.5
......................
Subsumption Network . . . . . . . . . . . . . .
History
3.2.3
A Predicate Logic Description of FBSM
3.2.3.1
.........
Mapping Primitive Features to Predicate Logic
...
3.2.3.3 Meta Features that Contain Negative Features .
3.2.3.4 Boolean Logics . . . . . . . . . . . . . . . . . .
3.2.3.5 Three-Valued Logic . . . . . . . . . . . . . . . .
3.2.3.2
Mapping Meta-Features t o Predicate Logic
3.2.3.6
The Logic Descriptions of Property /Value Pairs
...............
3.3 Descript.ion Identification . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Searching for Features . . . . . . . . . . . . . . . . . . .
3.3.1.1 hlultilevel Indexing . . . . . . . . . . . . . . . .
3.3.1.2 Feature Identification . . . . . . . . . . . . . .
3.3.1.3 Browsing Features with Objects . . . . . . . . .
3.3.2 Searching for Objects . . . . . . . . . . . . . . . . . . . .
3.3.2.1 Identification with Three-Valued Predicates . .
3.3.3.7
4
Sample Descriptions
Methodologies for Design Comparison
4.1
.............................
The Role of the FBSM . . . . . . . . . . . . . . . . . . .
Introduction
4.1.1
4.1.2 \Vila Will Perform the Comparison and Use its Results?
.............
hiodel (RM) . . . . . . . . . . . . . . . . .
4.2 The Two hIotlels for Object Comparison
4.2.1
The Relation
.....
4.2.1.1
Conceptual Graphs and Semantic Nets
4.2.1.2
Utilizing the Conceptual Graphs for a Compar-
80
4.2.1.4
. . . . . . . . . . . . . . . . . . . . 82
Language for theRelationModel . . . . . . . . 85
Cornpmite Relations . . . . . . . . . . . . . . . 88
4.2.1.5
Combining Relation Model Specifications . . . 89
4.2.1.6
..............
The Relation Model Graph . . . . . . . . . . .
Illustrative Examples . . . . . . . . . . . . . . .
ison Model
4.2.1.3
4.2.1.7
4.2.1.8
Inference Mechanisms
90
90
91
. . . . . . . . . . . . . . . . . . . 96
4.2.2.1 The Basic Properties of DM . . . . . . . . . . . 96
4.2.2.2 The Language for the Delta Model . . . . . . . 97
4.2.2.3
The DM Graph . . . . . . . . . . . . . . . . . . 98
4.2.2.4 Union and Intersection Operations . . . . . . . 100
4.2.2.5
Extending the Triangle Model . . . . . . . . . . 102
4.2.2.6 Comparing One Base Object with Others . . . 109
4.2.2 The DeltaModel (DM)
4.2.2.7
Integrating Object Variants with respect to the
. . . . . . . . . . . . . . . . . . . . . . . . 113
4.3 The Comparison of R M and DM . . . . . . . . . . . . . . . . . 114
4.4 Integrating RM and DM . . . . . . . . . . . . . . . . . . . . . . 120
Base
4.4.1
4.4.2 Sample Uses of the
5
. . . . . . . . . . . . . . . . . . 120
ICM . . . . . . . . . . . . . . . . . . 121
Specificat ion Integration
Implementation Issues
125
5.1 The Design Maintenance System Architecture . . . . . . . . . . 126
5.1.1
The ART-IM Expert System Shell . . . . . . . . . . . . . 127
5.1.1.1
The ART-IM Database . . . . . . . . . . . . . . 128
Supports for Different Programming Method-
5.1.1.2
. . . . . . . . . . . . . . . . . . . . . . . 128
Facts, Schemas. and Rules . . . . . . . . . . . . 129
ologies
5.1.1.3
5.1.3
. . . . . . . . . . . . . . . . 131
The Computing Environment . . . . . . . . . . . . . . . 134
5.1.4
The Use of the Front End Interface Module . . . . . . . 134
5.1.2
5.2
Lend-and-Borrow Paradigm
Tool Library
5.2.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . -138
How is Ccxrperation Accommodated?
5.2.1.1
. . . . . . . . . . .138
How are a Data Object and the Respective
Tool Lent? . . . . . . . . . . . . . . . . . . . .
5.2.1.2
Accommodating Different Views of a Shared
Abstraction
5.3
139
. . . . . . . . . . . . . . . . . . . . 143
AUTOMATON: A Prototype Multiuser Tool for Exploring Au-
.............................. A 3
5.3.1 Properties of Finite Automata . . . . . . . . . . . . . . . 144
5.3.2 Comparing Automata . . . . . . . . . . . . . . . . . . . 147
5.3.3 Functionality of AUTOMATON . . . . . . . . . . . . . . 151
5.4 Demonstration Scenarios . . . . . . . . . . . . . . . . . . . . . . 153
5.4.1 Sharing a Design Abstraction with Different Views . . . 153
tomata
. . . . . . . 155
5.4.2
Cmperating to Explore Alternative Designs
5.4.3
Integrating Designs - Modeling Intelligent Systems for
Patient Diagnosis and Treatment.
.............
5.4.4 The Use of the Voting Tool . . . . . . . . . . . . . . . .
5.5 Implementing the FBShl . . . . . . . . . . . . . . . . . . . . . .
5.5.1 Representingohjectsin FBSM . . . . . . . . . . . . . .
5.5.2 Representing hlctaFeatures . . . . . . . . . . . . . . . .
5.5.3 Searching Design Objects . . . . . . . . . . . . . . . . .
161
165
167
167
169
173
5.6 Implementing t h e Comparison Models
5.6.1
Representing
. . . . . . . . . . . . . . 178
RM . . . . . . . . . . . . . . . . . . . . . .
5.6.2 Forward Chaining versus Backward Chaining
178
. . . . . . . 184
5.6.3 Representing DM . . . . . . . . . . . . . . . . . . . . . . 187
5.6.4
5.7
The Icon for Comparing Objects . . . . . . . . . . . . . 187
A Configuration Management Twl to Support Cooperative Design 189
5.7.1
Design Versioning
. . . . . . . . . . . . . . . . . . . . . . 189
5.7.4
. . . . . . . . . . . . . 190
Minimal Configuration . . . . . . . . . . . . . . . . . . . 191
Branching Versions . . . . . . . . . . . . . . . . . . . . . 193
5.7.5
Operations
5.7.2 The Characteristics of CM Tools
5.7.3
5.7.6
6
. . . . . . . . . . . . . . . . . . . . . . . . . . 194
Cooperation Through Shared Work Areas . . . . . . . . 196
Conclusions and Future Work
200
. . . . . . . . . . . . . . . . . . . . . . . . . . . . -200
6.1.1 ITistorical Summary of Programming Environments . . . 200
6.1.2 Thesis Contributions . . . . . . . . . . . . . . . . . . . . 202
6.1.3 The Novel Features of FBSM . . . . . . . . . . . . . . . 203
6.1.4 Formal Methodology for Design Comparison . . . . . . . 205
6.1.5 Some Applications of DM . . . . . . . . . . . . . . . . . 206
6.1.6 Design Maintenance System . . . . . . . . . . . . . . . . 207
6.2 Futurework . . . . . . . . . . . . . . . . . . . . . . . . . . . . - 2 0 8
6.2.1 Extending the FBSM . . . . . . . . . . . . . . . . . . . . 208
6.2.1.1 Representational Adequacy . . . . . . . . . . . 209
6.2.1.2 Inferential Adequacy . . . . . . . . . . . . . . . 210
6.2.1.3 Relationships among Attributes . . . . . . . . . 211
6.2.1.4 User-Defined Granularity of Representation . . 212
6.1
Conclusions
6.2.2 Improving the Comparison Model . . . . . .
. . . . . . . 213
6.2.2.1
Extending the Relation Model (RM) . . . . . . 214
6.2.2.2
Using a Weighting Scheme to Guide Design
. . . . . . . . . . . . . . . . . . ,215
. . . . . . . . . . . . . . . . . . . . . 215
Comparisons
6.2.3
6.2.4
Tools Evaluation
6.2.3.1
Defining and Standardizing a Minimum Tool Set215
6.2,3.2
E~aluatingtheUtilit~ofOurTools
..
The Use of Multimedia Technology
. . . . -216
. . . . . . . . . . . . 217
A The Algebra of Sets
236
B The Implementation of the Lattice Construction Algorithm
238
C The Formal Construction and Comparison of Automata
240
(2.1 Unifying the Formal Theory of DFA with the Triangle Mode1
. . 241
C.2 The Strategy for Constructing DFA's with the Basic Triangle
Model . . . . . . . . . .
. .... . . . ... . . . . ... . ..
-242
. . . . . . . . . . . . . . . . . . . 244
Analysis of Time and Space Complexities . . . . . . . . . . . . . 246
The Implementation of the Algorithm. . . . . . . . . . . . . . . 248
How UsefuI is the Algorithm? . . . . . . . . . . . . . . . . . . . 250
C.3 Correctness of the Algorithm.
C.4
C.5
C.6
D The FBSM Grammar
252
D.1 Reading the BNF Notation . . . . . . . . . . . . . . . . . . . . . 252
D.2 The BNF Grammar for the FBSM Language . . . . . . . . . . . 253
Vita
260
3.13 Alternative trees depicting an exclusive OR relation.
. . . . . . 60
3.14 The FBSM system for storing frame design objects. . . . . . . . 67
4.1
The general comparison system that captures contexts of comparisons. context-dependent feature sets. and objects being cornpared .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.2 Meta features provide different contexts of object comparisons. . 77
4.3 The use of contexts for establishing design objectives . . . . . .
4.4 The larger conceptual graphs capturing various relations of furniture set components.
4.5
.
.......................
79
81
Classes of relations and their properties inheritable by the subclasses and instances .
........................
4.6 The basic relation model graphs . . . . . . . . . . . . . . . . . .
4.7 The use of RM graph for maintaining transformational history. .
4.8 The relation graph capturing the various network comparisons. .
4.9 The sample implementation of RM graphs. . . . . . . . . . . . .
4.10 The triangle model representing the triple D.[A,C,R]. . . . . . .
4.11 The union and intersection features in the triangle model.
4.12 The triangle model capturing n linear version objects.
84
91
91
93
95
98
. . . 101
. . . . . . 103
4.13 The complete configuration of the triangle model with n = 5. . . 104
4.14 Computing deltas .
. . . . . . . . . . . . . . . . . . . . . . . . . 106
4.15 The extension of union and intersection operations utilized in
the triangle model with any number of object versions . . . . . . 108
4.16 The triangle model showing the differing performance values of
external-wall designs .
. . . . . . . . . . . . . . . . . . . . . . . . 110
4.17 Differentiating base idea from others. . . . . . . . . . . . . . . . 111
4.18 Integrating versions with respect to base . . . . . . . . . . . . . . 115
4.19 Two alternative designs of distillation columns for separating
three components A. B. and C
.
These sample figures are ex-
tracted from Triantafyllou & Smith. 1992.
. . . . . . . . . . . .119
4.20 The ICM graph model representing [s..d] .
. . . . . . . . . 121
4.21 The ICM graph representing the three designs of external.walls . 121
. . . . . . . . . . . . . . . . . . .122
4.23 The lCM graph representing semi-rigid frames. . . . . . . . . . . 123
4.22 Three different frame structures
5.1 The main architecture of the design maintenance system.
. . . . 127
5.2 The intra- and inter-library communication architecture.
. . . . 132
5.3 Cooperating libraries provide data and their respective tools
toget her in one package which can be sent to any borrowers in
the network .
.............................
5.4 The main front end interface window . . . . . . . . . . . . . . . .
5.5 Multiuser talk windows . . . . . . . . . . . . . . . . . . . . . . .
5.6 Tools organization in CoDEv . . . . . . . . . . . . . . . . . . . .
5.7
133
135
137
140
The multiuser tool called AUTOMATON together with related
files (data objects) - STDl.art, STD2.art, and STD3.art - have
been lent to and used by a user .
. . . . . . . . . . . . . . . . . . 142
5.8 Three automata with their corresponding regular expressions.
5.9 The use of triangle model in the AUTOMATON system .
5.10 Observing different views of a shared abstraction.
5.1 1 Exploring two alternative designs concurrently.
. 150
. . . . 152
........
154
..........
157
5.12 Two users are comparing the regular expressions accepted/remgnized
by the automata STDl and STD2 respectively.
..........
158
5.13 The triangle model is used for comparing the behavior of two
automata .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
xvi
5.14 The automata capturing the functional behaviors of the intel-
ligent agents A (upper window) and B (lower window) that
perform patient diagnosis and treatment .
. . . . . . . . . . . . . 161
5.15 Two alternative schemes for integrating the functional behavior
of agents A and B .
. . . . . . . . . . . . . . . . . . . . . . . . . 162
5.16 The trees representing regular expressions ofautomata proposed
by Expert1 (left) and Expert2 (right).
. . . . . . . . . . . . . . . 164
5.17 The expanded regular expressions of automata AGENT- A- >B .
The highlighted sub-tree indicates the expanded portion . . . . . 164
5.18 Vote windows of a multiuser vote tool executed by all voters. . . 166
5.19 Voting tool window displaying theresult of voting .
. . . . . . . 166
5.20 The subsumption network of meta features described in representations ( I ) , (2). (3). (4). (6). and (7) .
. . . . . . . . . . . . . 172
5.21 Searching objects using a template-based query. . . . . . . . . . 174
5.22 The user-defined query for searching design objects. . . . . . . . 175
5.23 The query graph permits a user to interactively manipulate and
interconnect queries .
. . . . . . . . . . . . . . . . . . . . . . . . 176
5.24 The initial datamaintained by our query system prototype . The
data was produced by the system in the output log . . . . . . . . 180
5.25 A sample session of finding relation difference between objects. . 181
5.26 The relation model graph reflecting the difference among design
objects .
5.27
5.28
5.29
5.30
5.31
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
A sample interaction between backward and forward rules. . . . 186
The basic icon for ICM . . . . . . . . . . . . . . . . . . . . . . . 188
The features of objects STDl and STD2 are being compared . . . 188
Configurations t.hat save one version node plus deltas. . . . . . . 194
The nodes saved in branching versions . . . . . . . . . . . . . . . 195
5.32 Concurrent manipulation of a shared object .
6.1
The AND tree capturing relation hierarchy.
C.1 The algorithm for computing M = M l A M 2.
. . . . . . . . . . . 198
. . . . . . . . . . . . 215
. . . . . . . . . . . 243
C.2 Transition functions for MI (a), and M2 (b) . . . . . . . . . . . . 246
C.3 The data structures for the input automata Ml and Mz (a) ,
and the output automata M = MIAM2 (b). . . . . . . . . . . . 247
List of Tables
3.1
Other relations inferred from facts (1) to ( 5 ) and the reflexivity
and transitivity properties.
.....................
3.2 Binary set operations and the resulting is-a relationships.
....
29
38
3.3 Tabular categorization of animals based on the hierarchically
structured features.
. . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4 The truth table of three-valued predicates . . . . . . . . . . . . . 64
4.1
The properties of composite relations in the relation model . . . . 89
4.2 Performance features of external-wall designs (Mattar et al, 1975).10s
5.1 The implementation of tools in CoDEv .
5.2
All possible minimal
. . . . . . . . . . . . . . 141
configurations for 3 linear versions . . . . . . 193
6.1 Sample applications of multimedia technology.
. . . . . . . . . . 217
A . l Various set operations (Abbott. 1969). . . . . . . . . . . . . . . 237
C .1 The experimental cpu-time summary. . . . . . . . . . . . . . . -249
Chapter 1
Introduction
1.1
Towards Cooperative Design
A design (or design a r t i f a d ) is a description of the components of a system being created and the way they are joined together to form the system.
This description serves as an information base capturing the structure of the
components i n the system, their relationships, and their functionalities, which
altogether constitute design features. Such a definition covers a broad range of
fields, including architectural (buiidi ng) design, urban design, software design,
hardware design, and various types of engineering design.
Designs are often produced by the corporate efforts of experienced, trained,
and qualified individuals. Such groups or consortia are referred to as design
teams. This observation is based on the fact that current design research has
led to design methods and environments that incorporate distributed exper-
tise [106,25, 60, 291. A design environment is defined as a set of software,
or computer-based tools that aid the construction, maintenance, evaluation,
modification, and reuse of design artifacts.
One of the hallmarks
of incorpo-
rating distributed expertise i s the generation of a variety of possible design
alternatives (called a design space [76]) which are unlikely to result from the
mind of a single person. These daign alternatives can then be compared and
evaluated to select and poduce the best design possible. Therefore, a design
environment can be expedited by adding tools which permit team designers
to easily compare and assimilate a variety of designs, and store and classify
them so that they can become a body of common knowledge, available to all
members of the design team.
Many researchers [148, 76, 70, 34, 111, 7, 601 have reported that conventional design maintenance suffers from the absence of design information which
is crucial in aiding the designers or maintainers to make changes, to evaluate,
to reuse, and to reason about designs. Such information includes distinctive
and common features among design a1ternatives, relations across designs, and
a design history. As an example, a design Y with features ( a , b, c, d } is an extension of a design X with features { a , b ) ; Y was derived from X by applying a
transformation T on X such that new features c and d are obtained. It would
be useful to document that the existence of new features c and d makes design
Y become more portable and less erroneous than design X. This information
can be represented as
[ X , T,YJ ==+ [y,A : ( c , d ) , x]
[ Y ,A: { c , d ) , X']
[Y,(A more-portable less-erroneous), XI.
*
Surprisingly, such intuitive, useful information is often unavailable in the design
process.
1.2
Thesis Goal
The main goal of this thesis is the formulation of methodologies for maintaining and comparing designs contributed by design teams in a cooperative
design environment. It is envisioned that a design environment can and should
accommodate a basic mechanism for cooperative design exploration, construction, maintenance, and reuse. Although the domain of interest of the thesis is
cooperative design in software development, a variety of examples of cooperative design in other domains of interest, such as engineering design, is provided
to show the flexibility and generality of the methodologie described in this
thesis. The methodologies are built upon a model which provides a natural,
yet formal way of maintaining and comparing various designs. It also allows
categorizing and maintaining designs based on their common and differing features. This will permit the design teams to incorporate the ideas and expertise
of many different designers as well as members of the user community, who
hold vested interest in the design.
1.3
Design Comparison: Why is it Important?
There are many important reasons for comparing two alternative designs; situations where this is desirable are:
If the two designs use different strategies but have almost equally good
performance, the similarities and differences of their approaches are worth
identifying and exploring. Such a case is exemplified by the comparison
of two designs of distributed systems - Amoeba and Sprite [28].
If the performance of the two designs significantly differs, the differences
in their design methods are worth examining l o figure out the cause of
differing performance, as illustrated in [.31].
The similarities and differences between the two can be exploited to aid
future improvements, such as exemplified in [126].
To investigate the best possible integration of the two designs. This may
result in a hybrid method such aa exemplified in (281, and also includes
design reuse, such as exemplified in [3].
To categorize the two designs based on wme relevant characteristics such
as functionali ties, capabilities, uses, and support requirements. The AI-
Based Reuse System (AIRS) [94], for instance, classifies different software tools based on their similar functionali ties. page-Jones [95] outlines
the comparison between the structured approach and object-oriented ap-
proach to software design based on their uses and support requirements.
1.4
A Design is Specified as a Set of Features
In this thesis, features are viewed as the relevant properties or characteristics being considered about an object or a group of objects. The definition
of features includes object attributes, behavior, capabilities, functions, and
relations. A design is viewed as an artifact which is described by a set of
features.
Features allow the measurement of the similarity and dissimilarity among
designs, and thus provide criteria for design comparison and classification. An
important way to comprehend a design artifact is to compare it to how it
might otherwise be [76]. When a new design alternative is proposed, it needs
to be compared with existing designs to reveal differing and common features
between the alternatives [148].
Features are used by humans or intelligent systems to recognize, identify,
classify, and explore objects [140, 146,65, 123,121, 77,94, 58, 601. It would be
desirable if some of these features could be compared, retracted, replaced, or
integrated with other features to produce a new design, or to refine a n existing
design. If this mechanism can be exploited, a new design can be specified by
locating dissimilarities and similarities among pieces, combining pieces, and
thus encouraging the use of a large library of standard pieces and a modu-
lar approach to design construction. Also, objects can be classified based on
their similarities and differences, aiding the search for objects in the library.
The CBR (Case-Based Reasoning) systems [134, 75, 31, for instance, require
comparisons of cases or object descriptions to accomplish their reasoning ca-
pahilities.
Figure 1.1 exemplifies three alternative designs of external walls of single-
family dwellings in Montreal [BO]. T h e feature sets associated with t h e three
designs are listed in tabular form. The features listed from rows 1 to 7 correspond to the component materials. Rows 8 to 12 list the features corresponding
to performance parameters of the three designs. The values of these parameters
are predicted based on the number of design guides and exhaustive checklists
available in published sources or handbooks. Notice that the performance of
wall-section2 and wall-section1 differs on the thermal resistance (TR). The
fact that only the thickness of component c4 of the two walls differs provides
an explanation as to why they have different thermal resistance performance.
By locating such differences and similarities, a new design alternative can be
generated by either replacing some component materials or varying the size of
components, such as thickness, of previous designs. For instance, wall-section3
can be obtained from wall-section2 by replacing component c l with steel light
zinc coated flat siding.
(a) waLsecW
(a) d-s&cfionl
cl
1 wall-section1
I Wood Bevel Siding
c2
I
1 (314" x 8" Cedar)
c3
c4
c5
c6
c7
1 w d - s e c t ion2
I Wood Bevel Siding
1
I
(3/4" x 8" Cedar)
Building Paper
] Building Paper
(15#Felt)
(15#~elt)
Wood Sheathing ( 3 / 4 " ) I Wood Sheathing (3/4")
Batt Insulation (2")
Batt Insulation (3")
Wood Stud at 16" O.C.
Wood Stud at 16" O.C.
(Zn 1 4 " )
(2" x 4"))
Polyethylene Vapour
Polyethylene Vapour
Barrier (4 mil.)
Barrier (4 mil.)
Gypsum Board (112") Gypsum Board (112")
I
FR 0.83
TR 2.10
0.83
CR
ST
IC
None
43.0
2.66
-
None
FR: Fire Resistance ( h )
CR: Condensation Risk
I wail-section3
I Steel light zinc coated flat
I siding (22 Gauge)
Building Paper
I (15#~elt)
1 Wood Sheathing (314")
1 Batt Insulation (3")
Wood Stud at 16"
O.C.
(2" x 4")
Polyethylene Vapour
Barrier (4 mil.)
Gypsum Board (1/2")
0.83
2.53
2.61
43.0
2.62
(a) rPall-section3
None
42.0
3.18
TR:Thermal Resistance (O C / W / m 2 )
ST:Sound Transmission ( d B )
IC: Initial Cost ($/ft2)
Figure I. 1: Sample design alternatives of external walls of single-family
dwellings in Montreal (\fattar et al, 1978).
1.5
Design Process
As a process, design is viewed not only as problem solving but also as continual
problem finding [34, 1 141. The design p r m s involves exploring several alter-
natives [148], maintaining and comparing them, and possibly merging them un-
til the intended requirements are satisfied. The ability to perform differentialbased reasoning (DBR) [31, 1501 h e l p designers ~ombinethe features of past
designs in an intelligent fashion to derive new specifications [33, 85, 94, 71.
Knowing the differences and similarities between designs i s the key to proper
integration [71, 141, 132, 1551.
1.6
Diversities of Designs
Most engineering design problems do not have unique or absolute solutions. A
set of a1ternative solutions is usually developed to provide a room for comparative analysis and evaluation, rather than exposing a single design that results
from a single individual person's point of view. Differences in designs within
a design team can be worthwhile to locate, since they lead to a broader range
of ideas within a team and serve as a spark to intellectual interaction and
mutual understanding, enhancing the quality of designs [41,81, 37, 90, 301.
The proper articulation of different designs is likely to result in a better design. Based on empirical evidence, construction tools are necessary but not
sufficient conditions for useful design environments [29]. Design environments
need a tool that permits a designer to record the merits and deficiencies of
designs, and to maintain and compare design alternat,ives.
1.7 Approaches
To accomplish the thesis's goal, various related and complementary approaches
are studied and combined. These approaches comprise a theoretical basis for
the methodologies described in this thesis,
1.7.1
Set-Theoretic Approach
"The set allo~usihe
many to be seen as one."
(G-Cantor) [153],
The power of set theory stems from the fact that it helps humans formulate
general collections of features that apply to all object instances. Set theory
provides a natural, tractable set of tools to enhance humans' abilities to explore
and express various groups of objects. Figure 1.2 illustrates an example of
associating sets of wild animals with different sets of features, and vice versa.
The basic set-theoretic operations such as union (u), intersection
(n), dif-
ference (-), and symmetric diflerence (A) (see Appendix A) can be utilized
to locate distinct and common elements of any two sets, and construct a new
set from other sets. These operations have been proven useful for comparison
and reasoning [151, 31, 153, 9, 191. Referring to Figure 1.2, the set of common
features associated with Pant her and Lion is ( chases-pre y,good-wnner,good-
fighter, claws,strong-legs,shap.p-teeth);the set of features distinguishing Panther
from Lion is ( cliin bs-trees, black) ; the set of features distinguishing Lion from
Panther is ( b r o w n ) ; thus, the direring features of the two animals can be
captured as (climbs-trees, black] U { brown).
It is worth noting that set representations and operations have been studied
and utilized to cope with various data models [129, 153, 2, 113, 88,9, 4, 191.
The use of
for associating a class of animals to features and vice versa, clwifying
their similar features, and classifying features based on their nature and
context of observat,ion.
sets
animals based on
Figure 1.2: Associating objects to features and vice versa.
1.7.2
Logic Programming Approach
Predicate logic is an at tractive representation mechanism for knowledge in A1
(Artificial Intelligence) systems since formal techniques of logical inference can
easily be applied to such a representation. In the logic paradigm, a program is
a collection of formulae in predicate logic containing a theorem to be proved.
Its advantage is the separation between the program's logic and control so that
the logic can be checked independently of the run time behavior, enhancing
the reuse of control by many different programs. Logic programs are high-level
specifications that emphasize declarative meaning so that a person can think
of the correctness of a program apart from its operational behavior [78].
Pred-
icate logic is concerned with the extensional aspect of meaning 11451. As a
clarification, the extensional meaning of the predicate wild-animal(
) is that
subset of animals tha.t are wild. Factually, such an expression is empty and is
not a proposition; it becomes a proposition when its argument is filled by an instance that satisfies that predicate. Thus, a predicat.e wild-animal(sheerkhan)
asserts the fact that sheerkhan i s a wild animal. The extensional meaning of
predicate logic is the basis of inferencing procedures in logic programming, and
provides inheritance formalism in object-oriented programming.
1-73 Object-Oriented Approach
With predicate logics, t h e intensional meaning, which deals with the abstract concept of what constitutes a wild animal, is not presented. This differs from object-oriented programming [861,where a unary predicate, such as
wild-nnimnl(
) is expressed as a class named wild-animal, whose proper-
ties are explicitly listcd in the form of attribute/value pairs. Thus sheerkijan
becomes either an i n s h n c e , or a sub-class of the class mild-animal. The adran-
tages of both logic and object oriented paradigms are combined for specifying
and reasoning about objects. In this specification system, the assertion wildanimtal(sheerkhen) is tantamount to associating an object instance sheerkhan
to a feature wild-aninaal.
An object oriented representation offers an integrated view of abstract data
types and generic functions [86]. All propertie associated with an object
are encapsulated in a single representation.
operates primarily on the concept of classes.
Object oriented programming
The class notion serves a twofold
purpose 11131: (1) it represents a set of objects that share common properties,
(2) it provides a generic description for all objects belonging to that class.
One of the most important relationships between classes in the object oriented data models is an is-a relationship. This type of relationship provides
a crucial contribution to an inheritance mechanism between supercl;tsses and
subclasses. Intuitively, C1 is-a Czif all instances or members of the class Cl
are included in the class
Cz,and the descriptor for C1 is a sub-type of the de-
scriptor for Cz. For this reason, the data structures used to represent inclusion
relations are often called is-a hierarchies [135]. The novel feature of inheritance is that it promotes an open object architecture, that is, it facilitates
open-ended sets of extensions to a basic architecture [84].
1.7.4
Distributed Computing Environments
A design environment supporting cooperative tasks should be built on the
basis of a distributed computing base to alIow collaborating users to work
together, share information where necessary, and communicate with each other
via interconnected networks.
More importantly, such a distributed syst-em
must provide individuals with high level processing power and shared resources,
data objects and tools, and the maintenance of shared database. In this thesis,
the proposed distributed system was built on the basis of the lend-and-bomw
paradigm, where cooperating parties act a1ternately as lenders and borrowers.
Hence, each node in the system potentially serves as a library of data and
tools.
Thesis Contributions
The contributions provided by the thesis can be summarized as follows:
a
A formal methodology for maintaining designs.
A formal methodology for comparing designs.
a
The design of a design specification system, called FBS hf (Feature-Based
Specification Model).
A formal methodology for capturing differences and similarities among
designs, which is comprised of two basic models: ReIation Model
(RM)
and Delta Model (DM), and the integration the two, called the Integrated
Comparison Model (ICM).
The development of a tool for supporting cooperative design mnstruct ion, and exploration.
The development of a framework for concurrent engineering,
r The development of methodologies which can aid design reasoning, de-
sign selection and evaluation, design reuse, design integration and construction.
Thesis Outline
Chapter 2 contains some related work, whose novel ideas and approaches can
be studied to build the methodologies described herein. A t the same time,
their deficiencies and limitations are pinpointed to permit future improvement
and extension. The chapter starts with the existing design environments TO-
DOS [99) and JANUS [33], and the concurrent engineering environments and
tools, called Flecse [25], DRCS [60],and Designworld [49] respectively. These
pieces of work provide both motivation and insights for the need and develop-
ment of cooperative design environments. It proceeds to explore the related
work on differential-based analysis, which includes design space analysis [76],
viewpoint resolution [71], analogical derivation method [85], and differential
qualitative
(DQ)and exaggeration [150j. These pieces of
work provide a set
of lessons on why differential analysis is required to support reasoning rnechanisms and how it i s done. Finally, the existing reuse systems AIRS [94],
IRA [77], and the design maintenance system [7] are surveyed. These pieces
of work have inspired the development of the maintenance system described
in this thesis.
Chapter 3 formulates the methodology for storing design objects. The
methodology is built upon the formal specification system called Feature-Based
Specification Model (FBSM) which views design objects as entities associated
with a set of features. With the FBSM, objects can be related, compared,
and reasoned about based on their corresponding features. The detailed theoretical background for building FBSM is discussed. This includes the notion
of the is-a relationship, a lattice-based classification, the algorithm for build-
ing a lattice net,work, and the reasoning tools based on the lattice operations
and properties. Some techniques for searching both objects and features are
outlined. The FBSM provides a fundamental context for developing the comparison methodology described in Chapter 4.
Chapter 4 formulates the methodology for comparing objects and capturing their differences and similarities. The methodology is integrated with the
formal description of the FBSM, and is comprised of two complementary, integratable models: Relation Model
(RM)and
Delta Model (DM). The in-
tegration of the two results in a more comprehensive model called the
ICM
(Integrated Comparison Model). The textual and graphical languages of both
models are presented, and some important theorems are established, providing
rigorous semantics for the models.
Chapter 5 is concerned with the design architecture of a design environment
which has been built to support communication and cooperation among agents.
The lend-and-borrow paradigm is introduced to support the development of
such an environment. The implementation and sample uses of the FBSM and
the comparison models are presented. This includes a sample prototype for
cooperatively developing state transition diagrams or a11tomata.
The high level
features of the sample prototype are presented to demonstrate the applicability
of the methodologies.
Finally, Chapters 6 provides concluding remarks and some pointers for
future extension the thesis.
Chapter 2
Related Work
2.1
Existing Design Environments
Several design environments are already in existence. It is, therefore, worth-
while to compare the capabilities they support, the shortcomings they possess,
and novel feat lire5 they introduce.
TODOS 1991 is a design environment that supports the design of Ofice Information Systems (01s).A design performed using the TODOS environment
results in the functional specifications of the OIS, a prototype for evaluation,
and an architecture of hardware and software components that implement the
OIS. The resulting design specifications are stored in a Specification Database
(SDB) which provides a query language to browse, insert, delete, and validate
design specifications. TODOS supports all design phases including requirement collection and analysis, conceptual modeling, rapid prototyping, and
architecture selection. Some enhancements which are needed for TODOS are
the provision of design version management, and a comparison tool to support
maintenance, and evaluation of design alternatives. As pointed out before,
design history i s useful in design mamintenaxesystems but is frequently omit-
ted. This thesis at tempts to circumvent such a flaw by employing the triangle
model discussed in Section 4.2.2 to implement a design history.
JANUS [33] is
a
design environment that allows designers to construct
architectural floor plans of a kitchen and at the same time to learn about
the general guidelines for such wnstructions. JANUS contains two integrated
subsystems: J ANUS-CRACK , which is a knowledge-based system supporting
the construction of designs, and J ANUS-VIEWPOINTS, which is an issue-
based hypertext system that stores useful information about the principles of
design in the form of issues, answers, and arguments. The knowledge-based
system maintains criticisms, discriminates between good and bad designs, and
provides explanations for the discrimination. J ANUS-CRACK and JANUS-
VIEWPOINTS altogether allow argumentation to resolve problematic situations encountered during construction.
One limitation of JANUS is that
JANUS-VIEWPOINTS does not support the addition and deletion of new design rationale (issues, answers, and arguments) since its hyper text system does
not provide a tool for reconfiguring the data. Another limitation shared by
TODOS and JANUS is the lack of support for comparing, or perhaps integrating, design alternatives contributed by teams of designers.
2.2
Concurrent Engineering Tools
Concurrent engineering (CE) is a systematic approach to integrated product
development that emphasizes response to customer expectations and embodies
team values of coopera-tion,trust, and sharing [lo61 The computer support for
CE has been a.dvancing to enhance cooperative product development and to
overcome the barriers of distance, time, and heterogeneity in computer equipment. Such a technology has been manifested by collaborative environments
which enable any team member to collaborate with any other member or group
more effectivelj-
The Flexible Environment for Collaborative Software Engineering (Flecse)[25],
for instance, provides supports for concurrent program editing and debugging.
The supported tools include
the RCSTool, which allows users to efficiently access Revision Control
System (RCS) operations on various program versions such as check-in
and check-out and edit;
MShell, a multiuser command interpreter which allows multiple users
interleave their commands and share the responses to the commands;
a
MDebug, that allows multiple users to debug a program concurrently
but cooperatively;
Collaborative Software Inspector (CSI) that allows multiple users to
write comments (or annotations) an a particular program and to read
each other's annotations. The program inspection is aided by a hypertext
system which accommodates a fast navigation from a certain annotation
to the corresponding modules, programs, or fragment codes, and vice
versa.
and Comparing Designs in a
Cooperative Design
Environment
Kudang Boro Seminar
B.Sc. Agricultural Engineering, Bogor Agricultural University
M .Sc. Computer Science, University of New Brunswick
A DISSERTATION
SUBMITTED
IN PARTIAL
FULFILLMENT
OF
THE REQUIREMENTS
FOR THE DEGREEOF
Doctor of Philosophy in Computer Science
in the
Faculty of Computer Science
This dissertation is accepted.
Dean of Graduate Studies
G
THE UNIVERSITY OF NEW BRUNSWICK
OKudang Boro Seminar, 1993
Abstract
This thesis examinedl the problem of how to support several designers working on one or more projects so that they can pool their design ideas and produce
improved designs from wmparing and integrating various designs. The core
of the syetem is a design repitory based on the triangle madel, which stores
the designs and computes the differences hetween them. The designs are rep
resented as sets of features and a language (FBSM) is provided to describe
them. Meta-features can be defined so that designs can be viewed at different
levels of abstraction and formed into groups. A query language is provided
to help users search for designs with specific characteristics. Communication
tools are provided to allow users on individual workstations to communicate
with one another and share design ideas.
A prototype implementation called CoDEv (Cooperative Design Environment) has been built that demonstrates the utility of the techniques. A design
environment is a set of software, or computer-based tmls that aid the construction, maintenance, evaluation, modification, and reuM of designs. This
thesis has p r o p o d and developed formal methodologiw for daign maintenance and comparison, which are incorporated into CoDEv . This contribution
will enhance computer supported tools for cooperative design, and foster more
creative involvement of diverse experts towards large-scale, multidisciplinary
design activities.
Acknowledgements
This dissertation has been made possible by the significant, cooperative
contributions of the following:
a
Dr. Robert Rnbson, my supervisor, who has been remarkably patient,
cooperative, and constructive in all phases of the thesis work. His encouragement and stimulating guidance has allowed us to integrate our
separate ideas into a coherent thesis. Rob has given m e a high degree of
freedom in the exploration of my research, while keeping me cognizant
of my research direction, and more importantly, its completion. Many
things I have learned and gained from it.
Dr. Bruce Spencer and Dr. David Fellows, members of my committee,
w h o have provided constructive comments and suggestions both in the
logic and style of my writing. Bruce provided insight in several use-
ful discussions on the formality of t h e FBSM and logic-based formulas
presented in this thesis. David Fellows suggested additional, useful in-
formation in the implementation of the lend-and-borrow paradigm for
building our prototype design environment, and pinpointed many flaws
of my writing. Nevertheless, I take credit for any remaining flaws in t h e
writing.
r
Dr. Maureen Tingly, the chairperson of my examining board, who significant ly improved the mat hematical presentation in the thesis.
Dr. Carolyn Watters, my external examiner from the Department of
Mathematics, Statistics and Computer Science Dalhousie University, who
provided fruitful suggestions and comments on t h e overall presentation
of the thesis.
Kirby Ward, who has taught me many things about the ART-IM expert
system shell and programming language to implement the system prototype described herein. His time was rarely unavailable for me to ask
many fuzzy, boring questions.
a
Dr. Eldo Hildebrand and Dr. L. M. Waugh from Civil Engineering Department of UNB, who have provided me with useful information about
structural engineering processes that need the generation and cornparison of design alternatives.
Mrs. Taylor, my son's teacher in Montgomery Elementary School, who
has inspired me with the use of comparison for identifying Canadian
coins - quarters, dimes, nickels, and pennies - in a classroom session in
which I was invited to attend. Each pupil participating in the session was
stimulated to cmperatively enumerate and learn the distinctive features
of the coins.
The Government of Indonesia, that has generously granted major financial support and a valuable opportunity to pursue my graduate degrees
in Canada.
Faculty of Computer Science, University of New Brunswick, Canada,
that has kindly pravided partial financial support for my study.
Meitrisia, my beloved wife, who has kept my optimism high in many
difficult situations, and has patiently and cheerfully taken care and entertained our son and daughter, while I was engrossed with my work.
They are all always lovely, warm, and stimulating.
Bonang, my beloved son, who has helped me correct spelling errors in my
thesis. I must admit that, in some cases, his English is better than mine.
H e has also helped me enurrerate the common and distinctive features
of wild animals I used to illustrate my ideas in this thesis.
Annisa, my beloved daughter, who has given me plenty of times for
reading books while T was accompanying her to play ball in the play
ground of Regent Mall or Fredericton Mall, or to play at either Ode11
Park or LVilmott Park. These were the unforgettable occasions she Iet
me deal with my work without her disturbance.
My
parents who have provided me with continuous moral support that
will never end during their lifetime. Supardi, my father, who first taught
me various Boolean logic circuits. His enthusiasm and many other inter-
esting aspects of his teaching have stimulated m e to love and enjoy logic.
Sunarti, my beloved (late) mother, who had been waiting too long for
my study. Her sincere love and cares are impossible to repay.
Suman and Hanizur, my parents in law, who always encourage my wife
and me to be steadfast in pursuing knowledge, and discourage unnecessary, too early abandonment of any efforts.
W h a t is PHD?
At the start of my progrdrn, it was dark
Times after limes, dificulties after dificulties, I had
gone
through
No wonder, PHD has been popularly interpreted as
I Permanent Head Damaae 1
Despite these difticulties, I wanted not to stop &ere
I kept going with all that were supposed to go with m y struggle
Alas, the time came, I found ihat the interpretation was untrue
Rather, 1 envisioned PHD as a strategy for accomplishment; that was
I Patient
in Hunting o Degree ]
W i e n my sf.raf.egy worked out successfully
I felt
so proud of
bringing myseij unto climax
As an ordinary human being, I, at that moment, recalled
I Proud
of Holding
the Degree
PHD
as
I
Nevertheless, I wanted not to stay too long up high
It could be a source of various weaknesses
I
wanted to come down, and worked
pio~slgrwith the endowed degree
This motivated me to reJorrnulate the semantics of PHD as
1 Pious in Having the Degree I
I know it is uneasy to realize
Yet it should be exercised right jrom t h e start
I wish it uill be anofher contribution of my work
Thnl I sincerely invite and challenge all o j us
To more towards such
a
prestigious
Contemplation
So, verily, with every dificulty there is a relieve
Verily, with every dificulty there is a relieve
Thus, when you are free (relieved), still labour hard
And unto your LORD turn (all) your attention.
Contents
Abstract
1
Acknowledgements
I Introduction
....................
Thesis Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Design Comparison: Why is it Important? . . . . . . . . . . . .
A Design is Specified as a Set of Features . . . . . . . . . . . . .
Design Process . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diversities of Designs . . . . . . . . . . . . . . . . . . . . . . . .
Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
..................
8
...............
1.7.3 Object-Oriented Approach . . . . . . . . . . . . . . . . .
1.7.4 Distributed Computing Environments . . . . . . . . . . .
1.8 Thesis Contributions . . . . . . . . . . . . . . . . . . . . . . . .
1.9 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
1.1 Towards Cooperative Design
1
1.2
2
1.3
1.4
1.5
1.6
1.7
1.7.1
1.7.2
2
1
Set-Theoretic Approach
Logic Programming Approach
Related Work
3
7
7
8
10
11
12
13
15
...................
2.1
Existing Design Environments
2.2
. . . . . . . . . . . . . . . . . . . 16
Related Work on Differential-Based Analysis . . . . . . . . . . . 19
2.3.1 Design Space Analysis . . . . . . . . . . . . . . . . . . . 19
2.3.2 Viewpoint Resolution . . . . . . . . . . . . . . . . . . . . 19
2.3
Concurrent Engineering Tools
2.3.3
2.3.4
2.4
15
. . . . . . . . . . . . 20
Differential Qualitative Analysis and Exaggeration . . . . 20
Derivation by Andogical Approach
Software Reuse Systems
......................
3 A Methodology for Storing Designs
3.1 Theore tical Background . . . . . . . . . . . . . . . . . . . . . .
22
25
27
. . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.2 Lattice Theory . . . . . . . . . . . . . . . . . . . . . . .
28
3.1.2.1 Partial Order Relations . . . . . . . . . . . . . 28
3.1.1
Set
Theory
............
.......................
3.1.2.2
Upper and Lower Bounds
30
3.1.2.3
Lattice
31
. . . . . . . . . . . . . . . . . 31
3.1.3.1
Defined Functions . . . . . . . . . . . . . . . . 33
3.1.3.2 The Formal Notion of is-a Relationships . . . . 34
3.1.3.3 ClassConstructionbySetOperations . . . . . 36
3.2 Abstracting Design Objects . . . . . . . . . . . . . . . . . . . . 39
3.2.1 Feature-Based Specification Model (FBSM) . . . . . . . 39
3.2.2.1 AssociatingOhjectstoFeatures . . . . . . . . . 40
3.2.1.2 Feature Hierarchy, Meta Feature, and Norm . . 41
3.2.1.3 The Formal Description of FBSM . . . . . . . . 44
3.2.2 Organizing Objects with Lattice Networks . . . . . . . . 45
3.2.2.1 LatticeNetwork . . . . . . . . . . . . . . . . . 45
3.1.3 Object-Oriented Approach
3.2.2.2 The Reasoning Mechanism . . . . . . . . . . . .
3.2.2.3
ConstructingaLatticeNetwork .
........
3.2.2.4
The Importance of Knowing Object Creation
3.2.2.5
......................
Subsumption Network . . . . . . . . . . . . . .
History
3.2.3
A Predicate Logic Description of FBSM
3.2.3.1
.........
Mapping Primitive Features to Predicate Logic
...
3.2.3.3 Meta Features that Contain Negative Features .
3.2.3.4 Boolean Logics . . . . . . . . . . . . . . . . . .
3.2.3.5 Three-Valued Logic . . . . . . . . . . . . . . . .
3.2.3.2
Mapping Meta-Features t o Predicate Logic
3.2.3.6
The Logic Descriptions of Property /Value Pairs
...............
3.3 Descript.ion Identification . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Searching for Features . . . . . . . . . . . . . . . . . . .
3.3.1.1 hlultilevel Indexing . . . . . . . . . . . . . . . .
3.3.1.2 Feature Identification . . . . . . . . . . . . . .
3.3.1.3 Browsing Features with Objects . . . . . . . . .
3.3.2 Searching for Objects . . . . . . . . . . . . . . . . . . . .
3.3.2.1 Identification with Three-Valued Predicates . .
3.3.3.7
4
Sample Descriptions
Methodologies for Design Comparison
4.1
.............................
The Role of the FBSM . . . . . . . . . . . . . . . . . . .
Introduction
4.1.1
4.1.2 \Vila Will Perform the Comparison and Use its Results?
.............
hiodel (RM) . . . . . . . . . . . . . . . . .
4.2 The Two hIotlels for Object Comparison
4.2.1
The Relation
.....
4.2.1.1
Conceptual Graphs and Semantic Nets
4.2.1.2
Utilizing the Conceptual Graphs for a Compar-
80
4.2.1.4
. . . . . . . . . . . . . . . . . . . . 82
Language for theRelationModel . . . . . . . . 85
Cornpmite Relations . . . . . . . . . . . . . . . 88
4.2.1.5
Combining Relation Model Specifications . . . 89
4.2.1.6
..............
The Relation Model Graph . . . . . . . . . . .
Illustrative Examples . . . . . . . . . . . . . . .
ison Model
4.2.1.3
4.2.1.7
4.2.1.8
Inference Mechanisms
90
90
91
. . . . . . . . . . . . . . . . . . . 96
4.2.2.1 The Basic Properties of DM . . . . . . . . . . . 96
4.2.2.2 The Language for the Delta Model . . . . . . . 97
4.2.2.3
The DM Graph . . . . . . . . . . . . . . . . . . 98
4.2.2.4 Union and Intersection Operations . . . . . . . 100
4.2.2.5
Extending the Triangle Model . . . . . . . . . . 102
4.2.2.6 Comparing One Base Object with Others . . . 109
4.2.2 The DeltaModel (DM)
4.2.2.7
Integrating Object Variants with respect to the
. . . . . . . . . . . . . . . . . . . . . . . . 113
4.3 The Comparison of R M and DM . . . . . . . . . . . . . . . . . 114
4.4 Integrating RM and DM . . . . . . . . . . . . . . . . . . . . . . 120
Base
4.4.1
4.4.2 Sample Uses of the
5
. . . . . . . . . . . . . . . . . . 120
ICM . . . . . . . . . . . . . . . . . . 121
Specificat ion Integration
Implementation Issues
125
5.1 The Design Maintenance System Architecture . . . . . . . . . . 126
5.1.1
The ART-IM Expert System Shell . . . . . . . . . . . . . 127
5.1.1.1
The ART-IM Database . . . . . . . . . . . . . . 128
Supports for Different Programming Method-
5.1.1.2
. . . . . . . . . . . . . . . . . . . . . . . 128
Facts, Schemas. and Rules . . . . . . . . . . . . 129
ologies
5.1.1.3
5.1.3
. . . . . . . . . . . . . . . . 131
The Computing Environment . . . . . . . . . . . . . . . 134
5.1.4
The Use of the Front End Interface Module . . . . . . . 134
5.1.2
5.2
Lend-and-Borrow Paradigm
Tool Library
5.2.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . -138
How is Ccxrperation Accommodated?
5.2.1.1
. . . . . . . . . . .138
How are a Data Object and the Respective
Tool Lent? . . . . . . . . . . . . . . . . . . . .
5.2.1.2
Accommodating Different Views of a Shared
Abstraction
5.3
139
. . . . . . . . . . . . . . . . . . . . 143
AUTOMATON: A Prototype Multiuser Tool for Exploring Au-
.............................. A 3
5.3.1 Properties of Finite Automata . . . . . . . . . . . . . . . 144
5.3.2 Comparing Automata . . . . . . . . . . . . . . . . . . . 147
5.3.3 Functionality of AUTOMATON . . . . . . . . . . . . . . 151
5.4 Demonstration Scenarios . . . . . . . . . . . . . . . . . . . . . . 153
5.4.1 Sharing a Design Abstraction with Different Views . . . 153
tomata
. . . . . . . 155
5.4.2
Cmperating to Explore Alternative Designs
5.4.3
Integrating Designs - Modeling Intelligent Systems for
Patient Diagnosis and Treatment.
.............
5.4.4 The Use of the Voting Tool . . . . . . . . . . . . . . . .
5.5 Implementing the FBShl . . . . . . . . . . . . . . . . . . . . . .
5.5.1 Representingohjectsin FBSM . . . . . . . . . . . . . .
5.5.2 Representing hlctaFeatures . . . . . . . . . . . . . . . .
5.5.3 Searching Design Objects . . . . . . . . . . . . . . . . .
161
165
167
167
169
173
5.6 Implementing t h e Comparison Models
5.6.1
Representing
. . . . . . . . . . . . . . 178
RM . . . . . . . . . . . . . . . . . . . . . .
5.6.2 Forward Chaining versus Backward Chaining
178
. . . . . . . 184
5.6.3 Representing DM . . . . . . . . . . . . . . . . . . . . . . 187
5.6.4
5.7
The Icon for Comparing Objects . . . . . . . . . . . . . 187
A Configuration Management Twl to Support Cooperative Design 189
5.7.1
Design Versioning
. . . . . . . . . . . . . . . . . . . . . . 189
5.7.4
. . . . . . . . . . . . . 190
Minimal Configuration . . . . . . . . . . . . . . . . . . . 191
Branching Versions . . . . . . . . . . . . . . . . . . . . . 193
5.7.5
Operations
5.7.2 The Characteristics of CM Tools
5.7.3
5.7.6
6
. . . . . . . . . . . . . . . . . . . . . . . . . . 194
Cooperation Through Shared Work Areas . . . . . . . . 196
Conclusions and Future Work
200
. . . . . . . . . . . . . . . . . . . . . . . . . . . . -200
6.1.1 ITistorical Summary of Programming Environments . . . 200
6.1.2 Thesis Contributions . . . . . . . . . . . . . . . . . . . . 202
6.1.3 The Novel Features of FBSM . . . . . . . . . . . . . . . 203
6.1.4 Formal Methodology for Design Comparison . . . . . . . 205
6.1.5 Some Applications of DM . . . . . . . . . . . . . . . . . 206
6.1.6 Design Maintenance System . . . . . . . . . . . . . . . . 207
6.2 Futurework . . . . . . . . . . . . . . . . . . . . . . . . . . . . - 2 0 8
6.2.1 Extending the FBSM . . . . . . . . . . . . . . . . . . . . 208
6.2.1.1 Representational Adequacy . . . . . . . . . . . 209
6.2.1.2 Inferential Adequacy . . . . . . . . . . . . . . . 210
6.2.1.3 Relationships among Attributes . . . . . . . . . 211
6.2.1.4 User-Defined Granularity of Representation . . 212
6.1
Conclusions
6.2.2 Improving the Comparison Model . . . . . .
. . . . . . . 213
6.2.2.1
Extending the Relation Model (RM) . . . . . . 214
6.2.2.2
Using a Weighting Scheme to Guide Design
. . . . . . . . . . . . . . . . . . ,215
. . . . . . . . . . . . . . . . . . . . . 215
Comparisons
6.2.3
6.2.4
Tools Evaluation
6.2.3.1
Defining and Standardizing a Minimum Tool Set215
6.2,3.2
E~aluatingtheUtilit~ofOurTools
..
The Use of Multimedia Technology
. . . . -216
. . . . . . . . . . . . 217
A The Algebra of Sets
236
B The Implementation of the Lattice Construction Algorithm
238
C The Formal Construction and Comparison of Automata
240
(2.1 Unifying the Formal Theory of DFA with the Triangle Mode1
. . 241
C.2 The Strategy for Constructing DFA's with the Basic Triangle
Model . . . . . . . . . .
. .... . . . ... . . . . ... . ..
-242
. . . . . . . . . . . . . . . . . . . 244
Analysis of Time and Space Complexities . . . . . . . . . . . . . 246
The Implementation of the Algorithm. . . . . . . . . . . . . . . 248
How UsefuI is the Algorithm? . . . . . . . . . . . . . . . . . . . 250
C.3 Correctness of the Algorithm.
C.4
C.5
C.6
D The FBSM Grammar
252
D.1 Reading the BNF Notation . . . . . . . . . . . . . . . . . . . . . 252
D.2 The BNF Grammar for the FBSM Language . . . . . . . . . . . 253
Vita
260
3.13 Alternative trees depicting an exclusive OR relation.
. . . . . . 60
3.14 The FBSM system for storing frame design objects. . . . . . . . 67
4.1
The general comparison system that captures contexts of comparisons. context-dependent feature sets. and objects being cornpared .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.2 Meta features provide different contexts of object comparisons. . 77
4.3 The use of contexts for establishing design objectives . . . . . .
4.4 The larger conceptual graphs capturing various relations of furniture set components.
4.5
.
.......................
79
81
Classes of relations and their properties inheritable by the subclasses and instances .
........................
4.6 The basic relation model graphs . . . . . . . . . . . . . . . . . .
4.7 The use of RM graph for maintaining transformational history. .
4.8 The relation graph capturing the various network comparisons. .
4.9 The sample implementation of RM graphs. . . . . . . . . . . . .
4.10 The triangle model representing the triple D.[A,C,R]. . . . . . .
4.11 The union and intersection features in the triangle model.
4.12 The triangle model capturing n linear version objects.
84
91
91
93
95
98
. . . 101
. . . . . . 103
4.13 The complete configuration of the triangle model with n = 5. . . 104
4.14 Computing deltas .
. . . . . . . . . . . . . . . . . . . . . . . . . 106
4.15 The extension of union and intersection operations utilized in
the triangle model with any number of object versions . . . . . . 108
4.16 The triangle model showing the differing performance values of
external-wall designs .
. . . . . . . . . . . . . . . . . . . . . . . . 110
4.17 Differentiating base idea from others. . . . . . . . . . . . . . . . 111
4.18 Integrating versions with respect to base . . . . . . . . . . . . . . 115
4.19 Two alternative designs of distillation columns for separating
three components A. B. and C
.
These sample figures are ex-
tracted from Triantafyllou & Smith. 1992.
. . . . . . . . . . . .119
4.20 The ICM graph model representing [s..d] .
. . . . . . . . . 121
4.21 The ICM graph representing the three designs of external.walls . 121
. . . . . . . . . . . . . . . . . . .122
4.23 The lCM graph representing semi-rigid frames. . . . . . . . . . . 123
4.22 Three different frame structures
5.1 The main architecture of the design maintenance system.
. . . . 127
5.2 The intra- and inter-library communication architecture.
. . . . 132
5.3 Cooperating libraries provide data and their respective tools
toget her in one package which can be sent to any borrowers in
the network .
.............................
5.4 The main front end interface window . . . . . . . . . . . . . . . .
5.5 Multiuser talk windows . . . . . . . . . . . . . . . . . . . . . . .
5.6 Tools organization in CoDEv . . . . . . . . . . . . . . . . . . . .
5.7
133
135
137
140
The multiuser tool called AUTOMATON together with related
files (data objects) - STDl.art, STD2.art, and STD3.art - have
been lent to and used by a user .
. . . . . . . . . . . . . . . . . . 142
5.8 Three automata with their corresponding regular expressions.
5.9 The use of triangle model in the AUTOMATON system .
5.10 Observing different views of a shared abstraction.
5.1 1 Exploring two alternative designs concurrently.
. 150
. . . . 152
........
154
..........
157
5.12 Two users are comparing the regular expressions accepted/remgnized
by the automata STDl and STD2 respectively.
..........
158
5.13 The triangle model is used for comparing the behavior of two
automata .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
xvi
5.14 The automata capturing the functional behaviors of the intel-
ligent agents A (upper window) and B (lower window) that
perform patient diagnosis and treatment .
. . . . . . . . . . . . . 161
5.15 Two alternative schemes for integrating the functional behavior
of agents A and B .
. . . . . . . . . . . . . . . . . . . . . . . . . 162
5.16 The trees representing regular expressions ofautomata proposed
by Expert1 (left) and Expert2 (right).
. . . . . . . . . . . . . . . 164
5.17 The expanded regular expressions of automata AGENT- A- >B .
The highlighted sub-tree indicates the expanded portion . . . . . 164
5.18 Vote windows of a multiuser vote tool executed by all voters. . . 166
5.19 Voting tool window displaying theresult of voting .
. . . . . . . 166
5.20 The subsumption network of meta features described in representations ( I ) , (2). (3). (4). (6). and (7) .
. . . . . . . . . . . . . 172
5.21 Searching objects using a template-based query. . . . . . . . . . 174
5.22 The user-defined query for searching design objects. . . . . . . . 175
5.23 The query graph permits a user to interactively manipulate and
interconnect queries .
. . . . . . . . . . . . . . . . . . . . . . . . 176
5.24 The initial datamaintained by our query system prototype . The
data was produced by the system in the output log . . . . . . . . 180
5.25 A sample session of finding relation difference between objects. . 181
5.26 The relation model graph reflecting the difference among design
objects .
5.27
5.28
5.29
5.30
5.31
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
A sample interaction between backward and forward rules. . . . 186
The basic icon for ICM . . . . . . . . . . . . . . . . . . . . . . . 188
The features of objects STDl and STD2 are being compared . . . 188
Configurations t.hat save one version node plus deltas. . . . . . . 194
The nodes saved in branching versions . . . . . . . . . . . . . . . 195
5.32 Concurrent manipulation of a shared object .
6.1
The AND tree capturing relation hierarchy.
C.1 The algorithm for computing M = M l A M 2.
. . . . . . . . . . . 198
. . . . . . . . . . . . 215
. . . . . . . . . . . 243
C.2 Transition functions for MI (a), and M2 (b) . . . . . . . . . . . . 246
C.3 The data structures for the input automata Ml and Mz (a) ,
and the output automata M = MIAM2 (b). . . . . . . . . . . . 247
List of Tables
3.1
Other relations inferred from facts (1) to ( 5 ) and the reflexivity
and transitivity properties.
.....................
3.2 Binary set operations and the resulting is-a relationships.
....
29
38
3.3 Tabular categorization of animals based on the hierarchically
structured features.
. . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4 The truth table of three-valued predicates . . . . . . . . . . . . . 64
4.1
The properties of composite relations in the relation model . . . . 89
4.2 Performance features of external-wall designs (Mattar et al, 1975).10s
5.1 The implementation of tools in CoDEv .
5.2
All possible minimal
. . . . . . . . . . . . . . 141
configurations for 3 linear versions . . . . . . 193
6.1 Sample applications of multimedia technology.
. . . . . . . . . . 217
A . l Various set operations (Abbott. 1969). . . . . . . . . . . . . . . 237
C .1 The experimental cpu-time summary. . . . . . . . . . . . . . . -249
Chapter 1
Introduction
1.1
Towards Cooperative Design
A design (or design a r t i f a d ) is a description of the components of a system being created and the way they are joined together to form the system.
This description serves as an information base capturing the structure of the
components i n the system, their relationships, and their functionalities, which
altogether constitute design features. Such a definition covers a broad range of
fields, including architectural (buiidi ng) design, urban design, software design,
hardware design, and various types of engineering design.
Designs are often produced by the corporate efforts of experienced, trained,
and qualified individuals. Such groups or consortia are referred to as design
teams. This observation is based on the fact that current design research has
led to design methods and environments that incorporate distributed exper-
tise [106,25, 60, 291. A design environment is defined as a set of software,
or computer-based tools that aid the construction, maintenance, evaluation,
modification, and reuse of design artifacts.
One of the hallmarks
of incorpo-
rating distributed expertise i s the generation of a variety of possible design
alternatives (called a design space [76]) which are unlikely to result from the
mind of a single person. These daign alternatives can then be compared and
evaluated to select and poduce the best design possible. Therefore, a design
environment can be expedited by adding tools which permit team designers
to easily compare and assimilate a variety of designs, and store and classify
them so that they can become a body of common knowledge, available to all
members of the design team.
Many researchers [148, 76, 70, 34, 111, 7, 601 have reported that conventional design maintenance suffers from the absence of design information which
is crucial in aiding the designers or maintainers to make changes, to evaluate,
to reuse, and to reason about designs. Such information includes distinctive
and common features among design a1ternatives, relations across designs, and
a design history. As an example, a design Y with features ( a , b, c, d } is an extension of a design X with features { a , b ) ; Y was derived from X by applying a
transformation T on X such that new features c and d are obtained. It would
be useful to document that the existence of new features c and d makes design
Y become more portable and less erroneous than design X. This information
can be represented as
[ X , T,YJ ==+ [y,A : ( c , d ) , x]
[ Y ,A: { c , d ) , X']
[Y,(A more-portable less-erroneous), XI.
*
Surprisingly, such intuitive, useful information is often unavailable in the design
process.
1.2
Thesis Goal
The main goal of this thesis is the formulation of methodologies for maintaining and comparing designs contributed by design teams in a cooperative
design environment. It is envisioned that a design environment can and should
accommodate a basic mechanism for cooperative design exploration, construction, maintenance, and reuse. Although the domain of interest of the thesis is
cooperative design in software development, a variety of examples of cooperative design in other domains of interest, such as engineering design, is provided
to show the flexibility and generality of the methodologie described in this
thesis. The methodologies are built upon a model which provides a natural,
yet formal way of maintaining and comparing various designs. It also allows
categorizing and maintaining designs based on their common and differing features. This will permit the design teams to incorporate the ideas and expertise
of many different designers as well as members of the user community, who
hold vested interest in the design.
1.3
Design Comparison: Why is it Important?
There are many important reasons for comparing two alternative designs; situations where this is desirable are:
If the two designs use different strategies but have almost equally good
performance, the similarities and differences of their approaches are worth
identifying and exploring. Such a case is exemplified by the comparison
of two designs of distributed systems - Amoeba and Sprite [28].
If the performance of the two designs significantly differs, the differences
in their design methods are worth examining l o figure out the cause of
differing performance, as illustrated in [.31].
The similarities and differences between the two can be exploited to aid
future improvements, such as exemplified in [126].
To investigate the best possible integration of the two designs. This may
result in a hybrid method such aa exemplified in (281, and also includes
design reuse, such as exemplified in [3].
To categorize the two designs based on wme relevant characteristics such
as functionali ties, capabilities, uses, and support requirements. The AI-
Based Reuse System (AIRS) [94], for instance, classifies different software tools based on their similar functionali ties. page-Jones [95] outlines
the comparison between the structured approach and object-oriented ap-
proach to software design based on their uses and support requirements.
1.4
A Design is Specified as a Set of Features
In this thesis, features are viewed as the relevant properties or characteristics being considered about an object or a group of objects. The definition
of features includes object attributes, behavior, capabilities, functions, and
relations. A design is viewed as an artifact which is described by a set of
features.
Features allow the measurement of the similarity and dissimilarity among
designs, and thus provide criteria for design comparison and classification. An
important way to comprehend a design artifact is to compare it to how it
might otherwise be [76]. When a new design alternative is proposed, it needs
to be compared with existing designs to reveal differing and common features
between the alternatives [148].
Features are used by humans or intelligent systems to recognize, identify,
classify, and explore objects [140, 146,65, 123,121, 77,94, 58, 601. It would be
desirable if some of these features could be compared, retracted, replaced, or
integrated with other features to produce a new design, or to refine a n existing
design. If this mechanism can be exploited, a new design can be specified by
locating dissimilarities and similarities among pieces, combining pieces, and
thus encouraging the use of a large library of standard pieces and a modu-
lar approach to design construction. Also, objects can be classified based on
their similarities and differences, aiding the search for objects in the library.
The CBR (Case-Based Reasoning) systems [134, 75, 31, for instance, require
comparisons of cases or object descriptions to accomplish their reasoning ca-
pahilities.
Figure 1.1 exemplifies three alternative designs of external walls of single-
family dwellings in Montreal [BO]. T h e feature sets associated with t h e three
designs are listed in tabular form. The features listed from rows 1 to 7 correspond to the component materials. Rows 8 to 12 list the features corresponding
to performance parameters of the three designs. The values of these parameters
are predicted based on the number of design guides and exhaustive checklists
available in published sources or handbooks. Notice that the performance of
wall-section2 and wall-section1 differs on the thermal resistance (TR). The
fact that only the thickness of component c4 of the two walls differs provides
an explanation as to why they have different thermal resistance performance.
By locating such differences and similarities, a new design alternative can be
generated by either replacing some component materials or varying the size of
components, such as thickness, of previous designs. For instance, wall-section3
can be obtained from wall-section2 by replacing component c l with steel light
zinc coated flat siding.
(a) waLsecW
(a) d-s&cfionl
cl
1 wall-section1
I Wood Bevel Siding
c2
I
1 (314" x 8" Cedar)
c3
c4
c5
c6
c7
1 w d - s e c t ion2
I Wood Bevel Siding
1
I
(3/4" x 8" Cedar)
Building Paper
] Building Paper
(15#Felt)
(15#~elt)
Wood Sheathing ( 3 / 4 " ) I Wood Sheathing (3/4")
Batt Insulation (2")
Batt Insulation (3")
Wood Stud at 16" O.C.
Wood Stud at 16" O.C.
(Zn 1 4 " )
(2" x 4"))
Polyethylene Vapour
Polyethylene Vapour
Barrier (4 mil.)
Barrier (4 mil.)
Gypsum Board (112") Gypsum Board (112")
I
FR 0.83
TR 2.10
0.83
CR
ST
IC
None
43.0
2.66
-
None
FR: Fire Resistance ( h )
CR: Condensation Risk
I wail-section3
I Steel light zinc coated flat
I siding (22 Gauge)
Building Paper
I (15#~elt)
1 Wood Sheathing (314")
1 Batt Insulation (3")
Wood Stud at 16"
O.C.
(2" x 4")
Polyethylene Vapour
Barrier (4 mil.)
Gypsum Board (1/2")
0.83
2.53
2.61
43.0
2.62
(a) rPall-section3
None
42.0
3.18
TR:Thermal Resistance (O C / W / m 2 )
ST:Sound Transmission ( d B )
IC: Initial Cost ($/ft2)
Figure I. 1: Sample design alternatives of external walls of single-family
dwellings in Montreal (\fattar et al, 1978).
1.5
Design Process
As a process, design is viewed not only as problem solving but also as continual
problem finding [34, 1 141. The design p r m s involves exploring several alter-
natives [148], maintaining and comparing them, and possibly merging them un-
til the intended requirements are satisfied. The ability to perform differentialbased reasoning (DBR) [31, 1501 h e l p designers ~ombinethe features of past
designs in an intelligent fashion to derive new specifications [33, 85, 94, 71.
Knowing the differences and similarities between designs i s the key to proper
integration [71, 141, 132, 1551.
1.6
Diversities of Designs
Most engineering design problems do not have unique or absolute solutions. A
set of a1ternative solutions is usually developed to provide a room for comparative analysis and evaluation, rather than exposing a single design that results
from a single individual person's point of view. Differences in designs within
a design team can be worthwhile to locate, since they lead to a broader range
of ideas within a team and serve as a spark to intellectual interaction and
mutual understanding, enhancing the quality of designs [41,81, 37, 90, 301.
The proper articulation of different designs is likely to result in a better design. Based on empirical evidence, construction tools are necessary but not
sufficient conditions for useful design environments [29]. Design environments
need a tool that permits a designer to record the merits and deficiencies of
designs, and to maintain and compare design alternat,ives.
1.7 Approaches
To accomplish the thesis's goal, various related and complementary approaches
are studied and combined. These approaches comprise a theoretical basis for
the methodologies described in this thesis,
1.7.1
Set-Theoretic Approach
"The set allo~usihe
many to be seen as one."
(G-Cantor) [153],
The power of set theory stems from the fact that it helps humans formulate
general collections of features that apply to all object instances. Set theory
provides a natural, tractable set of tools to enhance humans' abilities to explore
and express various groups of objects. Figure 1.2 illustrates an example of
associating sets of wild animals with different sets of features, and vice versa.
The basic set-theoretic operations such as union (u), intersection
(n), dif-
ference (-), and symmetric diflerence (A) (see Appendix A) can be utilized
to locate distinct and common elements of any two sets, and construct a new
set from other sets. These operations have been proven useful for comparison
and reasoning [151, 31, 153, 9, 191. Referring to Figure 1.2, the set of common
features associated with Pant her and Lion is ( chases-pre y,good-wnner,good-
fighter, claws,strong-legs,shap.p-teeth);the set of features distinguishing Panther
from Lion is ( cliin bs-trees, black) ; the set of features distinguishing Lion from
Panther is ( b r o w n ) ; thus, the direring features of the two animals can be
captured as (climbs-trees, black] U { brown).
It is worth noting that set representations and operations have been studied
and utilized to cope with various data models [129, 153, 2, 113, 88,9, 4, 191.
The use of
for associating a class of animals to features and vice versa, clwifying
their similar features, and classifying features based on their nature and
context of observat,ion.
sets
animals based on
Figure 1.2: Associating objects to features and vice versa.
1.7.2
Logic Programming Approach
Predicate logic is an at tractive representation mechanism for knowledge in A1
(Artificial Intelligence) systems since formal techniques of logical inference can
easily be applied to such a representation. In the logic paradigm, a program is
a collection of formulae in predicate logic containing a theorem to be proved.
Its advantage is the separation between the program's logic and control so that
the logic can be checked independently of the run time behavior, enhancing
the reuse of control by many different programs. Logic programs are high-level
specifications that emphasize declarative meaning so that a person can think
of the correctness of a program apart from its operational behavior [78].
Pred-
icate logic is concerned with the extensional aspect of meaning 11451. As a
clarification, the extensional meaning of the predicate wild-animal(
) is that
subset of animals tha.t are wild. Factually, such an expression is empty and is
not a proposition; it becomes a proposition when its argument is filled by an instance that satisfies that predicate. Thus, a predicat.e wild-animal(sheerkhan)
asserts the fact that sheerkhan i s a wild animal. The extensional meaning of
predicate logic is the basis of inferencing procedures in logic programming, and
provides inheritance formalism in object-oriented programming.
1-73 Object-Oriented Approach
With predicate logics, t h e intensional meaning, which deals with the abstract concept of what constitutes a wild animal, is not presented. This differs from object-oriented programming [861,where a unary predicate, such as
wild-nnimnl(
) is expressed as a class named wild-animal, whose proper-
ties are explicitly listcd in the form of attribute/value pairs. Thus sheerkijan
becomes either an i n s h n c e , or a sub-class of the class mild-animal. The adran-
tages of both logic and object oriented paradigms are combined for specifying
and reasoning about objects. In this specification system, the assertion wildanimtal(sheerkhen) is tantamount to associating an object instance sheerkhan
to a feature wild-aninaal.
An object oriented representation offers an integrated view of abstract data
types and generic functions [86]. All propertie associated with an object
are encapsulated in a single representation.
operates primarily on the concept of classes.
Object oriented programming
The class notion serves a twofold
purpose 11131: (1) it represents a set of objects that share common properties,
(2) it provides a generic description for all objects belonging to that class.
One of the most important relationships between classes in the object oriented data models is an is-a relationship. This type of relationship provides
a crucial contribution to an inheritance mechanism between supercl;tsses and
subclasses. Intuitively, C1 is-a Czif all instances or members of the class Cl
are included in the class
Cz,and the descriptor for C1 is a sub-type of the de-
scriptor for Cz. For this reason, the data structures used to represent inclusion
relations are often called is-a hierarchies [135]. The novel feature of inheritance is that it promotes an open object architecture, that is, it facilitates
open-ended sets of extensions to a basic architecture [84].
1.7.4
Distributed Computing Environments
A design environment supporting cooperative tasks should be built on the
basis of a distributed computing base to alIow collaborating users to work
together, share information where necessary, and communicate with each other
via interconnected networks.
More importantly, such a distributed syst-em
must provide individuals with high level processing power and shared resources,
data objects and tools, and the maintenance of shared database. In this thesis,
the proposed distributed system was built on the basis of the lend-and-bomw
paradigm, where cooperating parties act a1ternately as lenders and borrowers.
Hence, each node in the system potentially serves as a library of data and
tools.
Thesis Contributions
The contributions provided by the thesis can be summarized as follows:
a
A formal methodology for maintaining designs.
A formal methodology for comparing designs.
a
The design of a design specification system, called FBS hf (Feature-Based
Specification Model).
A formal methodology for capturing differences and similarities among
designs, which is comprised of two basic models: ReIation Model
(RM)
and Delta Model (DM), and the integration the two, called the Integrated
Comparison Model (ICM).
The development of a tool for supporting cooperative design mnstruct ion, and exploration.
The development of a framework for concurrent engineering,
r The development of methodologies which can aid design reasoning, de-
sign selection and evaluation, design reuse, design integration and construction.
Thesis Outline
Chapter 2 contains some related work, whose novel ideas and approaches can
be studied to build the methodologies described herein. A t the same time,
their deficiencies and limitations are pinpointed to permit future improvement
and extension. The chapter starts with the existing design environments TO-
DOS [99) and JANUS [33], and the concurrent engineering environments and
tools, called Flecse [25], DRCS [60],and Designworld [49] respectively. These
pieces of work provide both motivation and insights for the need and develop-
ment of cooperative design environments. It proceeds to explore the related
work on differential-based analysis, which includes design space analysis [76],
viewpoint resolution [71], analogical derivation method [85], and differential
qualitative
(DQ)and exaggeration [150j. These pieces of
work provide a set
of lessons on why differential analysis is required to support reasoning rnechanisms and how it i s done. Finally, the existing reuse systems AIRS [94],
IRA [77], and the design maintenance system [7] are surveyed. These pieces
of work have inspired the development of the maintenance system described
in this thesis.
Chapter 3 formulates the methodology for storing design objects. The
methodology is built upon the formal specification system called Feature-Based
Specification Model (FBSM) which views design objects as entities associated
with a set of features. With the FBSM, objects can be related, compared,
and reasoned about based on their corresponding features. The detailed theoretical background for building FBSM is discussed. This includes the notion
of the is-a relationship, a lattice-based classification, the algorithm for build-
ing a lattice net,work, and the reasoning tools based on the lattice operations
and properties. Some techniques for searching both objects and features are
outlined. The FBSM provides a fundamental context for developing the comparison methodology described in Chapter 4.
Chapter 4 formulates the methodology for comparing objects and capturing their differences and similarities. The methodology is integrated with the
formal description of the FBSM, and is comprised of two complementary, integratable models: Relation Model
(RM)and
Delta Model (DM). The in-
tegration of the two results in a more comprehensive model called the
ICM
(Integrated Comparison Model). The textual and graphical languages of both
models are presented, and some important theorems are established, providing
rigorous semantics for the models.
Chapter 5 is concerned with the design architecture of a design environment
which has been built to support communication and cooperation among agents.
The lend-and-borrow paradigm is introduced to support the development of
such an environment. The implementation and sample uses of the FBSM and
the comparison models are presented. This includes a sample prototype for
cooperatively developing state transition diagrams or a11tomata.
The high level
features of the sample prototype are presented to demonstrate the applicability
of the methodologies.
Finally, Chapters 6 provides concluding remarks and some pointers for
future extension the thesis.
Chapter 2
Related Work
2.1
Existing Design Environments
Several design environments are already in existence. It is, therefore, worth-
while to compare the capabilities they support, the shortcomings they possess,
and novel feat lire5 they introduce.
TODOS 1991 is a design environment that supports the design of Ofice Information Systems (01s).A design performed using the TODOS environment
results in the functional specifications of the OIS, a prototype for evaluation,
and an architecture of hardware and software components that implement the
OIS. The resulting design specifications are stored in a Specification Database
(SDB) which provides a query language to browse, insert, delete, and validate
design specifications. TODOS supports all design phases including requirement collection and analysis, conceptual modeling, rapid prototyping, and
architecture selection. Some enhancements which are needed for TODOS are
the provision of design version management, and a comparison tool to support
maintenance, and evaluation of design alternatives. As pointed out before,
design history i s useful in design mamintenaxesystems but is frequently omit-
ted. This thesis at tempts to circumvent such a flaw by employing the triangle
model discussed in Section 4.2.2 to implement a design history.
JANUS [33] is
a
design environment that allows designers to construct
architectural floor plans of a kitchen and at the same time to learn about
the general guidelines for such wnstructions. JANUS contains two integrated
subsystems: J ANUS-CRACK , which is a knowledge-based system supporting
the construction of designs, and J ANUS-VIEWPOINTS, which is an issue-
based hypertext system that stores useful information about the principles of
design in the form of issues, answers, and arguments. The knowledge-based
system maintains criticisms, discriminates between good and bad designs, and
provides explanations for the discrimination. J ANUS-CRACK and JANUS-
VIEWPOINTS altogether allow argumentation to resolve problematic situations encountered during construction.
One limitation of JANUS is that
JANUS-VIEWPOINTS does not support the addition and deletion of new design rationale (issues, answers, and arguments) since its hyper text system does
not provide a tool for reconfiguring the data. Another limitation shared by
TODOS and JANUS is the lack of support for comparing, or perhaps integrating, design alternatives contributed by teams of designers.
2.2
Concurrent Engineering Tools
Concurrent engineering (CE) is a systematic approach to integrated product
development that emphasizes response to customer expectations and embodies
team values of coopera-tion,trust, and sharing [lo61 The computer support for
CE has been a.dvancing to enhance cooperative product development and to
overcome the barriers of distance, time, and heterogeneity in computer equipment. Such a technology has been manifested by collaborative environments
which enable any team member to collaborate with any other member or group
more effectivelj-
The Flexible Environment for Collaborative Software Engineering (Flecse)[25],
for instance, provides supports for concurrent program editing and debugging.
The supported tools include
the RCSTool, which allows users to efficiently access Revision Control
System (RCS) operations on various program versions such as check-in
and check-out and edit;
MShell, a multiuser command interpreter which allows multiple users
interleave their commands and share the responses to the commands;
a
MDebug, that allows multiple users to debug a program concurrently
but cooperatively;
Collaborative Software Inspector (CSI) that allows multiple users to
write comments (or annotations) an a particular program and to read
each other's annotations. The program inspection is aided by a hypertext
system which accommodates a fast navigation from a certain annotation
to the corresponding modules, programs, or fragment codes, and vice
versa.