Agile Integration Modeling Language (AIML): A conceptual ...
Agile Modeling Theory. 2 Agile Modeling (AM) AM is a chaordic, practices-based process for modeling...
-
Upload
scott-mathews -
Category
Documents
-
view
215 -
download
0
Transcript of Agile Modeling Theory. 2 Agile Modeling (AM) AM is a chaordic, practices-based process for modeling...
Agile Modeling
Theory
2
Agile Modeling (AM) AM is a chaordic, practices-based process for modeling
and documentation AM is a collection of practices based on several values
and proven software engineering principles AM is a light-weight approach for enhancing modeling
and documentation efforts for other software processes such as XP and RUP
Your Software Process
A Base Software Process(e.g. XP, RUP, DSDM, FDD, …)
Principles and Practices ofAgile Modeling (AM)
Other Techniques(e.g. Database refactoring)
Copyright 2001-2005 Scott W. Ambler
Copyright Scott W. Ambler
3
The Core of AM
Core Principles Assume Simplicity Embrace Change Enabling the Next Effort is Your
Secondary Goal Incremental Change Model With a Purpose Multiple Models Maximize Stakeholder
Investment Quality Work Rapid Feedback Software Is Your Primary Goal Travel Light
Core Practices Active Stakeholder Participation Apply the Right Artifact(s) Collective Ownership Create Several Models in
Parallel Create Simple Content Depict Models Simply Display Models Publicly Iterate to Another Artifact Model in Small Increments Model With Others Prove it With Code Single Source Information Use the Simplest Tools
Copyright Scott W. Ambler
4 Copyright Scott W. Ambler
Agile Model Driven Development Project Level
(www.agilemodeling.com/essays/amdd.htm)
Cycle n: Development
Cycle 2: Development
Cycle 1: Development
Cycle 0: Initial Modeling
Initial RequirementsModeling
(days)
Initial ArchitecturalModeling
(days)
Model Storming(minutes)
Implementation(Ideally Test Driven)
(hours)
Reviews(optional)
All Cycles(hours)
Copyright 2003-2005Scott W. Ambler
5 Copyright Scott W. Ambler
Agile Modelswww.agilemodeling.com/artifacts/
Conceptual Domain Modeling
- Class Responsibility Collaborator (CRC) Cards- Logical Data Model (LDM)- Object Role Model (ORM) Diagram- Robustness Diagram- UML Class Diagram
Usage Modeling- Acceptance Tests- Essential Use Cases- Features- System Use Cases- Usage scenario- User Stories- UML Use Case Diagram
Supplementary Requirements Modeling
- Business Rules- Conceptual Cases- Constraints- Glossary- Technical Requirements
User Interface Development
- Essential User Interface Prototype- User Interface Flow Diagram- User Interface Prototype
Architectural Modeling
- Change Cases- Free Form Diagram- Security Threat Modeling- UML Component Diagram- UML Deployment Diagram- UML Package Diagram
Dynamic Object Modeling
- UML Communication Diagram- UML Composite Structure Diagram- UML Interaction Overview Diagram- UML Sequence Diagram- UML State Machine Diagram- UML Timing Diagram
Process Modeling
- Data Flow Diagram (DFD)- Flow Chart- UML Activity Diagram- Value Stream Map- Workflow diagram
Detailed Structural Modeling
- External Interface (EI) Specification- Physical Data Model (PDM)- UML Class Diagram- UML Object Diagram
Copyright 2003-2005Scott W. Ambler
6
Tests as Primary ArtifactsReduce Documentation by Single Sourcing Information
Acceptance tests are considered to be primary requirements artifacts You can reduce your requirements documentation
dramatically Unit tests are considered to be detailed design
artifacts You can reduce your design documentation
dramatically and increase the chance that your detailed design artifacts are kept up to date by coders
www.agilemodeling.com/essays/singleSourceInformation.htm
Copyright Scott W. Ambler
7
Agile Documentation Travel light – You need far less documentation than
you think Agile documents:
Maximize stakeholder investment Are concise Fulfill a purpose Describe information that is less likely to change Describe “good things to know” Have a specific customer and facilitate the work efforts
of that customer Are sufficiently accurate, consistent, and detailed Are sufficiently indexed
Valid reasons to document: Your project stakeholders require it To define a contract model To support communication with an external group To think something through
www.agilemodeling.com/essays/agileDocumentation.htm Copyright Scott W. Ambler
8
Agile Software Requirements ManagementChanging Requirements Are a Competitive Advantage if You Can Act on Them: www.agilemodeling.com/essays/changeManagement.htm
{Each iteration implement the highest-priority requirements
Each new requirement is prioritized and added to the stack
Requirements may be reprioritized at any time
Requirements may be removed at any time
Requirements
HighPriority
LowPriority
Copyright 2004 Scott W. Ambler
Copyright Scott W. Ambler
9
Active Stakeholder ParticipationThe Stakeholders are the Experts, Shouldn’t They Model?
Project stakeholders should: Provide information in a timely manner Make decisions in a timely manner Actively participate in business-oriented
modeling www.agilemodeling.com/essays/activeStakeholderParticipation.htm www.agilemodeling.com/essays/inclusiveModels.htm
Copyright Scott W. Ambler
Agile Modeling
Details
11
AM Values (1)
The values of AM includes: communication, simplicity, feedback, courage, and humility.
Communication: It is critical to have effective communication between development team as well as with and between all project stakeholders.
Simplicity: Models are critical for simplifying both software and the software process.
12
AM Values (2)
Feedback: “Optimism is an occupational hazard of programming, feedback is the treatment”. (Kent Back, Extreme Programming Explained )
Courage: Need to make important decisions and to change direction by either discarding or refactoring completed work when some decisions proved inadequate.
13
AM Values (3)
Humility: All people involved with the project have equal value and should be treated with respect.
14
AM Principles (1)
AM defines a collection of core and supplementary principles that when applied on a software development project set the stage for a collection of modeling practices.
Core Principles are as follows: Assume Simplicity: Simplest solution is the
best solution. Embrace Change: People’s understanding
and requirements evolve over time.
15
AM Principles (2)
Enabling The Next Effort Is Your Secondary Goal: “When you are playing the software development game your secondary goal is to setup to play the next game”. (Alistair Cockburn,2002)
Incremental Change: Develop a small model, or perhaps a high-level model, and evolve it over time in an incremental manner.
16
AM Principles (3)
Maximize Stakeholder Investment: Developed software must meet the requirements of the project stakeholder since he is investing time, money, resources, etc.
Model With A Purpose: Identify a valid
purpose for creating a model and audience for the model.
17
AM Principles (4)
Multiple Models: Need to use multiple models since each model describes a single aspect of your software.
Rapid Feedback: Work closely with customers to understand and analyze their requirements and to develop a user interface that meets their need and provide opportunities for rapid feedback.
18
AM Principles (5)
Quality Work: Nobody likes sloppy work.
Software is your primary goal: Produced software should meet the stakeholders need in effective manner.
Travel Light: Create just enough models and documentation to get by.
19
AM Principles (6)
Supplementary principles: Content is more important than
representation: Any given model can be represented by several ways.
Everyone can learn from everyone else: Have the humility to recognize that one can never master everything.
20
AM Principles (7)
Know your models: Need to know the strengths and weaknesses of the multiple models to be effective in their use.
Open and honest communication: This enables people to make better decisions.
Work with people’s instincts: Instincts become sharper with the experience of software development.
21
AM Principles (8)
Know your tools: Know the features of the modeling tools for its effective use.
Local Adaptation: Adapt a specific approach to a project level as well as the individual level.
22
AM Practices (1)
AM defines a collection of core and supplementary practices, based on the principles of AM
Core practices are as follows: Active Stakeholder Participation: Project
success requires a significant level of involvement by project stakeholder.
Apply the Right Artifact(s): “Use the right tool for the job”. (e.g. A UML activity diagram is useful for describing a business process).
23
AM Practices (2)
Collective Ownership: Everyone can work on any model or any artifact on the project, if they need to.
Consider Testability: Do not build software if no one can test it.
Depict Models Simply: Key features are sufficient to understand the model.
24
AM Practices (3)
Create Simple Content: Don’t add any additional aspects to the model unless they are justifiable.
Create Several Models in Parallel: People are more productive when they work on several models simultaneously
Model with others: Dangerous to do it alone.
25
AM Practices (4)
Display Models Publicly: This supports open and honest communication since the current model is quickly accessible.
Iterate to Another Artifact: Start another artifact when you got stuck doing one.
Model in Small Increments: model a little, code a little, test a little, then deliver a little.
26
AM Practices (5)
Prove it with Code: validate the model by writing a corresponding code.
Use the Simplest Tools: Vast majority of models can be depicted on papers or whiteboard.
27
AM Practices (6)
Supplementary practices:
Apply modeling standards: Developers should agree on a common set of modeling standards on a software project.
Apply Patterns Gently: “Developers should consider easing into the application of a pattern, to apply it gently” (Martin Fowler and Joshua Kerievsky, 2001).
28
AM Practices (7)
Discard Temporary Models: Models quickly become out of sync with the code and there’s nothing wrong in discarding them.
Formalize Contract Models: Models are formalized when both parties agree to them and are ready to mutually change them over time if required.
29
AM Practices (8)
Model to Communicate: Need to create a contract model or to communicate with people external to the developing team.
Model to Understand: Explore the problem space, to identify and analyze the system requirements for the best potential solution that meets the requirements.
30
AM Practices (9)
Reuse Existing Resources: Take advantage of wealth of information by reusing the information (models and documentations).
Update only When It Hurts: Is not having the model updated is more painful than the effort of updating it?
31
When is a Model Agile?
Agile models are good enough when they exhibit the following criteria: They fulfill their purpose and no more. They are understandable. They are sufficiently accurate. They are as simple as possible. They are sufficiently consistent. They provide positive value. They are sufficiently detailed.
32
Agile Documentation (1)
A document is agile when it meets the following criteria: Agile documents maximize stakeholder
investment. Agile documents are “lean and mean”. Agile documents fulfill a purpose. Agile documents describe information that is
less likely to change. Agile documents describe “good things to
know”.
33
Agile Documentation (2)
Agile documents have a specific customer and facilitate the work efforts of that customer.
Agile documents are sufficiently accurate, consistent, and detailed.
Agile documents are sufficiently indexed.