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

02291: System Integration

Hubert Baumeister

hub@imm.dtu.dk

Spring 2013

Contents

1 More UML Diagrams 1 1.1 Object Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Package Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2 Software Development Process 8 3 Exam Project Planning 16 4 Project Introduction 19 4.1 Description of the toll system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2 Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.3 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1 More UML Diagrams

1.1 Object Diagrams

Object Diagram Example Class Diagram 1

Object Diagram Update operation of Account 2

State before executing update(n)

{n + b >= 0} h: History bal=m a: Account bal=b prev

3

State after executing update(n)

a: Account bal=b+n h: History bal=m h1: History bal=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 Diagrams

Package 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» B A P Q R

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 Process

Software 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 T A

Time Features Release date

Iterative Processes: E.g. Rational Unified Process Agile processes and Lean Software Development 10

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

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

Agile Processes and Lean Software Development

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

Development

• 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 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 (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 time Time 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

3 2 4

A T I

Work Item

D

Queue WIP Queue Queue Queue WIP WIP WIP

8 7 9 10 5 6

Blah

4 2

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 Planning

Planning Agile Projects

• 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

• 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 should be 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 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 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 user

stories have been done and what still needs to be done and replan accordingly) Example Plan

• Remark: report structure = 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 the

text 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 to

do – 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 some

requirements 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 system

Exam Project: Model of a Toll System Toll Lane 19

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 20

Toll Station Enterprise Toll Station Toll Station Toll Station : : Enterprise Server Enterprise 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 Task

Task

• 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 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)

• 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 Organization

Organization

• 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 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

– Week 10: Model-driven architecture (MDA) and Agile modelling – Week 11: Verification of models: Model checking – Week 12: Guest lecture by NetCompany 23