Appendix A Glossary This glossary contains important terms both from SSADM and SPECTRUM. Most of the SSADM definitions have been adapted from [Eva92]. The italic font marks words which are glossary entries. Attribute. An attribute is an identifier which is associated with an entity. For each attribute of an entity, a name for a data domain is defined. An attribute of an entity is to be interpreted as a function mapping occurrences of the entity onto values of the involved data domain. An attribute is called optional, if an undefined value for the attribute is permitted. Axiom. An axiom in SPECTRUM is an expression of Boolean sort which is part of a specification. The axioms of a specification use the function symbols which are defined in the signature part of the specification or in the signature part of primitive specifications. Data Flow. A dataflow is an arrow drawn in a Data Flow Diagram. It connects a process with external entities, with data stores or with other processes, in order to represent the input and output for the process. D a t a Flow Diagram. A Data Flow Diagram (DFD) consists of external entities, processes, and data stores which are connected by dataflow arrows. The purpose of a DFD in SSADM is to represent basic functionality of a system in a structured way without giving a detailed specification.

234

Appendix A: Glossary

Data Store. A data store is one of the building blocks for a Data Flow Diagram. It represents a part of the system state which is read or updated by the processes to which it is connected by data flow arrows.

Degree (of a relationship). A degree is a classification which restricts the number of occurrences of an entity being associated by a particular relationship. The following cases are distinguished, how an entity E can participate in a relationship to another entity F: • If there is no restriction about the number of occurrences of entities E and F, the relationship is called many-to-many (n:m). If only one ocurrence of entity E can be associated with a given occurrence of entity F, but arbitrary many occurrences of entity F can be associated with a given occurrence of entity E, the relationship is called one-to-many (1 :m). In this case the entity E is called the "master" in the relationship, and the entity F is called the "detail". • If, additionally, one and only one occurrence of the entity E can be associated with an occurrence of entity F, the relationship is called one-to-one (1:1). By default, in all three cases an occurrence of entity E has to be associated with at least one occurrence of entity B and vice versa, unless the relationship is declared to be optional for one or both of the participating entities. DFD. See Data Flow Diagram. Domain. A set of possible values from which any attribute of an occurrence may take its actual value. ECD. See Effect Correspondence Diagram. Effect. Any update of the system state caused by an event instance is described by its local effects to single occurrences. An effect specifies the changes for a given entity occurrence and its relationship associations. For a given entity of the occurrence under consideration, an effect is classified by a triple consisting of the actual event, the actual option and the rote (of the occurrence). Role and option information may be omitted in simple cases. An effect is further described as a composition of operations. The operations performed on a single entity occurrence can be read from the leaf of the Entity Life History of the entity which is labelled with the event and (possibly) the option and role.

Effect Correspondence Diagram. An Effect Correspondence Diagram (ECD) is a diagrammatical representation of the structure of the portion of the database

Appendix A: Glossary

235

which is affected by any instance of an event. The ECD contains the names of the involved entities, together with information on the multiplicity of ocurrences for these entities and the access paths within the database to identify the affected parts. Options and roles are used for a further distinction of event and entity. E L H . See Entity Life History.

Entity. An entity is an identifier, which is to be interpreted as a set of elements which are called the occurrences of the entity. Seen as abstractions from realworld things, all occurrences of the entity have the same characteristics and conform to the same rules. SSADM does only take care of entities which are candidates for components of the system data base.

Entity Life History. An Entity Life History (ELH) is a diagram of a tree-like shape which refers to a single entity. It contains (in its leaves) event names (possibly further specified by options and roles), which describe some effect on an occurrence of the entity under consideration. The tree-structure of the diagram (Jackson structure) enables an interpretation as a a set of admitted sequences of events. During system specification, the leaves are augmented with operations, which give a detailed description of the effect caused by the event. E v e n t . An event is an identifier which is interpreted as a property o f transformations of the system state. The admitted state transformations (event instances) are disjointly classified by the event identifiers. An event is further specified by the Effect Correspondence Diagram, the Event/Entity Matrix and by the operations contained in several Entity Life Histories. E v e n t / E n t i t y M a t r i x . T h e Event/Entity Matrix gives a compact overview describing which occurrences are affected by an event instance and in which way. The overview is given as a matrix, indexed by event and entity identifiers. The matrix entries show a rough classification of the type of update (creation, modification, deletion). In SSADM-F, the Event/Entity matrix is refined into a form which also covers

option and role information. E x t e r n a l Entity. An external entity is one of the building blocks for a Data Flow Diagram. It represents a source for input data or a sink for output data of the system. F o r m a l i t y . A technique of a method is called jbrmal, if it relies only on the syntactical form of the used artifacts, and not on the particular choice of identifiers. A method is called formal, it all its techniques are formal. A method with a significant of formal as well as informal techniques is called semi-formal.

236

Appendix A: Glossary

Function. a. In SSADM, a function is a user's view of a piece of system processing. [Eva92] b. In SPECTRUM,function is often used as a short form for function symbol. Function symbol. A function symbol in SPECTRUM is declared in the signature of a specification together with sort symbols. The declaration gives an identifier for the function symbol and its sort expression, which often involves the cartesian products (x) and function space (---~) constructions. Any model of the specification associates with the function symbol a mathematical function, which corresponds to the interpretation of the sort expression and which is require~ to be monotonic with respect to the underlying approximation order on carder sets. Function symbols are used in the axioms of a specification. Key. A key is an attribute whose value uniquely identifies a specific occurrence of an entity. [Eva 92]

Mapping. In SPECTRUM,the word mapping is used for a special kind of function symbols the interpretation of which is not required to be continuous. In the signature syntax, mappings are indicated by using the keyword to instead of the function arrow (---~). Method. A (software development) method is a notational and procedural framework to be used by humans for producing computer software. It consists of three parts: • A set of notations, which define the syntax of artifacts (texts, tables, diagrams, forms), which are to be produced when carrying out the method. A set of techniques, which encapsulate a number of notations together with basic technical steps of analysis and transformation for artifacts which are written in these notations. • A set of procedural guidelines, which define an order for applying the technical steps. Model. The semantics of a SPECTRUM specification is defined as the class of models of the specification. A model is a many-sorted algebra, which associates with each sort (expression) a carrier set and with each function (symbol) a continuous function working on the appropriate carrier sets. Moreover, nonmonotonic functions are admitted as the interpretation of mappings. For details see [BFG+93]. Notation. See Method.

Appendix A: Glossary

237

Occurrence. An occurrence is a single element belonging to the set described by an abstract entity. The state of an information system is a collection o f occurrences.

Operation. a.

In SPECTRUM, the word operation is frequently used as a synonym for function, which is an abbreviation for function symbol. Typically, function symbols with a symbolic or an infix syntax are addressed as operations.

b.

In SSADM, an operation is a discrete piece of processing which constitutes, together with other operations, an effect, i.e. a modification of the system state [Eva 92, adapted]. An operation always refers to one single occurrence of an entity. Possible operations are: • creation of an occurrence • changing the values of one or more attributes in the occurrence • deletion of an ocurrence • establishment of a relationship association with another occurrence • removal of a relationship association with another occurrence. During Requirements Specification in SSADM, the creation and deletion operations are not yet shown, but in Logical Database Process Design they appear exlicitly.

O p t i o n (for event). An option is an identifier which is used as an additional qualification for a specific event. The specification of an actual state transformation caused by an event instance is split into subcases by an option. The classification of an event instance by an option may depend on the actual state of the system. O p t i o n a l A t t r i b u t e . An attribute of an entity is called optional, if it is allowed that some occurrence of the entity may have no defined value for the attribute.

Optionality (of relationship). In a relationship R relating entity E to entity F, R is called optional for F, if ocurrences of entity E can exist which are not related through R to an occurrence of entity F. Analogously, the relationship R may be optional for F. In the graphical representation, the optionality of R for E is expressed by dashing the part of the R line attached to the E node. A nonoptional relationship is called "mandatory".

238

Appendix A: Glossary

Pragmatism. A method is called pragmatic if its notations, techniques and procedural guidelines are derived from significant practical experience and if its usefulness in practical applications has been proven.

Process. A process is one of the building blocks for a Data Flow Diagram. The semantics of a process is the transformation of the system state, where the data flows coming into the process from a data store represent a read access to parts of the state, the data flows going from the process to a data store represent updates to parts of the state. Other input and output data for the transformation are represented by data flows from and to external entities and other processes.

Relationship. A relationship is an identifier to which a number of entities are associated. In SSADM, a relationship is always associated with two entities, and therefore is called binary. A relationship is to be interpreted as a mathematical relation between the sets of occurrences which are denoted by the entities involved.

Requirements Specification. A software requirements specification is ,,a document containing a complete description of what the software will do without describing how it will do it." [Dav90, p. 17] Role. A role is an identifier which is sensible only if connected with a specific entity and a specific event. It is used to partition the set of occurrences of the entity into subclasses which are updated differently by instances of the given event.

Semi-formal. See Formality. Signature. The signature is the part of a SPECTRUM specification which contains declarations of sort symbols and function symbols. The other main constituents of a SPECTRUMspecification are axioms.

Sort Symbol. A sort symbol is declared in the signature part of a SPECTRUM specification. A sort symbol is an identifier, which is to be interpreted in any

model of the specification as a set of values. Sort symbols are use~ mainly in the function declarations in specifications, to ensure that the arguments and results of functions in the model belong to specific sets of values. A special case are here sort constructors for polymorphic sorts which can be understood as functions producing new sorts if provided with appropriate argument sorts. For a clear distinction between sort names and sort parameters for sort constructors, the sort parameters are always named by greek letters in this work, by convention.

Appendix A: Glossary

239

Strict. In SPECTRUM,a function symbol f can be declared to be strict. This means that the mathematical function associated with f in any model yields an undefined result if it is given an undefined argument. Strong. In SPECTRUM, a mapping symbol m can be declared to be strong. This means that the mathematical function associated with m in any model yields a defined result for any (defined or undefined) argument.

Technique. See Method. Total. In SPECTRUM,a function symbol f can be declared to be total. This means that the mathematical function associated with f in any model yields a defined result if it is given a defined argument.

Appendix B "Hotel A g e n c y " An SSADM-F Specification This appendix contains the detailed SSADM-F documents for the small example which was informally introduced in chapter 3. Appendix C contains the formal representation of these documents in the SPECTRUMabstract syntax for SSADM-F. As in the main text, mainly Logical Data Modelling (LDM) and Entity-Event Modelling (EEM) are covered here. For Data Flow Modelling (DFM), only a single Data Flow Diagram (the Context Diagram) is given. Examples of diagrams of lower levels are given in chapter 11.

242

Appendix B: "Hotel Agency" - An SSADM-F Specification

B. 1 DFD Documents B.I.1 Level 0 Data Flow Diagram (Context Diagram) application

~..k._

mqu]ry(~

TU'"J

B . 2 L D M Documents B.2.1 Entity-Relationship Diagram C

Customer

~) wants ~ Y.£'--

_~y

ho,~,-~.~...,

_

Request ~) ~ ~"

/ r~qoo,t,

.~ ~oservation)/

or lr,,,rvT--

/is_requested_in is_reserved in )) C - Hotel ' ' ,)- is_forj~ ""K. pre_booked_by

Quota

3

B.2 LDM Documents

243

B.2.2 Entity Descriptions SSADM-F Extended Entity Description I Entity name

Customer

Attribute name

!

Mandatory

Prim. Key -q

Customer number Customer name Customer address Credit card info Date last request

q q q q

SPECTRUM Domain nat str str

str_in(16) date

SSADM-F Extended Entity Description I ,,Entity name

Request

Attribute name

Mandatory

I Prim. Key

SPECTRUM Domain nat

Reference number Period of time Number of rooms Date req. hotel

pair(date, date) nat date

SSADM-F Extended Entity Description ] Entity name

Reservation

Attribute name

Reference number Period of time Number of rooms Date off. customer

Mandatory

Prim. Key

SPECTRUM Domain

nat pair (date, date) nat date

244

Appendix B: "Hotel Agency" - An SSADM-F Specification

SSADM-F Extended Entity Description ! Entity name

I

Hotel

Attribute name

Mandatory

Prim.Key

SPECTRUM Domain nat sir sir amount

Hotel number Hotel name Hotel address Room price

SSADM-F Extended Entity Description

I Entity name Quota Attribute name Hotel number Available date Num. rooms avail.

I Mandatory

Prim. Key

SPECTRUM Domain nat

date nat

B.3 EEM Documents

245

B . 3 E E M Documents B . 3 . 1 Event-Entity Matrix Entity Event Customer Request M immed, offered M inquired fr. hotel Hotel Reply available as reqd. altern, available

C

M M

C

M R

[reqd.] [alt.] M

D

C

M

M

D

C

M

not available

M

D

Fixed Booking

M

D

M

Check Reservns.

M

D

M

Check Customers

D

New Customer

C

M M

M

M

M

Add Hotel

C

Remove Hotel

D

D

Add Quota

M

C

Remove Quota

M

D

B . 3 . 2 Effect Correspondence Diagrams Event New Customer:

( ustome Event Add Hotel:

(,

H°tel 3

246

AppendixB: "HotelAgency"- An SSADM-FSpecification

Event Remove Hotel:

(

Hotel ~ - - i ~ pre_booked_by

Set of Quota

(

, , ,,,,,,,,,,

Quota

*1

)

Event Add Quota I Event Remove Quota:

Option pre__booked_by Event Customer Request:

\

pre_booked-by Hotel

0

immediately offered is_reserved_in I

Set of Quota *1

(

Quota 0 inquired fromhotel i is_requested_in

(Reservation) ( R e q u e s t ) I wants

holds i O

immediately offered

t

inquired fromhotel

Customer ,,,)

°l

)

B.3 EEM Documents

247

Event Hotel Reply:

Request

Customer

Reservation is_reserved_in

-available '~ o] i s - t~served- .for[ - "available o

[requested]

is_ alternative o I -. is_reserved_for available [ v i available pre_booked_by~ [ Set of Quota *l

I

(Quota) Event Fixed Booking:

(

holds Customer ~

reserves Reservation

Hotel

)

Event Check Reservations:

[Set of Reservation ] holds

I

= ( eservation

reserves

Ho~

)

I pre_booked_by [ Set of Quota "1

I

(Quota)

248

Appendix B: "HotelAgency" - An SSADM-F Specification

Event Check Customers: I set of Customer * I

( B.3.3

Customer )

Entity Life Histories with Operation Lists Customer

[

i ~owCu"omor! I "~-L~o * !

Requests of

!~ ~.om:~

! Reservations

Z~,

Customer o ][ o Request i Hotel Reply (inqd. ft. hotel) (not available)

/ o

Customer Request (imm. offered)

Hotel Reply (available as requested)

II

/

°ll

Hotel Reply (aitemative available)

\

°!!

F'~ed Booking

°I

Check Reservations

°!

B.3 EEM Documents

249

List of operations: Store attribute Customer number Store attributes Customer name, Customer address, Credit card information Store attribute Date last request Gain relationship Wants to Request Lose relationship Wants to Request Gain relationship Holds to Reservation Lose relationship Holds to Reservation

I Reservation !

I

Creation

I

I ~u~o~ Hotel Reply (available as requested)

I

Deletion

//\

Fixed Booking

Hotel Reply (alternative available)

°11

List of operations: 1 Store attribute Reference Number Store attributes Period, Number Rooms, Date Offered 2 Gain relationship Is_Reserved_For to Customer 3 4 Gain relationship Reserves to Hotel 5 Gain relationship Reserves to Hotel [requested] 6 Gain relationship Reserves to Hotel [alternative] 7 Lose relationship Reserves to Hotel 8 Lose relationship Is_Reserved_For to Customer

°I

I

oI

Check Reservations

250

Appendix B: "Hotel A g e n c y " - An SSADM-F Specification

Hotel

I

~eq°~" °1

!-

/'x,

Request !! (not available) !!nqd. fr. hotel) I I [requested]

o

o!

I Q,o.

o

t~ ! Reservatioes [

o

o

°N

I Request II(avail.~ d.) II(altemafiveavail+)llCaltemativeavail')li Booking I(immed.offered)ll [requested] I/ [requested] I/ [alternative| II ......

List of operations: Store attribute Hotel Number 1 Store attributes Hotel Name, Hotel Address, Price 2 Gain relationship Is_requested_in to Request 3 4 Lose relationship Is_requested_in to Request Gain relationship Is_reserved_in to Reservation 5 Lose relationship Is_reserved_in to Reservation 6 7 Gain relationship Pre_booked_by to Quota Lose relationship Pre_booked_by to Quota 8

! Reservations

B.3 EEM Documents

251

I

Request

[

ustomrel I

I

(inqd. fr. hotel) [

List of operations: Store attribute Reference Number 1 Store attributes Period, Number Rooms, Date Inquired 2 Gain relationship Is_requested_by to Customer 3 Gain relationship Requests to Hotel 4 Lose relationship Is_requested_by to Customer 5 Lose relationship Requests to Hotel [requested] 6

Quota

Add Quota

[

[

l

Deletion I

?--->_

[RemoveQuota° I [Remove.o!el o[

Mid-Life * [

utomr °, [ ustome ° I (available oe e asy°ll oel y Request Request (alternative otE

(imm. offered) I (inqd. ft. hotel)

requested)

available)

List of operations: Store attributes Hotel number, Date, Number Available 1 Gain relationship Isfor to Hotel 2 Store attribute Number Available 3 Lose relationship Is_for to Hotel 4

Check Reservations

o!

Appendix C SPECTRUM Translation of the "Hotel Agency" Specification This section contains the same information as appendix B (sections B.2 and B.3), but in the SPECTRUM abstract syntax for SSADM-F. This is a project level specification by which the parameterized SSADM-F specification can be instantiated.

C. 1 Translation of L D M Documents C.I.1 Entity-Relationship Diagram HA_ERD = { data Entity = customer I reservation I request I hotel I quota; data Rel = holds I is_reserved_for I wants t is_requested_by I is_reserved_in I reserves I is_requested_in I requests I pre_booked_for I is_for; inv: related: multiple, optional:

Rel --) Rel; Rel --) Entity x Entity; Rel --) Bool;

axioms inv(holds) = is_reserved_for; inv(wants) = is_requested_by;

inv(is_reserved_for) = holds; inv(is_requested_by) = wants;

254

Appendix C: SPECTRUMTranslation of the "Hotel Agency" Specification

inv(is_reserved_in) = reserves; inv(is requested_in) = requests; inv(pre_booked_for) = is_for;

inv(reserves) = is_reserved_in ; inv(requests) = is_requested_in; inv(is_for) = pre_booked_for;

related(holds) = (customer, reservation);

related(is_reserved_for) =

related(wants) = (customer, request); related(is_reserved_in) = (hotel, reservation); related(is_requested_in) = (hotel, request); related(pre_booked_for) = (hotel, quota); multiple(holds) = false; multiple(wants) = false;

multiple(is_reserved_in) = false; multiple(is_requested_in) = false; multiple(pre_booked_for) = false;

multiple(is_reserved_for) = true; multiple(is_requested_by) = true; multiple(reserves) = true; multiple(requests) = true; multiple(is_for) = true; endaxioms; }

(reservation, customer); related(is_requested_by) = (request, customer); related(reserves) = (reservation, hotel); related(requests) = (request, hotel); related(is_for) = (quota, hotel); optional(holds) = true; optional(wants) = true; optional(is_reserved_in) = true; optional(is_requested_in) = true; optional(pre_booked_for) = true; optional(is_reserved__for) = false; optional(is_requested_by) = false; optional(reserves) = false; optional(requests) = false; optional(is_for) = false;

C.1.2 Entity Descriptions ATTRVAL = { - - Attribute values for Hotel Agency; enhanced version of figure 7.11 strict total; enriches Naturals + String; data AttrVal = natural(!natval: Nat) I stdng(!strval: String) I boolean(tboolval: Bool)l dateYear(!day, tmonth, lyear: Nat) I money(lbeforePt, !afterPt: Nat) I valPair(! valt, ! val2: AttrVal); sortsyn Domain = AttrVal --> Bool; nat, bool, str: nat_in: str_in: date, amount: pair:

Domain; Nat x Nat --> Domain; Nat ~ Domain; Domain; Domain x Domain ~ Domain;

C. 1 Translation of LDM Documents

axioms V n, nl, n2: Nat; dl, d2: Domain; v: AttrVal in nat(v) = is_natural(v); str(v) = is_stdng(v); bool(v) = is_boolean(v); nat_in(n1, n2) (v) = is_natural(v) A (nl _ List c¢; - - Filters a list according to a predicate

filter:

foldrl:

List ¢ x ((x --) c() -e List c~; Transforms a list pointwise ((~ x c~ --~ o¢) x List c( --~ (x;

all, ex:

- - "Folds" binary o p e r a t o r o v e r list List ~ x (o( -~ Bool) --~ Bool;

map:

--

- - Extension of predicate to list n o D u p l i c a t e s : List c(--) Bool; - - N o duplicate e l e m e n t s in list?

List List c~ ~ List;

concat:

- - Concatenation of list of lists

pairs:

List (~ x List ¢ --) List ((x x c( ); - - List of all pairs out of t w o lists

filter, m a p , all, ex, noDuplicates, concat, pairs t o t a l ; axioms

V x: o~, V U, v: List (x, p: (c(--) Bool), f: (o~ --~ (z), g: (¢x x ~ --* (x) in

filter([], p) = []; filter([x]++u, p) = if p(x) t h e n [x]++filter(u, p) e l s e filter(u, p) e n d i f ; map([], f) = []; m a p ( [ x ] + + u , f) = [f(x)]++map(u, f);

D. 1 Lists

267

f o l d r l ( g , []) = _L; f o l d r l ( g , [ x ] + + u ) = if is_[](u) t h e n [x] e l s e g(x, f o l d r l ( g , u)); all(D, p) = true;

all([x]++u, p) = p(x) ^ all(u, p);

ex([I, p) = false;

ex([x]++u, p) = p(x) v ex(u, p);

n o D u p l i c a t e s ( u ) = (V x. length(filter(u, Xy. y = x)) < 1); concat([]) = []; -~ is D(u) =--:,c o n c a t ( u ) = f o l d r l ( . + + . , u); pairs([],v) = []; pairs([x]++u, v) = m a p ( v , Xy. (x, y)) ++ pairs(u, v);

}

endaxioms;

D . 2 Finite Sets SET = { strict total; enriches

--

P o t y m o r p h i c finite sets o v e r sorts with d e c i d a b l e e q u a l i t y

LIST;

s o r t S e t ~;

S e t :: ( E Q ) E Q ;

emptySet:

Set (~; - - T h e e m p t y set

addSet:

~:: EQ ~

(~. x S e t (~ -~ S e t c(; - - Insertion of an e l e m e n t

S e t c~ g e n e r a t e d remSet:

by emptySet,

(z:: EQ

Set (~ × (~ -~ Set (~; --

card:

(~:: EQ

addSet;

R e m o v a l of a n e l e m e n t

Set c( ~ Nat; - - Cardinality

• e.

:

(x:: E Q

(~ × S e t (~ -~ Bool; - - M e m b e r s h i p test

• c_. :

co: E Q

S e t ccx S e t o~ --) Bool; - - S u b s e t relation

• L ) . , . c~., .\.: c~:: E Q

S e t c~ x S e t cc --) S e t cq --

set:

c(:: EQ

Union,

intersection a n d d i f f e r e n c e

List c~ --) Set ~; - - C o n v e r s i o n list to set

- - Using the set function, set literals c a n be easily written like set [ 1 , 2 , 3] allSet,exSet:

(~:: EQ ~

S e t c( x ((~ ~ Bool) --~ Bool;

268

Appendix D: Basic SPECTRUM Specifications

filterSet:

c(:: EQ

mapSet:

(x:: EQ

- - Tests set for a property Set (x x ( c ( - ) Bool) --> Set c(; -Filters a set Set o{ x (a --) c¢) --) Set a; -Transforms a set pointwise

V et:: EQ ~ x, y: ix, s, s l , s2: Set e¢, u: List (x, p: ((x --) Bool) in addSet(x, addSet(x, s)) = addSet(x, s); x # y ~ addSet(x, addSet(y, s)) = addSet(y, addSet(x, s));

axioms

remSet(x, emptySet) = emptySet; remset(x, addset(y, s)) = if x = y t h e n remSet(x, s) else addSet(y, remSet(x, s)) endif;

card(I])

= 0;

card(addSet(x, s)) = 1 + card(remSet(x, s)); -, (x e emptySet); x e addSet(y, s) = ((x = y) v (x e s)); (sl ~ s2) ¢=>V x. x ~ sl ~ x ~ s2; (sl =S2) (sl ¢ S 2 A S 2 c s l ) ; x E (sl LJS2) ¢=> ( x ~ s l ) v ( X ~ S2); XE ( s l n s 2 ) ¢~ (X~ S l ) A ( X ~ S2); XE (sl \S2) ¢:> (XE s l ) A " ( X E S2); x ~ (set u) ¢=> x elem u; allSet(s, p) = (V x. x E s ~ p(x)); exSet(s, p) = (3 x. x ~ s A p(x)); X e (filterSet(s, p)) ¢=>(x elem u) A p(x); y E (mapSet(s, f))