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
• Teaching Assistant:
Swapnil Mhaske <smhaske@eden.rutgers.edu>
2
Team Projects
• Form teams of 6 (± 1?) students
DEADLINE: Friday, January 25, 2013
After that, teams assigned randomly
• Project Ideas:
http://www.ece.rutgers.edu/~marsic/books/SE/projects
• No more than two (2) groups working on the
same project
• One (1) new project allowed
• Email your project idea ASAP, before proposal is due, for feedback
3
Personal Health Monitoring Devices
Available budget:
$500
To do:
1. Search the Web
for devices and apps
that you would like to
work with
2. Email the components
list with costs+websites
4
Project Deliverables
Item
I
t
e
r
a
t.
#1
1. Proposal
2. First report (Specification only)
• Part 1 (Statement of Work & Requirements)
• Part 2 (Functional Requirements Spec & UI)
• Full Report #1
3. Second report (Design only)
• Part 1 (Interaction Diagrams)
• Part 2 (Class Diagram and System Architecture)
• Full Report #2
4. First demo
5. Third report (All reports collated)
6. Second demo
I
t
e
r #2 7. Electronic Project Archive
Due date
January 29
February 12
February 18
February 22
March 1
March 8
March 15
April 2 ► ...
April 27
May 1 ► ...
May 3
5
Team 1
Team
Project
Grading
Team 2
Team 3
Earned points
30
pts
30
pts
30
pts
21 p
50 pts
21 pts
26
pts
12 p
35
pts
Project grade
100
70
100
Team
T1
T2
T3
Project
grade
100%
70%
100%
Member
ID
Earned
points
Adjusted
points
Normalized
points
M1,1
30
30
(30/35 * 100) = 86
M1,2
30
30
(30/35 * 100) = 86
M1,3
30
30
(30/35 * 100) = 86
M2,1
21
(21 * 0.7) = 14.7
(14.7/35 * 100) = 42
M2,2
50
(50 * 0.7) = 35
100
M3,1
21
21
(19/35 * 100) = 60
M3,2
12
12
(12/35 * 100) = 34
M3,3
35
35
100
M3,4
26
26
(26/35 * 100) = 74
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
Setting posts
[ 3 time units ]
Cutting wood
[ 2 time units ]
Nailing
[ 2 time units for unpainted;
3 time units otherwise ]
Painting
[ 5 time units for uncut wood;
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 ]
8
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 Role of Software Engg. (1)
A bridge from customer needs to programming implementation
Customer
Programmer
First law of software engineering
Software engineer is willing to learn the problem domain
(problem cannot be solved without understanding it first)
10
The Role of Software Engg. (2)
Customer:
Requires a computer system to achieve some business goals
by user interaction or interaction with the environment
in a specified manner
System-to-be
User
Software-to-be
Environment
Software Engineer’s task:
To understand how the system-to-be needs to interact with
the user or the environment so that customer’s requirement is met
and design the software-to-be
May be the
same person
Programmer’s task:
To implement the software-to-be
designed by the software engineer
11
Example: ATM Machine
Understanding the money-machine problem:
7
4
1
0
2
5 3
8 6
9
ATM machine
Communication link
Bank’s
remote
datacenter
Bank
customer
12
How ATM Machine Might Work
Domain Model
Domain model
created with help
of domain expert
How may I
help you?
Transaction
record
Cash
Bookkeeper
Speakerphone
Safe keeper
Safe
Phone
Window clerk
Datacenter
liaison
Dispenser
Customer
Bank’s
remote
datacenter
13
Cartoon Strip
A
: How ATM Machine Works
Enter
your PIN
C
B
Verify
account
XYZ
D
Verify
this
account
Typing in
PIN number
…
E
How may
I help
you?
Withdraw
$60
Account
valid.
Balance:
$100
XYZ valid.
Balance:
$100
F
G
Release
$60
Dispense
$60
Record
$60 less
H
Dispensing!
Please take
your cash
14
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 …
15
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
16
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
 User feedback essential; feedback loops on several levels of
granularity
17
Waterfall Method
Requirements
Design
Implementation
Waterfall
method
Testing
Unidirectional, no way back
finish this step before moving to the next
Deployment &
Maintenance
18
UML – Language of Symbols
UML = Unified Modeling Language
«interface»
BaseInterface
ClassName
# attribute_1 : int
# attribute_2 : boolean
# attribute_3 : String
Three common
compartments:
Actor
1.
Classifier name
2.
Attributes
3.
Operations
+ operation()
+ operation_1() : void
+ operation_2() : String
+ operation_3(arg1 : int)
Class1Implement
Class2Implement
+ operation()
+ operation()
Stereotype
«» provides
additional info/
annotation/
explanation
Inheritance
relationship:
BaseInterface
is implemented
by two classes
Software Class
Comment
Software Interface Implementation
instance1 : Class1
instance5 : Class2
doSomething()
instance8 : Class3
doSomethingElse()
Interaction Diagram
doSomethingYetElse()
Online information:
http://www.uml.org
19
Understanding the Problem Domain
• System to be developed
• Actors
– Agents external to the system
• Concepts/ Objects
– Agents working inside the system
• Use Cases
– Scenarios for using the system
20
ATM: Gallery of Players
1
7
4
0
Bank customer
Actors
8
5
2
9
6
3
System
(ATM machine)
Bank’s remote
datacenter
(Easy to identify because they are visible!)
21
Gallery of Workers + Things
Window clerk
Datacenter
liaison
Bookkeeper
Safe keeper
Dispenser
Speakerphone
Telephone
Transaction
record
Safe
Cash
Concepts (Hard to identify because they are invisible/imaginary!)
22
Use Case: Withdraw Cash
A
B
Verify
account
XYZ
Enter
your PIN
C
How may
I help
you?
1
4 2
7 85 6 3
0 9
1
4 2
7 85 6 3
0 9
XYZ valid.
Balance:
$100
Typing in
PIN number
…
D
E
Please take
your cash
7
4
1
0
Collecting
cash …
Withdraw
$60
8
XYZ
withdrew
$60
2
5 63
9
Acknowledged
23
How ATM Machine Works (2)
Domain Model (2)
Solution
modification
Alternative
solution
How may I
help you?
Transaction
record
Bookkeeper
Speakerphone
Draftsman
Window clerk
Dispenser
Customer
How ATM Machine Works (3)
Domain Model (3)
Alternative
solution
Solution
modification
How may I
help you?
Transaction
record
Bookkeeper
Speakerphone
Courier
Window clerk
Dispenser
Remote
bank
Customer
Which solution is the best or even feasible?
Rube Goldberg Design
Garage door opener
26
Actual Design
Operator (includes motor and radio control mechanism)
1
2
Remote control transmitter
6
5
3
7
4
Rail with a belt or chain
5
8
6
Pressing of a button on the remote control transmitter (1)
Garage door
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).
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)   
27
Software Measurement
• What to measure?
– Project (developer’s work),
for budgeting and scheduling
– Product,
for quality assessment
28
Formal hedge pruning
29
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
Travel duration =
Path size
Travel velocity
Sizing the Problem (3)
• Advantages:
– Velocity estimate may need to be adjusted (based on
observed progress)
– However, the total duration can be computed quickly
(provided that the relative size estimates of parts are
accurate – easier to achieve if the parts are small and
similar-size)
Exponential Cost of Estimation
Estimation accuracy
100%
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
33
Estimation Error Over Time
Estimation
error
Requirements
Start
Design
Implementation
Completion
Time
The cone of uncertainty starts high and narrows down to zero
as the project approaches completion.
Agile Project Effort Estimation
35
Measuring Quality of Work
Good Shape
(Low branches get sun)
Snow accumulates
on broad flat tops
Poor Shape
(Low branches
shaded from sun)
Straight lines require
more frequent trimming
Heading back not
recommended as
it alters the natural
shape of the shrub
Peaked and rounded tops
hinder snow accumulation
Remove dead wood
Remove water spouts
and suckers
Rounded forms, which
follow nature’s tendency,
require less trimming
36
Concept Maps
Useful tool for problem domain description
SENTENCE: “My friend is coding a new program”
translated into propositions
Proposition Concept
Relation
I
Concept
1.
I
have
friend
2.
friend
engages in
coding
3.
coding
constructs a
program
4.
program
is
new
have
friend
engages in
coding
constructs a
program
is
Search the Web for Concept Maps
new
37
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
1
2
3
4
5
X
Y
Light bulb
Lock
Photosensor
Switch
38
Case Study – More Details
Alarm bell
System
1
2
3
4
5
X
Y
Lock
Light bulb
Photosensor
Switch
39
Know Your Problem
Mortise Lock Parts
1 Lock case
4
1
2 Latch bolt
3 Dead bolt
6
2
9
5
4 Strike plate
5 Strike box
3
7
6 Protective plate
7 Thumb-turn
8 Lock cylinder
8
9 Left hand lever
1
2
3
4
5
X
Y
40
Concept Map for Home Access
Control
tenant
enters
wishes
key
can be
upper bound on failed attempts
lock opened
causes
valid key
invalid key
may signal
burglar
launches
can be prevented by enforcing
dictionary attack
41
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
42