Lecture 4 Behaviour Modelling Requirement Specification ObjectOriented Paradigm

Lecture 4 Behaviour Modelling Requirement Specification Object-Oriented Paradigm 1

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, 2001. 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. 2

The Analysis Process build a prototype requirements the problem elicitation develop Specification Review create analysis models 3

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

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

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

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

Flow Modelling Notation external entity process data flow data store 8

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

Behavioural Modelling and Process Specification 10

Behavioural Modelling events Outside world behaviour Application 11

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

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

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

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

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

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

Guidelines for Building a CSPEC w w w 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 w describe the behaviour of a system by identifying its states; identify how each state is reach and defines the transitions between states w 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? ” 18

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

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

The Data Dictionary a quasi-formal grammar for describing the content of data that the software will process and create 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) 21

Data Dictionary Notation 22

Data Dictionary Example 23

Specification Guidelines 24

Specification Guidelines 25

Specification Guidelines 26

Object-oriented Concepts and Principles 27

The OO Process Model identify candidate classes Pla nning Risk Analysis Customer Co mmunic a tion look-up classes in library construct nth iteration of system extract classes if available put new classes in library Customer Evalua tion Engineering, Co nstruc tion & Relea se engineer classes if unavailable OO analysis OO design OO programming OO testing 28

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

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

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

Building a Class class name attributes: operations: 32

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

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

Methods w a. k. a. Operations, Services w 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. w A method is invoked via message passing. 35

Messages 36

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

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

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