02291: System Integration Hubert Baumeister hub@imm.dtu.dk Spring - - PDF document

02291: System Integration

Hubert Baumeister

hub@imm.dtu.dk

Spring 2011

Contents

1 Explorative Modelling 1 1.1 Example: MUD Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Example: EaseWaste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Software Development Process 6 2.1 Software Development Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Extreme Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3 Lean Software Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4 Cycle time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5 Create flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.6 Agile Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3 Project Introduction 22 3.1 Description of the toll system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2 Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3 Project Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.4 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1 Explorative Modelling

Explorative Modelling: The purpose of models

• Models provide an overview over the system for a certain purpose that is easier to obtain than actually

building the system – Purpose of models: e.g. plan the project, understand the problem, understand the design, guide the implementation – Make the problem easier by abstracting away from details

• Problem: How can one make models executable so that one, e.g., test them?
• Observation: Object-orientation provides: Abstraction and Encapsulation

→ Expressiveness of OO languages comes close to expressiveness of UML → Why not use OO languages as modelling languages?

• Advantage over UML

– OO programs can be executed which gives immediate feedback

• Difference from a prototype

– Only focus on the aspects one wants to model; disregarding, e.g. GUI, database, distribution, . . . 1

1.1 Example: MUD Game

Example: MUD Game

• Acceptance Tests

– http://localhost:9999/MudOneA.SuiteSwepTests – Here we use the acceptance tests to drive our executable model instead of using a GUI

• The Code

– Eclipse project http://www2.imm.dtu.dk/courses/02291/files/MUD.zip (Includes the Fitnesse Wiki with tests) Example: MUD Game Class Diagram

lastOffer

• bject

Player Offer currentRoom inventory

• bjects

connectedTo Room Level nextLevel SpecialRoom PersonalObject StartRoom

Example: MUD Game Sequence Diagram 2

getObject getObject getPlayer getPlayer _closeTrade

• 2:Offer

closeTrade()

• ffer(p1,obj2)

user 2

• 1:Offer

_receiveOffer(obj2,p2)

• ffer(obj1,p2)

user 1 _receiveOffer(obj1,p1) p2:Player p1:Player addToInventory(obj2) removeFromInventory(obj2) removeFromInventory(obj1) addToInventory(obj1)

1.2 Example: EaseWaste

Example: Modelling of Waste Processes

• Example of a Waste Process

– Waste is transformed from the production in households to the final deposition on a landfill – The whole process produces emissions (or saves them) and uses resources (or saves them) 3

Goal

• Create a model for waste processes

– How waste is transformed – What emissions are produced and what resources are used

• A first model of the waste

Missing feedback in modelling as a problem

• Model was done in cooperation with a PhD student from DTU Environment
• I didn’t have the confidence that the model was good

– The model didn’t help me understanding the details of their waste process modelling better → Missing feedback: Can the model model all type of waste processes? → Is the model appropriate to do all necessary computations?

• Creating Feedback with Models
• a. Define a set of scenarios that the model should be able to model with inputs and expected outcomes

(Use case scenarios) → Fit tests

• b. Show that the model is capable of modelling these scenarios (Use case realizations)

→ Execute the model wrt. the tests → Model is written in Ruby

• All scenarios: http://pchub.imm.dtu.dk:8008/EaseWaste.TestSuites
• Example scenario http://pchub.imm.dtu.dk:8008/EaseWaste.TestSuites.Us01SimpleIncinerationSimpleLci

Only the domain is modelled 4

• The model focuses on the domain layer

→ no GUI → no database

• Focus on clearly expressing the intention of the model

– Focus only on big O performance and only if the clarity of the model was not compromised The model as a UML diagram 5

ElementaryFlow LCI Waste name WasteFraction name WasteProcess AbstractWasteProcess add_property lci waste_outputs Scenario WasteGeneration LCIComputation aspect lci * * ext.proc. Exchange amount lci lci_for_inputs lci_for_outputs ExchangeInput ExchangeOutput 1 1 * TCTable WasteLCILinkTable 1 1 TypedLCI type SumLCI BasicLCI * 1 1 waste input * proc.spec Flow name ExternalProcess lci_for_inputs lci_for_outputs *

• The real model: http://pchub.imm.dtu.dk:8008/files/html/doc/index.html

Summary

• Use a real (high level) progamming language to create the model

– e.g. Java, Ruby, Scala, . . . – Model become executable – Models can be automatically tested – But, as with class diagrams, focus on the aspects you want to investigate and leave out aspects one is not interested in

• In this course:

– create class diagram, sequence diagrams, and state machines by reverse engineering from the model

• In real life:

– Tests can be reused. – Reverse engineering can be too expensive (e.g. keeping the class diagram up-to-date when the model changes) → Use tools, like eUML, to generate class diagrams (and other type of diagrams) from the model

2 Software Development Process

2.1 Software Development Processes

Software Development Challenges 6

• Challenges of Software Development

– On time – In budget – No defects – Customer satisfaction Software Development Process

• Activities in Software Development

– Understand and document what kind of the software the customer wants → Requirements Analysis – Determine how the software is to be built → Design – Build the software → Implementation – Validate that the software solves the customers problem → Testing → Verification → Evaluation: e.g. User friendliness

• Each of the steps has its associated set of techniques
• However, the techniques can be applied in different orders

→ Different software development processes – e.g. Waterfall and Iterative processes (e.g. Rational Unified Process (RUP), agile processes: Extreme Programming (XP), SCRUM, Feature Driven Development, Lean . . . ) Waterfall process 7

• Strict waterfall: An activity has to terminate (e.g. formally approved) before the next activity begins

→ No feedback possible from the later activities → Takes too long time for the system to be build, which does not allow the customer to give feedback Waterfall → No feedback from the next activity possible until the next activity is approved – But: during the design of the system new questions come up on how to interpret the requirements; or during the implementation questions come up on how to interpret the design → formal (costly) change process with approval → waste (c.f. Lean software development) → Iterative development improves on that (depends on the number of iterations)

• Delay in one phase of the project delays the whole project

D I T A

Time Features Release date

D A I T

Time Release date Features delay delay

8

Iterative Processes: E.g. Rational Unified Process

• Inception, Elaboration, Construction, Transition corresponds to Plan the project, understand the problem,

build the solution, test the solution, maintain the solution – All activities occur throughout the project – After each iteration, the customer sees the product and gives feedback Agile Processes and Lean Software Development

• eXtreme Programming (XP), Scrum, Feature Driven Development (FDD), Lean Software Development
• Iterations getting shorter than with, e.g., RUP
• New set of techniques: Pair programming, customer on site, user stories, test-first and test-driven develop-

ment, . . .

• Focus on marketable features

– A feature of the software that is relevant for the customer – User stories (XP), Backlog (Scrum), Features (FDD), ... – Corresponds roughly to use case scenarios

• Lean Software Development

– Apply values and principles from Lean Production to Software Development

2.2 Extreme Programming

eXtreme Programming (XP)

• Defined by Kent Beck, Ward Cunningham, and others while working at Chrysler on the C3 project (a payroll

system) end of the 90’s

• Name: take classical software engineering techniques and put them to the extreme

e.g. Tests are good: test always and make tests before writing the code → automatic tests and test-driven development 9

Kent Beck, eXtreme Programming, 1st edition

eXtreme Programming

Functionality Time

AD I T AD I T R AD I T R

F 1 F 2 F 3 F 4 F 5 F 6 F 7

• 1. Iteration
• 1. Iteration

Functionality Time

AD I T AD I T R AD I T R AD I T R

F 1 F 2 F 3 F 8 F 4 F 5 F 6

10

Functionality Time

AD I T AD I T R AD I T R AD I T R AD I T R AD I T R

F 1 F 2 F 3a F 8 F 4 F 5 F 6

R AD I T

• 1. Iteration

eXtreme Programming

Functionality Time

AD I T AD I T R AD I T R AD I T R AD I T R AD I T R

F 1 F 2 F 3a F 8 F 4 F 5 F 6

R AD I T

• 1. Iteration
• Iterations are planned by the customer and the developer based on user stories (stories about how the system

is to be used) – Customer decides on priority; Developer decides on effort: planning game → If the project is delayed, low priority features get not implemented

• Important step: refactoring: Improve the design of the system without changing its functionality
• Automated tests work as regression tests and ensure that existing functionality is not lost

2.3 Lean Software Development

Lean Software Development

• Apply ideas from Lean production to software development

– Main principle: Reduce the amount of waste (e.g. time spent that does not produce value for the customer) – E.g. for waste: ∗ time needed to fix bugs; ∗ time needed to change the system because it does not satisfies the customers requirements; ∗ waiting time for someone to approve, e.g. the design e.t.c. ∗ half finished functionality; unclean code (technical dept) Lean principles 1) Identify customer value 2) Analyse activities how much customer value they produce: value stream maps 11

3) Creation of flow through pull systems by moving to single piece flow 4) Perfection – Instead of finding and fixing defects, prevent defects – When a defect is detected, stop the process and search for reasons instead of continuing and fixing defects later – Construct a system to automatically detect defects → automatic tests and continuous integration in agile processes 5) Continuous process improvements → Kaizen – Based on the knowledge of the production team – Who produces more ideas: 2500 workers or 10 managers? – At Porsche the number of proposals for improvements raised from 0.06 a year to 12 (in Japan 29!) Value Stream Map for a Software Developoment Process Value Stream Map A value stream describes a set of activities to produce a product and how much each step contributes to customer value or is just waste.

• 17.5 week which creates value and 37 weeks waste.
• Production time can be reduced from 54.5 days to 17.5, if it is possible to reduce all waste

2.4 Cycle time

Cycle time and production of bikes Mass production Make Tube 10h = 10 * 1h 990h waiting Make Frame 2h Welding tubes 198h waiting Make Wheel 4h = 2 * 2h 396h waiting Assemble Bike 1h 99h waiting

• For 100 bikes one needs 1700 hours
• Value stream map: 17h value creation; 1683h waste

12

• Cycle time =

Number of units (100) P roduction rate (100/1700) = 1700h

→ Goals is to reduce the cycle time Lean production Make Tube 10h for 10 tubes Make Frame 2h Welding tubes Make Wheels 4h for 2 wheels Assemble Bike 1h

• Cycle time

1 1/17 = 17h

Difference mass production and lean production

• Mass production

– Focus on the effective use of machinery – Focus on the effectiveness of each phase (e.g. requirements, design, implementation, test)

• Lean production

– Focus on reducing the cycle time – Focus on the interaction of the phases to improve the product

• Advantages of a reduced cycle time:

– Faster feedback about the usability of a product – Faster feedback on the process → Changes in product and process can be done more easily How to reduce the cycle time? Cycle time Cycle time = number of units production rate a) Reducing number of units b) Increasing the production rate

• Reducing number of units is easier (means limit of work-in-progress (WIP))

→ Leads to more repetitions of the process → Leads to process improvements → Leads to increase of production rate due to reduction of waste → Agile processes use User Stories (XP), Features (FDD), Minimal Marketable Features (Lean SD) → Kanban-cards to reduce / control the work-in-progress limits 13

Example: Software Development Waterfall (flight control software; about 1000 requirements)

Design 1000h 1h per req. Implementation 1900h 1.9h per req. Release 100h 0.1h per req. Analysis 500h 0.5h per req. Testing 0.5h 499h

• Cycle time: 25 months
• Feedback after: 25 months

Single piece flow (one requirement at a time)

Analysis 0.5h Design 1h Implementation 1.9h Testing 0.5h Release 0.1h

• Cycle time: 4h
• Feedback: 4h

Note that the time for implementing all 1000 requirements is the same (i.e. 25 months)

• However, process improvements through feedback based on reduced cycle time allows to increase the pro-

duction rate

Adapted from Lean Software Strategies by Middelton and Sutton

2.5 Create flow

Kanban cards to achieve pull Pull or Just-in-time Only produce something when it is needed → Avoids over production and stores Kanban cards control buffers and stores Make Tube 10h for 10 tubes Make Frame 2h Welding tubes Make Wheels 4h for 2 wheels

• Assumption: Each activity is done by one person
• Underproduction (waiting) or overproduction (store)

→ Pull system or just in time

• Method for implementation of just in time: kanban cards

– There is only a buffer of exactly the amount of parts, so that the worker does not have to wait – Kanban cards indicate up stream when new parts are needed 14

Example for the use of kanban cards in software development Days used: 0; Features ready: 0 Days used: 0; Features ready: 0 Days used: 0; Features ready: 0 Days used: 1; Features ready: 0 Days used: 1; Features ready: 0 Days used: 2; Features ready: 0 Days used: 2; Features ready: 0 Days used: 3; Features ready: 0 Days used: 3; Features ready: 0 Days used: 4; Features ready: 1 Days used: 4; Features ready: 1 Days used: 5; Features ready: 2 Days used: 5; Features ready: 2 Days used: 6; Features ready: 3

A I T

Work Item Done

D

Queue WIP Queue Queue Queue WIP WIP WIP

Blah

1

Blah

2

Blah

3

Blah

4

Blah

5 A I T

Work Item Done

D

Queue WIP Queue Queue Queue WIP WIP WIP

1 2 3 4 5

15

A I T

Work Item Done

D

Queue WIP Queue Queue Queue WIP WIP WIP

2 3 4 1 5

A I T

Work Item Done

D

Queue WIP Queue Queue Queue WIP WIP WIP

2 4

A

1

Blah

1

3 5

16

A I T

Work Item Done

D

Queue WIP Queue Queue Queue WIP WIP WIP

4

1

1 2 3 5

A I T

Work Item Done

D

Queue WIP Queue Queue Queue WIP WIP WIP

1

1

Blah

3

2 4 3 5

A D

17

A I T

Work Item Done

D

Queue WIP Queue Queue Queue WIP WIP WIP

1

1

1

3

4 3 2 5

A I T

Work Item Done

D

Queue WIP Queue Queue Queue WIP WIP WIP

1

1

1

3

4 2 3

Blah

2

5

A D I

18

A I T

Work Item Done

D

Queue WIP Queue Queue Queue WIP WIP WIP

1

1

1

1

3

3

2

4 2 3 5

A I T

Work Item Done

D

Queue WIP Queue Queue Queue WIP WIP WIP

1

1 1

1

3

3

2

4 2 3

Blah

4

5

A D I T

19

A I T

Work Item Done

D

Queue WIP Queue Queue Queue WIP WIP WIP

1 1

1

1

1

3

3 3

2

2

4

4 2 3 5

A I T

Work Item Done

D

Queue WIP Queue Queue Queue WIP WIP WIP

1

1 1

3

3

2

Blah

5

1 3 2 4 5

A D I

4

2 3 T 1

20

A I T

Work Item Done

D

Queue WIP Queue Queue Queue WIP WIP WIP

1

1 1

3

3

2

1

4

2 3

3

1 3 2

4

5 4 2

A I T

Work Item Done

D

Queue WIP Queue Queue Queue WIP WIP WIP

1

1 1

3

3

2

1

4

2 3

3 2 4 5

I T 1 3 2

4 D

Flow through pull with kanban 21

• Process controlling through local rules
• Contains limits for Work-in-progress (ideal 1, but could also be higher)

→ Leads to short cycle times and improved feedback (product and process)

• Problems in the process (like blockages or empty activities) can be easily seen on the kanban board and

fixed (by process adaptation or help from others)

• Works for all process types (not only the prototypical process mentioned above): e.g. Usability tests, formal

methods . . . → Kanban is a tool for process improvements

2.6 Agile Planning

3 Project Introduction

3.1 Description of the toll system

Exam Project: Model of a Toll System

• Note: A detailed problem description has been uploaded to Campus Net

Toll Lane 22

Toll Lane Cash Register Credit Card Reader Printer Single Ticket Reader Toll Lane Computer Touchscreen Bank

)))

(((

Antenna 1) 1) 1) 1) 3) 2)

1) Only normal check-in lane 2) Only normal check-out lane 3) Only express lane (check-in and check-out)

Barrier 1,2,3) 1)

Toll Station

Toll Lane Toll Station Toll Lane Toll Lane Toll Lane : : Station Server Station Client

Toll Enterprise 23

Toll Station Enterprise Toll Station Toll Station Toll Station : : Enterprise Server Enterprise Client Webserver Functionality

• Check-in

– Via Express Lane using a toll tag – Via Normal Lanes paying cash or with credit card by buying a single ticket

• Check-out

– Via Express Lane using th toll tag – Via Normal Lanes by supplying the ticket

• Buy Toll Tag
• Show Reports
• Change Rate
• Notify Customers
• Adminstration

3.2 Task

Task

• Analyse the requirements

– Base workflows as activity diagrams – From that and problem description: set of use cases presented in a use case diagram – Select 6 use cases for detailed description, i.e. detailed use case descriptions with main and alternative scenarios 24

∗ Selection should be based on the customers priorities

• Design the system

– Component, detailed class diagram design, and behaviour design so that the functional requirements

• f the 4—6 use cases (4 for a 4 man group, 6 for a 6 man group) from the requirements analysis are

modeled

• Validate the model

– By showing the use case realization for the 6 choosen use cases – By providing acceptance tests for the 6 choosen use cases General Remarks

• Abstract here from any physical implementation, e.g. cash register, printer, etc. as, e.g., embedded system

– Assume that each software component can talk to another component via a standard component pro- tocol – I.e. the programmer himself chooses ∗ Implementation language for each device ∗ Communication technology between devices

• Abstract away from any concrete user interface representation

– Focus on application layer functionality ∗ The representation of any user interaction as messages to objects ∗ However, it may be helpful to draw sketches of the user interface The Report Document Structure

• Introduction

– Methodology used

• Requirements

– Domain Analysis – Functional Requirements – Non-Functional Requirements

• Acceptance Tests
• Design

– Component Design – Class Design – Behaviour Design

• Validation

– Use Case Realisation 25

Evaluation Criteria Basic Evaluation Criteria How well the teaching goals in the course description are accomplished by each participant. → For each section, digram etc. name who did it (at most two names)

• Make sure that everybody did something of everything
• In the project presentation:

– Everybody should have ∗ read the project report ∗ be able to explain each part of the model Evaluation Criteria (cont.)

• Correct use of UML diagrams and OCL constraints
• Understandability of the design

– e.g. decribe all non-obvious behaviour of components / classes / operations – Are all design decisions documented?

• Correctness of the use case realizations
• Correct connection between detailed class diagram, behaviour diagrams, and component design (including

ports, required/provided interfaces, and protocol state machines)

• Appropriate abstraction level of the design.
• Completeness w.r.t. the choosen use cases

3.3 Project Planning

Project Planning in the Examination Project

• You don’t have much time to use several iterations and releases
• Simplified version:

– Define a set of user stories, estimate them, and order them according to priority

• You can use the week boundaries to help you with tracking (i.e. each week you look at how many user

stories have been done and what still needs to be done and replan accordingly) User Stories I User Story User stories describe the requirements based on short stories how the user want to use the system. While use cases focus on one functionality, a user story focuses on a more complete usage scenario that could involve several use cases.

• Rule of thumb: User stories are close to use case scenarios
• A possible sentence structure for writing down user stories

– ”As a <role>, I want <goal/desire> so that <benefit>” or – ”As a <role>, I want <goal/desire>”

• Examples are:

26

– As a customer representative, I want to search for my customers by their first and last names. – As a mobile application tester, I want to test my test cases and report results to my management.

• User stories can not only represent functionality, but also other requirements, e.g.

– As the teacher of the course, I want to see a description of the design in a report and a class diagram depicting the design. – As the teacher of the course, I want to see the tables for the systematic tests in the report for an appropriate number of use cases (4 for a 2 man group, 6 for a 3 man group, 8 for a 4 man group and 10 for a 5 man group) (Note that these are the requirements for a different course) User Stories II While it helps to express user stories as ”As a <role>, I want <goal/desire> so that <benefit>” it is also possible to describe stories in a different way. For example:

• Starting Application

The application begins by bringing up the last document the user was working with.

• The consultant will enter expenses on an expense form.

The consultant will enter items on the form like expense type, description, amount, and any comments regarding the expense. At any time the consultant can do any of the below options. 1) Once this is completed the consultant will ”Submit”. If the expense is under fifty (< 50), the expense will go directly to the system for processes. 2) In the event the consultant has not finished entering the expense, the consultant may want to ”Save for later”. This instance should then be displayed on a list (queue) for consultant with the status of ”Incomplete”. 3) In the event the consultant decides to clear the data and close the form the consultant will ”Cancel and exit”. This instance will not be saved anywhere. Project estimation and monitoring

• Two possibilities

1) Estimate the ideal time (e.g. person days/weeks) needed to implement the feature. To get the real time multiply this with a load factor (e.g. 2) 2) Estimate the relative difficulty among user stories: e.g. user story 1 is more difficutl than user story 2 and assign (arbitrary) points to the

• Progress is monitored by how many user stories are completed

1) Defines the load factor (lf) (e.g. lf = total iteration time/user story time finished) 2) Defines velocity: Number of points per iteration – If in trouble: Focus on few stories that can be finished instead of having many unfinished stories → Don’t let deadlines slip (time boxing)

• Yesterdays weather: For the planning of the iteration use the load factor / velocity of the only the previous

iteration 27

Example Plan

• Remark

– There is no requirement that you have to do the project in the order the report is written – It is actually a good idea to proceed through all the all the tasks by use case scenario and later write up the text for the sections Plan execution

• 1. Create the business processes
• 2. Define the use cases
• 3. Select the most important use cases and define user stories for them
• 4. Determine a basic architecture (top components and their interactions, but no detailed interfaces yet)
• 5. Repeat:

– 2 people take a user story and flesh out details a) use case scenarios b) acceptance tests c) define the necessary component interfaces d) implement the component interfaces by classes e) define the behavior of the classes e) define the PSM’s f) create the sequence diagram for validation – Meet often to coordinate your designs

• 6. Check that the model is consistent: Use case scenarios are correct and Use case scenario validation is correct

3.4 Organization

Organization

• Start: Today (30.3.)
• End: Wednesday 4.5. (submissions arriving before 8:00 on Thursday 5.5. will be considered)

28

– Upload the report as PDF on Campus Net (there will be subgroups for each project group)

• Oral presentation

– Dates are not yet defined – 45 min: around 10 min slides presentation; rest is Q&A

• Ulyana and I are available for questions / clarifications

– Updates to the specification will be posted on the CampusNet – No specific exercises, but exercise session 10:15-12:00 will be kept for questions Project: Rules on Cheating Rules for Quoting (from Study Handbook Sect. 3.9) ”. . . The rules regarding citations and references to sources in written assignments are that citations must be indi- cated by quotation marks at the start and end of the citation and the source of the citation must be referred to either in parentheses or in a note to the text. When not citing directly but basing the discussion on a specific source, the source must be referred to either in parenthesis or a note to the text. . . . ” → Usual rules for referencing sources: sources must be named Course

• 3 more lectures

– Model-driven architecture (MDA) and Agile modelling – Verification of models: Model checking – Guest lecture by Netcompany on the use of models in industry 29