Software Engineering I (02161) Introduction to Software Engineering - PowerPoint PPT Presentation

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

Software project challenges Challenges: On time, within budget, without bugs, and does what the customer needs it to do Success rate for software projects 2000—2008 100% 80% Failed or challenged challenged 60% failed succeeded ◮ Amanda 40% 20% ◮ Rejsekortet 0% 2000 2002 2004 2006 2008 ◮ Obamacare Website CHAOS Summary 2009 Report ◮ German road toll system ◮ Succeeded: 32% ◮ . . . ◮ Failed: 20% ◮ Challenged: 48% (over time, over budget, . . . )

Scaling software development Skyscraper ◮ not possible with one Small hut person ◮ one person ◮ special knowledge: static, ◮ no special knowledge electricity, water, waste, elevator, . . .

Small software — large software: bug fixing Large software ◮ report defect ◮ collect defect reports ◮ analyse problem Small program ◮ identify bug ◮ find the defect ◮ define a bug fixing strategy ◮ fix the defect ◮ fix the bug ◮ adjust docu- ◮ testing: bug fixed; no new bugs mentation ◮ accept the fixed version ◮ integrate parallel changes ◮ update release documentation ◮ release the new system

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

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

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

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

Example Vending Machine Controller Controller software for a vending machine

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

Requirements: Use case diagram Vending Machine Buy fruit Cancel User

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)

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()); }

Vending Machine: Design and implementation ◮ Determine how the software is to be built → Class diagrams → Sequence diagrams → State machines ◮ Build the software

Design: High-level Class diagram VendingMachine <<enumeration>> Fruit dispensedItem: Fruit {readOnly} currentMoney: int {readOnly} APPLE totalMoney: int {readOnly} BANANA restMoney: int {readOnly} * input(money: int) select(f: fruit) cancel()

Application logic as a state machine event guard state state state Banana selected and Apple selected and Idle (I) not enough money not enough money (B) (A) enough money for dispense banana and dispense banana and dispense banana and banana banana rest money rest money-> I rest money-> I not enough banana -> B -> B money for banana no bananas banana -> I -> I available enough money for dispense apple and dispense apple and dispense apple and apple apple rest money -> I rest money -> I rest money -> I not enough apple -> A -> A money for apple no apples apple -> I -> I available enough money for add money to current dispense banana and add money to current money banana money rest money-> I money enough money for add money to current add money to current dispense apple and money apple money money rest money -> I not enough add money to current add money to current add money to current money money for neither money money money banana nor apple return current money return current money cancel return current money -> I -> I

Design: Design of the system as class diagram Use State pattern (a design pattern ) VendingMachine <<interface>> m.setCurrentMoney(m.getCurrentMoney() + i); VendingMachineState dispensedItem: Fruit {readOnly} currentMoney: int {readOnly} input(m: VendingMachine, money: int) totalMoney: int {readOnly} state select(m: VendingMachinef: fruit) if (!m.hasFruit(fruit)) { state.input(money); restMoney: int {readOnly} cancel(m: VendingMachine) m.setIdleState(); input(money: int) return; state.input(money); select(f: fruit) } cancel() if (m.hasEnoughMoneyFor(fruit)) { ~setCurrentMoney(money: int) m.setIdleState(); state.input(money); ~setIdleState() m.dispense(fruit); ~dispense(f: Fruit) } else { IdleState ~setCurrentStateForFruit(f: Fruit) m.setCurrentStateForFruit(fruit); ~hasFruit(f: Fruit) currentMoney += money; input(m: VendingMachine, money: int) } setChanged(); select(m: VendingMachinef: fruit) notifyObserver("currentMoney") cancel(m: VendingMachine) m.dispense(null); super.input(m, i); * if (m.hasEnoughMoneyFor(selectedFruit)) { <<enumeration>> FruitSelectionState m.setIdleState(); Fruit m.dispense(selectedFruit); input(m: VendingMachine, money: int) APPLE } cancel(m: VendingMachine) BANANA 1 m.setIdleState(); super.cancel(m);

Design: Visualization of the Execution ◮ Interaction Diagrams , aka. Sequence Diagrams ◮ used for designing the system ◮ used for documenting the system ◮ Vending Machine Vending Machine User Vending Machine i:IdleState f:FruitSelectedState select(APPLE) select(APPLE) hasEnoughMoney false setCurrentState(f) input(3) input(3) hasEnoughMoney true dispense(APPLE) setIdleState