UML and Agile Methods: Looking for an Agreement

Jose A. Gallud

and Habib M. Fardoun

Escuela Superior de Ingenier

ıa Inform

atica, University of Castilla-La Mancha, Albacete, Spain

Ahlia University, Bahrein

Keywords:

UML, Agile methodologies, Xcrum.

Abstract:

One of the effects of the nth software crisis is the great expansion of agile methodologies. Many agile method-

ologies have appeared since the publication of the Agile Manifesto. Agile methodologies are considered light

in comparison to the traditional heavy ones. This paper describes (a) whether or not it is worth to use some

UML diagrams as artefacts in Agile methods and, (b) what would be the set of UML diagrams selected as

useful artefacts obtained in an agile process and why. The paper makes use of a particular agile method called

Xcrum to show how and when the proposed UML diagrams would be employed.

1 INTRODUCTION

The ﬁeld of Software Engineering has solved its nth

growth crisis with the emergence of agile methodolo-

gies. These methodologies seem to free the heavy

burden development teams were suffering while were

applying documentation-based methodologies. The

need to elaborate many UML artefacts has been con-

sidered a heavy task by the development team, with

an unworthy impact in the ﬁnal product.

The Agile Manifesto declares, among other ideas,

that agile teams come to value working software over

comprehensive documentation (Beck and several au-

thors, 2001). Heavy documentation is not forbidden

but it is not valued. Agile methods are introducing

new ways of controlling the development process and

reducing the need of documentation.

UML (J. Rumbaugh and Booch, 1998) has been

playing an important role in the heavy methodologies

we have been using during the last ten years. People

involved in development teams, software architects,

analysts, requirement engineers, software designers,

database architects, and so on, have been spending

hours elaborating long documents that were full of

use cases, activity, class, deployment and all kinds of

UML diagrams. The question that emerges now is

what is the role of UML in this new agile world?

This article declares the validity of UML in this

new agile age, and proposes a set of UML artefacts

that are compatible with Agile methodologies. The

proposal is based on Xcrum, a new agile proposal

for the object-oriented development of software appli-

cations and services. The Object Oriented program-

ming paradigm maintains its inﬂuence thanks to the

new programming paradigms introduced by the Inter-

net languages. Languages such as JavaScript, Python

or Ruby are presented in many modern Web projects,

and they are the appropriate technologies in projects

where Xcrum is applied.

The article is organized in the following sections.

Section II presents a brief overview of the current

landscape of software development. The next two

sections (Section III and IV) presents the basis of

Xcrum. Section V presents a general discussion of

the proposal. Finally, Section VI presents the conclu-

sions and future work.

2 AGILE METHODS

One of the effects of this latest software crisis is the

birth of agile methodologies. The appearance of the

now famous Agile Manifesto (Beck and several au-

thors, 2001) is the starting point of this new era. In

its genesis is a group of software engineers who de-

cided to rebel in the ”plan and document” style om-

nipresent in most development teams. At the time

of the emergence of the Agile Manifesto, methodolo-

gies such as the cascade model, the Rational uniﬁed

process (Rational Uniﬁed Process) (Kruchten, 2003),

or Rapid Application Development (RAD) (Martin,

1990) dominated the development teams.

As noted by Fox and Patterson (Fox and Patter-

son, 2014), the crisis of the 1960s led engineers to

try to develop methodologies that made it possible

780

Gallud, J. and Fardoun, H.

UML and Agile Methods: Looking for an Agreement.

DOI: 10.5220/0006940907800785

In Proceedings of the 13th International Conference on Software Technologies (ICSOFT 2018), pages 780-785

ISBN: 978-989-758-320-9

to develop quality software and predictable and con-

trolled budget. The results of this effort were a se-

ries of development processes based on planning and

documenting (Plan-and-Document). Some strategies

(process models) on which many of these develop-

ment processes are based are well known: Cascade

model, Spiral model and Iterative and Incremental

models. In this last group, the RUP process should

be located, which is a combination of the previous

models. Development processes based on Planning-

Document are tedious since they put a lot of emphasis

on the preparation of documents, such as templates,

memories and diagrams, which sometimes diverts at-

tention from the software product that is intended to

be developed.

The agile proposal tries to recover the lost promi-

nence for the software product in favour of docu-

ments and diagrams. Alternatively, the Agile Mani-

festo also gives importance to the motivation of the

development team, and to maintain ﬂuid contact with

the client.

As a result, agile methodologies began to emerge

that tried to apply the principles listed in the Agile

Manifesto. Among the best known we can mention

Scrum (Schwaber, 2004) and Extreme Programming

(better known as XP) (Beck, 2004).

From Scrum and XP, there are numerous agile

proposals that have been emerging, although these are

general proposals that are based on applying the prin-

ciples contained in the agile manifesto. For exam-

ple, DSM (Bussiness, 2001) is based on a principle

in the integrates several statements of the Agile Man-

ifesto: the best business value emerges when projects

are aligned with clear business objectives, often visi-

ble results are released and involve motivated people.

In this sense, Xcrum also applies the principles of the

Agile Manifesto, as it is an agile method based on XP

and Scrum.

Letelier, in (Letelier and Penades, 2017), presents

a catalogue (AgileRoadmap) to implement agile prac-

tices in development teams, without suggesting a par-

ticular agile method. The Xcrum proposal is similar

to AgileRoadmap in that it promotes agile practices,

although Xcrum is based on principles that come from

Scrum and XP, to which the object-oriented vision of

the solution joins.

In (Mekni et al., 2017), the authors summarize the

best-known agile methods to point out the little atten-

tion paid to software architecture. The authors then

propose a methodology to deﬁne software architec-

ture in agile environments. In Xcrum, the software

architecture is an essential element, since it is based

on starting deﬁning the solution as an object-oriented

solution.

To conclude this section, Xcrum is related to most

agile methods insofar as it applies the principles of the

Agile Manifesto. However, it is novel in that it takes

as reference two of them, Scrum and XP, to propose a

synthesis of both.

3 Xcrum

This section brieﬂy describes the main elements of

Xcrum (Gallud, 2018). The section is organized in

the following sections: roles, iteration, artefacts and

meetings.

Like any good agile method, the most important

artefact in Xcrum is the code tested and working. All

other elements are means to get the software product.

3.1 Roles of Xcrum

The roles of Xcrum take into account the separation of

responsibilities, business and techniques, suggested

by the Agile Manifesto. There is separation and also

complementarity since it is about that both work to-

gether in obtaining the solution.

Thus, Xcrum uses Business and Development as

terms to deﬁne the roles that identify two responsibil-

ities. Business deﬁnes the user stories and the priority

of them. Development is responsible for estimating

stories and converting them into code.

The Business role of Xcrum is equivalent to the

Scrum Product Owner. The Development role is

equivalent to the Scrum Team role. The ScrumMas-

ter of Scrum is the leader of the development team at

Xcrum.

3.2 Iteration in Xcrum

The heart of Xcrum is the Iteration in the same sense

that the Sprint is for Scrum. The Iteration in Xcrum

lasts from 1 to 4 weeks. At the end of the iteration, the

team must provide an increase in value in the form of

code tested and functioning.

The Xcrum Iteration is equivalent to the Scrum

Sprint.

3.3 Xcrum Artefacts

User stories: Xcrum is based on deﬁning the sys-

tem requirements (functional, non-functional and in-

formation) as user stories, in a similar way to other

agile methodologies.

• List of System’s Histories: is the list of user sto-

ries deﬁned by Business to describe a system.

UML and Agile Methods: Looking for an Agreement

781

This list is equivalent to the Scrum Product Back-

log.

• List of Iteration’s Stories: is the subset of stories

that are assigned to an iteration. This list is equiv-

alent to the Sprint Backlog.

• Progress Chart: is the diagram that in Scrum is

called Sprint Burndown and that serves to mea-

sure the progress of the iteration (sprint).

As it can be noted, the Xcrum artefacts are mainly

those of Scrum.

3.4 Xcrum Meetings

The Xcrum meetings follow the structure of Scrum,

with incorporation of some XP activities. The follow-

ing sections detail how XP activities are combined in

Scrum meetings.

3.4.1 Iteration Preparation Meeting

The two roles, Business and Development, partici-

pate in this meeting. In Scrum the Sprint Preparation

Meeting has two parts, in the ﬁrst one it is carried out

between Business and Development and its objective

is to choose the functionality of the next Sprint. In

Xcrum this meeting has the same objective, although

it is proposed to incorporate the activities of the Ex-

ploration and Commitment phases of XP, namely:

• Write a story: Business writes a functionality

• Estimate a story: Development estimates the time

• Divide a story: If you can not estimate

• Sort the stories: Business order by value and De-

velopment by risk

• Choose ﬁeld: Business chooses the end date of the

Iteration or functionality (and Development date)

As you can see, this part of the preparation meeting of

the Iteration takes advantage of the detail of activities

that XP provides, while, in Scrum, it is left undeﬁned.

The second part of the meeting corresponds to the

team and consists of detailing the tasks in which each

story is broken down.

3.4.2 Xcrum Daily Meeting

On a daily basis, the team reviews the status of the

project following the same scheme proposed by the

Daily Scrum. At this point some XP activities are

proposed to obtain the increment:

• Accept a task: a developer chooses a pending task

• Implement a task: deﬁne the test cases, implement

the task and integrate the code

• Recovery and re-estimation: these are activities to

readjust the load, or the dates, with respect to the

estimate.

These XP activities, incorporated into Xcrum, serve

to give content to the daily task of the team. The only

difference in relation to XP is that in Xcrum it is not

necessary to implement the task through the technique

of programming in pairs.

An important aspect of Xcrum are the tests. The

team must write test cases so that the meaning of ”ﬁn-

ished” is demanding, not thinking about Business, but

internally, thinking about the team.

In the day to day of development the third princi-

ple of Xcrum is put into play: Object Oriented Solu-

tion. We will deal with this aspect in a later section

(section VI).

3.4.3 Iteration Review Meeting

In Scrum, at the end of the Sprint, two meetings are

held: the Review meeting and the Retrospective meet-

ing. The ﬁrst is done with the Product Owner. The

second is internal to the team.

In Xcrum, a similar scheme to Scrum is proposed.

In the ﬁrst meeting (Review) the increase in value of

this Business Iteration is shown to check if it is what

you requested. The second part is that Development

reviews the realization of the iteration.

4 THE OBJECT-ORIENTED

APPROACH IN Xcrum

Since the appearance of the book Design Patterns

(E. Gamma and Vlissides, 2011), the paradigm of Ob-

ject Oriented programming has experienced a grow-

ing development that continues to inﬂuence many of

the software solutions regardless of the technology

used.

In recent years we have witnessed, in Web pro-

gramming, a renaissance of dynamic languages, some

of which have appeared for some time, such as

Javascript, Python, Ruby and PHP. While most dy-

namic languages can be said to be object oriented and

class oriented. However, languages such as Javascript

(at least until version 7), omit the deﬁnition of classes,

since they are languages oriented to prototypes and

functions, although it is possible to use them with the

same approach used in the object-oriented and class-

oriented paradigm.

There are many advantages to using the object-

oriented and class-oriented paradigm, as opposed to

prototype-oriented. However, this discussion is out-

side the scope of this article.

IDEE 2018 - Special Session on Interaction Design in Educational Environments

782

What interests us here is to deﬁne how to obtain

an object-oriented solution, and how it is integrated

into the Xcrum methodology.

Obtaining an object-oriented solution is based on

a single principle:

Object model should come ﬁrst

This principle establishes as a priority to ﬁrst de-

ﬁne the object model of our application. This means

that both the user interface and persistence must be

left for later. In this way, and in broad strokes, the

proposal for the content of the iterations follows this

sequence:

• Examine functionality based on user stories

• Deﬁne the object model (with the tests)

• Deﬁne the service layer

• Deﬁne the user interface

• Deﬁne the persistence layer

• Final deployment

This principle applies more easily to Web-based

solutions. In these environments, the ﬁrst phase (de-

ﬁne the object model), can be detailed as follows:

• Develop the model objects in the client: using the

tools provided by most browsers we can validate

our object model

• Deﬁne the tests using some testing framework

• Move the model to the server: the ideal solution

is for the client’s own object solution to be the

one we use on the server. This depends on the

technology chosen

• Adapt the tests to the model on the server

The ﬁrst step (develop the object model) is also

broken down into activities that are repeated until we

get the complete object model. Here we apply an

XP principle by which we design (and implement)

only what is needed, avoiding including everything

we know in advance that we will need. So, the object

model is obtained with the following steps:

1. Choose a functionality (from the list of user sto-

ries)

2. Draw the class diagram with the minimum that is

needed to implement that functionality

3. The team conducts a discussion of the model

4. Implement the classes following the diagram

5. Validation in the browser

6. Optional tests are implemented: It is not conve-

nient to write the tests too early to avoid rewrit-

ing. This contradicts an XP principle but is more

practical.

7. Go back to step 1

The previous steps are completed when the devel-

oped model contemplates a sufﬁcient set of functions.

This procedure is especially useful when using

the same technology for client and server (such as

Javascript and NodeJS). The beneﬁt of using the same

technology is applied to the tests, since the same set

of test cases, with minimal changes, is valid on the

server side.

5 UML AND AGILE

METHODOLOGIES

A true agile team member knows that the most im-

portant artefact obtained in an agile methodology is

the tested and working code. There is nothing more

important than the working code. All the other ag-

ile artefacts (list of user stories, iteration user stories

and progress chart) are only secondary tools to help

developers to control the agile process.

Regarding documentation and UML artefacts, one

thing is to force the development team to follow a

heavy and strict set of documentation as part of the

development process, as it happens in the Uniﬁed Pro-

cess, and a different thing is to let them decide what

artefacts they want to use and which ones to avoid.

An important Agile Manifesto principle says

“Build projects around motivated individuals” (Beck

and several authors, 2001), which can be applied to

UML artefacts. Provided that the development team

understand how UML can help to develop a modular

and extensible solution, they will be the ﬁrst to pro-

pose use one UML diagram.

The following set of UML artefacts are highly rec-

ommended to use in Agile methodology:

• Class diagrams

• Deployment diagrams

UML Sequence diagrams can be useful for the de-

velopment team. However, they could be considered

as optional artefacts.

The following sections describe the role of each

diagram in Xcrum. The fact we illustrate how to use

these UML artefacts in Xcrum does not mean they are

restricted to this agile method. They can be used in

any other agile method in the same way they are used

in Xcrum. At least it is sure they can be used in Scrum

and XP, since these agile methods are the foundation

of Xcrum.

UML and Agile Methods: Looking for an Agreement

783

5.1 UML Class Diagrams

UML class diagrams provides a structural object-

oriented view of our solution. This artefact is one of

the most important artefacts a development team can

use.

The team’s goal is to build an object-oriented so-

lution. One of the best means to reach this goal is by

using UML class diagram. Class diagram allows the

development team to discuss the best design that will

implement the required functionality.

The previous sections shows how Xcrum pro-

motes the deﬁnition of the object model at ﬁrst. As

you can see in that section, the step 2 is “Draw the

class diagram with the minimum that is needed to im-

plement that functionality”. Xcrum recommends the

team to design only those entities and relationships

that are needed to implement the selected user story.

As the solution is built by increments deﬁned by

the iterations, this artefact will be evolving as the

same pace as the software. First iterations will show

a few entities and relationships and, as long as the so-

lution grows, the class diagrams grows as well.

One of the hard aspects of using UML diagrams

is to maintain the coherence between the code and the

class diagram. This is not a problem since this review

can provoke the development team re-think the solu-

tion, which could derive in some kind of refactoring

or redesigning. Some developers ﬁnd better design

solutions after analysing the class diagram.

5.2 UML Deployment Diagrams

UML deployment diagrams can play an important

role in any software development process. When de-

veloping software using an agile methods, it is pos-

sible to use UML deployment diagrams for the exact

same purpose.

One of the ﬁrst step in the development of any

software is to deﬁne the architecture of the solution.

Special attention deserves the software architecture of

the solution. UML deployment diagrams are one of

the best means to represent the designed software ar-

chitecture.

UML deployment diagrams show the nodes and

artefacts that are involved in the solution, and how

they are interconnected. The different artefacts

change through the development of the software. At

the end of each iteration, the team can show the arte-

fact that has been included in that iteration.

In Xcrum we can use UML deployment diagrams

from the ﬁrst iteration, since this ﬁrst diagram pro-

vides the foundation elements of the software archi-

tecture. UML deployment diagrams allow the devel-

opment team to have a global idea of the important

building blocks of the solution.

5.3 UML Sequence Diagrams

UML sequence diagrams can play an important role

when the development team is discussing some com-

plex interaction among objects. The development

team can learn from the designed solution and ﬁnd

better ways to implement the desired functionality.

However, UML sequence diagrams have been de-

clared as optional artefacts due to different reasons.

There are two main reasons:

• An object-oriented solution well designed con-

sists on many small objects. In this solutions

the use of delegation and composition makes se-

quence diagrams hard to draw (and many times

useless)

• The wide use of dynamic languages (as Javascript

or Python) makes almost impossible to repre-

sent the complex behaviour they are able to im-

plement. Important aspects of the language as

are anonymous functions, cannot be easily rep-

resented using any of the UML interactions dia-

grams.

When using Xcrum, the development team is

kindly invited to design and build an object-oriented

solution. Therefore, we can experience the problem

addressed before about the number of small collabo-

rative objects. However, as stated before, the devel-

opment team can use a sequence diagram to discuss

a particular design or to explain the rest of the team,

how works a complex interaction among objects.

In summary, some UML diagrams, as class and

deployment diagrams, can be useful for an agile de-

velopment team since they can contribute to design

and build the best object-oriented solution. An object-

oriented solution provides many of the best qualities

any agile development team seeks, as are extensibil-

ity, modularity, robustness and correction.

6 CONCLUSIONS

This article argue in favour to asign a role to UML

artefacts in this new agile age. The proposal includes

a set of UML artefacts that are compatible with Agile

methodologies.

UML class diagrams and deployment diagrams

have been proposed as essential diagrams to be used

in any agile method. Sequence diagrams have been

declared as recommendable optional diagrams.

IDEE 2018 - Special Session on Interaction Design in Educational Environments

784

The proposal is explained using Xcrum, a new

agile method for the object-oriented development of

software applications and services. Xcrum has been

inspired by Scrum and eXtreme Programming.

This article shows that UML diagrams may be

useful to reach the goal of designing and building the

best software in the shortest time.

ACKNOWLEDGEMENTS

There is always someone whose ideas have been

source of inspiration. In our case we would like to

thank the small but bold group of Smalltalk develop-

ers since they are always promoting object-oriented

creative software.

REFERENCES

Beck, K. (2004). Extreme Programming Explained.

Addison-Wesley; 2nd edition.

Beck, K. and several authors (2001). Agile Manifesto. Web-

site. http://www.agilemanifesto.org.

Bussiness, A. (2001). The Dsm Agile Project Framework.

Website. https://www.agilebusiness.org/resources/

dsdm-handbooks/the-dsdm-agile-project-framework-

2014-onwards.

E. Gamma, R. Helm, R. J. and Vlissides, J. (2011). De-

sign Patterns: Elements of Reusable Object-Oriented

Software. Addison-Wesley.

Fox, A. and Patterson, D. (2014). Engineering Software as a

Service. An Agile Approach Using Cloud Computing.

Strawberry Canyon LLC.

Gallud, J. A. (2018). An agile object-oriented method to

develop modern software applications. In Technical

Report DIAB-18-05-2, DSI, UCLM.

J. Rumbaugh, I. J. and Booch, G. (1998). The Uniﬁed Mod-

eling Language Reference Manual. Addison Wesley.

Kruchten, P. (2003). The Rational Uniﬁed Process: An In-

troduction. Addison-Wesley Professional.

Letelier, P. and Penades, M. C. (2017). Agileroadmap: An

approach to implement agile practices in teams. In

IEEE Latin America Transactions, VOL. 15, NO. 7.

Martin, J. (1990). Rapid Application Development.

MacMillan Publishing Co. Ed.

Mekni, M., Mounika, G., Sandeep, C., and Gayathri, B.

(2017). Software architecture methodology in agile

environments. In J Inform Tech Softw Eng 7: 195.

doi: 10.4172/2165-7866.1000195.

Schwaber, K. (2004). Agile Project Management with

Scrum. Microsoft Press.

UML and Agile Methods: Looking for an Agreement

785