Dr.P.M.MANOHAR, DEPT.

OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM

AGILE SOFTWARE DEVELOPMENT – MODULE-3

19ECS451: Agile Software Development

Module III: Agile Modelling and XP:

Agile Modelling and XP: Introduction, the fit, common practices, modelling
specific practices, XP objections to agile modelling, agile modelling and planning
XP projects, XP implementation phase.
Learning Outcomes:
After completion of this unit, the student will be able to:
1. How Agile Modelling enables developers to develop customized software(L1)
2. Illustrate common practices and specific practices(L3)
3. Apply XP objections to agile modelling(L4)
4. Distinguish agile modelling and planning XP projects(L5)
5. Create XP implementation phase(L6)

Agile Modelling and XP

Introduction
• Agile Modelling (AM) and eXtreme Programming (XP) are from the agile movement
and motivated by the desire to produce better software faster.
• The relationship between Agile Modelling and XP is discussed and how Agile Modelling
can actually enhance an XP project
The Fit
• In actual fact, many of the Agile Modelling practises fit straight into XP. In many
cases, they are the modelling equivalent of the XP programming-oriented practises.
• Do the Agile Modelling practises add any value to the XP practises
Dissimilarities:
• There may be a fundamental conflict, XP does not encourage big up-front modelling,
and Agile Modelling is obviously about modelling.
• Agile Modelling needs to be applied with some other development methodology to be
beneficial which brings a suite of agile techniques to the process of modelling.
• XP does do modelling, but not “big up-front modelling.”
• Modelling is performed as and when required during the lifetime of an XP project.
• When Modeling is applied, Agile Modelling practises can be extremely useful.

• Many of the Agile Modelling practices fit straight into XP and are the modelling
equivalent of the XP programming-oriented practices.
• Agile Modelling’s emphasis is modelling and XP’s emphasis is programming.

1
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-3

Common Practises
• They have quite a few practises in common. To illustrate this, consider Table below, pairs
up various Agile Modelling practises with their equivalent (or near-equivalent) XP
practises.
Table. Common practises between Agile Modelling and eXtreme Programming

• The emphasis on the two approaches differs, there is bound to be

a slight variation in emphasis within common practises but the intention is the same.
• For example, “Model with Others” is matched to “Pair Programming” because the
intention in both cases is that everything produced is examined and thought about by
two or more people.
• In Agile Modelling, we use modelling standards while in eXtreme Programming we use
coding standards.
• Other Agile Modelling practises have potentially less obvious parallels within
XP practises. But again if they are examined, it can be seen that they represent the
same or similar intention but from the modelling perspective. These are illustrated
in Table below.
Table. Parallel practises between Agile Modelling and eXtreme Programming

• For example, in Table when performing Agile Modelling you should consider how, what
you are modelling might be tested? How you can model to facilitate testing. This can be
then fed into the test-first coding style of XP.
• Agile Modelling also encourages modellers to work in “small increments” that is similar
to XP’s practise of defining a single test, implementing what is needed for that
test, before continuing with the next test.
• Finally, one way of validating models created in Agile Modelling is to prove those
models by implementing them. This is akin to requiring code to pass an individual test
before continuing. It also fits in very well with XP

2
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-3

Modelling Specific Practises

➢ The following practices doesn’t have place within XP:
• model with a purpose,
• using multiple models and
• know your models.
➢ XP's focus on modelling is limited, as it doesn't provide much information about the
process or the models created.
➢ Instead, discussions focus on stand-up modeling meetings, where existing code is
analyzed or new code explored using diagrams. XP “models” are often discarded,
never translated into a design tool.
Determine the three practises above have a role in XP
Model with a Purpose
• Many XP practitioners may view modelling as self-defeating, but it can have significant
purposes, such as the motivational category within Agile Modelling, which includes "Model
to Understand" and "Model to Communicate."
Model to understand the software
• Relevant when refactoring or extending the code.
• The nature of object-oriented systems necessitates considering cooperating classes together.
• Review the instances of the classes being created, interacted and are discarded.
• Producing a structural class diagram and one or more sequence diagrams will help
understand the code.
• To do this using Omondo plug-in for Eclipse for creation of class diagram is shown in the
diagram.

Fig. Creating a new UML diagram in Eclipse using Omondo

3
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-3

• Omondo presents classes and interfaces in the selected package which provides a selection
dialog to the user, and allow selection of classes and interfaces and relationships which have
to be included in the diagram and creates the class diagram.

Fig. Selecting the contents of the class diagram

• Then, Omondo then creates the class diagram displayed in Figure

Fig. The auto-generated class diagram

The package structure is now better understood than it would have been by simply examining
its contents shown in Figure.

4
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-3

Fig. Listing the package contents

• Drawing out the structure on a white board is more than sufficient is shown in Fig.

Fig. Hand drawn class diagram

Multiple Models
• The argument that XP is solely about programming suggests that using a single model can
hinder understanding of the complexity of the code
• If you wish to fully understand your application, then you may well need to consider a class
diagram (for the system structure), a sequence diagram (for its behaviour), a data diagram
(for the database representation), etc. This is still as true for XP as it is for Agile Modelling!
• You should then switch between the different models as and when required.

5
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-3

Know Your Models

• Whether you are an Agile modeller or an XP developer you need to know the tools
available to you. Even for those working on an XP project, modelling is relevant.
• Thus, XP developers need to understand the models available to them just as much as an
Agile modeller should. That is, they should understand the strengths and weaknesses of
different types of models.
• This will help them to keep models as simple as possible, as well as helps to apply
appropriate models which will help them to understand the systems under consideration.

XP Objections to Agile Modelling

Other arguments raised by XP practitioners against Agile Modelling include:
Modelling is all about big up-front design (the so called BMUF – Big Modelling Up-Front syndrome).
Agile Modelling clearly does not promote this. This is illustrated by the Agile Modelling practises
such as “Model in Small Increments” and “Prove it with Code.”
All models are permanent documents that must be updated when any changes are made. This is
clearly not what Agile Modelling says. For example, the practises “Discard temporary models,”
“Use the simplest tools” and “Update only when it hurts” contradict this view.
You need to use a complex modelling tool, such as Rational Rose to carry out any modelling
activity. However, as Agile Modelling explicitly debunks that myth, stating you should use
whatever modelling medium is appropriate, which may include modelling tools such as Rational
Rose, but also white boards, index cards, post-it notes, etc.
You need to know, and use, UML to create models. Agile Modelling emphasizes the use of various
representations, such as UML, but does not dictate a specific type. Modelers focus on creating
comprehensible diagrams for their audience, rather than ensuring a precise and complete UML
diagram.
XP does not encourage modelling. Actually this is wrong. XP does promote the creation and use
of models. The use of index cards for user stories and classes is a form of modelling. XP
practitioners will also often draw diagrams on white boards while trying to consider how to
address a problem of refactor code, etc. These are again forms of models.
XP does not create any documentation and models are a form of unnecessary documentation. XP
emphasizes code as the primary form of system documentation, but it should be suitable for the
intended audience. Source code is useful for programmers, but not end users, non-programmers,
or support personnel. Models like UML deployment diagrams can be useful for understanding
how the system will be installed over a network.

6
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-3

Agile modelling and Planning XP projects

• Agile Modelling fits into the project-planning aspects of an XP project. An XP project is
planned at a number of levels and at various points during an XP projects lifetime. Agile
Modelling practices may vary in relevance at different stages of the planning process, and
their potential benefits for XP can be explored.

Fig. The planning aspects of an XP project lifecycle

Initial Project Planning

There are two primary steps within the initial project-planning phase; these are
the initial planning game and the elaboration process.
1. Initial planning game
• Business and development often use Agile Modelling practices to clarify user stories during
the development process. This involves creating a User Interface mockup with flow charts to
prototype system behavior.
• For example, a membership web site's design involves diagrams on a white board to
illustrate fields and user interactions. The final application will be a Java 2 Enterprise
Edition-based web application is shown in following Figures.

7
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-3

Fig. User interface design

Fig. Basic member creation workflow

8
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-3

Fig. The membership web site implementation

2. Elaboration process.
• During the elaboration process, various models may be created to help the developers
understand what will be required of the system.
• Again, Agile Modelling practises can be of great help to produce better estimates, etc.
2. Iteration/Release Planning
• During the iteration/release planning stages, modelling is again important.
• Release planning game. Agile Modelling practices can assist in focusing modeling activities
to clarify user requirements, similar to the initial planning game.
• Elaboration process. Agile Modeling can be applied to minimize the burden of modelling
during the shorter project planning phase.

9
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-3

Iteration planning. It is necessary to break down user stories into tasks, model their
implementation, including initial class structures and behavior, to identify, clarify, or split tasks.

XP Implementation Phase
• Agile Modelling can be applied to various points in an XP project, such as understanding
code and refactoring it.
• It complements implementation-oriented practices like "Test-first coding" and "Refactoring"
rather than process-oriented ones like "The Planning Game" or "40 hour week rule."
• The practises to be looked at in this section are:
o refactoring,
o test-first coding,
o simple design and
o pair programming.
Refactoring

• Refactoring, a code improvement technique, is compatible with modelling activities,

particularly Agile Modelling, which is relevant to refactoring.
• Issues to consider when refactoring were given as:
• Make sure you know how to improve the code.
• Make sure what you have done has improved the code.
• “know what you are doing!” you should not refactor: “When you haven’t got a clear plan
of how you will improve the code.”
• Agile Modelling can be used to help with all three issues.
1. Agile Modelling is a cost-effective method for understanding and modifying a system's
functionality.
2. It allows for evaluation of refactoring and its benefits, making it a more efficient
approach than coding changes and considering results.
3. Agile Modelling also facilitates better communication between team members and other
developers. If a project has moved to XP, it may be necessary to update existing system
models, allowing for better decision-making on revisions.
For example, by considering the following two Agile Modelling practises:
• Update only when it hurts not to do so.
• Discard temporary models.
• The author suggests waiting for requests for existing models to update them in Just-In-Time
fashion, as XP projects may refactor multiple times before documentation, causing
unnecessary model revisions.
• Finally, tools that provide “in sync” modelling can really help Agile Modelling during
refactoring. Using such tools minimises the extra work required to produce the models but
maximises the benefits from having the models.
Test-First Coding
Test-first coding, which follows a specific cycle, may seem superfluous or contradictory at first
glance due to its reliance on modelling:

10
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-3

1. Write a test.
2. Write the code to be tested.
3. Run the test/get the code to work.
4. If the test has passed, then return to step 1 until finished.
• Agile Modelling is a crucial part of the Agile Development cycle, often used to understand
the requirements of a task.
• It helps identify tests for implementation and ensures that the team is engaged in the process.
Agile Modelling can also be useful when implementing business code after writing a test.
• A short "stand-up" design session with a pair-programming partner can clarify issues and
ensure everyone is involved, aligning with the "Prove it with Code" practice.
Thus, if you modify the test-first coding cycle to the following, then you are maximising this XP
practise, as well as, supporting the Agile Modelling principle of rapid feedback:
1. Write a test.
2. Model the solution.
3. Implement the solution.
4. Run the test/get the code to work.
5. Discard temporary models.
6. If the test has passed, then return to step 1 until finished.
Simple Design
The XP practise of simple design aims to promote the simplest implementation that will:
1. Run all the tests.
2. Has no duplicate code.
3. Makes it clear to anyone reading the code what it is meant to do.
4. Have the fewest possible classes and methods.
• Many XP circles argue that Agile Modelling promotes "Implement for today, design for
tomorrow," which is not what XP is about. Agile Modelling, on the other hand, focuses on
designing for today and leaving tomorrow to tomorrow.
• There are in fact a variety of Agile Modelling practises that also promote simplicity within
modelling. These are:
1. Create simple content.
2. Depict models simply.
3. Apply patterns gently.
4. Formalise contract models.

11
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-3

• The first practise essentially exhorts you not to get hung up on representation but focus on
the content and the meaning.
• In turn, the “Depict Models Simply” practise is complementary to this, promoting how you
present your models.
• Design Patterns, a tool designed to aid object-oriented design, can be beneficial in reusing
design knowledge and providing a common design vocabulary. However, they can be
applied inappropriately, as they may offer flexibility and extendibility that isn't needed
yet. Agile Modelling and XP require a simpler solution that solves the problem today, rather
than engineering features for tomorrow. Pattern-based solutions may be more complex,
take longer to develop, and make it harder for others to extend or refactor.
• The "Formalize Contract Models" practice aims to facilitate the interface between a project
and external technical groups, such as database teams and service suppliers, which may not
adopt an agile methodology. Agile Modelling encourages defining the interface between
these groups and oneself, making it easier to determine how to use external groups' systems
in an XP manner. Producing the contract model can be part of the XP elaboration process
and controlled using Agile Modelling practices.
Pair Programming
• Pair programming, as we know, involves two developers working together at a
single machine. Within the pair, one developer controls the mouse and keyboard
(the driver) while the other essentially monitors what the first is doing (the navigator).
• It is essentially that the pair communicates and understands what they are trying to
achieve. It is also important that the navigator understands how the driver is intended to
achieve their goals. There are situations when these goals can be achieved merely by
discussing what is to be done while sitting at the terminal.
• The author suggests that a modelling session is more effective than traditional software
analysis, as it helps consider alternative solutions and review progress. Figure below
presents a flow chart diagram for pair programming workflow, highlighting the
relevance of modelling within this context. Agile modelling practices ensure these points
are handled in an agile manner.

12
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-3

Fig.Pair-programming workflow annotated with modelling steps

13