Software Engineering I (02161) › courses › 02161 › 2020 › slides › 01... · Software...

21
Software Engineering I (02161) Introduction to Software Engineering Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 202

Transcript of Software Engineering I (02161) › courses › 02161 › 2020 › slides › 01... · Software...

Software Engineering I (02161)Introduction to Software Engineering

Assoc. Prof. Hubert Baumeister

DTU ComputeTechnical University of Denmark

Spring 202

Software project challenges

Challenges: On time, within budget, without bugs, and doeswhat the customer needs it to do

Failed or challengedI AmandaI RejsekortetI Obamacare WebsiteI German road toll systemI . . .

Success rate for softwareprojects 2000—2008

Sheet1

Page 1

2000 2002 2004 2006 2008

succeeded 28% 34% 29% 35% 32%

failed 23% 15% 18% 19% 24%

challenged 49% 51% 53% 46% 44%

2000 2002 2004 2006 2008

0%

20%

40%

60%

80%

100%

120%

challenged

failed

succeeded

CHAOS Summary 2009 Report

I Succeeded: 32%I Failed: 20%I Challenged: 48% (over

time, over budget, . . . )

Scaling software development

Small hutI one personI no special knowledge

SkyscraperI not possible with one

personI special knowledge: static,

electricity, water, waste,elevator, . . .

Small software — large software: bug fixing

Small programI find the defectI fix the defectI adjust docu-

mentation

Large softwareI report defectI collect defect reportsI analyse problemI identify bugI define a bug fixing strategyI fix the bugI testing: bug fixed; no new bugsI accept the fixed versionI integrate parallel changesI update release documentationI release the new system

What belongs to software?

I 10.000 LOC program, no special knowledge needed: Howmuch time?

I Industry estimate: 13.5 person month: around 39 LOC perwork day per person.

I How much time for a 100.000 LOC program?I 170 person monthsI Software development is more than programming

I Validation (e.g. tests)I Documentation (User–, System–)I Configuration filesI . . .

Software attributesI Maintainability

I Readable code (clean code, self documenting code, gooddocumentation)

I Reduce complexity (Design Pattern, low coupling/highcohesion)

I Dependability and securityI Includes: reliability (robustness), privacy, and safetyI Example: Apple root access on macOS

I EfficiencyI Don’t waste system resourcesI Responsiveness, processing time, memory utilisation

I Acceptability / user friendliness

Acceptability / user friendliness

Acceptability / user friendliness

Program vs product

Factor 3—20 from program to product

Software Engineering

Young disciplin: 1968 Nato conference

Software Engineering Definition (Sommerville 2010)

Software engineering is an engineering disciplinethat is concerned with all aspects of software productionfrom the early stages of system specificationthrough to maintaining the system after it has gone into use

Basic Activities in Software DevelopmentI Understand and document what kind of the software the

customer wants→ Requirements AnalysisI Use cases, user stories, domain model

I Determine how the software is to be built→ Software DesignI Class diagrams, sequence diagrams, CRC cards, design

patternsI Build the software

→ ImplementationI Good design principles, layered architecture, S.O.L.I.D

principles, design by contractI Validate that the software solves the customers problem

→ TestI automated vs manual tests, Test- and behvaiour driven

development (TDD/BDD), black-box and white-box tests,code coverage

Example Vending Machine Controller

Controller software for avending machine

Requirements: Glossary

Purpose:I Understand the problem domainI Common language

ExampleI Vending machine: The vending machine allows users to

buy fruit.I User: The user of the vending machine buys fruit by

inserting coins into the machine.I Owner: The owner owns the vending machine. He is

required to refill the machine and can remove the moneyfrom the machine.

I Display: The display shows how much money the user hasinserted.. . .

Requirements: Use case diagram

Cancel

Buy fruit

Vending Machine

User

Requirements: Detailed Use Case: Buy Fruit

Feature: Buy fruitDescription: A user buys a fruit from the vending machineActors: User

Scenario: Buy a fruit with enough moneyGiven the vending machine has fruitsWhen the user enters enough money for a fruitAnd the user selects a fruitThen the fruit will be dispensedAnd the machine returns the rest moneyAnd the machine remembers its earnings

... (More scenarios)

Validation: Specify success criteria: Acceptance testsUse detailed use cases directly (Cucumber)

Scenario: Buy a fruit with enough moneyGiven the vending machine has fruitsWhen the user enters enough money for a fruitAnd the user selects a fruitThen the fruit will be dispensed

VendingMachineSteps.java

@Given("the vending machine has fruits")public void theVendingMachineHasFruits() throws Exception {

vendingMachine = new VendingMachine(2,2);}@When("the user enters enough money for a fruit")public void theUserEntersEnoughMoneyForAFruit() throws Exception {

vendingMachine.input(3);}@When("the user selects a fruit")public void theUserSelectsTheFruit() throws Exception {

vendingMachine.selectFruit(Fruit.APPLE);}@Then("the fruit will be dispensed")public void theFruitWillBeDispensed() throws Exception {

assertEquals(Fruit.APPLE, vendingMachine.getDispensedItem());}

Vending Machine: Design and implementation

I Determine how the software is to be built→ Class diagrams→ Sequence diagrams→ State machines

I Build the software

Design: High-level Class diagram

VendingMachine

dispensedItem: Fruit {readOnly}currentMoney: int {readOnly}totalMoney: int {readOnly}restMoney: int {readOnly}

input(money: int)select(f: fruit)cancel()

<<enumera t i on>>Fruit

APPLEBANANA

*

Application logic as a state machine

event guard state state state

Idle (I)

banana

banana -> B -> B

banana -> I -> I

apple

apple -> A -> A

apple -> I -> I

money

money

money

cancel return current money

Banana selected and not enough money

(B)

Apple selected and not enough money

(A)

enough money for banana

dispense banana and rest money

dispense banana and rest money-> I

dispense banana and rest money-> I

not enough money for banana

no bananas available

enough money for apple

dispense apple and rest money -> I

dispense apple and rest money -> I

dispense apple and rest money -> I

not enough money for apple

no apples available

enough money for banana

add money to current money

dispense banana and rest money-> I

add money to current money

enough money for apple

add money to current money

add money to current money

dispense apple and rest money -> I

not enough money for neither banana nor apple

add money to current money

add money to current money

add money to current money

return current money -> I

return current money -> I

Design: Design of the system as class diagram

Use State pattern (a design pattern)

currentMoney += money;setChanged();notifyObserver("currentMoney")

state.input(money);

state.input(money);

state.input(money);

m.setIdleState();super.cancel(m);

super.input(m, i);if (m.hasEnoughMoneyFor(selectedFruit)) { m.setIdleState(); m.dispense(selectedFruit);}

m.dispense(null);

if (!m.hasFruit(fruit)) { m.setIdleState(); return;}if (m.hasEnoughMoneyFor(fruit)) { m.setIdleState(); m.dispense(fruit);} else { m.setCurrentStateForFruit(fruit);}

m.setCurrentMoney(m.getCurrentMoney() + i);

FruitSelectionState

input(m: VendingMachine, money: int)cancel(m: VendingMachine)

IdleState

input(m: VendingMachine, money: int)select(m: VendingMachinef: fruit)cancel(m: VendingMachine)

<<inter face>>VendingMachineState

input(m: VendingMachine, money: int)select(m: VendingMachinef: fruit)cancel(m: VendingMachine)

VendingMachinedispensedItem: Fruit {readOnly}currentMoney: int {readOnly}totalMoney: int {readOnly}restMoney: int {readOnly}input(money: int)select(f: fruit)cancel()~setCurrentMoney(money: int)~setIdleState()~dispense(f: Fruit)~setCurrentStateForFruit(f: Fruit)~hasFruit(f: Fruit)

<<enumerat ion>>Fruit

APPLEBANANA

state

*

1

Design: Visualization of the Execution

I Interaction Diagrams, aka. Sequence DiagramsI used for designing the systemI used for documenting the system

I Vending MachineVending Machine

select(APPLE)

select(APPLE)

hasEnoughMoney

false

setCurrentState(f)

input(3)

input(3)

hasEnoughMoney

true

dispense(APPLE)

setIdleState

User Vending Machine i:IdleState f:FruitSelectedState