02291: System Integration

Hubert Baumeisterhub@imm.dtu.dk

Spring 2013

Contents1 More UML Diagrams 1

1.1 Object Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Package Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Software Development Process 8

3 Exam Project Planning 16

4 Project Introduction 194.1 Description of the toll system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2 Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.3 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1 More UML Diagrams

1.1 Object DiagramsObject Diagram Example

Class Diagram

1

Object Diagram

Update operation of Account

2

State before executing update(n)

{n + b >= 0}

h: Historybal=m

a: Accountbal=b

prev

3

State after executing update(n)

a: Accountbal=b+n

h: Historybal=m

h1: Historybal=b

prev

prev

Object Diagram Purpose

• Describes

– Instances of classes: objects

– And associations: links

• Describes a snapshot of a running system

– e.g. visualizing the pre- and post state of an operation

• Used as the bases for communication diagrams

4

Notation

• Variant 1: an object with name and class

• Variant 2: an anonymous object of a class

• Variant 3: a named object of unknown class

Notation

• Value Specifications

• Slots

• Links to other objects

5

1.2 Package DiagramsPackage Diagram

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

• Structures the model, not the system

– c.f. component diagram

• Define a name space

– P::C means class C in package P

→ Java packages

Package Diagrams

• Purpose

– Structure the model∗ Structure should reflect the structure of the model and not model the structure of the underlying

system

• Package Diagrams group UML model elements

– mostly classes– but can contain any model element (use cases, activity diagrams, state machines ...)

• Packages can be included in other packages

• Packages define a namespace

– The same name for a model element can be used in different packages– Qualification with the name of the originating package may be necessary∗ E.g. class C in package P has to be used as P::C in package Q.

Package notation

• Notations for packages

6

Examples

• Dependencies between packages

Import vs access

«access»«access»BA

PQR

1.3 Deployment Diagram

7

Deployment Diagram

• Nodes represent

– �devices�

– �execution environments�

– can be nested

• Artifacts being deployed on nodes

– Correspond to, e.g. jar files, html files, exe files etc.

– They can manifest UML Elements like components

2 Software Development ProcessSoftware Development Challenges

8

• Challenges of Software Development

– On time

– In budget

– No defects

– Customer satisfaction

Software Development Process

• Activities in Software Development

– Understand and document what the customer wants: Requirements Engineering

– How to build the software: Design

– Build the software: Implementation

– Validate: Testing, Verification, Evaluation

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

• How to apply the techniques:

→ Different software development processes: Waterfall, Iterative processes, agile, . . .

Waterfall process

Delays in waterfall processes

9

D I TA

Time

Features

Release date

Iterative Processes: E.g. Rational Unified Process

Agile processes and Lean Software Development

10

Functionality

TimeAD IT

AD ITR

AD ITR

F 1

F 2

F 3

F 4

F 5

F 6

F 7

1. Iteration

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

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

Agile Processes and Lean Software Development

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

• Common characteristics

– Short iterations

– Focus on marketable features

– New, extreme practices

11

– Applying values and principles from Lean Production

Resource Triangle

Resource Triangle: Waterfall

Resource Triangle: Agile

12

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

eXtreme Programming (XP)

Sit-together

13

Lean Software Development

• Lean Production:

– Reduce the amount of waste

– Generate flow

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

– time needed to fix bugs

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

– time waiting for approval

– . . .

Cycle time

Cycle timeTime it takes to go throuh the process one time

cycle time =number of features

feature implemantion rate

• Batch size = number of features in an iteration

• Example: Waterfall

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

– cycle time = 250 / 5 = 50 weeks

– Overall time: 50 weeks

→ 1 cycle

14

Reducing the cycle time

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

cycle time =number of features

feature implemantion rate

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

→ 250 cycles

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

Software Engineering: Flow through Pull with Kanban

• Process controlling: local rules

• Load balancing: Kanban cards and Work in Progress (WIP) limits

• Process improvements

15

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

Figure from David Anderson www.agilemanagement.net

3 Exam Project PlanningPlanning Agile Projects

• 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

• Releases (quarterly cycle)

– make (business) sense

– user stories / themes / epics

• Iterations within releases (weekly cycle)

– user stories

• time boxing

– fixed: release dates and iterations

– adjustable: scope

Planning game

• Customer defines:

– user stories

– priorities

• Developer define:

– costs, risks

– suggest user stories

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

→ split a user story

→ change a user story

16

Planning game

• Release planning:

1) Define user stories that make up an iteration

2) Assign user stories to iterations

– Two clear distinguished roles

a) Customer defines which user story goes into which iteration based on business value, risk, and costs(i.e. development effort)

b) Developer owns the estimates for a user story (the user cannot tell the developer when the story shouldbe done)

∗ Ignore dependencies between user stories→ estimates in ideal man days/weeks or story points (gut feeling based on experience)

– After each iteration, the plan and progress are evaluated and possibly adjusted

• Iteration planning (at the start of each iteration):

– Define tasks for user stories of the iteration

– Programmers commit to tasks

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 timemultiply 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 2and 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 previousiteration

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

17

5.e. Create a use case realization

5.f. Update the report

• Meet often to coordinate the design

• Update your plan

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

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 userstories have been done and what still needs to be done and replan accordingly)

Example Plan

• Remark: report structure 6= project structure

– Report structure: waterfall (by technique)

– 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

• 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 thetext for the sections

Techniques for planning your project 1

• Step 1 Determine a set of scenarios (e.g. based on Use Case scenarios) that your system should be able todo

– Do a brain storming on the requirements (use cases)

∗ What are the scenarios? (success, failure, . . . )

18

∗ Is the set of use cases complete?

– Include user stories for writing the report

∗ E.g. Drawing class diagram∗ Documenting use cases∗ Sequence diagrams∗ Writing introduction∗ ...

• Step 2 Do a brain storming on the intended architecture of the system (usually, the customer has somerequirements here: e.g. implemented as a Web application . . .

– Only a rough idea is needed

Techniques for planning your project 2

• Step 3 Estimate the Use Case Scenarios

– How long, in ideal man hours, do you think you need for implementing the use case scenario?

– Multiply this with a load factor of 2 to get the real man hours

– This estimation includes

∗ Design∗ Define the detailed scenarios∗ Implementation∗ Testing∗ . . .

4 Project Introduction

4.1 Description of the toll systemExam Project: Model of a Toll System

Toll Lane

19

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)

Toll Station

Toll Lane

Toll Station

Toll Lane

Toll Lane

Toll Lane

::

Station Server Station Client

Enterprise

20

Toll Station

Enterprise

Toll Station

Toll Station

Toll Station

::

Enterprise ServerEnterprise Client

Webserver

Functionality

• Check-in

– Express Lane with toll tag

– Normal Lane using a single ticket with cash / credit card

• Check-out

– Express Lane with toll tag

– Normal Lane using a ticket

• Buy Toll Tag

• Show Reports

• Change Rate

• Notify Customers

• Adminstration

4.2 TaskTask

• Analyse the requirements

– Base workflows as activity diagrams

– Use case diagram

– Select 4—6 use cases for detailed description

∗ Based on the customers priorities and creating the basic architecture

21

• Acceptance tests

• Design the system

– Component, detailed class diagram design, and behaviour design

• Validate the model

→ use case realization

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

• Abstract away from any concrete user interface representation

– Application layer functionality

The Report

Document Structure

• Introduction

– Methodology used

• Requirements

– Business Processes

– Domain Analysis

– Functional Requirements

– Non-Functional Requirements

• Acceptance Tests

• Design

– Component Design

– Class Design

– Behaviour Design

• Validation

– Use Case Realisation

Evaluation Criteria

Basic Evaluation CriteriaHow 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)

• 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

22

Evaluation Criteria (cont.)

• Correct use of UML diagrams and OCL constraints

• Understandability of the design

• Correctness of the use case realizations

• Correct implementation of components

• Correct object life cycle state machine

• Appropriate abstraction level of the design

4.3 OrganizationOrganization

• Start: Today (10.4.)

• End: Wednesday 15.5. (submissions arriving before 8:00 on Thursday 16.5. will be considered)

• Upload the report as PDF on Campus Net using the assignment module

• Project presentations

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

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

• Teaching assistant 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 eitherin parentheses or in a note to the text. When not citing directly but basing the discussion on a specific source, thesource 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

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

– Week 11: Verification of models: Model checking

– Week 12: Guest lecture by NetCompany

23