02291: System Integration Week 9 Hubert Baumeister

(1)

02291: System Integration

Week 9

Hubert Baumeister hub@imm.dtu.dk

DTU Compute Technical University of Denmark

Spring 2013

(2)

Object Diagram Example

Class Diagram Object Diagram

(4)

Object Diagram Purpose

I Snapshot of a running system

I objects: Instance of a class

I links: instance of an association

I Communication diagram

(5)

Update operation of Account

Statebeforeexecuting update(n)

{n + b >= 0}

h: History bal=m

a: Account bal=b

a: Account bal=b+n

h: History bal=m

h1: History bal=b

Notation

I Variant 1: an object with name and class

I Variant 2: an anonymous object of a class

I Variant 3: a named object of unknown class

(7)

Notation

I Value Specifications

I Slots

I Links to other objects

(8)

Package Diagram

I Groups model elements: classes, objects, use cases, packages, . . .

I Structures themodel, not thesystem

I c.f. component diagram

I Define a name space

I P::C means class C in package P

→ Java packages

(9)

Package notation

I Notations for packages

(10)

Examples

I Dependencies between packages

(11)

Import vs access

«access»

B A

P Q

R

(12)

Deployment Diagram

Martin Fowler, UML Distilled

(13)

Software Development Challenges

I Challenges of Software Development

I Ontime

I Inbudget

I Nodefects

I Customersatisfaction

(15)

Software Development Process

I Activities in Software Development

I Understand anddocumentwhat thecustomer wants:

Requirements Engineering

I Howto build the software: Design

I Build the software:Implementation

I Validate: Testing,Verification,Evaluation

→ Set of techniques: Use cases, CRC cards, refactoring, test-driven development, . . .

I How to apply the techniques:

→ Differentsoftware development processes: Waterfall, Iterative processes, agile, . . .

(16)

Waterfall process

(17)

Delays in waterfall processes

D I T

A

Time Features

Release date

(18)

Iterative Processes: E.g. Rational Unified Process

(19)

Agile processes and Lean Software Development

Functionality

Time

A DTI A DTI

R A DTI

R

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

1. Iteration

(20)

Agile processes and Lean Software Development

1. Iteration Functionality

Time

A DTI A DTI

R A DTI

R

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

(21)

Agile processes and Lean Software Development

Functionality

Time

A DTI A DTI

R A DTI

R

A DTI R

A DTI

R

F 1 F 2 F 3a

F 8 F 4 F 5 F 6

A DTI R

1. Iteration

(22)

Agile Processes and Lean Software Development

I Agile processes: eXtreme Programming (XP), Scrum, Feature Driven Development (FDD),Lean Software Development

I Common characteristics

I Short iterations

I Focus onmarketable features

I New,extremepractices

I ApplyingvaluesandprinciplesfromLean Production

(23)

Resource Triangle

(24)

Resource Triangle: Waterfall

(25)

Resource Triangle: Agile

Functionality

Time

A DTI A DTI

R A DTI

R

A DTI R

A DTI

R

F 1 F 2 F 3a

F 8 F 4 F 5 F 6

A DTI R

1. Iteration

(26)

eXtreme Programming (XP)

(27)

Sit-together

(28)

Lean Software Development

I Lean Production:

I Reduce the amount ofwaste

I Generateflow

I Waste: resources used with does not produce value for the customer

I time needed to fix bugs

I time to change the system because it does not fit the customers requirements

I time waiting for approval

I . . .

(29)

Cycle time

Time it takes to go throuh the process one time

cycle time= number of features feature implemantion rate

I Batch size=number of features in an iteration

I Example: Waterfall

I Software: 250 features, feature implementation rate = 5 features/week

I cycle time = 250 / 5 = 50 weeks

I Overall time: 50 weeks

→ 1 cycle

(30)

Reducing the cycle time

I Software: 250 features, feature implementation rate = 5 features/week

cycle time= number of features feature implemantion rate

I Agile: cycle time = 1 / 5 = 8 hours

→ 250 cycles

(31)

Generating flow using Pull and Kanban

WIP = Work in Progress Limit

1 3 2

4

A T I

Work Item D Done

Queue WIP Queue WIP Queue WIP Queue WIP

8 7

9 10 5

6

Blah Composite

Leaf4Assembly 2 3

3 3 3 3

(32)

Software Engineering: Flow through Pull with Kanban

I Process controlling: local rules

I Load balancing: Kanban cards andWork in Progress (WIP) limits

I Process improvements

I www.targetprocess.com: Electronic Kanban board useful for your project

Figure from David Andersonwww.agilemanagement.net

(33)

Planning Agile Projects

I fixed general structure

→ quarterly cycle / weekly cycle practices in XP

...

1w−4w 1w−4w (but fixed) Release 1

3m−6m

...

Iteration 1

Pl. Pl. Iteration n

Planning Release

Pl.

Release m Iteration 1 ... Pl. Iteration n Planning

Release

I Releases (quarterly cycle)

I make (business) sense

I user stories/themes/epics

I Iterations within releases (weekly cycle)

I user stories

I time boxing

I fixed: release dates and iterations

I adjustable: scope

(35)

Planning game

I Customer defines:

I user stories

I priorities

I Developer define:

I costs, risks

I suggest user stories

I Customer decides: is the user story worth its costs?

→ split a user story

→ change a user story

(36)

Process for the exam project

1. Create workflows

2. Create use case diagrams 3. Select 4—6 use cases

4. Determine basic (intended) architecture

5. For each use case scenario / user story (2 people work together)

5.a. Detail use case scenario 5.b. Acceptance tests

5.c. Play the scenario: CRC cards or sequence diagram on component/class level

5.d. Extend components, ports, required/provided interfaces, classes, object life cycle state machines

5.e. Create a use case realization 5.f. Update the report

I Meet often to coordinate the design

I Update your plan

6. Check the use case realization for all use case scenarios

(37)

Example Plan

I Remark: report structure6=project structure

I Report structure: waterfall (by technique)

I Project structure: agile (by user story)

Project plan for a MUD game number of persons hours a week per person hours a week no. of weeks

4 8 32 5 160

User Story/Tasks Ideal man hour Total hours in week Total hours

Week 1 Creating the base structure of the report 1 2 2 2

Player starts game 2 4 6 6

Player looks into a room 2 4 10 10

Player moves to adjacent room 2 4 14 14

Writing about the use cases 2 4 18 18

Player advances to next level 2 4 22 22

Player finishes game 2 4 26 26

Player takes up object 2 4 30 30

Syst. tests for the use cases in this iteration 2 4 34 34

Week 2 Players lays down object 2 4 6 38

Player registers successful for the game 2 4 10 42

Player registers, but name is already used 2 4 14 46

Writing the introduction 2 4 18 50

Writing about the design 2 4 22 54

Syst. tests for the use cases in this iteration 2 4 26 58

… … … … …

hours for the whole project

man hour with load factor

(38)

Exam Project: Model of a Toll System

(40)

Toll Lane

Cash Register

Credit Card Reader Printer Single Ticket Reader

Toll Lane Computer Touchscreen

Bank

))) (((

Antenna

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)

(41)

Toll Station

Toll Lane Toll Station

Toll Lane

Toll Lane :

: Station Server Station Client

(42)

Enterprise

Toll Station Enterprise

Toll Station

Toll Station :

: Enterprise Server

Enterprise Client

Webserver

(43)

Functionality

I Check-in

I Express Lane withtoll tag

I Normal Lane using asingle ticket withcash / credit card

I Check-out

I Express Lane withtoll tag

I Normal Lane using aticket

I Buy Toll Tag

I Show Reports

I Change Rate

I Notify Customers

I Adminstration

(44)

Task

I Analyse the requirements

I Base workflows as activity diagrams

I Use case diagram

I Select4—6 use casesfor detailed description

I Based on the customers priorities and creating the basic architecture

I Acceptance tests

I Design the system

I Component, detailed class diagram design, and behaviour design

I Validate the model

→ use case realization

I Abstract from any physical implementation, e.g. embedded system, communication protocol, . . .

I Abstract away from any concreteuser interface representation

I Application layer functionality

(45)

The Report

Document Structure

I Introduction

I Methodology used

I Requirements

I Business Processes

I Domain Analysis

I Functional Requirements

I Non-Functional Requirements

I Acceptance Tests

I Design

I Component Design

I Class Design

I Behaviour Design

I Validation

I Use Case Realisation

(46)

Evaluation Criteria

Basic Evaluation Criteria

How well the teaching goals in the course description are accomplished by each participant.

→ For each section, diagram etc. name who did it (at most two names)

I Make sure that everybody did something of everything

I In the project presentation: Everybody should have

I read the project report

I be able to explain each part of the model

(47)

Evaluation Criteria (cont.)

I Correct use of UML diagrams and OCL constraints

I Understandability of the design

I Correctness of the use case realizations

I Correct implementation of components

I Correct object life cycle state machine

I Appropriate abstraction level of the design

(48)

Organization

I Start: Today (10.4.)

I End: Wednesday 15.5. (submissions arriving before8:00 on Thursday 16.5. will be considered)

I Upload the reportas PDF on Campus Net using the assignment module

I Project presentations

I Wed. 29.5, Thu. 30.5, Fr. 31.5

I 45 min: around 10 min slides presentation; rest is Q&A

I Teaching assistant and I are available for questions / clarifications

I Updates to the specification will be posted on the CampusNet

I No specific exercises, but exercise session 10:15-12:00 will be kept for questions

(49)

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 thatcitationsmust be indicated by quotation marksat the start and end of the citation and the source of the citationmust be referred to either in parentheses or in a note to the text. When not citing directly butbasing the discussionon a specific source, thesourcemust be referred to either in parenthesis or a note to the text. . . . ”

→ Usual rules for referencing sources:sources must be named

(50)

Course

I 3 more lectures

I Week 10: Model-driven architecture (MDA) and Agile modelling

I Week 11: Verification of models: Model checking

I Week 12: Guest lecture by NetCompany

02291: System Integration Week 9 Hubert Baumeister