LECTURE 1: Introduction

Lecture time: 1 hr. 20 min.

Ivan Marsic
Rutgers University
 Course Information

 Web: http://www.ece.rutgers.edu/~marsic/Teaching/SE
 Lecture Notes:
http://www.ece.rutgers.edu/~marsic/books/SE
 Textbooks (see more on the course website)
– Bruegge & Dutoit: Object-Oriented Software Engineering: Using UML, Patterns and
Java, Third Edition, Prentice Hall, 2010. | ISBN 0-13-6061257
– Miles & Hamilton: Learning UML 2.0, O’Reilly Media, 2006. ISBN: 0-596-00982-8

2
 Introduction: Software is Complex

 Complex  complicated

 Complex = composed of many simple parts

related to one another

 Complicated = not well understood, or explained

 Complexity Example:
Scheduling Fence Construction Tasks

Nailing Painting
Setting posts Cutting wood
[ 2 time units for unpainted; [ 5 time units for uncut wood;
[ 3 time units ] [ 2 time units ]
3 time units otherwise ] 4 time units otherwise ]

Setting posts  Nailing, Painting

Cutting  Nailing

…shortest possible completion time = ?

[  “simple” problem, but hard to solve without a pen and paper ] 4

 More Complexity

Suppose today is Tuesday, November 29

What day will be on January 3?

[ To answer, we need to bring the day names and the day numbers
into coordination, and for that we may need again a pen and
paper ]
 The Frog in Boiling Water
 Small problems tolerate complacency
—lack of immediate penalty leads to
inaction
 Negative feedback accumulates subtly
and by the time it becomes painful,
the problem is too big to address
 Frog in gradually heated water
analogy:
– The problem with little things is that
none of them is big enough to scare
you into action, but they keep
creeping up and by the time you get
alarmed the problem is too difficult to
handle
– Consequently, “design smells”
accumulate, “technical debt” grows,
and the result is “software rot” https://en.wikipedia.org/wiki/Design_smell
https://en.wikipedia.org/wiki/Technical_debt
https://en.wikipedia.org/wiki/Software_rot

6
 The Role of Software Engg. (1)
A bridge from customer needs to programming implementation

Customer
Customer
Programmer

First law of software engineering

Software engineer is willing to learn the problem domain
(problem cannot be solved without understanding it first) 7
 The Role of Software Engg. (2)
Customer:
Requires a computer system to achieve some business goals
by user interaction or interaction w ith the problem domain
in a specified manner

System-to-be
(includes hardware)

Problem Domain
Software-to-be
User

Software Engineer’s task:

To understand how the system-to-be needs to interact w ith
the user or the problem domain so that customer’s requirement is met
and design the software-to-be

May be the Programmer’s task:

same person To implement the software-to-be
designed by the software engineer

8
 Example: ATM Machine
Understanding the money-machine problem:

Communication link
1
4 2
7 5 3
8 6
0 9

Bank’s
remote
ATM machine
datacenter
Bank
customer
9
 Problem-solving Strategy

Divide-and-conquer:
Identify logical parts of the system that each solves a
part of the problem
Easiest done with the help of a domain expert who
already knows the steps in the process (“how it is
currently done”)
Result:
A Model of the Problem Domain
(or “domain model”)

10
 How ATM Machine Might Work
Domain Model

Transaction
How may I record
help you? Cash

Bookkeeper
Speakerphone Safe
Safe keeper
Phone

Window clerk

Datacenter
liaison

Dispenser

Bank’s
remote
datacenter 11
Customer
Cartoon Strip : How ATM Machine Works

A Enter B C Verify
account
D
your PIN
XYZ
Verify
this
account

Typing in XYZ valid. Account

PIN number Balance: valid.
… $100 Balance:
$100

E How may F Release

G Record
I help $60 $60 less
you?

Withdraw Dispense
H Dispensing!

$60 $60
Please take
your cash

12
 Software Engineering Blueprints

 Specifying software problems and solutions is like

cartoon strip writing
 Unfortunately, most of us are not artists, so we will use
something less exciting:
UML symbols
 However …

13
 Second Law of Software Engineering

 Software should be written for people first

– ( Computers run software, but hardware quickly
becomes outdated )
– Useful + good software lives long

– To nurture software, people must be able to understand

it

14
 Software Development Methods

 Method = work strategy

 The Feynman Problem-Solving Algorithm:
(i) Write down the problem (ii) think very hard, and
(iii) write down the answer.
 Waterfall
 Unidirectional, finish this step before moving to the next
 Iterative + Incremental
 Develop increment of functionality, repeat in a feedback loop
 Agile
 Continuous user feedback essential; feedback loops on several levels
of granularity

15
 Waterfall Method

Requirements

Design

Implementation

Testing
Waterfall
method Deployment &
Maintenance

Each activity confined to its “phase”.

Unidirectional, no way back;
finish this phase before moving to the next 16
 UML – Language of Symbols
UML = Unified Modeling Language
«interface»
Stereotype
BaseInterface
«» provides
ClassName additional info/
+ operation()
annotation/
# attribute_1 : int explanation
Three common # attribute_2 : boolean
compartments: # attribute_3 : String
1. Classifier name Inheritance
+ operation_1() : void relationship:
+ operation_2() : String Class1Implement Class2Implement
2. Attributes BaseInterface
+ operation_3(arg1 : int) is implemented
+ operation() + operation()
3. Operations by two classes
Software Class
Actor Comment Software Interface Implementation

instance1 : Class1 instance5 : Class2 instance8 : Class3

doSomething()
doSomethingElse()

Interaction Diagram
doSomethingYetElse()
Online information:
http://www.uml.org
17
 How Much Diagramming?
 Use informal, ad-hoc, hand-drawn, scruffy diagrams during
early stages and within the development team
– Hand-drawing forces economizing and leads to low emotional
investment
• Economizing focuses on the essential, most important considerations
– Prioritize substance over the form
• Not being invested facilitates critique and suggested modifications
– Always take snapshot to preserve records for future
 Use standardized, neat, computer-generated diagrams when
consensus reached and designs have “stabilized”
– Standards like UML facilitate communication with broad range of
stakeholders
– But, invest effort to make neat and polished diagrams only when
there is an agreement about the design, so this effort is worth doing
• Invest in the form, only when the substance is worth such an investment

18
 Understanding the Problem Domain

 System to be developed

 Actors
– Agents external to the system that interact with it

 Concepts/ Objects
– Agents working inside the system to make it function

 Use Cases
– Scenarios for using the system
19
 ATM: Gallery of Players

1
4 2
7 5 3
8 6
0 9

Bank customer System Bank’s remote

(ATM machine) datacenter

Actors (Easy to identify because they are visible!)

20
 Gallery of Workers + Tools

Window clerk Datacenter Bookkeeper Safe keeper Dispenser

liaison

Speakerphone Telephone Transaction Safe Cash

record

Concepts (Hard to identify because they are invisible/imaginary!) 21

 Use Case: Withdraw Cash
A Enter
B Verify
account C How may
your PIN XYZ I help
you?

1
4 2
7 5 63 1
8 4 2
0 9 7 5 3
8 6
0 9

Typing in XYZ valid. Withdraw

PIN number Balance: $60
… $100

D E XYZ
Please take
your cash withdrew
$60

1
4 2
7 5 63
8
0 9

Collecting
cash …
Acknowledged

22
 How ATM Machine Works (2)
Domain Model (2)

Solution
Alternative modification
solution
Transaction
How may I record
help you?

Bookkeeper
Speakerphone

Draftsman
Window clerk

Dispenser

Customer
 How ATM Machine Works (3)
Domain Model (3)

Alternative Solution
modification
solution
Transaction
How may I record
help you?

Bookkeeper
Speakerphone
Courier

Window clerk

Dispenser

Remote
bank
Customer
Which solution is the best or even feasible?
 Rube Goldberg Design
Garage door opener

25
 Actual Design
Operator (includes motor and radio control mechanism)

1
2
Remote control transmitter
6

3
5 7 Rail with a belt or chain

4 5
6
8

Pressing of a button on the remote control transmitter (1)

authenticates the device & activates the motor in the operator (2).
The motor pulls the chain (or belt) along the rail (3) and winds
the torsion spring (4).
Garage door
The torsion spring winds the cable on the pulleys (or drums) (5)
on both sides of the door.
The cables lift the door, pushing the different sections of the door
into the horizontal tracks (6)
At the same time, the trolley (or traveler) (7) moves along the rail (3)
and controls how far the door opens (or closes),
Safety reversing sensor
as well as the force the garage door exerts by way of the curved door arm (8)    26
 Feasibility & Quality of Designs

 Judging feasibility or quality of a design requires great

deal of domain knowledge
(and commonsense knowledge!)

27
 Software Measurement

 What to measure?
– Project (developer’s work),
for budgeting and scheduling
– Product,
for quality assessment

28
Formal hedge pruning

29
 Work Estimation Strategy

1. Make initial guess for a little part of the work

2. Do a little work to find out how fast you can go

3. Make correction on your initial estimate

4. Repeat until no corrections are needed
or work is completed

30
 Sizing the Problem (1)
Step 1: Divide the problem into small & similar parts

  Step 2:
Estimate relative

sizes of all parts

Size(  ) = 4
 Size(  ) = 7
Size(  ) = 10
Size(  ) = 3
Size(  ) = 4
 
 Size(  ) = 2
Size(  ) = 4
Size(  ) = 7
 Sizing the Problem (2)

 Step 3: Estimate the size of the total work

Total size =  points-for-section i (i = 1..N)

 Step 4: Estimate speed of work (velocity)

 Step 5: Estimate the work duration

Path size
Travel duration =
Travel velocity
 Sizing the Problem (3)
 Assumptions:
– Relative size estimates are accurate
• That’s why parts should be small & similar-size!
 Advantages:
– Velocity estimate may need to be adjusted (based on
observed progress)
– However, the total duration can be recomputed quickly
• Provided that the relative size estimates of parts are accurate
—accuracy easier achieved if the parts are small and similar-size

Unfortunately:
 Unlike hedges, software is mostly invisible and
does not exist when project is started
 The initial estimate hugely depends on experience and imagination
 Exponential Cost of Estimation
100%

Estimation accuracy

Estimation cost

 Improving accuracy of estimation beyond a certain point requires huge

cost and effort (known as the law of diminishing returns)
 In the beginning of the curve, a modest effort investment yields huge
gains in accuracy
34
 Estimation Error Over Time

Estimation
error Waterfall Method

Requirements Design Implementation

Start Completion Time

Waterfall method cone of uncertainty starts high and gradually

converges to zero as the project approaches completion.
 Estimation Error Over Time

Estimation
error
Agile Method

Leaps in estimation accuracy

gained through feedback
after completing parts of work

Requirements
Design
Implementation Requirements
Design Requirements
Start Implementation Design
Implementation
Project Time
1st iteration completion Completion
2nd iteration completion

Agile method cone of uncertainty starts high and in leaps

converges to zero as the project approaches completion.
 Agile Project Effort Estimation

Estimated work duration

Work backlog
1) Prune Section 8 3.5 days (7pts)
2) Prune Section 7 2 days (4pts)
Items pulled by the team into an iteration
3) Prune Section 6 1 day (2pts)
4) Prune Section 5 2 days (4pts)

5) Prune Section 4 1.5 days (3p)

6) Prune Section 1 2 days (4pts)

7) Prune Section 2 3.5 days (7p)

8) Prune Section 3 5 days (10p)

Work items
21 days

1st iteration 2nd iteration n-th iteration

5 days
List prioritized by the customer Estimated completion date Time
37
 Measuring Quality of Work

Good Shape Poor Shape

(Low branches get sun) (Low branches
shaded from sun) Heading back not
recommended as
it alters the natural
shape of the shrub
Remove dead wood
Remove water spouts
and suckers

Rounded forms, which

Snow accumulates Straight lines require Peaked and rounded tops
follow nature’s tendency,
on broad flat tops more frequent trimming hinder snow accumulation
require less trimming
38
 Concept Maps
Useful tool for problem domain description

SENTENCE: “My friend is coding a new program”

translated into propositions

I
Proposition Concept Relation Concept
have
1. I have friend
2. friend engages in coding friend

3. coding constructs a program engages in

4. program is new coding

constructs a

program
is
Search the Web for Concept Maps new
39
 Case Study: Home Access Control

 Objective: Design an electronic system for:

– Home access control
• Locks and lighting operation
– Intrusion detection and warning

Alarm bell
System

Light bulb
1
2
3
4
5
X
Y

Lock Photosensor Switch

40
 Case Study – More Details

Alarm bell
System

1
2
3
4
Light bulb
Central
5
X
Y

Computer

Lock Photosensor Switch

Backyard doors:
External &
Internal lock

Front doors:
External &
Internal lock
41
 Know Your Problem
Mortise Lock Parts 1 Lock case
1 4 5 2 Latch bolt
6 3 Dead bolt
2 4 Strike plate
9
5 Strike box
6 Protective plate
3
7 Thumb-turn
7 8 Lock cylinder
9 Left hand lever
8

1
2
3
4
5
X
Y

42
 Concept Map for Home Access Control

tenant

enters

wishes key

can be
upper bound on failed attempts
causes valid key invalid key
lock opened
can be prevented by enforcing
may signal

burglar launches dictionary attack

43
 States and Transition Rules

IF validKey AND holdOpenInterval THEN unlock

IF validKey THEN unlock

locked unlocked

IF pushLockButton THEN lock

IF timeAfterUnlock ≥ max{ autoLockInterval, holdOpenInterval } THEN lock

… what seemed a simple problem, now is becoming complex 44