SE 325/425 Principles and Practices of Software Engineering Autumn 2006

James Nowotarski

24 October 2006

SE 325/425Principles and

Practices of Software Engineering

Autumn 2006

2

Topic Duration

Planning and metrics 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

3

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

4

Planning process

Usersrequirements 1

Negotiatereqts

negotiatedrequirements

2

Decom-pose

workbreakdownstructure

4

Estimateresources

workmonths

3

Estimatesize

deliverablesize

5

Developschedule

schedule

Iterate as necessary

productivity rate

5

1. Breaks project into a hierarchy.

2. Creates a clear project structure.

3. Avoids risk of missing project elements.

4. Enables clarity of high level planning.

Work Breakdown Structure

6

Usersrequirements 1

Negotiatereqts


2

Decom-pose


4

Estimateresources

workmonths

3

Estimatesize

deliverablesize

5

Developschedule

schedule


productivity rate

Planning process

7

Units of Size

Lines of code (LOC)

Function points (FP)

Components

Computing Function PointsMeasurement parameter Count Sim-

pleAvg Com

-plex

Number of user inputs X 3 4 6 =

Number of user outputs X 4 5 7 =

Number of user inquiries

X 3 4 6 =

Number of files X 7 10 15 =

Number of external interfaces

X 5 7 10 =

Count (Unadjusted Function Points) UFP

5

8

10

8

2

15

32

40

80

10

177

9

Components

Simple Medium Hard

# Database tables

Criteria:

Simple –

Medium –

Hard –

10

Project Management

Communication project initiation requirements

Modeling analysis design

Construction code test

Deployment delivery support

Planning & Managing

top down estimating bottom up estimating

Empirical Estimation Models Empirical data supporting most empirical models is derived

from a limited sample of projects.

NO estimation model is suitable for all classes of software projects.

USE the results judiciously.

General model:

E = A + B X (ev)c where A, B, and C are empirically derived constants.E is effort in person monthsev is the estimation variable (either in LOC or FP)

Be sure to include contingency

The earlier “completed programs” size and effort data points in Figure 2 are the actual sizes and efforts of seven software products built to an imprecisely-defined specification [Boehm et al. 1984]†. The later“USAF/ESD proposals” data points are from five proposals submitted to the U.S. Air Force Electronic Systems Division in response to a fairly thorough specification [Devenny 1976].

http://sunset.usc.edu/research/COCOMOII/index.html

13

Usersrequirements 1

Negotiatereqts


2

Decom-pose


4

Estimateresources

workmonths

3

Estimatesize

deliverablesize

5

Developschedule

schedule


productivity rate

Planning process

14

GANTT Schedule

• View Project in Context of time.

• Critical for monitoring a schedule.

• Granularity 1 –2 weeks.

15

Objectives of Software Measurement Help a systems development unit understand their

performance

Evaluate performance relative to goals

Allow for comparisons to, e.g.,: Other organizations Alternative development approaches (custom,

packaged, outsourced, etc.) and technologies Other standards/targets

Improve estimating ability

Promote desired behaviors, e.g., reuse

16

GQM Example (High Level)

Improve systems delivery performanceGoal

What is the qualityof our deliverables? How predictable is

our process?How quickly do we deliver?

How efficient are we?

Question

MetricFault density Delivery rate Productivity rate Duration variance

percentage

17

Example: Speed of delivery

0

10

20

30

40

50

60

70

0 2000 4000 6000 8000 10000 12000

Developed Function Points

Ela

pse

d M

onth

s

= Is a single project release (Average elapsed months =14.8, n=33).

Industry Average line is determined from Software Productivity Research

18

Example: Schedule reliability

0%

10%

20%

30%

40%

50%

60%

2000 4000 6000 8000 10000 12000


Sch

edu

le V

aria

nce

abo

ve c

omm

itmen

t

= Is a single project release (n=33).

Industry Average line is determined from Software Productivity Research

19

Example: Software quality

0

1000

2000

3000

4000

5000

6000

7000

0 2000 4000 6000 8000 10000 12000


Fau

lts (

3 m

onth

s)

Faults reported over the first three months in operations (n=27) An estimated industry average for faults found in the first three months of operations. The assumption is that half the total faults are found in the first three months in operation. This average is one half of the industry average of the total faults from C. Jones, Applied Software Measurement, 1996, p.232.

20

Example: Productivity

0

2

4

6

8

10

12

0 2000 4000 6000 8000 10000 12000


Fun

ctio

n P

oint

s pe

r S

taff

Mon

th

Is a single project release (n=33) Industry Average line is determined from SoftwareProductivity Research.

21

Measurement and Continuous Improvement

Continuous Improvement Measurement

22

Continuous Process Improvement

Approach to Quality and Measurement

Plan

Do

Check

Act

1. Identify performance standards and goals

2. Measure project performance

3. Compare metrics against goals

4. Eliminate causes of deficient performance- fix defects- fix root causes

23

Metrics Programs Need to Address People, Process, Technology

QUALITY MANAGEMENT

Enable

Change

Technology

Process

People

Metrics Awareness Education

Metrics Network

Vital Few Metrics Definitions Vital Few Metrics Implementation

Technology Strategy

KM Support for Measurement Community of Practice

Measurement Process Improvement

Large Project Network

Metrics Strategy Commitment / Ownership

Distributed Support Units

Metrics Repository and tools

Measurement Process Definition

Roles & Responsibilities

PROGRAM MANAGEMENT

Achieve-1

Change

Sustain

Change

Achieve-2

Change

Metrics Rollout Education/Training

Pilot Project Group

Ongoing Metrics Education / Training

System Building Improvement Goals

Metrics Definition & Implementation for Delivery Centers

Metrics Embedded in System Building Methods

Dashboard metrics Implementation

Pilot Selected Projectsand Selected Delivery Centers

Enable Large Projectsand Remaining Centers

24

Most metrics programs fail within first 2 years

Lack of [visible] executive sponsorship Lack of alignment with organizational goals Tendency to collect too much data Measures not calibrated, normalized, or

validated Not comparing apples-to-apples

Fear of [individual] evaluation Learning curve (e.g., function points) Cost overhead

Reasons

25

Key Success Factors Ensure that measurement is part of something larger,

typically performance improvement “Trojan Horse” strategy Ensure alignment with organizational goals

Start small, iterate Strongly recommend doing a pilot test

Automate capture of metrics data Rigorously define a limited, balanced set of metrics

“Vital Few” Portfolio approach Comparability

Aggregate appropriately Focus should be on processes, not individuals

Obtain [visible] executive sponsorship Understand and address the behavioral implications

26

Other Quotes

“Count what is countable, measure what is measurable, and what is not measurable,

make measurable”

Galileo

27

Other Quotes

“In God we trust – All others must bring data”

W. Edwards Deming

28

Some Courses at DePaul SE 468: Software Measurement and

Estimation Software metrics. Productivity, effort and defect models.

Software cost estimation. PREREQUISTE(S):CSC 423 and either SE 430 or CSC 315 or consent

SE 477: Software and System Project Management Planning, controlling, organizing, staffing and directing

software development activities or information systems projects. Theories, techniques and tools for scheduling, feasibility study, cost-benefit analysis. Measurement and evaluation of quality and productivity. PREREQUISTE(S):SE 465 or CSC 315

29

Topic Duration



*** Break




Today’s Agenda

30

Context





Planning & Managing

elicitationRequirementsengineeringtasks (Ch. 7-8)

elaborationspecification

Primarydeliverables

functional reqtsnon-functional reqts

analysis modelsoftware reqts spec

31

Use case often first part of analysis model to be developed





Planning & Managing

elicitationRequirementsengineeringtasks (Ch. 7-8)

elaborationspecification

Use casedeliverables

preliminaryuse cases

refineduse cases

32

Use cases

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

device) interacting with the system

33

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

34

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

35

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


36

Use case description - template

Use-case: ActivateSystem

Actor: Homeowner

Pre-conditions:

Trigger:

Scenario:

Exceptions:

. . .


37

Analysis model

Combination of text and diagramming Depicts requirements:

DataFunctionBehavior

38

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

39

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

40

Entities and InstancesInstances are occurrences of an entity

41

Examples of Attributes

Entity: Person Attributes:

• first_name• last_name• eye_color• date_of_birth• address

Entity: Classroom Attributes:

• room_no• max_capacity

42

Depicting Entities, Attributes and Identifiers

Entity name

Attributes

Identifier

Or, usecd_id (PK)

43

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

44

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

45

Cardinality and Modality

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

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

Modality: 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

46

Sample NotationMin MaxCardinality

0 1

1 1

0 M[any]

1 M[any]

47

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)

48

Modality

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

relationship. Modality = 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

The Entity-Relationship Diagram (ERD)

50

An ERD Example

A Vendor must sell at least 1 CD

51

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

53

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 (in Visual

Analyst, e.g.) or strong entity

54

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

55

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

56

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?

57

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.

58

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

59

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 modality

60

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

61

Analysis model



62

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

63

Program Graph

READ_DATA

CALC_SALARY

CALC_TAXES

PRINT_PAYCHECK

employee_data

employee_data

salary

salary

taxes

64

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

65

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

66

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.

67

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 object

A data object; 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.

68

Context Model Example

69

Level 0 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

70

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

71

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

72

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 object

Data store

NOUNS

73

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

74

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

75

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

76

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

77

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

78

Another DFD Level 1 Example

79

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

80

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.

81

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.

82

Analysis model



83

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

84

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.

Locked A B Unlocked

Alarm

1L 3R 2L

Any other dial movement



85

Students at a university

Inquiry Lead Applicant

Admitted

Rejected

Withdrawn

Enrolled Matriculated Graduated

Drop Out

86

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

87

The relationship between data and control models

DFDs

PSPECSs

CFDs

CSPECSs

data input data output

process activators

data conditions

control inputcontrol output

Process model

Control model

88

Analysis modeling activity

89

Topic Duration



*** Break




Today’s Agenda

90

Design





Planning & Managing

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

91

Key principles of architectural design

Abstraction Modularity Reuse

92

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

93

What’s easier to understand and retain?

Grapes Oranges

Milk Butter

Potatoes Apples

Eggs Sour cream

Carrots

Dairy Fruit Vegetable

Milk

ButterEggs

Sour cream

94

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

95

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

96

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

97

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.

98

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.

99

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.

100

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.

101

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

102

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

103

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

104

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

105

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.

106

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.

107

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.

108

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:

109

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

110

Read Pressman Chapters 10, 27 Current event reports:

LinasPaulSanjay

For October 31

111

Extra slides

112

Change Control Process

Create InitialSections

Create/ModifyDraft

Review Draft(V&V)

Create Changes to Incorporate

Changes Needed In Document

DocumentApproved

Create Review Revise ReviewReview Approved

Time

...

Document in Production and Under Formal Change Control

Document in Production and Under Formal Change Control

Document Under Development and User Change Control

Document Under Development and User Change Control

113

Waterfall model

Systemrequirements

Softwarerequirements

Analysis

Program design

Coding

Testing

Operations

Source: Royce, W. "Managing the Development of Large Software Systems."

114

Technology

ProcessPeople

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

Core Concepts

Technology

ProcessPeople

… for the delivery of technology-enabled business solutions

115

LOC-Oriented Estimation Models

E = 5.2 X (KLOC)0.91 Walston-Felix Model

E = 5.5 + 0.73 X (KLOC)1.16 Bailey-Basili Model

E = 3.2 X (KLOC)1.05 Boehm simple model

E = 5.288 X (KLOC)1.047 Dot Model for KLOC > 9

FP-Oriented Estimation Models

E = -13.39 + 0.0545 FP Albrecht and Gaffney Model

E = 60.62 X 7.728 X 10-8 FP3

Kemerer model

E = 585.7 + 15.12 FP Matson, Barnett, Mellichamp model

The COCOMO ModelA hierarchy of estimation models

Model 1: BasicComputes software development effort (& cost) as a function of size expressed in estimated lines of code.

Model 2: IntermediateComputes effort as a function of program size and a set of “cost drivers” that include subjective assessments of product, hardware, personnel, and project attributes.

Model 3: AdvancedIncludes all aspects of the intermediate model with an assessment of the cost driver’s impact on each step (analysis, design, etc).

Three classes of software projectsOrganic

Relatively small, simple. Teams with good application experience work to a set of less rigid requirements.

Semi-detachedIntermediate in terms of size and complexity. Teams with mixed experience levels meet a mix of rigid and less rigid requirements. (Ex: transaction processing system)

EmbeddedA software project that must be developed within a set of tight hardware, software and operational constraints. (Ex: flight control software for an aircraft)

Basic COCOMO Model

Basic COCOMO equations

Nominal effort in person months: E = abKLOCbb

Development time in chronological monthsD = cbE

eb

Software Project ab bb cb db

Organic 2.4 1.05 2.5 0.38

Semi-detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

Major Software Functions

EstLOC

User interface and control facilities UICF 2,300

Two-dimensional geometric analysis 2DGA 5,300

Three-dimensional geometric analysis 3DGA 6,800

Database management DBM 3,350

Computer graphics display features CGDF 4,950

Peripheral control PC 2,100

Design analysis modules DAM 8,400

Estimated lines of code 33,200

E = abKLOCbb

E = 2.3(KLOC)1.05

= 2.3(33.2)1.05

= 95 person-months

D = 2.5E0.35

D = 2.5( 95)0.35

= 12.3 months.

Software Project

ab bb cb db

Organic 2.4 1.05 2.5 3.8

An example of Basic COCOMO

Intermediate COCOMO Model

Intermediate COCOMO equations

Effort in person months: E = abKLOCbb X EAFwhere EAF = an effort adjustment factor

Development time in chronological monthsD = cbE

eb

Software Project ab bb

Organic 3.2 1.05

Semi-detached 3.0 1.12

Embedded 2.8 1.20

Major Software Functions

EstLOC

User interface and control facilities UICF 2,300

Two-dimensional geometric analysis 2DGA 5,300

Three-dimensional geometric analysis 3DGA 6,800

Database management DBM 3,350

Computer graphics display features CGDF 4,950

Peripheral control PC 2,100

Design analysis modules DAM 8,400

Estimated lines of code 33,200

E = abKLOCbb X EAF

E = 3.2(KLOC)1.05 X 1

= 3.2 (33.2)1.05 X 1

Software Project ab bb

Organic 3.2 1.05

The same example in Intermediate COCOMO

EAF is calculated as a product of the multipliers. In this case we set them all to NOMINAL.

http://sern.ucalgary.ca/courses/seng/621/W98/johnsonk/cost.htm#Intermediate

122

Structured EnglishCommon Statements Example

Action Statement Profits = Revenues - Expenses Generate Inventory - Report Add Product record to Product Data Store

If Statement IF Customer Not in Customer Data Store THEN Add Customer record to Customer Data Store ELSE Add Current-Sale to Customer’s Total-Sales Update Customer record in Customer Data Store

For Statement FOR all Customers in Customer Data Store Generate a new line in the Customer-Report Add Customer’s Total-Sales to Report-Total

Case Statement CASEIf Income < 10,000: Marginal-tax-rate = 10%If Income < 20,000: Marginal-tax-rate = 20%If Income < 30,000: Marginal-tax-rate = 31%If Income < 40,000: Marginal-tax-rate = 35%ELSE Marginal-tax-rate = 38%

ENDCASE

123

Processes Logical process models omit any processes that do

nothing more than move or route data, thus leaving the data unchanged. Valid processes include those that: Perform computations (e.g., calculate grade point

average) Make decisions (e.g., determine availability of ordered

products) Sort, filter or otherwise summarize data (e.g., identify

overdue invoices) Organize data into useful information (e.g., generate a

report or answer a question) Trigger other processes (e.g., turn on the furnace or

instruct a robot) Use stored data (create, read, update or delete a record)

124

Creating Data Flow Diagrams

Creating DFDs is a highly iterative process of gradual refinement.

General steps:

1. Create DFD fragments for each use case/requirement

2. Create a Level 0 diagram from fragments

3. Decompose to Level 1,2,…

4. Go to step 1 and revise as necessary

5. Validate DFDs with users.

125

Some Data Flow Rules

External entity Process Data store

External entityCustomer

information

Process

Data store N/A

Data moved TO:

Data Moving FROM

A process moves data from place to place in the system. On a data flow diagram, processes may move data between certain symbols (data stores, external entities, and other processes). However, data may not be moved without a process. To help you understand and appreciate this, fill in the empty cells in the following table. The cell entries should either be 1) An example of how data could be moved; 2) N/A to indicate this cannot be done.

In this example, “customer information” may be moved from an external entity to a process (e.g., a customer gives their address and credit card information to a sales agent).

The “N/A” suggests data cannot be moved from a data store directly to an external entity, which is true (you need a process in between them).

Documents

SE 325/425 Principles and Practices of Software Engineering Autumn 2006