Domain Models of \The Market"
| in Preparation for E{Transation Systems
Dines Bjrner
Informatis&MathematialModelling
TehnialUniversityofDenmark
DK{2800Kgs.Lyngby,Denmark
dbimm.dtu.dk
Abstrat
ByanE{TransationSystemweshallunderstandaomputer&ommuni-
ations{basedsystemwhihsupport,and,inpartsautomatesexhanges
ofation{invokingloal state{hangingmessages(ie., transations) be-
tweenawidevarietyofators(traders). By\TheMarket"weshallrst
understandastrutureofonsumers,retailers,wholesalersandproduers
|ie., thetraders. Laterweshallextendournotionof\TheMarket".
WepresentinformalEnglishlanguagedesriptions(narratives)andfor-
malmodelsofa\Market"onept. Whatgenerallyharaterisetraders
are the kindof interations they engagein: Issuing inquieries and of-
feringquotations, plaingand aeptingorders,eetingand aepting
deliveries,postingand payinginvoies, et. Traders dynamiallyform
`supplyhains'. Anytradermay,potentially,overdierentinterations,
atanyoneofthetraderr^oleslistedearlier. Wethen\lift"themarketto
inludeagents 1
(atingonbehalfofanyoneofthetraderslistedearlier),
and brokers(ating onbehalfof`sequenes' oftwoor more\adjaent"
traderswhile basiallyengaginginthekindoftransationsenumerated
above). Wenishbyrstmakingsomeremarksontheuseofthemodel
presented as abasis for requirementsdevelopment. Thenwe \lift"the
notionoftraderstonotjustrepresentingpairsofbuyersandsellersina
onventionalsupplyhainofmerhandise,butanypairsof(institutional)
GovernmenttoG(G2G),Gto(privateorpubli)Business,Gto(individ-
ual, human) Citizen, B2G, B2B, B2C, C2G, C2B, and C2C transation
possibilities.
1
Westressthatthe notionof`agents'used hereisnotthesamenotionasitisurrently
envogueintheAIommunity.But,aswepointoutinaonludingsetion,Setion11.5.2,
11.1 Introdution
The aim of this paper is to ontribute to preise understandings of what is
meant by E{Commere, {Business,{Government, et. Wesuggestto ahieve
this goal by \imposing" orderly, formal tehniques{based proesses, rst of
analysis,laterofsynthesis,onthedevelopmentofsoftwarefor\suh"E appli-
ations.
11.1.1 The Setting
Some fats: Before software and omputing systems an be developed, their
requirementsmustbereasonablywellunderstood. Beforerequirementsanbe
nalisedtheappliationdomain,asitis, mustbefairlywellunderstood.
Some opinions: In today's software and omputing systems development
verylittle,ifanythingisdone,welaim,toestablishfairunderstandingsofthe
domain. It simply does not suÆe, we further laim, to reord assumptions
aboutthedomain when reordingrequirements. Farmoreradialtheories of
appliationdomainsmustbeathandbeforerequirementsdevelopmentiseven
attempted.
Inthispresentationweadvoateastrongr^olefordomainengineering. We
arguethat domaindesriptionsarefarmorestable thanarerequirementspre-
sriptionsfor support of oneor anotherset of domain ativities. We further
argue,thatone,givenextensivedomaindesriptions,itisomparativelyfaster
to establishtrustworthyand stable requirementsthan itis today. We nally
arguethat onewehaveasuÆient(varietal)olletionofdomainspei,ie.
related,albeitdistint,requirements,weandevelopfarmorereusablesoftware
omponentsthanusingurrentapproahes.
Thus, in this ontribution we shall reason, at a meta-level, about major
phasesofsoftwareengineering: Domainengineering,requirementsengineering,
andsoftwaredesign.
In other papers 2
we suggesta number of domain and requirementsengi-
neering as well as software design onerns, stages and steps, notably: Do-
mainfaets,inludingdomainintrinsis,supporttehnologies,management&
organisation, rules & regulations, as well as human behaviour. respetively
requirements: Domain requirements,interfaerequirements, and mahine re-
quirements. Speially: Domainrequirementsprojetion,determination,ex-
tension,andinitialisation.
11.1.2 The Bakground
Wementiontwofaetsofthebakgrounduponwhihthispaperisputforward.
2
Ourmainresearhdiretion isthatoftryingtoometo gripswith\What
issoftwareengineering?". Theenumerationsoftheprevioussetionprovidesa
glimpseintohowweintendtoanswerthatquestion: Softwaredevelopmentas
athree phase\aair"onsistingof the(possiblyoverlappingandre{iterated)
developmentsof domaindesriptions,requirementspresriptionsandsoftware
designs|witheahofthesephasestypiallyonsistingofuptoseveralstages
ofdevelopments(\renements",\transformations"),andwith stagestypially
onsisting of several steps. Our quest, along this rst faet of methodology,
isone ofdisovering(identifying), researhing, and developing priniples and
tehniquesforsensibledispathesofphases,stagesandsteps.
A derivative \researh"diretion is then that of applying these proposed
priniples andtehniquesto the buildingof spei domain theories. Justas
wehavethetheoriesofmehanis,eletriity,thermodynamis,et.,ofphysis,
so we would like to see theories emerge from domain models of man{made
universes suh as transport and logistis, nanial servie industry, health{
are,et.
The present paper onstitutes a seond beginning (f. [Bj01b℄) with re-
spet toapossibletheoryofsomeform of\market"domain. Weanreferto
similar suh \rst beginnings" for arailway domain [Bj94, BLP94, BGP99,
BPG99a,BPG99b,Bj00b,Bj03i℄,aresouremanagementdomain[Bj00a℄,a
projets(ie.,aprojetmanagement)domain[Bj99b,Bj03h℄,asustainablede-
velopmentdomain[Bj99a℄,alogistisdomain[Bj03e℄,ahealth{aredomain
[Bj03d℄,asheries(industry)domain[Bj98℄,ananialservie{industrydo-
main [BRH98, Bj03℄, and many others. Thepresentstage of mostof these
\rst beginnings" is that they are all somewhat skethy: Their ongoing de-
velopment is pursuedasmuh for the reason of testing developmentmethod
priniples and tehniques| and disoveryof new oralternative suh, asfor
thereasonoftheseonjetured, respetivedomaintheories.
Ingeneral,our seondresearhfaet aimsat overingvarious examplesof
the onept of infrastruture omponents and has, as its objetive, that of
eventuallybeingabletoharaterisetheinfrastrutureonept[Bj95,Bj96,
Bj01a,Bj02d℄
3
.
11.1.3 The Struture of the Paper
Setions11.2{11.3,besidesonstitutingthe\bulk"ofthispaper,alsoisinthe
formofaofthedoumentationthat wefavourfortheearlystagesofdevelop-
mentofsoftware. Setion11.2brieyoutlinesaprojetofdevelopingadomain
modelleadingupto E{Commere. Setion11.3presentsmain omponentsof
theformal doumentation ofa domainmodel for\the market". Setion 11.4
speulates on possible requirements for \E{Business", where, from a limited
viewof \the market" as onsisting of traders in the private enterprise sphre
3
andof onsumers,wegeneralisebyre{interpretingthemarket interations of
inquieries, quotes, delinations,refusals, orders, onrmations,deliveries, a-
eptanes,invoiings,payments,aknowledgements,returns,andrefunds(soon
tobeidentied)|withslight\re{labellings"|intointerationsbetweenand
withinGovernment,Businesses,andConsumers,that is: G2G,G2B,G2C,B2G,
B2B,B2C,C2C,C2B,andC2G.
Thenexttwosetionsarethus presentedaswewould developandpresent
maindoumentsofsoftwaredevelopment,frominitial, pragmatiprojetdo-
uments,viadomainmodellingdoumentsto,ashere,requirementsdouments.
Wedonotpresentalldouments,but ommentbrieyonthoseleftout.
11.2 Initial Projet Douments
The sope 4
of our onern is the market of onsumers, retailers, wholesalers
and produers. Thespan 5
of ouronern is the set of those ativitiesof the
marketthanan bemehanisedusingomputers andommuniation.
11.2.1 Needs and Ideas
Anoverall needispereivedfordeployingomputers andommuniation(in-
luding the Internet) to support a number of market transations. The
mainideasaretosupportthoseofinquiringastowhihprodutsareavailable,
their prie and delivery onditions, replying to suh inquieries, order-
ing produts,onrming, delivering,aepting, invoiing, paying, rejeting,
returning,andrefunding suhorders,respetivelydeliveries.
6
Further ideas are to provide speeh at{based software \agents"
7
[Pet02℄
fousedaroundmodallogis|notoveredinthepresentpaper.
11.2.2 The Design Brief
Theoveralldesignbriefistoprovideaskethofadomainmodelofthemarket.
Themodel shall be both informally and formally desribed. Andthe model
shallenablerequirementsdevelopment.
4
Weusetheterm`sope'inthesenseof[Ja95 ℄.
5
Weusetheterm`span'inthesenseof[Ja95 ℄.
6
Observetheuseofthreetypefonts: sansserif fordoumenttypes,slanted fordomain
operations,andtele typefordomainentities.
7
Cf. Footnote 1: Weare now,here, referringto what istraditionallyviewedas an AI
11.3 The Domain
By a domain we understand an area of human (or other) ativity. Exam-
plesare: \therailwaydomain",\the health{aredomain",thedomain ofthe
\nanial servie industry", et. Elsewhere the omposite term `appliation
domain',where`appliation'signalsthat thepersonwhoutterstheomposite
termintendstoapplyomputers&ommuniationtoproblemsofthedomain.
We presentour understanding of adomain through douments. Software
developmentisfoused onthedevelopmentof(semantiallymeaningful)do-
uments.
11.3.1 Informative Douments
We normally operatewith three kinds of douments: Informative(ie., prag-
mati),desriptive(ie.,syntatiandsemanti), respetivelyanalyti(valida-
tion&veriation)douments. Weshallexemplifyonlythersttwokindsof
douments,andthenonlysomeofthese.
Needsand Ideas
We need both informal and formal deriptions. Informal desriptions serve
validationpurposes: Arewedealingwiththeright\thing"? [Boe81℄. Formal
desriptions serve veriation purposes: Are we getting the \thing" right ?
[Boe81℄.
The ideasare to letthe informaldesriptions\follow" the formalmodels,
andtolettheformalmodelsbeexpressedintheRaiseSpeiationLanguage
(RSL)[GHH +
92,GHH +
95℄.
Etetera: Anatual`needsandideas'doumentmayontainfurtherdetails!
The DesignBrief
Thedomaindesign brief isto providedesriptiveand analytidouments: (i)
Roughskethesof theonepts ofthemarket,(ii)theformulationof abstrat
marketonepts(basedon(iii)analysesoftheroughskethes),a(iv)termino-
logyforthemarketdomainasitappliestothegivenproblem,andaombined
(v+vi)narrative(ie.,informal)andformaldesriptionofthemarket.
Etetera: Anatual`domain designbrief'doument will (shall)ontainfurther
details!
Onthe Contrat
Aontratdesribes`partiestotheontrat',`thesubjetmatter' and`onsid-
erations'.
Theontratualrelationshippotentiallyinvolvesthefollowingmarketstake-
brokers,naning(payment, et.), anddelivery(ie.,transport)servies|as
wellasthefollowingomputingsystemsstake{holders: domainengineers. The
`subjetmatter'isdesribedintheoveralldesignbriefandinthedomaindesign
brief. The ontratstatesthe following `onsiderations': (a)that themarket
stake{holders shall validate the domain desriptions provided by the domain
engineers,and(b)thatthelattershallhave\suh{and{suhfree"aesstothe
market stake{holders(in order to obtain theneessaryand suÆient domain
knowledge).
Etetera: Anatual`ontrat'doumentwill(shall)ontainfurtherdetails!
11.3.2 Desriptive Douments
Wepresentafairseletionof partsofdesriptivedouments.
ARough Skethand its Analysis
Werstbringanexampleroughsketh,thenitsanalysis. Afterthatwebring
bothroughskethesandanalyses.
Buyers and Sellers: Firsta roughskethof what is meantby buyersand
sellers,thenitsanalysis.
Rough Sketh: Consumers, retailers, wholesalers and produers form the
major\players"inthemarket.
A onsumer may inquire with asupposedly appropriateretailer asto the
availabilityofertainproduts(ummerhandise): Theirprie,deliverytimes,
otherdeliveryonditions(inl.quantityrebates),andnaning(ie.,payment).
A retailer may respond to a onsumer inquiry with either of the following
responses: Aquoteoftherequestedinformation,ora(ourteous)delination,
oramessage that the inquirywas misdireted(refusals), orthe retailermay
deidetonot, orfail to, respond ! A onsumermaydeide toorder produts
with a supposedly appropriate retailer, whether suh an order has been or
has not been preeded by a related inquiry. The retailer may respond to a
onsumerorder with either of thefollowingresponses: Conrming, delining
or \no{response", with a onrmation being following either by a delivery,
or no delivery | or the retailer may just provide a delivery, or inform the
onsumer that a bak{order has been reorded: The desired produts may
not be in store, but has been (or will be) ordered from a wholesaler | for
subsequent delivery. A delivery may deliver the ordered or some other, not
ordered, produts ! The onsumermay deide to not aept, orto aepta
delivery. Theretailer may invoie theonsumer before, at thesame timeas,
or after delivery. The onsumer may pay, or not pay an invoie, inluding
performing a payment basedon no invoie, for exampleat the same timeas
ndfaultswithapreviouslyaepteddeliveryandreturnthat(or,bymistake,
another)delivery. Theretailermayrefund,ornotrefundsuhareturn.
Analysis: Basedonananalysisoftheaboveroughskethwesuggesttotreat
marketinterationsbetweenretailersandwholesalers,andbetweenwholesalers
andproduersinexatlythesamewayasinterationsbetweenonsumersand
retailers. That is: we observethat retailers ats as(a kindof)\onsumers"
vis-a{viswholesalers(who,similarlyatsasretailers).
We thus summarise the interations into the following enumeration: in-
quieries,quotes,delinations,refusals,orders,onrmations,deliveries,aep-
tanes,invoiings,payments,aknowledgements,returns,andrefunds.
Figure 11.1attemptsto illustratepossibletransation transitionsbetween
buyersandsellers.
Figure11.1: Buyer/SellerProtool
Inquiry Quote,Decline,Wrong
Order, Decline, Wrong
Delivery,Sorry Confirm,Decline,Wrong
Accept,Reject,Wrong Invoice, Wrong Payment,Wrong Acknowledgement
Return Refund
BUYER SELLER
Buyer initiative Seller initiative
"Follows, as a consequence of"
Traders: As a onsequene of the analysis we shall \lift" the labels `on-
sumer',`retailer',`wholesaler'and`produer'intothelabels`buyer'and`seller'.
Andweshall use theterm `trader' to overbotha buyerand aseller. Sine
theonsumers and produers mentionedin therough sketh abovemay also
atasanyoftheotherkindsoftraders,allwillbelabelledtraders.
Figure11.2onthenextpageattemptstoshowthatatraderanbebotha
buyerand aseller. Thustraders\alternate" betweenbuying andselling,that
is: Betweenperforming`buy'andperforming`sell'transations.
Supply Chains: Figure 11.3 on the following page attempts to show \an
Figure11.2: Trader=Buyer+Seller
TRADER TRADER TRADER
SELLER BUYER
BUYER SELLER inquiry
order accept payment
return ...
quote confirm
...
quote confirm deliver invoice acknow.
refund ...
refund acknow. invoice deliver
inquiry order accept payment
return ...
Atomic Transactions, One way or the Other !
hains. Eahhain,inthisexample,onsists,inthisexample,ofa\onsumer",
aretailer,awholesaler,andaproduer.
Figure11.3: ANetworkofTradersandSupplyChains
A B
D C
H
(Example Supply Chains: ABCG, HDBF, BGAE, ...) G
E
F
A olletion,aset, of traders may thus giveriseto any set of supplyhains,
witheahsupplyhainonsistingofasequeneoftwoormoretraders. Supply
hainsarenotstati: Theyform,atanddissolve. Theyarearesultofpositive
inquieries,orders,deliveries,et.
`Likeness', `Kinds', `Adjaeny', and `Supply Chain Instanes': As
aresult of analysis we identify aneed for some abstrat onepts: `likeness',
`kinds',and`supply[hain℄ instanes'(where[...℄ expressesthatweanomit
the...).
onsumer,retailer,wholesaler,orproduer.
Weanalsospeakofthe`kind'ofatransation.
The `kind' of a transation is either than of inquiery, quote, delination,
refusal, order, onrmation,delivery, aeptane, invoie, payment, aknowl-
edgement,return,orrefund.
There may be hains of one or more wholesalers: Global, regional, na-
tional,or,withinastate,areawholesalers. Wethereforeallowforthefollowing
kinds of adjaent traders: (onsumer,retailer), (retailer,wholesaler), (whole-
saler,wholesaler),and(wholesaler,produer).
A supply [hain℄ instane is a spei and related ourrene of two or
more transations. The following is an elaborate supply hain instanes |
where we omit referene to the speis by only mentioning the transation
kinds: (i)inquiry(onsumertoretailer),!inquiry(retailertowholesaler),!
quote (wholesalerto retailer),!quote (retailertoonsumer),!order (on-
sumer to retailer), ! order (retailer to wholesaler), ! order (wholesaler to
produer),! onrm(produer towholesaler),! onrm (wholesaler tore-
tailer),!onrm(retailertoonsumer),!delivery(produertowholesaler),
!aeptane(wholesalertoproduer),!delivery (wholesalertoretailer),!
aeptane (retailerto wholesaler),! delivery (retailerto onsumer),! a-
eptane(onsumertoretailer),!invoie (retailertoonsumer),!payment
(et.,thereaderllsinpossibledetails),!aknowledge,!invoie,!invoie,
!payment,!payment,! aknowledge,! aknowledge,! return,and !
refund.
Agentsand Brokers: Althoughnotformalisedexpliitlyinthepresentpa-
perwedisusstheoneptsofbrokersandtraders. Wethen,lateron,\redue"
agentsandbrokersto beomeliketradersare.
Agents: An agent, 8
, in the domain, is any human orany enterprise, in-
luding mediaadvertisement,who,orwhih, atsonbehalfof onetrader, t
1 ,
in order tomediate possiblepurhase (or sale) ofgoodsfrom another trader,
t
2 . So t
1
may be a onsumer, ora retailer, or a wholesalerwho, through
aquiresgoodsfrom t
2
who,respetively,isaretailer,awholesalerandapro-
duer. Ort
1
maybearetailer,orawholesaler,oraproduerwho,through
sellsto t
2
who,respetively,is aonsumer, aretailer,and awholesaler. One
angeneralisethe notion of agents to suh who (or whih) ats on behalf of
agroupoflike tradersto \reah"aorresponding groupoflikeand adjaent
traders.
Figure11.4onthenextpageattemptstoshowabuyer{agent(lefthandg-
ure),respetivelyaseller{agent(righthandgure). Thebuyer{agent\searhes"
themarketfor suitablesellersofaspei produt. Theseller{agentsearhes
themarketforsuitablebuyersofaspeiprodut.
8
Buyer
Buyer
Buyer
Buyer
Seller
Seller
Seller
Seller
Seller
Seller Buyer
Agent
...
...
...
...
...
...
Buyer
Buyer
Seller
Seller
Seller
Seller Agent
Buyer
Buyer Buyer
Seller
...
...
...
... ...
...
Figure11.4: BuyerandSellerAgents
Theidea is that thetwokinds of agents behavelikebuyers,respetivelylike
sellers:Thebuyer{agent\learns"fromthebuyer 9
aboutwhatistobeinquired,
isinstruted when to order,et. The buyer{agentthen iterates overa set of
sellersknowntomeet inquiredexpetattion 10
Similarlyforseller{agents(the right{handsideofFigure11.4).
Brokers: A broker, , in the domain, is any human orany enterprise, in-
luding media advertisement, who, orwhih, atson behalf of two(or more,
respetively) adjaentgroupsof liketraders, bringing them together in order
toeetinstanesofsupplies.
Figure 11.5 on the faing page attempts to diagram a broker mediating
betweenmbuyersandn(adjaentkind) sellers.
The idea is that a ombination of buyer and seller searhes, and henea
ombinationofthebuyer{andseller{agentbehavioursareneeded.
Brokersanspanmorethanonestage.
Figure 11.6 on page 12 attempts to diagram a brokermediating between
m
1
onsumers,m
2
retailers,m
3
wholesalersandm
4
produers|subsetsofall
theknownsuh.
The three sets of dashed lines in the three vertial \stems" of thebroker
shalldesignate\loal"brokeragebetweenadjaentpairsofbuyersand sellers.
Theset of dashedlines in thehorisontalbranhof thebrokershalldesignate
overall,\global"brokeragebetweenallparties.
9
Thisisdesignatedbythesingleline(betweentheBuyerandtheBuyerAgentretangles)
oftheleft{handsideofFigure11.4.
10
Thisisdesignatedbythe mostlyslatedlines(betweenthe BuyerAgentandtheSeller
Figure11.5: ASimple(\OneStage")Broker
Buyer
Seller
Seller
Seller
Seller
Seller
Seller
...
...
...
...
...
...
Buyer Buyer Buyer
Buyer
...
...
Broker
Buyer
Theaimofthemediationistoreateaonsortiumofsubsetsofonsumers,
retailers,wholesalersandproduers. Theobjetiveoftheonsortiumis,likea
\BookoftheMonthClub",toreateastablesetofompletesupplyhainsfor
agivensetofproduts.
As for simple brokers we shall (ever sobriey) argue that the sameiter-
atedsearhingofresolutionprotoolsandmehanismsasforagentsaretobe
deployed, and that these are based on the all the transation kinds as rst
skethed.
Catalogues: An importantoneptof themarket isthat of aatalogue. It
may beimpliit, orit mayexist expliitly. A atalogue,in awidest sense of
that term, is any form of reording that lists what merhandise is for sale,
itsprie,onditionsofdelivery,payment,refund,et. Anordinaryretailer|
yoursmallneigbourhood\Mom&Pop"store|maynotbeabletodisplaya
atalogueintheformof,forexample,aringbindereahofwhosepageslists,in
someorder,themerhandisebyname,ordernumber,produer,et.,andwhih
reords theabove mentioned forms of information. But, from the shelves of
that storeonean \gather"that information. Forwholesalersand produers
weanprobably assumesuh moreformal atalogues. But, asaonept, we
aninanyasespeakofatalogues. Andheneweanspeakofsuhonepts
assearhing in aatalogue, markingentries asbeing outofstok, howmany
Figure 11.6: AMultiple(here: Three)StageBroker
...
...
...
...
...
... ...
...
... ...
...
...
S
B
B
B
B
B
B
B
B
B
B
B
B
B S
S
S
S S
S S S
S S
S
S
S
S B
B
Consumers Retailers Wholesalers Producers
Broker
TheTransations: Wehave,above,justhintedatthekindoftransations,
towit: inquiry,quote,delination,refusal,order,onrm,delivery,aeptane,
invoie, payment,aknowledge, return, andrefund. Insteadof treating them
inmoredetail|aspartofanarrative|werelegate,for thesakeofbrevity,
suh atreatment to the terminology setion, next, and to theformalisation,
following.
This ompletes our, lengthy, rough sketh of \The Market" domain. It was
made deliberatelylong in order to make the point: That rough skething is
animportantproess,and that roughskethesserveapurpose |asweshall
subsequentlysee.
Terminology
Inanydevelopment,in any (domain, requirementsorsoftware design)phase
ofsuhadevelopment,it isjudgedimportantto start, afterroughskething,
byestablishingaterminology,byadheringtoitthroughtthedevelpment,and,
wheneedarises, to update theterminology whileseuring that previoususes
(\adherenves")remainvalid. Failuretofollowthis`terminologyodex'usually
resultsin termonfusionandthusleadstolowqualitysoftware.
We sketh a ratherinformal terminology. That is: A properterminology
mustbefar morepedantiin its preision,onsisteny ofterm usage, andin
itsompleteness.
1. Aept: A delivered merhandise is in-
spetedbythebuyerandfoundaeptable.
2. Aknowledge: Reeipt of payment has
been reorded by a seller and thebuyer
(thepayee)isgivenanaknowledgement.
3. Agent: Asurrogatebuyerorasurrogate
sellerwhoatsonbehalfofeitherabuyer,
oraseller,andotherwiseperformsthefol-
lowingprotoolsoftransations:....
4. Bak{order: An order whose delivery
annotbeetedimmediately.
5. Broker: asurrogatebothbuyer& seller
whoatsonbehalfofbothbuyersandsell-
ers, andotherwiseperformsthefollowing
protoolsoftransations:...
6. Buy: Abuytransationisthesameasan
ordertransation.
7. Buyer: A buyer is any traderwho may
issueaninquiryoranordertransation.
8. Catalogue: Wheninquiringorordering,
an impliit refereneis made to a ata-
logue |somethingthatreordsproduts
boughtorsold,theirpries,deliveryonsi-
tions,et.|ie.,somethingthattheseller
issupposedtohaveandtobeabletoquote
from,orfromwhihruialinformationfor
aninvoieisulled,orwhihthebuyer...
et.
9. Conrm: Ifanorderanbeeeted,ei-
thernow,oraslater(asabak-order),then
aonrmationanbeissuedtothateet.
Etetera:
10. Consumer:...
11. Deline:...
12. Deliver:...
13. Inquire:...
14. Inventory:...
15. Invoie:...
16. Market:...
17. Merhandise:...
18. On{order:...
19. Order:...
20. Pay:...
21. Prie:...
22. Prie{list:...
23. Produer:...
24. Produt:...
25. Quantity:...
26. Refund:...
27. Rejet:...
28. Retailer:...
29. Return:...
30. Sell:...
31. Seller:...
32. Servie:...
33. Store:...
34. SupplyChain:...
35. Trader:...
36. Warehouse:...
37. Wholesaler:...
...
&. ...
Thisompletes ourrathershort terminology. It islargeenough, wethink, to
havepartially made ourpoint | asstated in the opening paragraph of this
setion. Afulljustiationfor`terminologisation'anonlybemadespmetime
aftertheendofaprojet.
Narrative and Formal Model
Weombine, into onedoument,the informaldesriptionand theformal de-
sriptionof the domain of traders. Wedesribe only the basiprotools for
inquiry,quote,order,onrmation,delivery,aeptane,invoie,payment,et.
transations. Wethus donotdesribeagentsandbrokers. Weleavethat toa
requirementsmodellingphase.
Pleaseobservetheextensiveneedforexpressing seletionofand responses
totransationsnon{deterministially. Intherealworld,ie.,inthedomain,all
ispossible: Dilligentstawillindeedfollow{uponinquiries,orders,payments,
et. Loyalonsumerswillindeedrespondlikewise. Butsloppysuhpeoplemay
not. And outright riminals may wish to heat, say on payments or rejets.
Se initial remarks on determination of undesirable non{determinisms in
Setion11.4on`Requirements'.
Formalisationof Syntax:
type
Trans==InqjOrdjAjPayjRej
jQoujConjDeljAjInvjRef
jNoRjDejMis
Thersttwolinesabovelistthe`buyer',respetivelythe`seller'initiatedtrans-
ationtypes. Thethirdlinelistsommontransationtypes.
In the domain we an speak of the uniqueness of a transation: \it was
issued at suh{and{suh time, by suh{and{suh person, and at suh{and{
suhloation,"etetera.
Ubelowstandfor(supposedly,orpossibly)uniqueidentiations,inluding
time,loation,person,et., stamps(T,P,L),Sui(wherei=1,2)standsforsur-
rogateinformation,and MQPalludes toMerhandiseidentiation, Quantity,
andPrie.
type
U,M,Q,P,T,Su1,Su2,Inf
Inq::MQPU
MQP==mk(m:M,q:Q,p:P,:::)
Quo:: ((InqjSu1)Inf)U
Ord:: QoujSu2U
Con:: OrdU
Del:: OrdU
A:: DelU
Inv:: DelU
Pay:: InvU
Rej:: DelU
Ref:: Pay U
NoR:: TransU
De:: TransU
Mis::TransU
value
obsT:U!T
Theabovedenesthesyntaxoflassesofdisjointtransationommands,ofthe
abstrat form mkName(kind,u) where Name is either of Inq, Quo, Ord, Con,
Del,... orMis.
Aninquiry:Inqonsistsofapair,some(desired)merhandise,(desired)quan-
tityand(desired)prieinformation,andasupposedlyuniqueidentiation(of
time,loation,person,et.) ofissue{this\mimis"aonsumerinquiryofthe
form\Iaminthemarketforsuh{and{suhmerhandise,insuh{and{suha
quantity,andat suh{and{suhpries. Whatanyouoer?"..
Anquote:Quoeitherreferstotheinquiryinwhihthequoteisaresponseor
presentssurrogateinformation|typially(wherethesellertakestheinitiative
toadvertisesomemerhandiseandthen)ofaformsimilartoaninquiry: \Ifyou
areinthemarketforsuh{and{suhmerhandise,insuh{and{suhaquantity,
andatsuh{and{suhpries,thenhereiswhat weoer".
Ingeneralwemodel,inthedomain,a\subsequent"transationbyreferring
toaompletetraeof(supposedly)uniquetime,loation,person,et.,stamped
transations. Thus,in general, atransation \embodies"thetransationit is
amanifestresponseto,andtime,loation,person,et. ofresponse.
Do not mistake this for a requirement. A requirement may or may not
imposeuniqueidentiationwrt.timeandloationandpersonet. Therefore
we do notdetail U. Nordo weatually say that no two transations anbe
issuedwiththesameuniqueness.
FormalisationofMarketInterations: \TheMarket"onsistofntraders,
whether buyers, or sellers, or both; whether additionally agents or brokers.
Eahtrader
i
isable,potentiallytoommuniatewithanyother trader:
f
1
;:::;
i 1
;
i+1
;:::;
n g:
Weomitformaltreatmentofhowtradersometoknowofoneanother. An
arbiterforsuhinformationisjustlikeatrader. Othertraderssellinformation
abouttheir existineto suh anarbiter. Thusno speial formal treatment is
neessary.
We fous on the internal and external non{determinism whih is always
there,inthedomain, whentransationsare seleted,sentandreeived.
OurmodelisexpressedinavariantofCSP,as\embedded"inRSL[GHH +
92℄.
type
[0℄ ,MSG
[1℄ Idx=fj1::njg
value
[2℄ sys: (Idx !
m
)!Unit
[3℄ sys(m)kftra(i)(m(i)) ji:Idxg
hannels ft[i,j℄:MSGji,j:Idx
i<jg
value
[4℄ tra: i:Idx!!inft[j,i℄jj:Idx
i6=jgoutft[i,j℄jj:Idx
i6=jgUnit
[5℄ tra(i)()tra(i)(nxt(i)())
[6℄ nxt: i:Idx!!in ft[j,i℄jj:Idx
i6=jgoutft[i,j℄jj:Idx
i6=jg
[7℄ nxt(i)()
[8℄ let hoie=rvdesndin
[9℄ aseshoieofrv!reeive(i)(),snd!send(i)()endend
(0) is the type spae that any trader may span. MSG is type spae of
detailneithernorMSG:Inthe\realworld",ie.,inthedomain,allispossible.
Determination of andMSG is usually donewhen \deriving"the funtional
requirementsfromthedomainmodel. (1)Idxisthesetofnindies,whereeah
traderhasauniqueindex. WedonotdetailIdx. Thatusuallyisdoneaslateas
possible,sayduringodeimplementation. (2)Thesysteminitialiseseahtrader
with apossibly unique loal state (from its only argument). (3) The system
is the parallel ombination of n traders. (4) A trader has aunique, onstant
index, i, and is, at any moment, in some state . (4) Traders ommuniate
(bothinputandoutput) overhannels: t[i,j℄|from traderito traderj. (5)
Eahtrader ismodelled asaproesswhih \goesonforever",(5)but insteps
of nextstatetransitions. (8)Thenext statetransitionnon|deterministially
(internal hoie, de) \alternates"between(9)expressingwillingnessto reeive,
respetivelydesiretosend.
In \real life", ie. in the domain, the hoie as to whih transations are
pursuedisnon{deterministi. Anditisaninternal hoie. That is: Thehoie
isnotinuenedbytheenvironment.
We model reeiving as something \passive": No immediate response is
made,but areeivestateomponentof thetraderstateisupdated. A trader
thathasdeided tosend(something), maynon{deterministialydeidetoin-
spet the reeive omponentof its state soasto asertain whether there are
reeivedtransationspendingthatoughtormayberespondedto.
Theupdatervstateinvokesfurther funtions.
reeive: i:Idx!!inft[j,i℄jj:Idx
i6=jg
reeive(i)()
de
bflet msg=t[j,i℄? in updatervstate(msg,j)()endjj:Idxg
One the internal non{deterministi hoie (de) has been made ((8) above):
Whether to reeive or send, the hoie as to whom to `reeive from' is also
non{deterministi,but nowexternal(dbe). That is: reeive expresseswillingness
to reeivefrom any other trader. But just one. As longas noother trader j
doesnotsendanythingtotrader ithat traderijust \sits"there, \waiting"|
potentially forever. This is indeed amodel of thereal world, the domain. A
subsequentrequirement may therefore, naturally, beto provide someform of
timeout. Are{speiationofreeivewithtimeoutisaorretimplementation
oftheabove.
[2℄ update rvstate: MSGi:Idx!!
[3℄ update rvstate(msg,j)()
[4℄ asesobsTrans(msg)of
[5℄ mk Del( , )
[6℄ !upd rv(msg,j)(upd del(msg,j)()),
[7℄ mk Ret( , )
[9℄ !updrv(msg,j)()
[10℄ end
(2)anymessagereievalleadstoanupdateofa'reeive'omponentoftheloal
traderstate(updre). (5{6)If thereeived\message"onstitutesa(physial
pakage)delivery, thena`Merhandise' omponentof theloal traderstateis
rstupdated(deposit delivery ). (7{8)Ifthereeived\message"onstitutesthe
return(ofaphysial pakage),thenthe`merhandise'omponentoftheloal
traderstateisrstupdated(removereturn).
[0℄ upd re(msg,j)()deposittrans((sU(msg),j),msg)(ond re(msg,j)())
[1℄ upd del(msg,j)()depositdelivery((sU(msg),j),msg)()
[2℄ upd ret(msg,j)()removereturn((sU(msg),j),msg)()
[3℄ ondrv(msg,j)()
[4℄ ifintialtrans(msg)()
[5℄ then
[6℄ elseremovepriortrans(sU(msg),j)()end
sU:Trans!U,sU( ,u)u
(0) The updre operation invokes the ondre operation and then extends
thepossiblynewstatebydepositing theargumentmessageunder theunique
identiation and message{sending trader identiation. (3{6) The ond re
operation examines ((4) initialtrans) whether the reeived message is a rst
suh, ie., \ontains" no prior transations, or whether it ontainssuh prior
transations.Inthislatterase(6)thepriortransationmaybeonditionally
removed (remove priortrans) |this is notshownhere, but ommentedupon
below.
[0℄ send: i:Idx!!inft[i,j℄jj:Idx
i6=jg
[1℄ send(i)()
[2℄ let hoie=inideresdenorin
[3℄ ases hoieof
[4℄ ini!sendinitial(i)(),
[5℄ res!sendresponse(i)(),
[6℄ nor!removereeivedmsg()endend
Eitheratrader,whenommuniatingatransationhooses(2,4)aninitial(ini)
one,orhooses(2,5)onewhihisinresponse(res)toamessagereeivedearlier,
orhooses(2,6) tonot respond (nor) to suh anearlier messageThehoie is
againnon{deterministiinternal(2). Inthelastase(6)thestateisthusnon{
deterministiallyinternalhoieupdatedbyremovingthe,oranearlierreeived
Note that the abovefuntions desribe the internal as well as the exter-
nalnon{determinism of protools. We omit thedetailed desription of those
funtionswhihanbelaimedtonotbeproperprotooldesriptionfuntions
|but are funtions whih desribeupdates to loal trader states. We shall,
below,explainmoreaboutthese state{hangingfuntions.
sendinitial: i:Idx!!outft[i,j℄jj:Idx
i6=jg
sendinitial(i)()
let hoie=buydesellin
aseshoieof
buy!sendinit buy(i)(),
sell!send init sell(i)()endend
sendresponse: i:Idx!!outft[i,j℄jj:Idx
i6=jg
sendresponse(i)()
let hoie=buydesellin
aseshoieof
buy!sendresbuy(i)(),
sell!send ressell(i)()endend
Intheabovefuntions wehave,perhapsarbitrarilyhosen,todistinguish be-
tween buy and selltransations. Both send initialandsend responsefuntions
|aswellasthefourauxiliaryfuntionstheyinvoke|desribeaspetsofthe
protool.
sendinit buy: i:Idx!!outft[i,j℄jj:Idx
i6=jg
sendinit buy(i)()
let hoie=inqdeorddepayderetde::: in
let (j,msg, 0
)=prepareinit buy(hoie)(i)()in
t[i,j℄!msg; 0
end end
sendinit sell: i:Idx!!outft[i,j℄jj:Idx
i6=jg
sendinit sell(i)()
let hoie= quodeondedeldeinvde:::in
let (j,msg, 0
)=prepareinit sell(hoie)(i)()in
t[i,j℄!msg; 0
end end
prepareinit buy is nota protool funtion, nor is prepareinit sell. Theyboth
assembleaninitial buy, respetivelysellmessage,msg, atargettrader, j, and
updateasendrepositorystateomponent.
sendresbuy: i:Idx!!outft[i,j℄jj:Idx
i6=jg
sendresbuy(i)()
0
let ( 00
,msg 0
)=response buy msg(msg)(
0
)in
t[i,j℄!msg 0
; 00
endend
sendressell: i:Idx!!outft[i,j℄jj:Idx
i6=jg
sendressell(i)()
let ( 0
,msg)=selupdate sellstate(),j=obstrader(msg)in
let ( 00
,msg 0
)=response sellmsg(msg)(
0
)in
t[i,j℄!msg 0
; 00
endend
selupdatebuy state is not aprotoolfuntion, neither is selupdate sellstate.
Theybothdesribetheseletionofapreviouslydeposited, buy,respetivelya
sellmessage,msg,(fromit)theindex,j,ofthetraderoriginatingthatmessage,
and desribesthe update of areeived messagesrepository stateomponent.
responsebuy msgand responsesellmsg botheet theassembly, frommsg, of
suitableresponse messages,msg 0
. As suh theyarepartlyprotoolfuntions.
Thus, if msg was an inquiry then msg 0
may be either a quote, deline, or a
misdiretedtransationmessage. Etetera.
OnOperationson Trader States: Wehaveleftanumberoftraderstate
operationsundened. Belowwegivertheir signatureand otherwiseomment
ontheminformally. Thereasonfornotformallydeningthemissimple: Sine
we are modelling the domain, and sine, in the domain, these updates are
typially performed by humans, and sine these humans are either dilligent,
orsloppy, ordelinquent, or outrightrominal in the despath of their duties
we really annot dene the operations as we would really like to see them
despathed|namelydiligently.
value
deposit trans: (UIdx)MSG!!
deposit delivery: (UIdx)MSG!!
removereturn: (UIdx)MSG!!
initialtrans: MSGIdx!!Bool
removepriortrans: UIdx!!
removereeivedmsg: !
Theaboveoperationshaveallbasiallybeenmotivatedearlier. Thedeposit trans
unonsditionallydepositsareeivedmessage,forexampleinapartoftheloal
trader statethat ould be haraterised as arepositoryfor reeivedtransa-
tions. That repository may have messages identied by the sender and the
uniqueidentiator. Tospeify sois not amatter of binding future require-
mentsandthereforealsonotfuture implementations. Itjust models thatone
Aninitialtransationisonewhihdoesnotontainpriortransations,that
is: Is onewhih is either an inquirytranationor ontainssurrogates (Sur1,
Sur2).
To remove a prior transation models that people may no longer keep a
reordofsuhatransation|sineitisembeddedinthemessageinresponse
towhih thisremovalis invoked. Wedonotshowthedetails ofremoval,but
expetamodeltoapturethatsuhpriortransationsneednotberemoved. In
otherwords: Theremovalmaybeinternalnon{deterministially\ontrolled".
removereeivedmsg unonditionallyremovesamessage: Thismodelsthat
people and institutions (internal non{deterministially) may hoose to ignore
inquieries,quotations,orders, onrmations,deliveries,et.
prepareinit buy: Choie!Idx!!IdxMSG
prepareinit sell: Choie!Idx!!IdxMSG
Theaboveoperationsinternalnon{deterministiallyhooseswhihpriortrans-
ationsto respondto.
obstrader: MSG!Idx
Nomatter whih transation (ie.,message)oneanalwaysidentify, sayfrom
the unique identiator, whih trader originated that message. We do not
speifyhowsinethatmightbiasanimplementation.
Forthesakeofompletenesswealsostatethesignaturesofremainingand
previouslydesribedoperations:
value
upd re: MSGIdx!!
upd del: MSGIdx!!
upd ret: MSGIdx!!
ondrv: MSGIdx!!
selupdate buystate: !MSG
selupdate sellstate: !MSG
response buy msg: MSG!!MSG
response sellmsg: MSG!!MSG
In summary: All operations on loal trader states are, in the domain, basi-
allyunder{speied. Itwill beataskforrequirementsto,asweshallallit,
Disussion
Asforloaltraderstateoperations,soitisforthepossiblesequenesoftrans-
ationsbetween\marketplayers"(ie.,thetraders): Theyareall,intheabove
model,left\grossly"non{deterministi.
Thosetraderwhoinitiatetransationstowardsothjertradersanbeviewd
as\lients", while those others are seenas\servers". Thus it is that we see
that\lients"areharaterisablebyinternalnon{determinism,while\servers"
areharaterisablebyexternalnon{determinism.
Itisnowataskforrequirementstodeterminetheextentofnon{determinisms
andthemorepreiser^olesof`lients'and`servers'.
11.3.3 Analyti Douments
We remind the reader that this main setion (Setion 11.3) of the urrent
paper is strutured and mostly presented in the form of atual development
douments: Theirsequene,interrelationsandontents.
Thereforeweshould,in thissetion bringanalytidouments. Spaeon-
siderationsmakethisimpossible. Insteadwebrieyommentastowhihkinds
ofdevelopmentstagesandsteps,andthustheirensuingdouments,wouldbe
neessaryfor a reasonablyprofessional phase of domain engineering to have
takenplae.
Validation
ParaphrasingBarry Boehm,[Boe81℄, for aprodutto be\the rightprodut"
wemustvalidatealsoitsdomainmodel.
11
The domain model has been \extrated" from all relevant stake{holders
of the domain: Owners, managers, workers, ustomers, regulatory agenies,
servieproviders(nanial institutions, logistisrms, et.) of \the market"
domain. Hene validation must be onduted with suh stake{holders. The
validation proessbasially \reads"theinformalterminologiesand narrative.
Heneitisutterlyimportantthattheyberelativelyompleteandonise.
Veriation
Again, paraphrasing Barry Boehm, [Boe81℄, for a \produt to be right" we
mustverifyimpliitlyexpressedpropertiesof adomainmodel.
12
11
Validationis\repeated", asweshallassumebelow,in\deriving"the produtrequire-
ments, and, fromrequirements,a, or the softwaredesign(s). Weshallnot oversoftware
designintheurrentpaper.
12
Veriationis\repeated"inallphasesofdevelopment(ie.,alsoforrequirementsdesign
andforsoftwaredesign):\Between"phases,stagesandstepsorretnessveriationisestab-
lished,and\within"stagesand/orsteps,impliitlyexpressed(ie.,derivativeor\assumed")
Theveriationproessis, in ontrastto thevalidation proess, basially
aformal one: Formallyexpressed prediates are laimed (ie., interpreted) to
represent\internal",respetivelyorretnessproperties. Thesearetheneither
provedormodelheked,aswellastheyortestedfor.
Towards TheoriesofMarketDomains
Just asphysiists keep studying \Mother Nature": The God{reated world,
so,undoubtedly we(or is it: us ?) mortals oughtstudy the man{reatedin-
frastrutureomponentssuhastransportation,logistis,\themarket",health
servies,et. The physiists keepomingupwith newdisoveries,sometimes
newlaws,sometimesfasinatingpropertiesthatfollowfromtheselaws,butare
hardtootherwiseasertain. Perhapswedomainengineersoulddisoverlaws,
properties,et., aboutthestudiedinfrastrutureomponents. Inotherwords:
Domainengineersshouldaim atestablishingtheoriesaboutthedomainsthey
model. Someofthesedomains,like\themarket",areabouttheowofpeople,
information,materials,andontrol.
11.3.4 Disussion
DomainFaets
In this short presentation of an example `development of a domain model'
wehavenotstruturedthat development,northe model, aswenormallydo.
Namelyaroundtheoneptsofdomainfaets: intrinsis,supporttehnologies,
management&organisation,rules®ulations,andhumanbehaviour.
Wendthat these \operators"that applyto theunanalyseddomain, and
whih, insequene,resultsinadomainmodel,arenovel.
Byintrinsis weunderstandtheverybasisofthestudieddomain. Whatis
basidependsonwhihstake{holderis\viewing"thedomain,what r^olethey
play.
The intrinsisof \the market" seemsto be (i) thenotions of traders and
theirinterationsequenes: Chainsaswellasprotools;and(ii)thenotionof
\inspetions"of,andupdatestoloaltraderstates.
Ourmodel,above,isbasiallyamodeloftheintrinsisfaetsof\themar-
ket". Wehaveonly representedthe views of onsumers, retailers,wholesaler
and produers. And we have, in fat, abstrated these in terms of traders.
Moreneedbedone.
Bysupport tehnologies weunderstandanytehnologythatsupportsa-
tivitiesin thedomain|asdistinguished(ie.,apart)fromthepeople faet|
whih wetreat separately (see below). Examples of support tehnologies for
telephone,faxes,ordinaryPC(inludingpossiblyordinaryE{Mail)and other
omputingforaounting,purhasing,personnel administration,et. Pls.ob-
servethat aslongas noE{Transationsupporthas been intriduedthat part
isnot(yet) asupportingtehnology. Itbeomespartofthedomain,andthen
has thefaet type `support tehnology' one it hasbeen installed and taken
intooperation.
Our model, above, abstrats from support tehnologies. Whenwemodel
thataonsumerdiretsaqueryataretailer,thenweabstrathowthatisdone.
Whetherbybeingpersonally,ie.,physially presentattheretailer'spremises,
orbyphoning,orfaxing,orsendinganE{Mail.
If wewere to model suh \ommuniation" failities, then we would also
haveto model their(un{)reliability, (in{)stability, et. That is: That,assup-
port tehnology theymay fail. Thatis: Wearenotmodelling howto ahieve
safetyorseurity,but thatsafetyorseuritymaybeompromisedbysupport
tehnologiesuponwhihweannotdepend. Modallogis,inludingtemporal
logis, in partiular those of the Duration Caluli [CH03℄, are presently our
favouriteformaltoolsin modellingsupporttehnologies.
By management& organisation weunderstandthewayinwhihdier-
ent stake{holderswithin an enterprise (ie., an infrastruture omponent) are
struturedand assumptionsaboutwhodoestakeswhih initiatives: Manager
$subordinate protools,et.
Inourmodel, above,wehavenotmodelledreal aspetsofmanagement&
organisation. Suhaspetsouldbe: Certainstainaretailermustapproveof
ertainquotes to onsumers;ertain staat awholesaler havetheobligation
to make sure that merhandise stores are kept \reasonably full", et. The
notionof agents and brokers, as well as the notionof learing house traders
forinformationabout\theplayers"in\themarket",thosenotionsalso,tous,
belongto themanagementandorganisationfaetof\themarket".
Byrules & regulations weunderstandtwokindsofstatements: Ruleslay
down guide{lines for humanbehaviour. Regulationsstipulate what remedial
ationsshould beinstituted shoulda rulebebroken. Thereare generalrules
andtherearerulespresribedbyspeistake{holders.
In our model, above, we havenot expressed any rules, letalone any reg-
ulations. So that remainsto be done. An exampleof a general ruleof \the
market" is: Thou shallpaythy bills! An example ofa spei ruleis: \We
give30daysredit". An exampleofaregulationould,in thisonnetion,be:
\If,upon thethird `Please pay'reminder youfail to do so,we shall invokea
debtolletingageny".
And by human behaviour wemeanwhat thenextsetionwill dealwith
\Inthe Domain AllisPossible"
Wehavepresentedsalientstagesofdevelopmentofadomainmodelfortrading
inthemarket.
Somereadersmaywelllaim: Well,havewereally\presentedsalientstages
ofdevelopmentofadomainmodelfortradinginthemarket"?
Those readers, typially, have expeted us to desribe \features" of \the
market"whihwewouldnowlaimarenotreallyproperlymanifestproperties
inthedomain. Weremindthereaderthat\inthedomainallispossible".
In the domain there are dilligent stake{holders: People who despath of
their work as expeted by others. But there are also sloppy stake{holders,
delinquent,yesoutrightriminalpeoplewhosetlowstandardsfortheirwork,
or,bydesign,desireriminal ondut. Andthedomain model must, insome
sense,model that.
We thus laim that the above model, to the extent that it really overs
transations, desribe suh a spetrum of behaviours. It does so by leaving
indeterminatewhetherproperlybeguntransationsequenes(frominquiryvia
quotationtoorder inganddelivery,et.) are atuallyproperlyonluded. And
itdoessobynotdetailinganyofthespeioperationsonthetraderstates.
11.4 E{Transation System Requirements
Fromnowon,in theurrentpaper,weshall bedisursive: Thereasonisrst
thattheoneptofdomainmaybewellunderstood,butthattheimportaneof
itspreiseinformalandformaldesriptionisfarfromsuÆientlyappreiated|
ertainlynottotheextentthatsoftwarelientsexpetsandsoftwaredevelopers
demandalear,suÆientlyextensivedomainmodel.
Weshallthereforeexaminethetransitionfromdomainsto requirements.
Wethuslaimthatinthepast,andstill,requirementsarebasiallyexprssed
withoutanytehniallysoundreferenetoanyformofdomainmodel.
Thus weneed to examinesuhnotions asneeds, goals,and requirements,
and,withinthese, ther^olesthat theoneptofdomain plays.
Alsoweobservethatpastandpresenttreatmentsoftheoneptofrequire-
ments have missed two, to us very important points: Namely, how might a
well{strutured set of requirementsbeformulaed; and what exatlyshould a
requirements doumentation ontain ? In muh of the urrent literature on
E{Market (et.) we ndthat very little, ifanythingis doneto really under-
stand\themarket",asadomain,andthatserious,ontemplativeonsideration
of orderly development of well{strutured requirements, asa onsequene, is
11.4.1 Needs, Goals and Requirements
\Inthebeginningtherewasthedomain!" Thenomputers&ommuniation
ame into being. Now needs 13
are \felt" for bringing about hanges whose
goal 14
it is (or whose goalsare) to ahieve ertain eets. \In theend there
is again the domain, but now with omputers, ommuniationand software
|suh that thesoftware satises requirements and, when used aordingto
assumptionsbeingmetbytheenvironment|atorsofthedomain|ahieve
thegoals,fulllstheneeds!"
In our example, \the market", examples of low{level needs may be: A
need for relieving humans from many hores of buying and selling, and/or
forsavingostson bureauratibusiness proessesin onnetion with hek-
inganddouble{hekingonorderdeliveries,invoiingandpayments,et.,has
been identied. A high{level need for a omputing system is settled upon
aordingly.
Commensuratewiththisidentiedhigh{levelneedsomegoalsfortheom-
puting systems are therefore enuniated: The omputing system shall help
bringaboutrelief,savings,et.
In Setion 11.2.1 we rst introdued the onept of `formulated needs'.
Therewelinked itto theformulation of`ideas' (by meansifwhih theneeds
ould possibly be implemented). Where do these `ideas' ome from ? Well,
thesimpleansweris: Thedomainandthepossible`mahine': Theomputing
systeminludingthedesiredsoftware! Fromwhereelse? Henedomainsand
softwareare\linked"byrequirements.
11.4.2 From Goals to Requirements
Goalsannot serve asa basisfor areasonably manageablesoftware develop-
ment: Theyare simply\toolofty",expressed,astheyare, intermsofhuman
sentiments, non{omputable soio|eonomi \values", et. So we need to
transliterate the goals into something that is omputable. It is this we all
requirements.
Requirementsare aset of statements, expressed in terms of someunder-
standingofwhatkindof,inoururrentexample,\amarketabstratmahine"
anbereatedinsidetheomputingsystem.
Thepurposeof requirementsisto express what themahine: Theombi-
nationofhardwareandsoftwarethat isdesired,shalloer.
Werefertothedisussion(\IntheDomainAllisPossible")presentedabove
(Setion11.3.4).
13
Need: (i)alakofsomethingrequisite,desirable,oruseful;(ii)aphysiologialorpsyho-
logialrequirementforthewell-beingofanorganism;(iii)aonditionrequiringsupplyorrelief,
(iv)lakofthemeansofsubsistene. Merriam{WebsterOn{Line: http://www.m-w.om/gi-
bin/ditionary
14
Goal: the end toward whih eort is direted. Merriam{Webster On{Line:
Theundesirable indeterminaiesof \themarket"maynowbe\remedied"
throughomputing &ommuniationssupport, orevenautomation. That is:
Thepurposeoftherequirementsengineeringphaseofomputingsystems(um
software)developmentistoensureproperbehavioursof\market"stake{holders
aswellasofitssupportingtehnology.
A set of requirements amount to a set of logial statements of the form:
\Providedtheenvironmentof(1) stake{holders,(2) support tehnology", (3)
managementandorganisation,behaveaslaiddownin thedomainmodel,and
provided that the (4) rules ®ulations areonsistent (...), then aorret
implementation of these requirementswill leadto adesirable omputingsys-
tem. Failuresin ahievinggoodsoftwareoftentimesanbeblamed notonthe
requirements themselves, nor on their maybe not soorret implementation,
butanratherbeblamedontheassumptions(1{4)notholding. Itistherefore
ofutmostimportanetoseurethat domainmodellinghavelaidbareallsuh
possibleassumptions.
11.4.3 The Three Dimensions of Requirements
We distinguish between three kinds of requirements: Domain, interfae and
mahinerequirements.
DomainRequirements
Domainrequirementsaresuhwhihanbeexpresseds^olelybyusingtehnial
termsfrom thedomain. Belowweshalldisusssomepriniplesfor\deriving"
domainrequirementsfrom domain models. Sine dierent stake{holdersmay
giverise to dierent domain requirements, these need be onsolidated: They
mustbeonsistentandtogetherformarelativeompletesetofrequirements.
If two dierent providers of domain requirements from within the same
stake{holder group give rise to mutually inonsistent requirements, then we
haveaninonsisteny thatmustberesolvedwithinthepertinentstake{holder
group. If two providers of domain requirements from dierent stake{holder
groupsgiverisetomutuallyinonsistentrequirements,thenwehaveaonit
thatmustberesolvedatmanage,mentlevel.
Domainrequirements(aka.`funtionalrequirements')anthereforeonlybe
expressed(ie., written) using domainterms. Theserequirementsanonlybe
undersood,byaasualreader,ifthatpersonhasrst(readand)understoodthe
domain(desription). Thusitisthatwesay: Expressingdomainrequirements
islikestatinghowationsandevents,that is: Behaviours,anbeeeted by
anabstratmahine,andthat abstratmahineis aomputablepartof \the
domain". Domaindesriptionsmaybeonernedalso withfuntionsthat are
notomputable,butrequirementsneessarilyhavetodealwith omputation,
Interfae Requirements
Interfaerequirementsaresuhwhih fousonthesharedphenomena: Those
forwhihweandesignateanentity,oranevent,orotherinthedomainwhih
isalso,somehow,representedwithin themahine. Interfaerequirementsthus
dealwith theinterfaebetweenthemahineand itsenvironment: Thestake{
holdersandthesupportingtehnologies.
Thusinterfaerequirementsfousontheso{alleduserinterfae(tostake-
{holders),aswellas theonnetions betweenthemahine andthesupporting
tehnologies.
ExamplesofE{TransationuserinterfaesarebasiallythoseoftheGraphi
UserInterfaes(GUIs) and the userdialogues, Other examplesare the mass
inputofforexampleatalogues,andrulesandregulations(ifenforedthrough
omputing).
Weshallnotdealfurtherwithinterfaerequirements.
The\abstratmahine"ofinterfaerequirementsisthusomposedofphe-
nomenawhih belong both in the\abstrat mahine"of the domainand the
\abstratmahine"ofthedesiredomputingsystem|whih,inamorenarrow
sene,nownotusingdoublequotationmarks,weallthemahine.
Mahine Requirements
Mahinerequirementsaresuhwhihanbeexpresseds^olelybyusingtehnial
terms of the desired omputing system itself: Abstrat mahine properties
of the appliation software to be developed as well as of the platform (the
hardwareandsupportingsystemssoftware)uponwhoseserviestheappliation
softwaredepends.
Examplesofmahinerequirementsaresuhwhihdealwithtimeandspae
performane, dependabilities (suh a the reliability, fault tolerane, seurity,
safety, availability, aessability, et., \ilities". No referene is made to any
spei domain onepts when stating mahine requirements, only at an ab-
stratlevel: Thefollowingoperationsmustexeutewithinsuhandsuhtime-
{bounds: ...,et.
Weshallnotdealfurtherwithmahine requirements.
11.4.4 Domain Requirements Development
When establishing domain requirements the requirements engineer is well{
adviedin struturing the requirementsmodelling proess and in presenting
therequirementsmodelsalongthelinesgivennext: Projetion,determination,
instantiation,extension, ttingand initialisation.
We nd that these \operators" that apply to domain requirements, and
Projetion
Inprojetionwestartwithadomaindesription. usuallywitharatherenom-
passingone. Fromthat we\ut down"to fous onlyon thoseaspetsof the
domain with whih the remaining requirementsare to be onerned. We go,
so{to{speak,from thesopeto thespanoftheproblemto besolved|using
oneptslearlyenuniatedbyMihaelJakson[Ja95℄.
Inourexampleof\themarket",wemighthavedesribedandmodelledhow
realagentsand realbrokersbehave. Butwemightsettle onanE{Transation
System that does not extend to agents and brokers. Thus we ut that part
of the domain desription out: It is no longer part of the requirements. It
maystillbepartoftheenvironmentinwhihthedesiredomputingsystemsis
toperform,and henetheassumptionslaid downin thedomainmodelabout
agent or brokertraders are still valid | and may have to be referred to in
reasoningabouttheorretnessofsomeE{TransationSystemfuntions.
Wedonotshow`formalprojetion'in theurrentpaper.
Removing Undesirable Non{Determinay
Usually\thedomainiskle": Humanbehaviouraswellasthatofsupporting
tehnologies. Desiredomputingsupport,orevenautomation,normallywishes
toavoidanumberofin{determinaies.
Onepurpose ofrequirements,amongstothers, is todetermine whatis in{
determinateinthedomain: Torenderhumanbehaviourpreditable,toguard
againstsloppy,delinquent,evenriminalations,et.
Inourdomainmodelof\themarket"weleftopenverymanypossibilitiesof
market transations: (i)Inquirieswere notguaranteedto bealwaysfollowed{
upbyquotations, (ii)aknowledged orders were notguaranteedto bealways
followed{upbydeliverriesandinvoies,(iii)invoieswerenotguaranteedtobe
alwaysfollowed{upbypayments,etetera. With omputing&ommuniation
muhof thisanbe\followed{up"morestrigently.
Thus requirements an be expressed that \removes" unertainties. In{
determinatebehavioursanbemadeintodeterminatetransationprotools.
Arequirementsmodelanthusbederivedfromtheprojetedmodel,onein
whihtheinternalnon{deterministihoieshavebeenreplaedbydeterminate
ones.
Wedonotshow`formaldetermination'intheurrentpaper.
Extension
With omputing &ommuniation ertainfuntions arepossible |funtion
that it was simply not feasible to do, in the domain, without for example
omputers. Brokering \aross" any number of levels of wholesalers et. is
(purhases)begivernedbyoneoranotherformofauxtioningisnowfeasible|
butwasbasiallyunthinkableofinsupporttehnology{weakdomains. Making
morevisibleompletesupplyhainssothatall\players"aremademoreaware
ofwhatisgoingon,\towardsanopen[market℄soiety,"isalsonowpossible.
All are examples of extensions: Of the domain but only made believable
throughomputing.
Aspeialformofextensionwill bementionednext.
Government,Businesses,and Citizens: TraditionallywehaveviewedE{
Transationsassomethingonlyinvolvingonsumersand retailers. Then \ex-
tensions"weremade tothe traditionalC2B paradigm. Ingeneralany \dire-
tionofrstinitiative" isworthonsidering. Simpleredenitions ofinquieries,
quotes,orders,deliveries,et.,an bereadilyput forward.
Figure11.7: TheGovernmentBusinessCitizen\MarketTriangle"
Enterprises (E) Citizens (C)
Institutions (G) Government
Offer Consume Offer
Consume
Consume Offer Offer
Consume
Offer Offer
Consume Consume
G2G: Speedingupinternal, loal and/orstate governmenttransations,
onebranhoggovernmentbuying serviesfrom anotherbranh,et.
G2B: Government serviing business better: Governmentbuying taxes
frombusiness inreturnforguaranteeringstableeonomies,et.
G2C: Governmentbuying taxesfromitizens inreturnforoeringsoial
welfare,publieduation,et.
B2G: Businesses buying for example areditation orertiation from
governmentpayingwithrealmonies.
B2B: Yes,Yougues what!
C2C: Enablinggrass{rootmovements,andwhatnot.
C2B: Citizens sellingtheirskillsto businesses.
AndC2G: Citizensoeringtheirvotestoloalandstatepolitiians.
Disussion
Intheurrentpaperwearenotoveringsuhotherdomainrequirementsteh-
niquesasinstantiation,tting,andinitialisation.
The disussion of the Government Business Citizen \Market Triangle" is
ratherindiative. Ithintsat,but doesnotreallysubstantiatespei require-
ments. WehopethatthehintsaresuÆienttojustifythelaim,thatonlywhen
wehavereasonablyonise domain models, suhasthe formalmodel ofSe-
tion11.3|thatonlythen|anwehopetoonqueranemergingompleity
of\FullsaleE{TransationSystems".
11.4.5 Disussion
We have overed someissues of requirements development based on domain
models. May other requirements issues have not been overed, but are, of
ourse, equallyrelevant: The proesses, astheywere fordomain aquisition,
for eleiting requirements; the issues of disivering inonsistenies, onits,
andunwantedinompleteness.
Sine E{Transation Systems typially involve many more, and in many
ases, new kindsof, stake{holdergroups than are usually enountered in re-
quirementsaquisition,speialareneedbetaken|andalsowrt.validation.
11.5 Conlusion
Itistimetoonlude. Wedoso,but onlypartially,andinthreeparts.
11.5.1 Summary: What has been Ahieved ?
Two\ahievements"standout: Oneismethodologial,theotherisinstantial.
Methdologially wehave surveyedtwo major phases of omputing, no-
tably software systems development: Domain desription and requirements
presription. Welaimthat ourapproahto domainmodelling: Detailed,and
bothinformalnarrationandformalisedmodels,isnovel. Welaim,further,but
donot show tehnial onsequenesof the laim, that the speial tehniques
for domain faet modelling: Intrinsis, support tehnologies, management &
organisation,rules®ulations,andhumanbehaviour arenew. Likewisewe
laimthat thespeial tehniquesfor domain requiremensmodelling: Proje-
itexpliitly,itisthepossibilityofstrong,formalrelationsbetweendomainde-
sriptionsandrequirementspresriptionsthat isnovel.
These (emphasized)tehniqueshavethenbeenexemplied onaninstane
of a domain model: That of\The Market". Wehaveyetto see suh lear
models of \the market" being even related to in the expandingliterature on
E{Business(et.).
11.5.2 InsuÆeny of Current Modelling Tehniques
Wewillonlypointout,in thissetion,that thenotionsofagentsandbrokers
asrstintroduedwasoneof\themarket". Infurtherspeifyingthosekindsof
agentsandbrokerswerstndthataneedforformalisedmodallogioriented
[Che80,Pop94,CZ97,Kra99,BdRV01℄speiationlanguagesarise,languages
in whih wean then desribe,respetivelypresribehowagentsandbrokers
behave\intherealdomain",respetivelyhowwemightrequirethem tooer
theirservies. We then extendthat need to also inlude possibilities of pro-
vidingimplementedtrader agentsand brokers,ie.autonomous agents (asthe
termisused nowintheAIliterature)withspeehat apabilities[Pet02℄.
11.5.3 Who Should be doing Domain Engineering ?
Isitreallytheideathatomputingsientistumsoftwareengineersumknowl-
edgeengineers should betheones who reatedomain models ? Well, forthe
time being, yes ! In ollaboration | as wasalwaysassumed above | with
domain stake{holders. But weforesee that gradually professionals of respe-
tive domainswill havelearnedbasitehniques of abstration and modelling
aspart of their domain spei aademieduation, but in ourses that ba-
siallypropagateomputing siene onepts and tehniques. And graudally
theywill takeovertheontinued modelling oftheir domain. Just like physi-
ists, after enturies of studying \Mother Nature", still study that domain,
intensely, sowe expet the man{made domains to be studied for as longas
mansustainthese domains. And: Justasmostsiene{based disiplines: Bi-
ology, eonomy, mehanialengineering, et., now\feature" asigniantown
(applied)mathematisstudy,soitisthatweforeseethataademisaswellas
professional pratitionerswithin the kindof infrastruture omponents listed
earlier (transport, health{are, et.) will feature their own, domain{spei,
ie.,appliedomputingsienestudiesandpraties.
11.5.4 Aknowledgements
Disussions and serious work with olleagues, espeially at UNU/IIST, the
UNUniversity'sInternationalInstitute forSoftwareTehnology,Maau,SAR
China,andespeiallyMessrsChrisGeorgeandSrenPrehn,ismuh apprei-
11.6 Bibliographial Notes
We apologize for the rather extensive set of referenes to own publiations.
Wejustifythis bythepereivedneedtosupport laimsmadebyreferenesto
supportingandsubstantiatingliterature.
Referenes
[BdRV01℄ PatrikBlakburn,MaartendeRijke,andYdeVenema.ModalLogi.Number53.
CambridgeUniversityPress,June282001. 554pages.
[BGP99℄ Dines Bjrner, C.W. George, and S. Prehn. Sheduling and Resheduling of
Trains,hapter8,pages157{184. IndustrialStrengthFormalMethodsinPra-
tie,Eds.:MihaelG.HinheyandJonathanP.Bowen.FACIT,Springer{Verlag,
London,England,1999.
15
.
[Bj94℄ DinesBjrner. Prospetsfora ViableSoftwareIndustry |EnterpriseModels,
DesignCaluli,andReusableModules.InFirstACMJapanChapterConferene,
Singapore,Marh 7{91994. World Sienti Publ. Appendix inollaboration
withSrenPrehnandDongYulin.
[Bj95℄ DinesBjrner.SoftwareSupportforInfrastrutureSystems.TehnialReport47,
UNU/IIST,P.O.Box3058, Maau,November1995. Position statement forthe
FirstMalaysiaInformationTehnologyDays: 1{3November1995.
[Bj96℄ DinesBjrner.NewSoftwareDevelopment.Administrative/TehnialReport59,
UNU/IIST,P.O.Box3058,Maau,January1996.SpeialThemepaper:NewSoft-
wareTehnologyDevelopment.InternationalSymposium: NewITAppliations
forGovernaneandPubliAdministration,UNDDSMS,Beijing,June1996.
[Bj98℄ DinesBjrner.FISH:AFisheriesInfrastruture|Hardware/SoftwareConept.
Tehnialreport,InformatisandMathematialModelling,TehnialUniversity
of Denmark,DK{2800 Kgs.Lyngby,Denmark, 1998. hisdoumentprovidesa
basisforanM.S.ThesisprojetarriedoutbyAudurThorunRognvaldsdottir,
Sept.1998|Aug.1999.
[Bj99a℄ DinesBjrner. ATriptyhSoftwareDevelopmentParadigm: Domain,Require-
mentsandSoftware.TowardsaModelDevelopmentofADeisionSupportSys-
temforSustainableDevelopment. InErnstRudigerOlderog,editor,Festshrift
toHans Langmaak.UniversityofKiel,Germany,Otober1999.
16
.
[Bj99b℄ DinesBjrner. ProjetInformation,MonitoringandControlSystems|ADo-
mainAnalysis.Tehnialreport,InformatisandMathematialModelling,Build-
ing322, Rihard PetersensPlads, Tehnial Universityof Denmark, DK{2800
Kgs.Lyngby,Denmark,1999.
[Bj00a℄ Dines Bjrner. Domain Modelling: ResoureManagementStrategis, Tatis
&Operations,DeisionSupportandAlgorithmiSoftware. InJimDavies,Bill
Rosoe,andJimWoodok,editors,MillenialPerspetivesinComputerSiene,
Cornerstones of Computing (Ed.: Rihard Bird and Tony Hoare), pages 23{
40, Houndmills, Basingstoke, Hampshire,RG216XS, UK, 2000.Palgrave(St.
Martin'sPress). AnOxfordUniversityand MirosoftSymposiuminHonourof
SirAnthonyHoare,September13{14,1999.
17
.
15
PostsriptdoumentatURL:http://www.it.dtu.dk/db/raosy/sheduling.ps
16
PostsriptdoumentatURL:http://www.imm.dtu.dk/db/langmaak/hans.ps
17
