Present and Ulterior Software Engineering

225 Pages·2017·4.48 MB·English

by  Manuel Mazzara, Bertrand Meyer

Manuel Mazzara
Bertrand Meyer Editors
Present and
Ulterior
Software
Engineering
Present and Ulterior Software Engineering
Manuel Mazzara • Bertrand Meyer
Editors
Present and
Ulterior
Software
Engineering
123
Editors
ManuelMazzara BertrandMeyer
InnopolisUniversity ChairofSoftwareEngineering
Innopolis,Russia ETHZuRrich
ZuRrich,Switzerland
ISBN978-3-319-67424-7 ISBN978-3-319-67425-4 (eBook)
https://doi.org/10.1007/978-3-319-67425-4
LibraryofCongressControlNumber:2017955568
©SpringerInternationalPublishingAG2017
Thisworkissubjecttocopyright.AllrightsarereservedbythePublisher,whetherthewholeorpartof
thematerialisconcerned,specificallytherightsoftranslation,reprinting,reuseofillustrations,recitation,
broadcasting,reproductiononmicrofilmsorinanyotherphysicalway,andtransmissionorinformation
storageandretrieval,electronicadaptation,computersoftware,orbysimilarordissimilarmethodology
nowknownorhereafterdeveloped.
Theuseofgeneraldescriptivenames,registerednames,trademarks,servicemarks,etc.inthispublication
doesnotimply,evenintheabsenceofaspecificstatement,thatsuchnamesareexemptfromtherelevant
protectivelawsandregulationsandthereforefreeforgeneraluse.
Thepublisher,theauthorsandtheeditorsaresafetoassumethattheadviceandinformationinthisbook
arebelievedtobetrueandaccurateatthedateofpublication.Neitherthepublishernortheauthorsor
theeditorsgiveawarranty,expressorimplied,withrespecttothematerialcontainedhereinorforany
errorsoromissionsthatmayhavebeenmade.Thepublisherremainsneutralwithregardtojurisdictional
claimsinpublishedmapsandinstitutionalaffiliations.
Printedonacid-freepaper
ThisSpringerimprintispublishedbySpringerNature
TheregisteredcompanyisSpringerInternationalPublishingAG
Theregisteredcompanyaddressis:Gewerbestrasse11,6330Cham,Switzerland
Preface
ThePAUSEsymposiumtookplacefromthe16thtothe19thofDecember2015.It
wasthefirstscientificeventintheelegantChâteauofVillebrumier,intheSouthwest
of France, newly equippedto serve as a conferencecenter for technicalmeetings,
withaparticularfocusoninformationtechnology.
TheaimofPAUSEwastomarkthecompletionof14yearsofworkattheChair
ofSoftwareEngineeringatETHZurich.Theparticipantswereformermembersof
the Chair andcolleaguesfromeverypartofthe worldwho hadthe opportunityto
collaboratewithitovertheyears.
Inthisinspiringcontext,extensivediscussionsaboutthepast,present,andfuture
of software engineering took place between some of the best minds in the field.
This volume includes some of the presentationsgiven at Villebrumier, edited and
extendedintofullchapters.
Thecontentofthisvolumecanbeconsideredaneffectivesynthesisofthecurrent
state of the art in software engineering with a projection into the future of the
discipline.
Innopolis,Russia ManuelMazzara
Zürich,Switzerland BertrandMeyer
28April2017
v
Contents
EngineeringbySoftware:SystemBehavioursasComponents ............. 1
MichaelJackson
WhatIsaProcedure?............................................................ 19
EricC.R.Hehner
TheEvolutionandEcosystemoftheUnifiedModelingLanguage ......... 37
ClaudeR.Baudoin
A Theory of Networking and Its Contributions to Software
Engineering ...................................................................... 47
PamelaZave
OnLanguageInterfaces......................................................... 65
ThomasDegueule,BenoitCombemale,andJean-MarcJézéquel
MoldableToolsforObject-OrientedDevelopment........................... 77
Andrei Chis¸, Tudor Gîrba, Juraj Kubelka, Oscar Nierstrasz,
StefanReichhart,andAliakseiSyrel
TheChangingFaceofModel-DrivenEngineering........................... 103
RichardF.Paige,AthanasiosZolotas,andDimitrisKolovos
BorealisBoundedModelChecker:TheComingofAgeStory.............. 119
MaratAkhin,MikhailBelyaev,andVladimirItsykson
HowtoMakeVisualModelingMoreAttractivetoSoftware
Developers ........................................................................ 139
AndreyTerekhov,TimofeyBryksin,andYuriiLitvinov
IntrinsicRedundancyforReliabilityandBeyond............................ 153
AlbertoGoffi,AlessandraGorla,AndreaMattavelli,andMauroPezzè
SoundSimulationandCo-simulationforRobotics........................... 173
AnaCavalcanti,AlvaroMiyazawa,RichardPayne,andJimWoodcock
vii
viii Contents
Microservices:Yesterday,Today,andTomorrow ............................ 195
Nicola Dragoni, Saverio Giallorenzo, Alberto Lluch Lafuente,
ManuelMazzara,FabrizioMontesi,RuslanMustafin,andLarisaSafina
Microservices:ALanguage-BasedApproach................................. 217
ClaudioGuidi,IvanLanese,ManuelMazzara,andFabrizioMontesi
Engineering by Software: System Behaviours
as Components
MichaelJackson
Abstract Software engineering means developing software for a purpose. For
systems that interact with a physical problem world, the proximate purpose is
a desired behaviour of that problem world: the fundamental engineering task
is to develop the system behaviour and specify the software that will evoke it.
This chapter sketches a discipline for this task, in which behaviours are always
understood as the result of interactions of a software machine and a physical
problem world. Complex behaviour is designed in terms of simple constituent
behaviours.Therunningbehaviourinstancesformadynamictreeinwhichcontrol
ofthetreeisexercisedbythesoftwaremachinesatthenodes.
Some salient concepts, principles, practices and concerns of this discipline are
discussed. After an introductory section, the development of a simple behaviour
is clarified, and the iterative relationship between behaviour and requirements is
illustrated. Requirements state the benefits expected from the system behaviour.
Anabstractgoalbehaviourisproposed,intendedtosatisfytherequirements.After
elaborationintoaconcretebehaviourofthephysicalproblemworld,itisagaineval-
uatedagainsttherequirements.Thenatureanddevelopmentofcomplexbehaviour
is discussed. Development is partly top-down and partly bottom-up: top-down
developmentdecomposesawell-understoodfunctionintosubfunctions;bottom-up
development combines disparate functions springing from distinct requirements.
In both, the identification and design of constituent behaviours is distinguished
fromtheircombinationintoacomplexwhole.Thechapterendswithsomegeneral
observationsontheprinciplesembodiedintheapproachdescribed.
1 Introduction
1.1 Two Faces of SoftwareEngineering
Wedistinguishtheengineeringof softwarefromengineeringbysoftware.Thefirst
looksinwardat the computer,inventing,structuring,elaboratingand transforming
M.Jackson((cid:2))
TheOpenUniversity,MiltonKeynes,UK
e-mail:[email protected]
©SpringerInternationalPublishingAG2017 1
M.Mazzara,B.Meyer(eds.),PresentandUlteriorSoftwareEngineering,
https://doi.org/10.1007/978-3-319-67425-4_1
2 M.Jackson
programsforefficientexecutionandcorrectcomputation.Thesecondlooksoutward
attheproblemworldwithwhichthecomputerinteracts,specifyingsoftwarewhose
executionwillproducedesiredbehavioursinthatworld.
If the problem—for example, factorising a large integer or solving a set of
equations—is located in an abstract and timeless world, then engineering by
softwaremakeslittlesense:inatimelessworld,thecomputercanproducenoeffects
andevokenobehaviour.Bycontrast,theworldofaphysicalproblemcanbeaffected
and even controlled. Achieving the desired effects and control is an engineering
problem:ifitcanbesolvedbyintroducinganappropriatelyprogrammedcomputer
into the world, it becomes a problem of engineering by software. This chapter
is concerned with problems of this kind. More specifically, it is concerned with
the developmentof embedded or cyber-physical systems. These systems have the
potentialtobringdramaticbenefitstosociety,butitwillnotbe possibleto realise
those benefits—especiallyin critical applications—unlesssoftware becomesmore
dependable[1].
1.2 TheSystem andtheProject
Forembeddedorcyber-physicalsoftware,thesystemcomprisesboththesoftware
andtheproblemworld—thosepartsofthenatural,engineeredandhumanphysical
world—whosebehaviouritmustcontrol.
The most important requirements are desired properties and effects of this
behaviour. It is a common mistake to identify the requirements with the system
behaviouritself. The behaviouritself is the productof a design activity, while the
requirementsshouldidentifythebenefitsthatthebehaviourmustbring.Abehaviour
cannotbespecifiedexactlybyenumeratingitsintendedbenefits,becausethesame
setofbenefitscanbeprovidedbydifferentsystembehaviours.Someorganisations,
aimingtostatetheirrequirementsexactly,trytocastthemintheformofstimulus-
response pairs, describing the software’s required response to each of the myriad
eventsthatmayhappenintheproblemworld.Onecompanyproudlyannouncedat
arequirementsworkshopthatacertainproductlinehad200,000requirements.Such
anapproachfailsonbothscores:itneitherspecifiesthebehaviourexactly—oreven
consistently—norcapturesitsintendedbenefitsexplicitly.
Weidentifytheseconceptualpartsofadevelopmentproblem:
(cid:129) Themachine:thepartofthesystemexecutingthesoftware
(cid:129) Theproblemworld:thephysicalworldmonitoredandcontrolledbythemachine
(cid:129) The system behaviour: the behaviour of the problem world resulting from its
interactionwiththesoftware
(cid:129) The requirements: the benefits that the system behaviour must provide—some
directlyobservableintheproblemworldandothersduetomoreremoteeffects
andconsequencesofthebehaviour
EngineeringbySoftware:SystemBehavioursasComponents 3
Wealsoidentifythesetworolesinadevelopmentproject:
(cid:129) Thestakeholders:thepeopleandorganisationswhohavelegitimateinterestsin
thesystemandaproperexpectationthatitwillsatisfytheirneedsandpurposes
asexpressedintherequirements;somestakeholdersmaythemselvesparticipate
inthesystembehaviour.
(cid:129) The developers: the software engineers who will design the system behaviour,
specifyingthesoftwarethatwillevokeit, andworkingwiththestakeholdersto
validatethebehaviour—thatis,toconfirmthattheirexpectationswillbesatisfied.
These rolesare merelyconceptual:thestakeholdershaveneeds;thedevelopers
designthe system to satisfy them.In practice,the rolesmay overlap,they maybe
structuredintomanyspecialisms,andthesamepersonmayplaymorethanonerole.
2 SimpleBehaviour
2.1 A SimpleSystem:ZooVisitor Control
Realistic systems have complex behaviours. Complex behaviour emerges from a
combination of simple behaviours and the interactions among them. To address
complexity, one must have a clear understanding of simplicity. So we begin here
withaverysimplesystemwhosepurposeistocontrolvisitorentrytoasmallzoo.
ThesystemcanbedepictedinaschematicdiagraminFig.1.
Thestripedboxrepresentsthemachine.Theotherboxesrepresentthe problem
domains of the problem world. These are the identified relevant components in
which the system behaviour will be evoked: the Coin Acceptor, the Barrier, the
StopButton,theManagerandtheVisitors.Thelabelledconnectinglinesrepresent
interfaces of shared phenomena between system components: at interfaces e and
f, the Visitors can operate the Coin Acceptor and the Barrier; at interface d, the
ManagercanoperatetheStopButton;atinterfacesa,bandc,themachineinteracts
withtheStopButton,CoinAcceptorandBarrier.
Fig.1 Asimplesystem