Post on 17-Sep-2020
02291: System IntegrationWeek 9
Hubert Baumeisterhub@imm.dtu.dk
DTU ComputeTechnical University of Denmark
Spring 2013
Contents
More UML DiagramsObject DiagramsPackage DiagramsDeployment Diagram
Software Development Process
Exam Project Planning
Project Introduction
Object Diagram Example
Class Diagram Object Diagram
Object Diagram Purpose
I Snapshot of a running systemI objects: Instance of a classI links: instance of an association
I Communication diagram
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
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
Notation
I Value Specifications
I Slots
I Links to other objects
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
Package notation
I Notations for packages
Examples
I Dependencies between packages
Import vs access
«access»«access»BA
PQR
Deployment Diagram
Martin Fowler, UML Distilled
Contents
More UML Diagrams
Software Development Process
Exam Project Planning
Project Introduction
Software Development Challenges
I Challenges of Software DevelopmentI On timeI In budgetI No defectsI Customer satisfaction
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, . . .
Waterfall process
Delays in waterfall processes
D I TA
Time
Features
Release date
Iterative Processes: E.g. Rational Unified Process
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
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
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
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
Resource Triangle
Resource Triangle: Waterfall
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
eXtreme Programming (XP)
Sit-together
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 . . .
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
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
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
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
Contents
More UML Diagrams
Software Development Process
Exam Project Planning
Project Introduction
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
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
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
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
Contents
More UML Diagrams
Software Development Process
Exam Project Planning
Project IntroductionDescription of the toll systemTaskOrganization
Exam Project: Model of a Toll System
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)
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 ServerEnterprise Client
Webserver
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
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
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
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
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
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
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
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