CPN Models as Enhancements to a Traditional Software

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 1

Problem: design of an elevator controller z Subject domain y. Ten floors y. Two cages y. Buttons, doors, sensors, … z Controller responsibilities y. Control movement of cages y. Display information 2

Wieringa’s specification: desired functionality z Mission statement, function refinement tree, service descriptions z Partial context diagram z Also dictionary and descriptions of entities in subject domain 3

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

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

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 - Up. Down and Indicators 6

CPN model: requirements-level architecture z Representation of controller y. Processes ~ Standard ML functions y. Data stores ~ tokens z Representation of subject domain y. Entities ~ tokens z Communications y. Possible internal communications in system ~ transitions y. Possible communications between controller and entities in environment ~ transitions 7

CPN model: basis for system engineering argument z Argue that specification and domain properties together entail requirements z Prerequisites for argument y. CPN model executable y. CPN model coherent z Example requirement: Collect passengers y. Trigger: Passenger pushes floor button F y. Delivered service: Controller ensures that cage stops at floor F and allows passengers to enter 8

Some perspectives on CPN in software engineering z Compliance with Jackson’s basic tenets y. Distinguish the machine from the problem domain y. Don’t restrict description to the machine y. State explicitly what is described z Advantages compared with statecharts y. CPN adequate to address scheduling y. CPN conveniently describe two cages together y. CPN facilitate prototyping and experiments 9

Conclusions and discussion z Advantages of adding CPN model y. Can be used as requirements-level architecture y. Facilitates system engineering argument z Cost-benefit issues of adding CPN model y. Gap between model and implementation y. Can existing specification be improved with simpler means? z Formal verification viable? y. Improve quality of system engineering argument y. Argue about more advanced behavioural properties y. Scalability problems 10