1 CPN Models as Enhancements to a Traditional Software Specification for an Elevator Controller Jens Bæk Jørgensen Department of Computer Science University of Aarhus Denmark MOCA’04, Aarhus, October 2004

2 Problem: design of an elevator controller zSubject domain yTen floors yTwo cages yButtons, doors, sensors, … zController responsibilities yControl movement of cages yDisplay information

3 Wieringa’s specification: desired functionality zMission statement, function refinement tree, service descriptions zPartial context diagram zAlso dictionary and descriptions of entities in subject domain

4 Wieringa’s specification: desired behaviour of cage movement Also descriptions of desired behaviour of allocation of request to cages, location indication, etc.

5 CPN model: representation of controller specification zSet of Standard ML functions ysetdirection ystophere yturnidle yservenow yresetdirection yaddrequest yremoverequest yupdatelocationindicators

6 CPN model: desired behaviour of subject domain Entities in subject domain represented as tokens – cages as (cageid,floor,requestlist, direction) Three net modules: - Basic Cage Movement - Requests and Allocations - UpDown and Indicators

7 CPN model: requirements-level architecture zRepresentation of controller yProcesses ~ Standard ML functions yData stores ~ tokens zRepresentation of subject domain yEntities ~ tokens zCommunications yPossible internal communications in system ~ transitions yPossible communications between controller and entities in environment ~ transitions

8 CPN model: basis for system engineering argument zArgue that specification and domain properties together entail requirements zPrerequisites for argument yCPN model executable yCPN model coherent zExample requirement: Collect passengers yTrigger: Passenger pushes floor button F yDelivered service: Controller ensures that cage stops at floor F and allows passengers to enter

9 Some perspectives on CPN in software engineering zCompliance with Jackson’s basic tenets yDistinguish the machine from the problem domain yDon’t restrict description to the machine yState explicitly what is described zAdvantages compared with statecharts yCPN adequate to address scheduling yCPN conveniently describe two cages together yCPN facilitate prototyping and experiments

10 Conclusions and discussion zAdvantages of adding CPN model yCan be used as requirements-level architecture yFacilitates system engineering argument zCost-benefit issues of adding CPN model yGap between model and implementation yCan existing specification be improved with simpler means? zFormal verification viable? yImprove quality of system engineering argument yArgue about more advanced behavioural properties yScalability problems