TNM082 Agil användbarhetsutveckling för handhållna enheter. Software Engineering. Karljohan Lundin Palmerius

Transcription

1 TNM082 Agil användbarhetsutveckling för handhållna enheter Software Engineering Karljohan Lundin Palmerius

2 Software Engineering Not programming => Software system development customer/producer negotiations budget and time constraints quality and feature requirements maintenance and system evolution

3 Software Engineering Processes Roles, activities, artefacts and work-flows Handling Quality, risk, scope, cost, schedule Scope Cost Schedule

4 Software Quality To whom? End user quality Developer/maintainer Interoperability Business value PR Often trade-off

5 The Development Process Guiding principles and constraints for optimizing work and communications for finding faults early Process overview help in finding inconsistencies help in finding redundancies help in finding omissions building a common understanding enabling reproducibility

6 Typiska aktiviteter Kravhantering (requirements) vad är mitt problem? Systemarkitektur (system architecture) vad behövs för att lösa problemet? Modul-design / programdesign (module design / program design) hur ska problemet lösas? Implementation (implementation) lös problemet! Enhetstest / modultest (unit testing / module testing) löstes problemet? Systemtest (system testing) är hela problemet löst? Leverans (delivery) leverera lösningen! Underhåll (maintenance) finns nya problem som behöver lösas?

7 Typical Activities System Architecture Top-down decomposition Module/Program Design Implementation Unit Testing Testing Integration Testing System Testing Acceptance Testing

8 Software Engineering in Scrum Sprint Planning Sprint Planning What to do How to do it Daily Work Scrum Task Work Sprint Review Retrospective Story Task Task Task

9 Software Engineering in Scrum Sprint Planning Sprint Planning What to do Architecture requirements How to do it Architecture refactoring Sprint Review Retrospective Story Module design Refactoring Execution test impl. Feature implementation Code review Unit test System test Acceptance test

10 Quality Aspects Many quality aspects and goals Modifiability Performance Security Reliability Robustness Usability Often trade-off

11 Modifiability Purpose easy to locate, analyse and fix faults easy to add, remove or modify features Means Modularity, interfaces, structure

12 Modularity Separation of concern I/O Database easier to understand and develop easier to maintain, use and reuse easier to locate faults Coupling Image Processor Audio Processor dependencies between modules references made, data passed, control applied uncoupled, loosely coupled, tightly coupled GUI Controller Cohesion dependencies inside a module does what it is supposed to do, no more and no less

13 Interfaces The connector to other modules keep it stable to avoid change propagation interface based on what not how avoid optimization through interfaces Specification purpose what is the interface (function) for preconditions assumptions, states, global resources, etc. protocols how is the interface used postconditions visible effects or changes quality attributes performance, reliability, etc. Database Image Processor Audio Processor

14 Security Resiliency recover quickly from attack segment functionality to minimize effect use strategies for quick functionality restoration Immunity not affected by attacks include security by design

15 Reliability Types of reliability reliable correct under assumed conditions robust survive invalid inputs or stressful conditions Fault Detection passive fault detection wait for failure active fault detection n-version programming diagnostic transactions Fault Recovery Undo Checkpoint/rollback Backup Degraded service Correct-and-continue

16 Robustness Defensive design mutual suspicion assume faulty input and states check against preconditions planned behaviour for failure

17 Architecture Modelling To better understand the system To provide a blueprint for construction To determine reuse To reason about future changes To analyse dependencies for design optimization To support management decisions and risk handling

18 Architecture Modelling Structural, systematic and systemic level Functional, quality and design requirements Connecting with system's general shape Decomposition of the systems inner workings Modifiability Performance Security Reliability Robustness Usability

19 Design Sources Reference models Other similar systems Experience Design conventions, idioms Design patterns New combinations of known architectures

20 Pipe-and-Filter Principles Standardized data format and filter principles Dynamic or static configuration Properties Module reuse, restructuring and replacement Constraints on data and filter format Source Filter Filter Sink Filter Filter Filter Filter

21 Publish-Subscribe Principles a component publishes data, others subscribe to them Properties extendible and promote module reuse data passing and synchronization may be expensive Component Component Component Component

22 Client-Server Principle Request-reply, potentially also callbacks or open streams Asymmetric relationship, star architecture Properties Centralized control Potential bottleneck and single-point-of-failure (SPOF) Server Client Client Client

23 Three-/Multi-tier System Principle strictly divided responsibilities, communicate-through Properties well known and understood responsibilities GUI Client Client Client Logics Server Data Database

24 Model-View-Controller Principle separation of concerns, directed communication Properties cleaner code, easier to identify faults easy to have multiple views of the one model care must be taken to avoid propagating changes View View View Controller Model

25 Layering Principles hierarchical structure based on abstraction strictly divided responsibilities, communicate-through Properties simplified interface, code reuse, maintainability possible negative performance impact Application Transport Network Physical layer Application Transport Network Physical layer

26 Peer-to-Peer Principles components communicate directly Properties low latency, no bottleneck poor control, hard to synchronize Node Node Node Node Node

27 Module Design Low level design module design, program design class structures, functions, calls, etc. Purpose there will be a design, make it explicit understanding and structuring documentation share the structure with future colleagues Approach top-down, bottom-up, outside-in Agile first approach is in slices, and refactor by bottom-up Image Processor Audio Processor Image Read/Write Audio Read/Write I/O FileIO WebDAV Networking

28 Module Design Most important design principles Modularity / composition Interfaces / information hiding Abstraction Generality

29 Important Aspects Inheritance vs composition Liskov Substitutability Principle Law of Demeter don't talk to strangers Thread safe calls / interfaces

30 The SOLID Principles Mnemonic SOLID S SRP Single Responsibility Principle O OCP Open Closed Principle L LSP Liskov Subsitutability Principle I ISP Interface Segregation Principle D DIP Dependency Inversion Principle

31 Design Modelling Using UML (Unified Modelling Language) Purpose there will be a design, make it explicit understanding and structuring documentation share the structure with future colleagues Process view what should be done activity diagram Logical view structure and interactions class diagram, object diagram, communication diagram, state machine diagram, sequence diagram

32 Class Diagram (Active Object) Client Proxy method1() methodn() dispatch() insert() Scheduler ResultHolder setresult() getresult() MethodRequest can_run() run() Servant method1() methodn() ConcreteRequest1 ConcreteRequestN

33 Sequence Diagram (Active Object) : Client : Proxy : Scheduler : Servant method1() : ResultHolder ResultHolder MethodRequest1 : MethodRequest1 ResultHolder run() setresult() method1() getresult()

34 Implementation Important principles Document first or it wont be done Document what, why, example usage, preconditions, etc Localize error-prone code (e g input/output) KISS keep it simple stupid Write for clarity, simplicity and readability, not for speed Top-down readability, simple flow: decision action Longer, more descriptive identifiers the larger the scope Check preconditions for robustness

35 Testing Purpose not about testing if a program functions as expected (see Works on My Machine Certification Programme ) search for faults successful when a fault is found Fault identification identify and analyse the fault do not immediately fix the fault, find the cause Fault removal/correction only after further analysis we know the cause remove the entire fault, not just the final cause of the failure

36 Types of Faults Consistent Faults Algorithmic faults Computation/precision faults Documentation faults Transient Faults resource limitations timing and coordination Environment Faults hardware or external software malfunction standards or procedure faults

37 Types of Tests Unit test test a unit (class or function) Integration test test a unit against dependences Agile uses continuous integration instead System test function, performance, security, etc. Acceptance test test the full system using customer's requirements

38 Unit Test Examining / code review manual reading with fresh eyes Approaches pair programming partner review walk-through code inspection Execution testing can be automated for regression testing (Formal proofs)

39 Execution Testing Manual or automated test execution Test client executes suites that execute tests Send example input, check for correct output CppUnit, JUnit, etc Client Test Test Suite Suite run() run() Testee method1() methodn() Unit Test Unit Unit Test Test Unit setup() Test execute() setup() cleanup() execute() cleanup()

40 Example Processes Partner code review and system testing Developer Implement function System testing Check in code Developer Review and comment Developer Review and comment (RUP work-flow diagram)

41 Example Processes Test-driven development (TDD) for each Story or Task Implement test Execute test [incorrect test] [working as expected] [good structure] Implementation Refactor (UML2 activity diagram)

42 Example Processes Design and implementation review Implement test [incorrect test] Execute test [working as expected] Re-design Implementation [substandard design] [good design] Design review Code review [substandard code] [good code] (UML2 activity diagram)

43 Example Processes Design and implementation review Implement test [incorrect test] Execute test [working as expected] Re-design Implementation [substandard design] [good design] Design review Code review [substandard code] [good code] (UML2 activity diagram)

44 System Testing Can be extremely elaborate Less elaborate in Agile projects Includes tests specified by Product Owner Thread testing follow protocols to test functionality Test system behaviour under stress (if wanted)

45 Acceptance Testing Benchmark testing test cases prepared by the customer typical conditions for the system Pilot testing install and use the system Alpha testing in house pilot Beta testing customer's pilot Parallel testing install and use in parallel with another or previous system