02291: System Integration Hubert Baumeister hub@imm.dtu.dk Spring 2011 Contents 1 Explorative Modelling 1 1.1 Example: MUD Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Example: EaseWaste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Software Development Process 6 2.1 Software Development Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Extreme Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3 Lean Software Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4 Cycle time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5 Create flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.6 Agile Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3 Project Introduction 22 3.1 Description of the toll system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2 Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3 Project Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.4 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 1 Explorative Modelling Explorative Modelling: The purpose of models • Models provide an overview over the system for a certain purpose that is easier to obtain than actually building the system – Purpose of models: e.g. plan the project, understand the problem , understand the design , guide the implementation – Make the problem easier by abstracting away from details • Problem: How can one make models executable so that one, e.g., test them? • Observation: Object-orientation provides: Abstraction and Encapsulation → Expressiveness of OO languages comes close to expressiveness of UML → Why not use OO languages as modelling languages? • Advantage over UML – OO programs can be executed which gives immediate feedback • Difference from a prototype – Only focus on the aspects one wants to model; disregarding, e.g. GUI , database , distribution , . . . 1
1.1 Example: MUD Game Example: MUD Game • Acceptance Tests – http://localhost:9999/MudOneA.SuiteSwepTests – Here we use the acceptance tests to drive our executable model instead of using a GUI • The Code – Eclipse project http://www2.imm.dtu.dk/courses/02291/files/MUD.zip (Includes the Fitnesse Wiki with tests) Example: MUD Game Class Diagram PersonalObject object nextLevel inventory objects Level connectedTo Room Player Offer currentRoom lastOffer StartRoom SpecialRoom Example: MUD Game Sequence Diagram 2
p1:Player p2:Player user 2 user 1 offer(obj1,p2) _receiveOffer(obj1,p1) o1:Offer offer(p1,obj2) _receiveOffer(obj2,p2) o2:Offer closeTrade() getPlayer getObject removeFromInventory(obj2) addToInventory(obj2) _closeTrade getPlayer getObject removeFromInventory(obj1) addToInventory(obj1) 1.2 Example: EaseWaste Example: Modelling of Waste Processes • Example of a Waste Process – Waste is transformed from the production in households to the final deposition on a landfill – The whole process produces emissions (or saves them) and uses resources (or saves them) 3
Goal • Create a model for waste processes – How waste is transformed – What emissions are produced and what resources are used • A first model of the waste Missing feedback in modelling as a problem • Model was done in cooperation with a PhD student from DTU Environment • I didn’t have the confidence that the model was good – The model didn’t help me understanding the details of their waste process modelling better → Missing feedback: Can the model model all type of waste processes? → Is the model appropriate to do all necessary computations? • Creating Feedback with Models a. Define a set of scenarios that the model should be able to model with inputs and expected outcomes (Use case scenarios) → Fit tests b. Show that the model is capable of modelling these scenarios (Use case realizations) → Execute the model wrt. the tests → Model is written in Ruby • All scenarios: http://pchub.imm.dtu.dk:8008/EaseWaste.TestSuites • Example scenario http://pchub.imm.dtu.dk:8008/EaseWaste.TestSuites.Us01SimpleIncinerationSimpleLci Only the domain is modelled 4
• The model focuses on the domain layer → no GUI → no database • Focus on clearly expressing the intention of the model – Focus only on big O performance and only if the clarity of the model was not compromised The model as a UML diagram 5
AbstractWasteProcess waste input Waste 1 name add_property LCI lci * 1 * waste_outputs * WasteFraction name SumLCI Scenario WasteProcess TCTable 1 ext.proc. proc.spec * * TypedLCI WasteGeneration type LCIComputation WasteLCILinkTable aspect 1 BasicLCI lci 1 Flow Exchange 1 name amount * lci lci_for_inputs lci_for_outputs ElementaryFlow ExternalProcess lci_for_inputs ExchangeInput ExchangeOutput lci_for_outputs • The real model: http://pchub.imm.dtu.dk:8008/files/html/doc/index.html Summary • Use a real (high level) progamming language to create the model – e.g. Java, Ruby, Scala, . . . – Model become executable – Models can be automatically tested – But, as with class diagrams, focus on the aspects you want to investigate and leave out aspects one is not interested in • In this course: – create class diagram, sequence diagrams, and state machines by reverse engineering from the model • In real life: – Tests can be reused . – Reverse engineering can be too expensive (e.g. keeping the class diagram up-to-date when the model changes) → Use tools, like eUML, to generate class diagrams (and other type of diagrams) from the model 2 Software Development Process 2.1 Software Development Processes Software Development Challenges 6
• Challenges of Software Development – On time – In budget – No defects – Customer satisfaction Software Development Process • Activities in Software Development – Understand and document what kind of the software the customer wants → Requirements Analysis – Determine how the software is to be built → Design – Build the software → Implementation – Validate that the software solves the customers problem → Testing → Verification → Evaluation: e.g. User friendliness • Each of the steps has its associated set of techniques • However, the techniques can be applied in different orders → Different software development processes – e.g. Waterfall and Iterative processes (e.g. Rational Unified Process (RUP), agile processes: Extreme Programming (XP), SCRUM, Feature Driven Development, Lean . . . ) Waterfall process 7
• Strict waterfall: An activity has to terminate (e.g. formally approved) before the next activity begins → No feedback possible from the later activities → Takes too long time for the system to be build, which does not allow the customer to give feedback Waterfall → No feedback from the next activity possible until the next activity is approved – But: during the design of the system new questions come up on how to interpret the requirements; or during the implementation questions come up on how to interpret the design → formal (costly) change process with approval → waste (c.f. Lean software development) → Iterative development improves on that (depends on the number of iterations) • Delay in one phase of the project delays the whole project Features A D I T Release date Time Features A D I T delay delay Release date Time 8
Iterative Processes: E.g. Rational Unified Process • Inception, Elaboration, Construction, Transition corresponds to Plan the project, understand the problem, build the solution, test the solution, maintain the solution – All activities occur throughout the project – After each iteration, the customer sees the product and gives feedback Agile Processes and Lean Software Development • eXtreme Programming (XP), Scrum, Feature Driven Development (FDD), Lean Software Development • Iterations getting shorter than with, e.g., RUP • New set of techniques: Pair programming, customer on site, user stories, test-first and test-driven develop- ment, . . . • Focus on marketable features – A feature of the software that is relevant for the customer – User stories (XP), Backlog (Scrum), Features (FDD), ... – Corresponds roughly to use case scenarios • Lean Software Development – Apply values and principles from Lean Production to Software Development 2.2 Extreme Programming eXtreme Programming (XP) • Defined by Kent Beck, Ward Cunningham, and others while working at Chrysler on the C3 project (a payroll system) end of the 90’s • Name: take classical software engineering techniques and put them to the extreme e.g. Tests are good: test always and make tests before writing the code → automatic tests and test-driven development 9
Kent Beck, eXtreme Programming, 1st edition eXtreme Programming Functionality F 7 F 6 F 5 F 4 F 3 AD T I AD T I R F 2 R AD T I F 1 1. Iteration Time Functionality F 6 F 5 F 4 AD T I F 8 AD T I F 3 R R F 2 AD T I R AD T I F 1 1. Iteration Time 10
Recommend
More recommend
