CSE 403Software Engineering

Spring 2020

Software design and best practices

April 22, 2020

Logistics

In-class exercise 1: Friday 04/24● Set up your machine

○ Git, Java 8+ JDK, and Apache Ant

● Test your set-up○ https://bitbucket.org/rjust/basic-stats○ Clone, build, and test (testMedian is supposed to fail)

● (Optional) pair up by Thursday (group In-class-1 on Canvas).

Logistics

In-class exercise 1: Friday 04/24● Set up your machine

○ Git, Java 8+ JDK, and Apache Ant

● Test your set-up○ https://bitbucket.org/rjust/basic-stats○ Clone, build, and test (testMedian is supposed to fail)

● (Optional) pair up by Thursday (group In-class-1 on Canvas).

Progress report and meeting agenda● Every Wednesday by 10pm● Markdown file in a publicly or UW-NetID accessible git repo● https://homes.cs.washington.edu/~rjust/courses/2020Spring/CSE403/project.html

Recap: software architecture vs. design

Architecture and design● Components and interfaces: understand, communicate, reuse● Manage complexity: modularity and separation of concerns● Process: allow effort estimation and progress monitoring

View Controller

Model

Client uses

manipulatesupdates

seesPresentation layer

Business logic layer

Data access layer DB

Client

Today

● Software design● How to avoid bugs in your program● Best practices

SW Design: Purposes, Concepts, and Misfits

Concept and motivating purpose

“A concept is something you needto understand in order to use anapplication (and also something adeveloper needs to understand towork effectively with its code) andis invented to solve a particularproblem, which is called the motivating purpose.”

Use case are a good starting pointfor defining concepts for motivating purposes.

Operational principle and misfit

“A concept is defined by an operationalprinciple, which is a scenario that illustrateshow the concept fulfills its motivating purpose.”

Operational principle and misfit

“A concept is defined by an operationalprinciple, which is a scenario that illustrateshow the concept fulfills its motivating purpose.”

“A concept may not be entirely fit for purpose.In that case, one or more operational misfitsare used to explain why. The operational misfitusually does not contradict the operationalprinciple, but presents a different scenario inwhich the prescribed behavior does not meet a desired goal.”

Properties of a good software design

MotivationEach concept should be motivated by at least one purpose.

CoherenceEach concept should be motivated by at most one purpose.

FulfillmentEach purpose should motivate at least one concept.

Non-divisionEach purpose should motivate at most one concept.

DecouplingConcepts should not interfere with one another’s fulfillment of purpose.

Properties of a good software design

MotivationEach concept should be motivated by at least one purpose.

CoherenceEach concept should be motivated by at most one purpose.

FulfillmentEach purpose should motivate at least one concept.

Non-divisionEach purpose should motivate at most one concept.

DecouplingConcepts should not interfere with one another’s fulfillment of purpose.

Properties of a good software design

MotivationEach concept should be motivated by at least one purpose.

CoherenceEach concept should be motivated by at most one purpose.

FulfillmentEach purpose should motivate at least one concept.

Non-divisionEach purpose should motivate at most one concept.

DecouplingConcepts should not interfere with one another’s fulfillment of purpose.

Properties of a good software design

MotivationEach concept should be motivated by at least one purpose.

CoherenceEach concept should be motivated by at most one purpose.

FulfillmentEach purpose should motivate at least one concept.

Non-divisionEach purpose should motivate at most one concept.

DecouplingConcepts should not interfere with one another’s fulfillment of purpose.

How to avoid bugs in your code?

How to avoid bugs in your code?

It’s super simple...don’t introduce them during coding!

Everybody makes mistakes, except for me…

But then, there is just one of me.

How to avoid bugs in your code?

A more realistic approach: 3 steps

1. Make certain bugs impossible by design2. Correctness: get it right the first time3. Bug visibility

How to avoid bugs in your code?

A more realistic approach: 3 steps

1. Make certain bugs impossible by designa. Programming language

i. Ever had a use-after free bug in a Java program?ii. Ever had an assignment bug (String to Integer) in a statically typed language?

b. Libraries and protocolsi. TCP vs. UDPii. No overflows in BigInteger

How to avoid bugs in your code?

A more realistic approach: 3 steps

1. Make certain bugs impossible by designa. Programming language

How to avoid bugs in your code?

A more realistic approach: 3 steps

1. Make certain bugs impossible by designa. Programming language

Pick the right tool for the job...

How to avoid bugs in your code?

A more realistic approach: 3 steps

1. Make certain bugs impossible by designa. Programming language

Pick the right tool for the job...if possible!

How to avoid bugs in your code?

A more realistic approach: 3 steps

1. Make certain bugs impossible by designa. Programming languageb. Libraries and protocols

2. Correctness: get it right the first timea. A program without a spec is bug freeb. Keep it simple, modular, and testablec. Defensive programming and conventions (discipline)

How to avoid bugs in your code?

A more realistic approach: 3 steps

1. Make certain bugs impossible by designa. Programming languageb. Libraries and protocols

2. Correctness: get it right the first timea. A program without a spec is bug freeb. Keep it simple, modular, and testablec. Defensive programming and conventions (discipline)

3. Bug visibilitya. Assertions (pre/post conditions)b. (Regression) testingc. Fail fast

Quiz: setup and goals● Each project group is a team● 6 code snippets● 2 rounds

○ First round■ For each code snippet, decide whether it represents good or bad practice.■ Goal: discuss and reach consensus on good or bad practice.

○ Second round (known “solutions”)■ For each code snippet, try to understand why it is good or bad practice.■ Goal: come up with an explanation or a counter argument.

Round 1: good or bad?

Snippet 1: good or bad?

…

…

Snippet 2: good or bad?

Snippet 3: good or bad?

…

…

Snippet 4: good or bad?

Snippet 5: good or bad?

…

…

…

Snippet 6: good or bad?

Round 2: why is it good or bad?

My take on this

● Snippet 1: bad

● Snippet 2: bad

● Snippet 3: good

● Snippet 4: bad

● Snippet 5: bad

● Snippet 6: good

Snippet 1: this is bad! why?

…

…

Snippet 1: this is bad! why?

…

…

Null references...the billion dollar mistake.

Snippet 1: this is bad! why?

…

…

… Don’t return null; return an empty array instead.

Snippet 1: this is bad! why?

…

…

No diagnostic information.

Snippet 2: short but bad! why?

Snippet 2: short but bad! why?

Defensive programming: add an assertion (or write the literal first).Use constants and enums to avoid literal duplication.

Snippet 3: this is good, but why?

…

…

Snippet 3: this is good, but why?

…

…

Type safety using an enum; throws an exception for unexpected cases (e.g., future extensions of PaymentType).

Snippet 4: also bad! huh?

Snippet 4: also bad! huh?

Method parameters should be final;use local variables to sanitize inputs.

Snippet 5: Java API, but still bad! why?

…

…

…

Snippet 5: Java API, but still bad! why?

…

…

…

What does the last call return?

Snippet 5: Java API, but still bad! why?

…

…

…

Avoid method overloading, which is statically resolved. Autoboxing/unboxing adds additional confusion.

Snippet 6: this is good, but why?

Snippet 6: this is good, but why?

Good encapsulation; immutable object.