1 of 9

Submitted to IEEE Design & Test of Computers (22 March 2000 4:59 pm)
Abstract: We propose a conceptual framework, called the Rugby Model, in which designs, design processes
and design tools can be studied. The model has similar objectives as the well known Y chart [1] but its scope
is extended to handle designs and design processes required for complex systems requiring concurrent proc-
esses and mixed HW/SW implementation. The Rugby model has four domains, namely, Computation, Com-
munication, Data and Time. The behavioural domain of the Y chart is replaced with more restricted
computation domain. The structural and physical domain of the Y chart are merged into a more generic
domain called Communication. The new domains Data and Time have become necessary to model data
abstractions used at various levels of design, and to explicitly model timing constraints at various levels in
the design process, respectively. We show that the Rugby model is able to represent mixed HW/SW designs
and design processes for HW/SW codesign at various levels of abstraction. It not only can represent state-of-
the-art of current electronic systems and electronic system design automation, but it also points to gaps in the
availability of tools and methodologies for designing complex system.
1: Introduction
A conceptual framework like the Y chart [1] helps designers, researchers, teachers, tool developers, and
foremost students, to conceptualise, categorise, and visualize issues in design automation. Since the introduc-
tion of Y chart in 1983, the complexity in terms of transistor count has increased more than two orders of
magnitude, which raises new design issues that are not naturally modelled on the Y chart. Today, the era of
system on a chip (SoC), with many concurrent and communicating activities on a single device, has emerged.
The consequence is that we need to revise the meaning of the old domains like behavioural, structural,
and physical. Also some new aspects like data, time and communication have become important when
dealing with complex systems. While Y chart sufces to describe the process of HW implementation of an
algorithm on a chip, a new model is required to deal with many communicating algorithms on a chip. A fur-
ther complication is a heterogeneous implementation technology, which includes embedded software, DSP
cores, micro processor cores, and custom hardware. For instance, HW/SW codesign requires segregation of
the design process at lower levels into separate HW and SW design ows, and integration at higher levels of
abstraction.
We must understand the three important concepts, namely, hierarchy, abstraction and domains before we
present our model.
Hierarchy: A hierarchy is a, possibly recursive, partitioning of a design model such, that the details of
each part is hidden into a lower hierarchical level.
Hierarchy denes the amount of information presented and visible at a particular hierarchical level of a
model. At all hierarchy levels the same modelling concepts are used. The motivation for hierarchy is to hide
information when it is not needed and to display details when they are useful.
Rugby: A Meta-Model to Study
Concepts in Electronic System Design
Axel Jantsch, Shashi Kumar, Ahmed Hemani
2 of 9
Submitted to IEEE Design & Test of Computers (22 March 2000 4:59 pm)
Abstraction: An abstraction level denes the modelling concepts and their semantics for representing a sys-
tem. The type of information available at different levels is different. A higher level ignores some irrelevant
information at a lower level and encodes it using different concepts.
Abstraction denes the type of information present in a model. Unlike hierarchy, abstraction is not concerned
with the amount of information visible, but with the semantic principles of a model. In general, the movement
from high to low abstraction levels includes a decision making process. By making design decisions and increas-
ing information about implementation details we replace more abstract models with less abstract models, until
the system is manufacturable.
Domain: A domain is an aspect of a model which can logically be analysed independently from other
aspects.
A domain focuses on one design aspect. Real models always contain several aspects or domains but different
models may emphasize one domain more than another. Models, which focus on one particular domain use mod-
elling notations and constructs to model the design aspect of concern explicitly. Other design aspects may be
implicitly part of the models. Whereas hierarchy and abstraction simplies the design, domain partitioning helps
the developers of tools and methodologies to cope with the complexity. The domains considered in this article
are computation, communication, data, and time.
While hierarchical partitioning is mostly a manual endeavour, the denition of abstraction levels and trans-
formations between them, is behind most of the advances in design automation. While hierarchy is a general and
important concept, it is not explicit in the Rugby model. We assume, hierarchy is possible at all abstraction lev-
els in any domain.
Rugby covers and relates models of all design phases from requirements to implementation. Consequently,
it also allows to study the HW/SW codesign process. For the sake of conciseness and brevity we restrict the dis-
cussion here mostly to issues at the core of design of digital hardware and software of embedded systems and
systems on a single chip. The model derives its name from the similarity of its visual representation (see gure
1) to the shape of a Rugby, with the domain lines forming the seams. The paper is organized as follows: The next
section presents other meta-models and discusses briey their limitations. Section 3 describes the Rugby model
with its four domains. Section 4 outlines the possible use by mapping design activities into the model and by
identifying research topics suggested by the model.
2: Existing Models
Previously proposed meta-models have several limitations which we try to overcome in Rugby. Earlier
models like the Y chart [1] did not pay attention to time, data, and communication aspects. Gradually, time and
data abstractions have been introduced [2], but not consistently to cover all levels of representations from
requirements to implementation. Communication has emerged as a hot research area, but meta-models have not
yet appreciated the fact, that topological and geometric structures are only low level manifestations of the more
general concept of communication.
The Y chart and the design cube do not separate design modelling issues from design process issues and can
only be fully understood in the context of concrete methodologies and tools. Essentially, the domains and
abstraction levels are chosen in a way to make them compatible with design languages, tools, and methodologies
under consideration. While this has the direct benet of providing a frame to categorize models, tools and meth-
odologies at the same time, we believe that much can be gained by cleanly separating these issues. Thus, the
Rugby model, as presented in this article, focuses solely on design modelling issues and selects the domains and
abstraction levels only based on inherent properties of the models. In a variant of Rugby [3] we have introduced
a fth domain addressing the design process and we argue, that the design process domain is orthogonal to the
design modelling domains and can also be viewed at several abstraction levels. However, for the sake of clarity
and brevity we restrict the discussion in this article to the four modelling domains.
3 of 9
Submitted to IEEE Design & Test of Computers (22 March 2000 4:59 pm)
VSIs Model Taxonomy [10] has been developed concurrently with and independently from Rugby. It has
similarities in the basic understanding of the important issues in electronic designs at system level. In particular,
it also recognises the importance of the Time and Data domains and assigns them independent axes. But its
objectives are focused on reuse of components and designs, whereas the Rugby model has the objectives to
derive a better understanding of electronic design concepts and processes. This is also revealed by the different
names used, e.g. precision level in the model taxonomy and abstraction level in Rugby. It is underscored by the
determined attempt in Rugby to use clearly different concepts for different abstraction levels, while in the model
taxonomy sometimes the same concepts with varying accuracy are used for several different levels, see for
instance the temporal precision.
3: The Rugby Model
Y chart is biased towards hardware implementation because its three domains, behavioural, structural and
physical, are inadequate to represent concepts such as inter-process communication, timing behaviour of sys-
tems, and various types of data abstractions and data encoding. To model different aspects of concurrent proc-
esses and mixed HW/SW systems and analyse their different problems, we choose Computation,
Communication, Time, and Data as the four domains in our model (see gure 1).
In order to represent different implementation technologies such as hardware and software, we allow
domain lines to be split. Hardware and software, when close to realization, use distinct concepts. For instance an
assembler program and a netlist of gates are very different. On the other hand, at higher levels hardware and soft-
ware developers use similar concepts such as communicating processes and abstract data types and can therefore
be treated uniformly. Thus, at higher levels from requirements denition to communicating processes there is
only one line in each domain representing the system level. This is independent from the later implementation
which can be hardware, software or a mixture of both. At lower levels the characteristics of the implementation
technology becomes dominant which requires separate domain lines as illustrated in gure 2.
3.1: Justication of Domains
The computation domain is derived from Y charts behavioural domain but is more restrictive and focuses
on the way the results are computed independent of the exact data types involved and from the exact timing
behaviour of the computation.
Idea
Physical
system
Computation
Communication
Time
D
ata
Development time line
High
abstraction
Low
abstraction
Figure 1. The Rugby model
4 of 9
Submitted to IEEE Design & Test of Computers (22 March 2000 4:59 pm)
For software there is a long tradition to model data types explicitly with modelling concepts such as entity-
relationship diagrams, and in the hardware community data structures have evolved from bit vectors to more
complex data structures like arrays, records, linked lists etc. This is reected in a urry of research activity in
this domain. Thus, for the modelling of mixed HW/SW systems it is desirable to treat data and data types as an
independent aspect.
Time is a crucial design characteristic which deserves independent analysis. Many electronic systems are
expected to be reactive real-time systems or have hard real time constraints. Furthermore, numerous publications
on how to model time illustrate that it is not bound to particular kinds of computation, but it is rather independ-
ent.
Complex systems are naturally modelled as communicating concurrent processes. Rening these abstract
communications to intra and inter component (ASICs, processor cores, memories etc.) communication primi-
tives is a major part of the design effort and is now being treated as a research problem [5]. Furthermore, lan-
guages and notations that were not main-stream in the hardware design community, are being explored to
specify communication dominated functionality [6, 7].
Figure 2 magnies part of the domain lines of the Rugby model and shows the abstraction levels from
abstract requirements denitions to a concrete mixed HW/SW implementation. It illustrates that domain lines
can split when design activities specialise. However, each split must have a corresponding joining of lines during
system integration, which is not shown in gure 2.
3.2: Computation
The computation domain is concerned with the relationship of input and output values, i.e. the behaviour as
it is observable from the outside. At the transistor level, models are based on differential equations representing
Computation
T
r
a
n
s
i
s
t
o
r
L
o
g
i
c

B
l
o
c
k
C
o
n
c
u
r
r
e
n
t

P
r
o
c
e
s
s
e
s
S
y
s
t
e
m

F
u
n
c
t
i
o
n
s
R
e
l
a
t
i
o
n
s

a
n
d
C
o
n
s
t
r
a
i
n
t
s
I
n
s
t
r
u
c
t
i
o
n

S
e
t
A
l
g
o
r
i
t
h
m
HW
SW
HW
SW
HW
SW
HW
SW
Communication
L
a
y
o
u
t
T
o
p
o
l
o
g
y
I
n
t
e
r

P
r
o
c
e
s
s
C
o
m
m
u
n
i
c
a
t
i
o
n
S
t
r
u
c
t
u
r
a
l

a
n
d
I
n
t
e
r
f
a
c
e

C
o
n
s
t
r
a
i
n
t
s
P
a
r
a
m
e
t
e
r
A
d
d
r
e
s
s
i
n
g
M
o
d
e
s
P
a
s
s
i
n
g
Data
N
u
m
b
e
r
L
o
g
i
c
A
n
a
l
o
g
S
y
m
b
o
l
D
a
t
a

T
y
p
e
C
o
n
s
t
r
a
i
n
t
s
P
r
o
c
e
s
s
o
r
D
a
t
a

T
y
p
e
s
V
a
l
u
e
V
a
l
u
e
(
b
i
t
,
b
y
t
e
,
w
o
r
d
)
Time
C
a
u
s
a
l
i
t
y
C
l
o
c
k
e
d
P
h
y
s
i
c
a
l
T
i
m
i
n
g

C
o
n
s
t
r
a
i
n
t
s
P
r
o
c
e
s
s
o
r
T
i
m
e
T
i
m
e
C
y
c
l
e

T
i
m
e
Idea
Physical
system
Development time line
High
abstraction
Low
abstraction
Figure 2. Abstraction levels in modelling domains
5 of 9
Submitted to IEEE Design & Test of Computers (22 March 2000 4:59 pm)
V-I characteristics. At the logic block level models are based on boolean functions.
The instruction set level is the lowest abstraction for software. Even though some computational concepts
like sequencing, branching and sub-routines are similar at the algorithmic level, it is considered less abstract
than the algorithmic level because the control elements are typically more primitive and it provides an abstrac-
tion layer around the details of the underlying processor architecture.
At the algorithmic level, models are based on control primitives such as sequence, parallel, if and
loop, and operators which manipulate data objects. Parallelism at this level is expressed in terms of concurrent
processes, where each process is typically described as an algorithm.
At the system function level the system is described from a purely external view without considerations of
the partitioning and the implementation of the system. The difference between the system functions and the
relation and constraints level is analogous to the difference between a function and a relation in mathematics.
3.3: Communication
The communication domain is concerned with the connections and interactions between design elements.
For hardware, the structural and physical domains of the Y chart are merged in this domain because movement
from a topological to a layout model is considered as a renement operation, not as an inter-domain movement.
The layout level is based on principles of geometry and uses physical units to describe geometric parameters.
This level corresponds to the physical domain in the Y chart. The topological level is only concerned with the
presence or absence of connections between design elements. It corresponds to the structural domain in the Y
chart.
In software there is no equivalent concept to the topology and layout levels of hardware but there exist two
other levels, which are denoted as parameter passing and addressing modes. Parameter passing is the com-
munication concept between functions and procedures in a sequential algorithm. Addressing modes is a concept
used in the denition of instruction sets. They describe the communication between the computational and the
storage parts of a processor.
The inter process communication level is concerned with mechanisms and protocols of communication
between design elements. The implementation of inter process communication channels and the physical struc-
ture of the design is irrelevant at this level.
At the highest level only the interface and communication constraints are expressed.
3.4: Data
The data domain is concerned with data types and data objects which are transformed by active design enti-
ties. The analog value level is based on real numbers and is used to quantify physical units like voltage, fre-
quency, etc. The logic value level is based on mathematical logic and is used to represent boolean and logic
expressions. The number and symbol levels are based on number theory and set theory, respectively. In software
the lowest abstraction level is based on data types of the target processor, which are typically bits, bytes, and
words of varying length.
3.5: Time
The time domain is concerned with the time relation between activities. The physical time level uses physi-
cal time units and is based on physical principles. Propagation delay, as it appears in simulation languages for
digital systems, is a simplication of the physical time and could be viewed as separate abstraction level. At the
clocked time level all activities are related to a clocking scheme and are based on concepts of digital time. While
there is no analogous concept to physical time in software, the processor cycle time corresponds to the clocked
time in hardware. At the causality level the total ordering of events is replaced by a partial ordering dened by
generation and consumption of data and by explicit control dependences. At the highest level the time is
expressed through performance constraints like data rate or frames per second.
6 of 9
Submitted to IEEE Design & Test of Computers (22 March 2000 4:59 pm)
In gure 2 we have emphasized that at high levels there is no distinction between hardware and software, as
a system can be implemented either way or as a mix of both. However, at lower levels the abstractions are differ-
ent and are therefore separated. At the same time, all software rests eventually on hardware. These two different
views are both valid and correspond to two active HW/SW codesign research areas: horizontal and vertical code-
sign. In the horizontal codesign one part of the system is implemented in software on a standard processor, and
the other part is implemented in custom hardware, e.g. an ASIC. In the vertical codesign the systems function-
ality is implemented entirely in software, but the underlying processor is also developed at the same time and
both, software and the hardware engine are designed and optimised at the same time.
Note that a model almost never uses elements from only one domain. In fact, most real models exhibit prop-
erties of all four domains, and can be characterized as a four tuple to indicate the abstraction level in the four
domains.
4: Representation of Design Models and Activities
To illustrate the Rugby model we give a few examples showing how existing modelling efforts and design
methods and tools t into the Rugby. More importantly, we point out some areas and issues which have not yet
been investigated thoroughly but which may be interesting areas of research according to Rugby.
4.1: Design Modelling
Many dedicated modelling efforts are characterized by a specic abstraction level in one of the four model-
ling domains. A few examples may illustrate the point.
The use of abstract symbols for data without relying on specic data values is an important feature of perform-
ance modelling in early system design phases.
The distinguishing element between register-transfer models and behavioural models in HW descriptions is
that the former assumes a clocked time and relates all activities to time slots, while the latter is placed on the
causality level of the time domain.
System level activities are conveniently described in terms of communicating processes and the inter-process
communication mechanism is often a distinguishing feature of a particular modelling approach, which is inde-
pendent of the computation concepts they use. For instance some modelling approaches and languages are
based on asynchronous, buffered communication (SDL, Erlang, CSP) while others are based on synchronous
communication (C++, Lustre, SIGNAL, Esterel).
Specic abstraction levels in the four domains are related to each other and are typically dealt within specic
design phases.
4.2: Design Transformations
In addition to conveniently representing traditional HW synthesis and SW compilation activities, the Rugby
model can also represent activities in the now established eld of HW/SW codesign as illustrated in gure 3.
HW/SW allocation and binding takes a description in terms of concurrent processes and generates a topology.
HW/SW partitioning creates a relation between a set of concurrent processes and a topology.
HW/SW binding renes this relation and creates a mapping between the processes and the topology such, that
each process is bound to only one topological element.
HW/SW Interface Synthesis renes the Communication domain from the Inter-process Communication
level to the Topology level.
4.3: Design Analysis and Estimation
Analysis, normally involves multiple domains. For example, a conventional logic simulation and timing
7 of 9
Submitted to IEEE Design & Test of Computers (22 March 2000 4:59 pm)
analysis tool requires models at the logic block level in the Computation domain, at the physical time level in the
Time domain, at the topology level in the Communication domain and at the logic value level in the Data domain
as illustrated in gure 4.
At the beginning of the design cycle, a feasibility analysis of the model could be carried out using Relations
and Constraints level in the Computation Domain, Timing Constraints in Time domain, Data Type Constraints in
Data domain and Structural and Interface constraints in the Communication domain. This analysis can be easily
represented in the Rugby model.
Tools for performance modelling and formal verication can also be represented in this framework. For
example, a tool checking deadlock in a system may involve a model at the concurrent processes level in the
Computation domain, at the causality level in Time domain, at the symbol level in the Data domain and at the
inter process communication level in the Communication domain.
4.4: Unexplored Problems and Issues
In addition to the representation of well formulated problems, the Rugby model brings out a number of
problems which have not been addressed adequately yet. Thus Rugby model not only helps in understanding the
current state-of-the-art in design and design automation, it also points to gaps and provides direction for future
research.
Data type renement: At lower levels of the Data domain the renement of data is handled by state encoding
and technology mapping techniques. But higher level models, which typically use abstract symbols for per-
formance modelling, based on queuing theory or petri nets, have usually no direct link to models with more
concrete data types to be used in the design and implementation process.
Computation
T
r
a
n
s
i
s
t
o
r
L
o
g
i
c

B
l
o
c
k
C
o
n
c
u
r
r
e
n
t

P
r
o
c
e
s
s
e
s
S
y
s
t
e
m

F
u
n
c
t
i
o
n
s
R
e
l
a
t
i
o
n
s

a
n
d
C
o
n
s
t
r
a
i
n
t
s
I
n
s
t
r
u
c
t
i
o
n

S
e
t
A
l
g
o
r
i
t
h
m
HW
SW
HW/SW Interface
Functional
Partitioning
HW/SW
Synthesis
Allocation
HW
SW
Communication
L
a
y
o
u
t
T
o
p
o
l
o
g
y
I
n
t
e
r

P
r
o
c
e
s
s
C
o
m
m
u
n
i
c
a
t
i
o
n
S
t
r
u
c
t
u
r
a
l

a
n
d
I
n
t
e
r
f
a
c
e

C
o
n
s
t
r
a
i
n
t
s
P
a
r
a
m
e
t
e
r
A
d
d
r
e
s
s
i
n
g
M
o
d
e
s
P
a
s
s
i
n
g
and Binding
Figure 3. HW/SW codesign tasks in the Rugby model
8 of 9
Submitted to IEEE Design & Test of Computers (22 March 2000 4:59 pm)
Transformation of system functions into concurrent objects indicated as functional partitioning in gure 3: In
early design phases a system is best described in terms of use cases [8], scenarios [9], and system functions.
These functions are independent from each other and represent the requirements. The challenge to transform
these system functions into interconnected concurrent objects is a key to link a problem oriented description to
an implementation oriented model [4]. It has not been systematically addressed.
The task of transforming requirements denitions into a system which fullls the requirements is notoriously
difcult. The Rugby model indicates that we need to address this problem in all four domains: computation,
time, data, and communication. Computational constraints in terms of input/output relations and timing con-
straints have to some extent been researched. But we have neither a formalism to express data type constraints
and structural and interface constraints, nor methods to integrate these constraints into the design process.
Computation
T
r
a
n
s
i
s
t
o
r
L
o
g
i
c

B
l
o
c
k
C
o
n
c
u
r
r
e
n
t

P
r
o
c
e
s
s
e
s
S
y
s
t
e
m

F
u
n
c
t
i
o
n
s
R
e
l
a
t
i
o
n
s

a
n
d
C
o
n
s
t
r
a
i
n
t
s
A
l
g
o
r
i
t
h
m
HW
HW
HW
HW
Communication
L
a
y
o
u
t
T
o
p
o
l
o
g
y
I
n
t
e
r

P
r
o
c
e
s
s
C
o
m
m
u
n
i
c
a
t
i
o
n
S
t
r
u
c
t
u
r
a
l

a
n
d
I
n
t
e
r
f
a
c
e

C
o
n
s
t
r
a
i
n
t
s
Data
N
u
m
b
e
r
L
o
g
i
c
A
n
a
l
o
g
S
y
m
b
o
l
D
a
t
a

T
y
p
e
C
o
n
s
t
r
a
i
n
t
s
V
a
l
u
e
V
a
l
u
e
Time
C
a
u
s
a
l
i
t
y
C
l
o
c
k
e
d
P
h
y
s
i
c
a
l
T
i
m
i
n
g

C
o
n
s
t
r
a
i
n
t
s
T
i
m
e
T
i
m
e
F
e
a
s
i
b
i
l
i
t
y
A
n
a
l
y
s
i
s
L
o
g
i
c

s
i
m
u
l
a
t
i
o
n
a
n
d

t
i
m
i
n
g

a
n
a
l
y
s
i
s
P
o
w
e
r
/
a
r
e
a
e
s
t
i
m
a
t
i
o
n

f
o
r
a
l
g
o
r
i
t
h
m
s
Figure 4. Design Analysis Tasks in the Rugby Model
9 of 9
Submitted to IEEE Design & Test of Computers (22 March 2000 4:59 pm)
5: Conclusions
Conceptual frameworks need to evolve with the increasing complexity of electronic systems to properly
model, represent and analyse designs and design processes. A unied framework for modelling of designs and
design processes of todays digital electronic systems has been presented. It covers models of electronic systems
from requirements specication to the implementation. Our treatment of Data and Time as independent domains
makes it distinctively more powerful for modelling mixed HW/SW systems and HW/SW codesign processes.
We also observe that at higher levels of abstraction, the modelling concepts are common for hardware and soft-
ware systems. By having an independent domain for design manipulation, we have shown how current tools for
design manipulation at different levels can be represented.
A good framework not only helps in studying and understanding the current state-of-the-art but also points
out gaps and areas for future work. Our framework highlights that there is a lack of appropriate representation of
models at the system level and of tools for the renement and analysis of models at the highest level of all four
domains. Design methodologies can use this framework to dene design documents and process steps which
correlate abstraction levels in different domains in a specic way. For instance a methodology could select one
domain leading the renement process, e.g. the abstraction levels in the data domain could dene process steps
and each renement of data would trigger a related renement in the other three domains.
We believe a good conceptual framework makes the analysis and communication more efcient and a stand-
ardization of such a framework including terminology, on the pattern of the 7 layer ISO OSI reference model,
would foster research and development and bring discipline in the electronic design automation area.
6: References
[1] Daniel D. Gajski and Robert H. Kuhn, Guest Editors Introduction: New VLSI Tools, IEEE Computer,
December 1983, pages 11-14.
[2] Wolfgang Ecker, Michael Hofmeister, and Sabine Mrz-Rssel, The Design Cube: A Model for VHDL
Design Flow Representation and its Application, in High Level System Modeling: Specication and Design
Methodologies, chapter 3, edited by Ronald Waxman and Jean-Michel Berge, Current Issues in Electronic
Modeling, vol. 4, Kluwer Academic Publishers, 1996.
[3] Axel Jantsch, Shashi Kumar, and Ahmed Hemani, The Rugby Model: A Framework for the Study of Mod-
elling, Analysis, and Synthesis Concepts in Electronic Systems, Proceedings of Design Automation and
Test in Europe (DATE), 1999.
[4] Axel Jantsch and Ingo Sander, On the Roles of Functions and Objects in System Specication, Proceed-
ings of the International Workshop on Hardware/Software Codesign, 2000.
[5] James A. Rowson and Alberto Sangiovanni-Vincentelli, Interface-Based Design, Proc. of the 34
th
Design
Automation Conference, 1997.
[6] A. Seawright, U. Holtmann, W. Meyer, B. Pangrle, R. Verbrugghe, and J. Buck, A System for Compiling
and Debugging Structured Data Processing Controllers, Proceedings of EuroDAC 96, Geneva, Switzer-
land, September 1996.
[7] Johnny berg, Anshul Kumar, and Ahmed Hemani, Grammar-based Hardware Synthesis of Data Commu-
nication Protocols, Proceedings of the 9th International Symposium on System Synthesis, pp. 14 - 19, 1996.
[8] Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar vergaard, Object Oriented Software Engi-
neering: A Use Case Driven Approach, Addison Wesley, Reading, Massachusetts, 1992.
[9] Colin Potts, Kenji Takahashi, and Annie I. Anton, Inquiry-Based Requirements Engineering, IEEE Soft-
ware, March 1994.
[10] VSI System Level Design Model Taxonomy, VSI Reference Document, version 1.0, [Link]
library/[Link], Virtual Socket Interface Alliance, October 1998.