1 Specification of IT Systems – Introduction

2 Book and web pages zIn the course we use the following litterature: yDesign Methods for Reactive Systems – Yourdon, Statemate, and the UML yR.J. Wieringa yMorgan Kaufmann, 2003 zCourse web page yhttp://

3 Lectures and exercises zLectures and exercises yThuesday 8-12 y Codd-S except for today… zFirst lectures, then exercises…

4 Mandatory excersises and exam zMandatory excersises yWeb... zExam yWeb...

5 Lectures zLectures yJens Bæk Jørgensen ySøren Christensen yKristian Bisgaard Lassen

6 Purpose and Contents zPurpose: yThe purpose of this course is to strengthen the students knowledge of conceptual modeling and system specification. zContents: yThe student will learn skills to build data models, data flow models and behavioral models. The course describe how these techniques is combined. The course emphasizes not just to describe the IT system from a technical point of view, but also to describe the environment where the given system is to be used. The course walks through techniques is method independent, but different concrete methods and notations is uses such as UML. yThe course focuses on making specification of systems and to a lesser extend how these specifications is realized in an implementation.

7 Part I: Reactive system design – contents zChapter 1: Reactive systems zChapter 2: The environment zChapter 3: Stimulus-response behaviour zChapter 4: Software specifications

8 Reactive systems – first characterisation zTwo main classes of systems yTransformational systems yReactive systems zReactive systems respond to stimuli in order to bring about desirable effects in their environments zReactive systems may yManipulate complex data yEngage in complex behavior yCommunicate with (many) other systems

9 Reactive systems – training information system example zPurpose yCoordinate monthly training courses for new employees of large company zCharacteristics yInteractive yNonterminating yState-dependent response yEnvironment-oriented response yParallel processing

10 Reactive systems – elevator controller example zPurpose yControl the movement of two elevator cages in a 10 floor building; update location and direction indicators zCharacteristics yInteractive yNonterminating yState-dependent response yEnvironment-oriented response yParallel processing yReal-time

11 Reactive systems – definition and examples (Wieringa) zA reactive system is a system that, when switched on, is able to create desired effects in its environment by enabling, enforcing or preventing events in the environment. zCharacteristics yInteractive yNonterminating yInterrupt-driven yState-dependent response yEnvironment-oriented response yParallel processing yReal-time zExamples yInformation systems, workflow systems, groupware, EDI systems, web market places, production control software, embedded software

12 The environment – training information system example

13 The environment – message exchange zEnvironment and system exchange messages zEach message has yA subject (people, devices, conceptual entities, lexical entities,...) yA function, which x informs the environment, x directs the environment, or x manipulates lexical items yA connection, which is xa path from sender to receiver that may delay, distort, or loose the message

14 The environment – subject domain zSubject domain of a reactive system yConsists of entities and events ySet of all subjects of all its input and output messages yThe part of the world talked about by the messages that cross the system interface zCategories of entities yPhysical entities yConceptual entities yLexical items

15 The environment – example of subject domain (with physical, conceptual, and lexical entities)

16 The environment – example of connection domain (and subject domain)

17 The environment – example of system directly connected to subject domain

18 Stimulus-response behaviour – training information system example Assumptions -Registration desk reliable -Employee is indeed a joiner

19 Stimulus-response behaviour – heating controller example Assumptions?

20 Stimulus-response behaviour – in general Event types -Named external event -Condition change event -Temporal event

21 Stimulus-response behaviour – assumptions zAssumptions are statements about the environment yMust be true for the (stimulus, response) pair to be desirable yBeyond control of SuD zExamples of categories of assumptions yLaws of nature yProperties of devices yProperties of people (users, operators, …)

22 Stimulus-response behaviour – event recognition and response computation - Observer makes event recognition - Actor makes response computation

23 Stimulus-response behaviour – example of assumptions about observers zEvents of interest: beginning of plate arrives, end of plate arrives zAvailable stimuli: on, off zNecessary assumptions: yThe photo-electric cell is functioning properly. yThe cell is stimulated only by the arrival of the beginning or end of a metal plate zEvent recognition?

24 Software specifications – basic concepts and terminology zDesign decision yAny creative decision about a system zSpecification yDescription of design decisions zA reactive system specification must describe ythe place of the SuD in the system hierarchy yfunctions, behaviour and communication of the SuD yits composition zThe specification must be used to make a system engineering argument

25 Software specifications – system engineering argument for training information system zEmergent property (E): Department must be able to handle newcomers efficiently zSpecification (S): The training information system allows registration of unexpected participants zAssumption (A): The department has extra staff

26 Software specifications – system engineering argument for heating controller zEmergent property (E): Pasteurization unit heats batch according to recipe zSpecification (S): The heating controller controls heater according to batch recipe zAssumption (A): The thermometer is functioning correctly

27 Software specifications – system engineering argument in general zIf SuD satisfies specification S and environment satisfies assumptions A (constraints) then composite system has emergent properties E (requirements) zEmergent properties arise by interaction of component systems

28 Software specifications – properties at every level zFunctional properties yService: Interaction that delivers desired effect yBehaviour: Ordering of interactions over time yCommunication: Symbol flow between different entities zQuality properties/attributes: Efficiency, usability, reliability, …

29 Summary zReactive systems yCommunicate with environment, create desired effects, … zThe environment yMessage exchange between subject domain and SuD, possibly via a connection domain yMessage functions are informative, manipulative, or directive zStimulus-response behaviour yEvent -> stimulus -> response -> action yAssumptions necessary zSoftware specifications yUsed in system engineering argument yFunctional properties concern services, behaviour, and communication