SLIDE 1 Software Engineering I (02161)
Introduction to Software Engineering
- Assoc. Prof. Hubert Baumeister
DTU Compute Technical University of Denmark
Spring 202
SLIDE 2 Software project challenges
Challenges: On time, within budget, without bugs, and does what the customer needs it to do Failed or challenged ◮ Amanda ◮ Rejsekortet ◮ Obamacare Website ◮ German road toll system ◮ . . . Success rate for software projects 2000—2008
2000 2002 2004 2006 2008 0% 20% 40% 60% 80% 100% challenged failed succeeded
CHAOS Summary 2009 Report
◮ Succeeded: 32% ◮ Failed: 20% ◮ Challenged: 48% (over time, over budget, . . . )
SLIDE 3
Scaling software development
Small hut ◮ one person ◮ no special knowledge Skyscraper ◮ not possible with one person ◮ special knowledge: static, electricity, water, waste, elevator, . . .
SLIDE 4
Small software — large software: bug fixing
Small program ◮ find the defect ◮ fix the defect ◮ adjust docu- mentation Large software ◮ report defect ◮ collect defect reports ◮ analyse problem ◮ identify bug ◮ define a bug fixing strategy ◮ fix the bug ◮ testing: bug fixed; no new bugs ◮ accept the fixed version ◮ integrate parallel changes ◮ update release documentation ◮ release the new system
SLIDE 5
What belongs to software?
◮ 10.000 LOC program, no special knowledge needed: How much time? ◮ Industry estimate: 13.5 person month: around 39 LOC per work day per person. ◮ How much time for a 100.000 LOC program? ◮ 170 person months ◮ Software development is more than programming
◮ Validation (e.g. tests) ◮ Documentation (User–, System–) ◮ Configuration files ◮ . . .
SLIDE 6
Software attributes
◮ Maintainability
◮ Readable code (clean code, self documenting code, good documentation) ◮ Reduce complexity (Design Pattern, low coupling/high cohesion)
◮ Dependability and security
◮ Includes: reliability (robustness), privacy, and safety ◮ Example: Apple root access on macOS
◮ Efficiency
◮ Don’t waste system resources ◮ Responsiveness, processing time, memory utilisation
◮ Acceptability / user friendliness
SLIDE 7
Acceptability / user friendliness
SLIDE 8
Acceptability / user friendliness
SLIDE 9
Program vs product
Factor 3—20 from program to product
SLIDE 10
Software Engineering
Young disciplin: 1968 Nato conference
Software Engineering Definition (Sommerville 2010)
Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use
SLIDE 11
Basic Activities in Software Development
◮ Understand and document what kind of the software the customer wants
→ Requirements Analysis ◮ Use cases, user stories, domain model
◮ Determine how the software is to be built
→ Software Design ◮ Class diagrams, sequence diagrams, CRC cards, design patterns
◮ Build the software
→ Implementation ◮ Good design principles, layered architecture, S.O.L.I.D principles, design by contract
◮ Validate that the software solves the customers problem
→ Test ◮ automated vs manual tests, Test- and behvaiour driven development (TDD/BDD), black-box and white-box tests, code coverage
SLIDE 12
Example Vending Machine Controller
Controller software for a vending machine
SLIDE 13
Requirements: Glossary
Purpose: ◮ Understand the problem domain ◮ Common language Example ◮ Vending machine: The vending machine allows users to buy fruit. ◮ User: The user of the vending machine buys fruit by inserting coins into the machine. ◮ Owner: The owner owns the vending machine. He is required to refill the machine and can remove the money from the machine. ◮ Display: The display shows how much money the user has inserted. . . .
SLIDE 14
Requirements: Use case diagram
Cancel Buy fruit Vending Machine User
SLIDE 15
Requirements: Detailed Use Case: Buy Fruit
Feature: Buy fruit Description: A user buys a fruit from the vending machine Actors: User Scenario: Buy a fruit with enough money Given the vending machine has fruits When the user enters enough money for a fruit And the user selects a fruit Then the fruit will be dispensed And the machine returns the rest money And the machine remembers its earnings ... (More scenarios)
SLIDE 16
Validation: Specify success criteria: Acceptance tests
Use detailed use cases directly (Cucumber)
Scenario: Buy a fruit with enough money Given the vending machine has fruits When the user enters enough money for a fruit And the user selects a fruit Then 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()); }
SLIDE 17
Vending Machine: Design and implementation
◮ Determine how the software is to be built
→ Class diagrams → Sequence diagrams → State machines
◮ Build the software
SLIDE 18 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() <<enumeration>> Fruit APPLE BANANA *
SLIDE 19 Application logic as a state machine
event guard state state state Idle (I) banana banana
banana
apple apple
apple
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
return current money
SLIDE 20 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) <<interface>> VendingMachineState input(m: VendingMachine, money: int) select(m: VendingMachinef: fruit) cancel(m: VendingMachine) VendingMachine dispensedItem: 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) <<enumeration>> Fruit APPLE BANANA state * 1
SLIDE 21 Design: Visualization of the Execution
◮ Interaction Diagrams, aka. Sequence Diagrams
◮ used for designing the system ◮ used for documenting the system
◮ Vending Machine
Vending 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
