Introduction to Agile Modeling

• A collection of best practices with a focus on effective modeling and documentation.

– Create agile models which are just barely good enough instead of extensive models, before source code is written.
– Not prescriptive. There are no detailed procedures, just advice for how to be an effective modeler.
– Through initial, high-level modeling you can gain the knowledge that you need to guide the project but choose to
wait to act on it.
• It is not a complete software process. Does not include:
– Programming activities (it does ask you to prove your models with code)
– Project management
– System deployment
– System operations or support
• It should be used with a full fledged process
– Agile Unified Process
– Ration Unified Process
– SCRUM
• Adopts and extends values for eXtreme Programming
– Communication
– Simplicity
– Feedback
– Courage
– Humility

1
Agile Modeling Best Practices

2
Enhances other software processes

3
Agile Model Driven Development (AMDD) lifecycle
The goal is to build a shared understanding of the high level requirements, not to write
detailed documentation. A critical success factor is to use modeling everyone can understand
and enable stakeholder participation.

4
AMDD through the Agile Development Lifecycle
Depicts how the AMDD activities fit into the various iterations of the agile software
Development cycle.

5
 Assume Simplicity & Embrace Change
• Requirements will change over time
• Incremental change of systems enable agility
• Initial iteration modeling you explore what you
need to build to so you can estimate and plan
the iterations
• Strive for rapid feedback on document from
stakeholders.
• Content is more important than representation
(many ways to model the same concept and all are right)

6
 How is AMDD Different?
• You do a little bit of modeling and then a lot of
coding vs. creating an entire design model
first.
• Design efforts are spread between your
modeling and coding activities.

7
 Why does AMDD work?
• You can still meet project planning needs by identifying
high-level requirements and potential architecture early
– allowing for cost and schedule estimates.
• Modeling identifies the technical risks.
• An iterative modeling approach enables you to focus on
the pieces of the systems you are actually going to build.
• You ask better questions in modeling sessions as you get
to know the domain better over time.
• Stakeholders give better answers when they have a
better understanding of the system.

8
Activity Diagram
• Typically used for business process modeling
• Models detailed logic for business rules
• Captured by a use case or user story
• Equivalent to flow charts or data flow diagrams

9
 Class Diagram
• Show the classes of the system, interrelationships, and operations and
attributes of the classes
• Can be used for conception/domain modeling and detailed design modeling

10
 Sequence Diagram

• Model the flow of logic within your

system
• Most popular for dynamic modeling
focusing on the behavior within your
system

11
 References
• www.agilemodeling.com
• www.visual-paradigm.com

12