INF5120
”Modellbasert Systemutvikling”
Forelesning 17.03.2005 Agile Methods & Architecture
INF5120 - Forelesninger - 2005
M: MDA, T: Eclipse, IBM tool, C: COMET, U
M: MDA, T: Eclipse, IBM tool, C: COMET, U:: UML 2.0 (Literature references) 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
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
Agile Methods – Smidige metoder
The Agile Manifesto
Agile Software Development Alliance
Manifesto for Agile Software Development
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.
The Agile Alliance
Kent BeckMike 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
Extreme Programming – XP (p. 114)
Kent Beck, Ward Cunningham – Chrysler 1996
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/ManagersAgile Architecture
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
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
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
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
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
Agile Modeling values
Communication Courage Feedback Humility SimplicityPrinciples 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
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
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
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
Agile Modeling (3)
Model to communicate
Model to understant
Reuse existing resources
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
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
