Formal P.S.C.
Specification
Alencar
D.D.
*
of Reusable
Cowan
t
C.J.P.
Abstract In
this
paper
we
called
of
to
face
and
Our
a high
from
application
for
building
tion
blocks
for
structure
to that
1
and
ADV
formally
application
an
for
should
both
required
inter-
the
object,
ADV
and
support
the
describes
be seen
development the
application
include
of system
can
descriptive are
the
ba-
design,
approach.
static,
operation schemas
on
that
specification,
structural,
system
based
dynamic
the
specifica-
it should
underlying
significant
barrier
implementations
between
in-
cation
components.
*P. S. C. Alencar ence Department tario,
Canada
to
the
reuse
of software
and
is currently
of
on
both and
Professor
University
designs modules
and
from
face.
On-
the Departamento
Waterloo,
Ontario,
~C.J. P. Lucena is a Visiting Professor in the ence Department at the University of Waterloo, t ario,
Canada
and is currently
Department from
at University CNPq,
Email:
on leave from
of Waterloo
For example,
practice
in general.
to the data structure.
Input
should
not be aware of the mode of interaction.
the Depart
terface” service.
Canada,
Computer Waterloo,
and holds
lcmnova@neumann.
a doctoral uwaterloo.
or object approach
should
not be aware of the inter-
to defining
an interface
implies
a
joins
two components
one of which
supplies
a
View [6] approach uses an objectThe Abstract Data oriented formal design model which supports separation of concerns and reuse of design specifications. The basic constructs of the ADV approach are the Abstract Data View (ADV) and the Abstract Data Object (ADO),
SciOn-
amento
This
clear separation of concerns. Such a problem is often addressed in mechanical systems where a linkage “in-
de
Inform& tica, Pontiffcia Universidade Cat61ica do Rio de Janeiro, Brazil. Email:
[email protected] $LC.M, Nova is a F’hll candidate in the computer Science lowship
not be attached
the module
Sci-
Waterloo,
de Ci6ncia da Computa@o, Universidade de Brasilia, Brasilia, Brazil. Email:
[email protected] o.ca tI).D. Cowan is a Professor in the Computer Science Department at the University of Waterloo, Email:
[email protected], ca
or modules.
define an interface that separates the module or object from the user interactions or from the services supplied by another module or object. The interface should be aware of the requirements of the module or object, but
is the
in the Computer
of Waterloo, leave
objects
Similarly a module should know it requires services and specify that fact, but it should not specify how those services are supplied. What is required is an ability to
objects
is a Visiting
at the
other
has a similar property. There are many ways that a user can interact with an application and so the appli-
of a specification
interconnection
about their sura typical module
There are many ways that a data structure can be displayed, and since this is not an intrinsic property,
components.
as an
from
but to good engineering
These
and
$
a module will know too much about naming conventions in a file system, or about the names of modules or functions from which it acquires services. Such depth of specialized knowledge seems counter not only to reuse
Introduction
A
Nova
application, or what objects on the screen correspond to activations of components of the module. Similarly, a module or object knows too much about the services
com-
approach
ADOS,
system
using the
such
language
The and
designs
is
and the
concurrent
Additionally,
terface
Such of
reuse
framework
of each
of the
the
of
ADVS
describe
feat ures
(ADVS). clearly
system.
both
implementation
schemas
L.C.M.
$
or object of an application often knows about its user interface, specifically details of how its data structures will be displayed, how the user will interact with the
a new
reuse-in-the-
components.
specification
schemas
and
interfaces
of
support
Views specify
degree
approach
to
to
of a software
lead
sic
Data
created
separation
a formal
concept
Abstract was
ponents
present
design
approach the
Lucena
Objects
fact that they internalize knowledge rounding environment. For example,
object-oriented large
Interface
which represent, respectively, interface objects (views and interactions) and application objects which are independent of the interface. These objects provide a disciplined approach to design which supports separation of concerns, and should lead to a wide and consistent reuse of design specifications for both interface and application components.
felca
Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and th,e title of the publication and its date appear, and notice is given’ that copying is by permission of the Association of Computing Machinery.To copy otherwise, or to republish, requires a fee and/or sriecific ~ermission. SSR ’95, Sea~le, WA, USA @ 1995 ACM 0-89791 -739-1 /95/0004 ...$3.50 ‘
Various architectural models and programming proaches [3, 9, 13, 14, 17] have been proposed
88
apthat
clearly separate the user interface application. little
However,
guidance
isgiven
with
and its corresponding
the architectural
undesigning
2.1
models,
aprogram
Before considering
to have
a reasonable level of assurance that the architecture will be followed. Specific implementation techniques such as MVC [14] and ALV [13] have also been reported in the literature. These rely on contemporary programming
and operators
to support
separation
mouse click typify
of in-
for representing
ADV
or events are the result dependencies introduced
an ADV
may be considered
as a special-
of ADOS and ADVS.
an
ADV
query
does
or modify
or a mapping
its
about state
between
the
associated
means ADV
importance of this asymmetry later in this paper.
of its
ADO public
and
Data Object
Objects (ADO)
is an object in that it
or user commands do not directly act on an ADO, thus conserving the notion of an interface disconnected from an ADO. In the ADV design model, we extend the concept of ADO to allow composition of ADOS through specification constructors, where composition implies that ADOS
An ADO has no knowledge
its by
Data
has a state and a public interface that can be used to query or change this state. Every action of the public interface of an ADO is an effectual action and can only be triggered as a consequence of another ADO or ADV action. The action of external events such as input events
are composed of a number of constit uent ADOS and that In using composione ADO encloses its constituents. tion we also assume that the enclosing ADO- knows the identity of its constituents, but the enclosed ADOS do not know the identity of the enclosing ADO.
(ADVS), thus ensuring independence of from its interface. On the other hand, know
Abstract
An Abstract
Both ADVS and ADOS are objects and are composed of data signatures, attributes, and actions. ADVS are modified ADOS that support the role of interfaces in a software system. Although we can find many structural similarities in both concepts, it is important to observe that there is a clear separation between capabilities
of external stimuli, the action in this section are quite intu-
model
ization of an object with characteristics to support the development of general interfaces. As a consequence, the ADV model will embrace most of the characteristics that are inherent in the theory of objects [18].
of its interfaces the application
between the two types
itive. Moreover, these dependency definitions lead us to the conclusion that only causal actions (input events) can change the state of the system. The notion of actions is used in a subsequent section with respect to interconnection between ADVS and ADOS.
2.2 In general,
events that are causal actions.
Since internal elements do not trigger any event external to the system, and in addition, internal operations
designs using ADVS, have been tested in the production of several different software designs. ADVcharts have also been used to redesign and reengineer an existing interactive soft ware system.
of the
two categories:
A causal action may originate zero, one, or several effectual actions. Conversely, an effectual action cannot generate a causal action. This means that if we visualize a tree of related actions occurring over time, then a causal action will always appear only at the root of a tree of actions. This syntactic rule also characterizes the ADV-ADO interaction.
style.
Concepts
ADVS
of actions, while Figure 2 exemplifies the relationship between the two types of action occurrences.
that was built as a research prototype, was motivated by the idea of composing applications in the ADV/ADO
2
input
shows the possible dependencies
a user interface design system (UIDS) [15], to support concurrency in a cooperative drawing tool, and to design and implement both a ray-tracer in a distributed environment [19] and a scientific visualization system for the Riemann problem. The VX-REXX [21] system
formalism
with
On the other hand, effectual actions are the actions generated directly or indirectly by a causal action. Figure 1
ADVS have been used to support user interfaces for games and a graph editor, to interconnect modules in
[4], a graphical
associated
We use the term causal actions to denote the input events acting on an ADV. Causal actions are triggered from outside the system and internal objects are not able to generate this type of action. A key stroke or a
terface and application in the design is one of the major contributions of the ADV design model.
ADVcharts
the concepts
and ADOS, we introduce some basic concepts about actions. We call actions the programming functions and input events that act on an object to change or query its state. Actions can be divided into causal act ions and effect ual actions.
models and have been illustrated by several examples. For example, MVC was originally used in Smalltalk and ALV used constraint programming in a LISP environment. Although these are excellent implementation models, it is often difficult to map these strategies into other programming paradigms. The introduction of structures
Actions
can
interface
and related ADO. The in the model is indicated
Specification constructors for inheritance, sequences are also part of the formalism.
89
sets, and They are
ActionC.U,.l Action,
+
Action,
ff,ctU.l
+
jf,
Action,
CtU.l
ActionC.U,.,
ff.ctU.l
Action,
Figure
described
in
[1]
and
composition-based, terpreted
all
of
which
through
these
means
a primitive
1: Action
constructors
that
they
can
composition
be
+
of an
in-
been triggered
effectual
of an ADV
specification
the
Abstract
An ADV
is a design
user interface providing
structure
and to achieve
a clear
the application
and
to ADOS
to support
terfaces.
Since they
support
the
previous
section.
a separation
separation
of concerns
at the design
its interface.
ADVS
the design
of user
ADO
are
specification
ated
to act as general level
by
and
module
totype
constructors
described
mands
in-
ADVS
ADO,
tation
also
mechanism
are activated
by a mouse,
of game state
ADO.
monitors nism.
the
provokes
in order
ADO,
ADV
and
the
state
detects
this
appropriate,
the state the
change
the
the
the
of this the
ADV mecha-
game
ADO,
ADO
the
mapping
message
its
board
mapping
in
through
sends an output
of
state
is changing
move,
state
for
action)
to change
operation
in the
event
(causal
consequently
through
an internal
procom-
on the represenan input
ADO
user
section,
If user
event
game
to the
a change
the
in this
a click
actions
ADO
When
between
of a chess game
generate
The input
While
or The
the associ-
stimuli.
ADV.
as a response
by
ADO.
represents
introduced
of a chess piece would
piece
to the
behavior
to an external
effectual
interface
of the ADO.
concepts
the simplified
associated
specified
established
which
has
a query
action
ADV
in response
triggers the
that
is either
public
the
the state
interface
Alternatively,
state
ADO
from
the
the corresponding
in the
ADO
of the ADV
and
we describe
are extensions
extensions,
variable
ADO
action.
the
mapping
To illustrate
between
of this
the
is a linking
owner
conceived
action
by another
accessing
mapping
Views
Data
Actionc.=,al
about
ADV
by a direct 2.3
+
dependencies.
are
construct.
ActionCaU,=l
ff,c,U.l
that
bead
and,
updates
if the
user view.
2.4
Interconnection
Communication
between
is essentially are mapped described proach Figure
As
shown
ADV
by input
Figure
The
interaction
2,
the
operations the ADO ADVS
the
ADVS, has
output
change ADO
an
ADO.
ADV of
is invoked
actions
such
in
the
state
no
knowledge
as the
Changes
of an
between origin.
Such
changing in
the
an
or ADO
are
the the
other
components.
handling
asynchronous
complex
than
invocations
error-prone
a one-way
With
Although ADO This
and
“body
ADV”
have
ADO
lationships and
result
90
and the
by
is placed
the
ADO
of actions ADO.
Such
itse!f.
the
This
relationships
the role
ADV
and
model
asyn-
ADV
approach,
structure
the
and attributes
that
the
a design
between
inen-
we
unambiguously.
we can still
using
using
mapping
as a consequence,
between
process,
as signals,
ensuring
are defined
interconnections
is achieved
state
and,
communication
is a synchronous
chronous
associ-
since
such
thus
asyn-
However, more
an explicit
communication
where
and
invocations,
mechanisms
or callbacks.
ap-
is considerably
synchronous
of the interface
interactions
state
from
force
an
models,
invocations
and scope
ADV
user interface
chronous
handling
as
synchronous
synchronous
or
ADO.
The
that
instances,
both
terrupts,
com-
ADO
handle
events.
its
querying
other
instance
of actions
must
it requires
an input
and
section.
interconnections,
associated about
with
and an ADO
invocation ADV
previous
have fewer
as display through
the
extends
or causal
is altered
in the
contrasts
by
event,
of the ADV
has
either
is triggered
a keyboard
external
interaction
an
of an ADV
click,
to include
between
and output
action
between
a component
events
interface
appearance
every
purpose the
as a mouse
send
or a
Since
ADO
is, an ADV
the action
if their
message
ated
that
interface
also
mands,
interface
such Thus,
model.
interaction
of input
action
events,
a timer.
of
in
ADV/ADO
and a user is by means
messages.
the
2: An
an ADV
a synchronous
ADV
body
ADV
between illustrate
where
(view)
a
of an
defines
re-
the ADVS the
corre-
spondence ADO.
of elements
Each
where and
one element the
other
In general, that
sociated
ADO.
an ADV
with
is defined
has a correspondence ADV
specifies
inside
instead
interacts
of acting
Consistency
ADO.
tions
with
the ADV
model.
is called
horizontal
its as-
the design
structures intercon-
tween ties
Asynchronous
Model
Data Signature
ADV
Dats Signatures
ADOS,
ADO
Data Signarure5
cent aining
Data Signatures
Actions
Amibutes
Atwibutes
In
the
of the with
the clock
Figure
3: Interconnection
the ADV
the
state
of the
not
by the user interface.
In
this
3(a)
illustrates
interconnection side in
the
process,
body
both
ADV
ADV
respectively.
dences,
the body
introduces
between tures
section
might
the
many
ADVS
or
where
describe
ated,
a relationship
of actions.
actions,
an ADO,
we can
In
[7] there
such
design
be useful.
These
both
schemas
how
Additionally,
to be suitable introduced
here
the definition
ADV
approach.
are cre-
constitute the
the
the basic structures
enused that
The
be regarded
in
software
operations
of a formal
use
and ADO
in the
of development.
may
ADOS, [16], we
objects
step
for refinement
at each stage
step towards design
they
and
through
for each ADV
is an important
were
In addi-
formalism the
the
informal
in [11].
are destroyed
since
for
schemas
of ADVS
process,
occur
and
abstract
and
our
logic
system.
of the
formal
fact,
development
fications
struc-
schemas
In
of a schema
system
the since
by a timer
ones described
and
through
of the ADO,
abstract
tities should
are
the
time.
ADOS.
descriptions
states,
definition
are shown
interconnections
for [2].
con-
associated
specifications
on a temporal
in
change
The
such
the use of a body with
ADOS.
applications
also
a.Z correspon-
horizontal views
is changed
and
tools
ensures
by the state
to the ADVS
ADO
syntactic
while
the same
ADO
on the
are based
a software
to describe only
based
to the
which
a2
time.
ADVS
specifications
consistency
speci-
as an initial
semantics
for the
Consistency between
to create
collection
face for
input
between
same structure
only
it possible
cation
also define
are useful
tion
the
al and
schemas
of an ADO
specified
to the state
ADVS
program
2 illustrates
a model
different
we introduce of
primarily
and an ADO
and
we have been illustrating
The separation
view,
should
al
in-
action
we have
where
to an ADV the
in invocation
interesting
2.5
single
3(b)
model,
asynchrony
to interconnect
also use this some
ADV
delay
Although ADV
Figure
invocation Besides
action
a corresponding
corresponding
action,
as a specific
In
of a synchronous
a is a single
has
ADO.
action
are two actions
where
that
and
asynchronous
that
the modeling
clock
and
specification Figure
show
from
ADV
properof ADVS,
Figure
ADO, the
accessible
mapping
3
models.
clock
ADO
beADO
consistency
using
the time
that
is made
by
ADVS
consistency
specification
vertical
shows
guarantees
time
These
example,
(ADV)
while
as a
interfaces.
corresponding
The
m)
clock
itself
introduced
the different
environment.
distinct
representa-
ADO
and its associated
by the
properties
two
a view
sistency
(a)
consistency.
by their
visual
the
among
(ADV)
be guaranteed
and
the
and
consistency, object
consistency
that
Actions
the user and
of concerns
Consistency
vertical
must
these ADO
between
among ADO
of the separation
the visual
is called
exist
of a single
consequence
nections.
ADV
must
(ADVS)
as a design
and asynchronous
Synchronous Model
as the interface
the ADO.
an ADV the
be regarded
3 illustrates
synchronous
associated of elements
inside
how an ADV
Figure
can model
may
its
for a pair
has a correspondence
the body
element that
in
relationship
a clock
an analog
[7] would
different
of ADOS.
visual
could
view,
or both.
ADO,
ADO.
be placed
and application
Another
between
ADVS
and
schemas
two
ADOS These
a system,
and dynamic
as
ery
ADOS,
91
ADV
distinct
or
rather
in a software
are described
are not
of the
structure
objects
of their of entities
object.
is subdivided
sys-
by differ-
the actual
descriptions
and declarations
the scope ADO
roles
they
schemas
but
properties
are used within
ADV
have
as a consequence,
ent schemas. inside
appli-
values
case, a composite
as an interface
Descriptive
tem and,
in a digital possible
is to use its attribute In such
for a
the user inter-
be represented
3.1 makes
representations
For example,
ADO
for the clock to another
interface
Therefore, into
static that evthree
sections:
declarations,
static
properties,
and
servable
dynamic
Despite system, most
properties
objects
properties. having
completely
an ADV,
of the
different
as an extension
properties
acterize
an ADO.
abstract
schema
tinctions
between
and
for
and
and
then
ADO
form
conserves
structure
we initially
ADVS,
ADV
of an ADO,
general
Therefore,
tributes
roles in a software
g:sl,
where
introduce
the
note
dis-
is a sort
the
optional the
Data
forADO
ADO_Name
Signatures
Attributes Causal Actions
- sorts and functions observable properties - list of possible input
Effectual Actions Nested ADVS
- list of possible effectual actions inheritance, - allows composition,
Static Properties Constraints Derived Attributes Dynamic
End
constraints
of objects actions
in the attributes
- non-primitive
attributes
of the object. are represented
optional both
values
are declared and
- attributes
Valuation
- communication process description the effect of events on attributes
initialization
only
be
Behavior
- behavioral
tions
defined
of the ADV
changed.
every
ADV
an application duces the
the
ADO,
link
ADV
AD V-Name/ADO-Name
rule
corresponding resents since
occurs
ADO,
a button
screen.
In this the ADV
The
data
changes
case, the
the
so is called
interface
section
when colors
f
the
an ADV
part
a
rep-
of j,
and
be used values
blank,
consists
of a s, E S
the domain
n is the
arity
In the
We use the pair ifications ations
for
establishing
on the
values
the
that
Among sort expressions tions, such as integer specific
abstractions
defined
sorts.
can
also
sions, an
since
functions,
are also part Attributes an object
that
available
are stored
types
and
in the
including
object
support
oper-
this
constructors, to
of a set
such as set and
compose
complex
involved of values
denoting
with
operations
of the data
signature
denote
state
the
can change
in a sort
over
a sort
over
sort
union, is
values,
section.
or the time.
They
of
are the ob-
values may
from
useful
to an-
to model
actions. we should
objects
specification
constructors the
[const~]obj,
that
syntax
where
and obj denotes
name. The ADV compose, inherit,
intro-
of a composite
we specify
constructor,
section.
be considered
one object
V) section
by the expression
the
of the ob-
valuation
is particularly
the
could
during
case the parameter
in the
Therefore,
occur-
or they
of data
the attribute
(AD
have They
of
constr
the nested
approach supports the set of and sequence
of. objects
objects
are components
which
do not
component
of the
Composite
objects
stance can
set of features
section
All
expres-
expression.
given
with
may
of an action
to query
in
while
of the system.
of an object,
parameters
ADO
nesting.
ADO (ADV) constructors
or user-
signature
of ADOS
ADO,
the
data
and
are defined
specification.
In the first
the
of ADV
actions
description
effect
ac-
to be
types
actions
can
the
of the attribute
a system
to transmit
is a specification
attributes.
instances
case,
or ADV
spec-
we may have the basic abstracand string and the application
the semantics
association
The
Sort
be applied
in our object
Causal
are
observer
duce the list of all the component ADO
f.
in
values
which
the state
is described
Nested
attribute
the transmission
Such a mechanism
the response
of of
second
that
action
state
process.
as a mechanism other.
declarations
so, with
the
are used to update
In the
occur
schemas,
sections:
of the associated
to define
process
of the
actions
distinct
observer
inside
to describe
This
2.1,
schema
modify
current
interconnection ject.
functions.
.sl, . . . . Sn is called
on the
the until
O,. ... n, wherea
in the ADV
subtypes:
in
role
i=
actions,
state
actions
be used
rence
display
is left
of an object
: S1, . . . . Sn --+
codomain
have
the
parameters
might
excep-
of the
and a set F of function
form
for z = O, . . . . n, where f,
the
The
does not
ADO-Name
has only
names,
have
the ADV
the changing
time,
creation
we can subdivide The
to query
an important
link
two
local
other
actions.
The
which
Such
for.ADO.
as for example
that
ADO.
of
4, intro-
through
associated
when
signature
set S of sort which
to the
ADVS part
seen in Figure
by the constructor
to this
for ADVS.
as an interface
the schema
is related
is represented tion
is considered
changing
Sfor
to note
by
two
AL
Actions.
in the same
into
over
from
Section
into
Additionally,
actions
change
However,
It is also important
ADV-Name
Since
in
Efieciuai
affected
may
so
attribute.
S1, . . . . Sn (~ ~ O) represent the of the action. According to the
and ADOS.
Actions
O) deand
as a set of declarations
sorts
actions
0,. ... n, z
attribute,
of the
sie
introduced
Initialization
schema
and
ADVS
Interconnection
4: A descriptive
name,
parameter
definitions
Properties
Figure
with
is an action
description
properties
. . ..sn.
of the
unaltered
Actions a:sl,
Atof the
Sfori=
range
values
remains
destruction
form
by other
object.
S1, . . . . Sm (n
sorts the
attribute
of that
sie
name,
parameter
set of attributes ADV ADV-Name Declarations
----+ so, with
determining
though
schemas.
. . ..sn
are used
state
as a set of declarations
g is an attribute
char-
and
on the current
are represented
that
mention
of an object
to report
of the
happen
component composite
of some composite
belong
to a composite
operating are
environment
responsible
components. only
once
object
can
objects.
The
for
Since
in
a life
never same
the
of any
be nested rules
object;
object or
are a
“system”.
creating
creation
the
in-
action
object,
then
in two
distinct
used here for ADOS
a
will
also apply
tion
to ADVS.
components
static
and
properties affect
the
ties
of an
object
While
state
constraint
be true derivation
primitive
[20].
logic
ant
and
property,
ways”.
Derived
of temporal The
that
is valued
the occurrence tribute
creation,
ues even after The BEG
--+
clared object
In the
tions
tion.
val-
and
must
to describe
Behavior
mented
., Sj),
where
must
be de-
they
change
havior.
section
there
actions
in
and
correspondence
and
should
also describe
tions
inside
trigger
no knowledge The
tended
section
interpretation
actions
must of
form
have
a morphism obj-name
is
is
specified
1 element
element
refers
In Figure
has
therefore
mor(or
F--+
in
the
first
header
be-
paper,
we
the object
be-
of graphical have
repre-
chosen
instead
[4, 12, 5].
of the
object.
logic actions
A typical
forand
behavior
A action-name
and post-state in the
-+
are states
data
signature
and action_name
of sec-
is an action
might
schemas of
tions.
obj-name2.element
the
the
header
related
actions
an ADO
of
the
name the
has no
header
of the ADV
of
ADO
schema
AD V-Name/ADO-Name. difference
As mentioned
of every is found
ADVS,
only
schema,
structure
Since
associated
structural
is effectual.
93
schemas.
contains
a pair
Its charac-
the details
in the
is in sections
of causal
or actions
its
while
contain
Another
represen-
need to describe
of the
schema
of an ADO.
to the ones in the ADV
distinction
about
(ADO-Name),
in-
attributes
to attributes
The
an ADO
interconnected expressions
task.
are aug-
by temporal
5 we see the schema
we do not
knowledge
and which The
functions,
are very similar
section. by
In this
by pre-state
pre-state
over
system
which
[8].
sequencing
are declared
as boolean
the ADO
The by
that
object
teristics
objects.
simultaneously.
the
ac-
attributes
and
where
formula of an ac-
a complex
to describe
of the
the
of an ac-
of the object.
of ac-
morphisms
state
of
a single
of an action
networks,
be expressed
post_ state,
important
interconnected values
in the
since
represent
of objects
the
is described
tion
declared
will
express
form
of temporal
we could
behavior
first
valuation
are a number
that
expression
an ADO
described The
between
same
section
ADVS.
which
is that the
happen
ob~”-name.
since
attributes.
to be identified
always
Another
here is that action,
are used to define are
in this
of an action
the existing
and
as an in-
be the triggering
object.
an ADV
about
of actions
mappings)
must
this
interconnection
actions
could
to be mentioned
cannot
phisms
expressions
of
the
that
changes
and ac-
there
of and
on the occur-
general
diagrams
means
occurrence
models
representation
behavior
mulas
a
of attributes
is described
all the effects
Such effects
have
the attributes
mapping
ADO
The
or outside
consideration
The
its associated property.
in this object.
with
object.
object
is in
languages
by
The
the effects
description
However,
The
is a description
one
form
of transition
de-
pre-conditions,
the
on the
shows
state-machine
sentation
the
other
will
pre-condition
= valuem.
of the object.
chose a textual
have a correspond-
a +
values
by means
that
a. In addition,
of the object-oriented
havior
that how
Such a formula
Most by the formula
The
if
of an
occurrence.
one, or many
post-conditions
the attribute
(, Sj),
actions
attributes
terconnection
where
the at-
action
to describe
is unlimited.
of a only
occurrence
a pre-condition
named zero,
of formulas
to describe
in any other
an ADV
the
AaN(Sl,
have
establishes
at the time
have undefined
is expressed
actions
after
Since
may
are applied
and the pre-conditions
of the forms
of the action
de-
properties in attribute
a is described
A. . . attw
causal
consequence
expression
the
defines
tion
attributes
before
and
occurring
for the
an action
formula
number
process.
interconnection
synchronous
tation
S;)
entrance
for
can term
properties
valuation
rules
the
= valuel
action
The
values
a + rence
attributes.
of which
tion
may
initialization
as effectual
ing valuation
action.
Both
and
is declared
effectual
valuation
pre-conditions
the new attribute
attl
the
valuation
formulas
by
every
unchanged
not be initialized
process ...
of an object,
The
temporal
val-
defined
in their
as an immediate
are satisfied.
Valuation
object
the objmame
be one that
the changes
object
action.
When
section.
are to be evaluated
by means
In addition,
an attribute
al(Sl,.
of this
termine
“al-
the attribute
remain
the initialization
are
operator
is generally
the creation
or may
initialization
al, . . . . aN
by
initialize
by actions
may
describe
@ is an invari-
logic
of the initialization
values
of object
that
as undefined.
are not affected
of an object
temporal
of an object Before
valuation
action
are represented
also have
in the
obj_name
should
declared
actions
sections
all the specified
itself, the
are also expressed
of actions
ues of this object. attribute
is
element
the
triggered
formulas.
initialization
the triggering
of the object
temporal
attributes
logic
from
the
the
object.
object.
values
the
does not change
CI#, where
All fined
attribute
inside
the current
action
must
define
attributes
Constraints
•I is the
that
A derived
expression
does
proper-
formulas
attribute
inside
formulas.
to properties
it is a property
of the object
static
closed
non-primitive
the derived
the temporal
by
attributes.
are defined
be seen by the current
considered
existence
The
attribute
the
in that
but computing state
for
(base)
an attribute
refer
are
their
represented
derived
rules
since object.
formulas
over time,
which of
is missing,
attributes
of the
are
descrip-
how specification
reusable.
derived
of an object,
not
is a formal
to indicate
can be made
Constraints
the
In [1] there
of some approaches
before,
between to the an ADO
in its structure,
thus
ADV
and ADO
description
of ac-
has no definition every
ADO
action
ADO
ADO ADO-Name Declarations - sorts and functiOns observable properties
Effectual Actions Nested ADOS
actions - list of possible effectual inheritance, - allows composition,
Hours,
of objects
- constraints - non-primitive
in the attributes attributes
Minutes:
Eflectual Addl; Static
Static Properties Constraints Derived Attributes
Show:
0(0
Hours
