02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister [email protected] DTU...

50
02291: System Integration Week 9 Hubert Baumeister [email protected] DTU Compute Technical University of Denmark Spring 2013

Transcript of 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister [email protected] DTU...

Page 1: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

02291: System IntegrationWeek 9

Hubert [email protected]

DTU ComputeTechnical University of Denmark

Spring 2013

Page 2: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Contents

More UML DiagramsObject DiagramsPackage DiagramsDeployment Diagram

Software Development Process

Exam Project Planning

Project Introduction

Page 3: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Object Diagram Example

Class Diagram Object Diagram

Page 4: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Object Diagram Purpose

I Snapshot of a running systemI objects: Instance of a classI links: instance of an association

I Communication diagram

Page 5: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Update operation of Account

State before executingupdate(n)

{n + b >= 0}

h: Historybal=m

a: Accountbal=b

prev

State after executingupdate(n)

a: Accountbal=b+n

h: Historybal=m

h1: Historybal=b

prev

prev

Page 6: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

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

Page 7: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Notation

I Value Specifications

I Slots

I Links to other objects

Page 8: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Package Diagram

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

I Structures the model , not the systemI c.f. component diagram

I Define a name spaceI P::C means class C in package P

→ Java packages

Page 9: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Package notation

I Notations for packages

Page 10: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Examples

I Dependencies between packages

Page 11: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Import vs access

«access»«access»BA

PQR

Page 12: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Deployment Diagram

Martin Fowler, UML Distilled

Page 13: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Contents

More UML Diagrams

Software Development Process

Exam Project Planning

Project Introduction

Page 14: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Software Development Challenges

I Challenges of Software DevelopmentI On timeI In budgetI No defectsI Customer satisfaction

Page 15: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Software Development Process

I Activities in Software DevelopmentI Understand and document what the customer wants:

Requirements EngineeringI How to build the software: DesignI Build the software: ImplementationI Validate: Testing, Verification, Evaluation

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

I How to apply the techniques:→ Different software development processes: Waterfall,

Iterative processes, agile, . . .

Page 16: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Waterfall process

Page 17: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Delays in waterfall processes

D I TA

Time

Features

Release date

Page 18: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Iterative Processes: E.g. Rational Unified Process

Page 19: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Agile processes and Lean Software Development

Functionality

TimeAD IT

AD ITR

AD ITR

F 1

F 2

F 3

F 4

F 5

F 6

F 7

1. Iteration

Page 20: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Agile processes and Lean Software Development

1. Iteration

Functionality

TimeAD IT

AD ITR

AD ITR

AD IT

R

F 1

F 2

F 3

F 8

F 4

F 5

F 6

Page 21: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Agile processes and Lean Software Development

Functionality

TimeAD IT

AD ITR

AD ITR

AD IT

R

AD IT

R

AD IT

R

F 1

F 2

F 3a

F 8

F 4

F 5

F 6

RAD IT

1. Iteration

Page 22: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Agile Processes and Lean Software Development

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

I Common characteristicsI Short iterationsI Focus on marketable featuresI New, extreme practicesI Applying values and principles from Lean Production

Page 23: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Resource Triangle

Page 24: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Resource Triangle: Waterfall

Page 25: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Resource Triangle: Agile

Functionality

TimeAD IT

AD ITR

AD ITR

AD IT

R

AD IT

R

AD IT

R

F 1

F 2

F 3a

F 8

F 4

F 5

F 6

RAD IT

1. Iteration

Page 26: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

eXtreme Programming (XP)

Page 27: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Sit-together

Page 28: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Lean Software Development

I Lean Production:I Reduce the amount of wasteI Generate flow

I Waste: resources used with does not produce value for thecustomer

I time needed to fix bugsI time to change the system because it does not fit the

customers requirementsI time waiting for approvalI . . .

Page 29: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Cycle time

Cycle timeTime 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 iterationI Example: Waterfall

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

I cycle time = 250 / 5 = 50 weeksI Overall time: 50 weeks→ 1 cycle

Page 30: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Reducing the cycle time

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

cycle time =number of features

feature implemantion rate

I Agile: cycle time = 1 / 5 = 8 hours→ 250 cycles

Page 31: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Generating flow using Pull and Kanban

WIP = Work in Progress Limit

1324

A T IWork Item DoneDQueue WIP Queue QueueQueue WIP WIP WIP

8

7

9

10

5

6

BlahComposite

Leaf Assembly4 2 3

3 3 3 3

Page 32: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Software Engineering: Flow through Pull with Kanban

I Process controlling: local rulesI Load balancing: Kanban cards and Work in Progress

(WIP) limitsI Process improvementsI www.targetprocess.com: Electronic Kanban board

useful for your project

Figure from David Anderson www.agilemanagement.net

Page 33: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Contents

More UML Diagrams

Software Development Process

Exam Project Planning

Project Introduction

Page 34: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

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 1Pl. Pl. Iteration nPlanning

ReleasePl.

Release m

...Iteration 1 Pl. Iteration nPlanning

Release

I Releases (quarterly cycle)I make (business) senseI user stories / themes / epics

I Iterations within releases (weekly cycle)I user stories

I time boxingI fixed: release dates and iterationsI adjustable: scope

Page 35: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Planning game

I Customer defines:I user storiesI priorities

I Developer define:I costs, risksI suggest user stories

I Customer decides: is the user story worth its costs?→ split a user story→ change a user story

Page 36: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Process for the exam project1. Create workflows2. Create use case diagrams3. Select 4—6 use cases4. Determine basic (intended) architecture5. For each use case scenario / user story (2 people work

together)5.a. Detail use case scenario5.b. Acceptance tests5.c. Play the scenario: CRC cards or sequence diagram on

component/class level5.d. Extend components, ports, required/provided interfaces,

classes, object life cycle state machines5.e. Create a use case realization5.f. Update the report

I Meet often to coordinate the designI Update your plan6. Check the use case realization for all use case scenarios

Page 37: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Example Plan

I Remark: report structure 6= project structureI 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

Page 38: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Contents

More UML Diagrams

Software Development Process

Exam Project Planning

Project IntroductionDescription of the toll systemTaskOrganization

Page 39: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Exam Project: Model of a Toll System

Page 40: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Toll Lane

Toll Lane

Cash Register

Credit Card Reader

Printer

Single Ticket Reader

Toll Lane ComputerTouchscreen

Bank

))) (((

Antenna

1)

1)1)

1)

3) 2)

1) Only normal check-in lane2) Only normal check-out lane3) Only express lane (check-in and check-out)

Barrier

1,2,3)

1)

Page 41: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Toll Station

Toll Lane

Toll Station

Toll Lane

Toll Lane

Toll Lane

::

Station Server Station Client

Page 42: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Enterprise

Toll Station

Enterprise

Toll Station

Toll Station

Toll Station

::

Enterprise ServerEnterprise Client

Webserver

Page 43: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Functionality

I Check-inI Express Lane with toll tagI Normal Lane using a single ticket with cash / credit card

I Check-outI Express Lane with toll tagI Normal Lane using a ticket

I Buy Toll TagI Show ReportsI Change RateI Notify CustomersI Adminstration

Page 44: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

TaskI Analyse the requirements

I Base workflows as activity diagramsI Use case diagramI Select 4—6 use cases for detailed description

I Based on the customers priorities and creating the basicarchitecture

I Acceptance testsI Design the system

I Component, detailed class diagram design, and behaviourdesign

I Validate the model→ use case realization

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

I Abstract away from any concrete user interfacerepresentation

I Application layer functionality

Page 45: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

The Report

Document StructureI Introduction

I Methodology usedI Requirements

I Business ProcessesI Domain AnalysisI Functional RequirementsI Non-Functional Requirements

I Acceptance TestsI Design

I Component DesignI Class DesignI Behaviour Design

I ValidationI Use Case Realisation

Page 46: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Evaluation Criteria

Basic Evaluation CriteriaHow well the teaching goals in the course description areaccomplished by each participant.

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

I Make sure that everybody did something of everythingI In the project presentation: Everybody should have

I read the project reportI be able to explain each part of the model

Page 47: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Evaluation Criteria (cont.)

I Correct use of UML diagrams and OCL constraintsI Understandability of the designI Correctness of the use case realizationsI Correct implementation of componentsI Correct object life cycle state machineI Appropriate abstraction level of the design

Page 48: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Organization

I Start: Today (10.4.)I End: Wednesday 15.5. (submissions arriving before 8:00

on Thursday 16.5. will be considered)I Upload the report as PDF on Campus Net using the

assignment moduleI Project presentations

I Wed. 29.5, Thu. 30.5, Fr. 31.5I 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 theCampusNet

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

Page 49: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Project: Rules on Cheating

Rules for Quoting (from Study Handbook Sect. 3.9)”. . . The rules regarding citations and references to sources inwritten assignments are that citations must be indicated byquotation marks at the start and end of the citation and thesource of the citation must be referred to either in parenthesesor in a note to the text. When not citing directly but basing thediscussion on a specific source, the source must be referred toeither in parenthesis or a note to the text. . . . ”

→ Usual rules for referencing sources: sources must benamed

Page 50: 02291: System Integration · 02291: System Integration Week 9 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013

Course

I 3 more lecturesI Week 10: Model-driven architecture (MDA) and Agile

modellingI Week 11: Verification of models: Model checkingI Week 12: Guest lecture by NetCompany