02291: System Integration Week 9 Hubert Baumeister

02291: System Integration

Week 9

Hubert Baumeister huba@dtu.dk

DTU Compute Technical University of Denmark

Spring 2018

Contents

Principles of Good Design Software Development Process Project Introduction

DRY principle

DRY principle Don’t repeat yourself

”Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”

The Pragmatic Programmer, Andrew Hunt and David Thomas

I code

I documentation

I build stystem

Example: Code Duplication

Example: Code Duplication

Company n a m e c-address-street c-address-city printAddress

Address street c i t y printAddress

Company n a m e Person

n a m e cpr-number

works at

home address

address Person

n a m e cpr-number home-address-street home-address-city printAddress

works at

DRY principle

I Techniques to avoid duplication

I Use appropriate abstractions

I Delegation

I Inheritance

I Classes with instance variables

I Methods with parameters

I Refactor to remove duplication

I Generate artefacts from a common source. Eg. Javadoc

KISS principle

KISS principle

Keep it short and simple(sometimes also:Keep it simple, stupid)

I simplest solution first

I Striveforsimplicity

I Takes time!!

I refactor forsimplicity

Antoine de Saint Exup ´ery

”It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away”.

YAGNI principle

YAGNI principle

You ain’t gonna needed it

I Focus on the task at hand

I E.g. using the observer pattern because itmightbe needed

→ Twodifferent kinds of flexibility

I make your design changeable

I tests, easy to refactor

I design for change

I Use good OO principles

I High cohesion, low coupling

I Decentralized control

→ Both are needed, but focus on the first before introducing not needed constructs for the second

Low Coupling

High coupling

A B

D E

C

F

Low coupling

A

B

D

E

C

F

Low Coupling

High coupling

A B

D E

C

F

Low coupling

A

B

D

E

C

F

High Cohesion

Low Cohesion

Person name cpr-number companyName work-address-street work-address-city home-address-street home-address-city

High Cohesion

Address street

city

Company name

Person name

cpr-number

works at

home address

address

High Cohesion

Low Cohesion

Person name cpr-number companyName work-address-street work-address-city home-address-street home-address-city

High Cohesion

Address street

city

Company name

Person name

cpr-number

works at

home address

address

Law of Demeter

Law of Demeter

I ”Only talk to your immediate friends”

I Only method calls to the following objects are allowed

I the object itself

I its components

I objects created by that object

I parameters of methods

I Law of Demeter =low coupling

→ delegate functionality

→ decentralised control

Computing the price of an order

Order calculate price calculate base price calculate discounts

Product name price

Customer name discount info

OrderLine quantity

*

1 1

Computing the price of an order

Order calculate price calculate base price calculate discounts

Product name price get price for quantity

Customer name discount info calculate discount

OrderLine quantity calculate price

*

1 1

Layered Architecture

Eric Evans, Domain Driven Design, Addison-Wesley, 2004

Example Vending Machine

Two different presentation layers

I Swing GUI

I Command line interface Current Money: DKK 5

0) Exit

1) Input 1 DKK 2) Input 2 DKK 3) Input 5 DKK 4) Select banana 5) Select apple 6) Cancel

Select a number (0-6): 5 Rest: DKK 2

Current Money: DKK 0 Dispensing: Apple

Architecture

«abstract»

Observable VendingMachineUI VendingMachineTextUI

«enumeration»

Fruit APPLE BANANA VendingMachine

dispensedItem : Fruit currentMoney : int totalMoney : int restMoney : int input(money : int) select(f : fruit) cancel() ...

Observable

Presentation Layer Presentation Layer

Application Layer

«delegate»

Observer

«delegate»

«delegate»

Observer

Contents

Principles of Good Design Software Development Process Project Introduction

Success rate for software projects 2000—2008

Sheet1

Page 1

2000 2002 2004 2006 2008

succeeded 28% 34% 29% 35% 32%

failed 23% 15% 18% 19% 24%

challenged 49% 51% 53% 46% 44%

2000 2002 2004 2006 2008

0%

20%

40%

60%

80%

100%

120%

challenged failed succeeded

CHAOS Summary 2009 Report

I Succeeded: 32%

I Failed: 20%

I Challenged: 48% (over time, over budget, lots of defects, low customer satisfaction. . . )

Failed or challenged

I Amanda

I Rejsekortet

I Obamacare Website

I German road toll system

I Denver airport baggage system

I . . .

Scaling software development

Small hut

I one person

I no special knowledge

Skyscraper

I not possible with one person

I special knowledge: static, electricity, water, waste, elevator, . . .

Types of software (Lehmann)

I s-type: mathematical function, sorting: complete specfication

I p-type: real world problems, e.g., chess: modelling the real world

I e-type: embeded into socio-technical systems.

Requirements change as the environment changes.

System changes the environment: e.g., operating system

I Continuing Change

I Increasing Complexity

I Conservation of Organisational Stability (invariant work rate)

I Continuing Growth

I Declining Quality

Activities in Software Development

I Understand anddocument what thecustomerwants:

Requirements Engineering

I How to build the software: Design

I Build the software: Implementation

I Validate:Testing,Verification,Evaluation

→ Waterfall

Waterfall process

I 1970: Winston W. Royce hownot to develop software

I 1985: Waterfall was required by the United States Department of Defence

Example: Empire State Steel Construction

From The Empire State Building by John Tauranac

From Building the Empire State by Willis, 1998

I Kept the budget I Was finishedbefore

deadline

I Built in21 month(from conception to finished building) (1931)

→ Basic design in 4 weeks

I Fast-trackconstruction

→ Begin the construction before the design is complete

→ create a flow

Delays in waterfall processes

D I T

A

Time Features

Release date

Implementation by layers and not functionality

Costs of changing requirements: Waterfall

I Changed / new requirements change the design and implementation

I Cost of change not predictable

→ Avoid changing/new requirements if possible

→ Good for s-type projects, not applicable to p-type and e-type projects

Iterative Processes: E.g. Rational Unified Process

(1996)

Agile Software Development Methods (1999)

I Extreme Programming (XP) (1999), Scrum (1995–2001), Lean Software Development (2003), . . .

I Kanban (2010): not a method;tool to improve processes

Functionality

Time

A DTI A DTI

R 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 DTIR

1. Iteration

Database / Infrastructure Layer Presentation Layer

Application Layer

Domain Layer

User Story

User Story User Story

I Highest priority user story first

I If delayed: important features are implemented

Problem in Software Engineering (Recap)

I Liggesmeyer 1998

Changing Requirements: Agile Methods

Scott Ambler 2003–2014http://www.agilemodeling.com/artifacts/userStory.htm

I Cost of change

I New / changed requirements not done yet: zero costs

I Changed requirements already done: the cost of a requirement that can not be implemented

Resource Triangle

Plan Driven

D I T

A

Time Features

Release date

Agile

Database / Infrastructure Layer Presentation Layer

Application Layer

Domain Layer

User Story

User Story User Story

eXtreme Programming (XP)

I Kent Beck 1999

I 12 Practices

Kent Beck, Extreme Programming 1st ed.

Scrum

Working increment of the software

Sprint Backlog Sprint

Product Backlog

30 days 24 h

file:///Users/huba/Desktop/Scrum_process.svg

1 of 1 /18.3.13 24:16

Wikipedia

I Robert Martin (Uncle Bob) about ”The Land that Scrum Forgot”

http://www.youtube.com/watch?v=hG4LH6P8Syk

→ History about agile methods, the agile manifesto, and Scrum and its relationshop to XP

Lean Software Development

I Lean Production:

I Value for the customer

I Reduce the amount ofwastein the production process

I Generateflow

I Waste: resources used which do 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 . . .

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

Flow through Pull with Kanban

I Process controlling: local rules

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

I Integration in other processes

Figure from David Andersonwww.agilemanagement.net

Online Kanban Tool: Trello

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

I Kanban board the exam project examplehttps:

//trello.com/b/CqzwTiRT/02291-example-lean

I Anotherhttps:

//trello.com/b/4wddd1zf/kanban-workflow

Process for the exam project

1. Create workflows

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

4. Determine basic (intended) architecture 5. Pair modelling: 2 people work together

→ https:

//trello.com/b/CqzwTiRT/02291-example-lean

I Meet often to coordinate the design

I Update your plan, use cases, detailed use cases, acceptance tests, etc. as needed

→ Important for grading: models have to be consistent with each other

6. Check the acceptance tests and use case realization for all use case scenarios

Important!

Report structure6=project structure

I Report structure: waterfall (by technique)

I Project structure: agile (by user case scenario)

Contents

Principles of Good Design Software Development Process Project Introduction

Description of the toll system Task

Organization

Exam Project: Model of a Toll System

I Report

I 45 min group presentation

A detailed project description can be found on CampusNet

Toll Lane

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

Enterprise

Toll Station Enterprise

Toll Station

Toll Station

Toll Station :

: Enterprise Server

Enterprise Client

Webserver

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

Tasks

I Tasks

I Analyse the requirements

I Acceptance tests

I Design the system: Components, Interfaces, PSM’s, Classes, LSM’s, OCL constraints

I Use case realizations as sequence diagrams

I General remarks

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

I Abstract away from any concrete user interface representation: Application layer functionality

I Focus on the 6 use cases you have chosen

Evaluation Criteria

Evaluation Criteria

How well are the learning objectives in the course description accomplished by each participant.

I Danish law: Be able to evaluate everybody individually

I Two aspects:

a) to give a fair evaluation to each of you b) to be able to detect possible differences

→ 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

Evaluation Criteria (cont.)

I Correct use of UML diagrams and OCL constraints

I Understandability of the design

I Correct use case realizations that are consistent with the LSM’s, PSM’s, classes, interfaces, etc.

I Correct implementation of components

I Correct object life cycle state machine

I Appropriate abstraction level of the design

Organization

I Start: Today

I End: Wednesday 2.5

I Upload the reportas PDF and with the correct name on Campus Net using the assignment module

I Project presentations

I Mon 28.5—Tue 29.5

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

I Teaching assistants and I are available for questions / clarifications

I More detailed specification of the problem is on CampusNet

I Lectures continue

I No specific exercises, but exercise session 8:15—10: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 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

Course

I 2 more lectures

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

I Week 11: Verification of models: Model checking

I Week 12: No lecture

I Week 13: No lecture