INF5120 Modellbasert Systemutvikling Forelesning 17.03.2005 Agile Methods & Architecture QVT ATL, MOF2Txt Arne-Jørgen Berre 1
INF5120 - Forelesninger - 2005 M: MDA, T: Eclipse, IBM tool, C: COMET, U: U UML 2.0 (Literature references) 1. Intro to System Modeling, Background: OO and UML, RUP, MDA 2. Enterprise Architecture - Enterprise Modeling & MAF&MAFE, BPEL/BPMN (E1) 3. Requirements Modeling (Mappings from Enterprise to System architecture) 4. Software Architecture and architecture modeling (E2) 5. Enterprise and IT architecture (17. February DnD) 6*. UML 2.0 and UML SysML profile (Birger & Øystein)? 7. PIM modeling and PSM mappings/transformations (MDA, MOF, QVT) 8*. Component Modeling and OCL, Model transformation tools&qvt Modelware (JOEA) 9. Agile Methods and Agile Modeling, + QVT/ATL/M2T (17. March) F8 (E4) 10. Architectural Patterns, Design Patterns *tool and Refactoring (E2-a) 11*. Non-functional requirements Quality of service, a QoS profile in UML (JOEA) 12. Service Oriented Architectures UML profile, Interoperability and Data Architectures ADM and Ontologies (ATHENA) (E3) (E2-b) 13. Usability and human centered design (E5) 14. Aspect Oriented Computing, Agents, other PSMs 15. Product Lines Families, Frameworks, Reuse, RAS, Teamwork (E6) 16. LAST: Summary preparation for exam - Microsoft: Software Factories and Domain oriented languages (1 time)! 2
A Practical Guide to Enterprise Architecture 1: Systems Architecture 2: Software Architecture 3: Service Oriented Architecture 4: Software Product Lines 5: Methodology overview 6: Enterprise Unified Process 7: Agile Architecture 8: Agile Modeling 9: Presentation Tier Architecture 10: Usability and User Experience 11: Data Architecture 12: Thought Leadership 3
Agile Methods Smidige metoder The Agile Manifesto (See presentation by Kjetil Jørgensen-Dahl) 4
Agile Software Development Alliance Manifesto for Agile Software Development http://www.agilealliance.org/home We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 5
The Agile Alliance Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas 6
Extreme Programming XP (p. 114) Kent Beck, Ward Cunningham Chrysler 1996 (See presentation by Kjetil Jørgensen-Dahl) 7
XP - 4 basic principles and practices 4 basic principles: Feedback Communication Simplicity Courage 4 main practices: Continuous Planning Continuous Design Continuous Coding Continuous Testing Customers Developers Coaches/Managers 8
Agile Architecture Agility in a nutshell 9
An Agile approach to Architecture Focus on people, not technology or techniques Keep it simple Work iteratively and incrementally Roll up your sleeves Build it before you talk about it Look at the whole picture Make your architecture attractive to customers 10
Potential problems with traditional approaches to Enterprise Architecture There is not an architecture effort Skewed focus Developers do not know that the architecture exists Developers do not follow the architecture Developers do not work with the architects Outdated architecture Narrowly focused architecture methods 11
What should Architecture efforts produce? Support for the customers of the architecture A vision and plan to achieve that vision A collection of models and documentation describing the architecture 12
Potential problems with an Agile approach It does not include an explicit way to ensure compliancy It depends on people being responsible It requires you to actively strive to keep things simple It requires you to accept an agile approach to modeling and documentation It s all about people 13
Agile Modeling Extreme Modeling Traditionally - either - insist on sophisticated models before coding - or think that modeling is paper-intensive, overly bureaucratic, and waste of time Architect pro-modeling Programmer anti-modeling 14
Agile Modeling values Communication Courage Feedback Humility Simplicity 15
Principles of agile modeling Assume simplicity Embrace change Enabling the next effort is you secondary goal Incremental change Maximize stakeholder investment (onsite customer) Model with a purpose Multiple Models Quality work Rapid feedback Software is your primary goal 16
Principles of agile modeling (2) Travel light Content is more important than representation Everyone can learn from everyone else Know your models Know your tools Local adaptation Open and honest communication Work with people s instincts 17
Agile Modeling core practices Active stakeholder particpation Apply the Right Artifacts Collective Ownership Consider testability Create several models in parallell Create simple content Depict models simply Display models publicly 18
Agile Modeling (2) Iterate to another artifact Model in small increments Model with others Prove IT with code Use the simplest tools Apply modeling standards Apply patterns gently Discard temporary models Formalise contract models 19
Agile Modeling (3) Model to communicate Model to understant Reuse existing resources Update only when it hurts 20
Agile Models Agile models fulfil their purpose Agile models are understandable Agile models are sufficiently accurate Agile models are sufficient consistent Agile models are sufficiently detailed Agile models provide positive value Agile models are as simple as possible 21
Implications for Architects It s about people, not models and documents Models do not equal documents You can t think everything through from the start, and you do not need to anyway You must embrace multiple models Be prepared to take an iterative and incremental approach Your work needs to be just barely good enough, it does not need to be perfect The longer you go without feedback, the greater the risk that your architecture does not reflect the needs of your stakeholders It is your stakeholder s money that is being spent, not yours, therefore they should determine what they choose to fund 22