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} a: Account bal=b prev h: History bal=m 3
a: Account bal=b+n prev h1: History bal=b prev h: History bal=m State after executing update(n) 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 R Q P «access» «access» A B 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
Features A D I T Release date Time Iterative Processes: E.g. Rational Unified Process Agile processes and Lean Software Development 10
Functionality F 7 F 6 F 5 F 4 F 3 AD T I AD T I R F 2 R F 1 AD T I 1. Iteration Time Functionality F 6 F 5 F 4 AD T I F 8 F 3 AD T I R R F 2 AD T I R AD T I F 1 1. Iteration Time Functionality F 6 F 5 AD T I AD T I F 4 F 8 AD T I R AD T I AD T I R F 3a R R AD T I R F 2 R F 1 AD T I 1. Iteration Time 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 F 6 F 5 AD T I AD T I F 4 F 8 AD T I R R F 3a AD T I AD T I R R AD T I R F 2 R F 1 AD T I 1. Iteration Time 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 number of features cycle time = 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 number of features cycle time = feature implemantion rate • Agile: cycle time = 1 / 5 = 8 hours → 250 cycles Generating flow using Pull and Kanban I A D T Work Item Queue Queue Queue WIP 3 Queue WIP 3 WIP 3 WIP 3 6 4 2 3 5 7 10 8 9 Blah Composite 4 2 Leaf Assembly WIP = Work in Progress Limit 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 Release Release ... Iteration 1 ... Pl. Iteration n Iteration 1 Pl. Iteration n Pl. Pl. Planning Planning ... 1w−4w 1w−4w (but fixed) Release 1 Release m 3m−6m • 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
Recommend
More recommend
