James Nowotarski 25 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008

James Nowotarski

25 September 2008

SE 325/425Principles and

Practices of Software Engineering

Autumn 2008

22

Software Engineering Body of Knowledge

Software requirementsSoftware designSoftware constructionSoftware testingSoftware maintenanceSoftware configuration managementSoftware engineering managementSoftware engineering processSoftware engineering tools and methodsSoftware quality

Source: Guide to the Software Engineering Body of Knowledge. (2004). IEEE. www.swebok.org

What is SE?

tonight

3

Topic Duration

Last week recap 20 minutes

Analysis modeling 60 minutes

*** Break

Current event reports 20 minutes

Analysis modeling (cont.) 30 minutes

Design modeling 30 minutes

Today’s Agenda

44

Systems development life cycle (SDLC) A description of the phases of an

information system

w x y z

Example

Core Concepts

SDLC is another synonym for software process

55Copyright © 1997 by Rational Software Corporation

Risk

Transition

Inception

Elaboration

Construction

PreliminaryIteration

Architect.Iteration

Architect.Iteration

Devel. Iteration

Devel. Iteration

Devel. Iteration

TransitionIteration

TransitionIteration

Post-deployment

Waterfall

Time

Risk Profile: Iterative vs. Waterfall

Iterative

66

Why focus on risk and change?

Life cycle phase

Co

st

of

ch

an

ge

Req Anal. Des. Impl. Test Prod

y = axp

77

RUP: “Be careful”

Life cycle phase

Co

st

of

ch

an

ge

Req Anal. Des. Impl. Test Prod

y = axp

RUP – “In general, as the project progresses, you should be more careful about introducing change”

88

XP: “Bring it on”

Time

Co

st

of

ch

an

ge

XP purports to change the curve so that the cost to find and repair software problems does not rise dramatically over time

99

What is XP

Test all the time Continuous integration Pair programming Coding standards Collective ownership Do simplest thing that will work today

“design tomorrow for tomorrow’s problems” Metaphor to aid in understanding the architecture Refactoring and evolutionary design

Key Practices/Features

1010

What is XP

Customer on-site as integral part of team Incremental planning

learning to driveprogrammers provide estimates

Short iterations, small releases2 month releases, 2 week iterations

40-hour week

Key Practices/Features (cont.)

1111

What is XP

Start design with a test Start coding with a test Test things that might break Testing is isolated Testing is integrated Testing is automated At least one dedicated tester

Begin with the end in mind . . .

1212

Technology1

ProcessPeople

The focus of SE 425 is the process component of software engineering

Core Concepts

Technology1

ProcessPeople

… for the delivery of technology-enabled business solutions

1 SE is primarily concerned with the software subset of technology

13

People trump process

“A successful software methodology (not new, others have suggested it):

(1) Hire really smart people(2) Set some basic direction/goals(3) Get the hell out of the way

In addition to the steps about, there's another key: RETENTION”

http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html

14

Topic Duration



*** Break




Today’s Agenda

1515

Context

Communication project initiation requirements

Modeling analysis design

Construction code test

Deployment delivery support

Planning & Managing

elicitationRequirementsengineeringtasks (Ch. 7-8)

elaborationspecification

Primarydeliverables

functional reqtsnon-functional reqts(aka quality reqts)

analysis modelsoftware reqts spec(SRS)

16

Use case often first part of analysis model to be developed





Planning & Managing

elicitationRequirementsengineeringtasks (Ch. 7-8)

elaborationspecification

Use casedeliverables

preliminaryuse cases

refineduse cases

17

Use cases

A user scenario A thread of usage Tells a story of an actor (end user or

device) interacting with the system

18

Use-Case Diagram

homeowner

Arms/ disarms system

Accesses system via Internet

Reconfigures sensors and related

system features

Responds toalarm event

Encounters anerror condition

system administrator

sensors

19

Use case description – narrative

“If I’m at a remote location, I can use any PC with appropriate browser software to log on to the SafeHome Products Web site . . . “

Use-case: Activate the system

20

Use case description – ordered sequence

1. The homeowner observes . . .

2. The homeowner uses the keypad . .

3. The homeowner selects and keys in stay or away . . .

4. When activation occurs . . .


21

Use case description - template

Use-case: ActivateSystem

Actor: Homeowner

Pre-conditions:

Trigger:

Scenario:

Exceptions:

. . .


22

Analysis model

Combination of text and diagramming Depicts requirements:

DataFunctionBehavior

23

Key Definitions

A data model is aFormal representation of the data to

be used for a business system. A data model should illustrate:

The people, places and things about which data is collected,

And how they are related to each other

24

Data Modeling

Entity-relationship diagram (ERD) Entity descriptions Attribute descriptions Relationship descriptions

A logical data model deliverable includes an ERD and descriptions of entities, attributes, and relationships

Components of a Logical Data Model

25

Entities and InstancesInstances are occurrences of an entity

26

Examples of Attributes

Entity: Person Attributes:

• first_name• last_name• eye_color• date_of_birth• address

Entity: Classroom Attributes:

• room_no• max_capacity

27

Depicting Entities, Attributes and Identifiers

Entity name

Attributes

Identifier

Or, usecd_id (PK)

28

Identifiers

An identifier should have the following characteristics:Its value should not change over the life of

each instanceIts value should never be “null” or emptyIt should be composed of the minimal

number (preferably one) of attributes required to ensure uniqueness

29

Relationships

Relationships represent connections, links, or associations between entities

• e.g., Patient-Appointment

Relationships have some important properties:

1. Names, that should be active verbs• (A patient schedules appointments)

2. Cardinality

3. Optionality.

30

Cardinality and Optionality

Department Employee

Cardinality: Implies that an employee is assigned to only one department.

Cardinality: Implies that there may be many employees in a department

contains

Optionality: Mandatory implies that an employee MUST be assigned to a department

Optionality: Optional implies that there may be a situation in which a department has no employees.

There are several other ERD notations, unfortunately there is no single standard!

is assigned to

31

Sample NotationMin MaxCardinality

0 1

1 1

0 M[any]

1 M[any]

32

Cardinality

Cardinality refers to the number of times instances in one entity can be related to instances in another entity One instance in an entity refers to one and

only one instance in the related entity (1:1) One instance in an entity refers to one or

more instances in the related entity (1:M) One or more instances in an entity refer to

one or more instances in the related entity (M:M)

33

Optionality

Optionality Indicates whether a particular data object MUST participate in the relationship. Optionality = 0: No particular need for the

relationship. Optionality = 1: Relationship is mandatory Refers to the minimum number of times that

an instance in one entity can be related to an instance in another entity

One means that the relationship is mandatory Zero means the relationship is optional

Also known as “modality”

The Entity-Relationship Diagram (ERD)

35

An ERD Example

A Vendor must sell at least 1 CD

36

What Is an ERD?

A picture of the logical data model, i.e., an ERD shows the information

created, stored, and used by a business system.

Entity Types

1. Independent2. Dependent3. Intersection

38

Independent Entities

An independent entity exists without the help of another entityCommon entities such as student,

professors, customers, productsThe identifier is created by the entity’s

own attributesUsually on the “1” side of a relationshipa.k.a. fundamental entity or strong entity

39

Dependent Entities Alternatively, a dependent entity cannot

exist without the help of another entitySpecial entities such as emp_dependent

(needs an employee to exist)The identifier is usually based on another

entity’s attributes (emp_ssn & dep_ssn)Usually on the “M” side of a relationshipa.k.a. weak entity

40

Intersection entities

An intersection entity exists based on the relationship between two entities.They have attributes that are peculiar to

the relationship between those entity instances, not the individual entities themselves

They are created to store information about two entities sharing an M:M relationship

a.k.a. associative entities

41

An Intersection Entity Example

A CD may be a part of many orders.

An order may contain many CDs.

The CD-order relationship is M:M.

Where do you store quantity of CD’s on an

order?

42

Adding Intersection Entities

1. Create an intersection entity

(line item).

3. The “1” side goes

on the original

entities.

2. Move the “M’s” adjacent to the

intersection entity.

43

M:N to 1:Ms

Rule: The M always go to the intersection entity.

Orders

CD_No CD_Title Order_No CD_No Qty Order_No234 Best of Lawrence Welk 100101 234 12 100101235 Living Daylights Soundtrack 100101 236 3 100102236 Moody Blues Greatest Hits 100102 234 5 100108

100102 235 2100102 236 6100108 236 1

CD Line Items

44

Summary

The ERD is the most common technique for drawing data models. The building blocks of the ERD are:Entities (nouns), describe people,

places, or thingsAttributes (nouns), capture information

about the entityRelationships (active verb sentences)

associate data across entities; they have cardinality and optionality

45

From Analysis to Design

ER Model Relational Model

Database Spreadsheet

Entity Relation Table, File Table

Instance Tuple Record Row

Attribute Attribute Field Column

Identifier Key Key Key

Analysis Design

46

Analysis model



47

Structure Chart

PROCESS_PAYROLL for each employee get_data(:employee_data) calc_salary(employee_data:salary) calc_tax(salary:tax) print_check(employee_data, salary, tax)

GET_DATA

employee_data

CALC_SALARY

employee_ data

salary

CALC_TAX

salary

tax

PRINT_CHECK

employee_data

salary

tax

48

Program Graph

READ_DATA

CALC_SALARY

CALC_TAXES

PRINT_PAYCHECK

employee_data

employee_data

salary

salary

taxes

49

Program Graph

READ_DATA

CALC_SALARY

CALC_TAXES

PRINT_PAYCHECK

employee_data

employee_data

salary

salary

taxes

Big idea: As a prelude to creating a design, represent the basic computational requirement for the system to be designed in more abstract terms, i.e., in terms of data flow

50

Data Flow Diagrams A Data Flow Diagram (DFD) is a graphical

technique for: Depicting information flow The transforms that are applied as data move

from input to output DFD also known as a data flow graph or a

bubble chart DFDs can be modeled at multiple levels of

abstraction Level 0 DFD is called the context diagram or

context model and represents the entire system as a single bubble with inputs and outputs

51

DFD Context Model for SafeHome Security System

SafeHomesoftware

Controlpanel

Sensors Telephoneline

Alarm

Controlpanel

displayUser commandsand data

Sensorstatus

Telephonenumber tones

Alarmtype

Displayinformation

This highest level model is also called a Level 0 model or a Fundamental model.

52

Basic DFD NotationExternal

entity

A producer or consumer of information that resides outside the bounds (or at the boundaries) of the system to be modeled.

ProcessA transformer of information (a function) that resides within the bounds of the system to be modeled.

Data flowA data flow; the arrowhead indicates the direction of data flow.

D1 Data storeA repository of data that is to be stored for use by one or more processes; may be as simple as a buffer or queue or as sophisticated as a relationship database.

53

Context Model Example

54

DFD Tips

Generally move from top to bottom, left to right

Minimize crossed lines Iterate as needed

The DFD is often drawn many times before it is finished, even with very experienced systems analysts

55

Some Rules for External Entities

External people, organizations, systems and data stores

Reside outside the system, but interact with system

Either receive info from system or trigger system into motion

Examples: Customers, managers

Not clerks or other staff

ExternalEntities

56

SafeHomesoftware

Controlpanel

Sensors Telephoneline

Alarm

Controlpanel

displayUser commandsand data

Sensorstatus

Telephonenumber tones

Alarmtype

Displayinformation

Perform a grammatical parse on the narrative that describes the context level bubble.

Isolate nouns (& noun phrases), and verbs (& verb phrases).

The safeHome security function enables the homeowner to configure the security system when it is installed, monitors all sensors connected to the security system, and interacts with the homeowner through the internet, a PC, or a control panel.

During installation, the SafeHome PC is used to program and configure the system. Each sensor is assigned a number and type, a master password is programmed for arming and disarming the system, and telephone number(s) are input for dialing when a sensor event occurs.

Refining Level 0 to Level 1

57

Refining Level 0 to Level 1

When a sensor event is recognized, the software invokes an audible alarm attached to the system. After a delay time that is specified by the homeowner during system configuration activities, the software dials a telephone number of a monitoring service, provides information about the location, reporting the nature of the event that has been detected. The telephone number will be redialed every 20 seconds until a telephone connection is obtained.

The homeowner receives security information via a control panel, the PC, or a browser, collectively called an interface. The interface displays prompting messages and system status information on the control panel, the PC, or the browser window. Homeowner interaction takes the following form.

Process

VERBS

Externalentity

Data flow

Data store

NOUNS

58

Level 1 DFD for SafeHome security function

Controlpanel

Interactwithuser

Processpassword

Configuresystem

Activate/deactivate

system

MonitorsensorsSensors Telephone

line

Alarm

Controlpanel

display

User commands & data

Password

Configurerequest

Start /stop

A/dmsg

Valid ID msg

Sensorstatus

Configuration information

Configuration data

Configuration data

Sensorinformation

Configurationdata

Displayinform-ationDisplay

messages& status

Alarmtype

Telephone number tones

MonitorsensorsSensor

status

Sensorinformation

Alarmtype


Configurationdata

59

Level 2 DFD for SafeHome’s “Monitor Sensors” process

Configuration information Formatfor

display

Configuration data

Assessagainstsetup

Generatealarmsignal

Readsensors

Dialphone

Sensor ID type, location

Sensor Information

Alarm type

Alarmdata

Telephonenumber

Telephonenumbertones

Sensor status

Sensor ID type

60

Some Rules for Data Stores

Internal to the system Data at rest Include in system if the system

processes transform the data Create, Update, Delete

Every data store on DFD should correspond to an entity on an ERD

Must have at least one input data flow (or else they never contain any data)

Usually have at least one output data flow

Data StoresD1

61

Some Rules for Data Flows

Data in motionFrom external entity

(“source”) to systemFrom system to external

entity (“sink”)From internal symbol to

internal symbol, but data flows always either start or end at a process

Data Flow

62

Some Rules for Processes

Always internal to system Law of conservation of data:

#1: Data stays at rest unless

moved by a process.

#2: Processes cannot consume or manufacture data Must have at least 1 input data flow (to avoid miracles) Must have at least 1 output data flow (to avoid black holes) Should have sufficient inputs to create outputs (to avoid

gray holes)

0.

Processes

63

Another DFD Level 1 Example

64

Level 1 DFD for SafeHome security function

Controlpanel

Interactwithuser

Processpassword

Configuresystem

Activate/deactivate

system

MonitorsensorsSensors Telephone

line

Alarm

Controlpanel

display

User commands & data

Password

Configurerequest

Start /stop

A/dmsg

Valid ID msg

Sensorstatus

Configuration information

Configuration data

Configuration data

Sensorinformation

Configurationdata

Displayinform-ationDisplay

messages& status

Alarmtype


MonitorsensorsSensor

status

Sensorinformation

Alarmtype


Configurationdata

65

Key Definition

Decomposition is the process of modeling the system and its components in increasing levels of detail.

Balancing involves insuring that information presented at one level of a DFD is accurately represented in the next level DFD.

66

Summary

The Data Flow Diagram (DFD) is an essential tool for creating formal descriptions of business processes and data flows.

Use cases record the input, transformation, and output of business processes.

Eliciting scenario descriptions and modeling business processes are critically important skills for the software engineer to master.

67

Analysis model



68

A large class of applications are: Driven by events rather than by data, Produce control information rather than reports and displays Process information with heavy concern for time and

performance

To select candidate events consider: All sensors read by the system All interrupt conditions All “switches” that are actuated by an operator All data conditions Look for “control items” in the existing DFD Describe the behavior of the system as a set of states.

Consider how each state is reached. Look for possible omissions (i.e., is there more than one way to

reach this state?)

Creating a control flow model

69

State Transition Diagram A safe has a combination lock that can be in one of

three positions, labeled 1, 2, and 3. The dial can be turned left (L) or right (R). Therefore there are only six possible dial movements:

1L (left to 1), 1R, 2L, 2R, 3L, 3R The combination is 1L, 3R, 2L.

1L 3R 2LLocked A B Unlocked

Alarm

Any other dial movement



70

Students at a university

Inquiry Lead Applicant

Admitted

Rejected

Withdrawn

Enrolled Matriculated Graduated

Drop Out

71

SafeHome Security

Resetting

Entry/set systemStatus “inactive”Entry/set displayMsg1 “Starting system”Entry/set displayMsg2 “Please wait”Entry/set displayStatus showBlinkingDo: run diagnostics

Idle

Entry/set systemStatus “inactive”Entry/set displayMsg1 “Ready”Entry/set displayMsg2 “”Entry/set displayStatus steadykeyHit/handleKey

ActingOnAlarm

Entry/set systemStatus “monitorAndAlarm”Entry/set displayMsg1 “ALARM”Entry/set displayMsg2 triggeringSensor Entry/set displayStatus fastBlinkingDo: soundAlarmDo: notifyAlarmResponderskeyHit/handleKey

MonitoringSystemStatus

Entry/set systemStatus “monitoring”Entry/set displayMsg1 “Armed”Entry/set displayMsg2 “”Entry/set displayStatus steadyDo: monitorAndControlSystemKeyHit/handleKey

Start/ stop switch power “on”

failureDetected / set displayMsg2 “contact Vendor”

SystemOK

Reset

Activate

deactivatePassword

falseAlarm

timeOut

sensorTriggered/startTimer

sensorTriggered/restartTimer

deactivate Password

off/powerOff

72

Analysis modeling activity

73

Topic Duration



*** Break




Today’s Agenda

74

Design





Planning & Managing

Primary deliverablesDesign model:• Data/Class • Architecture• Interfaces• Components

75

Key principles of architectural design

Abstraction Modularity Reuse

76

Abstraction

There is a limit to the number of ideas you can comprehend at any one time 7 +/- 2

Raise the level of detail by creating relationshipsExample: Grouping

Think in logical instead of physical terms

77

What’s easier to understand and retain?

Grapes Oranges

Milk Butter

Potatoes Apples

Eggs Sour cream

Carrots

Dairy Fruit Vegetable

Milk

ButterEggs

Sour cream

78

Modular design Reduces complexity Facilitates change Results in easier implementation by supporting parallel

development of different parts of the system.

Information hiding

Functional independence

Modularity

79

CohesionA measure of the relative functional strength of a module

High Cohesion (good)

CouplingA measure of the relative interdependence among modules.

High coupling (bad)

Func A-1

Func A-2

Func A-3

Func B-1

Func B-2

Func B-3

Two qualitative criteria

80

Cohesion "Cohesion is the degree to which the tasks performed by a single module are functionally related.“ IEEE, 1983

"Cohesion is the "glue" that holds a module together. It can be thought of as the type of association among the component elements of a module. Generally, one wants the highest level of cohesion possible.“ Bergland, 1981

"A software component is said to exhibit a high degree of cohesion if the elements in that unit exhibit a high degree of functional relatedness. This means that each element in the program unit should be essential for that unit to achieve its purpose.“ Sommerville, 1989

81

Cohesion A cohesive module performs a single task within a software

procedure, i.e., it should do JUST ONE THING.

Strive for HIGH cohesion.

Low High

“Scatter-brained” “Single-minded”

Coincidental

Logical

Temporal

Procedural

Communicational

Sequential

Functional

Strive for high cohesion.

Often acceptable. Almost as good as high cohesion.

Much worse than mid level cohesion.

82

Low Cohesion Logical Cohesion

Tasks related very loosely. (e.g., a module that produces ALL output regardless of its type).

public void logical_example( int flag ) { switch ( flag ) {

case 1: // “1” related functionality;break;case 2:// “2” related functionality;break;case 3:// “3” related functionality;break;

}}

Solution: Isolate each functionality into a separate operation / class etc.

83

Low Cohesion Temporal Cohesion

Tasks related by the fact that they must all be executed within the same span of time.

Common examples include startup or end of job clean-up routines.

procedure initializeData() { font = "times"; windowSize = "200,400"; foo.name = "Not Set"; foo.size = 12; foo.location = "/usr/local/lib/java";

}

Give each object a constructor and destructor.

84

Example of Low Cohesion A module that performs the following tasks when computed data exceed pre-specified bounds.

Computes supplementary data based on original computed data. Produces an error report (with graphical content) on the user’s workstation Performs follow-up calculations requested by the user Updates a database Enables menu selection for subsequent processing.

These functions are loosely connected but could best be implemented through individual modules.

85

Moderate Cohesion Relatively close to one another in the degree of module independence.

Procedural CohesionProcessing elements are related and must be executed in a specific order.

Communicational CohesionAll processing elements concentrate on one area of a data structure.

Sequential CohesionThe output data from one processing element serves as input data for the next processing element

86

Functional Cohesion If the operations of a module can be collectively

described as a single specific function in a coherent way, the module has functional cohesion. If not, the module has a lower type of cohesion.

In an O-O system,

Each operation in public interface of an object should be functional cohesive

Each object should represent a single cohesive concept

87

Coupling

A measure of interconnection among modules in a program structure.

Depends on The interface complexity between modules The point at which entry or reference is made to a module The data that pass across the interface.

Goal is LOW coupling in order to increase understandability and reduce the rippling effect during change.

Low High

No direct

coupling Data

coupling Stamp

coupling Control

coupling External

coupling Common

coupling Content

coupling

88

Types of coupling

a

b c

d

e

f g h

i

j k

Global data area

Data structure

Data (variables)

No direct coupling

Controlflag

Module M Module M’

Data Coupling

Stamp Coupling

ControlCoupling

CommonCoupling

89

Low Coupling

Data couplingCoupling is via a simple argument list through which simple data are passed.

Stamp couplingSame as data coupling except a portion of a data structure is passed.

Control couplingPassage of control between modules. (For example setting a control flag to control decisions in a subordinate module.)Very common in most software designs.

90

High Coupling Common Coupling

High level of coupling occurs when variables are tied to an environment external to software:

I/O couples a module to specific devices, formats, communication protocols.

In the example on the previous slide, c, g, and k all access a common data area.

c initializes it, g updates it incorrectly, later k uses and an error occurs. It appears that the error is in k – whereas actually it is in g.

The use of global data is not absolutely bad but:

Should be used sparingly

Developers should understand the possible implications.

91

Highest Coupling Content Coupling

One module makes use of data or control information maintained within the boundary of another module.

Branches are made into the middle of a module.

AVOID Content coupling.

Information hiding hiding helps prevent content coupling.

92

Design Heuristics1. Evaluate the first iteration of the program structure to reduce coupling and improve cohesion.

Implode or explode modules

2. Minimize structures with high fan-out; strive for fan-in as depth increases.

Avoid structures as shown below:

93

Design Heuristics3. Keep scope of effect of a module within the scope of control of that module.

The scope of control of a includes all modules that are subordinate to module a. (i.e., b,c,d,e,f)

If module a makes a decision that impacts module h, then this heuristic is violated.

a

b c d

g

h i

e f

94

Assignment 2 Read Pressman Chapters 13, 14, 26 Current event reports:

Poornima (in-class)Kelly (DL)Sean (DL)Travis (DL)

For October 2

Documents

James Nowotarski 25 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008