1

Specification of IT Systems – Introduction

2

Book and web pages

In the course we use the following litterature: Design Methods for Reactive Systems – Yourdon,

Statemate, and the UML R.J. Wieringa Morgan Kaufmann, 2003

Course web page http://www.daimi.au.dk/~krell/SITS/

3

Lectures and exercises

Lectures and exercises Thuesday 8-12 Codd-S 219 - except for today…

First lectures, then exercises…

4

Mandatory excersises and exam

Mandatory excersises Web...

Exam Web...

5

Lectures

Lectures Jens Bæk Jørgensen (jbj@daimi.au.dk) Søren Christensen (schristensen@daimi.au.dk) Kristian Bisgaard Lassen (krell@daimi.au.dk)

6

Purpose and Contents

Purpose: The purpose of this course is to strengthen the students knowledge of

conceptual modeling and system specification.

Contents: The 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.

The 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

Chapter 1: Reactive systemsChapter 2: The environmentChapter 3: Stimulus-response behaviourChapter 4: Software specifications

8

Reactive systems – first characterisation

Two main classes of systems Transformational systems Reactive systems

Reactive systems respond to stimuli in order to bring about desirable effects in their environments

Reactive systems may Manipulate complex data Engage in complex behavior Communicate with (many) other systems

9

Reactive systems – training information system example

Purpose Coordinate monthly training courses for new employees of

large company

Characteristics Interactive Nonterminating State-dependent response Environment-oriented response Parallel processing

10

Reactive systems – elevator controller example

Purpose Control the movement of two elevator cages in a 10 floor

building; update location and direction indicators

Characteristics Interactive Nonterminating State-dependent response Environment-oriented response Parallel processing Real-time

11

Reactive systems – definition and examples (Wieringa)

A 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.

Characteristics Interactive Nonterminating Interrupt-driven State-dependent response Environment-oriented response Parallel processing Real-time

Examples Information 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

Environment and system exchange messages Each message has

A subject (people, devices, conceptual entities, lexical entities, ...)

A function, which informs the environment, directs the environment, or manipulates lexical items

A connection, which isa path from sender to receiver that may delay, distort, or loose the

message

14

The environment – subject domain

Subject domain of a reactive system Consists of entities and events Set of all subjects of all its input and output messages The part of the world talked about by the messages that

cross the system interface

Categories of entities Physical entities Conceptual entities Lexical 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

Assumptions are statements about the environment Must be true for the (stimulus, response) pair to be

desirable Beyond control of SuD

Examples of categories of assumptions Laws of nature Properties of devices Properties 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

Events of interest: beginning of plate arrives, end of plate arrives Available stimuli: on, off Necessary assumptions:

The photo-electric cell is functioning properly. The cell is stimulated only by the arrival of the beginning or end of a

metal plate Event recognition?

24

Software specifications – basic concepts and terminology

Design decision Any creative decision about a system

Specification Description of design decisions

A reactive system specification must describe the place of the SuD in the system hierarchy functions, behaviour and communication of the SuD its composition

The specification must be used to make a system engineering argument

25

Software specifications – system engineering argument for training information system

Emergent property (E): Department must be able to handle newcomers efficiently

Specification (S): The training information system allows registration of unexpected participants

Assumption (A): The department has extra staff

26

Software specifications – system engineering argument for heating controller

Emergent property (E): Pasteurization unit heats batch according to recipe

Specification (S): The heating controller controls heater according to batch recipe

Assumption (A): The thermometer is functioning correctly

27

Software specifications – system engineering argument in general

If SuD satisfies specification S and environment satisfies assumptions A (constraints) then composite system has emergent properties E (requirements)

Emergent properties arise by interaction of component systems

28

Software specifications – properties at every level

Functional properties Service: Interaction that delivers desired effect Behaviour: Ordering of interactions over time Communication: Symbol flow between different entities

Quality properties/attributes: Efficiency, usability, reliability, …

29

Summary

Reactive systems Communicate with environment, create desired effects, …

The environment Message exchange between subject domain and SuD, possibly via a

connection domain Message functions are informative, manipulative, or directive

Stimulus-response behaviour Event -> stimulus -> response -> action Assumptions necessary

Software specifications Used in system engineering argument Functional properties concern services, behaviour, and

communication