1 Lecture 4 Behaviour Modelling Requirement Specification Object-Oriented Paradigm

2 Disclaimer and Copyright Notice This work is subject to copyright. All rights are reserved. This course material is developed in conjunction with the courseware of Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, The material provided is for reference only. It should not be redistributed with prior written consent. Proceeding beyond this notice implies willingness to comply with the terms.

3 The Analysis Process the problem requirementselicitation build a prototype createanalysismodels develop Specification Review

4 Analysis Principles  Model the Data Domain  Model Function  Model Behaviour  Partition the Models  Focus on the Essential View

5 Elements of an Analysis Model Data Dictionary Entity Relationship Diagram Data Flow Diagram State-transition Diagram Data Object Description Process Specification (PSPEC) Control Specification (CSPEC)

6 Identifying Objects and Operations  define “objects” - nouns in the written statement of scope producers/consumers of data places where data are stored “composite” data items  define “operations” - by active verbs processes relevant to the application data transformations  consider other “services” that will be required by the objects

7 ERD Notation object 1 object 2 (0, m) (1, 1) object 1 relationship One common form: (0, m) (1, 1) relationship Another common form: attributes

8 Flow Modelling Notation external entity process data flow data store

9 Constructing a DFD  review ERD to isolate data objects and grammatical parse to determine “operations”  determine external entities (producers and consumers of data)  create a level 0 DFD (fundamental system model, context model)  write a narrative describing the transform  parse to determine next level transforms  “balance” the flow to maintain data flow continuity  develop a level 1 DFD  use a 1:5 (approx.) expansion ratio

10 Behavioural Modelling and Process Specification

11 Behavioural Modelling Outside world Application events behaviour

12 The States of a System  State — a set of observable circumstances that characterizes the behaviour of a system at a given time  State Transition — the movement from one state to another  Event — an occurrence that causes the system to exhibit some predictable form of behaviour  Action — process that occurs as a consequence of making a transition

13 Behavioural Modelling  make a list of the different states of a system (How does the system behave?)  indicate how the system makes a transition from one state to another (How does the system change state?) – indicate event – indicate action  draw a state transition diagram  make a list of the different states of a system (How does the system behave?)  indicate how the system makes a transition from one state to another (How does the system change state?) – indicate event – indicate action  draw a state transition diagram State New State event causing transition action that occurs

14 STD Example reading operator commands making copies reloading paper Diagnosing problem full invoke read-op-input full and start invoke manage-copying copies done invoke read-op-input empty invoke reload paper jammed invoke perform problem-diagnosis not jammed invoke read-op-input Idle

15 The Control Model  the control flow diagram is “superimposed” on the DFD and shows events that control the processes noted in the DFD  control flows — events and control items — are noted by dashed arrows  a vertical bar implies an input to or output from a control spec (CSPEC) — a separate specification that describes how control is handled  a dashed arrow entering a vertical bar is an input to the CSPEC  a dashed arrow leaving a process implies a data condition  a dashed arrow entering a process implies a control input read directly by the process  control flows do not physically activate/deactivate the processes — this is done via the CSPEC

16 CFD Example Produce user displays Manage copying Read operator input Perform problem diagnosi s Reload paper Alarm Repro fault Full Start/stop Paper feed status (jammed, empty)

17 Control Specification (CSPEC) The CSPEC can be: state transition diagram (sequential spec) state transition table decision tables activation tables combinatorial spec

18 Guidelines for Building a CSPEC  list all sensors that are “read” by the software  list all interrupt conditions  list all “switches” that are actuated by the operator  list all data conditions  recalling the noun-verb parse that was applied to the software statement of scope, review all “control items” as possible CSPEC inputs/outputs  describe the behaviour of a system by identifying its states; identify how each state is reach and defines the transitions between states  focus on possible omissions... a very common error in specifying control, e.g., ask: “Is there any other way I can get to this state or exit from it?”

19 Process Specification (PSPEC) PSPEC narrative pseudocode (PDL) equations tables diagrams and/or charts bubble

20 A Design Note one or more ”components" in the software design PSPEC

21 The Data Dictionary Name:the primary name of the composite data item Aliases:other names for the data item Where used:data transforms (processes) that use the composite data item How used:the role of the data item (input, output, temporary storage, etc.) Description:a notation for representing content (presented on next slide) Format:specific information about data types, preset values (if known) a quasi-formal grammar for describing the content of data that the software will process and create

22 Data Dictionary Notation

23 Data Dictionary Example

24 Specification Guidelines

25 Specification Guidelines

26 Specification Guidelines

27 Object-oriented Concepts and Principles

28 The OO Process Model

29 The OO Mindset problem domain objects object-oriented = objects + classification + inheritance + communication

30 Key Concepts  classes and class hierarchies – instances – inheritance – abstraction and hiding  objects – attributes – methods – encapsulation – polymorphism  messages

31 Classes  a class is: – template – generalised description – pattern – “blueprint”... describing a collection of similar items  a metaclass (also called a superclass) is a collection of classes  once a class of items is defined, a specific instance of the class can be defined

32 Building a Class class name attributes: operations: attributes: operations

33 What Is a Class? external entities things occurrences roles organizational units places structures class name attributes: operations:

34 Class Hierarchy chair table desk"chable" instances of chair furniture (superclass) subclasses of the furniture superclass

35 Methods  a.k.a. Operations, Services  An executable procedure that is encapsulated in a class and is designed to operate on one or more data attributes that are defined as part of the class.  A method is invoked via message passing.

36 Messages

37 Encapsulation/Hiding The object encapsulates both data and the logical procedures required to manipulate the data Achieves “information hiding” method # 1 data method # 2 method # 4 method # 5 method # 6 Reduce side effect Facilitate reuse Simple object interface

38 Inheritance  Accomplish reuse directly  Subclasses inherit all attributes and operations of the superclass  New attributes/ methods of subclass overrides that of the superclass  Multiple inheritance – more than one superclass. Good? Bad? chair table desk"chable" furniture (superclass)

39 Polymorphism  Graphs: line graph, pie chart, histogram, etc.  Subclasses overload some methods of the superclass  Enables a number of different operations to have the same name  Decouples objects from one another