Introduction. Course Information

1.

LECTURE 1: Introduction

2. Course Information

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

3. Introduction: Software is Complex

Complex complicated
Complex = composed of many simple parts
related to one another
Complicated = not well understood, or explained

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

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

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

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

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

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

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

11. How ATM Machine Might Work

Domain Model
How may I
help you?
Transaction
record
Cash
Bookkeeper
Speakerphone
Safe keeper
Safe
Phone
Window clerk
Datacenter
liaison
Dispenser
Customer
Bank’s
remote
datacenter
11

12. Cartoon Strip: How ATM Machine Works

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
12

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

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

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

16. Waterfall Method

Requirements
Design
Implementation
Waterfall
method
Testing
Each activity confined to its “phase”.
Unidirectional, no way back;
finish this phase before moving to the next
Deployment &
Maintenance
16

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

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

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

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!)
20

21. Gallery of Workers + Tools

Window clerk
Datacenter
liaison
Bookkeeper
Safe keeper
Dispenser
Speakerphone
Telephone
Transaction
record
Safe
Cash
Concepts (Hard to identify because they are invisible/imaginary!)
21

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
Typing in
PIN number
…
1
4 2
7 85 6 3
0 9
XYZ valid.
Balance:
$100
D
Withdraw
$60
E
Please take
your cash
XYZ
withdrew
$60
1
4 2
7 85 6 3
0 9
Collecting
cash …
Acknowledged
22

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

24. 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
Customer
Which solution is the best or even feasible?
Remote
bank

25. Rube Goldberg Design

Garage door opener
25

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)
26

27. Feasibility & Quality of Designs

Feasibility & Quality of Designs
Judging feasibility or quality of a design
requires great deal of domain knowledge
(and commonsense knowledge!)
27

28. Software Measurement

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

29. Formal hedge pruning

29

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

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

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

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

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

35. Estimation Error Over Time

Estimation
error
Requirements
Start
Waterfall Method
Design
Implementation
Completion
Time
Waterfall method cone of uncertainty starts high and gradually
converges to zero as the project approaches completion.

36. Estimation Error Over Time

Estimation
error
Agile Method
Leaps in estimation accuracy
caused by insight about the overall
project, gained through completion
of parts of work
Requirements
Design
Implementation
Start
Requirements
Design
Implementation
Requirements
Design
Implementation
Part 1 completion
Project
Completion
Part 2 completion
Agile method cone of uncertainty starts high and in leaps
converges to zero as the project approaches completion.
Time

37. Agile Project Effort Estimation

37

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

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

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

41. Case Study – More Details

Alarm bell
System
1
2
3
4
5
X
Y
Lock
Light bulb
Photosensor
Switch
41

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

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

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