Agile and Modeling/MDE: Friends or Foes?

Jordi CabotÉcole des Mines de Nantes,

Agile Tour 2010

http://www.emn.fr/x-info/atlanmod http://modeling-languages.com

Joint team between INRIA & Ecole des Mines de Nantes (France)

+10 members

Research focus on:– MDE core technologies

• metamodeling, model transformation, MaaS, model management,…– MDE applications

• reverse engineering, tool interoperability

Organizers of the “MDE Diploma” 1st full postgraduate program on MDE

Commitment to Eclipse open-source projects: – ATL, MoDisco, EMF Facet, AMW, AM3, TCS

Strong links with several software development companies

Participation in both national and international research projects

AtlanMod

Index

Introduction to Modeling/MDE

Modeling in Agile

Agile in Modeling

Modeling the Agile

I hope that this talk can be the beginning of some kind of

collaboration! If you’re interested in the Agile-Mde combination

let me know!!

Index

Introduction to Modeling/MDE

Modeling in Agile

Agile in Modeling

Modeling the Agile

Introduction

In the beginning: Model Driven Architecture /Model Driven Development

Now Model Driven Engineering : endless possibilities– DSLs– Model to model and model to text transformations– Model-driven Reverse Engineering– Megamodeling & Model management– Model V&V– Business Rules Reengineering– Tool interoperability– …

UMLCASE Tool

Code Generation

SourceCode

Relationship between MDA/MDD/MDE

MDE vs Programming Technical Spaces

Modelware Grammarware

MOF/KM3 (metametamode

l)

UML (metamode

l)

MyModel.uml

EBNF.g

Java.g

MyProgram.java

Same “architecture” but different abstraction level

MMa MMb

Ma Mb

MMa2MMb.atl

MMa is thesourcemetamodel

Ma is the source model Mb is the target model

MMB is thetargetmetamodel

Key elements in MDE: Models and Model Transformations

ATL Transformation

A MDD dev. process could be defined as a series of M2M

transformations plus one final M2T transf. to generate the code

Why modeling?

The benefits of modeling activities in a software development process are well-known (?):– Improves the productivity of the development team (e.g. models can

be used for a semi-automatic code-generation) – Reduces the number of defects in the final code (models facilitate

early evaluation of the system) – Capture and organize the understanding of the system (which btw,

eases the integration of new team members). Models are well suited for documentation

– Permit early exploration of alternatives – Increases the decomposition and modularization of the system – Facilitates the system's evolution and maintenance (e.g. by facilitating

tracing back the code to the original requirements) – Facilitates the reuse of parts of the system in new projects

Reality Check (but let’s be optimistic)

Modeling will be commonplace in 3 years time – S. Mellor– Though he is giving the same answer for the last 20 years

Let’s be optimistic: Technology hype cycle

MDE?

Maybe a more agile modeling approach will help to climb up?

Will it happen the same with Agile?

Index

Introduction to Modeling/MDE

Modeling in Agile

Agile in Modeling

Modeling the Agile

Modeling in Agile? Are you serious?

Modeling may seem to go against agile principles (how many of you employ modeling techniques in your daily work?)

Stephen Mellor: agile critique to mde: – models don't run (i.e. not working software), – can't be tested,– are just documentation, – require extra work and alignment (i.e. not adequate for late

requirement changes)

But let´s take a closer look!!!– Let´s see if modeling can be integrated in agile processes– And what kind of modeling would be more beneficial for those (avoid

“modeling just for the sake of modeling”)

Modeling and MDE are process-agnostic

Modeling is not a development process just a software development technique– Many people still think that UML is their development process!!!

MDE is not really a development process either. It´s more a development framework that states that models should be the key artifact in all development phases

Any development process could follow MDE principles and employ modeling techniques

Two interesting initiatives:– Modeling tailored for Agile: Agile Modeling– MDE tailored for Agile: Agile MDA

Agile Modeling

A practice-based methodology for effective modeling and documentation of software-based systems.

Simply put, Agile Modeling (AM) is a collection of modeling practices that can be applied on a software development project in an effective and light-weight (i.e. Agile) manner.

Lead by Scott Ambler. Web site: http://www.agilemodeling.com/

Some Agile Modeling Principles (I)

Model With A Purpose. identify a valid purpose for creating a model and the audience for that model, then develop it to the point where it is both sufficiently accurate and sufficiently detailed.

Travel Light. Every artifact that you create, and then decide to keep, will need to be maintained over time. Trade-off agility for convenience of having that information available to your team in an abstract manner. 

Multiple Models. You need to use multiple models to develop software because each model describes a single aspect/view of your software.

Rapid Feedback. By working with other people on a model you are obtaining near-instant feedback on your ideas.

Assume Simplicity. Keep your models as simple as possible. Don't depict additional features that you don't need today. You can always refactor in the future (yes, there are model refactoring techniques)

Some Agile Modeling Principles (II)

Embrace Change. Requirements evolve over time and so your models

Incremental Change. Develop good enough models. Evolve models over time (or simply discard it when you no longer need it) in an incremental manner.

Working Software Is Your Primary Goal. The primary goal is not to produce extraneous documentation, extraneous management artifacts, or even models.  Any (modeling) activity that does not directly contribute to this goal should be questioned

Enabling The Next Effort Is Your Secondary Goal. To enable it you will not only want to develop quality software but also create just enough documentation and supporting materials so that the people playing the next game can be effective. 

Agile Modeling Practices

These practices help to achieve the previous principles and integrate very

well in agile dev. processes

Agile MDA (I)

Ambler’s view: MDA combined with the agile modeling principles seen before. Executability by means of series of transformation steps

One of the best ways of realizing the benefits of models is generating

software artifacts from them

Agile MDA (II)

S. Mellor’s view: Executable UML / Executable models

Models are directly executable

Easy to test/simulate

Code-generation and model interpretation are then two different alternative strategies to "implement" executable models.

Many design decisions need to be predefined

Most times, models with limited expressivity (you can only draw what you can execute)

MDD: Isn’t this Agile?

Automatic Generation of a CRUD application

Isn‘t this agile? (II)

Only a static model (e.g. UML class diagram) is provided

A full CRUD application can be obtained (for prototyping or even as part of the final application)

Would you say this is an agile technique?

Would you adopt such technique in your development process?

This is exactly what many dev. frameworks (symfony, Django, Grails,…)

already provide (even if it is using a specific notation like Doctrine)

Many programmers are then in fact modelers as well!! (low-level modelers)

Even if they don´t want to acknowledge that

Index

Introduction to Modeling/MDE

Modeling in Agile

Agile in Modeling

Modeling the Agile

Can Agile help MDE engineers?

MDE engineers need to develop a large number of metamodels, model transformations, model injectors,…

Can agile techniques help in this process?

Can we just treat an MDE project as a software project and follow an agile method to develop MDE artifacts?

Can Agile help MDE engineers? (II)

As you can guess my answer is a rotund YES

Let’s take a look at, for instance, the 12 XP practices to see if we could have an Extreme Modeling method.

1. Pair programming -> Pair Modeling. Same benefits

2. Planning game -> Planning the releases of the MDE artifact makes completely sense

3. Test-driven development -> Test-driven (meta)modeling. Modeling by first writing tests that the new model excerpt must pass.

Can Agile help MDE engineers? (III)

4. Whole team -> Even easier in this case. Customers are the designers that will use the MDE artifacts in the next development project

5. Continuous integration -> new versions of the MDE artifacts can be immediately integrated in existing projects. We may need migration policies in place. Version control tools for models are also needed ( http://modeling-languages.com/content/version-control-tools-modeling-artifacts )

6. Design improvement -> Model refactorings

7. Small releases -> Incremental development of the MDE artifacts (e.g. a transformation that in each iteration processes a larger part of the input models)

8. Coding standard -> Modeling standard. A consistent style and format for models (e.g. naming rules for elements) is as important as for code (and for the same reasons, e.g. better understandability)

Can Agile help MDE engineers? (III)

9. Collective code ownership -> Collective model ownership

10. Simple design -> As for programs, there are many possible models to express the same thing. The simpler one should be chosen. What is not so clear is the meaning of simpler for models. Simpler means less elements? (btw, what does simpler mean for programs?)

11. System metaphor -> MDE artifacts should also be easy to explain to everybody

12. Sustainable pace -> Believe it or not, MDE engineers are also human (as programmers)

Index

Introduction to Modeling/MDE

Modeling in Agile

Agile in Modeling

Modeling the Agile

Agile is fashionable: Many companies want to look “modern” by adopting an agile method

• The introduction of a new software process in an organization is a difficult and often risky proposition.

This is especially true when adopting agile processes since they usually imply radical departures from traditional team structures, cooperation styles and relationships

• Therefore, many of them fail and may (wrongly) conclude that agile does not work.

Adopting agile methods is not easy

Agile is not for every project nor for every team The “not for every project” part is usually assumed The “not for every team” is not

E.g. Email I got a few days ago:What method would you use for a project where users change

requirements often: RUP or Scrum? Technology we use: Java (JDeveloper), Oracle DB and the ERP Microsoft Dynamics.

I cannot answer if I don’t know the organization and context of your team!!

Adopting agile methods is not easy

Companies need a better understanding of the implications and

requirements to adopt an agile method

Once this is understood you can even go beyond Agile:

Survey results: companies selling agile tools do not use agile methods

themselves! (http://www.drdobbs.com/tools/220301068 )

We face the same situation with people trying to adopt MDE

Buying nice code-generator tools is not enough

What if nobody in your team is good at modeling? (even if he/she is a great programmer)

Any method needs to be adapted to the reality of the company

Adopting agile methods is not easy

Also, remember: Introduction of ANY new technology decreases

productivity in the short term

Unfortunately, descriptions of software processes focus on the sequence of process activities and generated artefacts

Understanding the agile method is key

Picture from Wikipedia

Can a company implement Scrum with these descriptions?

Understanding the agile method is key (II)

SPEM view of the process

These descriptions ignore the social and organizational aspects of the agile method, such as:

– Which are the most critical roles? What are the consequences if they don’t perform?

– What are the skills required to perform each role? – Which other actors a member depends on in order to succeed in his goals?

What does he depend on them for?

This kind of knowledge is key to facilitate the adoption of a software process

Helps to assess the chances of successfully enacting the process by checking (prior to process adoption) whether the social aspects of the process will be a good fit for the current team members structure

Adopting agile methods is not easy

E.g. If nobody in the team has the skills to play the role of Scrum

master I cannot adopt Scrum

How modeling can help?

We propose to use models to represent a new perspective of agile methods

This perspective focuses on describing and analyzing the social and human aspects of the process.

To do so we make use of the i* modelling framework for visualizing relationships among social actors, particularly how they depend on each other to achieve individual and team goals.

The i* framework consists of two main models: the SD (Strategic Dependency) and SR (Strategic Rationale) model.

This is based on the work: H. Chiniforooshan, J. Cabot, E. Yu: Adopting

Agile Methods. Can Goal-Oriented Social Modeling Help?. 4th Int. Conf. on

Research Challenges for Information Systems (RCIS’10)

Strategic Dependency model

Focuses on the dependencies between the different actors/roles of the process and the goals they want to achieve

Two kinds of goals: hard goals (or simply goals) representing the functional objectives, and soft goals, expressing qualitative objectives.

Analysing this information helps to answer questions about the social aspects of the software process, as the ones mentioned before.

Strategic Dependency model (II)

Here is very clear what are the roles team members must fill and what

problems may appear when a given member does not deliver

Simplified SD model for Scrum

Strategic Rationale model

Once the SD is done we refine it to create the SR model

A SR model looks at the internals of each actor to see how the actor fulfils the goals that have been assigned to him/her in the SD model

Strategic Rationale model (II)

Decomposition of the “Team to be managed” responsibility

We are not inventing the contents, we are just representing them in a (hopefully) better way

Analysing the models

The models facilitate the evaluation of the adequacy of this process for the company.

For instance, looking at the models, any company willing to adopt Scrum should realize that it needs to check:– If there is somebody in the company that can play the role of Scrum

Master (and the same for the other roles) – If that person has the qualities required to play that role successfully

(does she have good relationship with the product owner? does she have good communication skills? ...)

– . . .

Analysing the models (II)

And be prepared to invest the required time/money to cover the gaps found in the analysis or assume their consequences

Consequences are the cascade problems triggered by not satisfying the expectations of the other actors shown as dependencies in the SD model.

E.g. a bad Scrum Master may fail at properly managing the team which then may cause the team to fail at delivering the incremental product updates, even if the Product Owner does a good prioritization of the backlog.

In the future…

We would like to develop a library of goal models for agile processes to facilitate the evaluation and comparison of different agile methods from a social perspective.

We are also interested in formalizing the method for adapting a given software process to the reality of each organization by matching the organization structure to the process goal-model template. Experiments already done with students developing a

software project with Scrum We were able to correctly identify the problems they would

have applying Scrum before they started the project We knew what parts of the model were impossible to

satisfy in their classroom setting -> we identify the goals that would not be fulfilled

In the future…

Conclusions

Agile and Modeling / MDE are friends and not foes

There are many ways in which they can benefit from each other– Modeling helps to understand agile processes and facilitates their

adoption– Modeling is a useful technique to integrate in an agile process– Agile techniques can improve the modeling phase of any software

development process

Continuing the discussion

http://modeling-languages.com

jordi.cabot@mines-nantes.fr

www.emn.fr/x-info/atlanmod

@softmodeling

And the Jeudi des Modèles series of conferences : http://www.emn.fr/z-

info/jmodeles/